On Sun, Apr 18, 2010 at 11:07 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurte...@google.com] >> Sent: Sunday, April 18, 2010 1:38 PM > >> 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. > > How about we first figure this out? If we can agree on an extension policy, > we can see if it mitigates your concerns.
As Justin mentioned in his reply, this has nothing to do with extensions. Other parameters will be used just to deal with the callback implementation, to specify controllers and such. Maybe we should consider passing parameters some other way, and not part of query strings. JSON? Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
