I'm not sure where this comes into the picture, but I'm reminded of a conversation I had maybe 3 IIWs ago with some folks about the need to keep some policy-handling at the "edge" (in this case, in a SaaS application that had a lot of customizability options). We discussed how it could have been handy to have an RPT profile that contained both permissions and and an SSO token or other identity attributes or role info, so that the RS could do whatever additional fine-grained authorization was necessary beyond the level of scopes. Relevant? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Jun 23, 2016 at 2:12 PM, Justin Richer wrote:

ID tokens and access tokens are different creatures. ID Tokens are assertions that describe an authentication event. They’re meant to be consumed and, generally, tossed. The client doesn’t store them to use them with other services. The access token defines an access delegation and is consumed by the resource, not the client. The client holds on to the access token so that it can use it with the resource over time, until the token isn’t good anymore.

If instead what you’re saying is to declare a JWT-formatted access token, that’s something else entirely — but don’t call it an ID token. JWTs have their own issues and tradeoffs when used as access tokens.

— Justin

...

On Jun 23, 2016, at 7:18 AM, James Phillpotts < james.phillpotts@forgerock.com> wrote:

Hi again,

Another suggestion for consideration in UMA-next is whether we should support ID Tokens as an alternative to OAuth2 access tokens for bearer tokens from the Client to the RS. As the ID Token would be minted by the AS, then it should be able to introspect it just as it would an access token.

This would also have an advantage in the token-first flow I outlined in my other mail, where the Client can use the additional claims part of requesting an ID Token in OpenID Connect to get the AS to eagerly get extra claims for the user, for example at the time of enrolment.

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

I'd say that an ID Token represents an identity that has been verified in some way by the AS - in that sense it is useful to UMA, where we simply want to verify that the request comes from an identity that has been granted permissions to access the resource. However, if your point is that the access token that could have been requested with the ID token is fit for this purpose, I'm happy with that. J. On 23 June 2016 at 22:12, Justin Richer wrote:

ID tokens and access tokens are different creatures. ID Tokens are assertions that describe an authentication event. They’re meant to be consumed and, generally, tossed. The client doesn’t store them to use them with other services. The access token defines an access delegation and is consumed by the resource, not the client. The client holds on to the access token so that it can use it with the resource over time, until the token isn’t good anymore.

If instead what you’re saying is to declare a JWT-formatted access token, that’s something else entirely — but don’t call it an ID token. JWTs have their own issues and tradeoffs when used as access tokens.

— Justin

...

On Jun 23, 2016, at 7:18 AM, James Phillpotts < james.phillpotts@forgerock.com> wrote:

Hi again,

Another suggestion for consideration in UMA-next is whether we should support ID Tokens as an alternative to OAuth2 access tokens for bearer tokens from the Client to the RS. As the ID Token would be minted by the AS, then it should be able to introspect it just as it would an access token.

This would also have an advantage in the token-first flow I outlined in my other mail, where the Client can use the additional claims part of requesting an ID Token in OpenID Connect to get the AS to eagerly get extra claims for the user, for example at the time of enrolment.

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

The RS wouldn't know it's been given an ID Token though - it would just have a bearer token with some long string that it is then going to send on to the AS. J. On 27 June 2016 at 17:36, George Fletcher wrote:

Another issue with id_tokens that affects this kind of a use case is that id_tokens are currently audience bound to the client, so if you send it to the RS, it should be rejected because the RS is not the audience of the id_token. It's possible to get around the audience issues using a token exchange mechanism, but then the resulting token is not an id_token but just another JWT functioning as an access token (per Justin's last paragraph).

Thanks, George

On 6/23/16 5:12 PM, Justin Richer wrote:

ID tokens and access tokens are different creatures. ID Tokens are assertions that describe an authentication event. They’re meant to be consumed and, generally, tossed. The client doesn’t store them to use them with other services. The access token defines an access delegation and is consumed by the resource, not the client. The client holds on to the access token so that it can use it with the resource over time, until the token isn’t good anymore.

If instead what you’re saying is to declare a JWT-formatted access token, that’s something else entirely — but don’t call it an ID token. JWTs have their own issues and tradeoffs when used as access tokens.

— Justin

On Jun 23, 2016, at 7:18 AM, James Phillpotts wrote:

Hi again,

