New UMA solutions for scoped access and centralized AUTHZ
Session Topic: New UMA Solutions for Scoped Access and Centralized AUTHZ (T4B)
Convener: Eve Maler, Maciej Machulak
Notes-taker(s): Eve Maler
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
. We shared and discussed the User-Managed Access (UMA) draft solution for loosely coupling an OAuth authorization server and resource server to solve for externalized authorization and interoperable scoped access.
- A web protocol that lets you control authorization of data sharing and service access made on your behalf
- A Work Group of the Kantara Initiative that is free for anyone to join and contribute to
- A set of draft specifications that is free for anyone to implement
- Undergoing multiple implementation efforts
- Being contributed to the IETF, in pieces (over the next few months)
- Striving to be simple, OAuth-based, identifier-agnostic, RESTful, modular, generative, and developed rapidly
UMA has three phases:
1. Protect a resource (NEW protection model)
- Alice introduces her Calendar host to CopMonkey:“When CopMonkey says whether to let someone in, do what he says” – and then tells CopMonkey her calendar access policies
2. Get authorization (NEW authorization model)
- Chase VISA tries to subscribe to Alice’s travel calendar for fraud protection purposes; its client has to get authorization first, for which it may have to present claims to meet Alice’s policy
3. Access a resource
- Chase now has an access token with the necessary scope to use at the Calendar host: “This means Alice thinks it’s okay”
The presented slides can be found at: http://www.xmlgrrl.com/publications/IIW12-UMA-ScopedAccess-May2011.pdf
More information about UMA can be found at: http://kantarainitiative.org/confluence/display/uma/Home
Questions that came up about UMA (the group is working on publishing a FAQ with the answers given during the session) were:
- How can the host be made responsible for incorrect or malicious behavior? In other words, how does host/AM trust work?
- Have there been any usability studies?
- Why externalize authorization?