> -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Thursday, July 01, 2010 2:21 PM
> >> 2. Greatly reduce the chances of a conflict with a query parameter > >> used by an authz server endpoint or client redirect_uri. > > > > There should not be any conflict. Either it has been registered or uses x_. > > There can be. Here is the example I gave earlier in another thread. > MediaWiki uses the 'title' parameter. Some OAuth extension may register > and use this same name and this will prevent MediWiki from being able to > support that extension. I think this discussion (which we spent many days on already) boils down to a philosophical approach to the level a new protocol should accommodate the broken environment in which it is expected to be deployed. I think MediaWiki should change the way it treats the OAuth endpoints to isolate them from the rest of the platform. When receiving an OAuth request (with such an OAuth 'title' parameter), the platform can rename all the OAuth parameters to oauth_ internally and proceed to add its own parameters without conflicts. While this approach might not be trivial, it is clearly possible. I think there is a larger question of how OAuth is used in a MediaWiki installation, and how it can accommodate some of the other requirements such as SSL. I do not consider making MediaWiki's deployment of 2.0 easier an important consideration. > >> Cons: > >> > >> 1. Slightly longer parameter names. > > > > Also, messy, ugly, opens the door to extensions without review. > > I don't get the last part, skipping reviews. As for beauty, that's relative > ;-) If we approve a blanket "prefix_" extension, we lose the ability to review individual parameters within that prefix. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
