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
<[email protected] <mailto:[email protected]>>
wrote:
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.
On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef
<[email protected] <mailto:[email protected]>> wrote:
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
<[email protected]
<mailto:[email protected]>> wrote:
As mentioned during the Chicago meeting the
"invalid_target" error code that was added in -07 was
intended to give the AS a standard way to reject
request with multiple audiences/resources that it
doesn't understand or is unwilling or unable to
process based on policy or whatever criteria . It was
intended as a compromise, of sorts, to allow for the
multiple resources/audiences in the request but
provide an easy out for the AS of saying it can't be
supported based on whatever implementation or
security or policy it has.
On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura
<[email protected] <mailto:[email protected]>> wrote:
There are cases where tokens are supposed to be
consumed at multiple places and the `aud` needed
to capture them. That's why `aud` is a
multi-valued field.
On Mon, Mar 27, 2017 at 11:35 AM Torsten
Lodderstedt <[email protected]
<mailto:[email protected]>> wrote:
May I ask you to explain this reason?
Am 27.03.2017 um 08:48 schrieb Mike Jones
<[email protected]
<mailto:[email protected]>>:
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]
<mailto:[email protected]>>
*Cc:* oauth <[email protected]
<mailto:[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/
<https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/>
There's also a htmlized version
available at:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07>
A diff from the previous version is
available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07
<https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07>
Please note that it may take a
couple of minutes from the time of
submission
until the htmlized version and diff
are available at tools.ietf.org
<http://tools.ietf.org/>.
Internet-Drafts are also available
by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
