[WG-UMA] Scope and access tokens
eve at xmlgrrl.com
Tue Jan 11 20:51:39 EST 2011
Paul and I had a chance to meet F2F yesterday, and we filled a whiteboard or two with thoughts... I figured it might be useful (in my "council of dunces" fashion -- if I understand it, then we know it's understandable :-) to replay the discussion here, in preparation for tomorrow's ad hoc call at 9am PT. (I hope Paul will follow up with corrections and further thoughts.) Sorry in advance for the length of this message.
The direction we started to go for "scoped access" was, in essence, that the requester would approach the host trying to access something; the host would tell the requester where to go and what to ask for in order to succeed next time; the requester would convey enough info to the AM to let the AM figure out how to impose policies on the requester; and for the requester eventually to "qualify in" and get a token that would work at the host.
We had a couple of sources of discomfort with this.
- First, if the host *gives* the requester information to convey to the AM to kick off this process, are we violating minimal disclosure requirements and, thus, opening up security (and possibly privacy) issues? Using a "temporary referral" technique would mitigate this risk: The requester would approach the host as before, but then the host itself would create a short-lived referral description at the AM, give the requester the handle to that referral, and have it convey only the handle to the AM. (Paul's original ProtectServe sketch had a referral solution.)
- Second, we've been uncomfortable about exposing to requesters what the nature/extent of a "resource set" is; only the host ever really knows whether a resource set corresponds to a whole photo album, or a single resource, or everything the user owns on this host, or whatever. But this means the requester is in the dark about how to reuse the same token for the full extent of its "powers" for the entire set of resources and actions it applies to. We could consider this the naive-but-simple approach to UMA's flow and simply require the requester to go back for a new token every time. Or, still taking the naive approach, we could require the requester to go back for an upgrade to its single-for-this-user-at-this-host token every time. Or we could consider something more sophisticated that exposes resource set info to requesters (at least once they've become trusted by this user?).
Another issue surfaced, and it intertwines with these two and possibly points to partial solutions for them. It relates to a change that UMA underwent in the OAuth 1.0-to-2.0 transition that went unremarked at the time but is important for us to consider.
ProtectServe/UMA on OAuth 1.0 had a notion of an access token that (similarly to OAuth) merely reflected the *authentication* of that requester (in the context of that AM and user), but it also had an additional layer that reflected *authorization*. The act of authorization could be thought of as claims-derived, and the representation of that authorization could be thought of as the non-zero "scope" of the token.
But UMA on OAuth 2.0 today pretty much conflates these in its Step 2. Our Step 2 says the AM can respond to the requester's request in three ways: here's your access token based purely on your client credentials, you don't get no stinking access token, or please give me some claims first before I can determine whether you deserve an access token.
A cleaner separation would be for Step 2 to have two distinct parts. In the first part, the AM issues an "access" token to requesters that is really just a powerless authentication token for starters. In the second part, it has the opportunity to "upgrade" the token to give it some authorized power for real access (non-zero scope, possibly growing dramatically over time) by testing claims. Any requester already in possession of a baseline token could proceed directly to the second half of Step 2 to make it "good for" some purpose.
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
More information about the WG-UMA