Re: [OAUTH-WG] OAuth 2.0 Device Flow LC Comment (and OpenID Connect)

William Denniss <> Tue, 02 January 2018 22:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E56D12D82D for <>; Tue, 2 Jan 2018 14:38:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SVRACJLf7wD9 for <>; Tue, 2 Jan 2018 14:38:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 306C41270AB for <>; Tue, 2 Jan 2018 14:38:34 -0800 (PST)
Received: by with SMTP id o84so20281322yba.8 for <>; Tue, 02 Jan 2018 14:38:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pWSA3WNFMuAfo2Ogi4kGKt8pc6DYi1DPqhQOENzE64o=; b=VvR3qkisSbpiFRhvWmYv91iYM32nbUYp6IZvF0sJDojUxkRI5dosqYr5wERmZQW0nA MzdT35CaP90UkJ8irjR1eZbisZM2LnUgXjGPzQr0bc3hgxracYiKat+tD8u72wR553V3 oA6eFdhuLueHx9iS2M0qpljYIm+ub53j53OomKsiD8jPRYZ/3oYJyrXrt1wQfk3i+qzq jbYYNq4U8soYO3PwqYgmOyDHzwB48bOgfCVvB2JcsBFvS4eFHx2PWiyBwI1MswpRz6vD OT0sjc1gOKuMaHdRVEcNfE0AG1OSnxJMG1q8mFU9qR3txZJLuNVbjcmEszHqAAAtwExG XFOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pWSA3WNFMuAfo2Ogi4kGKt8pc6DYi1DPqhQOENzE64o=; b=dNSeg9hwHrdwIZ3u+PVU8PwCOPkjCEeIxUe0RE+h3K2d7w9uDtyQSx7D3OoeSNONpR dEdicL6EGiJqARSJ8BYAPh7F5oPBUL25NAc5IB+4087XTleNZ4vb0t+rvXlK71WFu7tF J/4j2sQVc4ARv3MZUZR+cRMB4XTV8EgAGIg81bbCPxqzjfqMYBKQWUJqaackFGs/+XOw cBjI3qTJaH+DYeMLeVG9TGnmhSFtFLdwL+Ww9TNVtsCjiaQhqjD7nYFuXMoPuRWf6uSs cLIL4q0ylWwhs69y1KRng+MUcoYqVCdCy0Sp7PefhOss9uuZcUPaNB5ft+XkOP1ZiXZO PWDA==
X-Gm-Message-State: AKGB3mIfQ0tugFxlV7upcuCXgdC6J8di7TsvXbrI7yd0zHJqjEFYbNzh anrHkppHG0iUAXmavZqbFXkD+5Mkm2Bf3cdR+5HrMH73
X-Google-Smtp-Source: ACJfBov7YRTymCPtaz+LKzCBLQrlsC49uGeBhZuKeLWEegeKEP+rik4CUQQ34VkEhK9FX+M90Oi7UHPDdme6f9EAi2M=
X-Received: by with SMTP id l4mr18896083ybm.398.1514932712823; Tue, 02 Jan 2018 14:38:32 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 2 Jan 2018 14:38:12 -0800 (PST)
In-Reply-To: <>
References: <>
From: William Denniss <>
Date: Tue, 2 Jan 2018 14:38:12 -0800
Message-ID: <>
To: "Hollenbeck, Scott" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="089e082667e4358ea00561d2c215"
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow LC Comment (and OpenID Connect)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jan 2018 22:38:36 -0000

On Mon, Nov 27, 2017 at 6:32 AM Hollenbeck, Scott <>

> I have reviewed draft-ietf-oauth-device-flow-07. Just one comment
> regarding Section 5.1:
> Would it be possible to suggest some minimally acceptable entropy value?
> The text says "The user code SHOULD have enough entropy that when combined
> with rate limiting makes a brute-force attack infeasible", but just how
> much entropy is enough?

There are a few challenges with requiring a minimum entropy of the
user_code due to the fact it's user-visible. Normally we would just set a
nice high number (like OAuth did
<>) and that would be
fine, as normally a few extra bytes on the token is no problem. With the
user_code however, the longer it is the harder it is to use. My expectation
is that the authorization server would determine their own acceptable
amount of entropy, trading off security for usability and taking into
account the expiry time of the code, and any brute-force mitigations they
have in place such as rate limiting.

Do you have any text to suggest?

> A related question: the last call made me wonder if there are any plans to
> add a device flow for OpenID Connect. Does anyone know if such a thing is
> in the works?

The Google implementation of the device flow already supports OpenID
Connect. Just add "openid" to the scopes in the request as you normally
would, and you'll get an ID Token on the response.

There isn't any effort that I'm aware of to document this. We could do it I
guess if there was demand, it would be quite a short document.

> Scott
> _______________________________________________
> OAuth mailing list