Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"
Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Fri, 03 August 2018 12:09 UTC
Return-Path: <rifaat.ietf@gmail.com>
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 C7FDD130E31 for <oauth@ietfa.amsl.com>; Fri, 3 Aug 2018 05:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fY4u_bV4tS40 for <oauth@ietfa.amsl.com>; Fri, 3 Aug 2018 05:08:59 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 1C5F1130DDB for <oauth@ietf.org>; Fri, 3 Aug 2018 05:08:59 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id d16-v6so5380667itj.0 for <oauth@ietf.org>; Fri, 03 Aug 2018 05:08:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Oi+uk4OA5XpzAT6jWluL1soTjGCSCNypgKHpS/wf0Fk=; b=gTcUryHdGdxoyHbfP2Pi4hy1I2ZjjOVJDtIdTNVlK7rDcVINag7LpBj5JKAzKXR0gz CSdJOFrlibb7HH5ZUomtOr+LdMSjdFQWsdIP8zRK4dCxI1uOEggClCE1bmY4fqht9QZz ROsxkb/LovRG2PApmofW1gvPSXenoOVLCvra/Uv+L0FMgRAnXf0BROyBeG0VVw5fVSBb WLeqG1iv7rH6KjU2sDCfRP3R/9ZrenRhTQjDQBaZupLx8i9e7Qk6KUlnCL2U4pl7UQ3M nO3XdHymH69YAuwy+kFgpowmbuF7Uq1Ro5M2rdOzQti/TGQA+ruQXOcPUD9+2Ygc5HfR AaxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Oi+uk4OA5XpzAT6jWluL1soTjGCSCNypgKHpS/wf0Fk=; b=ba6bXDlFy2uk+5PCL1MY9lXipaQj81rV4jpwFar69qXA9fri5pk8mLv1rSMImOGQpz 2/+/nTbIrBYIjsCvT+GvwRcd+MLBxQpgndvCC4rRphwKKjOJR6gddPZ2YuF5ZzfzT9cc 6hqK+yzRCwIok4NQ6Gb1WH/vmS3UEGzWvccvT3Lf746wCIbq9tRg9aGM8H0Dra5io3kT 5kofUpJE+SoP5W9+/8QeqBy4Sq1vBUC2QqmNJ3cWX7PTZdw/j8bftYPoNIZkE8CTcnXB GCUMOWgV3zestEMBBB85DEjhVwj0B4jC6KV09bE8d+O6IvljmHis5uQtpd0wBcc/KhNd g7Jg==
X-Gm-Message-State: AOUpUlHSjBmXDbwLgoVo/IFGBTK0lBVlfpNVXYJLvxrt7cg+6+QxsXqV 9miAmqCOpPGYmdKTDw2a35fIst9aN/hVa+SKXC1KS3Zy
X-Google-Smtp-Source: AAOMgpfPXTtE4T8IkNWbJo13YA3YItc9d/IWVDpr5ewSuyRw4uD3sScCI5BgpE3pjiStgkR4XLnNN6hdFTder/Ak7Hs=
X-Received: by 2002:a24:c445:: with SMTP id v66-v6mr6060440itf.110.1533298138300; Fri, 03 Aug 2018 05:08:58 -0700 (PDT)
MIME-Version: 1.0
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> <62C4BE6B-5E04-4E93-8083-A6D0895F2740@lodderstedt.net> <CA+k3eCRR3jOvq+odtEtFQOu7pNXKFpfDnTHs8w1KeWGZ7U_CBw@mail.gmail.com>
In-Reply-To: <CA+k3eCRR3jOvq+odtEtFQOu7pNXKFpfDnTHs8w1KeWGZ7U_CBw@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Fri, 03 Aug 2018 08:09:37 -0400
Message-ID: <CAGL6epJ-PuNUakteo0M-gV4VuTri71z8-425y=-uaRqWaWspGw@mail.gmail.com>
To: bcampbell=40pingidentity.com@dmarc.ietf.org
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000de433b057286cad4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RY4LNnfxC84nIf4K9w4hXL9ojfM>
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: Fri, 03 Aug 2018 12:09:03 -0000
All, Based on the feedback during the meeting in Montreal and on the mailing list, we think that the WG has decided to adopt this draft. *Authors,* Feel free to submit a new WG -00 draft. Regards, Rifaat & Hannes On Mon, Jul 23, 2018 at 1:27 PM Brian Campbell <bcampbell= 40pingidentity.com@dmarc.ietf.org> wrote: > My sense is that there's enough WG support to keep the multiple > "resource" parameters at both endpoints. The contextual meaning might be > a bit different at each endpoint - as you point out the refresh token may > represent the overall grant whereas the token request may issue an access > token representing the whole or a subset of the overall grant. There's also > the implicit grant to consider where the access token is returned from the > authorization endpoint. > > The draft hasn't seen any real changes since the initial -00 individual > posting a couple years ago. So, with its impeding adoption, it's overdue > for some updates - especially some more text and/or clarifications on > what's being discussed in this thread. I'm always happy to consider > proposed text from you, Torsten, for any of this stuff. > > > > On Sat, Jul 21, 2018 at 10:34 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Brian, >> >> Am 20.07.2018 um 16:18 schrieb Brian Campbell <bcampbell@pingidentity.com >> >: >> >> 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 >> >> >> I think this makes sense for the token request. This allows the AS to >> audience restrict and token bind the access token to a single resource >> server URL. >> >> and that a client could obtain an access token per resource (likely using >> a refresh token). >> >> >> I think the refresh token may represent the overall grant whereas the >> token request may issue an access token representing the whole or a subset >> of the overall grant. >> >> The question is what this means with respect to the scope. I assume scope >> values are typically bound to a certain resource service. For example, >> “openid email mediacloud#read emailservice#read” would match to permission >> on a OpenID OP, a private cloud and an email service. I therefore would >> suggest the AS may filter the scope down to the values applicable to the >> resource server for which the access token is being minted. >> >> Another question relates to the applicable resource URIs. Do you envision >> any way to constraint the resource URIs for which an access token might be >> created for a particular grant? My feeling is the resource owner should >> have a chance to consent or not in order to prevent the client to access >> resource servers the resource owner does not want it to do so. >> >> 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. >> >> >> As stated above, I’m fine with a single parameter. I could provide some >> text on how the resource parameter could govern the AS behavior in case of >> code and refresh token grant. >> >> I believe logical names are more potentially useful in an STS framework >> like token exchange but should be out of scope for this work. >> >> >> Are you referring to logical resource names? >> >> kind regards, >> Torsten. >> >> >> >> >> >> >> >> >> >> 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 <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.* >> >> > > *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-WG] Call for adoption for "Resource Indica… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Call for adoption for "Resource In… Mike Jones
- Re: [OAUTH-WG] Call for adoption for "Resource In… William Denniss
- Re: [OAUTH-WG] Call for adoption for "Resource In… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Call for adoption for "Resource In… Hannes Tschofenig
- Re: [OAUTH-WG] Call for adoption for "Resource In… William Denniss
- Re: [OAUTH-WG] Call for adoption for "Resource In… Mike Jones
- Re: [OAUTH-WG] Call for adoption for "Resource In… John Bradley
- Re: [OAUTH-WG] Call for adoption for "Resource In… Dick Hardt
- Re: [OAUTH-WG] Call for adoption for "Resource In… Dick Hardt
- Re: [OAUTH-WG] Call for adoption for "Resource In… William Denniss
- Re: [OAUTH-WG] Call for adoption for "Resource In… Brian Campbell
- Re: [OAUTH-WG] Call for adoption for "Resource In… Hannes Tschofenig
- Re: [OAUTH-WG] Call for adoption for "Resource In… n-sakimura
- Re: [OAUTH-WG] Call for adoption for "Resource In… Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption for "Resource In… Filip Skokan
- Re: [OAUTH-WG] Call for adoption for "Resource In… Brian Campbell
- Re: [OAUTH-WG] Call for adoption for "Resource In… Mike Jones
- Re: [OAUTH-WG] Call for adoption for "Resource In… Dick Hardt
- Re: [OAUTH-WG] Call for adoption for "Resource In… Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption for "Resource In… Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption for "Resource In… Brian Campbell
- Re: [OAUTH-WG] Call for adoption for "Resource In… Rifaat Shekh-Yusef