[OAUTH-WG] device profile comments

Brian Eaton <beaton@google.com> Thu, 22 April 2010 23:49 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 BD0B93A6858 for <oauth@core3.amsl.com>; Thu, 22 Apr 2010 16:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.584
X-Spam-Level:
X-Spam-Status: No, score=-100.584 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 osmfHDM5vRok for <oauth@core3.amsl.com>; Thu, 22 Apr 2010 16:49:33 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 153CF3A6973 for <oauth@ietf.org>; Thu, 22 Apr 2010 16:49:31 -0700 (PDT)
Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o3MNnJtY017752 for <oauth@ietf.org>; Fri, 23 Apr 2010 01:49:20 +0200
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271980160; bh=76QTFG6QJB/cLlzUmlHQFRubkjs=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type: Content-Transfer-Encoding; b=IangMcnp4yfm0cq/AWdDkentjmWXPOkRZkc0RLv9fjFK+QFCbk0tzDOPx3/U971Ii oYEPOuWW7IUgvPNrs8S3g==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type: content-transfer-encoding:x-system-of-record; b=nYsHExWa9DxmWg6kkweQ0bVxXReAZpzheTPBlHNHpvARbiLMswoSS1Gowm6OA7Kx2 lTaUmtSZq0D51QHov52mg==
Received: from pvg11 (pvg11.prod.google.com [10.241.210.139]) by kpbe19.cbf.corp.google.com with ESMTP id o3MNnH2w028372 for <oauth@ietf.org>; Thu, 22 Apr 2010 16:49:18 -0700
Received: by pvg11 with SMTP id 11so7654119pvg.0 for <oauth@ietf.org>; Thu, 22 Apr 2010 16:49:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.202.10 with HTTP; Thu, 22 Apr 2010 16:49:17 -0700 (PDT)
Date: Thu, 22 Apr 2010 16:49:17 -0700
Received: by 10.143.179.6 with SMTP id g6mr4993980wfp.21.1271980157395; Thu, 22 Apr 2010 16:49:17 -0700 (PDT)
Message-ID: <i2odaf5b9571004221649h733f675bva2f9f4438ef43921@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: oauth@ietf.org
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Subject: [OAUTH-WG] device profile comments
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, 22 Apr 2010 23:49:33 -0000

I'm going through the April 21 draft and making notes...  Most of them
are of the "what color should the bike shed be" variety, but I think
the device profile needs real changes.

The verification URI has to be short and memorable, because users have
to type it.

Different devices are probably going to end up needing different
verification URIs, for branding reasons.  (For example, the approval
page should say “link your Google account to your Foo device”)

Different devices are probably going to need different callback URLs.
In usability studies on desktop apps [1] we found that it was
important that users be told what to do after they had clicked "OK".
We dealt with that by finding ways for desktop apps to receive
callback URLs.  For apps which can't open a web browser [2], it seems
likely that we're going to want to give users instructions on what to
do next.  It really helps to give users a clue that they should go
back to the device that requested approval.

So I’d propose changing the profile as follows:

- Client requests device code by sending type=device and client_id=<id>

- Authorization server doesn’t return approval URL - device hard-codes
this instead.
   I expect that this will point to a manufacturer specific page, and
that the manufacturer specific page will automatically redirect to a
page on the authorization server.

- Approval URL MUST have client_id, and MAY have callback.
   I expect that the client_id will be used to brand the approval
page, and that the callback will point to a manufacturer specific
completion page.

Plus a few comments on error codes:

“End User Authorization Pending or Expired” - authorization server
probably isn’t going to be able to tell whether a code has expired, or
was never issued.  Probably just return “unknown_code”.

The “slow_down” error probably merits an “interval”.  Maybe always
return “interval” with authorization_pending, and eliminate the
slow_down error code entirely?

Cheers,
Brian

[1] http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps
[2] http://sites.google.com/site/oauthgoog/UXFedLogin/nobrowser