Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898B71B2EB7 for ; Thu, 17 Dec 2015 07:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0dKw-N4gVKl for ; Thu, 17 Dec 2015 07:24:54 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826A71B2EA0 for ; Thu, 17 Dec 2015 07:24:54 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id q126so58323052iof.2 for ; Thu, 17 Dec 2015 07:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+jwot8ockiSGHrSFLZZFzGRcUGBce8YE19lMDYbFk4I=; b=gp9BudrksAF0+JPrdEN/02vIuOV9JWMWyvbimi1EqEQFVTrDyROIfNY/0ihpOft0l8 GuajXuthXd26Lb5AZnglxqJ9W/UKHppX5vq+WLyO8LObozuSG+DvnOhesq8n3bk4Bp1W O2uBDDrGztLTC1X+NlHv+bVnhFf1J+QyJtLG0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+jwot8ockiSGHrSFLZZFzGRcUGBce8YE19lMDYbFk4I=; b=Cxqxll+pjYcyp/OUNo8WyaDqu2rz17cHNDxKTfiEtlh7y18wK0vtpMX5yMbf8LWblG NNedkDNMOGu6VxQn4HLKzMv8xuiWFvJEEWP42rpc23MvjS4p2XhVlDV3hEt11dG1xejo i1Mx/ZnxmY9LYO3AIqKheEKRMRFsxz3huymBlgXpsTWkqzLYHhQrXRvn87D31wZAggbl dqneqEoAQMPWV8ddzREDkQv4XjPo+kwbhLp/ZT1GpZVGuFB16IEmcoaTGPB+z3d7dFq5 OvJuUW0roN97gt41M221VLlU5fQkk59/7Kg/RIP0BlvkBBM+E0hDqycCzk0AuAFmgz0J ctEw== X-Gm-Message-State: ALoCoQkivbOjB09HbsbMYJiYwSWlzER+eMLAIFhnlb8UiRpIKmhj2FjhjnNZXZVx20yuY4kabLPoLPu0Oft7YcPkntFLNt+qZDCqH5UwCb99BekD39EdHDg= X-Received: by 10.107.158.213 with SMTP id h204mr58152154ioe.129.1450365893880; Thu, 17 Dec 2015 07:24:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Thu, 17 Dec 2015 07:24:24 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Thu, 17 Dec 2015 16:24:24 +0100 Message-ID: To: Rifaat Shekh-Yusef Content-Type: multipart/alternative; boundary=001a114075c2e64a040527199f76 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 15:24:56 -0000 --001a114075c2e64a040527199f76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 > wrote: > >> I=E2=80=99m 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 approache= s >> taken in the previous working group draft and draft-campbell-oauth-sts, >> incorporating working group input from the in-person discussions in Prag= ue >> 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 to= ken >> 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: >> >> =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-= 03 >> >> >> >> An HTML-formatted version is also available at: >> >> =C2=B7 >> 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=3D1509 and >> as @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 > > --001a114075c2e64a040527199f76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fair questions Rifaat,

Typically a= token exchange is done to exchange a temporary credential (the token the c= lient sends in) for a different temporary credential (the issued token) tha= t 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 lifeti= me 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 t= oken 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.=C2=A0



On Wed, Dec 16= , 2015 at 11:17 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com><= /span> wrote:
Hi Mike,
In section 2.2.1 Successful Response, the text states tha= t refresh_token is NOT RECOMMENDED, but it does not explain the reason behi= nd this.
Can you please elaborate on this point and explain the r= ational behind this choice?

Another question is ar= ound the impact of the new token on the subject token.=C2=A0
Does= a successful response mean that the Client can no longer use the subject t= oken?

Regards,
=C2=A0Rifaat


On Mon, Dec 14, 2015 at 3:05 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m happy to report that a substantially rev= ised OAuth 2.0 Token Exchange draft has been published that enables a broad= range of use cases, while still remaining as simple as possible.=C2=A0 Thi= s draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working gr= oup input from the in-person discussions in Prague and mailing list discuss= ions.=C2=A0 Thanks to all for your interest in and contributions to OAuth T= oken Exchange!=C2=A0 Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this d= raft.

=C2=A0

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

=C2=A0

See the Document History section for a summary of th= e changes made.=C2=A0 Please check it out!

=C2=A0

The specification is available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/dra= ft-ietf-oauth-token-exchange-03

=C2=A0

An HTML-formatted version is also available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info= /docs/draft-ietf-oauth-token-exchange-03.html

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<= u>

=C2=A0

P.S.=C2=A0 This note was also posted at http://self-issued.info/?p=3D1509 and as @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


--001a114075c2e64a040527199f76--