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

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Thu, 17 December 2015 16:21 UTC

Return-Path: <rifaat.ietf@gmail.com>
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 93F971B2F45 for <oauth@ietfa.amsl.com>; Thu, 17 Dec 2015 08:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 tT6xhsl1Rh4w for <oauth@ietfa.amsl.com>; Thu, 17 Dec 2015 08:21:08 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 240DC1B2F27 for <oauth@ietf.org>; Thu, 17 Dec 2015 08:21:08 -0800 (PST)
Received: by mail-ig0-x22a.google.com with SMTP id mv3so16088638igc.0 for <oauth@ietf.org>; Thu, 17 Dec 2015 08:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m6zj4b++w1/5WOVHh8eNpGJ1Le6oQYyvzdfAXWOqnd0=; b=QpbpUa+2b3QozeDSdu8Cbt0Fey+HVgWHwA6JmPmEPb/vXAoWaqLk5YXiITEerG7ZRE meyMjuBX8eQYLFcYf2CxX3UWCt3dB00jw0PLoh9R0EF5Cke6NN0jiFQm9D1V5tOMABXv JD5he8RSRXRp48BcZgPbCk3VJ0LqPbgHYqmytudsigTNDvX1UmMtwlAi03A+KXMyvv56 WgX+eJ7ycbo8m04Lgvfin80FMaHfC9BH2gAZVFnmPVAspLxrNK553RH2QwZ7cn0ckFRY my4lgCu4sYpjS1T4q+S0ARi2z2d2g6BO9FrEPp1MkO6dlRbZOMSIxyGJ3gOMpTqu3i1d ZX4w==
MIME-Version: 1.0
X-Received: by 10.50.124.102 with SMTP id mh6mr3078120igb.12.1450369267559; Thu, 17 Dec 2015 08:21:07 -0800 (PST)
Received: by 10.107.147.6 with HTTP; Thu, 17 Dec 2015 08:21:07 -0800 (PST)
In-Reply-To: <CA+k3eCSwQ+eO2P0Oh0EO+Kyq8vwA=+1nz2S1Fs_T57wjMG4aRA@mail.gmail.com>
References: <BY2PR03MB442F1857A7B1936D83F18DCF5ED0@BY2PR03MB442.namprd03.prod.outlook.com> <CAGL6epKjLvuTCrdvAc1p3rz3oQQUt+VZSU_nkUCggk_Gmk_NGQ@mail.gmail.com> <CA+k3eCSwQ+eO2P0Oh0EO+Kyq8vwA=+1nz2S1Fs_T57wjMG4aRA@mail.gmail.com>
Date: Thu, 17 Dec 2015 11:21:07 -0500
Message-ID: <CAGL6epK+O788MBhWg++mOLYgeObdvn27mT+Cx2TsMtY6M7=P-Q@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Content-Type: multipart/alternative; boundary=089e0111c1bafc747305271a689d
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/I-xlqhib17j4PaKEqNrCSvPtavI>
Cc: "oauth@ietf.org" <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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 16:21:10 -0000

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 <bcampbell@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.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
>>
>>
>