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

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 <rifaat.ietf@gmail.com>
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?
>
> 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 <Michael.Jones@microsoft.com>
> 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.
>>
>>
>>
>> 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>.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>