Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

[Eran Hammer-Lahav <[e-mail]>]

Propose text.

EHL

> -----Original Message-----
> From: Marius Scurtescu [mailto:[e-mail]]
> Sent: Monday, May 10, 2010 1:16 PM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG ([e-mail])
> Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
> 
> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav
> <[e-mail]> wrote:
> >
> >> -----Original Message-----
> >> From: Dick Hardt [mailto:[e-mail]]
> >> 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