Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06

Justin Richer <jricher@mit.edu> Wed, 28 June 2017 20:45 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A07112EB1F for <oauth@ietfa.amsl.com>; Wed, 28 Jun 2017 13:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkiPI9Fu4HVe for <oauth@ietfa.amsl.com>; Wed, 28 Jun 2017 13:45:45 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D701270AC for <oauth@ietf.org>; Wed, 28 Jun 2017 13:45:45 -0700 (PDT)
X-AuditID: 12074423-40dff70000003249-6a-59541577bc21
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id BF.61.12873.77514595; Wed, 28 Jun 2017 16:45:43 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5SKjfwe014224; Wed, 28 Jun 2017 16:45:42 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5SKjdpr012264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2017 16:45:41 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <8C46E20E-EFF4-481A-99E7-ADD1A9DF133F@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0B88D72B-044A-4328-B273-24A6FF5DFFA5"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 28 Jun 2017 16:45:40 -0400
In-Reply-To: <CAGL6epLPXRA=31WhV=jU3FAXQKhY99=RsXPG2HMkfeZQWE+hGQ@mail.gmail.com>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
References: <CAGL6epKEzeYp163zn_6+o3beDaHGmm_TnjHGk4zV+riNxa-Dvw@mail.gmail.com> <CAGL6epJV_ymy5cNE5FJhyOXRYprCFs3hpL6-dg2WWZmY-cUUBA@mail.gmail.com> <2F9EAD6E-DDBD-4763-AF7D-51A7018216E1@mit.edu> <CAGL6epLPXRA=31WhV=jU3FAXQKhY99=RsXPG2HMkfeZQWE+hGQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hRV1i0XDYk0aLmnZ3Hy7Ss2i50vWtkc mDx2zrrL7rFkyU+mAKYoLpuU1JzMstQifbsErozND18yFuyqr3i2cRtbA+P5nC5GTg4JAROJ F6umsHUxcnEICSxmkth3cj4LSEJIYCOjxLO9zhCJh0wSG3t+gCXYBFQlpq9pYQKxeQWsJBbM /M8GYjMLJEmsun4eKM4BFNeX6H3OCBIWFrCRWPJ3J5jNAtR6aOl6VhCbUyBQ4uLK9Wwg5cwC 6hLtJ11AwiICehLtfxcyQaztZ5Jov/2XHeJQWYlbsy8xT2Dkn4Vk2yyEbRBhbYllC18zQ9ia Evu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5xcmJeXmqRrplebmaJXmpK6SZGUFCz uyjvYHzZ532IUYCDUYmHl2FtcKQQa2JZcWXuIUZJDiYlUd4j74FCfEn5KZUZicUZ8UWlOanF hxglOJiVRHgrzgLleFMSK6tSi/JhUtIcLErivOIajRFCAumJJanZqakFqUUwWRkODiUJXneR kEghwaLU9NSKtMycEoQ0EwcnyHAeoOEq/EA1vMUFibnFmekQ+VOMuhwLejZ8YRJiycvPS5US 5zUBGSQAUpRRmgc3B5SMEt4eNn3FKA70ljAvG0gVDzCRwU16BbSECWgJy7wAkCUliQgpqQZG hzTOQw7c0+u4/8y81H9z/h7fXIG68Nt55XNvmk9i6+CxuDBfa3/0ZMU7c4tWL7eYwL1H6VDv /p+JtTe/mMVpaPKcXrF+Qs7EFuOlS+easem+YC06r1vop1rW3Pfkf5v4co8J9+PmJilMvJqt WLVC5LNy3LxwieiYWdJ3jjk8U9x00NnCdUeoEktxRqKhFnNRcSIAAFXQnSEDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Tfy35btR07OE-d0Ngm1ALHNq8-U>
Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jun 2017 20:45:47 -0000

> On Jun 28, 2017, at 2:35 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
> 
> 
> On Wed, Jun 28, 2017 at 11:33 AM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
> 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 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. 

>  
> 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 button one more time after the user is done with authenticating and authorizing the device; do you see any other steps needed here?
> 

What you describe as “clicking the button” really isn’t that simple in the real world:

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...


>  
> makes 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. 

I don’t see any need for changes to the document to accommodate this. I would not be against a very small note that polling could happen on a reactive basis from the device instead of a timer, perhaps adding something like this sentence to §3.3¶3:

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


> 
> 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
> 
>> On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com <mailto:rifaat.ietf@gmail.com>> wrote:
>> 
>> 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
>> 
>> 
>> On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com <mailto:rifaat.ietf@gmail.com>> wrote:
>> All,
>> 
>> We are starting a WGLC on the Device Flow document:
>> 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
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>