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

Nat Sakimura <sakimura@gmail.com> Thu, 12 October 2017 16:57 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 21F2913453E for <oauth@ietfa.amsl.com>; Thu, 12 Oct 2017 09:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id epQ087UwtHzM for <oauth@ietfa.amsl.com>; Thu, 12 Oct 2017 09:57:43 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB90124F57 for <oauth@ietf.org>; Thu, 12 Oct 2017 09:57:43 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id m16so6182712iod.1 for <oauth@ietf.org>; Thu, 12 Oct 2017 09:57:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4OGtooGHhk2pYjUKFS5PBlVT+iRTyB0z41BoulB8/cA=; b=vMkkwGGnvvSmirE9YHiBcqfcsXZ2pjcRDKOYvXsEnHG6OERIpqcwDcL0JWRoz+Vvpy RHcmnX2gJONPWPoIxd4TxXw31FbAfTr2wEECTXjW8bLdw0zH805vyBKDgkt6QZLcrUBP UsuuG8IOX0MPB5vj3NmpM8ecGV+HuxWpqsRG4PnjGF7TyGCFhFhmerDkKYfC72CsAHOz 2hpt3pbmshUwWTADlDswTC+FEYMmuqbja6Yfap2X6+PiOB3y6lt4Qm5b8OFp/WcixjNj hOoRfoJXb4YJ0CaAuyDPX5q9fwk0SMYYJIa755zRy41uVeNSjj0dyTLII2ln17rpzCIa NukA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4OGtooGHhk2pYjUKFS5PBlVT+iRTyB0z41BoulB8/cA=; b=oxs2MXd1s+31SE+9xo+1ZGTCrsv/u8a+eAtJaYLdxnc2cL+5iBSqGLVPKVh0e1rysr uNefjJTbavrtMGYEepK4EhMTFVJ9hOww+2O6B5t3rmNxXk7WlAFgEEd9/KM9CimtIoG5 k8tHqiS4Tu8AOrqHXHw1NGho92BD1Xc5pX7poyIym2SddHNUPmr0zbPf/+4S/REwTivn B62VaBS41sJ2xwmgrAmISOBupLjykzQkTPaIa0BLWaMh+dmLj97lUnuyQynT7Fi0x0VG Lb4s220n5GSloUKOZprrk38C/lt13LtIAyr9+Qwyu0aVkEZ05UiDN0sf4sgOQUQHx4xT KF1g==
X-Gm-Message-State: AMCzsaVpVV1S70kFR9cUm7oeXqdqxnFJgRQRklO4b6GWoqV06aCSf3AN mGkGWYMOVAzMZag6RbhJeHpaXgBe+3+FCYGdRN00+g==
X-Google-Smtp-Source: AOwi7QCycW5xV0mRUMjdkMkBiwU4h01lP3E5/JVdQuLHCidkmXttHQU6dgBMEMC+O0KhDxUsKRW+JX0ceiOggC3Vpxs=
X-Received: by with SMTP id 125mr4066506iov.295.1507827462363; Thu, 12 Oct 2017 09:57:42 -0700 (PDT)
MIME-Version: 1.0
From: Nat Sakimura <sakimura@gmail.com>
Date: Thu, 12 Oct 2017 16:57:30 +0000
Message-ID: <CABzCy2AGoRnoD3gSe8E01siKmdJdgCeO9emD+zi9HWBpmMZ-sA@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05e7f846e14c055b5c70de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/H42Hu4oLso9-jVf-Mp2dDgRaHNY>
Subject: [OAUTH-WG] A few questions to draft-ietf-oauth-device-flow-06
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: Thu, 12 Oct 2017 16:57:45 -0000

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


Nat Sakimura


Nat Sakimura

Chairman of the Board, OpenID Foundation