Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7271B2A37 for ; Wed, 20 Jan 2016 14:47:30 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Jza3yLsSBZvp for ; Wed, 20 Jan 2016 14:47:27 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (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 761741B2A36 for ; Wed, 20 Jan 2016 14:47:27 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id 6so18649835qgy.1 for ; Wed, 20 Jan 2016 14:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=EyYrHu2K2OVVoAQRFZenKaj/Mg7HNWCZeYUsLARLGgw=; b=L1zlOvP7QWe5hwomA07m4jaexKEQr/LXNAsQ0ZTOn4wb/a/SDDxjD3rzynCavP7UKb pfFAwzkszCfzNISPY//qX2OPqaO7aFjNdU/IHp6JOElTbRRP7a0el72l2/+tg/Bxj3L0 6XG35EH8esexEpNj6D5/pXdMwTGTzmHcBBRmhSL1R1ppS0F4COAeC11H/1COsXSmrHiL ym+XBBgfHxo1d8AMdFtilCrwJKzgqvIM3r1E4UgTLYqkCbA7WTQjfZC33A8Y1o72vATk aNeU0FRH1if1jMN0K4x1SVnJdErCHJr92A/4lV9DgYPWQVah1HZg1ppcSfFpTy4SaVed xwYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=EyYrHu2K2OVVoAQRFZenKaj/Mg7HNWCZeYUsLARLGgw=; b=e9yWVWe+Aes0OeIOwtzVSiSiRNKoe0YvIs1+Sve+uhtyzaMyOOT0qTn+QOWR5Wqt5a 2OOfN264jftK8OadQlsecIgSrqe8gSHbKJL+UkActWPIBowI+BCW0USX0fndaShjmoGp w8Jqp8kxgX8BQRpvmLJ+LaBVUgJWWztUDO9bfHMII3bYBlM1AlkFNDn0G8E5QfdRr0IQ rqEoVc69wn0/yPMzkduISkjybrDMXV2/plFrJMv3W5bXaQG9pI41N+crTdGnlOwuF+e6 flWdrUzIDnG76O3sSepofQsEpgW3yxI8nzDvbHeH7i/4zpEwPYSO27HGRLG8K8mUnrIB rX0Q== X-Gm-Message-State: ALoCoQm/m6rc80aE9ja4klyDlrCXLZ0IdXjYR9qRbta2x9vwwekKSWfDP75ty2Gp4QnXSGC7zi14vknR30SfuZ40+ce3Mk0Dng== X-Received: by 10.140.18.136 with SMTP id 8mr48067303qgf.64.1453330046665; Wed, 20 Jan 2016 14:47:26 -0800 (PST) MIME-Version: 1.0 References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com> In-Reply-To: <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com> From: Nat Sakimura Date: Wed, 20 Jan 2016 22:47:17 +0000 Message-ID: To: John Bradley , Michael Jones Content-Type: multipart/alternative; boundary=001a113546422c49ed0529cbc57a Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:47:30 -0000 --001a113546422c49ed0529cbc57a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Also, I have always thought that it would be good if one could ask for a particular resource type, and the server could respond with the actual location of it with the associated access token. This is because it is often undesirable to tell the client the location of the resource before the authorization from the privacy point of view. So, the processing flow in this case will be: 1. The client request an access to the resource type in the scope of the authorization request. 2. The client request an access token to the resource type to the token endpoint with audience/resource/scope parameter. 3. The token endpoint responds with token response with oauth-meta header indicating the URL of the resource as in draft-sakimura-oauth-meta. Best, Nat 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 7:27 John Bradley : > +1 > > On Jan 20, 2016, at 7:25 PM, Mike Jones > wrote: > > As mentioned in Prague, Azure Active Directory uses a =E2=80=9Cresource= =E2=80=9D request > parameter to supply the URL of the resource server that the access token = is > intended for. However, I believe that Google uses scope values for this > and some Microsoft services are moving towards using scope values as well= . > Sorting this out soon would be good. > > -- Mike > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Brian Campbell > *Sent:* Wednesday, January 20, 2016 2:18 PM > *To:* Hannes Tschofenig > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience > > > There does seem to be a need to provide the client a means of telling the > AS the place(s) and/or entity(s) where it intends to use the token it's > asking for. And that it's common enough to warrant it's own small spec. > This has come up several times before and I think has some consensus behi= nd > doing it. What needs to happen to move forward? > The concept shows up in these three different drafts (that I know of > anyway): > > > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 = has > an audience parameter > > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#sect= ion-3 > has an aud parameter > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1= has > both an audience and a resource resource > > All the above apply only to the token request. However, there are ways of > requesting/obtaining access tokens that don't involve the token endpoint > so I think it follows > that the same facility should be available for the authorization request > too. > > > > On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > Hi Sergey, > > that's a good question. After this document was published the > functionality had been integrated into the PoP solution document. > Recently, I got feedback that the functionality should be more generic > and it is independent of the PoP work. > > So, I guess it is a good time to discuss the needed functionality and > where it should be included. > > Ciao > Hannes > > > > On 01/20/2016 11:25 AM, Sergey Beryozkin wrote: > > Hi > > > > Given that the draft-tschofenig-oauth-audience [1] has expired, I'm > > wondering if it is still relevant. > > > > I know the token introspection response can provide the audience > > value(s), but the question is really how a client is associated with a = a > > given audience in the first place. As such [1] may still make sense, fo= r > > example, I can think of two options: > > 1. the client audiences are set out of band during the client > > registration time and all the tokens issued to that client will be > > restricted accordingly > > 2. the client is requesting a specific audience during the grant to > > token exchange as per [1] > > > > I guess 1. is how it is done in practice or is 2. is also a valid optio= n > ? > > > > > > Thanks, Sergey > > > > > > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > _______________________________________________ > > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113546422c49ed0529cbc57a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Also, I have always thought that it = would be good if one could ask for a particular resource type, and the serv= er could respond with the actual location of it with the associated access = token. This is because it is often undesirable to tell the client the locat= ion of the resource before the authorization from the privacy point of view= .=C2=A0

So, the processing flow in this case will = be:=C2=A0

  1. = The client request an access to the resource type in the scope of the autho= rization request.=C2=A0
  2. = The client request an access token to the resource type to the token endpoi= nt with audience/resource/scope parameter.=C2=A0
  3. The token endpoint responds with token response wi= th oauth-meta header indicating the URL of the resource as in=C2=A0<= span style=3D"line-height:1.5">=C2=A0draft-sakimura-oauth-meta.=C2=A0
Best,=C2=A0

Nat


2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6= =9C=A8) 7:27 John Bradley <ve7jtb@v= e7jtb.com>:
+1

