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: - 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. 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. - 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 _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
