井上直紀
2017-06-28 22:24:45 UTC
Sent from my iPhone
Send OAuth mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a út message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
1. Re: WGLC draft-ietf-oauth-device-flow-06 (Rifaat Shekh-Yusef)
2. Re: WGLC draft-ietf-oauth-device-flow-06 (Justin Richer)
3. Re: WGLC draft-ietf-oauth-device-flow-06 (Rifaat Shekh-Yusef)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Jun 2017 08:27:01 -0400
Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06
Content-Type: text/plain; charset="utf-8"
Hi (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
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20170628/e20dfd7b/attachment.html>
------------------------------
Message: 2
Date: Wed, 28 Jun 2017 11:33:28 -0400
Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06
Content-Type: text/plain; charset="utf-8"
This 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.
In practice, this isn?t very likely to happen, as it requires additional steps for the user and makes for a more clunky experience. 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
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20170628/4af5963c/attachment.html>
------------------------------
Message: 3
Date: Wed, 28 Jun 2017 14:35:33 -0400
Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06
Content-Type: text/plain; charset="utf-8"
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.
one more time after the user is done with authenticating and authorizing
the device; do you see any other steps needed here?
Regards,.
Rifaat
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20170628/050d51cc/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
------------------------------
End of OAuth Digest, Vol 104, Issue 30
**************************************
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a út message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
1. Re: WGLC draft-ietf-oauth-device-flow-06 (Rifaat Shekh-Yusef)
2. Re: WGLC draft-ietf-oauth-device-flow-06 (Justin Richer)
3. Re: WGLC draft-ietf-oauth-device-flow-06 (Rifaat Shekh-Yusef)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Jun 2017 08:27:01 -0400
Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06
Content-Type: text/plain; charset="utf-8"
Hi (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
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
-------------- next part --------------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
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20170628/e20dfd7b/attachment.html>
------------------------------
Message: 2
Date: Wed, 28 Jun 2017 11:33:28 -0400
Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06
Content-Type: text/plain; charset="utf-8"
This 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.
In practice, this isn?t very likely to happen, as it requires additional steps for the user and makes for a more clunky experience. 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
Hi (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
-------------- next part --------------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
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20170628/4af5963c/attachment.html>
------------------------------
Message: 3
Date: Wed, 28 Jun 2017 14:35:33 -0400
Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06
Content-Type: text/plain; charset="utf-8"
This 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 ifconcerned. 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.
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.
In 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 buttonsteps for the user and
one more time after the user is done with authenticating and authorizing
the device; do you see any other steps needed here?
makes for a more clunky experience.
I guess this is subjective, but why do you think it is clunky?Regards,.
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
Hi (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
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
-------------- next part --------------some clients. In any event, it?s not any different from the spec?s
perspective.
? Justin
Hi (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
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
_______________________________________________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
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20170628/050d51cc/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
------------------------------
End of OAuth Digest, Vol 104, Issue 30
**************************************