Another suggestion for consideration in UMA-next is whether we should support ID Tokens as an alternative to OAuth2 access tokens for bearer tokens from the Client to the RS. As the ID Token would be minted by the AS, then it should be able to introspect it just as it would an access token.

This would also have an advantage in the token-first flow I outlined in my other mail, where the Client can use the additional claims part of requesting an ID Token in OpenID Connect to get the AS to eagerly get extra claims for the user, for example at the time of enrolment.

Cheers James _______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

I'm assuming (2) - not interested in any tokens from other IdPs. Yes, I'm assuming that in this case the client is using the UMA AS as the OpenID Connect IdP, and wants to add extra claims for up-front token acquisition (as per other thread), which the OpenID Connect extension request parameters are useful for providing. Cheers James On 27 June 2016 at 17:51, George Fletcher wrote:

Yes, but then either (1) the AS is NOT the issuer of the id_token and can't process it because of the audience restrictions or (2) the AS is the issuer of the id_token and this is a very specialized and restricted use case. Also, if the client is doing pure OAuth it won't get an id_token so in this context the client would need to be using the UMA AS as the client's OpenID Connect provider.

Maybe I'm missing something?

Thanks, George

On 6/27/16 12:47 PM, James Phillpotts wrote:

The RS wouldn't know it's been given an ID Token though - it would just have a bearer token with some long string that it is then going to send on to the AS.

J.

On 27 June 2016 at 17:36, George Fletcher wrote:

...

Another issue with id_tokens that affects this kind of a use case is that id_tokens are currently audience bound to the client, so if you send it to the RS, it should be rejected because the RS is not the audience of the id_token. It's possible to get around the audience issues using a token exchange mechanism, but then the resulting token is not an id_token but just another JWT functioning as an access token (per Justin's last paragraph).

Thanks, George

On 6/23/16 5:12 PM, Justin Richer wrote:

ID tokens and access tokens are different creatures. ID Tokens are assertions that describe an authentication event. They’re meant to be consumed and, generally, tossed. The client doesn’t store them to use them with other services. The access token defines an access delegation and is consumed by the resource, not the client. The client holds on to the access token so that it can use it with the resource over time, until the token isn’t good anymore.

If instead what you’re saying is to declare a JWT-formatted access token, that’s something else entirely — but don’t call it an ID token. JWTs have their own issues and tradeoffs when used as access tokens.

— Justin

On Jun 23, 2016, at 7:18 AM, James Phillpotts wrote:

Hi again,

Another suggestion for consideration in UMA-next is whether we should support ID Tokens as an alternative to OAuth2 access tokens for bearer tokens from the Client to the RS. As the ID Token would be minted by the AS, then it should be able to introspect it just as it would an access token.

This would also have an advantage in the token-first flow I outlined in my other mail, where the Client can use the additional claims part of requesting an ID Token in OpenID Connect to get the AS to eagerly get extra claims for the user, for example at the time of enrolment.

Cheers James _______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

-- Distinguished Engineer Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography

+1 to George’s comment. What you’re describing isn’t an OpenID Connect ID Token. — Justin

On Jun 27, 2016, at 1:01 PM, George Fletcher wrote:

Then why use an id_token in this context? Why not just use the access_token which will have the additional scopes bound to it? If the UMA AS is also the OpenID Connect provider, it will know about the claims bound to that user and I don't think they need to be passed in the id_token. This resolves the audience issues with the id_token.

I do feel like this is a different UMA token profile which should be pretty easy to write for your constrained environment. In this profile you could allow for a "permission ticketless token" which is what the returned access_token would be and then define how the AS should process it against a specific identified resource.

Thanks, George

On 6/27/16 12:55 PM, James Phillpotts wrote:

...

I'm assuming (2) - not interested in any tokens from other IdPs. Yes, I'm assuming that in this case the client is using the UMA AS as the OpenID Connect IdP, and wants to add extra claims for up-front token acquisition (as per other thread), which the OpenID Connect extension request parameters are useful for providing.

Cheers James

On 27 June 2016 at 17:51, George Fletcher mailto:george.fletcher@teamaol.com> wrote: Yes, but then either (1) the AS is NOT the issuer of the id_token and can't process it because of the audience restrictions or (2) the AS is the issuer of the id_token and this is a very specialized and restricted use case. Also, if the client is doing pure OAuth it won't get an id_token so in this context the client would need to be using the UMA AS as the client's OpenID Connect provider.

