Hi Eran,
On Wed, Mar 31, 2010 at 9:17 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > 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. I agree that non-standard parameters are far from ideal, but they are used in practice for various reasons. > 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. That's a different issue IMO. In general if you use non-standard stuff you are on your own. We should try to protect the standard part and I think a prefix helps. > 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. I don't see how dropping the prefix solves any of these problems. I think it just makes matters worse. >> 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). Yes, this is only for OAuth endpoints, but all kinds of frameworks will be used to implement them I can imagne that many of them will use their own parameters. Also, many implementation will probably choose to pass state through the callback URL, as query parameters (even though there is a special OAuth parameter for that). > What do you think? What are the reasons we would drop the prefix? So far the only one I heard was shorter messages, but I am not convinced this is a real problem. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
