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

Anthony Nadalin <> Mon, 11 August 2014 16:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 65C351A0640 for <>; Mon, 11 Aug 2014 09:41:18 -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 PHmHx0DSN1LO for <>; Mon, 11 Aug 2014 09:41:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A78721A05C0 for <>; Mon, 11 Aug 2014 09:41:15 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1010.13; Mon, 11 Aug 2014 16:40:55 +0000
Received: from ([]) by ([]) with mapi id 15.00.1010.013; Mon, 11 Aug 2014 16:40:55 +0000
From: Anthony Nadalin <>
To: Brian Campbell <>, Mike Jones <>
Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item
Thread-Index: AQHPqoof8H11iWqER027eNF8GSlzsZvG1MCAgAAqHACAAA/hAIAABqiAgAR6bwCAACA0MA==
Date: Mon, 11 Aug 2014 16:40:55 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:80e0:ee43::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 03008837BD
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(377454003)(21056001)(79102001)(77982001)(80022001)(81542001)(16236675004)(1511001)(93886004)(20776003)(2421001)(19300405004)(64706001)(85852003)(86362001)(19580395003)(19580405001)(92566001)(83322001)(83072002)(33646002)(2656002)(50986999)(87936001)(86612001)(106356001)(54356999)(76176999)(4396001)(76576001)(99396002)(107046002)(101416001)(46102001)(106116001)(81342001)(15975445006)(76482001)(85306004)(15202345003)(95666004)(74316001)(99286002)(31966008)(74662001)(105586002)(74502001)(19625215002)(3826002)(24736002)(108616003)(42262002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309;; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_28538159db0344b7a0c572e31c75ed50BLUPR03MB309namprd03pro_"
MIME-Version: 1.0
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: Mon, 11 Aug 2014 16:41:18 -0000

I read the draft and just don’t get it, it overloads some of the basic semantics, I’m not quite sure you get the concept of token exchange, has what you described been deployed ? or even built ?

From: OAuth [] On Behalf Of Brian Campbell
Sent: Monday, August 11, 2014 7:42 AM
To: Mike Jones
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item

I'd be okay with that as a way forward. Frankly, of course, I'd prefer to see draft-campbell-oauth-sts as the starting point with Mike and the other draft-jones-oauth-token-exchange authors added as co-authors. Regardless, there are elements from both that likely need to end up in the final work so a consolidation of authors and concepts makes sense.
And yes, there are lots of details that the working group will need to decide on going forward that we shouldn't get hung up on right now. Though I believe that deciding if the token endpoint is used for general token exchange is an important philosophical question that should be answered first. If the token endpoint is to be used, I strongly belie that this token exchange should leverage and work within the constructs provided and defined by OAuth. That's the direction I took with draft-campbell-oauth-sts and yes that involves overloading the access_token response parameter with something that's not always strictly an access token. The existing token endpoint request/response are already rather close to what one might expect in an STS type exchange. I find there's a nice elegant simplicity to it but I also see where that discomfort might come from. If there's consensus to not use/overload the existing stuff, I think it'd be much more appropriate to define a new endpoint. A lot of syntactic stuff likely falls out from that decision.