Re: [WG-UMA] Preparing for progressing the specs / discussing and deciding new issue #358

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

...

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