Subject: [OAUTH-WG] device profile comments

From: Brian Eaton <[email-masked]>
Date: Thu, 22 Apr 2010 16:49:17 -0700

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

---

From: David Recordon <[email-masked]>
Date: Thu, 22 Apr 2010 17:58:44 -0700

Thanks!

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

I might be reading something different than you are, but according to
http://tools.ietf.org/html/draft-hammer-oauth2-00#section-3.5.3.1 those are
the parameters included.

> page on the authorization server.

By having the Authorization Server pass the Client the approval URL it's
much easier to change over the lifetime of a living room device. This could
be in your application settings (for Facebook's usage) if it's pointing to a
page on the manufacturer's site. Or it gives the Authorization Server the
ability to change it if they're hosting the page.

> page, and that the callback will point to a manufacturer specific

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.

Plus a few comments on error codes:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 23 Apr 2010 16:28:15 +0200

> page on the authorization server.

Why not returning client-id-specific approval-URLs from the 
authorization server? This would allow to change them dynamically w/o 
changing the device's firmware/configuration.
And even if the authorization server returns an URL, the device 
firmeware can always use hard-coded URLs.

What do you think?

regards,
Torsten.

---

From: Brent Goldman <[email-masked]>
Date: Fri, 23 Apr 2010 19:17:17 -0700

I sent this reply to Brian's original email earlier, but forgot to click reply-all.

I disagree with hardcoding the approval URL into the device. To enable short URLs, there's nothing in the spec preventing the Auth Server from returning a different approval URL for each client id. E.g.,http://www.facebook.com/roku to link a Roku device to your Facebook account.

I also don't think we need a callback URL specified by the device so that instructional text can be displayed after the user authorized. The approval URL will just tell the user to go back to the device once they're done. If an Auth Server wants to support more detailed instructions, the client can register a callback URL or approval text in advance, at the same time they're registering their short URL.

-Brent

On Apr 23, 2010, at 7:28 AM, Torsten Lodderstedt wrote:

What do you think?

regards,
Torsten.

Cheers,
Brian

[email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Eaton <[email-masked]>
Date: Mon, 26 Apr 2010 23:27:13 -0700

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

"(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.)"

Changes to (D):

"(D) The authorization server authenticates the end user and prompts
the end user to grant the client's access request.  If the end user
agrees to the client's access request, the end user enters the user
code provided by the client."

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

Cheers,
Brian