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....@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 <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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
