> > Also, when implementing OAuth 2.0 people will take into account existing > > parameters and will avoid them, they will chose other parameter names (if > > possible). If the next version of OAuth, let's call it 2.1, adds a few new > > parameters, how can we chose them so they don't collide with extra > > parameters used by 2.0 implementations? > > By defining an extension policy. Anything that is not in the core spec is an > extension.
OAuth extensions are well and good, but there are cases (that Marius has outlined, and I agree with) where the underlying system will simply add more stuff to the pack of URL parameters. For two concrete examples, let's talk MediaWiki and Elgg. To get a plugin to define an endpoint in MediaWiki, you can define a Special page. This gets handled by the redirect engine, and you end up with title=Special:OAuthEndpoint or something as a parameter. This setup allows the extension of the URL space by a plugin alone without mucking with the HTTP server configuration. Elgg's system is similar, with a pageview handler turning pg/oauth/requesttoken into something else on the inside. I don't think we can make the assumption that OAuth endpoints will be single-purpose and pristine in the wild. There are too many frameworks that behave similarly, especially in Apache/PHP land. I think we need to assume that OAuth endpoints *will* have extra parameters, that these parameters are out of our control, and that we should take reasonable steps to namespace the OAuth parameters out of other peoples' way. Query parameter URLs don't have their own namespacing schemes that we can use to get stuff out of the way, so we need to use our own, like OpenID's "openid." prefixing. It's pretentious to think that a framework will change their API just to support OAuth. It's much more likely that a framework will say that OAuth isn't compatible with them, and therefore just not ever support it. If we want to facilitate adoption, we need to keep in mind that OAuth is the outsider to most systems. I'm still not seeing the reasons for dropping the prefix in the first place. I don't buy the argument that it's really a space saving device by not defining the prefix. Were we hitting against size limits so tightly that dropping a few characters per request is a big deal? I agree that it's convenient to not have all of those extra characters, but at the same time it immediately tells you which parts of the protocol stack belong to core OAuth and which don't. Along those lines, I do think that an extension policy is needed as well, since we'll end up with people adding their own oauth_ stuff and pushing that part of the conflict problem there, as Eran said. I still contend, though, that since OAuth is designed to work with other APIs and within other frameworks, this is not the only collision space we need to worry about. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
