On Tue, May 11, 2010 at 3:04 PM, Evan Gilbert <uid...@google.com> wrote: > > On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu <mscurte...@google.com> > wrote: >> >> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav <e...@hueniverse.com> >> wrote: >> > >> >> -----Original Message----- >> >> From: Dick Hardt [mailto:dick.ha...@gmail.com] >> >> 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. > > I think this we should leave this matching undefined for now - since you > have to preregister with every site, you will have provider-specific logic > anyway. This will be much more important when we have a discovery mechanism > for callback URLs.
If we leave undefined then that is the same as enforcing strict equality matching. Then let's make that explicit. Are we OK with that? A client that eventually wants to interact with several authz servers will have to assume the "greatest common divisor", which is strict matching. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
