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

Brian Campbell <bcampbell@pingidentity.com> Mon, 08 May 2017 19:36 UTC

Return-Path: <bcampbell@pingidentity.com>
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 BA61A1296B3 for <oauth@ietfa.amsl.com>; Mon, 8 May 2017 12:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
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 tnejQSield7i for <oauth@ietfa.amsl.com>; Mon, 8 May 2017 12:36:34 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6160F129A8E for <oauth@ietf.org>; Mon, 8 May 2017 12:36:34 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id e64so37807507pfd.1 for <oauth@ietf.org>; Mon, 08 May 2017 12:36:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=96W4R6IjNq9HflZgjefIbpmq8Rjz1MxFAGNnU3opWz8=; b=i+UFV0GAzY1ovXk/FechN1VIGBtbmvo0h70OS9o4mndvpt0HSyKEInau/i/g6CATeD tCEo3fmu1JxksnvLklHq1jAPkMiLnl8J6ogCWpUV+5Nbh6vYFotDVZ9eFrywUyCJkFYV /cjj195WfTocR4AEU0CJUmMdasH8jsPOe0I9g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=96W4R6IjNq9HflZgjefIbpmq8Rjz1MxFAGNnU3opWz8=; b=mcizlo5eW1MRpGbHZJvQF/zJ64GWFl7KgCYs6Dh7RLR9nWz7NvNBfT9BjG7RSJY/V4 XXuxMDSAkFt07C4g5kRE2FcOTaYn6pD/HLBTKZuKpmNLrxsKnwjjSQK6kaXlSn3aN0th 9UB9uvIBoxWHwoj8bbUCf9hYKyUA/1Oigmk63HDaleEvA7W7AD9zmC/GNhtsnUUMVOkQ BVRb8k4hIDTyUwfCT/vu0WvoWPhwxltFrDZxLeXj6uWW5LwmY9jkSqPNVe6IKREj/wMb tOReRmjb/EGSjttTomeNwg2bIY+w2tyE9kCTu4QwLoWVi+7e7Ia2dxtjoRhC9Zmz4DMB B2gQ==
X-Gm-Message-State: AN3rC/5EqH7QU4WIfEI/J56qEuWpvAoqPVqAWWKrhtaeP7WpiKn3xr6Q 2l9mwVis6HhgweAeRs7Cd/Mt+Rpd+cMp
X-Received: by 10.99.123.77 with SMTP id k13mr20947624pgn.32.1494272193757; Mon, 08 May 2017 12:36:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.154.205 with HTTP; Mon, 8 May 2017 12:36:03 -0700 (PDT)
In-Reply-To: <CA+k3eCStAqU0kQOuyrOkjPO8zejf519ZxcVFzkV-y_feR8STUQ@mail.gmail.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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 8 May 2017 13:36:03 -0600
Message-ID: <CA+k3eCQUeJyfROy1ZNSoPhQzLOSi4NTp8WLwehT-NrmyL=4z1Q@mail.gmail.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: Nat Sakimura <sakimura@gmail.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=f403045c5f804eada4054f085b35
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/lmCVzMevHd8_OxWGb0UGazLebKE>
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: Mon, 08 May 2017 19:36:42 -0000

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>
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>
> 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> 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>
>>> 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> wrote:
>>>>
>>>>> May I ask you to explain this reason?
>>>>>
>>>>> Am 27.03.2017 um 08:48 schrieb Mike Jones <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 <oauth-bounces@ietf.org>]
>>>>> *On Behalf Of *Brian Campbell
>>>>> *Sent:* Monday, March 27, 2017 8:45 AM
>>>>> *To:* Torsten Lodderstedt <torsten@lodderstedt.net>
>>>>> *Cc:* oauth <oauth@ietf.org>
>>>>> *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 <
>>>>> 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>:
>>>>>
>>>>>
>>>>>
>>>>> 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>
>>>>> 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
>>>>> Cc: 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/
>>>>>
>>>>> 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
>>>>> OAuth@ietf.org
>>>>> 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
>>>>>
>>>> --
>>>>
>>>> Nat Sakimura
>>>>
>>>> Chairman of the Board, OpenID Foundation
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>