[WG-UMA] Question about Requested Scope -- RE: Review UMA core spec rev8 until pargr. 2
gffletch at aol.com
Fri May 27 15:48:04 EDT 2011
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
>> core spec rev8 until pargr. 2
>> Comments lnline
>> On 5/26/11 10:58 AM, Thomas Hardjono wrote:
>> [I was going to ask this question to the group at today's UMA call,
>> cannot make it to the call today. So I'm sending it to the list.]
>> I'm re-reading Rev 8 and have stumbled at Section 2.3 (about the
>> registering a Requested-Scope). Maybe I just need more coffee today
>> Here is the situation:
>> - The Host has received a token from the requester, and is
>> that token to the AM for validation.
>> - The AM returns a token-is-valid response, but the Host decides
>> the scope of the token is insufficient. So the Host then sends a
>> Requested-Scope message to the AM.
>> - In response, the AM returns a Requested-Scope Ticket (which is to
>> passed by the Host to the Requester, so that the Requester can use
>> ticket to get a new token from the AM).
>> Here is my question:
>> (a) Why can't the Host decide that a token has insufficient scope
>> *before* forwarding it to the AM for validation? If the Host could
>> decide that a token has insufficient scope (before asking AM for
>> validation), it could skip a sub-step (ie. the asking of AM to do a
>> token-validate) and just go directly to asking the AM for Requested-
>> Scope Ticket.
>> (I think we may have talked about this question before, but cannot
>> remember the answer).
>> The reason right now is that the token itself is not processable by
>> Host. This could change with JWTs and such for the first iteration
>> took the simple approach that the AM is the only party to generate
>> validate tokens. Hence, the Host needs the AM to validate the token
>> return the scopes associated with that token (really user:requester
>> Also, unless things have changes, one of the models that Paul
>> recommended, is to not have the tokens contain the scope themselves,
>> but rather just be a "pointer" to the scopes stored at the AM. This
>> way, as the user negotiates additional claims with the AM in
>> to the requestor, the token itself doesn't need to change. This
>> simplifies requester development which would otherwise have to
>> multiple tokens for each user.
> 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
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).
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
Chief Architect AIM: gffletch
Identity Services Engineering Work: george.fletcher at teamaol.com
AOL Inc. Home: gffletch at aol.com
Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the WG-UMA