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

[Denis <[e-mail]>]

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 
> <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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>>     <[e-mail] <mailto:[e-mail]>>
>>     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
>>         <[e-mail] <mailto:[e-mail]>> 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
>>             <[e-mail]
>>             <mailto:[e-mail]>> 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
>>                 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>>                     <mailto:[e-mail]>> wrote:
>>
>>                         May I ask you to explain this reason?
>>
>>>                         Am 27.03.2017 um 08:48 schrieb Mike Jones
>>>                         <[e-mail]
>>>                         <mailto:[e-mail]>>:
>>>
>>>                         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:[e-mail]] *On Behalf
>>>                         Of *Brian Campbell
>>>                         *Sent:* Monday, March 27, 2017 8:45 AM
>>>                         *To:* Torsten Lodderstedt
>>>                         <[e-mail]
>>>                         <mailto:[e-mail]>>
>>>                         *Cc:* oauth <[e-mail]
>>>                         <mailto:[e-mail]>>
>>>                         *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 <[e-mail]
>>>                         <mailto:[e-mail]>> 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 <[e-mail]
>>>                                 <mailto:[e-mail]>>:
>>>
>>>                                 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: <[e-mail]
>>>                                 <mailto:[e-mail]>>
>>>                                 Date: Wed, Jan 11, 2017 at 12:00 PM
>>>                                 Subject: [OAUTH-WG] I-D Action:
>>>                                 draft-ietf-oauth-token-exchange-07.txt
>>>                                 To: [e-mail]
>>>                                 <mailto:[e-mail]>
>>>                                 Cc: [e-mail]
>>>                                 <mailto:[e-mail]>
>>>
>>>
>>>
>>>                                 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
>>>                                 [e-mail] <mailto:[e-mail]>
>>>                                 https://www.ietf.org/mailman/listinfo/oauth
>>>                                 <https://www.ietf.org/mailman/listinfo/oauth>
>>>
>>>                                 _______________________________________________
>>>                                 OAuth mailing list
>>>                                 [e-mail] <mailto:[e-mail]>
>>>                                 https://www.ietf.org/mailman/listinfo/oauth
>>>                                 <https://www.ietf.org/mailman/listinfo/oauth>
>>>
>>
>>                         _______________________________________________
>>                         OAuth mailing list
>>                         [e-mail] <mailto:[e-mail]>
>>                         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
>>                     [e-mail] <mailto:[e-mail]>
>>                     https://www.ietf.org/mailman/listinfo/oauth
>>                     <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>>
>>                 _______________________________________________
>>                 OAuth mailing list
>>                 [e-mail] <mailto:[e-mail]>
>>                 https://www.ietf.org/mailman/listinfo/oauth
>>                 <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>     _______________________________________________ OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth> 
>