Subject: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us

From: Mike Jones <[email-masked]>
Date: Mon, 14 Dec 2015 08:05:28 +0000

I'm happy to report that a substantially revised OAuth 2.0 Token Exchange draft has been published that enables a broad range of use cases, while still remaining as simple as possible.  This draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working group input from the in-person discussions in Prague and mailing list discussions.  Thanks to all for your interest in and contributions to OAuth Token Exchange!  Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this draft.

The core functionality remains token type independent.  That said, new claims are also defined to enable representation of delegation actors in JSON Web Tokens (JWTs).  Equivalent claims could be defined for other token types by other specifications.

See the Document History section for a summary of the changes made.  Please check it out!

The specification is available at:

*       http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03

An HTML-formatted version is also available at:

*       http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html

                                                          -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1509 and as @selfissued<https://twitter.com/selfissued>.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 16 Dec 2015 17:17:14 -0500

Hi Mike,

In section 2.2.1 Successful Response, the text states that refresh_token is
NOT RECOMMENDED, but it does not explain the reason behind this.
Can you please elaborate on this point and explain the rational behind this
choice?

Another question is around the impact of the new token on the subject
token.
Does a successful response mean that the Client can no longer use the
subject token?

Regards,
 Rifaat

On Mon, Dec 14, 2015 at 3:05 AM, Mike Jones <[email-masked]>
wrote:

> I’m happy to report that a substantially revised OAuth 2.0 Token Exchange
> draft has been published that enables a broad range of use cases, while
> still remaining as simple as possible.  This draft unifies the approaches
> taken in the previous working group draft and draft-campbell-oauth-sts,
> incorporating working group input from the in-person discussions in Prague
> and mailing list discussions.  Thanks to all for your interest in and
> contributions to OAuth Token Exchange!  Brian Campbell deserves special
> recognition for doing much of the editing heavy lifting for this draft.
>
>
>
> The core functionality remains token type independent.  That said, new
> claims are also defined to enable representation of delegation actors in
> JSON Web Tokens (JWTs).  Equivalent claims could be defined for other token
> types by other specifications.
>
>
>
> ·       http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03
>
>
>
> ·
> http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html
>
>
>
>                                                           -- Mike
>
>
>
> P.S.  This note was also posted at http://self-issued.info/?p=1509 and as
> @selfissued <https://twitter.com/selfissued>.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 17 Dec 2015 16:24:24 +0100

Fair questions Rifaat,

Typically a token exchange is done to exchange a temporary credential (the
token the client sends in) for a different temporary credential (the issued
token) that can be used in some other context. A refresh token would be an
additional credential issued and one that probably isn't so temporary (the
lifetime of refresh tokens depends on the deployment/implementation but are
often unlimited or relatively long), which sort of undermines the typical
token exchange model of swapping temporary credentials. Does that explain
it any more? I can add some text along those lines into the next draft.

In general the act of doing the exchange has no impact on the validity of
the subject token (or actor token). I suppose that particular kinds of
token could have one-time-use semantics or something like that, which would
mean the doing the exchange makes it no longer usable. But that would be a
specific detail of the particular kind of token.

On Wed, Dec 16, 2015 at 11:17 PM, Rifaat Shekh-Yusef <[email-masked]>
wrote:

> Hi Mike,
>
> In section 2.2.1 Successful Response, the text states that refresh_token
> is NOT RECOMMENDED, but it does not explain the reason behind this.
> Can you please elaborate on this point and explain the rational behind
> this choice?
>
>> P.S.  This note was also posted at http://self-issued.info/?p=1509 and
>> as @selfissued <https://twitter.com/selfissued>.
>>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 17 Dec 2015 11:21:07 -0500

Hi Brian,

Thanks for your response.

Yes, that clarifies it for me. It would be great if you can add some text
around these two issues to the next version of the document.

Regards,
 Rifaat

On Thu, Dec 17, 2015 at 10:24 AM, Brian Campbell <[email-masked]

> On Wed, Dec 16, 2015 at 11:17 PM, Rifaat Shekh-Yusef <
> [email-masked]> wrote:
>
>> Hi Mike,
>>
>>> I’m happy to report that a substantially revised OAuth 2.0 Token
>>> Exchange draft has been published that enables a broad range of use cases,
>>> while still remaining as simple as possible.  This draft unifies the
>>> approaches taken in the previous working group draft and
>>> draft-campbell-oauth-sts, incorporating working group input from the
>>> in-person discussions in Prague and mailing list discussions.  Thanks to
>>> all for your interest in and contributions to OAuth Token Exchange!  Brian
>>> Campbell deserves special recognition for doing much of the editing heavy
>>> lifting for this draft.
>>>
>>>
>>>

---

From: nov matake <[email-masked]>
Date: Mon, 21 Dec 2015 15:32:02 +0900

Hi Mike,

I’m planning to use Token Exchange spec for a use-case described bewlow.

1. a native app obtains an access_token & an id_token from an IdP
2. the native app passes the id_token to its own backend component
3. the backend component obtains an access token from the IdP using the id_token via token exchange

In this use-case, the IdP will issue an id_token like below gist.
https://gist.github.com/nov/d760b78c5cce8248b308

In the gist, “cnf” and “scopes" claim comes from OpenID Connect ACDC discussed in the NAPPS WG.
https://bitbucket.org/openid/napps/src/c22a2adb3f66f7a34fb599285720498782390f7d/draft-acdc-01.txt?at=default&fileviewer=file-view-default

And now I realized ACDC defines “scopes” claim and Token Exchange defines “scp”.
In my case, the first id_token will includes “scopes” claim, and the access token issued to the client's backend component includes “scp” claim.
It’s theoretically OK, but I prefer those two claims have the same name…

nov

> On Dec 14, 2015, at 17:05, Mike Jones <[email-masked]> wrote:
> 
> I’m happy to report that a substantially revised OAuth 2.0 Token Exchange draft has been published that enables a broad range of use cases, while still remaining as simple as possible.  This draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working group input from the in-person discussions in Prague and mailing list discussions.  Thanks to all for your interest in and contributions to OAuth Token Exchange!  Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this draft.
>  
> ·       http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 <http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03>
>  
> ·       http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html <http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html>
>  
>                                                           -- Mike
>  
> P.S.  This note was also posted at http://self-issued.info/?p=1509 <http://self-issued.info/?p=1509> and as @selfissued <https://twitter.com/selfissued>.
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>