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 <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 >>> >>> -- _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
