Authorization should be under the purview of the relying party

[xmlgrrl]

This issue was received from a commenter on November 11, during the second public comment period (for "relying party", perhaps understand as "resource server"/"authorization 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.

[agropper]

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

[andihindle]

Let's start by assuming, as Eve suggests, that "Relying Party" in this case means "Resource Server".

Let's further assume that, in the analogy presented, 'key master' == 'Auth. Server' and 'room'=='Resource'. The room is protected by a lock (=='Resource Server'), and I unlock the lock with a key (=='UMA Requesting Party Token')

As I read it, the primary concern appears to be that PII (read to include 'sensitive information') could be exposed to the AS ('key master'), rather than the RS ('lock') via the token ('key'). Which is odd - because this is exactly the flow that the analogy presents.

Indeed, I think the analogy they present is exactly how things already work in UMA. I request a 'key' (Requesting Party Token) from the 'key master' (AS). I present claims to the key master in order that the key master can decide whether to issue me with a key. UMA itself does not prescribe the format of such claims - hence, for a given implementation, the claims could contain PII that can be verified separately; or could contain some trustable statement (such as a boolean response to 'over-18?'). This is implementation-specific; and there are valid use-cases either way. The 'key' (i.e. RPT) does not contain any claims.

Let's then take a broader look at this. Perhaps the concern is with the 'risk' that, in the current UMA model, PII could be exposed to more places that might be desirable.

It is indeed the case that UMA supports the notion that the RS and the AS might be separate entities. (UMA does not require this of course...). However, since Claims are only ever shared with the AS, then even in the worst-case scenario that every RS maps to a single AS, Claims are still only sent to the same number of places. It is actually more likely that multiple RS's will map to a single AS - this reduces the number of places to which Claims are sent.

And again, Claims do not necessarily contain PII. Whether they do or do not is entirely implementation- and deployment-specific.

Finally, let's take an example from the paper that Adrian pointed to, and investigate what would happen if we wanted to use some form of self-sovereign identity solution to assert claims in an UMA flow.

In such a case (and skipping a few steps for brevity):

• The client collects claims from the self-sovereign solution (whatever it may be); it presents these claims to the AS to request an RPT.
• If the AS is not satisfied it requests more claims
• The Client collects the additional claims form the self-sovereign solution; and presents these to the AS
• If the AS is satisfied, away we go.

Again: UMA as a protocol has nothing to say about the format of those claims, nor what they should contain. For all UMA cares, it could be some signed token containing no real data for which the AS knows how to verify the signature. If the AS is satisfied with the signature, then this could be enough to satisfy the conditions for access. (I think that's unlikely in a real-world implementation - but it would be possible).

Conclusion: I do not think any specification adjustments are needed, because I do not think that the spec as written supports the concerns expressed in the comment.

Or am I missing something?

[xmlgrrl]

Being unable to tell quite what is at stake in the commenter's description (see the extensive list discussion thread), the group is considering this as two sub-issues:

• Sub-issue (a): 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): 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.

Taking into account several people's sentiments, I have proposed a "no change" resolution to sub-issue (a), with a rationale as follows:

One of the important benefits of UMA is to provide formal separation between the "keymaster" (roughly, PDP) and the "gatekeeper" (roughly, PEP), with trust established between them in the resource owner's context through OAuth. And indeed the "key" (access token/permissions) doesn't contain information about the "person" (requesting party/client pair) holding it; the keymaster assesses claims (which may or may not be related to personal information) as necessary before issuing it to the person. Then the gatekeeper is able to check with the keymaster about the key's exact shape and compare it to the tumblers of its lock.

And I have proposed a series of editorial changes that enhance existing security and privacy considerations in Grant in this message.

[xmlgrrl]

Per UMA telecon 2017-11-16, consensus on the above resolution to sub-issue (a) was reached.

[xmlgrrl]

Oops, meant to close this issue back in mid-November.