Some brief thoughts from me. Scratching any of the itches, do you think? ==== The concern seems to be that the resource owner's authorization server must generally learn claims about the requesting party in order for the latter to satisfy policy conditions and gain access to protected resources. Indeed, UMA's Federated Authorization specification optionally enables a resource server to formally outsource resource protection to an authorization server, an access control architecture sometimes described in terms of a "policy decision point/policy enforcement point" split. This has value in that it enables the resource server to become simply a "relying party for authorization services", doing much less work itself and being able to scale better. If UMA is not used to assess claims at an authorization server, then each resource server has to collect and assess claims itself, which spreads the claims further. It also enables the resource owner to monitor and manage resource sharing from a single service. With regard to only requiring the requesting party to reveal a "credential score": There are use cases for Alice choosing to share resources on the basis of *non-uniquely identifiable* claims, for example, "prove you are a citizen of country X", or "prove possession of a one-time code or token". For these use cases (explored in this talk https://www.youtube.com/watch?v=QGNhtKA9MOM&feature=youtu.be), a single "credential score" may not work so well. (UMA does explicitly allow resource servers to add their own checking. "... [T]he resource server MAY apply additional authorization controls beyond those imposed by the authorization server. For example, even if an RPT provides sufficient permissions for a particular case, the resource server can choose to bar access based on its own criteria." See this section https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-08.h.... Thus, outside the scope of UMA, resource servers can "use their own sources of information about the client" and requesting party as they see fit.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Sun, Nov 12, 2017 at 10:03 AM, Adrian Gropper wrote:

I think this paper relates to this issue: https://github.com/ WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/ master/final-documents/identity-hubs-capabilities-perspective.pdf

Adrian

On Sun, Nov 12, 2017 at 12:14 PM Eve Maler wrote:

...

I've edited the Grant spec to take care of the two outstanding editorial issues (but haven't published it yet), and also the Disposition of Comments https://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+of... document. In the meantime, we received a late-breaking issue from an external commenter that I put into issue #358 https://github.com/KantaraInitiative/wg-uma/issues/358. I'll duplicate the text here so we can hopefully discuss and decide it efficiently, in email and if necessary in our upcoming call on Thursday:

*Authorization should be under the purview of the relying party*

*Referencing sections 3.3.1, 3.3.2, 3.3.4, and 6.2 of the UMA 2.0 Grant for OAuth 2.0 Authorization, our comments are as follows.*

*Authorization of a client should strictly be under the purview of the relying party, who would use their own sources of information about the client to determine that authorization. Including any information beyond an identity credential score with the credential itself invites invasion of privacy and trackability. Claims, then, should not contain personally identifiable nor sensitive information. Authorization must be separate from authentication.*

*The real-world analogy is the key master of a room. The key master is responsible for issuing and revoking keys and for knowing who those keys are given to; the keys themselves do not contain information about the person holding that key.*

Please weigh in with your comments. I will try and do so myself when I get a chance later tonight.

The goal is to wrap up all outstanding issues (as of now, this is the only one; the comment period closes at 11:59 UTC today) ASAP and vote out the (edited as required) specs for the LC to certify as ready for All-Member Ballot.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/

I would like to *close discussion of issue #358 before our Thursday call*. This is a request for WG participants to *speak up by Wednesday* if they believe any *concrete change* should be made to the specifications in response to the comment. Note that the comment does not request any specific changes. However, it mentions a few concepts that are -- if everything were read at face value -- seemingly contrary to UMA's base architecture: 1. Relying party/resource server being the exclusive entity (vs. the resource owner, the "user" in User-Managed Access) to authorize access 2. Relying party/resource server being the exclusive entity (vs. the authorization server, for the GDPR liability rationale Adrian gave and the scalability and the central monitoring and management user convenience rationales I gave) to collect claims 3. Claims consisting only of an identity credential/credential score (vs. a full variety of claim types, including non-identity/non-uniquely identifying credentials, as motivated by the examples I provided) 4. Claims only being about the client (vs. the requesting party -- I think they must have meant the requesting party, thinking about the discussion of privacy concerns with the claims) The focus seems mainly on nos. 2 and 3. If no one recommends a specific change, then I propose that we *take no spec action* in response to the comment, with the provided rationales. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Nov 13, 2017 at 2:18 PM, Eve Maler wrote:

