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

[i***@ietf.org]

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/

There's also a htmlized version available at:
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


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

[Brian Campbell]

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: <internet-***@ietf.org>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
To: i-d-***@ietf.org
Cc: ***@ietf.org



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/

There's also a htmlized version available at:
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


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

[Torsten Lodderstedt]

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.

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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
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
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/>
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07 <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07>
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/>.
ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

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 <

Hi Brian,
thanks for the clarification around resource, audience and scope.
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
"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.
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
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
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.
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Mike Jones]

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:oauth-***@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, March 27, 2017 8:45 AM
To: Torsten Lodderstedt <***@lodderstedt.net>
Cc: oauth <***@ietf.org>
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 <***@lodderstedt.net<mailto:***@lodderstedt.net>> wrote:
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 <***@pingidentity.com<mailto:***@pingidentity.com>>:

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: <internet-***@ietf.org<mailto:internet-***@ietf.org>>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
To: i-d-***@ietf.org<mailto:i-d-***@ietf.org>
Cc: ***@ietf.org<mailto:***@ietf.org>



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/

There's also a htmlized version available at:
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


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/

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

[Torsten Lodderstedt]

May I ask you to explain this reason?

Post by Mike Jones
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
  <>
Sent: Monday, March 27, 2017 8:45 AM
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.
Hi Brian,
thanks for the clarification around resource, audience and scope.
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?
"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.
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
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
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/>
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07 <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07>
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/>.
ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[Nat Sakimura]

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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
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
Behalf Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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
"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.
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
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
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.
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Denis]

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

Post by Nat Sakimura
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
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones
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
*Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
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
Hi Brian,
thanks for the clarification around resource, audience and scope.
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
"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
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
draft-ietf-oauth-token-exchange-07.txt
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
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.
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
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/>.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

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.

Post by Nat Sakimura
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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
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
Behalf Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
*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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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" 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.
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
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
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.
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Rifaat Shekh-Yusef]

Hi All,

The last email from Brian addresses the multiple audiences/resources issue
with an error code, and we did not see any objection to this approach so
far.


*Authors,*

Are there any other open issues with this draft?
Do you believe it is ready for WGLC?

Thanks,
Rifaat & Hannes

Post by Brian Campbell
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.

Post by Nat Sakimura
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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
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
Behalf Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
*Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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" 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 <
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
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
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.
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

I do have one minor issue I'd like to raise that relates to some
conversations I've been a party to recently about implementations and
applications of token exchange.

I think that the current text in §2.1 for the "actor_token" is overly
specific towards the delegation scenario. I'd propose the language be
generalized somewhat to allow more versatility in applications/deployments
of the token exchange framework. Here's that text:

actor_token
OPTIONAL. A security token that represents the identity of the
acting party.

Post by Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple audiences/resources issue
with an error code, and we did not see any objection to this approach so
far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <

Post by Brian Campbell
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.

Post by Nat Sakimura
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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
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
Behalf Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
*Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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" 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 <
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
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
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.
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Denis]

Brian,

The current text is:

actor_token OPTIONAL. A security token that represents the identity of
the party that is authorized to use the requested security token and act
on behalf of the subject.

This sentence is indeed wrong since an actor-token is not a security token.

So your proposed change does not solve this issue: actor_token
OPTIONAL. A security token that represents the identity of the acting
party.

The current text states:

Typically, in the request, the subject_token represents the identity
of the party on behalf of whom
the token is being requested while the actor_token represents the
identity of the party to whom the access
rights of the issued token are being delegated.

Logically, the definition should be along the following lines:

actor_token OPTIONAL. Indicates the identity of the party to whom the
access rights of the issued token are being delegated.

If there is no delegation, then this field (which is optional) will not
be used.

Anyway, thank you for requesting the change, otherwise this would have
been a left error.

Denis

Post by Brian Campbell
I do have one minor issue I'd like to raise that relates to some
conversations I've been a party to recently about implementations and
applications of token exchange.
I think that the current text in §2.1 for the "actor_token" is overly
specific towards the delegation scenario. I'd propose the language be
generalized somewhat to allow more versatility in
applications/deployments of the token exchange framework. Here's that
actor_token
OPTIONAL. A security token that represents the identity of the
acting party.
On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple
audiences/resources issue with an error code, and we did not see
any objection to this approach so far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell
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
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
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones
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
Behalf Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
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
Hi Brian,
thanks for the clarification around resource,
audience and scope.
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
"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
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
draft-ietf-oauth-token-exchange-07.txt
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
draft-ietf-oauth-token-exchange-07.txt
Pages : 31
Date : 2017-01-11
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
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
<https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/>
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07>
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
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

