Re: [OAUTH-WG] A few questions to draft-ietf-oauth-device-flow-06

Nat Sakimura <> Thu, 12 October 2017 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9111013454F for <>; Thu, 12 Oct 2017 10:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 CgIb24BMI--Z for <>; Thu, 12 Oct 2017 10:43:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E780134317 for <>; Thu, 12 Oct 2017 10:43:41 -0700 (PDT)
Received: by with SMTP id 189so6303119iow.10 for <>; Thu, 12 Oct 2017 10:43:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QWZhPRZIm7xFd04TfbISlealhw7535X1EnPkKLRyjO8=; b=Rt+zE394uL3Sa07lhm+XAlP86X3Sfh50fOd7aKGH/gtkKoYSKOHoK2AVaN1KkXek04 QvBJ6q1zhe2EkXFZJamM4ejZEEKZelrhHhER9aiH2eJiQLeFtNoXhicneE0rNaSORztP sORVj7V5rDiKsY5ny47OBhwgqKkJ3L27E1r05ds5+3FiTFXvlDIgQbSPVDZnKZdVOLm3 kxAWkpY3YHPmw5nSQ9uPlfEis4+ksFFAl/hqrzsjTZS4sJUoysplSbXr4u9hJJF1QI5u XK3az03rJaCM54C1/rKg19gKF6pXFJa6FPqHN9cq2nywOunXzkIeGjOs0x8QQ2THaAoi 33Jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QWZhPRZIm7xFd04TfbISlealhw7535X1EnPkKLRyjO8=; b=iyyEc/s7h8hue8/7Hviba9dveJRv0kGU0LLS/xwF+mPLi6Cn33V+au0z0IuGmlEAN7 xlt67fTat7jQ+j6PwOWFlcSnE99S37y8BVCo/sBGe6KQ0S6TwvpKSbop0QMkj2G9mHsg JIRzp47m/LYnE3uFJCcJSuqe/xNzqeOQ0KUO7mZW9qbfWto7oROnDX/eeb5aGH2nhrnp 4x9j7hxuU0CuoF2ZKcuAideEO1CS1CACEtZYLrcAl2ZJ4GIod5XT4pzk+dr7SOqffdjK Y5o6XanHD2JSwPLGh1qFlAzzjxHtKgNjFBqT+dB2zg5PP78Jl0q1IB+vAKtGmiGQ8xx6 fQWA==
X-Gm-Message-State: AMCzsaWAyZhOZTmTCdcGxmiFhB5m5iSImBpaY4gVGAMyCVvSLlC9PFp8 GTDaHBR9dVIjqVnEjdkm0h1WeWX1LjAYXQTXgk8=
X-Google-Smtp-Source: ABhQp+ROtWrvu/j49S3XHJSWwo2hzb+/78BbWGUX4wA3QLFFMlAPGiVRznlr/SRXGO13UhMq3K5bd/5SMGb5ulxvf1U=
X-Received: by with SMTP id 34mr3878691ioq.169.1507830220411; Thu, 12 Oct 2017 10:43:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Nat Sakimura <>
Date: Thu, 12 Oct 2017 17:43:28 +0000
Message-ID: <>
To: William Denniss <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="001a113edbd4ab58ef055b5d14b6"
Archived-At: <>
Subject: Re: [OAUTH-WG] A few questions to draft-ietf-oauth-device-flow-06
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: Thu, 12 Oct 2017 17:43:44 -0000

Thanks for the very quick response!

Re: the last point -- I had a particular kind of Kiosk terminal based
client which is split between the Kiosk which only has a browser with some
hardware driving plugins and the server side that deals with most of the
logic. The user comes to the kiosk terminal and touches a button on the
screen. Then, it will trigger a browser to spawn and access a preconfigured
URI on the server component of the client which creates the HTML user
interface displaying the URI and the user code (probably in a QR code). The
page starts polling the authorization endpoint then. Note that it is not
the token endpoint in this case. The user then scans the QR code with his
smartphone app to get to the authorization server. Then the user
authenticates and authorizes at the authorization server. Once that is
done, the polling finishes and the browser in the Kiosk get the `code`,
which is handed back to the client. Then, the client calls the token
endpoint to get the access token etc. Similar kind of scenario applies to a
case where a client that resides on a small computer has to interact with
various makes and OS of the user terminal, which is not under its control.

Am I clear enough?


On Fri, Oct 13, 2017 at 2:11 AM William Denniss <> wrote:

> Hi Nat,
> Thanks for reviewing the draft!
> On Thu, Oct 12, 2017 at 9:57 AM, Nat Sakimura <> wrote:
>> Thanks to the authors for coming up with this document.
>> The scenario is very close to what I implemented back in 2011 or so, so I
>> am naturally interested.
>> Here are some questions I have with the draft.
>> 1) Am I correct to assume that the draft targeting a device that is
>> completely unable to accept user input?
> The spec itself requires zero input on the primary device (it's an
> exercise to the implementor on how to trigger it, etc).
>> 2) I feel that it is appropriate to mention the shoulder hacking as well.
>> In the Kiosk kind of use cases, the screen might be watched by the remote
>> camera and the "session" might be hijacked by the remote attacker. (This is
>> why I am asking 1) above. If the device has a capability to accept a
>> number, the risk can be made much lower. )
> We should add this as a security consideration.
>> 3) It probably is better to explicitly say that "device code MUST NOT be
>> displayed" especially in the case of a public client.
> Agreed.
>> 4) Does section 3.4 and 3.5 exclude the possibility of using something
>> like web socket?
> We are specifying a very basic approach assuming highly constrained
> clients. I like the idea of doing better than simple polling but not sure
> how to best add this and keep the spec streamlined. One thought was a HTTP2
> long poll where the server just keeps the connection open, which I believe
> is possible as specified (though we don't mention it, and I don't have
> experience with this).
>> 5) If my read is correct, the client is doing the polling etc. by itself
>> and not spawning a system browser.
> Correct.
>> In a Kiosk kind of use case, I can imagine a case that the original app
>> spawning a browser -- i.e, doing PKCE. In this case, the authorization
>> server creates user authentication and authorization page that displays the
>> verification URI and the user code. The client does nothing but a regular
>> PKCE. This kind of use case is out of scope for this document, is it
>> correct?
> I don't quite follow, can you elaborate?
> Cheers,
> William
>> Cheers,
>> Nat Sakimura
>> --
>> Nat Sakimura
>> Chairman of the Board, OpenID Foundation
>> _______________________________________________
>> OAuth mailing list
> --

Nat Sakimura

Chairman of the Board, OpenID Foundation