It's not exactly vanilla OAuth, because that assumes that the RqP can get "plain" OAuth tokens at the RO's AS. This is the erroneous assumption that led to the creation of the AAT, something that you can't rely on in a wide ecosystem. How is the RqP supposed to log in in that case? Much more discussion here:

https://github.com/KantaraInitiative/wg-uma/issues/154

Unless of course you're saying that it's either:

a) a client-credentials token, in which case the client needs to be configured to be allowed to get this kind of token with no user interaction, and no scopes/rights. Keep in mind that you will generally want to allow dynamically registered clients to do this, and you've got a potentially large problem. This is going to be problematic for a lot of OAuth implementations, including our own, due to the complexity of allowing this one case but not leaving the front door open.

b) a special UMA-flow token that hasn't been defined yet, analogous to the ticket flow but with no ticket.

 -- Justin

On 6/27/2016 4:25 AM, James Phillpotts wrote:

Yep, exactly - the token isn't bound to any particular resource set - it's a vanilla OAuth2 token.

J.

On 23 June 2016 at 22:50, Eve Maler <eve@xmlgrrl.com> wrote:

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