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:* [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
--
ForgeRock <http://www.forgerock.com/> *Simon Moffatt*
Product Management | ForgeRock
*tel* +44 (0) 7903 347 240 | *e* [email protected]
<mailto:[email protected]>
*skype* simon.moffatt | *web* www.forgerock.com
<http://www.forgerock.com/> | *twitter* @simonmoffatt
ForgeRock Live 2017 <https://summits.forgerock.com/>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
