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. The difference between registered and unregistered for clients without secrets feels like a continuum, not black and white. So separate flavours (client_id+state vs redirect_uri) makes less sense to me. -- James Manger From: Brian Eaton [mailto:bea...@google.com] Security for the implicit grant type comes from identifying the client based on the redirect URI. At client registration time, you bind client_id X to redirect URIs Y and Z. If the redirect URIs use HTTPs, that gives you reasonable security. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Changes I would like to see: The implicit grant should be split into 2 flavors (can be given different grant type name or just using normative language to define the restrictions), one with client_id and state, and one with redirect_uri only. Registered client: the client request token response type by including its client identifier and optional state parameter... Unregistered client: the client request token response type by including a redirection URI (no client_id or state)...
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
