On Mon, May 10, 2010 at 7:53 PM, Eran Hammer-Lahav <[email protected]> wrote: > Propose text.
Tried to write some text, but still not sure what the right solution is. redirect_uri matching is done in two flows: Web Server and User-Agent. In Web Server the matching issue can be avoided by always requiring redirect_uri on the initial request, and require authz servers not to match against a pre-registered one, and then do strict matching when the access token is requested. In User-Agent, matching must be done between pre-registered and the one sent with the request. Here I would suggest strict matching (which boils down to no requirement to send redirect_uri if it was pre-registered). For this flow, does anyone see the need for wild card domain matching or for path prefix matching? If we cannot get to an agreement, maybe the spec can at least advise clients to assume strict matching since this assures the largest compatibility? Does it help to propose text if there is no agreement? Marius > > EHL > >> -----Original Message----- >> From: Marius Scurtescu [mailto:[email protected]] >> Sent: Monday, May 10, 2010 1:16 PM >> To: Eran Hammer-Lahav >> Cc: Dick Hardt; OAuth WG ([email protected]) >> Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt >> >> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav >> <[email protected]> wrote: >> > >> >> -----Original Message----- >> >> From: Dick Hardt [mailto:[email protected]] >> >> Sent: Sunday, May 09, 2010 5:52 PM >> > >> >> >> 3.5.1. Client Requests Authorization >> >> >> >> >> >> If the client has previously registered a redirection URI with the >> >> >> authorization server, the authorization server MUST verify that >> >> >> the >> >> >> redirection URI received matches the registered URI associated >> >> >> with >> >> >> the client identifier. >> >> >> >> >> >> Does this mean equality? Or just the same base string? >> >> > >> >> > Right now it depends on the server. >> >> >> >> The spec should clarify that. Suggested wording: >> >> >> >> >> >> If the client has previously registered a redirection URI with the >> >> authorization server, the authorization server MUST verify that the >> >> redirection URI received matches the registered URI associated with >> >> the client identifier. The components of the redirection URI that >> >> must match the registered URI is authorization server dependant. >> > >> > I don't see how that helps... I also don't see why we can't just profile >> > this >> and decide on how the matching should be done. We have the state >> parameter to help too. >> >> I also think the spec should specify how the matching should be done. >> >> If left up to the authz server then a client that designs its OAuth 2 >> implementation will have to assume that all authz servers will do strict >> equality matching, otherwise it may not be able to interact with some >> servers. >> >> For example, if the client assumes that it can use load balancing by varying >> the first part of the host name, and this may work with the fist authz >> server it >> integrate with, later this client will not be able to interact with an authz >> server >> which does strict matching on host name. And changing the load balancing >> architecture once deployed could be very hard. >> >> Since there is a state parameter maybe it is enough to allow wild cards only >> in >> the domain name of the callback URI. >> >> Marius > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
