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