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

[Justin Richer <[e-mail]>]

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.

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]> 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 <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 <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]
> https://www.ietf.org/mailman/listinfo/txauth