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

From: Fabien Imbault <[email-masked]>
Date: Fri, 3 Jul 2020 11:27:42 +0200

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

---

From: Denis <[email-masked]>
Date: Fri, 3 Jul 2020 12:01:19 +0200

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

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 3 Jul 2020 16:46:13 +0200

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.
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). 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. More trivially, if you loose
your hardware, you loose your ID. 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.

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.

Fabien

On Fri, Jul 3, 2020 at 12:01 PM Denis <[email-masked]> wrote:

> *Note*: The slides should be viewed "full screen" to get the animations.
>
> Coming back to your requirement, I would not cover it if it infringes the
> sentence "the RS and the AS never communicate directly".
>
> privacy preserving architecture you're proposing. It would help to get a
> more thorough proposal if you can.
>

---

From: Denis <[email-masked]>
Date: Mon, 6 Jul 2020 12:15:41 +0200

Hello Fabien,
> 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

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

> 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.
>
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello Fabien,
>
>     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.
>>

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 6 Jul 2020 13:06:13 +0200

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 <[email-masked]> a écrit :

> fundamental point here: since it is not always possible to trust an AS to
> respect the law,
>    - "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).
>
> sovrin foundation
> open up the system, it always ends up as whether you can trust the uncle to
> be honest
> In the ABC attack, the RS will never know whether someone forwarded or not
> an access token to Alice.
>
> 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.
>
> 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.
> make some tradeoffs.
> balance between privacy and security, and sometimes there is no possibility
> to tick all boxes.
> 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 ?

---

From: Justin Richer <[email-masked]>
Date: Mon, 6 Jul 2020 13:27:53 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> a écrit :
> Hello Fabien,
>> 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 
> 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 
> 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.
> 
>> 3) The use of hardware FIDO inspired components does relax some of the previous concern, but comes with its own sets of challenges.
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> Hello Fabien,
>> 
>> 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.
>>> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Denis <[email-masked]>
Date: Mon, 6 Jul 2020 22:39:13 +0200

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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Denis,
>>
>> 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
>>
>>
>>>     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
>>     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 :
>>
>>>     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 ABC attack, the RS will never know whether someone
>>     forwarded or not an access token to Alice.
>>
>>>     3) The use of hardware FIDO inspired components does relax some
>>>     of the previous concern, but comes with its own sets of challenges.
>>     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
>>>     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.
>>
>>     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.
>>     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
>>>
>>>
>>>
>>>
>>>         The general approach is how to construct from scratch a
>>>         "privacy by design" architecture taking also into
>>>         consideration "security by design".
>>>
>>>         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.
>>>>
>> [email-masked] <mailto:[email-masked]>