On Wed, Jun 15, 2011 at 7:36 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: > It seems like an authorization server receiving a request with an > unregistered redirect_uri of https://example.org/ can tell the user: > > > > “Permission will be passed to your browser then onto *example.org*” > > > > An authorization server receiving a request with a registered redirect_uri > of https://example.net/ can tell the user: > > > > “Permission will be passed to your browser then onto *WidgetXYZ by Example > Inc (example.net) [logo]*” > > > > Where the label, company, and logo are extra details from the registration, > hopefully after some verification by the authorization server that all these > details are a consistent set. That verification could come from some > discovery on the redirect_uri, or from reputation stats – perhaps even > without a priori registration. > > > > We might be better off ditching the client_id field and just keeping > redirect_uri in the implicit grant. If the value is registered (or the > server has done some discovery on it, or has some reputation stats for it) > it can display a more user-friendly permission message.
Several clients may register the exact same redirect URI: localhost or non-routable IP address. You cannot uniquely identify the client based on the redirect URI. Similarly, you cannot perform discovery in these cases either. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
