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

John Bradley <ve7jtb@ve7jtb.com> Wed, 20 January 2016 22:55 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 3DB6F1B2A2A for <oauth@ietfa.amsl.com>; Wed, 20 Jan 2016 14:55:42 -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 hYWKWZCSXaSV for <oauth@ietfa.amsl.com>; Wed, 20 Jan 2016 14:55:39 -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 E8A021A9127 for <oauth@ietf.org>; Wed, 20 Jan 2016 14:55:38 -0800 (PST)
Received: by mail-qg0-x22d.google.com with SMTP id o11so18797835qge.2 for <oauth@ietf.org>; Wed, 20 Jan 2016 14:55:38 -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=P5t5jsYiz+07tyWFBgblpyZ9f+C1LS9GyK7U1VfX2Y0=; b=RYH1NQdpkNNUO38IBKxjDwbJWkjHXvwG7zTwdRbk9aY3mlhA00XLtddUS8pkBsnSh1 IlfT3ocyNKL4323sxUFUzXiGGvr9tFs3Zb1NmAWaLBlXK0yKa3OrsSqfLLiLrlOJR8nG +H/3kF2HrnGLoCs3mV6jIRt0le5xPXiR42B7AzvabfO7ZYtvKgZAYaNDVxTx99O0/RsF zl8lzOY1jCmvIqzxBPl5j6izMCfHQhNmdjx7abUoU7FaPqszApV6RCwr0t03ixfr5J1Y Dajps+NnS6/8zF/JH8ASrPV3ZBhbfnyJZxjABnLmtItZOsq7qHWfKVr112cs22i+svVt mkDA==
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=P5t5jsYiz+07tyWFBgblpyZ9f+C1LS9GyK7U1VfX2Y0=; b=OgNPIUsZrJ7JCnECNuOP9Xq9xhbAVybmfUQ3vaz94XOkDRccvu2baq3NvC6G/D83y9 C3q7o9aZM1vQr9tGGZ+1ahGKvXmyTSUZWud/z3CaKoZGc6Ge273mIAgYt55hLzHj3iyB tfIJU+hg3C00yJVcWoZsraGtxOC4bJS1yPatPT7LwHi6M2khJ4fPV2ZAiQyXAxrY51nI ByJRprSf0aq09yr8bVN3n+R0O0ycwgbD8fa9bV1VSoIV24kDINrj0NIGuMtWpdIaSYu1 JfWr33fpQ1255dh8kkS/l9sJ0Rgh41OKtO4UWcTNZDj90VgY/CjOT7LCcyC018k58qp0 WB3g==
X-Gm-Message-State: ALoCoQlKnn9YiWjVLDpYzUPrzhrDUnlwrJnvVbKRN8yMWUYzt8WUDZv6rJsDie/wJD6Pn3DtoJYQKOQ1wx1iv5OFFXWnHKdc9w==
X-Received: by 10.140.175.7 with SMTP id v7mr51282353qhv.103.1453330538039; Wed, 20 Jan 2016 14:55:38 -0800 (PST)
Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id d6sm15232016qkb.13.2016.01.20.14.55.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 14:55:37 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_ADF6BD98-8CDE-48B3-8214-A8775BFBC8BB"; 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: <CABzCy2BZvvqZxmEGdf1b61Ra52W2jo-vak1gEHQ0_KhKg3aBNA@mail.gmail.com>
Date: Wed, 20 Jan 2016 19:55:32 -0300
Message-Id: <C45284CB-7E6C-4DDA-8475-6C608984D909@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> <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com> <CABzCy2BZvvqZxmEGdf1b61Ra52W2jo-vak1gEHQ0_KhKg3aBNA@mail.gmail.com>
To: Nat Sakimura <sakimura@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/KTrrfGONCO6dATEcM3KV-q5zQTE>
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:55:42 -0000

We have been talking about providing the resource or audience as the input.

The resource type would be more abstract than audience.  

That is something we would need to discuss in a spec.

The problem foe POP is that the same scope may cover multiple resource endpoints.  Especially when using a symmetric key you need to specify what Resource server you are sending the token to so that it can be encrypted with the correct key.

John B.
> On Jan 20, 2016, at 7:47 PM, Nat Sakimura <sakimura@gmail.com>; wrote:
> 
> +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: 
> 
> The client request an access to the resource type in the scope of the authorization request. 
> The client request an access token to the resource type to the token endpoint with audience/resource/scope parameter. 
> 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年1月21日(木) 7:27 John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>:
> +1
> 
>> On Jan 20, 2016, at 7:25 PM, Mike Jones <Michael.Jones@microsoft.com <mailto: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>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>