Oh yes, in addition to Adrian's note and my last one, I also wanted to mention the UMA legal framework effort. The framework is intended to map technical UMA artifacts to legal devices such as contracts and licenses, and to enable the usage of these devices in a manner consistent with protecting privacy rights.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Nov 13, 2017 at 11:48 AM, Eve Maler wrote:

...

Some brief thoughts from me. Scratching any of the itches, do you think?

==== The concern seems to be that the resource owner's authorization server must generally learn claims about the requesting party in order for the latter to satisfy policy conditions and gain access to protected resources.

Indeed, UMA's Federated Authorization specification optionally enables a resource server to formally outsource resource protection to an authorization server, an access control architecture sometimes described in terms of a "policy decision point/policy enforcement point" split. This has value in that it enables the resource server to become simply a "relying party for authorization services", doing much less work itself and being able to scale better. If UMA is not used to assess claims at an authorization server, then each resource server has to collect and assess claims itself, which spreads the claims further. It also enables the resource owner to monitor and manage resource sharing from a single service.

With regard to only requiring the requesting party to reveal a "credential score": There are use cases for Alice choosing to share resources on the basis of *non-uniquely identifiable* claims, for example, "prove you are a citizen of country X", or "prove possession of a one-time code or token". For these use cases (explored in this talk https://www.youtube.com/watch?v=QGNhtKA9MOM&feature=youtu.be), a single "credential score" may not work so well.

(UMA does explicitly allow resource servers to add their own checking. "... [T]he resource server MAY apply additional authorization controls beyond those imposed by the authorization server. For example, even if an RPT provides sufficient permissions for a particular case, the resource server can choose to bar access based on its own criteria." See this section https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-08.h.... Thus, outside the scope of UMA, resource servers can "use their own sources of information about the client" and requesting party as they see fit.)

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sun, Nov 12, 2017 at 10:03 AM, Adrian Gropper wrote:

...

I think this paper relates to this issue: https://github.com/WebO fTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/f inal-documents/identity-hubs-capabilities-perspective.pdf

Adrian

On Sun, Nov 12, 2017 at 12:14 PM Eve Maler wrote:

...

I've edited the Grant spec to take care of the two outstanding editorial issues (but haven't published it yet), and also the Disposition of Comments https://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+of... document. In the meantime, we received a late-breaking issue from an external commenter that I put into issue #358 https://github.com/KantaraInitiative/wg-uma/issues/358. I'll duplicate the text here so we can hopefully discuss and decide it efficiently, in email and if necessary in our upcoming call on Thursday:

*Authorization should be under the purview of the relying party*

*Referencing sections 3.3.1, 3.3.2, 3.3.4, and 6.2 of the UMA 2.0 Grant for OAuth 2.0 Authorization, our comments are as follows.*

*Authorization of a client should strictly be under the purview of the relying party, who would use their own sources of information about the client to determine that authorization. Including any information beyond an identity credential score with the credential itself invites invasion of privacy and trackability. Claims, then, should not contain personally identifiable nor sensitive information. Authorization must be separate from authentication.*

*The real-world analogy is the key master of a room. The key master is responsible for issuing and revoking keys and for knowing who those keys are given to; the keys themselves do not contain information about the person holding that key.*

Please weigh in with your comments. I will try and do so myself when I get a chance later tonight.

The goal is to wrap up all outstanding issues (as of now, this is the only one; the comment period closes at 11:59 UTC today) ASAP and vote out the (edited as required) specs for the LC to certify as ready for All-Member Ballot.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/