The actor_token is a security token so that's not an issue that needs to be
addressed.

Post by Torsten Lodderstedt
Brian,
actor_token OPTIONAL. A security token that represents the identity of the
party that is authorized to use the requested security token and act on
behalf of the subject.
This sentence is indeed wrong since an actor-token is not a security token.
So your proposed change does not solve this issue: actor_token
OPTIONAL. A security token that represents the identity of the acting
party.
Typically, in the request, the subject_token represents the identity of
the party on behalf of whom
the token is being requested while the actor_token represents the identity
of the party to whom the access
rights of the issued token are being delegated.
actor_token OPTIONAL. Indicates the identity of the party to whom the
access rights of the issued token are being delegated.
If there is no delegation, then this field (which is optional) will not be
used.
Anyway, thank you for requesting the change, otherwise this would have
been a left error.
Denis
I do have one minor issue I'd like to raise that relates to some
conversations I've been a party to recently about implementations and
applications of token exchange.
I think that the current text in §2.1 for the "actor_token" is overly
specific towards the delegation scenario. I'd propose the language be
generalized somewhat to allow more versatility in applications/deployments
actor_token
OPTIONAL. A security token that represents the identity of the
acting party.

Post by Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple audiences/resources
issue with an error code, and we did not see any objection to this approach
so far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <

Post by Brian Campbell
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.

Post by Nat Sakimura
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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
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
*On Behalf Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
*Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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" 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 <
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
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
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.
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

Let me throw out a bit more context about this. The "actor_token" might, in
a delegation scenario, represent the identity of the party to whom the
access rights of the issued token are being delegated. That's the typical
delegation scenario that is discussed in the draft. However, the
"actor_token" might also be utilized/needed by the AS in an impersonation
scenario for policy or auditing reasons even when the resulting issued
token doesn't contain info about the delegation or actor. Similarly, the
actor might not be strictly doing the impersonation but rather just be a
party (again maybe needed for policy or auditing) to the token exchange
event itself. When I wrote the "actor_token" text in section 2.1 some ~18
months ago I had the delegation scenario at the front of my mind and
(clearly) intended to accommodate it. However, I didn't intend to limit it
to only that and, looking at the text again, I think what is there now is
too prescriptive and narrow. Thus my proposing to generalize the text
somewhat.

Post by Brian Campbell
I do have one minor issue I'd like to raise that relates to some
conversations I've been a party to recently about implementations and
applications of token exchange.
I think that the current text in §2.1 for the "actor_token" is overly
specific towards the delegation scenario. I'd propose the language be
generalized somewhat to allow more versatility in applications/deployments
actor_token
OPTIONAL. A security token that represents the identity of the
acting party.

Post by Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple audiences/resources
issue with an error code, and we did not see any objection to this approach
so far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <

Post by Brian Campbell
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.

Post by Nat Sakimura
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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
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
*On Behalf Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
*Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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" 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 <
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
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
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.
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Denis]

Brian,

You omitted to include my comments in this post. So here it is again:

===========================================================

The current text is:

actor_token OPTIONAL. A security token that represents the identity of
the party that is authorized to use the requested security token and act
on behalf of the subject.

This sentence is indeed wrong since an actor-token is not a security token.

So your proposed change does not solve this issue: actor_token
OPTIONAL. A security token that represents the identity of the acting
party.

The current text states:

Typically, in the request, the subject_token represents the identity
of the party on behalf of whom
the token is being requested while the actor_token represents the
identity of the party to whom the access
rights of the issued token are being delegated.

Logically, the definition should be along the following lines:

actor_token OPTIONAL. Indicates the identity of the party to whom the
access rights of the issued token are being delegated.

If there is no delegation, then this field (which is optional) will not
be used.

===========================================================

I read your argumentation, but I maintain my comment. Each field should
have a precise semantics.

If you want to have another semantics, you should propose to define
another field with its precise meaning.

Denis

