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

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 26 Mar 2017 16:00:10 +0200

Hi Brian,

thanks for the clarification around resource, audience and scope. 

Here are my comments on the draft:

In section 2.1 it states: „Multiple "resource" parameters may be used to indicate
      that the issued token is intended to be used at the multiple
      resources listed.“

Can you please explain the rational in more detail? I don’t understand why there is a need to ask for access tokens, which are good for multiple resources at once. This is a request type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction. 

On the other side, this feature increases the AS's complexity, e.g. its policy may prohibit to issue tokens for multiple resources in general or the particular set the client is asking for. How shall the AS handles such cases?

And it is getting even more complicated given there could also be multiple audience values and the client could mix them: 

"Multiple "audience" parameters
      may be used to indicate that the issued token is intended to be
      used at the multiple audiences listed.  The "audience" and
      "resource" parameters may be used together to indicate multiple
      target services with a mix of logical names and physical
      locations.“

And in the end the client may add some scope values to the „meal“, which brings us to 

„Effectively, the requested access rights of the
   token are the cartesian product of all the scopes at all the target
   services."

I personally would suggest to drop support for multiple audience and resource parameters and make audience and resource mutual exclusive. I think this is sufficient and much easier to implement.

kind regards,
Torsten.

> Am 11.01.2017 um 20:04 schrieb Brian Campbell <[email-masked]>:
> 
> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource/scope, which was a request or comment that came up during the f2f meeting in Seoul. 
> 
> Excerpted from the Document History:
> 
>    -07
> 
>    o  Fixed typo (desecration -> discretion).
>    o  Added an explanation of the relationship between scope, audience
>       and resource in the request and added an "invalid_target" error
>       code enabling the AS to tell the client that the requested
>       audiences/resources were too broad.
> 
> 
> ---------- Forwarded message ----------
> From: <[email-masked] <mailto:[email-masked]>>
> Date: Wed, Jan 11, 2017 at 12:00 PM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol 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-07.txt
>         Pages           : 31
>         Date            : 2017-01-11
> 
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/>
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07 <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07>
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07>
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> _______________________________________________
> OAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Mon, 27 Mar 2017 08:44:33 -0500

Thanks for the review and question, Torsten.

The desire to support multiple audience/resource values in the request came
up during a review and discussion among the authors of the document when
preparing the -03 draft. As I recall, it was said that both Salesforce and
Microsoft had use-cases for it. I incorporated support for it into the
draft acting in the role of editor.

>From an individual perspective, I tend to agree with you that allowing for
multiple audiences/resources adds a lot of complexity that's like not
needed in many (or most) cases. And I would personally be open to making
audience and resource mutual exclusive and single valued. A question for
the WG I suppose.

The "invalid_target" error code that was added in -07 was intended to give
the AS a standard way to deal with the complexity and reject request with
multiple audiences/resources that it doesn't understand or is unwilling or
unable to process. It was intended as a compromise, of sorts, to allow for
the multiples but provide an easy out of saying it can't be supported based
on whatever implementation or policy of the AS.

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> Can you please explain the rational in more detail? I don’t understand why
> there is a need to ask for access tokens, which are good for multiple
> resources at once. This is a request type more or less exclusively used in
> server to server scenarios, right? So the only reason I can think of is
> call reduction.
>
> On the other side, this feature increases the AS's complexity, e.g. its
> policy may prohibit to issue tokens for multiple resources in general or
> the particular set the client is asking for. How shall the AS handles such
> cases?
>
> And it is getting even more complicated given there could also be multiple
> audience values and the client could mix them:
>
> I personally would suggest to drop support for multiple audience and
> resource parameters and make audience and resource mutual exclusive. I
> think this is sufficient and much easier to implement.
>
> kind regards,
> Torsten.
>
>
> Am 11.01.2017 um 20:04 schrieb Brian Campbell <[email-masked]
> >:
>
> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary
> change in -07 is the addition of a description of the relationship between
> audience/resource/scope, which was a request or comment that came up during
> the f2f meeting in Seoul.
>
> From: <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07
>
>
> until the htmlized version and diff are available at tools.ietf.org.
>
> ftp://ftp.ietf.org/internet-drafts/
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 27 Mar 2017 13:48:30 +0000

