For the same reason that the “aud” claim is multi-valued in JWTs, the audience
needs to stay multi-valued in Token Exchange. Ditto for resources.
Thanks,
-- Mike
From: OAuth [mailto:[email protected]] On Behalf Of Brian Campbell
Sent: Monday, March 27, 2017 8:45 AM
To: Torsten Lodderstedt <[email protected]>
Cc: oauth <[email protected]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
Thanks for the review and question, Torsten.
The desire to support multiple audience/resource values in the request came up
during a review and discussion among the authors of the document when preparing
the -03 draft. As I recall, it was said that both Salesforce and Microsoft had
use-cases for it. I incorporated support for it into the draft acting in the
role of editor.
From an individual perspective, I tend to agree with you that allowing for
multiple audiences/resources adds a lot of complexity that's like not needed in
many (or most) cases. And I would personally be open to making audience and
resource mutual exclusive and single valued. A question for the WG I suppose.
The "invalid_target" error code that was added in -07 was intended to give the
AS a standard way to deal with the complexity and reject request with multiple
audiences/resources that it doesn't understand or is unwilling or unable to
process. It was intended as a compromise, of sorts, to allow for the multiples
but provide an easy out of saying it can't be supported based on whatever
implementation or policy of the AS.
On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>>:
Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary change
in -07 is the addition of a description of the relationship between
audience/resource/scope, which was a request or comment that came up during the
f2f meeting in Seoul.
Excerpted from the Document History:
-07
o Fixed typo (desecration -> discretion).
o Added an explanation of the relationship between scope, audience
and resource in the request and added an "invalid_target" error
code enabling the AS to tell the client that the requested
audiences/resources were too broad.
---------- Forwarded message ----------
From: <[email protected]<mailto:[email protected]>>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
