[WG-UMA] Notes from UMA ad hoc meeting 2012 03 07

[Eve Maler]

Attending: John, George, Thomas, Eve, Maciej, Jacek, Lukasz, Domenico, Sal

The title of issue 49 (https://github.com/xmlgrrl/UMA-Specifications/issues/49) is phrased in terms of the potential appropriateness of the client_credentials flow for requester access tokens, but our nickname for the issue has become "token upgrade". The latter is an important consequence of choosing a "tenancy model" for requester access tokens (RATs). Currently we haven't specified a practical way for the RAT to be "single tenant" as far as a particular host/authorizing user pair, in the context of a particular AM (represented by a host access token or HAT), is concerned; it would by default represent multiple HATs.

To be clear, the RAT is for accessing an UMA-protected resource (and we're discussing how far off the OAuth reservation it needs to be in its construction, issuance, and usage). The HAT is for the host and AM to collaborate in an UMA-specific way in protecting the resource, but it's just a normal OAuth access token that accesses an OAuth-protected API at the AM.

The requester-AM relationship outside of any specific hosts and authorizing users is still a useful thing. Client_credentials could actually suffice for this.

See Lukasz's proposal from two weeks ago: http://is.gd/COFINs A later idea they came up with is that the requester could use a new endpoint we'd make available at the AM, sending its own RAT and the host ID, and getting back a requester permissions token (RPT) that is specific to that host. It wouldn't, however, distinguish between two different authorizing users that use the same host and AM -- the RPT would represent the entire set of permissions that's valid for it at that host, whether for accessing Alice's stuff or Bob's stuff. Would that be okay, privacy-wise? Maybe.

Now, at the same time, in order to distinguish between the requester (app) and requesting party (liable entity), maybe we need to do exactly what SMART currently does, which is to use an authorization code flow for OpenID Connect (to start collecting claims from the requesting party).

Let's use the following entities in our scenario:

* Authorizing users Alice and Bob
* AM CopMonkey (which Alice and Bob both use)
* Host Calendar app (which Alice and Bob both use)
* Requesting parties Roger and Sam
* Requester TripIt (which Roger and Sam both use)


This scenario needs to have at least the following tokens:

# Host access token Alice-CopMonkey-Calendar to represent Alice's instruction for Calendar to outsource protection to CopMonkey
# Host access token Bob-CopMonkey-Calendar to represent Bob's instruction for Calendar to outsource protection to CopMonkey
# Requester access token Roger-TripIt-CopMonkey to let Roger's TripIt account make uniquely authenticated calls to the protected resource (without considering whether access would be successful)
# Requester access token Sam-TripIt-CopMonkey to let Sam's TripIt account make uniquely authenticated calls to the protected resource (without considering whether access would be successful)


See Jacek's new diagram online: http://goo.gl/jXA4O Basically, the client_credentials flow is proving to be insufficient for the needs of #3 and #4. Using an authorization code flow or similar is required.

Is it worth enhancing #3 and #4 to account for Calendar host uniqueness? Or should we invent a new kind of token, as Lukasz had proposed, to do this job? And does it need to account for Alice vs. Bob at Calendar? In other words, do we need this?

_Multi-tenant permission tokens at hosts:_
* Requester permission token Roger-TripIt-CopMonkey-Calendar and
* Requester permission token Sam-TripIt-CopMonkey-Calendar

or this?

_Single-tenant permission tokens at hosts:_
* Requester permission token Roger-TripIt-CopMonkey-Calendar-Alice and
* Requester permission token Roger-TripIt-CopMonkey-Calendar-Bob and
* Requester permission token Sam-TripIt-CopMonkey-Calendar-Alice and
* Requester permission token Sam-TripIt-CopMonkey-Calendar-Bob

George's rationale for not needing the authorizing user distinction in RPTs is that the requesting party's claims are independent of the authorizing side, and it should be possible for the AM to cache claims appropriately if that same requesting party has provided/proven them to that same AM before. Additionally, Eve suspects that we need this rationale: The permissions associated with a host could safely apply to multiple authorizing users, since permissions and HATs together implicitly distinguish the authorizing user in question and you could do things like audit access of "someone's stuff" successfully without complicating the UMA token picture. Do requesters and requesting parties actually care about the details of which authorizing user is involved? We can't think of why. In fact, this helps to protect the privacy of the authorizing user (one of our design principles), since we don't want the requesting side to have to care about extraneous details of the authorizing side.

So this constitutes progress. :-) So how do we account for the "RPT function"? Please send concrete proposals for solutions to the list by tomorrow.

John notes that there are interesting wrinkles related to the actual API at the host. For example, what if there are multiple resource owners (something UMA has sort of "assumed away") or a non-RESTful resource interface such as Twitter and Facebook Graph? Our solution to issue 49 seems like it doesn't inherently make the problem worse, but the problem is still there. Today's APIs didn't account for Alice-to-other sharing, and so their endpoints tend to be "underspecified". Perhaps with the advent of selective sharing with others, this could change. What if George could give John permission to tweet on his behalf? This would currently still look like "impersonation" from the Twitter side, even with UMA. This is perhaps something that APIs will need to grow to accommodate with UMA in the picture.


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl