[WG-UMA] Question about Requested Scope -- RE: Review UMA core spec rev8 until pargr. 2

George Fletcher gffletch at aol.com
Tue May 31 09:15:18 EDT 2011


I'm unclear about the use case regarding the per-host token approach and 
it's scaling concerns. Do you have more details?

The one issue that we've raised in the past, is that many deployments do 
not want the overhead of having to validate tokens with the AM on every 
request. Depending on the number of requests, this can turn into quite a 
load and a performance issue (from a latency perspective). Even today, 
many of the large providers of multiple services, do not use a 
centralized token validation model, but rather a "distributed" one where 
tokens are validated on the host (resource owner).

I would suggest that there are two topics being discussed in this thread.

1. Validation of tokens locally by the host vs a host<->AM token 
validation API call

2. Owner of scope definitions. I may have misunderstood, but I think 
Thomas is suggesting that the AM and user should be the owner of scope 
definitions.

For #1, there are trade offs between simplicity and distributed/internet 
scale. Basically, if the host is going to validate the token, the token 
must contain all the information (in some form) that the host would 
receive back from the AM in a token validation call.

For #2, I'm concerned that the user:AM pair might define scopes that the 
host could not enforce. It seems to me that the host needs to own the 
definition of scopes (what the allowed scopes/actions are) and the 
user:AM pair get to determine the policies around how those scopes are 
employed.

Thanks,
George

On 5/29/11 1:08 PM, Eve Maler wrote:
> George, your description of UMA's choices on host-owned scopes seems 
> right to me.
>
> Regarding per-host vs. per-resource tokens, I recall a conversation 
> with Maciej M. at IIW where he mentioned someone had commented on 
> UMA's direction, saying that the per-host token approach (with 
> upgrades and downgrades to a single token) wouldn't scale for them. 
> Would this be due to an eventual move to "meaningful" JWT tokens? Your 
> comment below suggests this. I'd love to understand this reasoning better.
>
> (Can't wait to see notes from this week's meeting -- sorry I had to 
> miss it!)
>
> Eve
>
> On 27 May 2011, at 12:48 PM, George Fletcher wrote:
>
>> Comments inline...
>>
>> On 5/27/11 1:45 PM, Thomas Hardjono wrote:
>>>> From: George Fletcher [mailto:gffletch at aol.com]
>>>> Sent: Thursday, May 26, 2011 11:45 AM
>>>> To: Thomas Hardjono
>>>> Cc:wg-uma at kantarainitiative.org
>>>> Subject: Re: [WG-UMA] Question about Requested Scope -- RE: Review
>>> Thanks George.
>>>
>>> Since the User is the entity deciding on policies for accessing
>>> her/his resources at the Host, would it be possible for the AM to
>>> decide about scopes (instead of the Host), so that the AM would be
>>> generating correctly-scoped tokens every time. This would seem to be
>>> more in-line with Paul's suggestion of using a "pointer" to the scopes
>>> held by the AM.
>>>
>>> In this approach, the User would fine-tune policies and scopes at the
>>> AM.  The Host would "fetch" these scopes from the AM and attempt to
>>> fit them to the resources at the Host.  For any mismatches or
>>> conflicts, the Host would report back to the AM/User (perhaps in
>>> real-time so that the User can see and adjust). Perhaps this
>>> Host-AM/User dialog could be part of the Dynamic Registration
>>> protocol.
>> As I remember, the perspective has been that the host is the only one 
>> who can truly be authoritative about the scopes for any given 
>> resource. The thinking being that scopes are specific to a particular 
>> service and hence not generic or manageable by the AM. So the host 
>> registers the allowed scopes for a given resource set with the AM and 
>> then the user can chose among the specified set of scopes. That way, 
>> whatever the user chooses is guaranteed to be viable.
>>
>> I'm probably missing something, but it seems like if the user and AM 
>> are choosing the scopes, it's very possible a host will get a scope 
>> that it doesn't understand. I'm not sure how that can be resolved at 
>> runtime.
>>
>> As for the AM generating tokens based on scope, that's possible but 
>> it requires the requesting service to manage multiple tokens per 
>> user:am:host tuple. I believe the goal is to reduce this to one token 
>> per tuple if possible.
>>
>> There has been some discussion and agreement that if UMA moves from 
>> AM generated opaque tokens (which require the host<->AM validation 
>> step) to JWTs that are processable by the Host, then tokens will need 
>> to contain scopes and hence the requester will have to mange tokens 
>> on a per protected resource URL instead of just per Host. I still 
>> believe it's best for the Host to manage the scopes because they are 
>> "unique" in some respects to the service provided by the host (e.g. a 
>> music service will not likely have a "print" scope while a photo 
>> service likely will).
>>
>> Thanks,
>> George
>>> Thanks.
>>>
>>> /thomas/
>>>
>
>
> 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/20110531/9f707963/attachment.html 


More information about the WG-UMA mailing list