Inline.
Post by Justin RicherPost by Justin RicherThis is functionally equivalent to polling, as far as the spec is concerned. Instead of it being a timeout-based poll, itâs an interaction-based poll. Either way, the device makes a new HTTP request to the AS to see if the device code is good or not, and either option is possible at that point as far as the device knowsâ the user could go mash buttons as fast as possible without ever entering the user code.
You are correct that this does not change the communication model, but if there is a large number of devices being configured at the same time, then the polling as it is defined in the document unnecessarily overloads the AS whether the user is doing anything or not.
The polling mechanism already has slow-down and other mechanisms to prevent the AS from being unnecessarily overloaded by well-behaved clients.
Sure, but if there is a way to avoid the polling altogether, then we might not need these slow-down mechanisms in the first place.
Thereâs not a way to avoid it altogether, and again I remind you that the current spec will already fully allow the use case that youâre describing, without requiring any changes to the text whatsoever. You could literally build a client today that does exactly what youâre talking about. All you need to do is:
1. Call the device code endpoint to get your device code and user code
2. Not call the token endpoint automatically
3. Wait until a button press to call the token endpoint
4. If you get a token back, great; if you get one of the errors back, wait until another button press
Note that if the user hammers the button too fast you should still wait for the timeout before calling again. This is only slightly different from most code deployed today:
1. Call the device code endpoint to get your device code and user code
2. Wait until a a timeout to call the token endpoint
3. If you get a token back, great; if you get one of the errors back, wait until another timeout
In fact, I wouldnât at all be surprised that somebodyâs built the first one along with the number of implementations of the second one that have been built to date. So Iâm still not seeing what changes youâd want in the specification to address this.
Post by Justin RicherPost by Justin RicherIn practice, this isnât very likely to happen, as it requires additional steps for the user and
It requires one more step (not steps), which is the user pushing the button one more time after the user is done with authenticating and authorizing the device; do you see any other steps needed here?
1) Being told I need to go click a button by the AS, or maybe I need to go click a button, because now we have something thatâs device specific and would be tied to the device registration. After all, some things will be âautomaticâ per the userâs experience (because of polling) and some will require further actions.
2) Finding the device because I wasnât at the device I was at my computer and maybe the device needs me to do something else or maybe not (see step 1)
3) Finding the button on the device, or is that one the power button? Or does this one require me to wave my hand in front of a sensor instead of a button? Maybe there are some instructions on the device, or it will talk to me and tell me what to do when I push the button.
4) Clicking the button. Or waving my hand. Or shaking it really hard. Or licking it.
5) Checking to see if it worked, maybe clicking the button again just in case...
We are talking about a use case where a person is getting ready to install a device, and you would expect the user to be able to find the device he wants to install and interact with that device.
Thatâs making a lot of assumptions about the nature of the device and the availability of the non-constrained login platform.
Post by Justin RicherAre you expecting the user to be able to install a device without any interaction with that device?
If youâre provisioning thousands of devices simultaneously like you said in your original email, I should hope I donât need to go around pushing a bunch of buttons to make it happen. So, yes.
Perhaps if you can describe in detail what changes youâd like to see to the specification, or in what way the current text does not allow for your use case, then Iâd be able to understand what youâre asking for.
â Justin
Post by Justin RicherRegards,
Rifaat
Post by Justin Richermakes for a more clunky experience.
I guess this is subjective, but why do you think it is clunky?
See the process above. Itâs going to be incredibly device specific and not something we can, or should address at the protocol level, especially since the protocol as-is already allows for action-based polling completely transparently to the rest of the system.
Common mechanisms for determining when to poll include use of an internal timer and reliance on an interaction with the user, such as a button click or other physical activation. The details of such reactive polling behavior are expected to be device specific and are therefore outside the scope of this specification.
Thanks,
â Justin
Post by Justin RicherRegards,.
Rifaat
If anything, we might see it as an optimization in some environments for some clients. In any event, itâs not any different from the specâs perspective.
â Justin
Post by Rifaat Shekh-YusefHi (as individual),
I have reviewed the Device Flow document, and I have a question about the polling part.
The current draft is calling for the Device Client to poll the AS for a token (steps E & F of Figure 1).
Presumably, the process started with the user pushing some button on the Device Client to initiate the process.
One way to avoid the need for polling is for the Device Access Token Request to be sent to the AS only after the user for example pushed that same button again.
This would allow the user to perform steps C and D to authorize the device, and then push the button again to get the token.
Thoughts?
Regards,
Rifaat
All,
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06>
Please, review the document and provide feedback on any issues you see with the document.
The WGCL will end in two weeks, on June 16, 2017.
Regards,
Rifaat and Hannes
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>