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