Thank you guys!
On Monday, January 21, 2019, Vittorio Bertocci <vitto...@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.i...@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....@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. >>>>>> c...@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
