UMA 201 Q and A

From IIW

Issue/Topic: UMA 201

Session: Wednesday 2D

Conference: IIW-11 November 2-4, Mountain View, Complete Notes Page

Convener: Eve Maler

Notes-taker(s): Maciej


Discussion notes:

Thanks to Maciej for capturing these! Here are some relevant links that could usefully be added:

Draft minutes of UMA group meeting held two days ago:

Summary of UMA specs and the specs they reference:

Info on the Newcastle University SMART project:

The SMART implementation of OAuth, called "leeloo":

UMA group wiki:

UMA Q&A Session

Q) UMA - what is the current state of the protocol?

UMA is OAuth-based. Initially OAuth 1.0a, now OAuth 2.0. UMA is now at the point of reaching UMA 1.0 protocol. Newcastle University (SMART Project) has an implementation of the OAuth protocol and the UMA protocol. OAuth constitutes roughly around 50% of the entire UMA implementation.

OAuth terminology is different from UMA terminology.

OAuth: resource owner, authz server, resource server, client

UMA: authz user, authz manager, host, requester (+requesting party)

Q) UMA Interaction Perspective

The user would start with the resource - when a user would like to share a resource then would go to the resource, click on Share Resource and start associating a policy with that. At the AM, the user would have the option to see all registered applications, all registered resources, all the people that have access to some resources.

Q) How to understand the identifiers of requesting parties

UMA allows different identifiers to be used for defining requesting parties. For example, claims could be used to say “I’ll share that resource with somebody who can prove to be”. Another example is where a user would define a policy that says “I’ll share this resource if you say “Hi” to me or if you become my friend on FB”. Group management could be integrated with an authorization manager. (see portable contacts).

Q) Resource/Scope Registration

At the host, the person’s job is to say that a resource should be protected/shared. At the AM, the user’s job is to say how this resource should be protected/shared (by defining a policy for a resource)..

Q) AM <-> Host relationships

Basically, there is a one-to-many relationship - where multiple hosts would trust a single authorization manager (preferred and chosen by the authorizing user). The Host would ask the AM for the scopes/permissions for which a particular access token received from a requester is valid.

Q) Enterprise Use Cases for UMA

UMA 1.0 is focused on consumer proposition. We will see if there is a interest from the enterprises (e.g. including UMA’s Authorization Manager within enteprise infrastructures). This would allow enterprises to have selective sharing.

Q) Integration for existing systems

Necessity to have standard and RESTful (well-known) APIs - because we cannot assume that parties of the UMA protocol will meet statically or will be introduced statically - there is a lot of dynamism and there is a necessity to allow easy integration between parties of the protocol. Standardisation of APIs is important.

Q) UMA Topology

In the basic setting, a user would have a single AM and a bunch of hosts and a bunch of requesters. This AM would be used for all these nodes. In more advanced setting, for example within the enteprise, the employeer could ask for having an additional AM for the hosts that a user uses.

Q) Would that be possible to chain AMs together?

Yes. For example, the AM could provide an AM,Host and Requester interfaces. And other AMs could subscribe to the Requester interface of another AM. If you have a lot of ACLs then it might be reallly viable to have these stored and evaluated in multiples AMs and not in a single AM.

Q) How does UMA fit into the current model on the Web?

UMA can be introduced to the current model incrementally. Resources stored at hosts can be private, public, or managed by UMA. AM would be a service and the Host may want to to provide an additional interface to actually use the AM’s functionality for this “managed by UMA” part. Examples: every OAuth server, exposing data on the Web (e.b. Facebook Social Graph). The host needs to be able to support local access management while allowing selected resources to be shared using UMA..