On Thu, Apr 15, 2010 at 6:31 PM, Marius Scurtescu <mscurte...@google.com>wrote:
> 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. > We should ask Drupal to change their query parameter to drupal_q. > > 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. > This use case makes sense, but do we know of any existing conflicts? Very few web servers have this restrictive a URL parameter policy - I think I'm OK losing compatibility with future web servers that reserve the "callback" parameter for other purposes. > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
