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