On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> 1. Why not require the registration of a redirection URI for implicit grant > requests, removing the redirect_uri parameter completely from the request > (the client can still use the state parameter)? > As others have stated, this is a bad idea because there are legitimate reasons for a single client to have multiple redirect URIs. > ** > > 2. What is the value of the client_id when a redirection URI is not > pre-registered? The client identity cannot be verified without other means > for the purpose of informing the user who is asking for access, no refresh > token is issued, and the redirect_uri parameter contains the only useful > information for both the flow and identifying the client (to the extent it > can be trusted not to be an open redirector). > I think you're saying that redirect URIs should always be preregistered for the implicit grant flow. That's a very good idea. > 3. Are there real use cases for performing redirection URI matching against > a pre-registered value, where partial (i.e. not string) comparison is > needed? Why can’t this be solved by simply using any URI variations into the > state parameter? > I don't understand this question. > Authorization server who want to be fancy can allow you to register more than one and let you indicate which one you want by adding a suffix to the client id (say 'abcd-1' to pick URI 1). This is a bad idea. Client identifiers are like usernames; you wouldn't tell a user to use a different variety of their username, don't tell developers that they have to use a different variety of their client identifiers. Please don't tamper with these protocol flows. The protocol flows are fine as is. There should be language making it clear that registration is required. Everyone is doing that already, so that's not a particularly disruptive change.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
