Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices

William Denniss <wdenniss@google.com> Tue, 02 January 2018 22:13 UTC

Return-Path: <wdenniss@google.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 28A3B12D82F for <oauth@ietfa.amsl.com>; Tue, 2 Jan 2018 14:13:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xaJKubd0Bz87 for <oauth@ietfa.amsl.com>; Tue, 2 Jan 2018 14:13:19 -0800 (PST)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 DE4551241F8 for <oauth@ietf.org>; Tue, 2 Jan 2018 14:13:18 -0800 (PST)
Received: by mail-yb0-x230.google.com with SMTP id b39so7041709ybj.13 for <oauth@ietf.org>; Tue, 02 Jan 2018 14:13:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gq+bAxogvc4EFwXEXtrbxFisCavKuw9l65Vlv4BB8w0=; b=mw+yo4L2WiXc5XnANceeK3BMEe8thH2RstPchdbUKJSj5UC/wr0vG5oBgh0EXiz6Ap +y7wPCNhFzwvV/lXlaC3krRbHo411UUpcIhtSL/IHnu5wMnXqQ/n5aPrhcyn3RHMPaac qqBhUQOkMLvddybf07jrlFURvuR22Yi35X4y08QtCGpzz/kaXWtEhreZHlK3PvH0M+Ys +J+/D7QsTslvVVpJE79Qo744NHvostg8S/qy3mO+mjNcW6H+NRrNuWj+dzt3PcHzSMiz wpJX6USHHbyXQkM6Xee2zGI8PTPIddcqpM8m7uhkfcOXHMVWpc60/eYiOPtQRiq0BUAQ 8U7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gq+bAxogvc4EFwXEXtrbxFisCavKuw9l65Vlv4BB8w0=; b=Js0fe7lgyDI1nAlynexH3Uj4a5ANNY8CqJFNO40wz8zjwnCP3VfzUywGVBbZ3zvKrO fxjRZJ0hjiI6ahjNOcBfCk3Wh77s5/P3UgVAWjx3U31R6M5qB2FGSoNmQGhEm+lJY4zw Q5B7bptu5htz17+gwVv7nGSetLJWMOuQyFW5pmawPVu69wBS7G/TTgMik/6nIOoolXC/ 8dE7akF3f6D0gZ2Man4qG6WVHir1gE0EQk4MHr0NylU7mWeyiQMp04YH77cfpXrRlJdU R/sOw2S1QjOwRRs1vyACE5QaG/5LZfEUqUDjqwDQRMhvZE5taPZ+F8FV1MWyS0iMzDeS p+Pg==
X-Gm-Message-State: AKGB3mIgI4E1+ktE0fcYy1rK7nQyKdmpVhQHJTWH1xyZvkrqZRAGap9L OSqxrT7lk+lnp5Ru3mJGMZGkgHHFgiTmarkKPII6GCkfyWE=
X-Google-Smtp-Source: ACJfBotd0FCMiGPlO9WgsYjIqIWV2dnAMeMy1oiE5QxL2jGlGrDCUxlwHxKI3GX6GmyvHtELPHM1jf70wOIaadKizsw=
X-Received: by 10.37.132.132 with SMTP id v4mr28149660ybk.512.1514931197518; Tue, 02 Jan 2018 14:13:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.160.146 with HTTP; Tue, 2 Jan 2018 14:12:56 -0800 (PST)
In-Reply-To: <BCC03DD9-7BC3-450A-9DEB-96FF7B48F1FB@verisign.com>
References: <CAGL6epLJHUn+4E1jksJW=Zpu=DE84uQgARhHyPH3H8yAAkijOg@mail.gmail.com> <4e14a1ec-8b6d-476b-3949-8a0b63017232@connect2id.com> <CAAP42hBY74goaNvJBb0yQ9AG4aQAmyVGxJFxHrUYtDdefouEJA@mail.gmail.com> <b123d697-25ae-43df-2ef9-388c0adfdb92@connect2id.com> <CAAP42hBxPhq_pMN7fON=HVW5kE=E=Xqt8Yo-9JHJOTBp6MuFLQ@mail.gmail.com> <BCC03DD9-7BC3-450A-9DEB-96FF7B48F1FB@verisign.com>
From: William Denniss <wdenniss@google.com>
Date: Tue, 02 Jan 2018 14:12:56 -0800
Message-ID: <CAAP42hA_1gcasD4wMj1Wam4E=mtSSA2yGmt0WzrtrDzc5JeUcg@mail.gmail.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="089e082c2688e411cf0561d26791"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/dNks-X8Yby7g3eAN-mix4izZN8M>
Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
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: Tue, 02 Jan 2018 22:13:21 -0000

Hollenbeck, sorry – I just found a half-written email in my drafts, will
finish & send shortly. I don't think this will impact the draft status, as
it's not too late to add text regarding entropy recommendations if in fact
this is the outcome of that discussion.

On Tue, Jan 2, 2018 at 1:50 PM, Hollenbeck, Scott <shollenbeck@verisign.com>
wrote:

>
> On Jan 2, 2018, at 4:08 PM, William Denniss <wdenniss@google.com> wrote:
>
>
> On Fri, Dec 15, 2017 at 11:12 PM, Vladimir Dzhuvinov <
> vladimir@connect2id.com> wrote:
>
>> On 15/12/17 00:43, William Denniss wrote:
>> > On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov <
>> vladimir@connect2id.com
>> >> wrote:
>> >> Hi,
>> >>
>> >> I just got a question on Twitter about the slow_down error:
>> >>
>> >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07#
>> section-3.5
>> >>
>> >> The question was why slow_down is communicated via HTTP status code 400
>> >> and not 429 (Too Many Requests).
>> >>
>> > We could, it seems to match the intent of that error code. Main reason
>> it's
>> > not like that so far is that 400 is the default for OAuth, I fear people
>> > may not be checking for a 429. We don't strictly *need* the 429, since
>> > we're returning data in machine readable format one way or another (i.e.
>> > it's easy for the client to extract the "slow_down" response either
>> way),
>> > which differs from HTML over HTTP which is intended for end-user
>> > consumption, making the specific status code more important.
>> Yes, on a 400 clients will need to check the error JSON object anyway,
>> so the "slow_down" cannot be missed. Whereas with 429 that becomes more
>> likely.
>>
>> +1 to return "slow_down" with status 400 as it is with the other OAuth
>> error codes.
>>
>
> Thanks for considering this Vladimir. To conclude this topic, it seems
> there are no compelling reasons to change to the 429, and a reasonable
> explanation of why it's a 400, so I think we should keep things as-is.
>
> Rifaat: The deadline has passed on the WGLC, and I believe all comments
> raised have been addressed. Can we now advance the draft?
>
>
> No one responded to the comment I shared on 27 November.
>
> Scott
>