As I read it, this is talking about the possibility of a malicious client gaining access to resources by impersonating the requesting party: 1. The malicious client learns that AcmeAS supports claims submission of some form that it can acquire*, and that AcmeRS always uses AcmeAS as its authorization server 2. The client sets itself up to acquire claims in that form about Bob, through some seemingly unrelated operation on its own service, without mentioning AcmeRS or AcmeAS. 3. The client requests resources at AcmeRS out of band, receives a ticket, and presents it along with claims about a user to AcmeAS 4. The client gains an access token in the Bob's name without Bob knowing about it. * I'm trying not to get hung up about what form the claims might be in that the client can acquire them, but for example, if the client knows that AcmeAS doesn't properly check the audience of ID Tokens, then an ID Token from a supported IdP would be one such form. This seems like a legitimate concern about claims submission by the Client. Assuming that it is, I don't think we can take no action. We can either (a) remove claim submission by the client completely, (b) add a privacy clause stating that the AS MUST NOT support claims submission from the Client unless the deployment is a closed ecosystem in which it can be sure the client has given consent for its credentials to be used without direct consent, or (c) something else...? Option (a) is probably the strongest, but least desirable, where as option (b) is much weaker. Cheers James On 14 November 2017 at 10:37, Andrew Hindle wrote:

I made a comment in GitHub. Unless I fundamentally misunderstood what the comment was getting at (which is entirely possible), I concur with Eve's assessment.

--&e

On Tue, Nov 14, 2017 at 12:45 AM, Eve Maler wrote:

...

I would like to *close discussion of issue #358 before our Thursday call*. This is a request for WG participants to *speak up by Wednesday* if they believe any *concrete change* should be made to the specifications in response to the comment.

Note that the comment does not request any specific changes. However, it mentions a few concepts that are -- if everything were read at face value -- seemingly contrary to UMA's base architecture:

1. Relying party/resource server being the exclusive entity (vs. the resource owner, the "user" in User-Managed Access) to authorize access 2. Relying party/resource server being the exclusive entity (vs. the authorization server, for the GDPR liability rationale Adrian gave and the scalability and the central monitoring and management user convenience rationales I gave) to collect claims 3. Claims consisting only of an identity credential/credential score (vs. a full variety of claim types, including non-identity/non-uniquely identifying credentials, as motivated by the examples I provided) 4. Claims only being about the client (vs. the requesting party -- I think they must have meant the requesting party, thinking about the discussion of privacy concerns with the claims)

The focus seems mainly on nos. 2 and 3.

If no one recommends a specific change, then I propose that we *take no spec action* in response to the comment, with the provided rationales.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Nov 13, 2017 at 2:18 PM, Eve Maler wrote:

...

Oh yes, in addition to Adrian's note and my last one, I also wanted to mention the UMA legal framework effort. The framework is intended to map technical UMA artifacts to legal devices such as contracts and licenses, and to enable the usage of these devices in a manner consistent with protecting privacy rights.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Nov 13, 2017 at 11:48 AM, Eve Maler wrote:

...

Some brief thoughts from me. Scratching any of the itches, do you think?

==== The concern seems to be that the resource owner's authorization server must generally learn claims about the requesting party in order for the latter to satisfy policy conditions and gain access to protected resources.

Indeed, UMA's Federated Authorization specification optionally enables a resource server to formally outsource resource protection to an authorization server, an access control architecture sometimes described in terms of a "policy decision point/policy enforcement point" split. This has value in that it enables the resource server to become simply a "relying party for authorization services", doing much less work itself and being able to scale better. If UMA is not used to assess claims at an authorization server, then each resource server has to collect and assess claims itself, which spreads the claims further. It also enables the resource owner to monitor and manage resource sharing from a single service.

With regard to only requiring the requesting party to reveal a "credential score": There are use cases for Alice choosing to share resources on the basis of *non-uniquely identifiable* claims, for example, "prove you are a citizen of country X", or "prove possession of a one-time code or token". For these use cases (explored in this talk https://www.youtube.com/watch?v=QGNhtKA9MOM&feature=youtu.be), a single "credential score" may not work so well.

(UMA does explicitly allow resource servers to add their own checking. "... [T]he resource server MAY apply additional authorization controls beyond those imposed by the authorization server. For example, even if an RPT provides sufficient permissions for a particular case, the resource server can choose to bar access based on its own criteria." See this section https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-08.h.... Thus, outside the scope of UMA, resource servers can "use their own sources of information about the client" and requesting party as they see fit.)

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sun, Nov 12, 2017 at 10:03 AM, Adrian Gropper < agropper@healthurl.com> wrote:

...

I think this paper relates to this issue: https://github.com/WebO fTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/f inal-documents/identity-hubs-capabilities-perspective.pdf

Adrian

On Sun, Nov 12, 2017 at 12:14 PM Eve Maler wrote:

...

I've edited the Grant spec to take care of the two outstanding editorial issues (but haven't published it yet), and also the Disposition of Comments https://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+of... document. In the meantime, we received a late-breaking issue from an external commenter that I put into issue #358 https://github.com/KantaraInitiative/wg-uma/issues/358. I'll duplicate the text here so we can hopefully discuss and decide it efficiently, in email and if necessary in our upcoming call on Thursday:

*Authorization should be under the purview of the relying party*

*Referencing sections 3.3.1, 3.3.2, 3.3.4, and 6.2 of the UMA 2.0 Grant for OAuth 2.0 Authorization, our comments are as follows.*

*Authorization of a client should strictly be under the purview of the relying party, who would use their own sources of information about the client to determine that authorization. Including any information beyond an identity credential score with the credential itself invites invasion of privacy and trackability. Claims, then, should not contain personally identifiable nor sensitive information. Authorization must be separate from authentication.*

*The real-world analogy is the key master of a room. The key master is responsible for issuing and revoking keys and for knowing who those keys are given to; the keys themselves do not contain information about the person holding that key.*

Please weigh in with your comments. I will try and do so myself when I get a chance later tonight.

The goal is to wrap up all outstanding issues (as of now, this is the only one; the comment period closes at 11:59 UTC today) ASAP and vote out the (edited as required) specs for the LC to certify as ready for All-Member Ballot.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

-- Andrew Hindle Hindle Consulting Limited +44 7966 136543 <+44%207966%20136543> Schedule a meeting https://freebusy.io/andrew@hindleconsulting.com/30min

------------------------------ Hindle Consulting Limited is a company registered in England and Wales. Company number: 8888564. Registered office: Claremont House, Deans Court, Bicester, Oxfordshire OX26 6BW, UK.

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

Thanks all Your consideration of this is both much appreciated and necessary, not least because it forms a provable trail that the matter is being given deep consideration. I am not directly and deeply involved in every detail of UMA so it is possible I am way off the mark. But when I looked at the comment, my first thought was that the commenter may not have been fully aware of the context and background of UMA. The phraseology used was reminiscent of what I might describe as 'classic' thinking - good, logical and understandable in its own way. But UMA, like many Kantara specifications that Kantara member volunteers and non member participants contribute to solve known industry issues, can be disruptive as it breaks new ground. Is it possible that there might be some 'over-thinking' by the Group in trying to respond to this comment? Not taking anything away from any comment .. but just sayin'.. Kind regards Colin Executive Director Cell: +44 (0)7490 266 778 Kantara Initiative Inc. https://kantarainitiative.org/ On Tue, Nov 14, 2017 at 5:27 PM, Eve Maler wrote:

Andi, thanks for the thorough writeup on GitHub.

James and I have just been discussing this. I had a little trouble understanding his interpretation until I mentally mapped "claims submission" onto "claims pushing" -- and "relying party" very roughly onto "*requesting party*"! Now I get it.

It's not clear which interpretation our commenter means; I'm going to ask Kantara staff to reach out and see if I can have a dialog with them just to clarify. But in any case, let's treat this potentially as two sub-issues:

- Sub-issue *(a)* (responses from Adrian, me, Andi): A concern about the existence of the authorization server as a separate service learning PII (vs. the service actually holding the protected resources), about the notion of "outsourcing" authorization, and about arbitrary claims being passed vs. the minimum possible. - Sub-issue *(b)* (response from James): A concern about claims being sent (pushed) by a potentially malicious client seeking access to a protected resource without authorization by the requesting party using that client.

If I can establish that the commenter's concern is *(b)*, we don't need to respond formally to *(a)*. If their concern is indeed *(a)*, we do need to respond to it (and I think we have plenty of fodder for a rationale for "no change"), but we should take a look at *(b)* regardless. You can't un-ring a bell.

Here is my comment on *(b)*.

