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

William Denniss <> Thu, 12 October 2017 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B552F134219 for <>; Thu, 12 Oct 2017 10:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, 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 EfeDveRq-gnS for <>; Thu, 12 Oct 2017 10:11:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9B1C133224 for <>; Thu, 12 Oct 2017 10:11:12 -0700 (PDT)
Received: by with SMTP id q4so14908744qtq.8 for <>; Thu, 12 Oct 2017 10:11:12 -0700 (PDT)
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=HjZyDmWhwQ7vvAdTg9Ydhc3sZfsaHjnbZtGK8gPE2xk=; b=qhwDOkoQLlpqEN8deSvGxNhUyM8467sCtcGsw8KdutoDxLVIygxdpw4ZJV6OZaLjYR ntPfEc89fJAEw1BpefNUbzWTiw24jdVn1N0qkI+e3Z+iHxm053iVvtsPGseFO4uENF5B ENltXluAEu+UbDsdHzS+aaEKrC1TWvSb9rtXkmO6i9KdAKMmOZhdPszLZCyjyEeW+3o0 dHmesCS7tJ0c6GN7f3JjOBbplwzEbMRwKj978P27d2C9tpqnTvxbHroPZ6I6GkMg31iu e9Lkng1icv8HT0uqKdQVG5FheHizr3FR2Y+mO/7lgOU6tTiej7WQ6pVvDvF2HYK7yChU sRHg==
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=HjZyDmWhwQ7vvAdTg9Ydhc3sZfsaHjnbZtGK8gPE2xk=; b=U3n2T63vpUQ65uo9ASPkTDGOHxv+1xwLCz/dWTpKmG1rZHh2wtKwuVti7NFnOilFVs Q86puUoZAuM8NoAn8i4tTdi8DgQZutulRhoaoMEsix+zaluROoVQYhQMDLfllBpUTnga TK9yNYR4xnX0ZsH0cZBnenkEoHYAJt+ovnWuPkTZfFzFSW+skN4NyG77XN5thk+FGRCF zuwfo6z2Scc3OBF3ebhktOFvPWGS40oGhZm8UVOPtq+1BLtWy9TPYedjdyRuVuBjrE+w 92D9uTEHLpXQOCS16Vqt3Z0g16UCJVXgOIYVfvhDM5XKKL9rOQEoTMQlYKLc8xfUzEJC 3RdQ==
X-Gm-Message-State: AMCzsaU/akEEE/pvTozkkNSJJ8m9lkMy/HJxXTtNQO/Wk/KflgxieYo5 72wKyC2Wlw/ibvSnqMLqxbO/ViS1a/MI7Cr2WjE28SQh
X-Google-Smtp-Source: AOwi7QD3AiA7LCE3LqIbPkOrZ6HeEL1rXeDpnqBU7wp5NRs8WiEsm78z+So6I4Z1IpavlaRPVCrX87kTsnHomB4B8sU=
X-Received: by with SMTP id c127mr2183389ybb.398.1507828271273; Thu, 12 Oct 2017 10:11:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 12 Oct 2017 10:10:50 -0700 (PDT)
In-Reply-To: <>
References: <>
From: William Denniss <>
Date: Thu, 12 Oct 2017 10:10:50 -0700
Message-ID: <>
To: Nat Sakimura <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="001a113e96027e8a7d055b5ca02c"
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:11:14 -0000

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.


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


> 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,
> Nat Sakimura
> --
> Nat Sakimura
> Chairman of the Board, OpenID Foundation
> _______________________________________________
> OAuth mailing list