Return-Path: 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 0BA83129998 for ; Fri, 31 Mar 2017 08:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 jCYo2t8HWDIp for ; Fri, 31 Mar 2017 08:04:30 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 8DB011298CF for ; Fri, 31 Mar 2017 08:04:24 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id 21so73821538pgg.1 for ; Fri, 31 Mar 2017 08:04:24 -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=c4QzZ2rGjfg/qnt8kutRSaoe4KUHMf+TSWrjkWcu5bQ=; b=d/hKj0+pEsAqyrZnGu9uOG3RvifCdC1QUyE8cqzUN0SHDSa6Do5eSH9fbnknzaHPlO jBu0jssQIhtWvoLHov2kvQWXXtepxae4wFSeq90i7er+B3FmOKwKsuMON/oaWQclei7S m2Zm2fm7rsr69oaJ1UaVDmP8+XdY1Wp6MJtYM= 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=c4QzZ2rGjfg/qnt8kutRSaoe4KUHMf+TSWrjkWcu5bQ=; b=cKFV1RaSXY43lkFFmqcUzKKDwW/m3unNRJ1bSwj43HTJX2gnC9p79lQ2HD8hFDEN37 C+JRtmqIwEnRxhQ9ROQ1MuFYY7wKeITbVKdn26ltBZfVxEjWiPpVY/aydFhY/s+kLia/ lrx1xcESS+7lEkNWS/epbmIqWFv9Pz2ED+eHrtdUYCcDXemYNXJtsREGKgeHj31YlgzT AlksKGPrfLq3ox3J/MTFz/OW0A5k/a5g/C8juuvo5m5Ki1gLN3SbShIgRrjr7RmVadVq 2wlHOAXRywNkkK1G2ELnrmNWihqWihEmvyxFsLMtZnrEnBPt9uTWwH7tKmzZZ/mOy/Cg IFSg== X-Gm-Message-State: AFeK/H0axBigHYQ0S1jyMRUl5c6Kwq+2eRX0FN8HKM+hcyztMYa5f8/f1LUI44u8WfrS4eqVsgGh87UjMfEDgILm X-Received: by 10.99.112.18 with SMTP id l18mr3848599pgc.142.1490972664035; Fri, 31 Mar 2017 08:04:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.165.172 with HTTP; Fri, 31 Mar 2017 08:03:53 -0700 (PDT) In-Reply-To: References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> From: Brian Campbell Date: Fri, 31 Mar 2017 10:03:53 -0500 Message-ID: To: Nat Sakimura Cc: Torsten Lodderstedt , Mike Jones , oauth Content-Type: multipart/alternative; boundary=f403045c7b0a02acba054c0820ec Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:04:35 -0000 --f403045c7b0a02acba054c0820ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 : >> >> For the same reason that the =E2=80=9Caud=E2=80=9D claim is multi-valued= in JWTs, the >> audience needs to stay multi-valued in Token Exchange. Ditto for resour= ces. >> >> >> >> 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 >> *Cc:* oauth >> *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 Salesfo= rce >> and Microsoft had use-cases for it. I incorporated support for it into t= he >> 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 no= t >> 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 reques= t >> with multiple audiences/resources that it doesn't understand or is >> unwilling or unable to process. It was intended as a compromise, of sort= s, >> 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: =E2=80=9EMultiple "resource" parameters may be= used to >> indicate >> >> that the issued token is intended to be used at the multiple >> >> resources listed.=E2=80=9C >> >> >> >> Can you please explain the rational in more detail? I don=E2=80=99t unde= rstand >> why there is a need to ask for access tokens, which are good for multipl= e >> 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 su= ch >> 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.=E2=80=9C >> >> >> >> And in the end the client may add some scope values to the =E2=80=9Emeal= =E2=80=9C, which >> brings us to >> >> >> >> =E2=80=9EEffectively, 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 > >: >> >> >> >> 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 betwe= en >> audience/resource/scope, which was a request or comment that came up dur= ing >> 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: >> 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=3Ddraft-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 > > --f403045c7b0a02acba054c0820ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As mentioned during the Chicago meeting the "invalid_= target" error code that was added in -07 was intended to=20 give the AS a standard way to reject=20 request with multiple audiences/resources that it doesn't understand or= =20 is unwilling or unable to process based on policy or whatever criteria . It= was intended as a compromise, of=20 sorts, to allow for the multiple resources/audiences in the request but pro= vide an easy out for the AS of saying it=20 can't be supported based on whatever implementation or security or poli= cy it has.

On Tue, Ma= r 28, 2017 at 1:32 AM, Nat Sakimura <sakimura@gmail.com> wr= ote:
There are cases whe= re tokens are supposed to be consumed at multiple places and the `aud` need= ed to capture them. That's why `aud` is a multi-valued field.=C2=A0

