Re: [Txauth] RS/AS communication for multiparty cases

[Denis <[e-mail]>]

Hi Justin,

> Fabien and Denis,
>
> I think here we can see that there are multiple different directions 
> that people’s use cases and concerns will pull GNAP’s design. Some 
> want to have the AS have no knowledge of the RS, and only the client 
> to know that; others want the AS to have knowledge of all of its RS’s 
> and be able to dispatch an naive client to one. The thing is, I think 
> both of these have merit and both of them can be accommodated in the 
> protocol. Allowing one does not disallow the other. It’s not up to 
> GNAP to decide which of these approaches is morally correct.

As soon as we allow a RS to get access tokens from multiples ASs, the 
driving of a client by a *single AS* does not make sense any more.
If we allow the RSs to drive the clients, it will also apply to "naive 
clients" and then they do not need to be driven by a *single AS*.

The model should be the same whether a RS requests to get an access 
token from a single AS or from multiple ASs.

The delegation model would also be quite different whether the client 
will be driven by a single AS or be driven by each RS
that is attempting to respond to an original operation.  Has the 
delegation model been discussed on the mailing list ?

Accommodating both approaches in the same protocol appears to me rather 
difficult:
I do not see how "privacy by design" could be melt into "spy by design" 
nor how "spy by design" could  be melt into "privacy by design".

Denis

