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