Re: [OAUTH-WG] FW: draft-ietf-oauth-device-flow: url with code

[Simon Moffatt <[e-mail]>]

Hi James

My only comment on sending values are URL arguments, is that 
intermediary network devices typically log the entire URL - meaning the 
code would be written to a secondary location in logs for example.  
Whilst the re-use potential would be limited, it is of a course a 
potential...

Worth considering if using that approach.

My 2c.

Simon


On 01/03/17 00:23, Manger, James wrote:
>
> Resending; not sure that OAuth email list is working at the moment.
>
> *From:*Manger, James
> *Sent:* Tuesday, 28 February 2017 9:53 AM
> *To:* [e-mail]
> *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, <[e-mail] 
> <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
ForgeRock <http://www.forgerock.com/> 	*Simon Moffatt*
Product Management  |  ForgeRock
*tel* [phone]  | *e* [e-mail] 
<mailto:[e-mail]>
*skype* simon.moffatt  | *web* www.forgerock.com 
<http://www.forgerock.com/>  | *twitter* @simonmoffatt


ForgeRock Live 2017 <https://summits.forgerock.com/>