Thanks, This is the first mention that I have heard that resource was already in use by someone.
On Sun, Jan 20, 2019 at 11:39 PM Vittorio Bertocci <vitto...@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 <ve7...@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.h...@oracle.com> wrote: >> >>> +1 to Mike and John’s comments. >>> >>> Phil >>> >>> On Jan 19, 2019, at 12:34 PM, Mike Jones < >>> Michael.Jones=40microsoft....@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-boun...@ietf.org> *On Behalf Of * John Bradley >>> *Sent:* Saturday, January 19, 2019 9:01 AM >>> *To:* Brian Campbell <bcampb...@pingidentity.com> >>> *Cc:* Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org>; IETF >>> oauth WG <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 < >>> bcampb...@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.i...@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 < >>> bcampb...@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.i...@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 <ve7...@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 < >>> richa...@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-boun...@ietf.org> on behalf of Vittorio Bertocci >>> <Vittorio=40auth0....@dmarc.ietf.org <40auth0.....@dmarc.ietf.org>> >>> *Date: *Friday, January 18, 2019 at 5:47 AM >>> *To: *John Bradley <ve7...@ve7jtb.com> >>> *Cc: *IETF oauth WG <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 <ve7...@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 <vitto...@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.i...@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 >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> <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 >>> >>> _______________________________________________ >>> 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
