On Mon, Jan 21, 2019, 4:39 PM <[email protected]> wrote:
> Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 (Vittorio Bertocci) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 21 Jan 2019 16:38:47 -0800 > From: Vittorio Bertocci <[email protected]> > To: Rifaat Shekh-Yusef <[email protected]> > Cc: Brian Campbell <[email protected]>, > IETF oauth WG <[email protected]> > Subject: Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > Message-ID: > <CAO_FVe4+X0uZVDATcZSSGhzcv= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > 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 <[email protected]> > 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= > > [email protected]> 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 <[email protected]> > >> 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 <[email protected]> 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 <[email protected]> wrote: > >>>> > >>>>> +1 to Mike and John?s comments. > >>>>> > >>>>> Phil > >>>>> > >>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones < > >>>>> [email protected]> 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 <[email protected]> *On Behalf Of * John Bradley > >>>>> *Sent:* Saturday, January 19, 2019 9:01 AM > >>>>> *To:* Brian Campbell <[email protected]> > >>>>> *Cc:* Vittorio Bertocci <[email protected]>; IETF > >>>>> oauth WG <[email protected]> > >>>>> *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 < > >>>>> [email protected] 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 < > >>>>> [email protected]> 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 < > >>>>> [email protected]> 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 < > >>>>> [email protected]> 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 <[email protected]> > >>>>> 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 < > >>>>> [email protected]> wrote: > >>>>> > >>>>> Doesn?t the ?scope? parameter already provide a means of specifying a > >>>>> logical identifier? > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> Annabelle Richard Backman > >>>>> > >>>>> AWS Identity > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> *From: *OAuth <[email protected]> on behalf of Vittorio > Bertocci > >>>>> <[email protected] <[email protected]>> > >>>>> *Date: *Friday, January 18, 2019 at 5:47 AM > >>>>> *To: *John Bradley <[email protected]> > >>>>> *Cc: *IETF oauth WG <[email protected]> > >>>>> *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 <[email protected]> > >>>>> 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 < > [email protected]> > >>>>> 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 < > >>>>> [email protected]> 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 > >>>>> [email protected] > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> > >>>>> OAuth mailing list > >>>>> > >>>>> [email protected] > >>>>> > >>>>> https://www.ietf..org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> [email protected] > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> [email protected] > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> [email protected] > >>>>> 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 > >>>>> [email protected] > >>>>> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190121/46482262/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 123, Issue 42 > ************************************** >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