Maybe I'm missing something?

Thanks, George

On 6/27/16 12:47 PM, James Phillpotts wrote:

...

The RS wouldn't know it's been given an ID Token though - it would just have a bearer token with some long string that it is then going to send on to the AS.

J.

On 27 June 2016 at 17:36, George Fletcher < mailto:george.fletcher@teamaol.comgeorge.fletcher@teamaol.com mailto:george.fletcher@teamaol.com> wrote: Another issue with id_tokens that affects this kind of a use case is that id_tokens are currently audience bound to the client, so if you send it to the RS, it should be rejected because the RS is not the audience of the id_token. It's possible to get around the audience issues using a token exchange mechanism, but then the resulting token is not an id_token but just another JWT functioning as an access token (per Justin's last paragraph).

Thanks, George

On 6/23/16 5:12 PM, Justin Richer wrote:

...

ID tokens and access tokens are different creatures. ID Tokens are assertions that describe an authentication event. They’re meant to be consumed and, generally, tossed. The client doesn’t store them to use them with other services. The access token defines an access delegation and is consumed by the resource, not the client. The client holds on to the access token so that it can use it with the resource over time, until the token isn’t good anymore.

If instead what you’re saying is to declare a JWT-formatted access token, that’s something else entirely — but don’t call it an ID token. JWTs have their own issues and tradeoffs when used as access tokens.

— Justin

...

On Jun 23, 2016, at 7:18 AM, James Phillpotts mailto:james.phillpotts@forgerock.com wrote:

Hi again,

Another suggestion for consideration in UMA-next is whether we should support ID Tokens as an alternative to OAuth2 access tokens for bearer tokens from the Client to the RS. As the ID Token would be minted by the AS, then it should be able to introspect it just as it would an access token.

This would also have an advantage in the token-first flow I outlined in my other mail, where the Client can use the additional claims part of requesting an ID Token in OpenID Connect to get the AS to eagerly get extra claims for the user, for example at the time of enrolment.

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

-- Distinguished Engineer Identity Services Engineering Work: george.fletcher@teamaol.com mailto:george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 tel:%2B1-703-462-3494 Twitter: http://twitter.com/gffletch http://twitter.com/gffletch Office: +1-703-265-2544 tel:%2B1-703-265-2544 Photos: http://georgefletcher.photography http://georgefletcher.photography/

-- Distinguished Engineer Identity Services Engineering Work: george.fletcher@teamaol.com mailto:george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography http://georgefletcher.photography/

There are lots of interesting ways to consider passing claims to the AS about the user. One we've talked about in the past is if the client authenticated the RqP with via an OpenID Connect flow, could it pass the id_token it received from the IdP to the UMA AS as a claim. The issue with this is that if we are being strict about audience checking the UMA AS has to reject the passed in id_token. What needs to happen is that the client needs to request from the IdP a token (id_token or otherwise) that is audience restricted to the UMA AS. This is viable from a flow and tech perspective, but if we want this token to be another form of "RPT" then it seems like it should have it's own token profile written to cover the use case. Now in Jame's case, the OpenID Connect provider for the client that authenticates the RqP is the UMA AS. This is a very constrained use case though perfectly viable and maybe commonly deployed. I still think this kind of a flow should have it's own token profile as the token to the RS does not carry the same semantics as the current RPT. The current RPT binds the client, the RS and the AS together and sometimes the RqP as well. If all that's being presented is effectively an id_token, then the semantic of that token is just the RqP. Thanks, George On Tue, Jun 28, 2016 at 11:26 PM Eve Maler wrote:

There could be a reason for an id_token to be passed back around to the same AS/IdP: There are "stateful" models for deriving identity information about the user in front of you, and alternatively "stateless" models where the information shows up with the user. There are pros and cons to each method.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Jun 27, 2016 at 1:03 PM, Justin Richer wrote:

...

+1 to George’s comment. What you’re describing isn’t an OpenID Connect ID Token.

— Justin

On Jun 27, 2016, at 1:01 PM, George Fletcher wrote:

Then why use an id_token in this context? Why not just use the access_token which will have the additional scopes bound to it? If the UMA AS is also the OpenID Connect provider, it will know about the claims bound to that user and I don't think they need to be passed in the id_token. This resolves the audience issues with the id_token.

I do feel like this is a different UMA token profile which should be pretty easy to write for your constrained environment. In this profile you could allow for a "permission ticketless token" which is what the returned access_token would be and then define how the AS should process it against a specific identified resource.

Thanks, George

On 6/27/16 12:55 PM, James Phillpotts wrote:

I'm assuming (2) - not interested in any tokens from other IdPs. Yes, I'm assuming that in this case the client is using the UMA AS as the OpenID Connect IdP, and wants to add extra claims for up-front token acquisition (as per other thread), which the OpenID Connect extension request parameters are useful for providing.

Cheers James

On 27 June 2016 at 17:51, George Fletcher wrote:

...

Yes, but then either (1) the AS is NOT the issuer of the id_token and can't process it because of the audience restrictions or (2) the AS is the issuer of the id_token and this is a very specialized and restricted use case. Also, if the client is doing pure OAuth it won't get an id_token so in this context the client would need to be using the UMA AS as the client's OpenID Connect provider.

Maybe I'm missing something?

Thanks, George

On 6/27/16 12:47 PM, James Phillpotts wrote:

The RS wouldn't know it's been given an ID Token though - it would just have a bearer token with some long string that it is then going to send on to the AS.

J.

On 27 June 2016 at 17:36, George Fletcher < george.fletcher@teamaol.com> wrote:

...

Another issue with id_tokens that affects this kind of a use case is that id_tokens are currently audience bound to the client, so if you send it to the RS, it should be rejected because the RS is not the audience of the id_token. It's possible to get around the audience issues using a token exchange mechanism, but then the resulting token is not an id_token but just another JWT functioning as an access token (per Justin's last paragraph).

Thanks, George

On 6/23/16 5:12 PM, Justin Richer wrote:

ID tokens and access tokens are different creatures. ID Tokens are assertions that describe an authentication event. They’re meant to be consumed and, generally, tossed. The client doesn’t store them to use them with other services. The access token defines an access delegation and is consumed by the resource, not the client. The client holds on to the access token so that it can use it with the resource over time, until the token isn’t good anymore.

If instead what you’re saying is to declare a JWT-formatted access token, that’s something else entirely — but don’t call it an ID token. JWTs have their own issues and tradeoffs when used as access tokens.

— Justin

On Jun 23, 2016, at 7:18 AM, James Phillpotts wrote:

Hi again,

Another suggestion for consideration in UMA-next is whether we should support ID Tokens as an alternative to OAuth2 access tokens for bearer tokens from the Client to the RS. As the ID Token would be minted by the AS, then it should be able to introspect it just as it would an access token.

This would also have an advantage in the token-first flow I outlined in my other mail, where the Client can use the additional claims part of requesting an ID Token in OpenID Connect to get the AS to eagerly get extra claims for the user, for example at the time of enrolment.

Cheers James _______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

-- Distinguished Engineer Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography

-- Distinguished Engineer Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography

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

So, hang on a minute here.

If the IdP is the AS, that means that the IdP is authenticating the RqP … to itself. That makes absolutely no sense, as the RqP would have a “local” account at the IdP/AS anyway and wouldn’t need or use OIDC to carry identity information to itself. So that’s particularly pointless. I don't think this is pointless. Let's say Bob is using a Photo Site (photos.example.com) and the Photo Site uses an OpenID Connect Provider as it's Idp (umaas.example.com). When Bob shows up at photos.example.com and clicks the login button, photos.example.com starts an OpenID Connect flow with umaas.example.com when Bob logs in and at the completion of

Comments inline... On 6/29/16 10:03 AM, Justin Richer wrote: the flow, photos.example.com has an id_token, access_token and possibly a refresh_token. If then photos.example.com were to send the id_token as a bearer token to printme.example.com and printme.example.com is using umaas.example.com as it's UMA AS, then this would all work. Hence my comment about this being a constrained environment. Or maybe a "close eco-system" is a better term.

Now if you’re talking about the AS being an IdP to the Client or the RS, that’s another story. However, those are separate flows entirely. The data carried on each branch of that network is quite different and it would be dangerous to conflate them. You could definitely do the id-token-as-claims bit that George mentions below in this use case, but this is NOT the same as the RqP logging into the AS using OIDC. The client is passing along an incidental artifact of authentication to prove that the RqP was at one point present at the client.

Yes, I was not suggesting that the RqP was logging into the AS using OIDC... sorry for that confusion.

And quite frankly if you’ve got the case where the RqP has an account at the AS and you can go straight to the AS to start the flow … you don’t need UMA. Seriously, take away the claims system (because you don’t need it with a local account) and the permission ticket (which you don’t need if you strip out the AS discovery and claims systems), and you’re not doing UMA anymore. At that point, you’re much better off doing vanilla OAuth.

Not sure I've totally reached this conclusion, though I do agree that it's a very special deployment case and there are probably lots of optimizations that can be applied.

"But wait!”, you may say, “There’s still an RqP who is different from the RO!” To which I say: “So what?”. In any OAuth system, Alice could be given the capability to share her resources with any other identified party. If that party has a local account (is already known well by the AS) and the client doesn’t need to look up the AS at runtime, then there’s nothing that’s preventing you from building this out in a plain OAuth server’s policy engine. OAuth never states or presumes a 1:1 mapping between RO and protected resource, so it’s perfectly reasonable to use some kind of internal mechanism allowing Alice to delegate access to Bob. Bob then become the RO in the OAuth process, even if he’s been seconded the responsibility by Alice he’s playing that role now because the AS knows who Bob is already and knows Bob is allowed access. You don’t need an interoperable protocol to do that, and as we’re seeing in this conversation, the protocol is actually getting in the way.

While from the syntax perspective OAuth2 would work fine, I do think there is a semantic difference. Most OAuth2 Authorization Service don't allow the RO to add policy around access. Not impossible and not out of scope of OAuth2, just not something I've seen often. The part of UMA that makes sense in this use case is the policy engine that allows Alice to say if a token shows up trying to access my resource and that token happens to be Bob, then it's ok.

So I think James’s use case definitely has a point, but it’s already been specified in RFC6749.

— Justin

...

On Jun 29, 2016, at 9:34 AM, George Fletcher mailto:george.fletcher@teamaol.com> wrote:

There are lots of interesting ways to consider passing claims to the AS about the user. One we've talked about in the past is if the client authenticated the RqP with via an OpenID Connect flow, could it pass the id_token it received from the IdP to the UMA AS as a claim. The issue with this is that if we are being strict about audience checking the UMA AS has to reject the passed in id_token. What needs to happen is that the client needs to request from the IdP a token (id_token or otherwise) that is audience restricted to the UMA AS. This is viable from a flow and tech perspective, but if we want this token to be another form of "RPT" then it seems like it should have it's own token profile written to cover the use case.

Now in Jame's case, the OpenID Connect provider for the client that authenticates the RqP is the UMA AS. This is a very constrained use case though perfectly viable and maybe commonly deployed. I still think this kind of a flow should have it's own token profile as the token to the RS does not carry the same semantics as the current RPT. The current RPT binds the client, the RS and the AS together and sometimes the RqP as well. If all that's being presented is effectively an id_token, then the semantic of that token is just the RqP.

Thanks, George

On Tue, Jun 28, 2016 at 11:26 PM Eve Maler mailto:eve@xmlgrrl.com> wrote:

There could be a reason for an id_token to be passed back around to the same AS/IdP: There are "stateful" models for deriving identity information about the user in front of you, and alternatively "stateless" models where the information shows up with the user. There are pros and cons to each method.

*Eve Maler *Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Jun 27, 2016 at 1:03 PM, Justin Richer mailto:jricher@mit.edu> wrote:

+1 to George’s comment. What you’re describing isn’t an OpenID Connect ID Token.

— Justin

...

On Jun 27, 2016, at 1:01 PM, George Fletcher mailto:george.fletcher@teamaol.com> wrote:

Then why use an id_token in this context? Why not just use the access_token which will have the additional scopes bound to it? If the UMA AS is also the OpenID Connect provider, it will know about the claims bound to that user and I don't think they need to be passed in the id_token. This resolves the audience issues with the id_token.

I do feel like this is a different UMA token profile which should be pretty easy to write for your constrained environment. In this profile you could allow for a "permission ticketless token" which is what the returned access_token would be and then define how the AS should process it against a specific identified resource.

Thanks, George

On 6/27/16 12:55 PM, James Phillpotts wrote:

...

