Re: [OAUTH-WG] username password delegation profile

Allen Tom <atom@yahoo-inc.com> Tue, 27 April 2010 23:26 UTC

Return-Path: <atom@yahoo-inc.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 311EE3A6A34 for <oauth@core3.amsl.com>; Tue, 27 Apr 2010 16:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.329
X-Spam-Level:
X-Spam-Status: No, score=-14.329 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15]
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 VSPE+Jr5oVBW for <oauth@core3.amsl.com>; Tue, 27 Apr 2010 16:26:11 -0700 (PDT)
Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 1C7433A69E9 for <oauth@ietf.org>; Tue, 27 Apr 2010 16:26:11 -0700 (PDT)
Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o3RNPfhD083963; Tue, 27 Apr 2010 16:25:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: content-transfer-encoding:return-path:x-originalarrivaltime; b=Q25qyadbgfzeW7xkG4r5FjGln+WBpQjVX63py7GtpT3+HjpfpnGPhGftcSDk9PAt
Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Apr 2010 16:25:41 -0700
Received: from 172.21.149.123 ([172.21.149.123]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Apr 2010 23:25:16 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 27 Apr 2010 16:25:09 -0700
From: Allen Tom <atom@yahoo-inc.com>
To: Brian Eaton <beaton@google.com>, oauth@ietf.org
Message-ID: <C7FCC065.2CBAF%atom@yahoo-inc.com>
Thread-Topic: [OAUTH-WG] username password delegation profile
Thread-Index: AcrmYOBtSpGFPvfh00+TuXxraF3UEQ==
In-Reply-To: <q2gdaf5b9571004221744ya2323eaav8cc1394af5d32b85@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 27 Apr 2010 23:25:41.0239 (UTC) FILETIME=[F3A4C070:01CAE660]
Subject: Re: [OAUTH-WG] username password delegation profile
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, 27 Apr 2010 23:26:12 -0000

Hi Brian,

1) Telling the user to go to an error URL using a separate browser is
reasonable and will work most of the time. There are some cases (especially
for mobile devices) where it might be tricky to resolve issues if the user's
mobile device and desktop browser are on different subnets (or are in
different countries!) but this is probably the best compromise.

2) At least in Yahoo's case, we will definitely be issuing a Refresh Token
for all flows.

Allen



On 4/22/10 5:44 PM, "Brian Eaton" <beaton@google.com> wrote:

> A couple of comments on this profile.
> 
> 1) Error URL
> 
> I noticed that there was wide consensus that returning a
> captcha-specific error was not going to be useful.  That matches our
> experience with ClientLogin [1] - very few developers properly handle
> captcha.  And if a developer is sophisticated enough to handle
> Captchas, I would rather they just used a web browser in the first
> place.
> 
> However, lots of developers do tell users to visit the URL we return
> in our error response.  This is often sufficient to resolve whatever
> problems are happening with the user¹s account.  So I¹d like to see an
> optional ³url² parameter returned with the ³invalid_credentials² error
> code.  Clients should instruct the user to visit that URL.
> 
> 2) Is anyone actually going to implement this flow and not return a
> refresh token?
> 
> Cheers,
> Brian
> 
> [1] http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth