It looks like this is a client-to-AS-first flow, where the client gets a sort of incomplete token (that is, not yet bound to a particular resource of Alice's), and it leverages this token subsequently at the RS rather than getting a ticket and doing a subsequent dance with the AS. Is that right?...

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Jun 23, 2016 at 2:10 PM, Justin Richer <jricher@mit.edu> wrote:

How and when does Bob’s token get associated with Alice’s resource sets?

 — Justin

On Jun 23, 2016, at 7:04 AM, James Phillpotts <james.phillpotts@forgerock.com> wrote:

Hi all,

I'd like to formally propose support for a token-first, reduced-ticket use flow for UMA-next. The scenario this addresses is when the RS publicly publishes the scopes that it uses for resources (as many OAuth2 RSs do currently), and the Client would like to get a single token for this up-front, before it accesses anything at the RS specifically owned by Alice.

Here is a brief description of how I see this working:

• For the simple case, let's say that Client service is a tightly coupled client to services from one RS (could be multiple, not necessary for this description). Let's say the RS is a photo sharing site, and the Client is a photo printing site
• Bob signs up to Printing (client) service
• Client uses AS for sign in
• Because the Client knows that the user will be printing photos, it requests scope photos-view-hires in its token
• Client has obtained access token that includes the requested scope
• Client accesses Alice's photo resource, presenting Bob's bearer token
• RS uses the protection API to register an attempted access to a Resource Set, but includes the presented token in the request
• The AS evaluates the policy for the Resource Set using the details from the token, and responds:
• If the policy is satisfied, (a) a ticket is not generated, and the AS returns a success response
• If the policy is not satisfied, the AS can choose whether (b) to return a ticket, in which case the UMA flow continues as usual, or (c) return a forbidden response with optional message for Bob
• The RS then returns either (a) the resource, (b) returns a WWW-Authenticate response, as per usual flow, or (c) returns a forbidden response with the message from the AS, if supplied.

If it would help, I'm happy to produce a sequence diagram for the above.

Cheers

James

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma