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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 8 May 2017 10:01:45 -0400

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-masked]
> 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-masked]> 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-masked]> wrote:
>>
>>> May I ask you to explain this reason?
>>>
>>> Am 27.03.2017 um 08:48 schrieb Mike Jones <[email-masked]>:
>>>
>>> For the same reason that the “aud” claim is multi-valued in JWTs, the
>>> audience needs to stay multi-valued in Token Exchange.  Ditto for resources.
>>>
>>>
>>>
>>>                                                        Thanks,
>>>
>>>                                                        -- Mike
>>>
>>>
>>>
>>> *From:* OAuth [mailto:[email-masked] <[email-masked]>] *On
>>> Behalf Of *Brian Campbell
>>> *Sent:* Monday, March 27, 2017 8:45 AM
>>> *To:* Torsten Lodderstedt <[email-masked]>
>>> *Cc:* oauth <[email-masked]>
>>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-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 <
>>> [email-masked]> 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-masked]>:
>>>
>>>
>>>
>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary
>>> change in -07 is the addition of a description of the relationship between
>>> audience/resource/scope, which was a request or comment that came up during
>>> the f2f meeting in Seoul.
>>>
>>> Excerpted from the Document History:
>>>
>>>    -07
>>>
>>>    o  Fixed typo (desecration -> discretion).
>>>    o  Added an explanation of the relationship between scope, audience
>>>       and resource in the request and added an "invalid_target" error
>>>       code enabling the AS to tell the client that the requested
>>>       audiences/resources were too broad.
>>>
>>> ---------- Forwarded message ----------
>>> From: <[email-masked]>
>>> Date: Wed, Jan 11, 2017 at 12:00 PM
>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
>>> To: [email-masked]
>>> Cc: [email-masked]
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Web Authorization Protocol of the IETF.
>>>
>>>         Title           : OAuth 2.0 Token Exchange
>>>         Authors         : Michael B. Jones
>>>                           Anthony Nadalin
>>>                           Brian Campbell
>>>                           John Bradley
>>>                           Chuck Mortimore
>>>         Filename        : draft-ietf-oauth-token-exchange-07.txt
>>>         Pages           : 31
>>>         Date            : 2017-01-11
>>>
>>> Abstract:
>>>    This specification defines a protocol for an HTTP- and JSON- based
>>>    Security Token Service (STS) by defining how to request and obtain
>>>    security tokens from OAuth 2.0 authorization servers, including
>>>    security tokens employing impersonation and delegation.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>>>
>>> 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/
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> --
>>
>> Nat Sakimura
>>
>> Chairman of the Board, OpenID Foundation
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 8 May 2017 10:29:56 -0600

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-masked]>
wrote:

> On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <
> [email-masked]> wrote:
>
>>>> Am 27.03.2017 um 08:48 schrieb Mike Jones <[email-masked]
>>>> >:
>>>>
>>>> In section 2.1 it states: „Multiple "resource" parameters may be used
>>>> to indicate
>>>>
>>>> And in the end the client may add some scope values to the „meal“,
>>>> which brings us to
>>>>
>>>>
>>>>
>>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The
>>>> primary change in -07 is the addition of a description of the relationship
>>>> between audience/resource/scope, which was a request or comment that came
>>>> up during the f2f meeting in Seoul.
>>>>

---

From: Denis <[email-masked]>
Date: Mon, 8 May 2017 19:00:21 +0200

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

> generalized somewhat to allow more versatility in 
> applications/deployments of the token exchange framework. Here's that 
> text:
>
>    actor_token
> On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef 
> <[email-masked] <mailto:[email-masked]>> 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,*
>
>     On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell
>     <[email-masked] <mailto:[email-masked]>>
>     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-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>>
>             wrote:
>
>>                 <mailto:[email-masked]>>:
>>
>>                 For the same reason that the “aud” claim is
>>                 multi-valued in JWTs, the audience needs to stay
>>                 multi-valued in Token Exchange. Ditto for resources.
>>
>>                 Thanks,
>>
>>                 -- Mike
>>
>>                 *From:* OAuth [mailto:[email-masked]] *On
>>                 *To:* Torsten Lodderstedt <[email-masked]
>>                 <mailto:[email-masked]>>
>>                 *Cc:* oauth <[email-masked] <mailto:[email-masked]>>
>>                 *Subject:* Re: [OAUTH-WG] I-D Action:
>>                 draft-ietf-oauth-token-exchange-07.txt
>>
>>                 The desire to support multiple audience/resource
>>                 values in the request came up during a review and
>>                 discussion among the authors of the document when
>>                 preparing the -03 draft. As I recall, it was said
>>                 that both Salesforce and Microsoft had use-cases for
>>                 it. I incorporated support for it into the draft
>>                 acting in the role of editor.
>>
>>                 From an individual perspective, I tend to agree with
>>                 you that allowing for multiple audiences/resources
>>                 adds a lot of complexity that's like not needed in
>>                 many (or most) cases. And I would personally be open
>>                 to making audience and resource mutual exclusive and
>>                 single valued. A question for the WG I suppose.
>>
>>                 The "invalid_target" error code that was added in -07
>>                 was intended to give the AS a standard way to deal
>>                 with the complexity and reject request with multiple
>>                 audiences/resources that it doesn't understand or is
>>                 unwilling or unable to process. It was intended as a
>>                 compromise, of sorts, to allow for the multiples but
>>                 provide an easy out of saying it can't be supported
>>                 based on whatever implementation or policy of the AS.
>>
>>                 On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt
>>                 <[email-masked]
>>                 <mailto:[email-masked]>> wrote:
>>
>>                     Hi Brian,
>>
>>                     In section 2.1 it states: „Multiple "resource"
>>                     parameters may be used to indicate
>>
>>                     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:
>>
>>                     And in the end the client may add some scope
>>                     values to the „meal“, which brings us to
>>
>>                     I personally would suggest to drop support for
>>                     multiple audience and resource parameters and
>>                     make audience and resource mutual exclusive. I
>>                         Am 11.01.2017 um 20:04 schrieb Brian Campbell
>>                         <[email-masked]
>>                         <mailto:[email-masked]>>:
>>
>>                         Draft -07 of "OAuth 2.0 Token Exchange" has
>>                         been published. The primary change in -07 is
>>                         the addition of a description of the
>>                         relationship between audience/resource/scope,
>>                         which was a request or comment that came up
>>                         during the f2f meeting in Seoul.
>>
>>                         From: <[email-masked]
>>                         <mailto:[email-masked]>>
>>                         <mailto:[email-masked]>
>>                         Cc: [email-masked] <mailto:[email-masked]>
>>
>>
>>
>>                         A New Internet-Draft is available from the
>>                         on-line Internet-Drafts directories.
>>                         <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/>
>>
>>                         [email-masked] <mailto:[email-masked]>
>>                         <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>                         [email-masked] <mailto:[email-masked]>
>>                         <https://www.ietf.org/mailman/listinfo/oauth>
>>
>
>                 [email-masked] <mailto:[email-masked]>
>                 <https://www.ietf.org/mailman/listinfo/oauth>
>
>             -- 
>
>             Nat Sakimura
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 8 May 2017 12:12:39 -0600

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

On Mon, May 8, 2017 at 11:00 AM, Denis <[email-masked]> wrote:

> 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.
>
> 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
> If there is no delegation, then this field (which is optional) will not be
> used.
>
>> 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,*
>>
>>>>> *From:* OAuth [mailto:[email-masked] <[email-masked]>]
>>>>> *On Behalf Of *Brian Campbell
>>>>> 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?
>>>>>
>>>>>
>>>>>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 8 May 2017 13:36:03 -0600

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.

---

From: Denis <[email-masked]>
Date: Tue, 9 May 2017 11:06:02 +0200

Brian,

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

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

The current text is:

The current text states:

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

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 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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
>         audiences/resources issue with an error code, and we did not
>         see any objection to this approach so far.
>
>
>         *Authors,*
>
>         <mailto:[email-masked]>> 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
>                 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.
>
>>                     that both Salesforce and Microsoft had use-cases
>>                     for it. I incorporated support for it into the
>>                     From an individual perspective, I tend to agree
>>                     with you that allowing for multiple
>>                     audiences/resources adds a lot of complexity
>>                     that's like not needed in many (or most) cases.
>>                     And I would personally be open to making audience
>>                     and resource mutual exclusive and single valued.
>>                     A question for the WG I suppose.
>>
>>                     The "invalid_target" error code that was added in
>>                     -07 was intended to give the AS a standard way to
>>                     deal with the complexity and reject request with
>>                     multiple audiences/resources that it doesn't
>>                     understand or is unwilling or unable to process.
>>                     It was intended as a compromise, of sorts, to
>>                     allow for the multiples but provide an easy out
>>                     of saying it can't be supported based on whatever
>>                     implementation or policy of the AS.
>>
>>                     On Sun, Mar 26, 2017 at 9:00 AM, Torsten
>>                     Lodderstedt <[email-masked]
>>                         In section 2.1 it states: „Multiple
>>                         "resource" parameters may be used to indicate
>>
>>                         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.
>>
>>                         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?
>>
>>                         there could also be multiple audience values
>>                         and the client could mix them:
>>
>>                         I personally would suggest to drop support
>>                         for multiple audience and resource parameters
>>                         and make audience and resource mutual
>>                         exclusive. I think this is sufficient and
>>                         much easier to implement.
>>
>>                         kind regards,
>>
>>                         Torsten.
>>
>>                             Am 11.01.2017 um 20:04 schrieb Brian
>>                             Campbell <[email-masked]
>>                             Draft -07 of "OAuth 2.0 Token Exchange"
>>                             has been published. The primary change in
>>                             -07 is the addition of a description of
>>                             the relationship between
>>                             A New Internet-Draft is available from
>>                             the on-line Internet-Drafts directories.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 9 May 2017 09:12:24 -0600

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.

On Tue, May 9, 2017 at 3:06 AM, Denis <[email-masked]> wrote:

> 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
> On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <
>> On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <[email-masked]
>> > wrote:
>>
>>> Hi All,
>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>

---

From: Denis <[email-masked]>
Date: Tue, 9 May 2017 17:55:53 +0200

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.
>
> On Tue, May 9, 2017 at 3:06 AM, Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>         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
>     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
>
>>     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.
>>
>>
>>
>>
>>         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
>>             audiences/resources issue with an error code, and we did
>>             not see any objection to this approach so far.
>>
>>
>>             *Authors,*
>>
>>                 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.
>>
>>                     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
>>>                         multi-valued in JWTs, the audience needs to
>>>                         stay multi-valued in Token Exchange. Ditto
>>>                         for resources.
>>>
>>>                         Thanks,
>>>
>>>                         -- Mike
>>>
>>>                         *From:* OAuth
>>>                         [mailto:[email-masked]] *On Behalf
>>>                         Of *Brian Campbell
>>>                         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
>>>                         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
>>>                             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
>>>                             server to server scenarios, right? So
>>>                             the only reason I can think of is call
>>>                             reduction.
>>>
>>>                             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:
>>>
>>>                             And in the end the client may add some
>>>                             scope values to the „meal“, which brings
>>>                             us to
>>>
>>>                             resource parameters and make audience
>>>                             and resource mutual exclusive. I think
>>>                             this is sufficient and much easier to
>>>                             implement.
>>>
>>>                             kind regards,
>>>
>>>                             Torsten.
>>>
>>>                                 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
>>>                                 <mailto:[email-masked]>
>>>                                 until the htmlized version and diff
>>>                                 are available at tools.ietf.org
>     _______________________________________________ OAuth mailing list

---

From: Brian Campbell <[email-masked]>
Date: Thu, 11 May 2017 09:58:47 -0600

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).

On Tue, May 9, 2017 at 9:55 AM, Denis <[email-masked]> wrote:

> 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."
>> the party that is authorized to use the requested security token and act on
>> behalf of the subject.
>>
>>> On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <
>>> [email-masked]> wrote:
>>>
>>>> Hi All,
>>>>
>>>>> 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
>>>>>>> For the same reason that the “aud” claim is multi-valued in JWTs,
>>>>>>> the audience needs to stay multi-valued in Token Exchange.  Ditto for
>>>>>>> resources.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                                                        Thanks,
>>>>>>>
>>>>>>>                                                        -- Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* OAuth [mailto:[email-masked]
>>>>>>> <[email-masked]>] *On Behalf Of *Brian Campbell
>>>>>>> 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
>>>>>>> In section 2.1 it states: „Multiple "resource" parameters may be
>>>>>>> used to indicate
>>>>>>>
>>>>>> ...
> [Message clipped]

---

From: Brian Campbell <[email-masked]>
Date: Fri, 26 May 2017 16:21:19 -0600

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 <[email-masked]>
wrote:

>> 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
>>>>>>>> I personally would suggest to drop support for multiple audience
>>>>>>>> and resource parameters and make audience and resource mutual exclusive. I