Re: [OAUTH-WG] OAuth Digest, Vol 104, Issue 30

井上直紀 <white.fuku3@icloud.com> Wed, 28 June 2017 22:24 UTC

Return-Path: <white.fuku3@icloud.com>
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 E4AE512EB44 for <oauth@ietfa.amsl.com>; Wed, 28 Jun 2017 15:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.501
X-Spam-Level:
X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com
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 wZbImqYEzgbl for <oauth@ietfa.amsl.com>; Wed, 28 Jun 2017 15:24:49 -0700 (PDT)
Received: from mr11p26im-asmtp004.me.com (mr11p26im-asmtp004.me.com [17.110.86.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B53B12EC71 for <oauth@ietf.org>; Wed, 28 Jun 2017 15:24:49 -0700 (PDT)
Received: from process-dkim-sign-daemon.mr11p26im-asmtp004.me.com by mr11p26im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OSA00O003D4IJ00@mr11p26im-asmtp004.me.com> for oauth@ietf.org; Wed, 28 Jun 2017 22:24:49 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1498688688; bh=4L7GHOlPmFC+8HChFA29REpZDFPqccKTE9tqS+xDak0=; h=From:Content-type:MIME-version:Date:Subject:Message-id:To; b=LcP/1kZIFW7JxG2Id3keVSHf3eaIpoHaDwkGPjHb4J//lGlbfvqChPnXxRYCSscNT K13EClsXE84xLhho42lW246xIMXi7D4pNAhiAdOKJ1RETAQ8H5Y/nCfpHiFzvnOYXP Mi7JWCsAMx8+q+1hMsXCvB3LBnEJYvSfelp2RCGaNxl+wmCOsYp16Ef47cTvoVaCKi ZQcTuYjn5rC/7ajQScI8Pc4hkAja2UF4o0nd2MBTcooRLJv6Gq+osZO+DhDDwk4AVl XnXZf164ELTDxvQT/+iXZpfmj70A6BYnB447JoKarqBbXGm8GLBGR03a/INARb5uHA ILFk46sNxpd8A==
Received: from icloud.com ([127.0.0.1]) by mr11p26im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OSA005CI3LARO30@mr11p26im-asmtp004.me.com> for oauth@ietf.org; Wed, 28 Jun 2017 22:24:48 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-28_14:,, signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1706280359
From: 井上直紀 <white.fuku3@icloud.com>
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (1.0)
Date: Thu, 29 Jun 2017 07:24:45 +0900
Message-id: <5559F37F-CF65-43FE-A281-1BB8607506B0@icloud.com>
References: <mailman.89.1498676411.31174.oauth@ietf.org>
In-reply-to: <mailman.89.1498676411.31174.oauth@ietf.org>
To: oauth@ietf.org
X-Mailer: iPhone Mail (14F89)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/AW0MAjoDQCFuwSL1zQgexLzNcfw>
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 104, Issue 30
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 22:24:57 -0000


Sent from my iPhone

> On Jun 29, 2017, at 4:00, oauth-request@ietf.org wrote:
> 
> Send OAuth mailing list submissions to
>    oauth@ietf.org
> 
> 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
>    oauth-request@ietf.org
> 
> You can reach the person managing the list at
>    oauth-owner@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> 
> 
> Today's Topics:
> 
>   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
> From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
> To: oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06
> Message-ID:
>    <CAGL6epJV_ymy5cNE5FJhyOXRYprCFs3hpL6-dg2WWZmY-cUUBA@mail.gmail.com>
> 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
> 
> 
> On Thu, Jun 1, 2017 at 8:32 AM, Rifaat Shekh-Yusef <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
>> 
>> 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 --------------
> 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
> From: Justin Richer <jricher@mit.edu>
> To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
> Cc: "<oauth@ietf.org>" <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06
> Message-ID: <2F9EAD6E-DDBD-4763-AF7D-51A7018216E1@mit.edu>
> 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
> 
>> On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef <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
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> -------------- next part --------------
> 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
> From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
> To: Justin Richer <jricher@mit.edu>
> Cc: "<oauth@ietf.org>" <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] WGLC draft-ietf-oauth-device-flow-06
> Message-ID:
>    <CAGL6epLPXRA=31WhV=jU3FAXQKhY99=RsXPG2HMkfeZQWE+hGQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
>> On Wed, Jun 28, 2017 at 11:33 AM, Justin Richer <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.
> 
> 
> 
>> 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?
> 
> 
> 
>> 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
>> 
>> On Jun 28, 2017, at 8:27 AM, Rifaat Shekh-Yusef <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>
>> wrote:
>> 
>>> All,
>>> 
>>> We are starting a WGLC on the Device Flow document:
>>> 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
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20170628/050d51cc/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> ------------------------------
> 
> End of OAuth Digest, Vol 104, Issue 30
> **************************************