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

Brian Campbell <> Fri, 08 August 2014 17:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F4A21A00D5 for <>; Fri, 8 Aug 2014 10:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bgb_2kVwNkE9 for <>; Fri, 8 Aug 2014 10:55:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E42C71A007D for <>; Fri, 8 Aug 2014 10:55:47 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Fri, 08 Aug 2014 10:55:47 PDT
Received: by with SMTP id h3so1409113igd.8 for <>; Fri, 08 Aug 2014 10:55:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2UXUGuLwstN9IFhXLk7KYdoRE+yL6evuLOEQTikPoJA=; b=VEgxcKEpEH5CrFiAHP/fYuFCxY+ESRSsPevI9UIElvtffi9Wf49no9MqhiduAWflX0 9dFGEWbIgnUq9n1kK2Kw9gM2mDmnEfvtjJOi3NutH5oLrFsjl8kN664208zIYnK+L6hN nqxkgkqoK/6D81oM8gQsh3T3hkvMWGhG9v2oMdRs08p+299qjHCPFZ1VOp97x8k4VXFw yQNB1BQ465Kb/dnt+vcmtQUK3lqnvrbXm9xm33l0pAEnUF88wQBv68XUw6t4cEyoXx/C 2InpU0OG+X2X6Mf0pY/kmuW6UIOO0MsZnlEiY6At4o0rEyhqoVnpUOq7ag1PEQ4Yxbso QbaQ==
X-Gm-Message-State: ALoCoQkMsVDze5tHmhNfc38asDj5jvMJjk2DsYtSBzxN6Dz18poYqB26U8QBHodAJeBUve7a1wfOEmcaegexXdVxfs3QlsdANTMMc0Qpq88JE6vBCNTqukfkSoKzQQ+vvJRGP+2kE5bK
X-Received: by with SMTP id gc2mr7593206igd.40.1407520547158; Fri, 08 Aug 2014 10:55:47 -0700 (PDT)
X-Received: by with SMTP id gc2mr7593187igd.40.1407520547042; Fri, 08 Aug 2014 10:55:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 8 Aug 2014 10:55:16 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Brian Campbell <>
Date: Fri, 08 Aug 2014 11:55:16 -0600
Message-ID: <>
To: John Bradley <>
Content-Type: multipart/alternative; boundary="001a1135f3a4389a45050021ea50"
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 17:55:50 -0000

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

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