User-Managed Access Intro and Update (1B)

Session Topic:User-Managed Access Update (T1B)

Convener: Eve Maler

Notes-taker(s): Judi Clark

Tags for the session - technology discussed/ideas considered:  user-managed access, uma, context, control, choice, respect

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Data price for online services is too high. There’s provisioning data by hand or by value, problems of oversharing, lying.

Another problem: meaningless consent to unfavorable terms, messy and painful management, more oversharing. Enables you to manage sharing (host: biographical, reputation including credit scores, location, etc.; other authorized users: share selectively, protect; other requesters) and protect access from a single hub (authorization manager).

UMA gives users a true digital footprint dashboard. Unified access control under one access manager. You can test for claims like “over 18″ or reuse policies with multiple hosts. Not good for serious security concerns though. You can keep rebuilding your “sharing circles.” Can’t advertise your content without giving it away, can’t get a global view of all sharing relationships.

UMA lets web apps easily offer “context, control, choice and respect.” You can provide sophisticated protection and sharing of any user content or data that isn’t meant to be public, can outsource the entire job to third party AMs, can ensure that protection of sensitive resources is stronger than the “Private URL” trick, build trust more readily with users who are “privacy fundamentalists, and can integrate these features using lightweight OAuth, JSON, HTTP, REST paradigms and a freely implementable protocol.


 * Glossary item: Access Control Lists (ACLs)

Demo of UMA in action with the SMART system. SMART: Student-Managed Access to Online Resources, a project at School of Computing Science, Newcastle University. They’yre planning to open-source its “UMA/j” implementation and contribute to Apache Amber. smartam.net and gallerifyme

UMA’s history with OAuth: they’ve kept up with emerging tech. UMA pliers are really just enhanced OAuth players. Think of Authorization Manager as “authz server,” think HOST as “resource server, and Authorizing User and “resource owner.” Much overlap between authz server and resource server. They standardized scope enough to make this interoperable.

UMA has 3 phases: 1. protect a resource, 2) get authorization, and 3) access a resource. The process depends on the authorizing user being present, even if as shared agent or power of attorney.

Phase 1: Alice introduces host and AM using OAugh (possibly dynamic registration). The host registers sets of resources to be protected and available scopes at AM host resource set registration endpoints. Alice ensures that AM knows her policies for sharing an item. (She can set policies out of band.) Scope URIs resolve to scope descriptions (can live anywhere). Host registers resource sets and maps to available scopes using RESTful API.


 * Glossary item: Scope = like the object and potential verbs. What’s possible to do with APIs and what happens in the access, permissions.

Between phases 1 and 2: an intermission. Requesting party learns about a resource (discovery, email, etc.), and knows how to use the API and scopes at the host (somehow).

Phase 2: Get Authorization. Requester attems to get resource but… token from AM requester token endpoint, permission for scope from AM authorization endpoint, likely claims to win permission. Host uses AM token status endpoint to check each attempt by requester, then Host uses AM permission registration endpoint to register the sought-after scope. This flow is a back-and-forth process for requesting access to something.

Language between requesting party and requester is really important. There’s a fair amount of redirection to facilitate the flow of tokens and claims.

Edge case: Alice to Alice sharing! (Sharing with herself.) She only needs to list herself in the policy.

Promises: can’t be made by software, must be made in person (self-asserted). UMA doesn’t discriminate against claims.

Next steps: they’ve submitted 2nd Internet Draft. More info at later session.

Notes source: http://digitalidcoach.com/2011/10/iiw-xiii-user-managed-access-update/