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

Thomas Hardjono identity at hardjono.net
Fri May 27 13:45:18 EDT 2011

> 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
> pair).
> 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



More information about the WG-UMA mailing list