[WG-UMA] UMA core: be more explicit about PAT

Eve Maler eve at xmlgrrl.com
Wed Oct 8 19:44:44 CDT 2014


Hi Zhanna,

Indeed the PAT is just a plain vanilla OAuth token with a particular scope. Section 1.3.1 says: "The authorization server MUST present a TLS- and OAuth-protected, HTTP-based protection API for use by resource servers." and "An entity seeking protection API access MUST have the scope "http://docs.kantarainitiative.org/uma/scopes/prot.json". (This URI resolves to a JSON-encoded scope description, as defined in [OAuth-resource-reg]. The description is non-normative for UMA purposes.) An access token with at least this scope is called a protection API token (PAT) and an entity with this scope is definitionally a resource server." The comment about binding is just meant to be more an observation than anything, since OAuth tokens do this kind of binding anyway. We stayed away from showing normal OAuth flows since they are literally the "same as usual".

What do you suggest for making this clearer?

This actually relates to Marcelo's suggestion about backing off of the "MUST" around the scope statement I quote above, since -- if I understand correctly -- he's suggesting that someone with an existing OAuth-protected API could subsume UMA protection into an existing scope simply by declaring it to be the case in their developer documentation and any machine-readable versions thereof. (And it would apply with exactly the same logic to AATs too.)

What do people think of this idea? Since this part of UMA is strictly in OAuth-land, I'm inclined to agree that MUSTs arguably go a bit far. Scope semantics in OAuth frequently live outside of machines. E.g., I recently charted the interrelationships of the OAuth scopes for the Salesforce.com APIs for a presentation, and there's a *lot* of complex ones, to wit (I may have gotten some details wrong...):

full
- id
- api
  - id
  - chatter_api
    - id
- openid
  - id
- web
  - id
  - visualforce
    - id
- visualforce
refresh_token
custom_permissions

If someone wants to just "declare" that their scope includes "UMA protection" or "UMA authorization", why not?

(To be devil's advocate, OpenID Connect defines an API and also defines standard scopes that go with it: profile, email, address, phone.)

	Eve

On 8 Oct 2014, at 1:19 PM, Zhanna Tsitkov <tsitkova at MIT.EDU> wrote:

> Hi,
> I suggest to clarify a little bit more the text related to PAT (Section 1,3,1.)  to the benefit of UMA implementors.  The following would be useful explicitly stated bits of information:
> 
> 1. Is PAT a plain OAuth access token or not? 
> 2. "A PAT binds a resource owner, a resource server the owner uses for resource management, and an authorization server the owner uses for protection of resources at this resource server."  Should the PAT token (explicitly) carry additional fields for the keeping track of the 3-way binding (relationship among the RO, the RS and the AS).
> 3. An example of PAT issuance would be useful too.
> 
> Thanks,
> Zhanna

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



More information about the WG-UMA mailing list