On Jan 20, 2016, at 7:25 PM, Mike Jones &= lt;Michael= .Jones@microsoft.com> wrote:

As mentioned in Prague, Azure Active Directory uses a =E2=80=9Cresource=E2= =80=9D request parameter to supply the URL of the resource server that the = access token is intended for.=C2=A0 However, I believe that Google uses sco= pe values for this and some Microsoft services are moving towards using sco= pe values as well.=C2=A0 Sorting this out soon would be good.=
=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=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
=C2=A0
Fro= m:<= span>=C2=A0OAuth [mailto:oauth-bou= nces@ietf.org]=C2=A0On Behalf Of=C2=A0= Brian Campbell
Sent:=C2=A0Wednesday, January 20, 201= 6 2:18 PM
To:=C2=A0Hannes Tschofenig
Cc:=C2=A0oauth
Subject:=C2=A0Re: [OAUTH-WG] = Status of draft-tschofenig-oauth-audience
=C2=A0

There does seem to be a need to provide the client a means of= telling the AS the place(s) and/or entity(s) where it intends to use the t= oken it's asking for. And that it's common enough to warrant it'= ;s own small spec. This has come up several times before and I think has so= me consensus behind doing it. What needs to happen to move forward?<= u>

The concept shows up in these three = different drafts (that I know of anyway):


https://tools.ietf.org/html/draft-tschof= enig-oauth-audience-00#section-3=C2=A0has an audience para= meter=C2=A0
https://tools.ietf.org/html/draft-ietf-= oauth-pop-key-distribution-02#section-3=C2=A0has an aud pa= rameter=C2=A0
http://tools.ietf.org/html/draft-ietf-oaut= h-token-exchange-03#section-2.1=C2=A0has both an audience = and a resource resource

All the above apply only to the token reques= t. However, there are=C2=A0ways of requesting/obtaining access tokens that don't = involve the token endpoint=C2=A0so I think it follows that= =C2=A0 the same facility should be available for the authorization request = too.=C2=A0


=C2=A0
On Wed, = Jan 20, 2016 at 7:27 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Sergey,

that's a good question. After this d= ocument was published the
functionality had been integrated into the PoP= solution document.
Recently, I got feedback that the functionality shou= ld be more generic
and it is independent of the PoP work.

So, I g= uess it is a good time to discuss the needed functionality and
where it = should be included.

Ciao
H= annes



On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> Hi
&= gt;
> Given that the draft-tschofenig-oauth-audience [1] has expired,= I'm
> wondering if it is still relevant.
>
> I know = the token introspection response can provide the audience
> value(s),= but the question is really how a client is associated with a a
> giv= en audience in the first place. As such [1] may still make sense, for
&g= t; example, I can think of two options:
> 1. the client audiences are= set out of band during the client
> registration time and all the to= kens issued to that client will be
> restricted accordingly
> 2= . the client is requesting a specific audience during the grant to
> = token exchange as per [1]
>
> I guess 1. is how it is done in p= ractice or is 2. is also a valid option ?
>
>
> Thanks, S= ergey
>
>
> [1]=C2=A0https://tools.ietf.org/html/dra= ft-tschofenig-oauth-audience-00
>
> _______________________= ________________________
> OAuth mailing list
>=C2=A0OAuth@ietf.org
>=C2=A0<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" style=3D"color:purpl= e;text-decoration:underline" target=3D"_blank">https://www.ietf.org/mailman= /listinfo/oauth


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

=C2=A0
_____________________= __________________________
OAuth mailing li= st
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth

_____________= __________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a113546422c49ed0529cbc57a--