Re: [OAUTH-WG] Issue: 'username' parameter proposal

Brian Eaton <beaton@google.com> Tue, 20 April 2010 18:03 UTC

Return-Path: <beaton@google.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 1995A3A6A53 for <oauth@core3.amsl.com>; Tue, 20 Apr 2010 11:03:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 e1cooUOxOUzH for <oauth@core3.amsl.com>; Tue, 20 Apr 2010 11:03:47 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2074B3A67E5 for <oauth@ietf.org>; Tue, 20 Apr 2010 11:03:47 -0700 (PDT)
Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [10.3.21.12]) by smtp-out.google.com with ESMTP id o3KI3Ys9017614 for <oauth@ietf.org>; Tue, 20 Apr 2010 11:03:34 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271786615; bh=GcYLx+F5S74V+o1X1eNbz4AONLo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=COvMwPWM8kbYhs7lJCsUe0w3os4SEj4UYeRxvCq3RdGFao43XjA4kg1OXyvjEcVEM vpw6MqBsF1eKJXyqBvW3w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=YJcdgzYnhv4b6L6eIoAUL0m98A0nhYnYRtNqbspxs92zjy9njYCwyc+2ptyuyfDyo L1U1ViM1U+VwsNeB24R/A==
Received: from pzk10 (pzk10.prod.google.com [10.243.19.138]) by hpaq12.eem.corp.google.com with ESMTP id o3KI3VuQ007437 for <oauth@ietf.org>; Tue, 20 Apr 2010 20:03:33 +0200
Received: by pzk10 with SMTP id 10so897108pzk.20 for <oauth@ietf.org>; Tue, 20 Apr 2010 11:03:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.202.10 with HTTP; Tue, 20 Apr 2010 11:03:31 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723438E5C7F533@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <r2pc8689b661004190833tf46085bayb92b840acf080bb4@mail.gmail.com> <C7F1C6AC.327EE%eran@hueniverse.com> <u2jc8689b661004191006hc3c7fb3eid09feafd57d2fd8a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F163@P3PW5EX1MB01.EX1.SECURESERVER.NET> <o2wc8689b661004191716o69966d5di900c07737d3be568@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F45A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <z2xc334d54e1004200936s57f06dedt8e0e46df3480f8d4@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F533@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Tue, 20 Apr 2010 11:03:31 -0700
Received: by 10.142.247.28 with SMTP id u28mr3152968wfh.69.1271786611260; Tue, 20 Apr 2010 11:03:31 -0700 (PDT)
Message-ID: <s2odaf5b9571004201103w17ade392j91727ced1dc39072@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: "jsmarr@stanfordalumni.org" <jsmarr@stanfordalumni.org>, OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal
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: Tue, 20 Apr 2010 18:03:48 -0000

On Tue, Apr 20, 2010 at 10:23 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I’m not aware of anyone arguing against this feature. The only issue is a
> full security review before we add it to the spec. If one of the security
> experts here can spend a few minutes to review this, we can move forward and
> add it to the draft.

I'd like to see some solutions mature in the wild.  Once we figure out
best practices in the real world, it'll be a lot easier to put good
policy on paper.

I just don't think we have a solid answer, and I don't want something
ending up in the spec that we will regret later.

Cheers,
Brian