> In particular, addressing both of these dimensions is one of the 
> things that having a multi-dimensional language for requesting 
> resources in a standard way is going to help beyond what OAuth 2 can 
> do. These queries can be designed in such a way to minimize disclosure 
> to the AS or to minimize the amount of knowledge in the client, or 
> anywhere in between. Ultimately it’s up to the RS to decide whether 
> the rights associated with the token are good enough for the request, 
> and GNAP’s proposed charter says we’ll be defining both a means for 
> fine-grained requests as well as a consistent data model for the 
> token’s rights. Neither of these assumes that the RS will be 
> identified, nor that it can’t be.
>
>  — Justin
>
>> On Jul 6, 2020, at 7:06 AM, Fabien Imbault <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Hi Denis,
>>
>> Thanks for your feedback. Your scheme is interesting and covers well 
>> the personal access.
>>
>> The variant I'm referring to is multiparty access, which is a fairly 
>> common pattern also. Handled as an extension in Oauth2, but to my 
>> knowledge it requires an additional relationship between RS and AS. 
>> Maybe we can come up with an alternative design, I don't know yet.
>>
>> Cheers.
>>
>> Fabien
>>
>>
>> Le lun. 6 juil. 2020 à 12:23, Denis <[e-mail] 
>> <mailto:[e-mail]>> a écrit :
>>
>>     Hello Fabien,
>>>     Thanks Denis. It clarifies what you have in mind.
>>>
>>>     While I agree with the general idea that we need to take privacy
>>>     more seriously, there are a few hypotheses that we need to put
>>>     in perspective :
>>>
>>>     1) AS-RS relationship <=> big brother. It may happen as we all
>>>     know, but you always have the choice as a user to not deal with
>>>     orgs you don't like
>>>     or maybe even take action if they don't respect the law.
>>
>>     Unfortunately, the choice you mention is not always possible.
>>     There is a fundamental point here: since it is not always
>>     possible to trust an AS to respect the law,
>>     it is possible to build an architecture where the AS will be
>>     unable to by-pass the law. It is the difference between :
>>
>>       * "the AS *should not* do this or that" (but it could if it
>>         would) and
>>       * "the AS *cannot do* this or that" (it cannot even if it would).
>>
>>>     2) the collusion possibility (Alice's uncle) : there are of
>>>     course situations where that may be an issue. This is I guess
>>>     the reason for the sovrin foundation
>>>     to require that only approved issuers can participate. But even
>>>     if you open up the system, it always ends up as whether you can
>>>     trust the uncle to be honest
>>>     in the first place (knowing that trust is a social construct).
>>
>>     When using computers, trust is not a "social construct". It is a
>>     construction where an entity A trusts an entity B for some
>>     behaviour C.
>>     In the ABC attack, the RS will never know whether someone
>>     forwarded or not an access token to Alice.
>>
>>>     So I may require the issuer to be a well known participant instead.
>>>
>>>     3) The use of hardware FIDO inspired components does relax some
>>>     of the previous concern, but comes with its own sets of challenges.
>>>     Biometrics come with their own sets of potential issues.
>>
>>     The use of FIDO does not imply that you must use its biometrics
>>     features.
>>
>>>     More trivially, if you loose your hardware, you loose your ID.
>>
>>     If you loose your ID, you should report of its loss. It also
>>     means that by design, a mechanism has been constructed to recover
>>     from the situation
>>     within a short period of time. Unfortunately, such a property is
>>     currently missing in FIDO, but it does not mean that it cannot be
>>     added.
>>
>>>     And there can also be hacks in hardware. If I find a way to
>>>     import or export the private key from the enclave, the system fails.
>>
>>     The whole system does not fail. When someone attempts to export a
>>     private key from an hardware device in an unlawful way, it takes
>>     some time and some expertise.
>>     As soon as the legitimate holder realizes the lost of his
>>     hardware, he should report the loss. Then after, the discovery of
>>     private keys stored into the device is no more an issue.
>>
>>>     So in the end, I agree it's best to enable as much privacy by
>>>     design as we possibly can, but we need to put that in
>>>     perspective with use cases too and make some tradeoffs.
>>>     Healthcare in particular is a domain that is concerned with a
>>>     constant balance between privacy and security, and sometimes
>>>     there is no possibility to tick all boxes.
>>>     I think an UMA2/OpenId Heart scenario is a very important case
>>>     to consider in that respect.
>>
>>     The goal of this BoF/WG is not to rubber-stamp the "Health
>>     Relationship Trust Profile for User-Managed Access 2.0"
>>     specification.
>>
>>     Since the "Health Relationship Trust Profile for User-Managed
>>     Access 2.0" specification has nothing really specific to
>>     healthcare, what is the "very important case" you have in mind ?
>>     Would it be possible to model a specific characteristic you have
>>     in mind in terms of model components, operations flows, trust
>>     relationships, privacy requirements and security requirements ?
>>
>>     Denis
>>
>>>
>>>     Fabien
>>>
>>>
>>>
>>>
>>>     On Fri, Jul 3, 2020 at 12:01 PM Denis <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>
>>>         Hello Fabien,
>>>
>>>         In 2017, I made a presentation at the OAuth workshop in Zurich.
>>>
>>>         The paper is available from:
>>>         https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf
>>>
>>>         The slides are available from:
>>>         https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt
>>>         _Note_: The slides should be viewed "full screen" to get the
>>>         animations.
>>>
>>>         The general approach is how to construct from scratch a
>>>         "privacy by design" architecture taking also into
>>>         consideration "security by design".
>>>
>>>         Coming back to your requirement, I would not cover it if it
>>>         infringes the sentence "the RS and the AS never communicate
>>>         directly".
>>>
>>>         You should start your design by defining the trust
>>>         relationships, then apply the privacy requirements while not
>>>         forgetting the security requirements.
>>>
>>>         Denis
>>>
>>>>         Hello Denis,
>>>>
>>>>         I have been following your comments. I still fail to see
>>>>         the global privacy preserving architecture you're
>>>>         proposing. It would help to get a more thorough proposal if
>>>>         you can.
>>>>
>>>>         But more specifically, I have a comment on :
>>>>
>>>>         "I would have preferred that you meant: the RS and the AS never
>>>>         communicate directly, which is indeed a nice property to follow
>>>>         to ensure the user's privacy."
>>>>         I think that may come as an issue in some cases, especially for multiparty patterns (like in UMA). Typically we may wish the RS to start a grant request and use the handle to continue until a token is generated.
>>>>         I think those cases, which weren't initially covered by OAuth2, are very important to cover as well. How would you cover such requirements?
>>>>         Fabien
>>>>
>>>
>>
>> -- 
>> Txauth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth
>