OK, here is a concrete example: A Drupal (popular PHP based CMS) based web site wants to become an OAuth 2 client. Among other things it needs to implement a callback endpoint.
Ideally this endpoint would look something like: http://example.com/oauth/back Depending on what web server is used and how it is configured, the above URL may not be possible. Drupal is dispatching all requests through the main script and the path of the endpoint is passed as a query parameter. Normally the above URL is seen as: http://example.com/index.php?q=oauth/back The cleaner http://example.com/oauth/back is achieved with Apache URl rewriting, but if Apache is not available or configured to support that, you are stuck with the ugly query parameters. In the unlucky case the registered callback, and the actual callback used in messages, is "http://example.com/index.php?q=oauth/back";. This callback has a query parameter, it is not used for state, and it is not an extension. It so happens that "q" will not conflict with any of the existing OAuth 2 parameters, but you can see the potential issue. Now, even if Apache is available and URL rewrites work, so the nice callback is used, a collision would still happen if "q" was used by OAuth 2. Apache rewrites "/oauth/back", but the Drupal dispatcher always sees "/index.php?q=oauth/back", so another q parameter would break things. I do realize that a prefix will not solve ALL collisions and it is also not solving the extension question, but I still think makes a big difference. Hope this helps, Marius On Thu, Apr 15, 2010 at 12:44 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > > > > On 4/15/10 12:36 PM, "Marius Scurtescu" <mscurte...@google.com> wrote: > >> On Thu, Apr 15, 2010 at 12:27 PM, Eran Hammer-Lahav <e...@hueniverse.com> >> wrote: >>> >>> On 4/15/10 12:15 PM, "Marius Scurtescu" <mscurte...@google.com> wrote: >>> >>>> I really think we should keep a standard parameter prefix like >>>> "oauth_". What are the issue with having a prefix? >>> >>> I really think we shouldn't. :-) >>> >>> Requests are longer for no reason. >> >> Not much longer, the number of parameters is small. Why is this a problem? > > It's longer for no reason. > >> >>> You need to show how a prefix actually >>> helps. Otherwise, it is the same as adding an 'protocol=oauth' to every >>> request just for fun. >> >> I think I did. > > Say it helps isn't proof, just an argument. > >> >>>> Not having such a prefix will lead to collisions with query parameter >>>> on the authz server endpoints >>> >>> Having a prefix without an extension policy does not help at all to prevent >>> collisions. This is a false expectation. There is no difference between >>> saying 'don't add new parameters with the oauth_ prefix' or 'don't add new >>> parameters with names already used by this specification'. >> >> I agree this is not perfect, but that does not mean it does not help. >> >> It is one thing to say to implementors to stay away from parameters >> stating with "oauth_" and a totally different thing to say stay away >> from "scope", "mode", "callback", ... and whatever we will add to >> newer versions to the spec. All these are very common words and >> chances for collision are high. > > So what happens when someone wants to add a language parameter? Do they call > is 'language' or 'oauth_language'? The prefix just doesn't solve anything > without a policy, and once you write a policy it is no longer needed. > >> >>>> or on the callback URL. Even if state is >>>> not passed with additional parameters on callbacks. This also leads to >>>> adding further limitations on these URLs, by not allowing query >>>> parameters. >>> >>> Callback parameters are a bit different. We still need to solve the issue of >>> how to allow client state in callbacks (state parameter or free-for-all). >>> But here too, a prefix does not solve collisions. You have the same >>> extension policy issue. >> >> State aside, the callback may want to have query parameters, even in >> the registered version. Why disallow that? > > I don't think it should, but I am opposed to both random parameters and a > client state parameter. Either way, that's a different issue - let's try to > keep this focused on one issue at a time. > >> >>> A prefix just "solves" potential collision between the core spec and other >>> specs using the same parameter names. It does not help how to avoid >>> collisions between extensions and vendors. OAuth 1.0a had a prefix and then >>> we spent weeks discussion who else can define oauth_ parameters. It just >>> moved the problem somewhere else - the extension policy. >> >> Not trying to solve the extension issue at all. > > This is all about extensions (common or vendor specific)! > > EHL > >> >> Marius >> >>> >>>> Marius >>>> >>>> >>>> >>>> On Thu, Apr 15, 2010 at 12:08 PM, John Kemp <j...@jkemp.net> wrote: >>>>> Hello, >>>>> >>>>> On Apr 15, 2010, at 2:27 PM, Eran Hammer-Lahav wrote: >>>>> >>>>>> OAuth 2.0 flows use a single authorization endpoint (with 'type' >>>>>> parameter). >>>>>> This endpoint is OAuth-specific but must allow for extension parameters >>>>>> (standard or vendor-specific). >>>>>> >>>>>> The issue is how to best allow for extensions defining new parameters. >>>>>> The >>>>>> danger is common parameter names ('scope', 'language', 'permission') >>>>>> being >>>>>> used differently by different vendors, creating interop issues with >>>>>> libraries. >>>>> >>>>> If the OAuth specification defines the name for a parameter, and people >>>>> claim >>>>> to implement the specification, they must use those parameter names >>>>> according >>>>> to the specified usage. In other words, implementations of OAuth should >>>>> all >>>>> do the same thing, and use the same names for the OAuth-specific >>>>> parameters. >>>>> But, deployments of OAuth will use OAuth implementations and possibly have >>>>> additional requirements (such as passing other query string parameters >>>>> which >>>>> may collide with the OAuth ones). And particular OAuth vendors may add >>>>> other >>>>> extension parameters (agreed between particular implementations but not >>>>> perhaps within the entire community) to the query string. All of that >>>>> might >>>>> be covered by "conformance to the specification" - conformant >>>>> implementations >>>>> MUST not define parameters with names that clash with the agreed OAuth >>>>> names. >>>>> >>>>>> >>>>>> Prefix alone (for the core or extensions) does not solve the problem >>>>>> since >>>>>> extensions still suffer from potential namespace collision. >>>>> >>>>> Right. You cannot solve this problem. The danger is for those who don't >>>>> read >>>>> the spec. (because they don't have to - they are buying a product, or >>>>> using >>>>> a >>>>> library). >>>>> >>>>>> 'oauth_' prefix >>>>>> makes all the parameter names longer, but doesn't add real value - >>>>>> defining >>>>>> new parameters, with or without the 'oauth_' prefix is still the same >>>>>> problem. >>>>>> >>>>>> The typical solution is to define an extension policy, using a registry >>>>>> or >>>>>> domain-namespace for new names. >>>>>> >>>>>> Proposal: >>>>>> >>>>>> Plain parameter names (names without '.' character) require registration >>>>>> (IANA registry with a published specification). This will encourage >>>>>> people >>>>>> to share their parameters and improve interop beyond the core protocol >>>>>> parameters. >>>>> >>>>> It will - how? >>>>> >>>>>> >>>>>> Vendor specific names will require a prefix using either registered >>>>>> vendor >>>>>> names (e.g. 'google', 'fb', 'yahoo'). >>>>> >>>>> How will you *require* this - will there be a statement to that effect in >>>>> the >>>>> specification - "conformant implementations MUST NOT define query >>>>> parameters >>>>> that clash withe names int he OAuth registry "? What will you do about >>>>> deployments which include an OAuth library and do not know anything at all >>>>> about the OAuth requirements? >>>>> >>>>>> Alternatively, use the same extension >>>>>> policy as OpenID where extensions use any prefix and include a prefix URI >>>>>> identifier (e.g. >>>>>> http://example.com?etx.language=en&ns:ext=http://example.com/spec1). >>>>>> >>>>> >>>>> What do you consider an "extension" for this purpose (some parameter >>>>> agreed >>>>> on by two or more conforming OAuth implementations)? >>>>> >>>>> - johnk >>>>> >>>>>> EHL >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>> >>> >> > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
