Re: [OAUTH-WG] device profile comments

Eran Hammer-Lahav <eran@hueniverse.com> Sun, 09 May 2010 17:12 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 CD11D3A6A7C for <oauth@core3.amsl.com>; Sun, 9 May 2010 10:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level:
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001]
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 rCQO4xUL3+KH for <oauth@core3.amsl.com>; Sun, 9 May 2010 10:12:23 -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 2285D3A6A77 for <oauth@ietf.org>; Sun, 9 May 2010 10:12:20 -0700 (PDT)
Received: (qmail 21076 invoked from network); 9 May 2010 17:12:08 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2010 17:12:07 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 9 May 2010 10:12:06 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Brian Eaton <beaton@google.com>, David Recordon <recordond@gmail.com>
Date: Sun, 09 May 2010 10:12:06 -0700
Thread-Topic: [OAUTH-WG] device profile comments
Thread-Index: Acrl0rY3zOZMJVVHQ4C/UTKkqPpJMAJxz+uw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <i2odaf5b9571004221649h733f675bva2f9f4438ef43921@mail.gmail.com> <y2kfd6741651004221758y7d207961we2a6d1e65e6dd279@mail.gmail.com> <o2qdaf5b9571004262327u90caa8b6vbfa976ec44c86d91@mail.gmail.com>
In-Reply-To: <o2qdaf5b9571004262327u90caa8b6vbfa976ec44c86d91@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@ietf.org" <oauth@ietf.org>
Subject: Re: [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: Sun, 09 May 2010 17:12:25 -0000

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Monday, April 26, 2010 11:27 PM
> To: David Recordon
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] device profile comments
> 
> On Thu, Apr 22, 2010 at 5:58 PM, David Recordon <recordond@gmail.com>
> wrote:
> > I don't fully understand what you're proposing. The device would show
> > a screen which tells the user to visit http://fb.me/xbox and enter the
> > code 123456. (Or to visit http://xbox.com/fb.) Asking a user to go to
> > http://goo.gl/?client_id=bndi12boi1 seems like it's prone to user error.
> 
> Yeah, we are shooting for the exact same UX and typable URLs that you are.
> I was thinking that this would be done without requiring preregistration at
> the authorization server.  That requires that the device point to a friendly
> URL (e.g. http://xbox.com/fb), which then automatically redirects to the
> authorization server with a few more bits of information tacked on to the
> URL.
> 
> But, as you point out, the protocol that requires pre-registration is simpler.  I
> don't think asking manufacturers to register is a problem, either.
> 
> Proposed changes to the spec (for clarity, I don't think these change the
> protocol flows.)
> 
> "The client is incapable of receiving incoming requests from the authorization
> server (incapable of acting as an HTTP server).  ADD:
> The device manufacturer is assumed to have registered with the
> authorization server.  The authorization server and device manufacturer
> agree on a client id used to identify the manufacturer's devices."

I don't see the point. The fact that there is a client_id parameter makes this clear enough. This is true for all flows.

> "(B) The authorization server issues a verification code, a user code, and
> provides the end user authorization URI.  ADD: The authorization URI
> SHOULD be suitable for manual user entry.  Authorization servers MAY
> return different approval URLs for different authorization requests.  (These
> different approval URLs allow the user interface to be customized for
> different clients.)"

I added the 'suitable for manual entry' text to the parameter definition. The rest is stating the obvious.

> New step E.
> 
> "(E) After the end user grants or denies access, the Authorization Server
> MAY redirect to a callback URL previously registered for the client.  If the user
> denies access, the Authorization Server must append the query parameter
> "error=user_denied" to the callback URL.
> The callback URL can be used to provide further instructions to the user if
> necessary."

If the client can receive callbacks, why use this flow?

EHL