James proposes we take one of two actions: remove claims pushing entirely, OR add a privacy consideration. The commenter pointed to an existing privacy consideration in Grant Sec 6.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#rqp-pr..., but it seems to me that this issue is, rather, a security challenge ("malicious client"). It turns out we already have a relevant security consideration section, Grant Sec 5.7 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#trust-... (Requirements for Pre-Established Trust Regarding Claim Tokens). Since the use cases for claims pushing are pretty well-documented in that section, does it make sense to enhance that section with RqP authorization comments and tie that in with some additional comments at the following points?

- Grant Sec 3.3.1 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#uma-gr...: Client Request to Authorization Server for RPT - claim_token: "The client MAY provide this information on both first and subsequent requests to this endpoint." - pct: "Given that some claims represented by a PCT are likely to contain identity information about a requesting party, a client supplying a PCT in its RPT request MUST make a best effort to ensure that the requesting party using the client now is the same as the requesting party that was associated with the PCT when it was issued." - Grant Sec 3.3.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#claim-...: Resource Server Response to Client on Permission Request Failure - "The client redirects an end-user requesting party to the authorization server's claims interaction endpoint for one or more interactive claims-gathering processes as the authorization server requires. These can include direct interactions, such as account registration and authentication local to the authorization server as an identity provider, filling out a questionnaire, or asking the user to authorize persistent storage of any collected claims to optimize future authorization processes; this last example could potentially be associated with the authorization server's subsequent issuance of a PCT." - "In order for the client to redirect the requesting party immediately on receiving the initial permission ticket from the resource server, this process assumes that the authorization server has statically declared its claims interaction endpoint in its discovery document." - Do we actually need an additional privacy consideration to match the security consideration? Or need to enhance the text in Sec 6.2?

Thoughts?

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Nov 14, 2017 at 3:11 AM, James Phillpotts < james.phillpotts@forgerock.com> wrote:

...

As I read it, this is talking about the possibility of a malicious client gaining access to resources by impersonating the requesting party:

1. The malicious client learns that AcmeAS supports claims submission of some form that it can acquire*, and that AcmeRS always uses AcmeAS as its authorization server 2. The client sets itself up to acquire claims in that form about Bob, through some seemingly unrelated operation on its own service, without mentioning AcmeRS or AcmeAS. 3. The client requests resources at AcmeRS out of band, receives a ticket, and presents it along with claims about a user to AcmeAS 4. The client gains an access token in the Bob's name without Bob knowing about it.

* I'm trying not to get hung up about what form the claims might be in that the client can acquire them, but for example, if the client knows that AcmeAS doesn't properly check the audience of ID Tokens, then an ID Token from a supported IdP would be one such form.

This seems like a legitimate concern about claims submission by the Client. Assuming that it is, I don't think we can take no action. We can either (a) remove claim submission by the client completely, (b) add a privacy clause stating that the AS MUST NOT support claims submission from the Client unless the deployment is a closed ecosystem in which it can be sure the client has given consent for its credentials to be used without direct consent, or (c) something else...? Option (a) is probably the strongest, but least desirable, where as option (b) is much weaker.

Cheers James

On 14 November 2017 at 10:37, Andrew Hindle wrote:

...

I made a comment in GitHub. Unless I fundamentally misunderstood what the comment was getting at (which is entirely possible), I concur with Eve's assessment.

--&e

On Tue, Nov 14, 2017 at 12:45 AM, Eve Maler wrote:

...

I would like to *close discussion of issue #358 before our Thursday call*. This is a request for WG participants to *speak up by Wednesday* if they believe any *concrete change* should be made to the specifications in response to the comment.

Note that the comment does not request any specific changes. However, it mentions a few concepts that are -- if everything were read at face value -- seemingly contrary to UMA's base architecture:

1. Relying party/resource server being the exclusive entity (vs. the resource owner, the "user" in User-Managed Access) to authorize access 2. Relying party/resource server being the exclusive entity (vs. the authorization server, for the GDPR liability rationale Adrian gave and the scalability and the central monitoring and management user convenience rationales I gave) to collect claims 3. Claims consisting only of an identity credential/credential score (vs. a full variety of claim types, including non-identity/non-uniquely identifying credentials, as motivated by the examples I provided) 4. Claims only being about the client (vs. the requesting party -- I think they must have meant the requesting party, thinking about the discussion of privacy concerns with the claims)

The focus seems mainly on nos. 2 and 3.

If no one recommends a specific change, then I propose that we *take no spec action* in response to the comment, with the provided rationales.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Nov 13, 2017 at 2:18 PM, Eve Maler wrote:

...

Oh yes, in addition to Adrian's note and my last one, I also wanted to mention the UMA legal framework effort. The framework is intended to map technical UMA artifacts to legal devices such as contracts and licenses, and to enable the usage of these devices in a manner consistent with protecting privacy rights.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Nov 13, 2017 at 11:48 AM, Eve Maler wrote:

...

Some brief thoughts from me. Scratching any of the itches, do you think?

==== The concern seems to be that the resource owner's authorization server must generally learn claims about the requesting party in order for the latter to satisfy policy conditions and gain access to protected resources.

Indeed, UMA's Federated Authorization specification optionally enables a resource server to formally outsource resource protection to an authorization server, an access control architecture sometimes described in terms of a "policy decision point/policy enforcement point" split. This has value in that it enables the resource server to become simply a "relying party for authorization services", doing much less work itself and being able to scale better. If UMA is not used to assess claims at an authorization server, then each resource server has to collect and assess claims itself, which spreads the claims further. It also enables the resource owner to monitor and manage resource sharing from a single service.

With regard to only requiring the requesting party to reveal a "credential score": There are use cases for Alice choosing to share resources on the basis of *non-uniquely identifiable* claims, for example, "prove you are a citizen of country X", or "prove possession of a one-time code or token". For these use cases (explored in this talk https://www.youtube.com/watch?v=QGNhtKA9MOM&feature=youtu.be), a single "credential score" may not work so well.

(UMA does explicitly allow resource servers to add their own checking. "... [T]he resource server MAY apply additional authorization controls beyond those imposed by the authorization server. For example, even if an RPT provides sufficient permissions for a particular case, the resource server can choose to bar access based on its own criteria." See this section https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-08.h.... Thus, outside the scope of UMA, resource servers can "use their own sources of information about the client" and requesting party as they see fit.)

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sun, Nov 12, 2017 at 10:03 AM, Adrian Gropper < agropper@healthurl.com> wrote:

> I think this paper relates to this issue: https://github.com/WebO > fTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/f > inal-documents/identity-hubs-capabilities-perspective.pdf > > Adrian > > On Sun, Nov 12, 2017 at 12:14 PM Eve Maler wrote: > >> I've edited the Grant spec to take care of the two outstanding >> editorial issues (but haven't published it yet), and also the Disposition >> of Comments >> https://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+of... >> document. In the meantime, we received a late-breaking issue from an >> external commenter that I put into issue #358 >> https://github.com/KantaraInitiative/wg-uma/issues/358. I'll >> duplicate the text here so we can hopefully discuss and decide it >> efficiently, in email and if necessary in our upcoming call on Thursday: >> >> *Authorization should be under the purview of the relying party* >> >> >> *Referencing sections 3.3.1, 3.3.2, 3.3.4, and 6.2 of the UMA 2.0 >> Grant for OAuth 2.0 Authorization, our comments are as follows.* >> >> >> *Authorization of a client should strictly be under the purview of >> the relying party, who would use their own sources of information about the >> client to determine that authorization. Including any information beyond an >> identity credential score with the credential itself invites invasion of >> privacy and trackability. Claims, then, should not contain personally >> identifiable nor sensitive information. Authorization must be separate from >> authentication.* >> >> >> *The real-world analogy is the key master of a room. The key master >> is responsible for issuing and revoking keys and for knowing who those keys >> are given to; the keys themselves do not contain information about the >> person holding that key.* >> >> >> Please weigh in with your comments. I will try and do so myself >> when I get a chance later tonight. >> >> The goal is to wrap up all outstanding issues (as of now, this is >> the only one; the comment period closes at 11:59 UTC today) ASAP and vote >> out the (edited as required) specs for the LC to certify as ready for >> All-Member Ballot. >> >> >> *Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: >> xmlgrrl | Twitter: @xmlgrrl >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA@kantarainitiative.org >> https://kantarainitiative.org/mailman/listinfo/wg-uma >> > -- > > Adrian Gropper MD > > PROTECT YOUR FUTURE - RESTORE Health Privacy! > HELP us fight for the right to control personal health data. > DONATE: https://patientprivacyrights.org/donate-3/ >

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

-- Andrew Hindle Hindle Consulting Limited +44 7966 136543 <+44%207966%20136543> Schedule a meeting https://freebusy.io/andrew@hindleconsulting.com/30min

------------------------------ Hindle Consulting Limited is a company registered in England and Wales. Company number: 8888564. Registered office: Claremont House, Deans Court, Bicester, Oxfordshire OX26 6BW, UK.

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

If that is indeed the concern, then I'm not sure that is a specification issue per se; but rather a security consideration. A proper implementation would (as you say) check the issuer, and potentially have other ways to verify the source of claims (example: claims are digitally signed by a trusted cert). If it's not already in there (and my apologies: I honestly can't remember) then we should make sure we note this in security considerations; but I don't think a spec adjustment is necessary. --&e On Tue, Nov 14, 2017 at 11:11 AM, James Phillpotts < james.phillpotts@forgerock.com> wrote:

As I read it, this is talking about the possibility of a malicious client gaining access to resources by impersonating the requesting party:

1. The malicious client learns that AcmeAS supports claims submission of some form that it can acquire*, and that AcmeRS always uses AcmeAS as its authorization server 2. The client sets itself up to acquire claims in that form about Bob, through some seemingly unrelated operation on its own service, without mentioning AcmeRS or AcmeAS. 3. The client requests resources at AcmeRS out of band, receives a ticket, and presents it along with claims about a user to AcmeAS 4. The client gains an access token in the Bob's name without Bob knowing about it.

* I'm trying not to get hung up about what form the claims might be in that the client can acquire them, but for example, if the client knows that AcmeAS doesn't properly check the audience of ID Tokens, then an ID Token from a supported IdP would be one such form.

This seems like a legitimate concern about claims submission by the Client. Assuming that it is, I don't think we can take no action. We can either (a) remove claim submission by the client completely, (b) add a privacy clause stating that the AS MUST NOT support claims submission from the Client unless the deployment is a closed ecosystem in which it can be sure the client has given consent for its credentials to be used without direct consent, or (c) something else...? Option (a) is probably the strongest, but least desirable, where as option (b) is much weaker.

Cheers James

On 14 November 2017 at 10:37, Andrew Hindle wrote:

...

I made a comment in GitHub. Unless I fundamentally misunderstood what the comment was getting at (which is entirely possible), I concur with Eve's assessment.

--&e

On Tue, Nov 14, 2017 at 12:45 AM, Eve Maler wrote:

...

I would like to *close discussion of issue #358 before our Thursday call*. This is a request for WG participants to *speak up by Wednesday* if they believe any *concrete change* should be made to the specifications in response to the comment.

Note that the comment does not request any specific changes. However, it mentions a few concepts that are -- if everything were read at face value -- seemingly contrary to UMA's base architecture:

1. Relying party/resource server being the exclusive entity (vs. the resource owner, the "user" in User-Managed Access) to authorize access 2. Relying party/resource server being the exclusive entity (vs. the authorization server, for the GDPR liability rationale Adrian gave and the scalability and the central monitoring and management user convenience rationales I gave) to collect claims 3. Claims consisting only of an identity credential/credential score (vs. a full variety of claim types, including non-identity/non-uniquely identifying credentials, as motivated by the examples I provided) 4. Claims only being about the client (vs. the requesting party -- I think they must have meant the requesting party, thinking about the discussion of privacy concerns with the claims)

The focus seems mainly on nos. 2 and 3.

If no one recommends a specific change, then I propose that we *take no spec action* in response to the comment, with the provided rationales.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Nov 13, 2017 at 2:18 PM, Eve Maler wrote:

...

Oh yes, in addition to Adrian's note and my last one, I also wanted to mention the UMA legal framework effort. The framework is intended to map technical UMA artifacts to legal devices such as contracts and licenses, and to enable the usage of these devices in a manner consistent with protecting privacy rights.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Nov 13, 2017 at 11:48 AM, Eve Maler wrote:

...

Some brief thoughts from me. Scratching any of the itches, do you think?

==== The concern seems to be that the resource owner's authorization server must generally learn claims about the requesting party in order for the latter to satisfy policy conditions and gain access to protected resources.

Indeed, UMA's Federated Authorization specification optionally enables a resource server to formally outsource resource protection to an authorization server, an access control architecture sometimes described in terms of a "policy decision point/policy enforcement point" split. This has value in that it enables the resource server to become simply a "relying party for authorization services", doing much less work itself and being able to scale better. If UMA is not used to assess claims at an authorization server, then each resource server has to collect and assess claims itself, which spreads the claims further. It also enables the resource owner to monitor and manage resource sharing from a single service.

With regard to only requiring the requesting party to reveal a "credential score": There are use cases for Alice choosing to share resources on the basis of *non-uniquely identifiable* claims, for example, "prove you are a citizen of country X", or "prove possession of a one-time code or token". For these use cases (explored in this talk https://www.youtube.com/watch?v=QGNhtKA9MOM&feature=youtu.be), a single "credential score" may not work so well.

(UMA does explicitly allow resource servers to add their own checking. "... [T]he resource server MAY apply additional authorization controls beyond those imposed by the authorization server. For example, even if an RPT provides sufficient permissions for a particular case, the resource server can choose to bar access based on its own criteria." See this section https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-08.h.... Thus, outside the scope of UMA, resource servers can "use their own sources of information about the client" and requesting party as they see fit.)

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sun, Nov 12, 2017 at 10:03 AM, Adrian Gropper < agropper@healthurl.com> wrote:

...

I think this paper relates to this issue: https://github.com/WebO fTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/f inal-documents/identity-hubs-capabilities-perspective.pdf

Adrian

On Sun, Nov 12, 2017 at 12:14 PM Eve Maler wrote:

> I've edited the Grant spec to take care of the two outstanding > editorial issues (but haven't published it yet), and also the Disposition > of Comments > https://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+of... > document. In the meantime, we received a late-breaking issue from an > external commenter that I put into issue #358 > https://github.com/KantaraInitiative/wg-uma/issues/358. I'll > duplicate the text here so we can hopefully discuss and decide it > efficiently, in email and if necessary in our upcoming call on Thursday: > > *Authorization should be under the purview of the relying party* > > > *Referencing sections 3.3.1, 3.3.2, 3.3.4, and 6.2 of the UMA 2.0 > Grant for OAuth 2.0 Authorization, our comments are as follows.* > > > *Authorization of a client should strictly be under the purview of > the relying party, who would use their own sources of information about the > client to determine that authorization. Including any information beyond an > identity credential score with the credential itself invites invasion of > privacy and trackability. Claims, then, should not contain personally > identifiable nor sensitive information. Authorization must be separate from > authentication.* > > > *The real-world analogy is the key master of a room. The key master > is responsible for issuing and revoking keys and for knowing who those keys > are given to; the keys themselves do not contain information about the > person holding that key.* > > > Please weigh in with your comments. I will try and do so myself when > I get a chance later tonight. > > The goal is to wrap up all outstanding issues (as of now, this is > the only one; the comment period closes at 11:59 UTC today) ASAP and vote > out the (edited as required) specs for the LC to certify as ready for > All-Member Ballot. > > > *Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl > | Twitter: @xmlgrrl > > _______________________________________________ > WG-UMA mailing list > WG-UMA@kantarainitiative.org > https://kantarainitiative.org/mailman/listinfo/wg-uma > --

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

-- Andrew Hindle Hindle Consulting Limited +44 7966 136543 <+44%207966%20136543> Schedule a meeting https://freebusy.io/andrew@hindleconsulting.com/30min

------------------------------ Hindle Consulting Limited is a company registered in England and Wales. Company number: 8888564. Registered office: Claremont House, Deans Court, Bicester, Oxfordshire OX26 6BW, UK.

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

-- Andrew Hindle Hindle Consulting Limited +44 7966 136543 Schedule a meeting https://freebusy.io/andrew@hindleconsulting.com/30min -- ------------------------------ Hindle Consulting Limited is a company registered in England and Wales. Company number: 8888564. Registered office: Claremont House, Deans Court, Bicester, Oxfordshire OX26 6BW, UK.