[WG-UMA] Which additional UMA token profiles are most needed?

Eve Maler eve at xmlgrrl.com
Sun Jul 15 21:13:33 EDT 2012


Following on our discussion of this topic in the last call, I had an interesting meeting with the folks who are working on the RHEx project (http://wiki.siframework.org/RHEx+Quick+Start -- "Powering Secure, Web-Based Health Data Exchange"). It seems they are not focused on UMA-related use cases at this point, but they're interested to keep that door open for the future.

As part of that conversation, I highlight a key way in which UMA is extensible to accommodate a number of different use cases that have the host and AM closer together or farther apart (currently these roles are colocated in RHEx, as they are for a number of folks). The following whiteboard drawing resulted; it shows our current "UMA bearer token profile" choice (the small oval in the middle) and the same alternative options I'd listed in the email below.

Interestingly, it seems that both of the "edge" approaches are viable when you know the AM and host have an inherently tight trust relationship (so that, for example, you don't have to worry so much about the privacy implications we discussed on the call). Only in the case where they're run by different operators (a la Street Identity with its IdP and APs) does the middle option start to look most viable.

FWIW,

	Eve


On 1 Jul 2012, at 11:31 AM, Eve Maler wrote:

> This appeared on the agenda for our call last Thursday, but we didn't get to it. As noted there, it's related to issues #14, #24, #50, and #51.
> 
> Some level-setting: Our requester permission token or RPT is an UMA-specific token, unlike the PAT and AAT which are just vanilla OAuth tokens that get generated and used in various parts of our flows. We've defined a single UMA token profile so far, which we've called "bearer". But actually, this profile wraps two dimensions together that could theoretically be separated:
> 
> - The assertions associated with the token are structured in the form of "permissions" coming from the AM (or alternatively a "token is invalid" indicator).
> 
> - These assertions don't travel on the wire; instead they're represented by an "artifact" that the host must dereference with the AM at run-time through the token status endpoint.
> 
> The universe of possible UMA token profiles could reflect a much more fleshed-out grid than this. For example:
> 
> 1. Assertions: Permissions (gives the host some responsibility/authority for policy decisions)
>   a. Wire: Artifact
>   b. Wire: Assertions themselves
> 2. Assertions: Authorization decision (permit/deny a la XACML; gives the AM full responsibility/authority for policy decisions)
>   a. Wire: Artifact
>   b. Wire: Assertions themselves
> 3. Assertions: Identity claims (gives the host all responsibility/authority for policy decisions; AM just gathers claims per policy)
>   a. Wire: Artifact
>   b. Wire: Assertions themselves
> 
> We have only profiled 1a so far. I get the idea that if we were to prioritize interesting token profiles, 3a would come pretty high on the list because this is likely what today's proprietary AS/RS communications are likely already doing. And 2a/b could obviously be interesting in light of the JSON-based XACML topic we just discussed. What do others think? Do you agree with these dimensions? What patterns do you have a requirement for? What is this analysis missing entirely? (E.g. where does bearer vs. holder of key fit in?)
> 
> BTW, see this section of the OAuth thread model doc for its explanation of the OAuth token universe:
> 
> http://tools.ietf.org/id/draft-ietf-oauth-v2-threatmodel-06.html#rfc.section.3.1
> 
> 	Eve
> 
> 
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
> 
> 
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20120715/7f75ad0d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_0486_2.jpg
Type: image/jpeg
Size: 73896 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-uma/attachments/20120715/7f75ad0d/attachment-0001.jpg 


More information about the WG-UMA mailing list