Re: [OAUTH-WG] register prefixes as opposed to full parameter names

Eran Hammer-Lahav <eran@hueniverse.com> Thu, 01 July 2010 21:52 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B368C3A694E for <oauth@core3.amsl.com>; Thu, 1 Jul 2010 14:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9YPCuCy+Yx0 for <oauth@core3.amsl.com>; Thu, 1 Jul 2010 14:52:22 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 27A4C3A696B for <oauth@ietf.org>; Thu, 1 Jul 2010 14:52:17 -0700 (PDT)
Received: (qmail 16225 invoked from network); 1 Jul 2010 21:52:28 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 21:52:28 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Jul 2010 14:52:28 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Marius Scurtescu <mscurtescu@google.com>
Date: Thu, 01 Jul 2010 14:52:40 -0700
Thread-Topic: [OAUTH-WG] register prefixes as opposed to full parameter names
Thread-Index: AcsZZBy/c5Pe4L6bQJqWVPzUcp8EVwAARdIQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C528@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <AANLkTin7zWi7m_evTgI49JKXLPuVqYBFlCR8CtSYRKDM@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTik_f9MRWIK4kZ3c5pANtPloOsxyzYeL6bqMFhbs@mail.gmail.com>
In-Reply-To: <AANLkTik_f9MRWIK4kZ3c5pANtPloOsxyzYeL6bqMFhbs@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2010 21:52:24 -0000

> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com]
> 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