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 <bcampb...@pingidentity.com > wrote: > 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.i...@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.jo...@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 >> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
