I am not sure we can specify how callbacks are registered which is where your syntax resides. The whole registration process is out of scope. The server has *something* and needs to match the callback in the request to it.
My proposal is to provide a narrow facility with the client state parameter which makes this simple, but somewhat limited, and allow servers to support a more robust system using any client provided callback parameter. My problem is that I don't know where to put these rules because we don't have a section dealing with callback registration. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Monday, April 19, 2010 10:46 AM > To: Eran Hammer-Lahav > Cc: Brian Eaton; Dick Hardt; OAuth WG > Subject: Re: [OAUTH-WG] Clarification: authorization server matching of > redirect URI > > On Mon, Apr 19, 2010 at 8:39 AM, Eran Hammer-Lahav > <[email protected]> wrote: > > > > > >> -----Original Message----- > >> From: Brian Eaton [mailto:[email protected]] > >> Sent: Monday, April 19, 2010 8:37 AM > >> To: Dick Hardt > >> Cc: Eran Hammer-Lahav; OAuth WG > >> Subject: Re: [OAUTH-WG] Clarification: authorization server matching > >> of redirect URI > >> > >> On Sun, Apr 18, 2010 at 10:35 PM, Dick Hardt <[email protected]> > wrote: > >> > The spec should describe how the redirect URI is verified to what > >> > is > >> registered. I can enumerate the options for discussion adding in the > >> state parameter as an option. > >> > >> Note that there are two spots where the AS does some URI matching. > >> > >> The first is before redirecting the user to the callback URI. This > >> seems doomed to being service provider specific, unfortunately. > > > > I agree. If someone wants to suggest some security consideration text that > would be good. > > If this is authz server specific I can see the following problem: > - authz server 1 allows regular expressions in registered callback URLs > - client integrates with authz server 1 and designs its own implementation > based on these callback URLs, uses load balancing on different hosts and > passes state through query parameters > - authz server 2 comes along and it requires strict matching on callbacks > - client wants to integrate with authz server 2 as well, but will have to > rewrite > everything because the load balancing and state infrastructure will not work > > In order to support interop I think it would be useful to specify how > callbacks > are matched. > > Proposal: > - path and query string are strictly matched (the spec has a state parameter) > - host names can contain a wild card (to allow for load balancing) > - port and scheme strictly matched > > For example: > - registered callback: https://*.example.com/client?controller=oauth2 > - matching callbacks: > https://example.com/client?controller=oauth2 > https://sv1.example.com/client?controller=oauth2 > https://sv2.n1.example.com/client?controller=oauth2 > - not matching: > https://example.net/client?controller=oauth2 > https://example.com/client?controller=oauth2&user=x > http://example.com/client?controller=oauth2 > https://example.com:8080/client?controller=oauth2 > > > Marius _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
