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

[Denis <[e-mail]>]

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
>>
>