Eve, to somewhat fortify this use case, we did exactly the same thing with some of our IoT work (that I spoke about at CIS), however, in our case, we never verify the JWT containing grants other than the signature, to deal with the offline scenarios some IoT systems may face. =peterd Peter Davis: Neustar, Inc. Distinguished Engineer, Director, Identity Architect 46000 Center Oak Plaza Sterling, VA 20166 [T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] https://www.neustar.biz/

On Jun 23, 2016, at 5:50 PM, Eve Maler 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?...

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 mailto: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 tel:%2B1%20425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Jun 23, 2016 at 2:10 PM, Justin Richer mailto: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 mailto: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 o 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: o If the policy is satisfied, (a) a ticket is not generated, and the AS returns a success response o 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 mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

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

The RPT is and always has been an access token. We’re just calling a spade a spade, not really replacing anything with anything else. It’s still not a “plain” OAuth access token in the sense that you don’t do “plain” OAuth to get it, and it’s going to be associated with a resource set and associated rights, but it’s still an access token. The question from my email below remains, however: how do you propose the client get the token in the first place? If it’s an OAuth grant, which grant? Does it involve the user? Is it tied to any set of rights? If it’s not an OAuth grant, what’s the extension look like? — Justin

On Jun 27, 2016, at 10:10 AM, James Phillpotts wrote:

My understanding of the discussions from the past few weeks was that we are replacing the RPT with an OAuth2 access token, so that AS will have to be able to issue access tokens - have I misunderstood?

J.

On 27 June 2016 at 13:09, Justin Richer mailto:jricher@mit.edu> wrote: 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 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 mailto: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 tel:%2B1%20425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Jun 23, 2016 at 2:10 PM, Justin Richer < mailto:jricher@mit.edujricher@mit.edu mailto: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 < mailto:james.phillpotts@forgerock.comjames.phillpotts@forgerock.com mailto: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 mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

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

So your statement below makes the assumption that the RqP can get an OAuth token by delegating rights at the AS. Please see the thread I linked — that is not an assumption that I think we should be making, and it’s proven problematic to implement and deploy in a wide ecosystem use case. In other words, I think that for many use cases this is a non-starter for an UMA system. If what you’re describing is in fact “how to just go do OAuth instead of UMA at an UMA protected resource”, then let’s start there and call it that. — Justin

On Jun 27, 2016, at 12:14 PM, James Phillpotts wrote:

Yes, the token is the user's and could be acquired by any means the user can acquire one (password, code or implicit grants, for example). It is literally just an OAuth token, and as such is tied to a set of scopes, and internally may be tied to one or more claims associated with the OAuth RO's (UMA RqP's) identity.

Yes, the RPT has always been a form of access token, but it was not previously an OAuth access token - you didn't get it using any OAuth grant flow, nor even from an OAuth endpoint. I'm assuming (hoping) that the changes being proposed use completely "plain" OAuth to acquire the token, just with an extra parameter for the permission ticket? As such, the AS will have to be a conformant OAuth AS.

As with OAuth, where not all flows are required to be supported, this could be an optional flow in UMA.

On 27 June 2016 at 15:43, Justin Richer mailto:jricher@mit.edu> wrote: The RPT is and always has been an access token. We’re just calling a spade a spade, not really replacing anything with anything else. It’s still not a “plain” OAuth access token in the sense that you don’t do “plain” OAuth to get it, and it’s going to be associated with a resource set and associated rights, but it’s still an access token.

The question from my email below remains, however: how do you propose the client get the token in the first place? If it’s an OAuth grant, which grant? Does it involve the user? Is it tied to any set of rights?

If it’s not an OAuth grant, what’s the extension look like?

— Justin

...

On Jun 27, 2016, at 10:10 AM, James Phillpotts mailto:james.phillpotts@forgerock.com> wrote:

My understanding of the discussions from the past few weeks was that we are replacing the RPT with an OAuth2 access token, so that AS will have to be able to issue access tokens - have I misunderstood?

J.

On 27 June 2016 at 13:09, Justin Richer mailto:jricher@mit.edu> wrote: 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 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 mailto: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 tel:%2B1%20425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Jun 23, 2016 at 2:10 PM, Justin Richer < mailto:jricher@mit.edujricher@mit.edu mailto: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 < mailto:james.phillpotts@forgerock.comjames.phillpotts@forgerock.com mailto: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 mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

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