Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

John Bradley <ve7jtb@ve7jtb.com> Wed, 20 January 2016 22:27 UTC

Return-Path: <ve7jtb@ve7jtb.com>
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 892281B29AF for <oauth@ietfa.amsl.com>; Wed, 20 Jan 2016 14:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 8w7LwOLd2viq for <oauth@ietfa.amsl.com>; Wed, 20 Jan 2016 14:27:16 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 AD57E1B29AE for <oauth@ietf.org>; Wed, 20 Jan 2016 14:27:15 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id s68so9147737qkh.3 for <oauth@ietf.org>; Wed, 20 Jan 2016 14:27:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=n1dP9e83BhJ0fs6yLLNa8phIENZYUlacfJWinfj9jMA=; b=yHy5GtklYTqkObIKZxUDjJm++pBgwVpnAqT7UBn4eh6TwONYHmO2YLTNHnecuAt7zx h1ygO8SbbL469Cd44iMEhtlSwAgcCYEq/h7VnSVlt1tM+7WUEZzVuzS8jcBZS//vxMZf x8eMMxQBVeIS35fiac8UodZi0GjV5HASsY7HuCElkiSqGJQ5VAAmSFuNAgLElrolnq+l cBTt9yShz4f6iEzEbiY+TyQIu1M0S2uhqJm0r0hHz1zAqeKMiKaRIQL2IoGZ8HVFFvt0 2W2LD+c+6wkQMW7h3/hQc7k/6vCnLqDPTw6baoWwRKqm6o3WgyF6jRhSjumanUAMCBQM BCpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=n1dP9e83BhJ0fs6yLLNa8phIENZYUlacfJWinfj9jMA=; b=TyzuJpNM8k1Mwk++C/HJTbrujRRZ/wO5pjrfk6HtxiSB54wVilwQr3B2S5nM+AtJoS mBtho+FpDtDQNPrG+dcwQY3krd1EeSRO5Mhz9VHru7C/u1gwPCvAUAMm0noQ2+iInhAs gETJnSP+OLMD8CmBKg+T9wUZnTxqhfTrF5UKEfkrFOLhU1Joy6+NNoLYbiJUxbM8OtN4 ZKytbS5deGrVvcw1poyRrkTSt4LZqpgjLMx7R4V9qi0DOmxcfDLsADoG9KouwW72kQdx kpVNprTojw7ciXHAlyNTeT+cW0TziBXae36L2UTM4nk0qaRx/AAYweUGZEYTzrNIkumt N/ew==
X-Gm-Message-State: ALoCoQkDWBLkInWAtv0ff3o/eKKPIQviGVtrsl85iPPjfHKf6OAkJUk6YcHb/g4GndGXf4n5d3K5zg67OkT0Lx1kUu9VEG5ltg==
X-Received: by 10.55.76.84 with SMTP id z81mr47785558qka.17.1453328834856; Wed, 20 Jan 2016 14:27:14 -0800 (PST)
Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id t10sm12561862qhc.1.2016.01.20.14.27.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 14:27:14 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B130B023-EDFA-4676-8365-96A637C2C120"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <BY2PR03MB442A47609A3B5AD87169294F5C20@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Wed, 20 Jan 2016 19:27:09 -0300
Message-Id: <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com>
References: <CA+k3eCSpWFwyvk=XHP4b_zxzu-zrMYsS-axF6csO90-ahmkueQ@mail.gmail.com> <BY2PR03MB4423033D5604E9E36B20C23F5CA0@BY2PR03MB442.namprd03.prod.outlook.com> <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <ade5692aa1afa2d9d79b8ac7a55bf150@lodderstedt.net> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <A1C1786C-BE13-4D0F-9541-BEAE4DB8F284@mit.edu> <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> <CA+k3eCTzX+DkuEzb5XdTxtouOgkdMfZxp=Ue4ZvDJLf0wCFdPA@mail.gmail.com> <BY2PR03MB442A47609A3B5AD87169294F5C20@BY2PR03MB442.namprd03.prod.outlook.com>
To: Michael Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/tQ7MVshXfVvnop9w7tAtyB0lXfg>
Cc: oauth <oauth@ietf.org>
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 <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: Wed, 20 Jan 2016 22:27:18 -0000

+1

> On Jan 20, 2016, at 7:25 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> 
> As mentioned in Prague, Azure Active Directory uses a “resource” 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 <mailto:oauth-bounces@ietf.org>] On 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 behind 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 <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#section-3 <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3> has an aud parameter 
> http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 <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 <https://tools.ietf.org/html/rfc6749#section-4.2> 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 <mailto: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, for
> > 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 option ?
> >
> >
> > Thanks, Sergey
> >
> >
> > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 <https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00>
> >
> > _______________________________________________
> > 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>