+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> > 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 > _______________________________________________ > 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