For the same reason that the “aud” claim is multi-valued in JWTs, the audience needs to stay multi-valued in Token Exchange.  Ditto for resources.

                                                       Thanks,
                                                       -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Monday, March 27, 2017 8:45 AM
To: Torsten Lodderstedt <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt

Thanks for the review and question, Torsten.
The desire to support multiple audience/resource values in the request came up during a review and discussion among the authors of the document when preparing the -03 draft. As I recall, it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for it into the draft acting in the role of editor.
From an individual perspective, I tend to agree with you that allowing for multiple audiences/resources adds a lot of complexity that's like not needed in many (or most) cases. And I would personally be open to making audience and resource mutual exclusive and single valued. A question for the WG I suppose.
The "invalid_target" error code that was added in -07 was intended to give the AS a standard way to deal with the complexity and reject request with multiple audiences/resources that it doesn't understand or is unwilling or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but provide an easy out of saying it can't be supported based on whatever implementation or policy of the AS.

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian,

kind regards,
Torsten.

Am 11.01.2017 um 20:04 schrieb Brian Campbell <[email-masked]<mailto:[email-masked]>>:

   -07

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 27 Mar 2017 11:35:26 -0500

May I ask you to explain this reason?

> Am 27.03.2017 um 08:48 schrieb Mike Jones <[email-masked]>:
> 
>   <>
> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Brian,
>  
> Am 11.01.2017 um 20:04 schrieb Brian Campbell <[email-masked] <mailto:[email-masked]>>:
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 28 Mar 2017 06:32:36 +0000

There are cases where tokens are supposed to be consumed at multiple places
and the `aud` needed to capture them. That's why `aud` is a multi-valued
field.

On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <
[email-masked]> wrote:

> For the same reason that the “aud” claim is multi-valued in JWTs, the
> audience needs to stay multi-valued in Token Exchange.  Ditto for resources.
>
>
>
>                                                        Thanks,
>
>                                                        -- Mike
>
>
>
> *From:* OAuth [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Brian Campbell
> *Sent:* Monday, March 27, 2017 8:45 AM
> *To:* Torsten Lodderstedt <[email-masked]>
> *Cc:* oauth <[email-masked]>
> *Subject:* Re: [OAUTH-WG] I-D Action:
> draft-ietf-oauth-token-exchange-07.txt
>
>
>
> The desire to support multiple audience/resource values in the request
> came up during a review and discussion among the authors of the document
> when preparing the -03 draft. As I recall, it was said that both Salesforce
> and Microsoft had use-cases for it. I incorporated support for it into the
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Denis <[email-masked]>
Date: Tue, 28 Mar 2017 09:57:40 +0200

The 'aud' parameter can be multi-value ... as long as it is advertised 
that there are advantages and drawbacks to do so.

The advantage is that a single token can be consumed by more than one 
server.

The drawback is that one of these servers, depending how the access 
token is protected, might be able to re-use
the token towards one of these other servers. This may be desirable of 
some cases, but not necessarily.

These advantages and drawbacks should be advertised in the main body of 
the document and/or in the security
considerations section.

According to the content of RFC 7800:

The "aud" (audience) claim identifies the recipients that the JWT is 
intended for.
The interpretation of audience values is application specific.

So the 'aud' parameter is not necessarily a" mix of logical names and 
physical locations".

If a fixed value is being used, e.g. a URL of the server, then the 
authorization server can easily know where the access tokens
will be used and thus is in a position to act as Big Brother. It is thus 
recommended to use a different value in the aud claims
for each access token that contains no semantics in it but that the 
resource server can easily recognize.

This should be advertised in a privacy considerations section.

Denis

> There are cases where tokens are supposed to be consumed at multiple 
> places and the `aud` needed to capture them. That's why `aud` is a 
> multi-valued field.
>
> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     Am 27.03.2017 um 08:48 schrieb Mike Jones
>>     <[email-masked] <mailto:[email-masked]>>:
>>
>>     For the same reason that the “aud” claim is multi-valued in JWTs,
>>     the audience needs to stay multi-valued in Token Exchange.  Ditto
>>     for resources.
>>
>>     Thanks,
>>
>>     -- Mike
>>
>>     *From:* OAuth [mailto:[email-masked]] *On Behalf Of
>>     *Brian Campbell
>>     *To:* Torsten Lodderstedt <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Cc:* oauth <[email-masked] <mailto:[email-masked]>>
>>     The desire to support multiple audience/resource values in the
>>     request came up during a review and discussion among the authors
>>     of the document when preparing the -03 draft. As I recall, it was
>>     said that both Salesforce and Microsoft had use-cases for it. I
>>     incorporated support for it into the draft acting in the role of
>>     editor.
>>
>>     From an individual perspective, I tend to agree with you that
>>     allowing for multiple audiences/resources adds a lot of
>>     complexity that's like not needed in many (or most) cases. And I
>>     would personally be open to making audience and resource mutual
>>     exclusive and single valued. A question for the WG I suppose.
>>
>>     The "invalid_target" error code that was added in -07 was
>>     intended to give the AS a standard way to deal with the
>>     complexity and reject request with multiple audiences/resources
>>     that it doesn't understand or is unwilling or unable to process.
>>     It was intended as a compromise, of sorts, to allow for the
>>     multiples but provide an easy out of saying it can't be supported
>>     based on whatever implementation or policy of the AS.
>>
>>     On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         Hi Brian,
>>
>>         Can you please explain the rational in more detail? I don’t
>>         understand why there is a need to ask for access tokens,
>>         which are good for multiple resources at once. This is a
>>         request type more or less exclusively used in server to
>>         server scenarios, right? So the only reason I can think of is
>>         call reduction.
>>
>>         On the other side, this feature increases the AS's
>>         complexity, e.g. its policy may prohibit to issue tokens for
>>         multiple resources in general or the particular set the
>>         client is asking for. How shall the AS handles such cases?
>>
>>         And it is getting even more complicated given there could
>>         also be multiple audience values and the client could mix them:
>>
>>         I personally would suggest to drop support for multiple
>>         audience and resource parameters and make audience and
>>         resource mutual exclusive. I think this is sufficient and
>>         much easier to implement.
>>
>>         kind regards,
>>
>>         Torsten.
>>
>>             <mailto:[email-masked]>>:
>>
>>             Draft -07 of "OAuth 2.0 Token Exchange" has been
>>             published. The primary change in -07 is the addition of a
>>             description of the relationship between
>>             audience/resource/scope, which was a request or comment
>>             that came up during the f2f meeting in Seoul.
>>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 31 Mar 2017 10:03:53 -0500

As mentioned during the Chicago meeting the "invalid_target" error code
that was added in -07 was intended to give the AS a standard way to reject
request with multiple audiences/resources that it doesn't understand or is
unwilling or unable to process based on policy or whatever criteria . It
was intended as a compromise, of sorts, to allow for the multiple
resources/audiences in the request but provide an easy out for the AS of
saying it can't be supported based on whatever implementation or security
or policy it has.

On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <[email-masked]> wrote:

>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-
>> exchange-07.txt
>>
>>
>>
>> From an individual perspective, I tend to agree with you that allowing
>> for multiple audiences/resources adds a lot of complexity that's like not
>> The "invalid_target" error code that was added in -07 was intended to
>> give the AS a standard way to deal with the complexity and reject request
>> with multiple audiences/resources that it doesn't understand or is
>> unwilling or unable to process. It was intended as a compromise, of sorts,
>> to allow for the multiples but provide an easy out of saying it can't be
>> supported based on whatever implementation or policy of the AS.
>>
>>
>>
>>
>>
>>
>>
>> Can you please explain the rational in more detail? I don’t understand
>> why there is a need to ask for access tokens, which are good for multiple
>> And it is getting even more complicated given there could also be
>> multiple audience values and the client could mix them:
>>
>>
>>