I'm assuming (2) - not interested in any tokens from other IdPs. Yes, I'm assuming that in this case the client is using the UMA AS as the OpenID Connect IdP, and wants to add extra claims for up-front token acquisition (as per other thread), which the OpenID Connect extension request parameters are useful for providing.

Cheers James

On 27 June 2016 at 17:51, George Fletcher mailto:george.fletcher@teamaol.com> wrote:

Yes, but then either (1) the AS is NOT the issuer of the id_token and can't process it because of the audience restrictions or (2) the AS is the issuer of the id_token and this is a very specialized and restricted use case. Also, if the client is doing pure OAuth it won't get an id_token so in this context the client would need to be using the UMA AS as the client's OpenID Connect provider.

Maybe I'm missing something?

Thanks, George

On 6/27/16 12:47 PM, James Phillpotts wrote:

...

The RS wouldn't know it's been given an ID Token though - it would just have a bearer token with some long string that it is then going to send on to the AS.

J.

On 27 June 2016 at 17:36, George Fletcher mailto:george.fletcher@teamaol.com> wrote:

Another issue with id_tokens that affects this kind of a use case is that id_tokens are currently audience bound to the client, so if you send it to the RS, it should be rejected because the RS is not the audience of the id_token. It's possible to get around the audience issues using a token exchange mechanism, but then the resulting token is not an id_token but just another JWT functioning as an access token (per Justin's last paragraph).

Thanks, George

On 6/23/16 5:12 PM, Justin Richer wrote:

...

ID tokens and access tokens are different creatures. ID Tokens are assertions that describe an authentication event. They’re meant to be consumed and, generally, tossed. The client doesn’t store them to use them with other services. The access token defines an access delegation and is consumed by the resource, not the client. The client holds on to the access token so that it can use it with the resource over time, until the token isn’t good anymore.

If instead what you’re saying is to declare a JWT-formatted access token, that’s something else entirely — but don’t call it an ID token. JWTs have their own issues and tradeoffs when used as access tokens.

— Justin

> On Jun 23, 2016, at 7:18 AM, James Phillpotts > mailto:james.phillpotts@forgerock.com wrote: > > Hi again, > > Another suggestion for consideration in UMA-next is whether we should support ID Tokens as an alternative to OAuth2 access tokens for bearer tokens from the Client to the RS. As the ID Token would be minted by the AS, then it should be able to introspect it just as it would an access token. > > This would also have an advantage in the token-first flow I outlined in my other mail, where the Client can use the additional claims part of requesting an ID Token in OpenID Connect to get the AS to eagerly get extra claims for the user, for example at the time of enrolment. > > 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

-- Distinguished Engineer Identity Services Engineering Work:george.fletcher@teamaol.com mailto:george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile:+1-703-462-3494 tel:%2B1-703-462-3494 Twitter:http://twitter.com/gffletch Office:+1-703-265-2544 tel:%2B1-703-265-2544 Photos:http://georgefletcher.photography http://georgefletcher.photography/

-- Distinguished Engineer Identity Services Engineering Work:george.fletcher@teamaol.com mailto:george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile:+1-703-462-3494 tel:%2B1-703-462-3494 Twitter:http://twitter.com/gffletch Office:+1-703-265-2544 tel:%2B1-703-265-2544 Photos:http://georgefletcher.photography http://georgefletcher.photography/

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

-- Distinguished Engineer Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography

A couple of points... I thought AS-as-IdP was baked into the scenario being talked about in the thread already (George's "If the UMA AS is also the OpenID Connect provider..."). If it's not, never mind my point about the "stateless pattern" (which is nevertheless a valid pattern, usable in SSO contexts as well as here). But it can be relevant to talk about using UMA in cases where OAuth on its own is possible to use. Classic API management is one scenario (I've now had many conversations with people who complain that it's awkward to separate the enterprise resource owner and its asynchronous authorization policy from whoever is wielding the client); centralizing Alice's management of "SSO-style" consents over time is another. The latter is what is being considered in this OIX UK project http://www.ukauthority.com/UKA-Local-Digital/entry/5958/local-and-central-go... (link down for the moment...), which currently uses OAuth and OIDC, and invented some consent and service loose coupling flows that they probably need not have if they'd taken advantage of UMA. Ian Litton tells me they only didn't because UMA wasn't at V1 yet at the time. :) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Wed, Jun 29, 2016 at 8:25 AM, Justin Richer wrote:

