Subject: Re: [OAUTH-WG] device profile comments

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 10:12:06 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Eaton
> Sent: Monday, April 26, 2010 11:27 PM
> To: David Recordon
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] device profile comments
> 
> On Thu, Apr 22, 2010 at 5:58 PM, David Recordon <[email-masked]>
> 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

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 10 May 2010 11:06:14 -0700

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

I think this is a generic callback page with information for this
specific class of devices. The device itself cannot receive callbacks.

Marius

---

From: Brian Eaton <[email-masked]>
Date: Mon, 10 May 2010 16:24:29 -0700

> 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.

It's definitely not true for all flows.  Neither the web app profile,
nor the javascript profile, nor the installed application profile
requires preregistration in order to work.  The appropriate user
experience happens via the callback URL.

The device profile is different because you really cannot achieve a
suitable user experience without preregistration.