Post by Brian Campbell
Let me throw out a bit more context about this. The "actor_token"
might, in a delegation scenario, represent the identity of the party
to whom the access rights of the issued token are being delegated.
That's the typical delegation scenario that is discussed in the draft.
However, the "actor_token" might also be utilized/needed by the AS in
an impersonation scenario for policy or auditing reasons even when the
resulting issued token doesn't contain info about the delegation or
actor. Similarly, the actor might not be strictly doing the
impersonation but rather just be a party (again maybe needed for
the "actor_token" text in section 2.1 some ~18 months ago I had the
delegation scenario at the front of my mind and (clearly) intended to
accommodate it. However, I didn't intend to limit it to only that and,
looking at the text again, I think what is there now is too
prescriptive and narrow. Thus my proposing to generalize the text
somewhat.
On Mon, May 8, 2017 at 10:29 AM, Brian Campbell
I do have one minor issue I'd like to raise that relates to some
conversations I've been a party to recently about implementations
and applications of token exchange.
I think that the current text in §2.1 for the "actor_token" is
overly specific towards the delegation scenario. I'd propose the
language be generalized somewhat to allow more versatility in
applications/deployments of the token exchange framework. Here's
actor_token
OPTIONAL. A security token that represents the identity of the
acting party.
On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple
audiences/resources issue with an error code, and we did not
see any objection to this approach so far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell
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
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
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones
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
Behalf Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
*To:* Torsten Lodderstedt
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
Hi Brian,
thanks for the clarification around resource,
audience and scope.
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
"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
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
draft-ietf-oauth-token-exchange-07.txt
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
draft-ietf-oauth-token-exchange-07.txt
Pages : 31
Date : 2017-01-11
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
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
<https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/>
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
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
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

Yes, I omitted your comments in that post because I'd previously replied to
you in a separate message where I said that the "actor_token is a security
token so that's not an issue that needs to be addressed."
https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html

The other point you've just made about having very precise semantics for a
field is a fair one. However, I wanted to avoid introducing yet another
field (or really two fields b/c of the associated *_type for each inbound
token field), for what felt like a minor semantic variation that could be
easily accommodated by the existing framework, to the draft that already
has a lot of options and parameters on the request. And Token Exchange
really is a framework. I think that, to some extent, the framework is a bit
of a Rorschach test for deployers and implementers to utilize to solve
their specific issues and needs. I expect that will be the case regardless.
And I am proposing to somewhat genericize the text around one request
parameter to be more reflective of that.

I would like to hear from others in the WG though.

Post by Torsten Lodderstedt
Brian,
===========================================================
actor_token OPTIONAL. A security token that represents the identity of the
party that is authorized to use the requested security token and act on
behalf of the subject.
This sentence is indeed wrong since an actor-token is not a security token.
So your proposed change does not solve this issue: actor_token
OPTIONAL. A security token that represents the identity of the acting
party.
Typically, in the request, the subject_token represents the identity of
the party on behalf of whom
the token is being requested while the actor_token represents the identity
of the party to whom the access
rights of the issued token are being delegated.
actor_token OPTIONAL. Indicates the identity of the party to whom the
access rights of the issued token are being delegated.
If there is no delegation, then this field (which is optional) will not be
used.
===========================================================
I read your argumentation, but I maintain my comment. Each field should
have a precise semantics.
If you want to have another semantics, you should propose to define
another field with its precise meaning.
Denis
Let me throw out a bit more context about this. The "actor_token" might,
in a delegation scenario, represent the identity of the party to whom the
access rights of the issued token are being delegated. That's the typical
delegation scenario that is discussed in the draft. However, the
"actor_token" might also be utilized/needed by the AS in an impersonation
scenario for policy or auditing reasons even when the resulting issued
token doesn't contain info about the delegation or actor. Similarly, the
actor might not be strictly doing the impersonation but rather just be a
party (again maybe needed for policy or auditing) to the token exchange
event itself. When I wrote the "actor_token" text in section 2.1 some ~18
months ago I had the delegation scenario at the front of my mind and
(clearly) intended to accommodate it. However, I didn't intend to limit it
to only that and, looking at the text again, I think what is there now is
too prescriptive and narrow. Thus my proposing to generalize the text
somewhat.
On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <

Post by Brian Campbell
I do have one minor issue I'd like to raise that relates to some
conversations I've been a party to recently about implementations and
applications of token exchange.
I think that the current text in §2.1 for the "actor_token" is overly
specific towards the delegation scenario. I'd propose the language be
generalized somewhat to allow more versatility in applications/deployments
actor_token
OPTIONAL. A security token that represents the identity of the
acting party.

Post by Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple audiences/resources
issue with an error code, and we did not see any objection to this approach
so far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <

Post by Brian Campbell
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.

Post by Nat Sakimura
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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
Am 27.03.2017 um 08:48 schrieb Mike Jones <
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
*On Behalf Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
*Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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" 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 <
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-07.txt
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
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.
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Denis]

Brian,

Even if Token Exchange is a framework, the goal is to be finally able to
interoperate.

Whether we have one or two parameters, would you be able to provide a
precise semantics for the "other case" you have in mind ?

Denis

