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.

UMA is:
 * 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?