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

John Bradley <> Fri, 08 August 2014 18:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 435F51A00AE for <>; Fri, 8 Aug 2014 11:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kNkvlbIK_Jy8 for <>; Fri, 8 Aug 2014 11:47:32 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD0401A0067 for <>; Fri, 8 Aug 2014 11:47:31 -0700 (PDT)
Received: by with SMTP id f12so5884907qad.17 for <>; Fri, 08 Aug 2014 11:47:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nQboFnkptnGL7h5f4nROnjaUA2B3zKVRNGTlVWtk010=; b=S1OQBJZwzP70kCvCzYXBD4HE/KbLw7uIXeHcbgcyq1ys13wm9KW4wn0qszg2NI8ljM dGimCJVAnMEPpSScOuTIpPG5azipZ3O4WSiorKCmXGpzkwy3nAUuqktDL+/o9o8JJJ7J ygIX/W5JtQph0bLGubeExSeN+QQ5IZuzAWHPpGUEyAH+pY+4ExKDyxtIuGJ2YQOwGTrr gwTXSYb4jHe1AEuMlGQuFsjC7JhiBRUviW+RXNZfT0Qjx0tJLs7FCBOHmTqse7DXkptc 8RWdSIu+6Nh9YIxBvMEJJXA9fRHuRrtqfOyUFIL5qWwHoCLwzLFzurc/RLLPck/l7+wj D84g==
X-Gm-Message-State: ALoCoQk0gu5NU22KgQ8/apjAFTtRHipnAfSsxudeYTkKI0SEuXQ6MyDbOS8hZaQtKGhame5ETPEg
X-Received: by with SMTP id gs10mr39821931qcb.7.1407523651109; Fri, 08 Aug 2014 11:47:31 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id g3sm6816352qar.31.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 11:47:30 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_5BD9E430-046A-42B5-B6F0-A67A1BC76C96"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley <>
In-Reply-To: <>
Date: Fri, 08 Aug 2014 14:49:23 -0400
Message-Id: <>
References: <> <> <> <>
To: Brian Campbell <>
X-Mailer: Apple Mail (2.1878.6)
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:47:34 -0000

OK so act_as if not sent is implicitly the requestor perhaps authenticated by the endpoint in the normal OAuth way.

If the if the requestor is acting like a proxy as in the Token Agent case the act_as would indicate the identity of the client making the request to the Token Agent so that the resulting token can include that identity as the AZA.

I think that logic holds together.  

In that case, if the resulting token is PoP,  then the party identified by the act_as's  public key would go in the resulting token.  

That may actually be reversed from the WS-Trust usage, but that is something else to dig into in the WG.

I think working on this along side of the PoP drafts will help prevent possible conflicts and confusions.

We should accept Mikes draft or both of these as a starting point.

John B.

On Aug 8, 2014, at 1:55 PM, Brian Campbell <> wrote:

> 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