Post by Brian Campbell
Yes, I omitted your comments in that post because I'd previously
replied to you in a separate message where I said that the
"actor_token is a security token so that's not an issue that needs to
be addressed."
https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html
<https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html>
The other point you've just made about having very precise semantics
for a field is a fair one. However, I wanted to avoid introducing yet
another field (or really two fields b/c of the associated *_type for
each inbound token field), for what felt like a minor semantic
variation that could be easily accommodated by the existing framework,
to the draft that already has a lot of options and parameters on the
request. And Token Exchange really is a framework. I think that, to
some extent, the framework is a bit of a Rorschach test for deployers
and implementers to utilize to solve their specific issues and needs.
I expect that will be the case regardless. And I am proposing to
somewhat genericize the text around one request parameter to be more
reflective of that.
I would like to hear from others in the WG though.
Brian,
===========================================================
actor_token OPTIONAL. A security token that represents the
identity of the party that is authorized to use the requested
security token and act on behalf of the subject.
This sentence is indeed wrong since an actor-token is not a security token.
So your proposed change does not solve this issue: actor_token
OPTIONAL. A security token that represents the identity of the
acting party.
Typically, in the request, the subject_token represents the
identity of the party on behalf of whom
the token is being requested while the actor_token represents
the identity of the party to whom the access
rights of the issued token are being delegated.
actor_token OPTIONAL. Indicates the identity of the party to whom
the access rights of the issued token are being delegated.
If there is no delegation, then this field (which is optional)
will not be used.
===========================================================
I read your argumentation, but I maintain my comment. Each field
should have a precise semantics.
If you want to have another semantics, you should propose to
define another field with its precise meaning.
Denis

Post by Brian Campbell
Let me throw out a bit more context about this. The "actor_token"
might, in a delegation scenario, represent the identity of the
party to whom the access rights of the issued token are being
delegated. That's the typical delegation scenario that is
discussed in the draft. However, the "actor_token" might also be
utilized/needed by the AS in an impersonation scenario for policy
or auditing reasons even when the resulting issued token doesn't
contain info about the delegation or actor. Similarly, the actor
might not be strictly doing the impersonation but rather just be
a party (again maybe needed for policy or auditing) to the token
exchange event itself. When I wrote the "actor_token" text in
section 2.1 some ~18 months ago I had the delegation scenario at
the front of my mind and (clearly) intended to accommodate it.
However, I didn't intend to limit it to only that and, looking at
the text again, I think what is there now is too prescriptive and
narrow. Thus my proposing to generalize the text somewhat.
On Mon, May 8, 2017 at 10:29 AM, Brian Campbell
I do have one minor issue I'd like to raise that relates to
some conversations I've been a party to recently about
implementations and applications of token exchange.
I think that the current text in §2.1 for the "actor_token"
is overly specific towards the delegation scenario. I'd
propose the language be generalized somewhat to allow more
versatility in applications/deployments of the token exchange
actor_token
OPTIONAL. A security token that represents the
identity of the
acting party.
On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple
audiences/resources issue with an error code, and we did
not see any objection to this approach so far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell
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
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
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones
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
Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
*To:* Torsten Lodderstedt
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
Hi Brian,
thanks for the clarification around
resource, audience and scope.
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
"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
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
draft-ietf-oauth-token-exchange-07.txt
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
draft-ietf-oauth-token-exchange-07.txt
Pages : 31
Date : 2017-01-11
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
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
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
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
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________ OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>

[Brian Campbell]

The token exchange framework facilitates deployments like this one
https://help.salesforce.com/articleView?id=remoteaccess_oaut
h_asset_token_flow.htm or https://developer.box.com/docs
/getting-started-with-new-box-view, for example, and I don't think pure
plug and play interoperability is a realistic goal. The framework promotes
interoperability in the form of common patterns and parameters that can be
supported in libraries, products, and services.

There's not one "other case" I have in mind but rather just broadening the
text somewhat to more straightforwardly accommodate other cases. One
potential example is where the actor_token represents an authorizing party
(again maybe needed for policy or auditing) to the token exchange event
itself rather than the party that's having access rights assigned to it
(implicitly with impersonation or explicitly with delegation).