On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <torsten@lodderste= dt.net> wrote:
May I ask = you to explain this reason?

Am 27.03= .2017 um 08:48 schrieb Mike Jones <Micha= el.Jones@microsoft.com>:

For the same reason that the =E2=80=9Caud=E2=80=9D claim is multi-val= ued in JWTs, the audience needs to stay multi-valued in Token Exchange.=C2= =A0 Ditto for resources.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0<= /span>

From: OAuth [mailto:oauth-bounces@ietf.= org] On Behalf Of Brian Campbell
Sent: Monday, March 27, 20= 17 8:45 AM
To: Torsten Lodderstedt &l= t;torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-= D Action: draft-ietf-oauth-token-exchange-07.txt

=C2=A0

Thanks for the re= view 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 th= e 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 individua= l perspective, I tend to agree with you that allowing for multiple audience= s/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 ques= tion for the WG I suppose.=

The "invalid_target" error code that w= as 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 do= esn'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 i= mplementation or policy of the AS.

=C2=A0

=C2=A0

=C2=A0

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodders= tedt <torsten@lodderstedt.net> wrote:=

Hi Brian,

=C2=A0

thanks for the clarification around resource, au= dience and scope.=C2=A0

=C2=A0

Here are my comments on the draft:

=C2=A0

In section 2.1 it states: =E2=80=9EMultiple &quo= t;resource" parameters may be used to indicate<= /p>

=C2=A0 =C2=A0 =C2=A0 that the issued token is in= tended to be used at the multiple

=C2=A0 =C2=A0 =C2=A0 resources listed.=E2=80=9C<= u class=3D"m_-4354184635220679769gmail_msg">

=C2=A0

Can you please explain the rational in more deta= il? I don=E2=80=99t understand why there is a need to ask for access tokens= , which are good for multiple resources at once. This is a request type mor= e or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction.=C2= =A0

=C2=A0

On the other side, this feature increases the AS= 's complexity, e.g. its policy may prohibit to issue tokens for multipl= e resources in general or the particular set the client is asking for. How = shall the AS handles such cases?

=C2=A0

And it is getting even more complicated given th= ere could also be multiple audience values and the client could mix them:= =C2=A0

=C2=A0

"Multiple "audience" parameters

=C2=A0 =C2=A0 =C2=A0 may be used to indicate tha= t the issued token is intended to be

=C2=A0 =C2=A0 =C2=A0 used at the multiple audien= ces listed.=C2=A0 The "audience" and

=C2=A0 =C2=A0 =C2=A0 "resource" parame= ters may be used together to indicate multiple

=C2=A0 =C2=A0 =C2=A0 target services with a mix = of logical names and physical<= /u>

=C2=A0 =C2=A0 =C2=A0 locations.=E2=80=9C

=C2=A0

And in the end the client may add some scope val= ues to the =E2=80=9Emeal=E2=80=9C, which brings us to=C2=A0

=C2=A0

=E2=80=9EEffectively, the requested access right= s of the

=C2=A0 =C2=A0token are the cartesian product of = all the scopes at all the target

=C2=A0 =C2=A0services."<= /u>

=C2=A0

I personally would suggest to drop support for m= ultiple audience and resource parameters and make audience and resource mut= ual exclusive. I think this is sufficient and much easier to implement.

=C2=A0

kind regards,

Torsten.

=C2=A0

=C2=A0

Am 11.01.2017 um 20:04 schrieb Brian Campbell &l= t;bcampbell@pingidentity.com>:

=C2=A0

Draft -07 of &quo= t;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:

=C2=A0=C2=A0 -07

=C2=A0=C2=A0 o=C2=A0 Fixed typo (desecration -> discretion).
=C2=A0=C2=A0 o=C2=A0 Added an explanation of the relationship between scope= , audience
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and resource in the request and added an &qu= ot;invalid_target" error
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code enabling the AS to tell the client that= the requested
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Token Exchange
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Anthony Nadalin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brian Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Chuck Mortimore
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-token-exchange-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 31
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-11

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- b= ased
=C2=A0 =C2=A0Security Token Service (STS) by defining how to request and ob= tain
=C2=A0 =C2=A0security tokens from OAuth 2.0 authorization servers, includin= g
=C2=A0 =C2=A0security tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
https://data= tracker.ietf.org/doc/draft-ietf-oauth-token-exchange/

There's also a htmlized version available at:
https://tools.i= etf.org/html/draft-ietf-oauth-token-exchange-07

A diff from the previous version is available at:
https:/= /www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-07


Please note that it may take a couple of minutes from the time of submissio= n
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

=C2=A0

______________= _________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/= listinfo/oauth

=C2=A0

=C2=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.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


--f403045c7b0a02acba054c0820ec--