Resending; not sure that OAuth email list is working at the moment. From: Manger, James Sent: Tuesday, 28 February 2017 9:53 AM To: [email protected] Subject: draft-ietf-oauth-device-flow: url with code
How about combining the verification_uri and user_code? The Device Flow provides a verification_uri and user_code, both of which have to be copied to a web browser on, say, a mobile phone. The main model in this draft is that the user copies the uri, then the resulting web page prompts for the code. The draft also mentions other possibilities such as Bluetooth to do the “copying”. Transmitting a URI via Bluetooth, or NFC, or QR code, is quite common. In such cases it would be nicer to transmit the user_code as part of the URI. Perhaps both modes could be supported by saying the user_code can be included as a query parameter on the verification_uri when it is more convenient for a device to transmit a single URI. Authorization Servers MUST accept this. The choice is to use user_code as the complete query string (eg https://example.com/device?wdjb-mjht) or specify a “code” parameter name (eg https://example.com/device?code=wdjb-mjht). Recommending case-insensitive punctuation-ignoring alphabetic codes is good, but how does a user know this is the case for a particular code? Perhaps the advice needs to be to use a “fancy” input field with javascript to convert to uppercase as the user types and handle punctuation? [§6.1] The example user code “WDJB-MJHT” doesn’t have “24^8 bits of entropy”, but “log2(24 ^ 8) = 36.7 bits of entropy”. -- James Manger On Mon, Feb 27, 2017 at 9:46 AM, <[email protected]<mailto:[email protected]>> wrote: Title : OAuth 2.0 Device Flow for Browserless and Input Constrained Devices Filename : draft-ietf-oauth-device-flow-04.txt Abstract: This OAuth 2.0 authorization flow for browserless and input constrained devices, often referred to as the device flow, enables OAuth clients to request user authorization from devices that have an Internet connection, but don't have an easy input method (such as a smart TV, media console, picture frame, or printer), or lack a suitable browser for a more traditional OAuth flow. This authorization flow instructs the user to perform the authorization request on a secondary device, such as a smartphone. There is no requirement for communication between the constrained device and the user's secondary device. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