Post by Torsten Lodderstedt
Brian,
Even if Token Exchange is a framework, the goal is to be finally able to
interoperate.
Whether we have one or two parameters, would you be able to provide a
precise semantics for the "other case" you have in mind ?
Denis
Yes, I omitted your comments in that post because I'd previously replied
to you in a separate message where I said that the "actor_token is a
security token so that's not an issue that needs to be addressed."
https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html
The other point you've just made about having very precise semantics for a
field is a fair one. However, I wanted to avoid introducing yet another
field (or really two fields b/c of the associated *_type for each inbound
token field), for what felt like a minor semantic variation that could be
easily accommodated by the existing framework, to the draft that already
has a lot of options and parameters on the request. And Token Exchange
really is a framework. I think that, to some extent, the framework is a bit
of a Rorschach test for deployers and implementers to utilize to solve
their specific issues and needs. I expect that will be the case regardless.
And I am proposing to somewhat genericize the text around one request
parameter to be more reflective of that.
I would like to hear from others in the WG though.

Post by Torsten Lodderstedt
Brian,
===========================================================
actor_token OPTIONAL. A security token that represents the identity of
the party that is authorized to use the requested security token and act on
behalf of the subject.
This sentence is indeed wrong since an actor-token is not a security token.
So your proposed change does not solve this issue: actor_token
OPTIONAL. A security token that represents the identity of the acting
party.
Typically, in the request, the subject_token represents the identity of
the party on behalf of whom
the token is being requested while the actor_token represents the
identity of the party to whom the access
rights of the issued token are being delegated.
actor_token OPTIONAL. Indicates the identity of the party to whom the
access rights of the issued token are being delegated.
If there is no delegation, then this field (which is optional) will not
be used.
===========================================================
I read your argumentation, but I maintain my comment. Each field should
have a precise semantics.
If you want to have another semantics, you should propose to define
another field with its precise meaning.
Denis
Let me throw out a bit more context about this. The "actor_token" might,
in a delegation scenario, represent the identity of the party to whom the
access rights of the issued token are being delegated. That's the typical
delegation scenario that is discussed in the draft. However, the
"actor_token" might also be utilized/needed by the AS in an impersonation
scenario for policy or auditing reasons even when the resulting issued
token doesn't contain info about the delegation or actor. Similarly, the
actor might not be strictly doing the impersonation but rather just be a
party (again maybe needed for policy or auditing) to the token exchange
event itself. When I wrote the "actor_token" text in section 2.1 some ~18
months ago I had the delegation scenario at the front of my mind and
(clearly) intended to accommodate it. However, I didn't intend to limit it
to only that and, looking at the text again, I think what is there now is
too prescriptive and narrow. Thus my proposing to generalize the text
somewhat.
On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <

Post by Brian Campbell
I do have one minor issue I'd like to raise that relates to some
conversations I've been a party to recently about implementations and
applications of token exchange.
I think that the current text in §2.1 for the "actor_token" is overly
specific towards the delegation scenario. I'd propose the language be
generalized somewhat to allow more versatility in applications/deployments
actor_token
OPTIONAL. A security token that represents the identity of the
acting party.
On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <

Post by Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple audiences/resources
issue with an error code, and we did not see any objection to this approach
so far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <

Post by Brian Campbell
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.

Post by Nat Sakimura
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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
Am 27.03.2017 um 08:48 schrieb Mike Jones <
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
*Sent:* Monday, March 27, 2017 8:45 AM
*Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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" 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 <
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-07.txt
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
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.
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

...

[Message clipped]

[Brian Campbell]

Following up on this, I'd like to propose a different and less invasive
change to the "actor_token" text. The new wording is below and not much
different than the text in the current draft. Barring any solid objections
to this in the next week or so, I'll publish -08 at which point I believe
the document will be ready for WGLC.

actor_token

OPTIONAL. A security token that represents the identity of the acting
party. Typically this will be the party that is authorized to use the
requested security token and act on behalf of the subject.

Post by Brian Campbell
The token exchange framework facilitates deployments like this one
https://help.salesforce.com/articleView?id=remoteaccess_oaut
h_asset_token_flow.htm or https://developer.box.com/docs
/getting-started-with-new-box-view, for example, and I don't think pure
plug and play interoperability is a realistic goal. The framework promotes
interoperability in the form of common patterns and parameters that can be
supported in libraries, products, and services.
There's not one "other case" I have in mind but rather just broadening the
text somewhat to more straightforwardly accommodate other cases. One
potential example is where the actor_token represents an authorizing party
(again maybe needed for policy or auditing) to the token exchange event
itself rather than the party that's having access rights assigned to it
(implicitly with impersonation or explicitly with delegation).

