> 2. Section 8.2. What about applications using legacy parameters? Does > not make much sense to register them, and they cannot be changed to > x_.
I *guarantee* that there will be many noncompliant implementations of this, built on server frameworks with required parameters on all endpoints. Not everyone is a Facebook or Google who can just define a new top-level endpoint with clean parameter space. OAuth2 is going to be integrated into *existing* systems that already have their allowable extra parameters carved out, and these systems are not going to change their parameters just to support OAuth. Once again, I'll say that if the choice comes down to changing around existing parameters or not supporting OAuth, most people are going to just not support OAuth. > Broken record: using a prefix for all registered parameters is > much cleaner (as opposed to requiring that all no-registered > parameters use a prefix). And once again, a strong +1 to this, even though I know it's far too late to make such a breaking change to the spec. I really think this was a bad decision and is going to come back and bite us in the future. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
