Hey Marius, On 3/31/10 8:37 PM, "Marius Scurtescu" <mscurte...@google.com> wrote:
> On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: >> The only significant change I have made (which is of course open to debate) >> is renaming all the authorization flows parameters. I dropped the oauth_ >> prefix (no real need since these are purely OAuth endpoints, not protected >> resources), and made most of the parameter names shorter. I am not done so >> they are not consistent yet. > > Having a common prefix for all parameters is quite important IMO. It > allows parties > to define and pass additional, non-standard, parameters. Non-standard parameter hurt interoperability. The question is whether the right approach is to add a prefix to the protocol parameters or to the extension parameters (such as x_), or none. What prevents a custom parameter to collide with a standard extension not supported by the server or someone else's custom parameter? If we are serious about parameter collision (which I doubt given past sentiments on registries etc.), we should require all parameters to register unless they have some special custom prefix. In other word, adding the oauth_ prefix to the core parameters doesn't really accomplish much, other than making requests longer. In the past, people wanted to define extension parameters starting with oauth_ and we didn't really reach consensus on whether to allow it or not. Then we played with xoauth_ for a while, then went back and just allowed oauth_ for extensions. If we keep the oauth_ prefix, do we also require a registry for extensions? Do we define another prefix? Do we create a registry for extension prefixes? This gets bad really fast. > Also, quite > often parameters > are added to existing URLs, and a prefix helps prevent collisions. Extension parameters should never conflict with core parameter because we know all the core parameters before we write custom ones... This is only for the OAuth-specific endpoint (authorization endpoint), not the protected resource endpoint in which we will still use oauth_token (the only parameter added to protected resource requests). What do you think? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
