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

Denis <> Fri, 01 December 2017 18:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2A57127876 for <>; Fri, 1 Dec 2017 10:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.617
X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vfxJOXF-00ng for <>; Fri, 1 Dec 2017 10:12:29 -0800 (PST)
Received: from ( [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B22312762F for <>; Fri, 1 Dec 2017 10:12:29 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTP id ECD21780336 for <>; Fri, 1 Dec 2017 19:12:26 +0100 (CET)
References: <>
From: Denis <>
Message-ID: <>
Date: Fri, 1 Dec 2017 19:12:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------2470B47927CC114E82FF06B9"
Content-Language: en-US
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, 01 Dec 2017 18:12:32 -0000

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 

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