Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item

Mike Jones <> Fri, 08 August 2014 18:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4EFE11A002C for <>; Fri, 8 Aug 2014 11:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tjNKvsFre-yD for <>; Fri, 8 Aug 2014 11:19:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B4911A001A for <>; Fri, 8 Aug 2014 11:19:27 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 18:19:18 +0000
Received: from (2a01:111:f400:7c10::178) by (2a01:111:e400:2c5d::49) with Microsoft SMTP Server (TLS) id 15.0.1005.10 via Frontend Transport; Fri, 8 Aug 2014 18:19:18 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Fri, 8 Aug 2014 18:19:17 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Fri, 8 Aug 2014 18:19:06 +0000
From: Mike Jones <>
To: Brian Campbell <>
Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item
Date: Fri, 08 Aug 2014 18:19:05 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AE0D742TK5EX14MBXC293r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(189002)(199002)(377454003)(77096002)(16236675004)(83072002)(93886004)(80022001)(95666004)(66066001)(19617315012)(107046002)(106116001)(104016003)(74502001)(512874002)(110136001)(33656002)(71186001)(19300405004)(85852003)(85306004)(50986999)(76176999)(54356999)(64706001)(81342001)(99396002)(81542001)(16297215004)(46102001)(86362001)(97736001)(19580405001)(83322001)(21056001)(6806004)(92566001)(44976005)(86612001)(55846006)(68736004)(20776003)(84326002)(84676001)(74662001)(15975445006)(81156004)(106466001)(15202345003)(4396001)(79102001)(31966008)(69596002)(2656002)(77982001)(19580395003)(19625215002)(87936001)(26826002)(92726001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR0301MB0763;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 02973C87BC
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, "" <>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item
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: Fri, 08 Aug 2014 18:19:35 -0000

First, I’ll say that I appreciate Brian also working on this topic.  This is important for many multi-actor use cases and it would be good for OAuth to develop a standard in this area.  I also agree with the discussion on the list that having some use case descriptions and concrete examples could help developers know how to do token exchange in an interoperable way.  We should do that going forward.

I just skimmed through Brian’s document.  I agree with the thrust of a lot of.  Much of it is equivalent to parts of draft-jones-oauth-token-exchange – albeit with different syntax.  However, it seems to be missing the ability to represent statements about who is eligible to act for who, as is enabled by  Also, I’m not sure I’m comfortable overloading the access_token Token Endpoint response to convey the returned security token, since in the general case, the security token is not an access token.  All of those are the kinds of details that the working group will get to decide on, so I’m not all that hung up on them right now.

As a way forward, I’d actually propose that we accept draft-jones-oauth-token-exchange as a starting point for the working group document – as the hum in Toronto seemed to say that we would – but that we add Brian as a co-author of it.  I’m comfortable working with Brian as a co-editor and we have a good track record of doing productive work together – including the nearly finished OAuth Assertions specifications.

I’d also privately communicated to Brian that I see my current document as a starting point for the work and not something in final form and that I’d be happy to work with him to make sure that his use cases are accommodated and that it’s clear to developers how and when to use token exchange.

                                                            Best wishes,
                                                            -- Mike

From: OAuth [] On Behalf Of Brian Campbell
Sent: Friday, August 08, 2014 10:55 AM
To: John Bradley
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item

Absolutely agree that some examples are needed. There's a [[ TODO ]] in there for it. I just hadn't gotten to it yet and wanted to get the I-D up before the Aug 10 date that Hannes put out there. The example you outlined is a good start, I think.
Yes, code and refresh tokens would/could be valid tokens. A previously issued access token might also be. JWT & SAML too. The last paragraph of attempts to state that the scope of the doc is only the framework for exchange and that the "syntax, semantics and security characteristics of the tokens themselves (both those presented to the are explicitly out of scope."  What constitutes a valid token will depend on the deployment or additional profiling.

"So how might sending an act_as token to the token endpoint as part of the request impact the result." -> in general I was thinking it'd result in an azp claim or something like that in the returned token.

"Do you see the act_as interacting with PoP to limit who can present the resulting token. " -> Quite possibly. Though, honestly, I don't yet have a complete concept of how PoP works in conjunction with all this.

"Is act_as simply duplicating the authentication portion of the current assertion profile?" -> there is potential for duplication in some cases, yes. But the motivation for act_as was to give additional flexibility by allowing an additional party to be represented. Also to try and align with
draft-jones-oauth-token-exchange<> to the extent possible. I had toyed with the idea of only having one inbound token for the subject and having the client (relying on client authentication) be the actor. Then maybe a flag to indicate if delegation vs impersonation is deserted in the returned token. But it seemed like there was a need (things you'd said among others) for more than two parties to be represented. There's some refinement to be done for sure though.

"Not having concrete answers at this point is not a problem, but we do need to think all of this through." -> agree

"I think this document is also useful input." -> thanks