>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04
>> 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. > I don't really see the benefit. If the device is always used with a pre-installed companion mobile app: no benefit. If the device has ample screen size for "To register, visit <uri> and enter <code>": no benefit. If the device can use NFC/BLE/QR-code/… to transmit a URI: benefit; can get verification_uri and user_code to a mobile browser without anything else (on the device or on the mobile). Scenario: a device with no screen, just a few LEDs; the instructions say "to activate, tap the device with your mobile (after enabling NFC or bluetooth)". User taps with mobile; browser launches; AS shows picture of device and asks user to confirm LEDs are flashing red/green/red/green… (on form with CSRF-protection); user click Yes; next device polling token request succeeds. This scenario is harder without a standard way to combine verification_uri and user_code into a single URI. > If you're doing some kind of out-of-band transmission (which is mentioned as > out of scope of the spec) there's no reason you can't simply transmit both > pieces of information. My guess is that "transmitting both pieces of info" requires special-purpose code that understands those 2 pieces. Whereas browsing to a transmitted URI is generic. > We've done that before, and this is what we do. Having the data separate >did not really alter the implementation of this, and combining it wouldn't >measurably make it simpler (but it would make the spec more complex). > > Also if the AS really wanted to, there's nothing to stop it including > whatever parameters it wanted in the verification URI today (which could > include the user code). > So I'd prefer to keep 1 protocol, designed for the browser model (which is > the only thing in-scope in the spec), that can potentially work with a wide > range of cases. It is still the browser model; it's just how the URI and code get to the browser. >> 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). > -1. I know for sure Google's AS will not comply with that MUST. As it is > there are some phishing concerns around this flow (documented in the spec), > and this change unfortunately makes the matter worse by allowing for > single-click phishing. I didn't mean to imply the AS had to *finish* the flow immediately when uri?code was accessed. An AS can still display anti-phishing measures requiring explicit user clicks to continue. The AS could still display a picture of the device. I do concede that requiring a code to be manually entered is a specific phishing defence so any alternative should probably be specified separately. > For example, we use the text today: "Enter the code displayed on your > device". And we display a picture picture of the device to help guide the > user as to the expected usage of this flow (this by itself isn't everything – > but they are important hints). >> 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? > I believe that's covered: > > The server should ignore … I guess I read that as a suggestion for server-side code. But the user needs a hint at the client-side as they enter the code. This is a minor detail. A web form could, for instance, say "case and punctuation are ignored" below the code input field. -- James Manger _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