Post by Torsten Lodderstedt
Brian,
Even if Token Exchange is a framework, the goal is to be finally able to
interoperate.
Whether we have one or two parameters, would you be able to provide a
precise semantics for the "other case" you have in mind ?
Denis
Yes, I omitted your comments in that post because I'd previously replied
to you in a separate message where I said that the "actor_token is a
security token so that's not an issue that needs to be addressed."
https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html
The other point you've just made about having very precise semantics for
a field is a fair one. However, I wanted to avoid introducing yet another
field (or really two fields b/c of the associated *_type for each inbound
token field), for what felt like a minor semantic variation that could be
easily accommodated by the existing framework, to the draft that already
has a lot of options and parameters on the request. And Token Exchange
really is a framework. I think that, to some extent, the framework is a bit
of a Rorschach test for deployers and implementers to utilize to solve
their specific issues and needs. I expect that will be the case regardless.
And I am proposing to somewhat genericize the text around one request
parameter to be more reflective of that.
I would like to hear from others in the WG though.

Post by Torsten Lodderstedt
Brian,
===========================================================
actor_token OPTIONAL. A security token that represents the identity of
the party that is authorized to use the requested security token and act on
behalf of the subject.
This sentence is indeed wrong since an actor-token is not a security token.
So your proposed change does not solve this issue: actor_token
OPTIONAL. A security token that represents the identity of the acting
party.
Typically, in the request, the subject_token represents the identity of
the party on behalf of whom
the token is being requested while the actor_token represents the
identity of the party to whom the access
rights of the issued token are being delegated.
actor_token OPTIONAL. Indicates the identity of the party to whom the
access rights of the issued token are being delegated.
If there is no delegation, then this field (which is optional) will not
be used.
===========================================================
I read your argumentation, but I maintain my comment. Each field should
have a precise semantics.
If you want to have another semantics, you should propose to define
another field with its precise meaning.
Denis
Let me throw out a bit more context about this. The "actor_token" might,
in a delegation scenario, represent the identity of the party to whom the
access rights of the issued token are being delegated. That's the typical
delegation scenario that is discussed in the draft. However, the
"actor_token" might also be utilized/needed by the AS in an impersonation
scenario for policy or auditing reasons even when the resulting issued
token doesn't contain info about the delegation or actor. Similarly, the
actor might not be strictly doing the impersonation but rather just be a
party (again maybe needed for policy or auditing) to the token exchange
event itself. When I wrote the "actor_token" text in section 2.1 some ~18
months ago I had the delegation scenario at the front of my mind and
(clearly) intended to accommodate it. However, I didn't intend to limit it
to only that and, looking at the text again, I think what is there now is
too prescriptive and narrow. Thus my proposing to generalize the text
somewhat.
On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <

Post by Brian Campbell
I do have one minor issue I'd like to raise that relates to some
conversations I've been a party to recently about implementations and
applications of token exchange.
I think that the current text in §2.1 for the "actor_token" is overly
specific towards the delegation scenario. I'd propose the language be
generalized somewhat to allow more versatility in applications/deployments
actor_token
OPTIONAL. A security token that represents the identity of the
acting party.
On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <

Post by Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple audiences/resources
issue with an error code, and we did not see any objection to this approach
so far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <

Post by Brian Campbell
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.

Post by Nat Sakimura
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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
Am 27.03.2017 um 08:48 schrieb Mike Jones <
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
*Sent:* Monday, March 27, 2017 8:45 AM
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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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" 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 <
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-07.txt
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
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.
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-exc
hange-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
.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

...

[Message clipped]

[Rifaat Shekh-Yusef]

Brian,

We did not see any objection to this latest proposal.

Can you please go ahead and publish version -08 of the draft?
We would like to start a WGLC on the new version.

Regards,
Rifaat

Post by Brian Campbell
Following up on this, I'd like to propose a different and less invasive
change to the "actor_token" text. The new wording is below and not much
different than the text in the current draft. Barring any solid objections
to this in the next week or so, I'll publish -08 at which point I believe
the document will be ready for WGLC.
actor_token
OPTIONAL. A security token that represents the identity of the acting
party. Typically this will be the party that is authorized to use the
requested security token and act on behalf of the subject.
On Thu, May 11, 2017 at 9:58 AM, Brian Campbell <

Post by Brian Campbell
The token exchange framework facilitates deployments like this one
https://help.salesforce.com/articleView?id=remoteaccess_oaut
h_asset_token_flow.htm or https://developer.box.com/docs
/getting-started-with-new-box-view, for example, and I don't think pure
plug and play interoperability is a realistic goal. The framework promotes
interoperability in the form of common patterns and parameters that can be
supported in libraries, products, and services.
There's not one "other case" I have in mind but rather just broadening
the text somewhat to more straightforwardly accommodate other cases. One
potential example is where the actor_token represents an authorizing party
(again maybe needed for policy or auditing) to the token exchange event
itself rather than the party that's having access rights assigned to it
(implicitly with impersonation or explicitly with delegation).

