Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt

Brian Campbell <> Fri, 08 December 2017 20:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20104128656 for <>; Fri, 8 Dec 2017 12:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.719
X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fVxL--3lawTl for <>; Fri, 8 Dec 2017 12:48:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61D80127241 for <>; Fri, 8 Dec 2017 12:48:04 -0800 (PST)
Received: by with SMTP id s37so3678995ioe.10 for <>; Fri, 08 Dec 2017 12:48:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R7wjuzfwfBSxz2QgHWDnmbLSa9fK3ZCQiQuGF4tnnfI=; b=pkZILknah4ExFRH/3bAI8fuvn7N2HGGwh4cr/LpTAL05tXA3OWZFFIXRpugyRUa6+w EUTJOCxpVtvB+2LmoO/Aooz0N2khlKLMbIqVivKW1/b+L537E86S3dORjQaUD2ILvnT+ tYt7rU4AgpoyHNmX4I/ZCbyjeKLikiAGvMD6s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R7wjuzfwfBSxz2QgHWDnmbLSa9fK3ZCQiQuGF4tnnfI=; b=DKemQkTPPWpBAgWcpgAbMLSBWKJ03F8PJj3vDM2WkTFKdjF/PcJJ4FVSEw/nX08mH1 LHaj0jrKhcHkNP8dSOuiEI7DkQqruO810y8Q6S8lkrV5CdVaMi7qK3eQNpnfbU4MgCJX Uildfccey+cxCjLI1fQI9y1hg1W7KZC9QsRTEoORU5rt1kBz7Wv9SeUuD9cjMqAkT36r gMX1pCz6b0FSJm9/QNIgZsrD+TAdEpYlShboO3HTbotxggfMnGcevIkbg6kLBWZHwfgq nlmEdXh8KicYPtJQXdlvOk9d4wkWIox6rgfoYG/Fc0lUvPN67rB4VTmdTaahE6nK1H0F qrAg==
X-Gm-Message-State: AKGB3mJC0xY/lwWjNh8wxg9qjYtXFjNtKNsO/R9ZO5bhn4090v3yfM0A 1qqe6YVnscSnJhM1pHv92b6bUvhLW0VXXmfPymBRZeLj87gQ6tbciwPWUACJNb2PILn9OBaXkBd SuWOltRAKg/q1Yw==
X-Google-Smtp-Source: AGs4zMaJ2P21mzZGcj/3SG4FkpLpxSg43/x9bbIitIKPyhNfrBynrm9gA/NAjLMsY1yRYUO9NUX/NL2B4jSy3iEbVV4=
X-Received: by with SMTP id n187mr39398465iod.54.1512766083184; Fri, 08 Dec 2017 12:48:03 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 8 Dec 2017 12:47:32 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Brian Campbell <>
Date: Fri, 8 Dec 2017 13:47:32 -0700
Message-ID: <>
To: Denis <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="94eb2c05be5a045b9a055fda4dec"
Archived-At: <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Dec 2017 20:48:07 -0000

As an individual, I do not believe that the proposed text should be
incorporated into the draft.

As one of the document editors, my responsibility is for the document to be
of reasonable quality and to reflect the rough consensus of this Working
Group. So I should ask the list more explicitly - are there other WG
remembers who are in favor of the proposed text here (the text would have
to be fixed up some too)?

On Fri, Dec 1, 2017 at 11:12 AM, Denis <> wrote:

> Comments on draft-ietf-oauth-token-exchange-10
> I propose the following rephrasing for sections 6 and 7:
> 6 . Security Considerations
> All of the normal security issues that are discussed in [JWT],especially
> in relationship to comparing URIs
> and dealing with unrecognized values, also apply here.  In addition, both
> delegation and impersonation introduce
> unique security issues. Any time one user receives a token, the potential
> for abuse is a concern,
> since that user might be willing to collude with another user so that
> other user could use the token.
> Techniques like the binding of an access token to a TLS channel described
> elsewhere are ineffective since
> the legitimate user would be able to perform all the cryptographic
> computations that the other user would need
> to demonstrate the ownership of the token. The use of the "scp" claim is
> suggested to mitigate potential for
> such abuse, as it restricts the contexts in which the token can be
> exercised.  If the issued access token scope
> allows to unambiguously identify the user, then that user is likely to be
> reluctant to collude with another user.
> However, if the issued access token scope only indicates that the user is
> over 18, then there is no risk
> for the original user to be discovered and in such a context a collusion
> may easily take place.
> This document does not specify techniques to prevent such a collusion to
> be successful.
> 7 . Privacy Considerations
> Tokens typically carry personal information and their usage in Token
> Exchange may reveal details of the target services
> being accessed. The resource and the audience parameters allow
> authorization servers to know where the issued access token
> will be used.  This may be a privacy concern for some users. This
> document does not specify techniques to prevent
> authorization servers to know where the access tokens they issue will be
> used.
> Denis
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>         Title           : OAuth 2.0 Token Exchange
>         Authors         : Michael B. Jones
>                           Anthony Nadalin
>                           Brian Campbell
>                           John Bradley
>                           Chuck Mortimore
> 	Filename        : draft-ietf-oauth-token-exchange-10.txt
> 	Pages           : 32
> 	Date            : 2017-11-30
> Abstract:
>    This specification defines a protocol for an HTTP- and JSON- based
>    Security Token Service (STS) by defining how to request and obtain
>    security tokens from OAuth 2.0 authorization servers, including
>    security tokens employing impersonation and delegation.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> OAuth mailing listOAuth@ietf.org
> _______________________________________________
> OAuth mailing list

*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*