The last few weeks have been fertile for the Kantara User-Managed Access work. First we ran a half-day UMA workshop (slides, liveblog) at EIC that included a presentation by Maciej Machulak of Newcastle University on his SMART project implementation; the workshop inspired Christian Scholz to develop a whole new UMA prototype the very same day. (And they have been busy bees since; you can find more info here.)
Then, this past week at IIW X, various UMAnitarians convened a series of well-attended sessions touching on the core protocol, legal implications of forging authorization agreements, our “Claims 2.0” work, and how UMA is being tried out in a higher-ed setting — and Maciej and his colleague Åukasz MoreÅ„ demoed their SMART implementation more than a dozen times during the speed demo hour.
In the middle of all this, Maciej dashed off to Oakland, where the IEEE Symposium on Security and Privacy was being held, to present a poster on User-Managed Access to Web Resources (something of a companion to this technical report, all with graphic design by Domenico Catalano).
Through it all, we learned a ton; thanks to everyone who shared questions and feedback.
Because UMA layers on OAuth 2.0 and the latter is still under development, IIW and the follow-on OAuth interim F2F presented opportunities for taking stock of and contributing to the OAuth work as well.
Since lots of people are now becoming familiar with the new OAuth paradigm, I thought it might be useful to share a summary of how UMA builds on and differs from OAuth. (Phil Windley has a thoughtful high-level take here.) You can also find this comparison material in the slides I presented on IIW X day 1.
Terms
UMA settled on its terms before WRAP was made public; any overlap in terms was accidental. As we have done the work to model UMA on OAuth 2.0, it has become natural to state the equivalences below more boldly and clearly, while retaining our unique terms to distinguish the UMA-enhanced versions. If any UMA technology ends up “sedimenting” lower in the stack, it may make sense to adopt OAuth terms directly.
- OAuth: resource owner; UMA: authorizing user
- OAuth: authorization server; UMA: authorization manager
- OAuth: resource server; UMA: host
- OAuth: client; UMA: requester
Concepts
I described UMA as sort of unhooking OAuth’s authorization server concept from its resource-server moorings and making it user-centric.
- OAuth: There is one resource owner in the picture, on “both sides”. UMA: The authorizing user may be granting access to a truly autonomous party (which is why we need to think harder about authorization agreements).
- OAuth: The resource server respects access tokens from “its” authorization server. UMA: The host outsources authorization jobs to an authorization manager chosen by the user.
- OAuth: The authorization server issues tokens based on the client’s ability to authenticate. UMA: The authorization manager issues tokens based on user policy and “claims” conveyed by the requester.
Dynamic trust
UMA has a need to support lots of dynamic matchups between entities.
- OAuth: The client and server sides must meet outside the resource-owner context ahead of time (not mandated, just not dealt with in the spec). UMA: A requester can walk up to a protected resource and attempt to get access without having registered first.
- OAuth: The resource server meets its authorization server ahead of time and is tightly coupled with it (not mandated, just not dealt with in the spec). UMA: The authorizing user can mediate the introduction of each of his hosts to the authorization manager he wants it to use.
- OAuth: The resource server validates tokens in an unspecified manner, assumed locally. UMA: The host has the option of asking the authorization manager to validate tokens in real time.
Protocol
UMA started out life as a fairly large “application” of OAuth 1.0. Over time, it has become a cleaner and smaller set of profiles, extensions, and enhanced flows for OAuth 2.0. If any find wider interest, we could break them out into separate specs.
- OAuth: Two major steps: get a token (with multiple flow options), use a token. UMA: Three major steps: trust a token (host/authorization manager introduction), get a token, use a token.
- OAuth: User delegation flows and autonomous client flows. UMA: Profiles (TBD) of OAuth flows that add the ability to request claims to satisfy user policy.
- OAuth: Resource and authorization servers are generally not expected to communicate directly, vs. through the access token that is passed through the client. UMA: Authorization manager gives host its own access token; host uses it to supply resource details and request token validation.
Much work remains to be done; please consider joining us (it’s free!) if you’d like to help us make user-managed access a reality.
you guys should have presented at Google I/O. Lot of interest and enthusiasm around OpenID and OAuth…….
on page 27/28 of the “Making the World Safe for
User-Managed Access” pdf what is the user disclosing to the client?
Hi Saqib– Thanks for your interest. I’m not sure what you mean about pages 27/28 specifically; they don’t seem to have stuff on them that’s relevant to your query. But in general, the thing being protected/disclosed is any web resource. The requester might have authorization to access a web page, calendar, photo, identity profile, health record, etc., or it could be an API endpoint a la OAuth APIs. And the type of access granted could include whatever makes sense: reading, writing, or even deleting… (UMAnitarians are partial to RESTful interfaces, but we can’t control the nature of APIs that someone might want to protect with UMA.) We’ve got a huge Scenarios and Use Cases document that explores some of the possibilities. Hope this helps!