IETF Logo Mail Archive

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 21 July 2018 16:40 UTC

Return-Path: <torsten@lodderstedt.net>
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 49F4D130E46 for <oauth@ietfa.amsl.com>; Sat, 21 Jul 2018 09:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 ZNCNuqaoLBIz for <oauth@ietfa.amsl.com>; Sat, 21 Jul 2018 09:40:15 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB27130DFF for <oauth@ietf.org>; Sat, 21 Jul 2018 09:40:14 -0700 (PDT)
Received: from [80.187.120.149] (helo=[10.150.89.103]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1fguvS-0000Ge-Lt; Sat, 21 Jul 2018 18:40:10 +0200
Content-Type: multipart/signed; boundary="Apple-Mail-647604C8-5B33-4C22-9498-E9776A27D3FB"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPad Mail (15F79)
In-Reply-To: <CAD9ie-saxrBABtc6Z5AQLT9M0tk92HF7ATZBETPTaC=TnfstMw@mail.gmail.com>
Date: Sat, 21 Jul 2018 18:40:09 +0200
Cc: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <47B1C568-D395-42D7-B1CC-C7A718AECB89@lodderstedt.net>
References: <CAGL6ep+p-JsvuT5imuNN=NXg2rGX98omibO7KeGxAu3yGpaiWg@mail.gmail.com> <CA+k3eCRy_1_pgB=KWJMOgUAEgwX_jrSkpBrffk__khV_Jv1nDA@mail.gmail.com> <TY2PR01MB22971D8FB9BCA1513C3794E9F9510@TY2PR01MB2297.jpnprd01.prod.outlook.com> <426DBA0B-CC9B-4D9D-9ED8-5AD779159638@lodderstedt.net> <CALAqi_-hciPUdQbq7kmu-mJMECjVzj_Xp_vDsdYi_yCDCG8=wg@mail.gmail.com> <CA+k3eCQx3puZsgyBGf=GAeAcYmrJMTgkU90WUu3W-VNU6-KurQ@mail.gmail.com> <MW2PR00MB0300E556CAC7F285C11DB784F5510@MW2PR00MB0300.namprd00.prod.outlook.com> <CAD9ie-saxrBABtc6Z5AQLT9M0tk92HF7ATZBETPTaC=TnfstMw@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/K6dxJjFwL5ewLyJL4Jd3DZKb7os>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
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: Sat, 21 Jul 2018 16:40:20 -0000

Hi Dick,

> Am 20.07.2018 um 19:46 schrieb Dick Hardt <dick.hardt@gmail.com>:
> 
> There are a few places where multiple resources could be used:
> 
> One is in the code flow where it is desirable to optimize the user experience so that the user is granting authorization once, and not multiple times. 
> 

I agree. That’s the reason why I’m advocating multiple resource.

> The second is in the access token request, which leads to the third instance, which is in the access token. If an access token is being returned for each resource, then making a single request is simpler, it seems to complicate the interface more.

I agree.

> 
> If we want to have audience constrained access tokens, then it is safer to have only one resource in the access token - otherwise each resource can use the access token to access the other resources.

Yes and no. Yes because it’s safer to use tightly audience restricted access tokens.

No because token binding or cert-bound access tokens can prevent abuse in such a case.

> 
> All of these examples assume that it is a single AS. Supporting multiple AS in a single request seems super complicated and wrought with security and trust issues.

I don’t see a use case for multiple AS (yet ;-).

kind regards,
Torsten.
> 
> 
> 
> 
>> On Fri, Jul 20, 2018 at 11:13 AM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:
>> While I agree that a single requested resource is the common case, enough people have spoken up with a need for multiple requested resources over the years that I think everyone will be better served by leaving the ability to specify multiple requested resources in the specification.
>> 
>>  
>> 
>>                                                        -- Mike
>> 
>>  
>> 
>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
>> Sent: Friday, July 20, 2018 10:18 AM
>> To: Filip Skokan <panva.ip@gmail.com>
>> 
>> 
>> Cc: oauth <oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"
>>  
>> 
>> The current draft does allow multiple "resource" parameters. However, there seemed to be consensus in the WG meeting yesterday that only a single "resource" parameter was preferable and that a client could obtain an access token per resource  (likely using a refresh token). I'm personally sympathetic to that point. But maybe it's too restrictive. I would like to see some more text about the complexity implications of multiple "resource" parameters and perhaps some discouragement of doing so. I believe logical names are more potentially useful in an STS framework like token exchange but should be out of scope for this work.  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan <panva.ip@gmail.com> wrote:
>> 
>> Hi Torsten,
>> 
>>  
>> 
>> > Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at multiple resource servers.
>> 
>>  
>> 
>> That's already in. Furthermore what about logical names for target services? Like was added in -03 of token exchange?
>> 
>> 
>> 
>> Best,
>> Filip Skokan
>> 
>>  
>> 
>>  
>> 
>> On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> 
>> I support adoption of this document.
>> 
>>  
>> 
>> I would like to point out (again) a single resource is not sufficient for most use cases I implemented in the last couple if years. I‘m advocating for enhancing the draft to support multiple resources and a clear definition of the relationship between resource(s) and scope.
>> 
>> 
>> Am 20.07.2018 um 08:20 schrieb n-sakimura <n-sakimura@nri.co.jp>:
>> 
>> +1
>> 
>>  
>> 
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
>> Sent: Friday, July 20, 2018 7:42 AM
>> To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
>> Cc: oauth <oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"
>> 
>>  
>> 
>> I support adoption of this document.
>> 
>>  
>> 
>> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
>> 
>> Hi all,
>> 
>> This is the call for adoption of the 'Resource Indicators for OAuth 2.0' document
>> following the positive call for adoption at the Montreal IETF meeting.
>> 
>> Here is the document:
>> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
>> 
>> Please let us know by August 2nd whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>> 
>> Regards,
>> Rifaat
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>>  
>> 
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>> 
>> _______________________________________________
>> 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
>> 
>>  
>> 
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>> 
>> 
>> _______________________________________________
>> 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

v2.23.0 | Report a Bug | By Email