On Thu, Apr 22, 2010 at 5:58 PM, David Recordon <record...@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." "(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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