I think the key comment to this thread is this:

The part of UMA that makes sense in this use case is the policy engine that allows Alice to say if a token shows up trying to access my resource and that token happens to be Bob, then it's ok.

Which isn’t UMA as a protocol, it’s UMA as a concept, which I would argue is better implemented in this case using OAuth.

— Justin

On Jun 29, 2016, at 10:33 AM, George Fletcher wrote:

Comments inline...

On 6/29/16 10:03 AM, Justin Richer wrote:

So, hang on a minute here.

If the IdP is the AS, that means that the IdP is authenticating the RqP … to itself. That makes absolutely no sense, as the RqP would have a “local” account at the IdP/AS anyway and wouldn’t need or use OIDC to carry identity information to itself. So that’s particularly pointless.

I don't think this is pointless. Let's say Bob is using a Photo Site ( photos.example.com) and the Photo Site uses an OpenID Connect Provider as it's Idp (umaas.example.com). When Bob shows up at photos.example.com and clicks the login button, photos.example.com starts an OpenID Connect flow with umaas.example.com when Bob logs in and at the completion of the flow, photos.example.com has an id_token, access_token and possibly a refresh_token.

If then photos.example.com were to send the id_token as a bearer token to printme.example.com and printme.example.com is using umaas.example.com as it's UMA AS, then this would all work.

Hence my comment about this being a constrained environment. Or maybe a "close eco-system" is a better term.

Now if you’re talking about the AS being an IdP to the Client or the RS, that’s another story. However, those are separate flows entirely. The data carried on each branch of that network is quite different and it would be dangerous to conflate them. You could definitely do the id-token-as-claims bit that George mentions below in this use case, but this is NOT the same as the RqP logging into the AS using OIDC. The client is passing along an incidental artifact of authentication to prove that the RqP was at one point present at the client.

Yes, I was not suggesting that the RqP was logging into the AS using OIDC... sorry for that confusion.

And quite frankly if you’ve got the case where the RqP has an account at the AS and you can go straight to the AS to start the flow … you don’t need UMA. Seriously, take away the claims system (because you don’t need it with a local account) and the permission ticket (which you don’t need if you strip out the AS discovery and claims systems), and you’re not doing UMA anymore. At that point, you’re much better off doing vanilla OAuth.

Not sure I've totally reached this conclusion, though I do agree that it's a very special deployment case and there are probably lots of optimizations that can be applied.

"But wait!”, you may say, “There’s still an RqP who is different from the RO!” To which I say: “So what?”. In any OAuth system, Alice could be given the capability to share her resources with any other identified party. If that party has a local account (is already known well by the AS) and the client doesn’t need to look up the AS at runtime, then there’s nothing that’s preventing you from building this out in a plain OAuth server’s policy engine. OAuth never states or presumes a 1:1 mapping between RO and protected resource, so it’s perfectly reasonable to use some kind of internal mechanism allowing Alice to delegate access to Bob. Bob then become the RO in the OAuth process, even if he’s been seconded the responsibility by Alice he’s playing that role now because the AS knows who Bob is already and knows Bob is allowed access. You don’t need an interoperable protocol to do that, and as we’re seeing in this conversation, the protocol is actually getting in the way.

While from the syntax perspective OAuth2 would work fine, I do think there is a semantic difference. Most OAuth2 Authorization Service don't allow the RO to add policy around access. Not impossible and not out of scope of OAuth2, just not something I've seen often.

The part of UMA that makes sense in this use case is the policy engine that allows Alice to say if a token shows up trying to access my resource and that token happens to be Bob, then it's ok.

So I think James’s use case definitely has a point, but it’s already been specified in RFC6749.

— Justin

On Jun 29, 2016, at 9:34 AM, George Fletcher wrote:

There are lots of interesting ways to consider passing claims to the AS about the user. One we've talked about in the past is if the client authenticated the RqP with via an OpenID Connect flow, could it pass the id_token it received from the IdP to the UMA AS as a claim. The issue with this is that if we are being strict about audience checking the UMA AS has to reject the passed in id_token. What needs to happen is that the client needs to request from the IdP a token (id_token or otherwise) that is audience restricted to the UMA AS. This is viable from a flow and tech perspective, but if we want this token to be another form of "RPT" then it seems like it should have it's own token profile written to cover the use case.

Now in Jame's case, the OpenID Connect provider for the client that authenticates the RqP is the UMA AS. This is a very constrained use case though perfectly viable and maybe commonly deployed. I still think this kind of a flow should have it's own token profile as the token to the RS does not carry the same semantics as the current RPT. The current RPT binds the client, the RS and the AS together and sometimes the RqP as well. If all that's being presented is effectively an id_token, then the semantic of that token is just the RqP.

Thanks, George

On Tue, Jun 28, 2016 at 11:26 PM Eve Maler wrote:

...

There could be a reason for an id_token to be passed back around to the same AS/IdP: There are "stateful" models for deriving identity information about the user in front of you, and alternatively "stateless" models where the information shows up with the user. There are pros and cons to each method.

*Eve Maler *Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Jun 27, 2016 at 1:03 PM, Justin Richer < jricher@mit.edu> wrote:

...

+1 to George’s comment. What you’re describing isn’t an OpenID Connect ID Token.

— Justin

On Jun 27, 2016, at 1:01 PM, George Fletcher < george.fletcher@teamaol.com> wrote:

Then why use an id_token in this context? Why not just use the access_token which will have the additional scopes bound to it? If the UMA AS is also the OpenID Connect provider, it will know about the claims bound to that user and I don't think they need to be passed in the id_token. This resolves the audience issues with the id_token.

I do feel like this is a different UMA token profile which should be pretty easy to write for your constrained environment. In this profile you could allow for a "permission ticketless token" which is what the returned access_token would be and then define how the AS should process it against a specific identified resource.

Thanks, George

On 6/27/16 12:55 PM, James Phillpotts wrote:

I'm assuming (2) - not interested in any tokens from other IdPs. Yes, I'm assuming that in this case the client is using the UMA AS as the OpenID Connect IdP, and wants to add extra claims for up-front token acquisition (as per other thread), which the OpenID Connect extension request parameters are useful for providing.

Cheers James

On 27 June 2016 at 17:51, George Fletcher < george.fletcher@teamaol.com> wrote:

...

Yes, but then either (1) the AS is NOT the issuer of the id_token and can't process it because of the audience restrictions or (2) the AS is the issuer of the id_token and this is a very specialized and restricted use case. Also, if the client is doing pure OAuth it won't get an id_token so in this context the client would need to be using the UMA AS as the client's OpenID Connect provider.

Maybe I'm missing something?

Thanks, George

On 6/27/16 12:47 PM, James Phillpotts wrote:

The RS wouldn't know it's been given an ID Token though - it would just have a bearer token with some long string that it is then going to send on to the AS.

J.

On 27 June 2016 at 17:36, George Fletcher < george.fletcher@teamaol.com> wrote:

...

Another issue with id_tokens that affects this kind of a use case is that id_tokens are currently audience bound to the client, so if you send it to the RS, it should be rejected because the RS is not the audience of the id_token. It's possible to get around the audience issues using a token exchange mechanism, but then the resulting token is not an id_token but just another JWT functioning as an access token (per Justin's last paragraph).

Thanks, George

On 6/23/16 5:12 PM, Justin Richer wrote:

ID tokens and access tokens are different creatures. ID Tokens are assertions that describe an authentication event. They’re meant to be consumed and, generally, tossed. The client doesn’t store them to use them with other services. The access token defines an access delegation and is consumed by the resource, not the client. The client holds on to the access token so that it can use it with the resource over time, until the token isn’t good anymore.

If instead what you’re saying is to declare a JWT-formatted access token, that’s something else entirely — but don’t call it an ID token. JWTs have their own issues and tradeoffs when used as access tokens.

— Justin

On Jun 23, 2016, at 7:18 AM, James Phillpotts wrote:

Hi again,

Another suggestion for consideration in UMA-next is whether we should support ID Tokens as an alternative to OAuth2 access tokens for bearer tokens from the Client to the RS. As the ID Token would be minted by the AS, then it should be able to introspect it just as it would an access token.

This would also have an advantage in the token-first flow I outlined in my other mail, where the Client can use the additional claims part of requesting an ID Token in OpenID Connect to get the AS to eagerly get extra claims for the user, for example at the time of enrolment.

Cheers James _______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

-- Distinguished Engineer Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography

-- Distinguished Engineer Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography

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

-- Distinguished Engineer Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography