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

Brian Campbell <bcampbell@pingidentity.com> Thu, 17 December 2015 15:24 UTC

Return-Path: <bcampbell@pingidentity.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 898B71B2EB7 for <oauth@ietfa.amsl.com>; 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 <oauth@ietfa.amsl.com>; 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 <oauth@ietf.org>; Thu, 17 Dec 2015 07:24:54 -0800 (PST)
Received: by mail-io0-x235.google.com with SMTP id q126so58323052iof.2 for <oauth@ietf.org>; 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: <CAGL6epKjLvuTCrdvAc1p3rz3oQQUt+VZSU_nkUCggk_Gmk_NGQ@mail.gmail.com>
References: <BY2PR03MB442F1857A7B1936D83F18DCF5ED0@BY2PR03MB442.namprd03.prod.outlook.com> <CAGL6epKjLvuTCrdvAc1p3rz3oQQUt+VZSU_nkUCggk_Gmk_NGQ@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 17 Dec 2015 16:24:24 +0100
Message-ID: <CA+k3eCSwQ+eO2P0Oh0EO+Kyq8vwA=+1nz2S1Fs_T57wjMG4aRA@mail.gmail.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a114075c2e64a040527199f76
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/0cD9Nr69vGyaFS_gW-9Ojw0iTUg>
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 15:24:56 -0000

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
>
>