Post by Torsten Lodderstedt
Brian,
Even if Token Exchange is a framework, the goal is to be finally able to
interoperate.
Whether we have one or two parameters, would you be able to provide a
precise semantics for the "other case" you have in mind ?
Denis
Yes, I omitted your comments in that post because I'd previously replied
to you in a separate message where I said that the "actor_token is a
security token so that's not an issue that needs to be addressed."
https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html
The other point you've just made about having very precise semantics for
a field is a fair one. However, I wanted to avoid introducing yet another
field (or really two fields b/c of the associated *_type for each inbound
token field), for what felt like a minor semantic variation that could be
easily accommodated by the existing framework, to the draft that already
has a lot of options and parameters on the request. And Token Exchange
really is a framework. I think that, to some extent, the framework is a bit
of a Rorschach test for deployers and implementers to utilize to solve
their specific issues and needs. I expect that will be the case regardless.
And I am proposing to somewhat genericize the text around one request
parameter to be more reflective of that.
I would like to hear from others in the WG though.

Post by Torsten Lodderstedt
Brian,
===========================================================
actor_token OPTIONAL. A security token that represents the identity of
the party that is authorized to use the requested security token and act on
behalf of the subject.
This sentence is indeed wrong since an actor-token is not a security token.
So your proposed change does not solve this issue: actor_token
OPTIONAL. A security token that represents the identity of the acting
party.
Typically, in the request, the subject_token represents the identity of
the party on behalf of whom
the token is being requested while the actor_token represents the
identity of the party to whom the access
rights of the issued token are being delegated.
actor_token OPTIONAL. Indicates the identity of the party to whom the
access rights of the issued token are being delegated.
If there is no delegation, then this field (which is optional) will not
be used.
===========================================================
I read your argumentation, but I maintain my comment. Each field should
have a precise semantics.
If you want to have another semantics, you should propose to define
another field with its precise meaning.
Denis
Let me throw out a bit more context about this. The "actor_token"
might, in a delegation scenario, represent the identity of the party to
whom the access rights of the issued token are being delegated. That's the
typical delegation scenario that is discussed in the draft. However, the
"actor_token" might also be utilized/needed by the AS in an impersonation
scenario for policy or auditing reasons even when the resulting issued
token doesn't contain info about the delegation or actor. Similarly, the
actor might not be strictly doing the impersonation but rather just be a
party (again maybe needed for policy or auditing) to the token exchange
event itself. When I wrote the "actor_token" text in section 2.1 some ~18
months ago I had the delegation scenario at the front of my mind and
(clearly) intended to accommodate it. However, I didn't intend to limit it
to only that and, looking at the text again, I think what is there now is
too prescriptive and narrow. Thus my proposing to generalize the text
somewhat.
On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <

Post by Brian Campbell
I do have one minor issue I'd like to raise that relates to some
conversations I've been a party to recently about implementations and
applications of token exchange.
I think that the current text in §2.1 for the "actor_token" is overly
specific towards the delegation scenario. I'd propose the language be
generalized somewhat to allow more versatility in applications/deployments
actor_token
OPTIONAL. A security token that represents the identity of the
acting party.
On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <

Post by Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple audiences/resources
issue with an error code, and we did not see any objection to this approach
so far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <

Post by Brian Campbell
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.

Post by Nat Sakimura
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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
Am 27.03.2017 um 08:48 schrieb Mike Jones <
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
*Sent:* Monday, March 27, 2017 8:45 AM
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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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" 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 <
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-07.txt
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
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07>
...

[Message clipped]
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

Sure thing Rifaat, here it is:
https://mailarchive.ietf.org/arch/msg/oauth/svrY2VEiYAJClftN8y1oQ1p4rVw

Post by Torsten Lodderstedt
Brian,
We did not see any objection to this latest proposal.
Can you please go ahead and publish version -08 of the draft?
We would like to start a WGLC on the new version.
Regards,
Rifaat
On Fri, May 26, 2017 at 6:21 PM, Brian Campbell <

Post by Brian Campbell
Following up on this, I'd like to propose a different and less invasive
change to the "actor_token" text. The new wording is below and not much
different than the text in the current draft. Barring any solid objections
to this in the next week or so, I'll publish -08 at which point I believe
the document will be ready for WGLC.
actor_token
OPTIONAL. A security token that represents the identity of the acting
party. Typically this will be the party that is authorized to use the
requested security token and act on behalf of the subject.
On Thu, May 11, 2017 at 9:58 AM, Brian Campbell <

