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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 02 January 2018 21:50 UTC

Return-Path: <shollenbeck@verisign.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 34F5112D84A for <oauth@ietfa.amsl.com>; Tue, 2 Jan 2018 13:50:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, 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=verisign.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 DkwoMgNippHA for <oauth@ietfa.amsl.com>; Tue, 2 Jan 2018 13:50:27 -0800 (PST)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62F5126CBF for <oauth@ietf.org>; Tue, 2 Jan 2018 13:50:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=5224; q=dns/txt; s=VRSN; t=1514929827; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=sJBmHv4rvgXpPsCrjxnjC9gZgnOZEatPtdvGpnwnNGo=; b=CA5BDsxKZFNEnF+23IPfNsJJb0d9JUS3e4T071sJED9/+lHmG91CvYTM kH3kLRpF0mrDDUIskaCcqubqjJBbD0jR6JpCFZD5Uw6+xjgkfG9cpeYWq FfbZG2O9okRP207wsscceflKu8lhLfwgUFkdyocLGh52CyGs1IY7LAq06 hmJ/wCzCEXsBjdD81WO8DA07O4MDsgDaS5p7AuP/qELoXjzLRMEP3Kgvu SqsqSdgyl5FOqEg4IkvaNpoq/VAC6dwmV28MbB680EfbuZIXCjkGMVe3Q 6snMlgYeoiPG2uuoPDeYyyidHOgi1Sw3xkxG6La2hNPcLvLq3noRjOD0t w==;
X-IronPort-AV: E=Sophos;i="5.45,499,1508803200"; d="scan'208,217";a="3510594"
IronPort-PHdr: 9a23:P2SKBBJouiYcwRnmAdmcpTZWNBhigK39O0sv0rFitYgfLPXxwZ3uMQTl6Ol3ixeRBMOHs6sC07KempujcFRI2YyGvnEGfc4EfD4+ouJSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgppPOT1HZPZg9iq2+yo9JDffxhEiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLdQgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QKsqUjq+8ahkVB7oiD8GNzEn9mHXltdwh79frB64uhBz35LYbISTOfFjfK3SYMkaSHJBUMhPSiJBHo2yYYgBD+UDIelXoJLwqEESoRu7HwSgGP/jxiFOi3Tr3aM6yeMhEQTe0QAuHdwOt3DUrNHrO6cUSu+60rXHzTbbY/hLxDny9I/Icgw9of2CQLl9dtHRyUkoFwPBilWft4rlMCiL2esRsGiW9PRgWvy1i24msAFxozevxsE2hobVgYIVz0nJ+CNky4g7It24TVR0Yd+iEJZItiGVKZd2Qs04T2FvoiY6xbsLsoO4cigS0Jkr2gLTZ+aaf4WK7B/vTvudLDd2iX5/Zr6yiBa//E69wePmTMa0ykxFri9dn9nJsXACygLc59CcSvt44kehwTGP1x3P6u1cIUA7i67bK5k5z7ErjJoTt1nPHiv5mUXzlqCWd0Ek+u+16+T7frnquIWQN5FqhQHkM6Qugc2/Aes+MgQUQ2eb/uG82KXi/U3/XrpKkuU7nrTFvJzAOMgWpKC0DxVI3osj5RuzFSmq3dsYkHUfKVJKYhOHj4znO1HUJ/D4CO+yg0+skDdsw/DGOqPuApPWIXfdjLjhfq1w61BCxwopzNBf/JNUCr4HIP7pRkDxs9nYAgcjMwOo2+bnFMl91oQGVGKIGKCZLb/SsV+T6+IuPeaMeIEVtCz6K/g/6P7klWU5lkMFfam1wZsXb2i1HupiI0qDfHXsg9IBEWYQvgclUOPqj1uCUThNaHmuQ6Iw+DA7B5+8AYjfQYCthaSL3D2nEZ1OemBGFleMHG/mdoqZRfgMbiSSIs56kjwfTrWhRIgh1RahtA/+1bVrNPbb+iodtcGr6N8g2OzXkRA78HRYAsKb0nqWBzVrkm4OQT4tx4hwpktyzlrF2q991a92D9tWsrlpVQM+OJjWwud5T5jJUQXdYp3BHE2mRdGiDDc7Q9ky68EDeUdmGtqkyBvE2nz5UPcui7WXCclsoern1H/rKpM4ki6e2Q==
X-IPAS-Result: A2G1AAAx/kta//WZrQpcGQEBAQEBAQEBAQEBAQcBAQEBAYQkgRuONZEalyoXgR8DXAojhRgChG8YAQEBAQEBAQEBAQKBEII4JAEOS1kBAQEBAQEjAj4tAQV5EAIBCAQJAQojBAcyFBECBA4FiUp0tFCKOgEBAQEBAQEBAQEBAQEBAQEBAQEaBYQMg2mBaCmDBYMvAYU2gjQFo0YGAogBoS+NJIkyAgQLAhkBgTwfbIEdb0gPJQFXAYEhBYMJgU54AYhzAQEB
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id w02LoPSw014778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Jan 2018 16:50:25 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Tue, 2 Jan 2018 16:50:32 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: William Denniss <wdenniss@google.com>
CC: Vladimir Dzhuvinov <vladimir@connect2id.com>, oauth <oauth@ietf.org>
Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
Thread-Index: AQHThA3a4DhalVuPCEWFw8dpWcXVsqNhH1EH
Date: Tue, 02 Jan 2018 21:50:32 +0000
Message-ID: <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>
In-Reply-To: <CAAP42hBxPhq_pMN7fON=HVW5kE=E=Xqt8Yo-9JHJOTBp6MuFLQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_BCC03DD97BC3450A9DEB96FF7B48F1FBverisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/IXn3m52OaTMmX5QDzk_JAIk_aJk>
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 21:50:29 -0000

On Jan 2, 2018, at 4:08 PM, William Denniss <wdenniss@google.com<mailto:wdenniss@google.com>> wrote:


On Fri, Dec 15, 2017 at 11:12 PM, Vladimir Dzhuvinov <vladimir@connect2id.com<mailto: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<mailto: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