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

Denis <denis.ietf@free.fr> Tue, 09 May 2017 15:56 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7712E054 for <oauth@ietfa.amsl.com>; Tue, 9 May 2017 08:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQmQwRtw7j6r for <oauth@ietfa.amsl.com>; Tue, 9 May 2017 08:55:57 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7048A12949A for <oauth@ietf.org>; Tue, 9 May 2017 08:55:56 -0700 (PDT)
Received: from [192.168.0.14] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5BE6278039D; Tue, 9 May 2017 17:55:53 +0200 (CEST)
To: Brian Campbell <bcampbell@pingidentity.com>
References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <CA+k3eCTE1NM90QcZRFR0jATCqdeJWyTRUb6Ryp52n9FRg6aGpA@mail.gmail.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <CA+k3eCTjmifjsbec80vGTE5Hw4ws7oARuaatDk4RYOLK26-87Q@mail.gmail.com> <CY4PR21MB050479DBD8A7AB6342682209F5330@CY4PR21MB0504.namprd21.prod.outlook.com> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> <CABzCy2ArQ29xtyzT+t4i1fq9XZT+fMLgsw5oV75aFTkvVf8tgw@mail.gmail.com> <CA+k3eCRMwS7KiCyrGm8d6Syo=SpfR65zSb0MFJ8A1ns=DVrR0g@mail.gmail.com> <CAGL6epKM8DyTqG4gLr0OnVJXtZyhziiit7UnRjBs-ME0rvPtpA@mail.gmail.com> <CA+k3eCStAqU0kQOuyrOkjPO8zejf519ZxcVFzkV-y_feR8STUQ@mail.gmail.com> <CA+k3eCQUeJyfROy1ZNSoPhQzLOSi4NTp8WLwehT-NrmyL=4z1Q@mail.gmail.com> <be5e59c1-d6ca-cc48-8a81-56b1dd58026c@free.fr> <CA+k3eCSdDDufp6+p4RmxOwcGzcaEX+W4MotE9qWDQNgiYcHBsg@mail.gmail.com>
Cc: oauth <oauth@ietf.org>
From: Denis <denis.ietf@free.fr>
Message-ID: <58cc229c-ca5e-18d4-8b62-fbb3853f5cca@free.fr>
Date: Tue, 9 May 2017 17:55:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCSdDDufp6+p4RmxOwcGzcaEX+W4MotE9qWDQNgiYcHBsg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------EEAEE88F620BB96F53B0D418"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nxZ8EYYhQnoYhwShZOEJbwCjQtE>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 May 2017 15:56:04 -0000

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 <denis.ietf@free.fr 
> <mailto:denis.ietf@free.fr>> 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
>>     <bcampbell@pingidentity.com <mailto:bcampbell@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.ietf@gmail.com <mailto:rifaat.ietf@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
>>             <bcampbell@pingidentity.com
>>             <mailto:bcampbell@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
>>                 <sakimura@gmail.com <mailto:sakimura@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 <torsten@lodderstedt.net
>>                     <mailto:torsten@lodderstedt.net>> wrote:
>>
>>                         May I ask you to explain this reason?
>>
>>>                         Am 27.03.2017 um 08:48 schrieb Mike Jones
>>>                         <Michael.Jones@microsoft.com
>>>                         <mailto:Michael.Jones@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-bounces@ietf.org] *On Behalf
>>>                         Of *Brian Campbell
>>>                         *Sent:* Monday, March 27, 2017 8:45 AM
>>>                         *To:* Torsten Lodderstedt
>>>                         <torsten@lodderstedt.net
>>>                         <mailto:torsten@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 <torsten@lodderstedt.net
>>>                         <mailto:torsten@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 <bcampbell@pingidentity.com
>>>                                 <mailto:bcampbell@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-drafts@ietf.org
>>>                                 <mailto:internet-drafts@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-announce@ietf.org
>>>                                 <mailto:i-d-announce@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 <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> 
>