Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01
George Fletcher <gffletch@aol.com> Mon, 28 January 2019 22:12 UTC
Return-Path: <gffletch@aol.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1E31311D6 for <ace@ietfa.amsl.com>; Mon, 28 Jan 2019 14:12:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 MX4xLQ2svpOD for <ace@ietfa.amsl.com>; Mon, 28 Jan 2019 14:12:09 -0800 (PST)
Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (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 BA93A130EE5 for <ace@ietf.org>; Mon, 28 Jan 2019 14:12:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1548713527; bh=vQvhLQcIXJWbVb6tvCRNuVIxiVGA5CbWUmTjOF7XG84=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=qEydn8aeUC61culQ8rpQEhxISgg5+M6M0wbNe70o15Fl3JXYtFTSpIiJkgKODi6Qcg+GFMOZF7M/40IAtTiNExvh5s/lF8wT3nqzk0LYbPGqj2VCr7PEKrfkmXdamGhSWJyZEGRQOGgaRL+mFv3aXNW09IOe1Awx653qB/Q+C6jVSE8BGpJ4FQo1aMzxQKcikNQu+70UsBEJ3hATuS73A7TqHYiXsvPHbq2Ex7EFDj7FVbKNTXCJJI3Jyc+Vs+20PLTXTdMyXmtPSOdNklFeagSe1isRxEgQcrHYZsn/GdDgHoZLktBDHxwNjHQY42S0C8aKVS0XWRmc0jYytmJ/LA==
X-YMail-OSG: BqN2C74VM1lcCVEnVsy19KhljNmH.3.BYOJPZFFX5BmUyg06wut0xY5rk9.lwU_ md.ssBgUWO3FyNhiUdekDNGzN40YznhnL7gFFxRhvV58DofFyUA3o4TekdcOyuSQQNLeYdapr1j8 pIRj3yoYPndT84h2elzMnRNrj9mG5.u4hJW5_GKM.gBdxerYNWXljd253j4QNll.6golHrJkBLcd AV7VfOHK2H2X3mN4jPQMbPd0cMYZ1ISxYZFpann51nd0T26eQUTJVxuaOHZIoos5rb8z7YOGTYE7 Zpftvg9OcfUgELgUBsxBV3bPEhfPOw3cjSTXPUaLjS6RBS98AcW5LoW_H042dyYeLPzDgbhbkHki uJOw4.T.yvfMoYwrVDimodCaxbLiIj9k3hAZ60j0V8ZZS2BfeZYeIzabGmE5gKnKjKC_BD.FiOk0 er7OFu.nSicTtDiJaCO4eD3BwBfn.pzyGB_yKn03bt.n5b5FlkHQN7CrJueHU1iEkn89WLCdhPws msVo_BHjQ9porWJKPM_3nSAzD2ZPOenod_AKtaC9SpZ2jtsB_a9f4kkus7xk3v8PPJC9XbGI1_dI NGV4fZ2FKmnUoS5a8oJdCm.oMrNjFrl4QWIbqGnkWG_CNGv_gJrjhkaCAsi5IbQddxmT_aQv5zh3 x9fih822WF8hIDmRQ1qxDChxXBIC_oYln99NG8s4szyaHjJq_AYCdJF2Gl5EF6uRXEbOsgceCubj kh8xowBB50VtdFTkBaEk2g64JsUv8G9nu.tVvWpeccg3uzXHVNJENSIGfr02h7.vNVKOrx7JZnS9 TiLub76A18xHMFUDpd8zO7ATQOkcKGGbSVyhGJBYQpyE786eVkXUP6iTbHCZQJSNe_THi6z_Y5RH QJolchPJjS7hLh.osMknmn6_wMqBnhgv2Shva.neREzGRrpzsHf_jBoR1zP.Ehv2a_YQEgVk0tkq trCPdU3Dx_taD5r2omzGwF8uigXteK.GQaV2Tc1AWlmO3M36.ubw7HwmtBD3UDVgHcYzS2Bd3the prek5OUwN1fTQEqyHrr3_LHGfRmP.Cz79hoS3.WheFryIGZF9NYk1jMkV5bKTF0Xp.w0PpW_nVA- -
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Mon, 28 Jan 2019 22:12:07 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp417.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e30a89303b267a154ac0f0d07589e754; Mon, 28 Jan 2019 22:12:03 +0000 (UTC)
To: Brian Campbell <bcampbell@pingidentity.com>, Mike Jones <Michael.Jones@microsoft.com>, ace@ietf.org
Cc: "oauth@ietf.org" <oauth@ietf.org>, Vittorio Bertocci <vittorio.bertocci@auth0.com>
References: <CAGL6epKeGW195z2SJdcXU-MyVBwTBDnsvGeo7mNJvn8UkAWmnw@mail.gmail.com> <CAGL6epKRkmf9YJCk7DV51vG9UgTzfxM5Da35w9CEYRuN+Js3kw@mail.gmail.com> <CAO_FVe6+2eexcqkreKnV43stoAsA8-+RMRZEK7_EhJk+OA7X_A@mail.gmail.com> <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <DM5PR00MB0293B214D198F4D9DBD08814F5990@DM5PR00MB0293.namprd00.prod.outlook.com> <CAO_FVe6CecdCxtJ78FcZ6pFJZwu6dudomjFgVeLr_cHNFbUZXQ@mail.gmail.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <CAGL6epKismmWSnNcca41HWHEGhaJG7XhOULUwAz9jd5AemvuOg@mail.gmail.com> <BL0PR00MB02920F6A16D28D1652F21B2DF59A0@BL0PR00MB0292.namprd00.prod.outlook.com> <CAGL6epKjUJQNZdyHjrsJYvXE_p8QvjqxhcxXVnax2_VJ3qMO6g@mail.gmail.com> <CA+k3eCT-dU96D+_LdCtZGMA2TJij2Jzc=BgzCDkbkBGf=jKWnA@mail.gmail.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <BL0PR00MB029262B150B2D8F3C3792302F5960@BL0PR00MB0292.namprd00.prod.outlook.com> <CA+k3eCT+ndfChx1-tqsxyqg8kX5Sc=BDw6UJyu2VQU3MDs1ssQ@mail.gmail.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com>
Date: Mon, 28 Jan 2019 17:12:02 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCT+ndfChx1-tqsxyqg8kX5Sc=BDw6UJyu2VQU3MDs1ssQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------1CD0A9136094A3FD1F9AE843"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/g38V9qW3aimiJOUCtIukn7Wbthw>
Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jan 2019 22:12:16 -0000
I also don't know that this raises to the level of "concern" but I find the parameter name of "req_aud" odd. Given that the parameter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the thread on the ACE working group list so there could be very good reasons for the chosen name:) I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters that cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they are distinctly separate? Thanks, George On 1/28/19 3:54 PM, Brian Campbell wrote: > [added ace@ietf.org <mailto:ace@ietf.org> kinda per suggestion from Mike] > > I don't know that there are concerns about “req_aud” per se. > Admittedly, I did use the word "concerns" but I was more trying to say > that referencing it from the draft-ietf-oauth-resource-indicators > document wasn't needed to address Vittorio's request. And pointing out > that “req_aud” is defined for the token endpoint while the > draft-ietf-oauth-resource-indicators document also deals with the > authorization endpoint so such a reference wouldn't really work anyway. > > I don't know of anyone that just works from the OAuth parameter > registration but maybe I'm just out of touch. And I don't think its a > stretch at all to observe that ACE OAuth and OAuth 2 are different. > > > > On Mon, Jan 28, 2019 at 11:28 AM Mike Jones > <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote: > > Brian, etc. If you have concerns about “req_aud”, now’s the time > to provide that feedback to the ACE WG, as they’re trying to > complete that draft soon. Please join the ACE WG mailing list and > send your feedback there directly. > > You and I may know that ACE OAuth and OAuth 2 are pretty different > but developers later will just see the OAuth parameter > registration and won’t realize that it’s coming from a different > universe. If we can harmonize things now, we should. > > -- Mike > > *From:*OAuth <oauth-bounces@ietf.org > <mailto:oauth-bounces@ietf.org>> *On Behalf Of *George Fletcher > *Sent:* Monday, January 28, 2019 10:05 AM > *To:* Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org > <mailto:40pingidentity.com@dmarc.ietf.org>> > *Cc:* oauth@ietf.org <mailto:oauth@ietf.org>; Vittorio Bertocci > <vittorio.bertocci@auth0.com <mailto:vittorio.bertocci@auth0.com>> > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > +1 > > I came to a similar conclusion over the weekend. If > https://api.example.com/mail <https://api.example.com/mail> is an > allowed location URI, how is it not also a logical location > considering it's possible there are multiple endpoints "below" > https://api.example.com/mail? (e.g. > https://api.example.com/mail/user/mailbox). Also if > https://api.example.com is really a load balancer that fronts the > " > <https://api.example.com/mail?(e.g.https://api.example.com/mail/user/mailbox).Alsoifhttps://api.example.comisreallyaloadbalancerthatfrontsthe>real" > endpoints, then it's also "logical" in that context and not an > exact location. > > This brings me to the conclusion that all the resource identifiers > are "logical" along a range of specificity. How specific a > resource is identified is really a risk decision and based on the > deployment model can be managed at either the RS or the AS. > > Thanks, > George > > On 1/28/19 9:07 AM, Brian Campbell wrote: > > I plan on joining the meeting today at noon eastern time to > discuses this little ditty. I hope others who have a stake in > it can too. > > The proposed changes that Vittorio and I put together can be > seen in the diff of this pull request > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files > and I even put a xml2rfc'ed text version on > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 > for ease of reference. I maintain that is the most > straightforward way forward with all this. Yet another new > additional parameter could be defined for the logical case but > I struggle to see the value in doing so. The 'resource' is URI > that points to the resource. The level of specificity of that > pointer is intentionally a bit fuzzy and > application/deployment specific. Is > https://graph.microsoft.com (mentioned in the documentation > previously linked) a location or an abstract identifier or > both? The document already (somewhat awkwardly) describes > using a "base URI" for the application or resource. Is that a > a location or an abstract identifier? Or kinda both? > > In addition to the concerns others have expressed about > "req_aud", I"d note that draft-ietf-ace-oauth-params defines > its use only at the token endpoint as one of the "additional > parameters for requesting an access token from a token > endpoint in the ACE framework". Whereas the > resource-indicators draft scope includes the authorization > endpoint too. Furthermore, while the ACE WG is building on > OAuth, for all intents and purposes ACE and regular OAuth are > different worlds and I think a reference in regular OAuth > document like this one to "Additional OAuth Parameters for > Authorization in Constrained Environments (ACE)" would be a > disservice to just about everyone. > > On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef > <rifaat.ietf@gmail.com <mailto:rifaat.ietf@gmail..com>> wrote: > > Hannes sent an update to this meeting here: > > https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU > > Regards, > > Rifaat > > On Thu, Jan 24, 2019 at 6:20 PM Mike Jones > <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>> wrote: > > The virtual office hours in my calendar start 1/2 hour > before that. If the time has changed, can you have > the meeting organizer update the calendar entry? > > Thanks, > > -- Mike > > *From:* Rifaat Shekh-Yusef <rifaat.ietf@gmail.com > <mailto:rifaat.ietf@gmail.com>> > *Sent:* Thursday, January 24, 2019 12:46 PM > *To:* George Fletcher <gffletch@aol.com > <mailto:gffletch@aol.com>> > *Cc:* Vittorio Bertocci <Vittorio@auth0.com > <mailto:Vittorio@auth0.com>>; Mike Jones > <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>>; oauth@ietf.org > <mailto:oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > All, > > This coming Monday, Jan 28 @ 12:00pm Eastern Time, we > have a scheduled OAuth WG Virtual Office meeting. > > Feel free to attend the meeting to discuss this topic > to try to get to a conclusion on this. > > Regards, > > Rifaat > > On Wed, Jan 23, 2019 at 3:00 PM George Fletcher > <gffletch=40aol.com@dmarc.ietf.org > <mailto:40aol.com@dmarc.ietf.org>> wrote: > > +1 > > Also, I don't really like the parameter name > 'req_aud' :) I'm not 100% convinced that > 'audience' and 'logical resource' are completely > overlapping concepts. We can potentially make them > completely overlapping but we need text to that > effect. > > I also believe that we don't have a complete > solution for all deployments using exact locations > (see my previous email). > > Thanks, > George > > On 1/23/19 2:50 PM, Vittorio Bertocci wrote: > > As mentioned below, I agree the two can be > separated- but I also agree with George on the > need to be clear an easy to reference for > developers. > > Just adding a reference to req_aud would just > raise the cyclomatic complexity of the specs, > which is already unusably high for mere > mortals in the OAuth2/OIDC family of specs. > > One additional complication is that this > specification is reusing a parameter that is > already used in a *very* large number of > production systems (small example here > <https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code>), > and whose concrete semantic happens to be > prevalently logic identifier. If the parameter > you are defining here has a different > semantic, at the very least it would seem good > hygiene to rename it to avoid collision and > confusion. > > On Wed, Jan 23, 2019 at 11:03 AM Mike Jones > <Michael.Jones=40microsoft.com@dmarc.ietf.org > <mailto:40microsoft.com@dmarc.ietf.org>> wrote: > > I agree with John’s logic. The physical > resource and logical resource should use > different identifiers. Fortunately, we > already have “resource” and “req_aud” for > these parameters. I believe we’re good to > go, as-is. > > -- Mike > > *From:* OAuth <oauth-bounces@ietf.org > <mailto:oauth-bounces@ietf.org>> *On > Behalf Of *John Bradley > *Sent:* Wednesday, January 23, 2019 10:56 AM > *To:* oauth@ietf.org <mailto:oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] Shepherd > write-up for > draft-ietf-oauth-resource-indicators-01 > > I don't think they are necessarily > mutually exclusive, that is why I think > there is value in allowing them to be > specified separately. > > As an AS in the distributed OAuth case > knowing that a client interacting with RS > https://fire.hhs.com as the resource wants > a OAuth token with an audience of HHS and > a scope of read. > > Without proof of possession we need to > keep bad RS from asking for tokens with > scopes and audiences of other RS that can > be replayed. > > I really like keeping the resource simple > and unspoofable, it is the URI of the RS > where you are presenting the AT. > > I prefer to keep that separate from the > logical resource that may span more than > one RS endpoint. > > Merging the two and we are probably back > at the AS looking into the URI to figure > out which one it is. I think that is > harder for implementations and more likely > to have security issues down the road. > > John B. > > On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: > > Hi all, > > thanks for you patience. Brian and > myself iterated on modifying the text > to cover the logical identifier use > case, highlighting the security > implications of going that route. You > can find the revised text in > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, > see the commits in the history from > January 21 for the specific changes. > > Note: I also had a chat with John > offline, and he expressed the desire > to split the resource parameter in two > distinct parameters to better signal > the intended usage. I am sure he can > elaborate. I have nothing against it > in principle, as long as we leave > nothing as exercise to the reader and > we are very clear on usage (e.g. > mutual exclusivity, etc) but didn't > have a chance to speak w Brian about > it. If the discussion stretches > further, I would suggest we pause it > and let him enjoy his time off for the > rest of the week. > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat > Shekh-Yusef <rifaat.ietf@gmail.com > <mailto:rifaat.ietf@gmail.com>> wrote: > > Thank you guys! > > > > On Monday, January 21, 2019, > Vittorio Bertocci > <Vittorio@auth0.com > <mailto:Vittorio@auth0.com>> wrote: > > Hi Rifaat, > > absolutely. Brian and myself > already started working on > some language, however this > week he is in vacation hence > it might take few days before > we come back to the list with > something. > > Cheers, > > V. > > On Mon, Jan 21, 2019 at 9:35 > AM Rifaat Shekh-Yusef > <rifaat.ietf@gmail.com > <mailto:rifaat.ietf@gmail.com>> > wrote: > > Brian, Vittorio, > > To move this discussion > forward, can you guys > suggest some text to make > the logical identifier > usage clearer? > > Regards, > > Rifaat > > On Mon, Jan 21, 2019 at > 10:32 AM Brian Campbell > <bcampbell=40pingidentity.com@dmarc.ietf..org > <mailto:40pingidentity.com@dmarc.ietf.org>> > wrote: > > As I suggested before, > I do think that's > within the bounds of > the draft's definition > of 'resource' as a > URI. And that perhaps > all that's needed is > some minor adjustment > and/or augmentation of > some text to make it > more clear. > > On Sun, Jan 20, 2019 > at 7:39 PM Vittorio > Bertocci > <Vittorio@auth0.com > <mailto:Vittorio@auth0.com>> > wrote: > > [sent to John only > by mistake, > resending to the ML] > > In Azure AD v1 & > ADFS, that's > resource.. It > could be used for > both network and > logical ids, with > the concrete usage > in the wild I > described earlier. > > In Azure AD v2, > the resource as > explicit parameter > (network, logic or > otherwise) is gone > and is expressed > as part of the > scope string of > all the scopes > requested for a > given resource- > but it still exist > in practice tho as > it still end up in > the resulting > aud of the issued > token. > > This is 9 months > old info hence > > On Sun, Jan 20, > 2019 at 17:58 John > Bradley > <ve7jtb@ve7jtb.com > <mailto:ve7jtb@ve7jtb.com>> > wrote: > > What is the > parameter that > Microsoft is > using? > > On 1/20/2019 > 3:59 PM, > Vittorio > Bertocci wrote: > > First of > all, it > wasn't my > intent to > disrupt > the > established > process. > In my > former > position I > wasn't > monitoring > those > discussions > hence I > didn't > have a > chance to > offer > feedback. > When I saw > something > that gave > me the > impression > might lead > to issues, > and given > that I > worked > with > actual > deployments > and > developers > using a > similar > parameter > for a long > time, I > thought > prudent to > bring this > up. I > really > appreciate > Rifaat's > stance on > this. End > of preamble. > > Ultimately > my goal is > for > developers > to have > guidance > on how to > work with > the > concept of > logical > resource > in a > standard > compliant > way, hence > it doesn't > strictly > matter > whether > the > definition > of the > corresponding > parameter > lives > in oauth-resource-indicators > or elsewhere. > > That said. > Reading > through > the draft, > it would > appear > that most > of the > reasons > for which > the spec > was > created > apply to > both the > network > addressable > and the > logical > resource > types: > knowing > what keys > to use to > encrypt > the token, > constrain > access > tokens to > the > intended > audience, > avoiding > overloading > scopes > with > resource > indicating > parts... > those all > apply to > network > addressable > and logic > identifiers > alike. And > both > parameters > are > expected > to result > in > audience > restricted > tokens. It > seems the > only > difference > comes at > token > usage > time, with > the > network > addressable > case > giving > more > guarantees > that the > token will > go to its > intended > recipient, > but the > request > and > audience > restriction > syntax > seems to > be exactly > the same. > > On top of > this: in > the > 99.999% of > the > scenarios > I > encountered > in the > wild in > the last 5 > years of > using the > resource > parameter > in the MS > ecosystem, > the > resource > identifier > was known > at design > time: the > developer > discovered > it out of > band and > placed it > in the app > config at > deployment > time. > Those > aren't > fringe > cases I > occasionally > encountered: > the > resource > parameter > in Azure > AD v1 and > ADFS was > mandatory, > hence > literally > every > solution i > saw or > touched > used it. > As Brian > suggested, > this is a > scenario > where the > security > advantages > of the > network > addressable > case > aren't as > pronounced > as in the > case in > which the > client > discovers > the > resource > identifier > at > runtime. > This isn't > just > because > there is > no > specification > suggesting > location > should be > explicitly > indicated, > it's > because > there are > many > practical > advantages > at > development > and > deployment > time to be > able to > use > logical > identifiers- > and if the > /concrete > /security > advantages > don't > apply to > the their > case, > people > will > simply not > comply. > > In > summary: > creating > two > different > parameters > in two > different > documents > is better > than > ignoring > he logical > identifier > case > altogether, > however I > think that > not > acknowledging > the > logical id > case > in oauth-resource-indicators > is going > to create > confusion > and > ultimately > not be as > useful to > the > developer > community > as it > could be. > > On Sat, > Jan 19, > 2019 at > 12:38 Phil > Hunt > <phil.hunt@oracle.com > <mailto:phil.hunt@oracle.com>> > wrote: > > +1 to > Mike > and > John’s > comments. > > Phil > > > On Jan > 19, > 2019, > at > 12:34 > PM, > Mike > Jones > <Michael.Jones=40microsoft.com@dmarc.ietf.org > <mailto:Michael.Jones=40microsoft.com@dmarc.ietf.org>> > wrote: > > I > also > agree > that > “resource” > should > be > a > specific > network-addressable > URL > whereas > a > separate > audience > parameter > (like > “aud” > in > JWTs) > can > refer > to > one > or > more > logical > resources. > They > are > different, > if > related, > things. > > Note > that > the > ACE > WG > is > proposing > to > register > a > logical > audience > parameter > “req_aud” > in > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 > - > partly > based > on > feedback > from > OAuth > WG > members. > This > is > a > general > OAuth > parameter, > which > any > OAuth > deployment > will > be > able > to > use. > > I > therefore > believe > that > no > changes > are > needed > to > draft-ietf-oauth-resource-indicators, > as > the > logical > audience > work > is > already > happening > in > another > draft. > > -- > Mike > > *From:* > OAuth > <oauth-bounces@ietf.org > <mailto:oauth-bounces@ietf.org>> > *On > Behalf > Of > *John > Bradley > *Sent:* > Saturday, > January > 19, > 2019 > 9:01 > AM > *To:* > Brian > Campbell > <bcampbell@pingidentity.com > <mailto:bcampbell@pingidentity.com>> > *Cc:* > Vittorio > Bertocci > <Vittorio=40auth0.com@dmarc.ietf.org > <mailto:Vittorio=40auth0.com@dmarc.ietf.org>>; > IETF > oauth > WG > <oauth@ietf.org > <mailto:oauth@ietf.org>> > *Subject:* > Re: > [OAUTH-WG] > Shepherd > write-up > for > draft-ietf-oauth-resource-indicators-01 > > We > need > to > decide > if > we > want > to > make > a > change. > > > For > security > we > are > location > centric. > > > I > prefer > to > keep > resource > location > separate > from > logical > audience > that > can > be > a > scope > or > other > parameter. > > > If > becomes > harder > for > people > to > use > the > parameter > correctly > if > we > are > too > flexible. > > > I > would > rather > have > a > separate > logical > audience > parameter > if > we > think > we > want > one. > > John > B. > > On > Sat, > Jan > 19, > 2019, > 11:41 > AM > Brian > Campbell > <bcampbell@pingidentity.com > <mailto:bcampbell@pingidentity.com> > wrote: > > No > apology > needed, > Rifaat. > And > I > apologize > if > what > I > said > came > off > the > wrong > way. > I > was > just > trying > to > make > light > of > the > situation.. > And > I > agree > that > we > should > not > be > hamstrung > by > the > process > and > there > are > times > when > it > makes > sense > to > be > flexible > with > things. > > > On > Fri, > Jan > 18, > 2019 > at > 6:22 > PM > Rifaat > Shekh-Yusef > <rifaat.ietf@gmail.com > <mailto:rifaat.ietf@gmail.com>> > wrote: > > Sorry > Brian, > I > was > not > clear > with > my > statement. > > I > meant > to > say > that > we > should > not > allow > the > process > to > prevent > the > WG > from > producing > a > quality > document > without > issues, > assuming > there > is > an > issue > in > the > first > place. > > Ideally > we > want > to > get > these > identified > during > the > WGLC, > but > things > happen > and > sometimes > the > WG > misses > something. > > > I > hear > you > and > agree > that > this > make > things > difficult > for > authors. > We > will > make > sure > that > this > does > not > become > the > norm, > and > we > will > try > to > stick > to > the > process > as > much > as > possible. > > Regards, > > Rifaat > > On > Fri, > Jan > 18, > 2019 > at > 5:35 > PM > Brian > Campbell > <bcampbell@pingidentity.com > <mailto:bcampbell@pingidentity.com>> > wrote: > > Thanks > Rifaat. > Process > is > as > process > does, > right? > I > do > kinda > want > to > grumble > about > WGCL > having > passed > already > but > that's > mostly > because > replying > to > these > kinds > of > threads > is > hard > for > me > and > I'll > just > get > over > it... > > > As > far > as > I > understand > things, > the > security > concerns > come > into > play > when > the > client > is > being > told > the > by > the > resource > how > to > identity > the > resource > like > is > described > in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 > and > using > the > actual > location > in > that > context > ,along > with > some > other > checks > prescribed > in > that > draft, > prevents > the > kind > of > issues > John > described > earlier > in > the > thread. > > > In > cases > where > the > client > knows > the > resource > a > priori > or > out-of-band > or > configured > or > whatever, > I > don't > think > the > same > security > concerns > arise. > And > using > such > a > known > value, > be > it > an > actual > location > or > logical > representation, > would > be > okay. > > The > resource-indicators > draft > is > admittedly > somewhat > location-centric > in > how > it > talks > about > the > value > of > the > 'resource' > parameter. > But > ultimately > it > defines > it > as > an > absolute > URI > that > indicates > the > location > of > the > target > service > or > resource > where > access > is > being > requested. > A > location > can > be > varying > shades > of > abstract > and > I'd > say > that > using > a > URI > as > 'resource' > parameter > value > that's > a > logical > identifier > that > points > to > some > resource > is > well > within > the > bounds > of > the > draft. > > > So > maybe > the > draft > is > okay > as > is? > > Or > perhaps > that's > too > much > to > be > left > as > an > exerciser > to > the > reader? > And > some > text > should > be > added > and/or > adjusted > so > the > resource-indicators > draft > would > be > a > little > more > open/clear > about > the > parameter > value > potentially > being > more > of > a > logical > or > abstract > identifier > and > not > necessarily > a > network > addressable > URL? > > On > Fri, > Jan > 18, > 2019 > at > 1:18 > PM > Rifaat > Shekh-Yusef > <rifaat.ietf@gmail.com > <mailto:rifaat.ietf@gmail.com>> > wrote: > > I > wouldn't > worry > too > much > about > the > process. > > If > it > makes > sense > to > update > the > document, > then > feel > free > to > do > that. > > Regards, > > Rifaat > > On > Fri, > Jan > 18, > 2019 > at > 3:08 > PM > John > Bradley > <ve7jtb@ve7jtb.com > <mailto:ve7jtb@ve7jtb.com>> > wrote: > > Yes > the logical > resource > can > be > provided > by > "scope" > > Some > implementations > like > Ping > and > Auth0 > have > been > adding > another > parameter > "aud" > to > identify > the > logical > resource > and > then > using > scopes > to > define > permissions > to > the > resource. > > Fortunately, > we > are > using > a > different parameter > name > so > not > stepping > on > that.. > > We > could > go > back > and > try > to > add > text > explaining > the > difference, > but > we > are > quite > late > in > the > process. > > > I > agree > that > a > logical > resource > parameter may > be > helpful, > but > perhaps > it > should > be > a > separate > draft. > > John > B. > > On > Fri, > Jan > 18, > 2019 > at > 4:38 > PM > Richard > Backman, > Annabelle > <richanna@amazon.com > <mailto:richanna@amazon.com>> > wrote: > > Doesn’t > the > “scope” > parameter > already > provide > a > means > of > specifying > a > logical > identifier? > > -- > > > Annabelle > Richard > Backman > > AWS > Identity > > *From: > *OAuth > <oauth-bounces@ietf.org > <mailto:oauth-bounces@ietf.org>> > on > behalf > of > Vittorio > Bertocci > <Vittorio=40auth0.com@dmarc.ietf.org > <mailto:40auth0..com@dmarc.ietf.org>> > *Date: > *Friday, > January > 18, > 2019 > at > 5:47 > AM > *To: > *John > Bradley > <ve7jtb@ve7jtb.com > <mailto:ve7jtb@ve7jtb.com>> > *Cc: > *IETF > oauth > WG > <oauth@ietf.org > <mailto:oauth@ietf.org>> > *Subject: > *Re: > [OAUTH-WG] > Shepherd > write-up > for > draft-ietf-oauth-resource-indicators-01 > > Thanks > John > for > the > background. > > > I > agree > that > from > the > client > validation > PoV, > having > an > identifier > corresponding > to > a > location > makes > things > more > solid. > > That > said: > the > use > of > logical > identifiers > is > widespread, > as > it > has > significant > practical > advantages > (think > of > services > that > assign > generated > hosting > URLs > only > at > deployment > time, > or > services > that > are > somehow > grouped > under > the > same > logical > audience > across > regions/environment/deployments). > People > won't > stop > using > logical > identifiers, > because > they > often > have > no > alternative > (generating > new > audiences > on > the > fly > at > the > AS > every > time > you > do > a > deployment > and > get > assigned > a > new > URL > can > be > unfeasible). > Leaving > a > widely > used > approach > as > exercise > to > the > reader > seems > a > disservice > to > the > community, > given > that > this > might > lead > to > vendors > (for > example > Microsoft > and > Auth0) > keeping > their > own > proprietary > parameters, > or > developers > misusing > the > ones > in > place; > would > make > it > hard > for > SDK > developers > to > provide > libraries > that > work > out > of > the > box > with > different > ASes; > and > so > on. > > Would > it > be > feasible > to > add > such > parameter > directly > in > this > spec? > That > would > eliminate > the > interop > issues, > and > also > gives > us > a > chance > to > fully > warn > people > about > the > security > shortcomings > of > choosing > that > approach. > > On > Thu, > Jan > 17, > 2019 > at > 4:32 > PM > John > Bradley > <ve7jtb@ve7jtb.com > <mailto:ve7jtb@ve7jtb.com>> > wrote: > > We > have > discussed > this. > > Audiences > can > certainly > be > logical > identifiers. > > > This > however > is > a > more > specific > location. > The > AS > is > free > to > map > the > location > into > some > abstract > audience > in > the > AT. > > From > a > security > point > of > view > once > the > client > starts > asking > for > logical > resources > it > can > be > tricked > into > asking > for > the > wrong > one > as > a > bad > resource > can > always > lie > about > what > logical > resource > it > is. > > If > we > were > to > change > it, > how > a > client > would > validate > it > becomes > challenging > to > impossible. > > > The > AS > is > free > to > do > whatever > mapping > of > locations > to > identifiers > it > needs > for > access > tokens. > > Some > implementations > may > want > to > keep > additional > parameters > like > logical > audience, > but > that > should > be > separate > from > resource. > > John > B. > > On > 1/17/2019 > 9:56 > AM, > Rifaat > Shekh-Yusef > wrote: > > Hi > Vittorio, > > > The > text > you > quoted > is > copied > form > the > abstract > of > the > draft > itself. > > *Authors,* > > Should > the > draft > be > updated > to > cover > the > logical > identifier > case? > > Regards, > > Rifaat > > On > Thu, > Jan > 17, > 2019 > at > 8:19 > AM > Vittorio > Bertocci > <Vittorio@auth0.com > <mailto:Vittorio@auth0.com>> > wrote: > > Hi > Rifaat, > > > one > detail. > The > tech > summary > says > > An > extension > to > the > OAuth > 2.0 > Authorization > Framework > defining > request > > > parameters > that > enable > a > client > to > explicitly > signal > to > an > authorization > server > > > about > the > *location* > of > the > protected > resource(s) > to > which > it > is > requesting > > > access. > > But > at > least > in > the > Microsoft > implementation, > the > resource > identifier > doesn't > /have/ > to > be > a > network > addressable > URL > (and > if > it > is, > it > doesn't > strictly > need > to > match > the > actual > resource > location). > It > can > be > a > logical > identifier, > tho > using > the > actual > resource > location > there > has > benefits > (domain > ownership > check, > prevention > of > token > forwarding > etc). > > Same > for > Auth0, > the > audience > parameter > is > a > logical > identifier > rather > than > a > location. > > On > Wed, > Jan > 16, > 2019 > at > 6:32 > PM > Rifaat > Shekh-Yusef > <rifaat.ietf@gmail.com > <mailto:rifaat.ietf@gmail.com>> > wrote: > > All, > > > The > following > is > the > first > shepherd > write-up > for > the draft-ietf-oauth-resource-indicators-01 > document. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > Please, > take > a > look > and > let me > know > if > I > missed > anything. > > Regards, > > Rifaat > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > <mailto:OAuth@ietf.org> > 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 > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > <mailto: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 > <mailto: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 > <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto: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 <mailto: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./
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… Brian Campbell
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… George Fletcher
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… Brian Campbell
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… Ludwig Seitz
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… George Fletcher
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… Hannes Tschofenig
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… Hannes Tschofenig
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… Ludwig Seitz
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… Hannes Tschofenig
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… George Fletcher
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… Hannes Tschofenig
- Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-… George Fletcher