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
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
<bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com>> 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
<rifaat.i...@gmail.com <mailto:rifaat.i...@gmail.com>> 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
<bcampb...@pingidentity.com
<mailto:bcampb...@pingidentity.com>> 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
<sakim...@gmail.com <mailto:sakim...@gmail.com>> 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
<tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>> wrote:
May I ask you to explain this reason?
Am 27.03.2017 um 08:48 schrieb Mike Jones
<michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>:
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-boun...@ietf.org] *On
Behalf Of *Brian Campbell
*Sent:* Monday, March 27, 2017 8:45 AM
*To:* Torsten Lodderstedt
<tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>>
*Cc:* oauth <oauth@ietf.org <mailto: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 <tors...@lodderstedt.net
<mailto:tors...@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 <bcampb...@pingidentity.com
<mailto:bcampb...@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-dra...@ietf.org
<mailto:internet-dra...@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-annou...@ietf.org
<mailto:i-d-annou...@ietf.org>
Cc: oauth@ietf.org <mailto:oauth@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/
<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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
