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
