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

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 8 Dec 2017 21:42:24 +0200

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

Thanks,

Vladimir

On 27/11/17 15:55, Rifaat Shekh-Yusef wrote:
> All,
>
> As discussed in Singapore, we are starting a WGLC for the
> *draft-ietf-oauth-device-flow-07* document, starting today and ending on
> December 11, 2018.
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>
> Please, review the document and provide feedback on the list.
>
> Regards,
>  Rifaat & Hannes

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Dec 2017 09:46:09 -0700

I couldn't get the QR code to work... ;)

On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef <[email-masked]>
wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: William Denniss <[email-masked]>
Date: Thu, 14 Dec 2017 14:43:29 -0800

On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov <[email-masked]

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

What do others think about this? It's a simple change to make.

---

From: William Denniss <[email-masked]>
Date: Thu, 14 Dec 2017 14:43:34 -0800

> I couldn't get the QR code to work... ;)

Mild shock! ;-)

> On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef <[email-masked]
> > wrote:
>
>> All,
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 16 Dec 2017 09:12:20 +0200

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

Vladimir