Post by Brian Campbell
The token exchange framework facilitates deployments like this one
https://help.salesforce.com/articleView?id=remoteaccess_oaut
h_asset_token_flow.htm or https://developer.box.com/docs
/getting-started-with-new-box-view, for example, and I don't think pure
plug and play interoperability is a realistic goal. The framework promotes
interoperability in the form of common patterns and parameters that can be
supported in libraries, products, and services.
There's not one "other case" I have in mind but rather just broadening
the text somewhat to more straightforwardly accommodate other cases. One
potential example is where the actor_token represents an authorizing party
(again maybe needed for policy or auditing) to the token exchange event
itself rather than the party that's having access rights assigned to it
(implicitly with impersonation or explicitly with delegation).

Post by Torsten Lodderstedt
Brian,
Even if Token Exchange is a framework, the goal is to be finally able
to interoperate.
Whether we have one or two parameters, would you be able to provide a
precise semantics for the "other case" you have in mind ?
Denis
Yes, I omitted your comments in that post because I'd previously
replied to you in a separate message where I said that the "actor_token is
a security token so that's not an issue that needs to be addressed."
https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html
The other point you've just made about having very precise semantics
for a field is a fair one. However, I wanted to avoid introducing yet
another field (or really two fields b/c of the associated *_type for each
inbound token field), for what felt like a minor semantic variation that
could be easily accommodated by the existing framework, to the draft that
already has a lot of options and parameters on the request. And Token
Exchange really is a framework. I think that, to some extent, the framework
is a bit of a Rorschach test for deployers and implementers to utilize to
solve their specific issues and needs. I expect that will be the case
regardless. And I am proposing to somewhat genericize the text around one
request parameter to be more reflective of that.
I would like to hear from others in the WG though.

Post by Torsten Lodderstedt
Brian,
===========================================================
actor_token OPTIONAL. A security token that represents the identity of
the party that is authorized to use the requested security token and act on
behalf of the subject.
This sentence is indeed wrong since an actor-token is not a security token.
So your proposed change does not solve this issue: actor_token
OPTIONAL. A security token that represents the identity of the acting
party.
Typically, in the request, the subject_token represents the identity
of the party on behalf of whom
the token is being requested while the actor_token represents the
identity of the party to whom the access
rights of the issued token are being delegated.
actor_token OPTIONAL. Indicates the identity of the party to whom
the access rights of the issued token are being delegated.
If there is no delegation, then this field (which is optional) will
not be used.
===========================================================
I read your argumentation, but I maintain my comment. Each field
should have a precise semantics.
If you want to have another semantics, you should propose to define
another field with its precise meaning.
Denis
Let me throw out a bit more context about this. The "actor_token"
might, in a delegation scenario, represent the identity of the party to
whom the access rights of the issued token are being delegated. That's the
typical delegation scenario that is discussed in the draft. However, the
"actor_token" might also be utilized/needed by the AS in an impersonation
scenario for policy or auditing reasons even when the resulting issued
token doesn't contain info about the delegation or actor. Similarly, the
actor might not be strictly doing the impersonation but rather just be a
party (again maybe needed for policy or auditing) to the token exchange
event itself. When I wrote the "actor_token" text in section 2.1 some ~18
months ago I had the delegation scenario at the front of my mind and
(clearly) intended to accommodate it. However, I didn't intend to limit it
to only that and, looking at the text again, I think what is there now is
too prescriptive and narrow. Thus my proposing to generalize the text
somewhat.
On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <

Post by Brian Campbell
I do have one minor issue I'd like to raise that relates to some
conversations I've been a party to recently about implementations and
applications of token exchange.
I think that the current text in §2.1 for the "actor_token" is overly
specific towards the delegation scenario. I'd propose the language be
generalized somewhat to allow more versatility in applications/deployments
actor_token
OPTIONAL. A security token that represents the identity of the
acting party.
On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <

Post by Rifaat Shekh-Yusef
Hi All,
The last email from Brian addresses the multiple audiences/resources
issue with an error code, and we did not see any objection to this approach
so far.
*Authors,*
Are there any other open issues with this draft?
Do you believe it is ready for WGLC?
Thanks,
Rifaat & Hannes
On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <

Post by Brian Campbell
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.

Post by Nat Sakimura
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 <

Post by Torsten Lodderstedt
May I ask you to explain this reason?
Am 27.03.2017 um 08:48 schrieb Mike Jones <
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
*Sent:* Monday, March 27, 2017 8:45 AM
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 <
Hi Brian,
thanks for the clarification around resource, audience and scope.
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" 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 <
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.
-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 ----------
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
e-07.txt
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
...

[Message clipped]