UMA Workshop at European Identity Conference
UMA is
- web protocol which lets you control authorization of data sharing and service access made on your behalf
- A WG of Kantara
- set of draft specifications
- there are some implementation efforts
- will be contributed to IETF
- Striving to be simple, OAuth based, identifier agnostic, RESTful, modular, generative and developed rapidly.
Entities in the UMA system
- Authorizing User (web user who configures an Authorization Manager)
- Authorization Manager (carries out an authorization user’s policies giverning access)
- Host (hold some protected resource)
- Requester (an entity who wants to get access to the host)
- Requesting Party (not directly part of the protocol but necessary)
Example:
- Authorizing User = Alice Adams
- Host = TravelIt.com (her travel agency)
- Requester = Schedewl (some sort of calendar)
- Requesting Party = Bob, who wants to have access to her calendar to know when to get her from the airport
- Airplanr = another requesting party like Dopplr
Now the requesting parties could get access via OAuth but we want a central point: The Authorization Manager (usually called copmonkey)
Many efforts
There are many efforts going on worldwirde in this space:
- VRM
- Digital Identity Management
- Online Social Networking
Concepts coming from these efforts:
- Digital identity Management: Policy Decision making, Privacy, Informational Self-Determination, User Centricity
- Online Social Networking: Data Portability, The “Open Stack”, the “Connect” phenomenon
- VRM: Volunteered Personal Information, Personal Datastores
Digital Shadow Cruft: That’s what you don’t have permission data sharing. Unwarranted effects etc. Concepts from this: Intentional vs. behavorial data, digital footprint dashboard
Question from the audience: What about delegation? E.g. granting access from Alice to Bob is not the problem but Alice granting it to Charlie and Charlie to Bob.
Provisioning data “by hand and by value” is broken
Problem: Annoying and data is getting stale over time. This also means that all those websites which got data out of you will lose in value over time.
We also have a problem with oversharing information. This also means people will lie more which degrades the quality of the information.
You also have the problem that you sort of have to agree to the terms. The power balance is out of balance.
Sometimes you also have some ACL editor on e.g. flickr or Google Calendar but this is sort of siloed.
Comparing models
- Direct input
- Classic federated Identity Model (Identity Provider, Consomer/Relying Party, Service Provider).
- OAuth-style model including FB Connect and it’s successor (client, server. Store is on the server and you can authorize elements there). In 2.0 you also have an authz server additionally. authz server and resource server need to be in the same security domain though, they are more tightly coupled.
- UMA model (requester, host, authorization manager). The latter is similar to OAuth2.0. It doesn’t necessarily need to be in the same security domain though as it’s the case with OAuth 2.0
- Classic access management model: User is not in the center, requester, PEP, PDP/PAP/PIP
Design Principles and requirements
Original DPs: simple OAuth; ID-agnostic; RESTful, modular, generative (something this is purpose built for a clear purpose), fast
Emergent DPs: Cryptography, Privacy, Compelxity, Authentication, User Experience
Original Reqs: Access Relationship Service, userdriven policies and terms, user management of relationships, auditing, direct access (requesters should go to hosts directly without bothering the user. You might also give your consent async not realtime consent), multiple hosts (you shouldn’t need to collect all your information in one place)
Emergent reqs: host/AM separation, resource orientation, correlation of authorizing user by multiple hosts, representation-agnostic AM
User Experiences (Imagined and real)
Presentation of SMART = Student Managed Access to Online Resources from Newcastle University.
Students should be allowed to create the CVs and to share them with e.g.companies for recruiting etc. Students only need to provide a link and not copy it everywhere. They can also define some terms and conditions under which these CVs can be accessed.
Some problems in developing have been found already and reported back to the UMA group.
Institutional context: There are large amounts of data stored on a variety of systems. Information sharing is often hard to do. UMA-compliant software should help to ease these problems in information sharing.
Another goal is to see how UMA works in a big institution. They want to report lessons learned back.
Measuring success: Deliverables will be available on the web (use case scenarios, req analysis, developed sofwtare, demo app, best practice docs etc.)
Link to the website: http://research.ncl.ac.uk/smart
AM Example
Eve shows some screenshots of some imagined authorization manager.
You can:
manage hosts, suspend access for now, release the host again, define policies, maybe define a timeframe, define baskets of resources.
Some policies might not be possible to enforce unilaterally (like the access time period), e.g. if somebody is over 18 years old. This means you need to have some back and forth with the requester.
They also imagined some statistics, e.g. your privacy exposure.
Baskets: Put some resources into a group. Not clear yet if there should be policies for the whole basket which get inherited.
A sampling of scenarios
see scenario document in the wiki for a complete list of accepted and pending one.
Examples:
- Sharing a calendar with vendors
- Packaging resources for e-commerce vendors
- online personal loan request scenario
- Distributed Services
- Managing information in which employers and employees both have a stake
etc.
The protocol
First: Explanation of OAuth1.0, then OAuth 2.0
In the beginning UMA was based on OAuth1.0, then moved to OAuth WRAP and now it’s in the process of being converted to use OAuth2.0
Comparing OAuth2.0 and UMA
Resource Owner => Authorizing User
Resource server => Host
Authorization server => Authorization Manager
Client => Requester
The two servers meet out of band => Host and AM can meet dynamically (using OAuth)
Authz is binary: you get a token or you don’t => Authz can depend on requester “claims”
Token validation process is unspecified => Host can ask AM to validate token at runtime
Highlevel picture of a UMA flow
How do you tell the host which access tokens to trust? Answer: You have to tell it the AM to work with.
- User introduces Host to AM (provision the AM location). The host will then start an embedded OAuth flow acting as a client. User authorizes Host to trust AM (host gets access token from AM). Eventually the user can define policies on the AM for this host.
- The user provisions a resource location to the requester (hand the URL, broadcast the URL, discover it somehow). The requester attempts access to the host. It learns that it’s protected. It then asks the AM for an access token, supplying claims as needed. In OAuth this is either allowed or denied, in UMA you can ask it to meet claims additionally.
- Requester accesses resource on host with that access token and the host can optionally validate a token with the AM.
Some current protocol issues:
- Spec modularity (claim and core protocol are now separate specs, more are thinkable)
- Flows for getting a token: user delegation? autonomous client? others?
- Token validation models
- Claims about requesting-party identity
- inter-entity info discovery
- Resource basket optimizations
Policies, Claims and Agreements
Unilateral: Allow access for a week
Claims-requiring:
- “Allow access to anyone who agrees to my licensing terms” (promissory statement)
- “Allow access to someone who can prove themselves to be bob@gmail.com” (affirmative statement)
- “Allow access to anyone who says they are 18 years or older” (affirmative statement)
The question: how binding is it to click “I agree” in terms of legal matters? Working together with lawyers to work out if that works. How enforcable are these requests?
Question: US attorney or international thinking ones?
There is one US and one Canadian one right now. They also look into international matters but there is still lots to solve (as nothing really is solved anyway right now, e.g. how binding are the Facebook TOS in Germany?)
Claims are about requesting parties not requesters.
e.g. Alice wants AIRPLANR (a company) to agree to her terms
Claim 2.0 document: http://kantarainitiative.org/confluence/display/uma/Claims+2.0
(not finished yet)
Signed claims are another option but self-asserted ones might be sufficient in many cases. With signed claims probably magic signature from the Salmon project.
