[OAUTH-WG] Device Flow: Alternative to Polling

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 21 October 2016 22:23 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D32A129534 for <oauth@ietfa.amsl.com>; Fri, 21 Oct 2016 15:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.032
X-Spam-Level:
X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvDWvSeSI3BI for <oauth@ietfa.amsl.com>; Fri, 21 Oct 2016 15:23:16 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA291295C2 for <oauth@ietf.org>; Fri, 21 Oct 2016 15:23:15 -0700 (PDT)
Received: from [192.168.91.153] ([104.132.0.103]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LnTjW-1cZVoF2jvi-00hetu for <oauth@ietf.org>; Sat, 22 Oct 2016 00:23:14 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
To: "oauth@ietf.org" <oauth@ietf.org>
Message-ID: <8b540eff-2b1c-2d9f-6d40-2be327f91eb7@gmx.net>
Date: Sat, 22 Oct 2016 00:23:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="04ueIdh9H64PawnTWPsAFtR9bQfa0roxM"
X-Provags-ID: V03:K0:4dGd+p+GJEtqGn+1Sz95eLKlcpPpWlmWjWxtdskagY3mp1v+OD/ rmBmHXNslm77f8Q2mdNMkJ1H+5cRZMaBr79qA6GkOCFKP4eSUXb+wP+xy4EN8iptEbruvWu kV1ak4lIkBFJGwrr2Q0XklOPCAHW4+qVrn8h7pXuYrmFWJMeKdkuUyfCuJhmNQ/rkbaHSyc oMzAneOm21R40XwvnUJAA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:wyCKY+v9eGk=:W8jdI8oRkeQbtggoBhvVz0 LSq17DdPRcn5ruvfjleRDtfDVMMaZjituKakx7PWJUgEOB2iuLc114eZtgULwpirugSmfi2w6 nL6ta0G7S105LFDTR+y5qCoP9PUEd2/E2y3jwKgCdexzz2ICTZ7rrKdlVdBXFILA7PaXS/Jol k9yV7P1PcmkTnieLzNfgSn8v4EVl8LW0XPfwakOcsmVYBMXMsSqtsWBPILOW+2BmIDx5Iiygs 2P4hZiLxfkeEtiejaqFwIG2H3d0TzczUk0bZJqkIUTICa5q8lnBPhEwvzwGWXpxZ0O3EssZR6 y169JCgtM1oyiyPVx4nWFDhQKtw9qllMTr5AOcXSDLa1z3/lL6LcQOQyF5F7qXt2u2K4/V8vd Z6y/WvgcQD7AJVo1B245WJ6NNA3MeWl1HRexq4IpllqkGR/R8jFAIPeq63Wm7Q3kPFylBnld3 LHPWcsAEO30mzIXIsFEd+IA924li+U9uBfrmb0I7ofv1g3bV/csPZ08ScADUeZQTzRGdXo/px x0L68pGschaR0QgJuL9jyfknTZ9uL0K/MPdWKPw2OKvIc9G8OhbbvhwFRuOAeguCmOaPOeOYh y3RRcz/h8h/eITS+cH7a3wWP4MF8sgLIAN0Bn46HBwSTOPgVl2qcZ4I8ymvwBWEiLyoHrZB58 7Ti/NRJeqnK/MHigCYKbHUiV9SVygNgF405RizO1oVuaDjddQRSvxo0Bh5KSTm3NIcecMYPiy yssSz1dJAvch8daifwYAYiFih8hmPpFqBs0V0Ls39BY88D1c/unNDQs8mkk=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/37INAAHk-kAevBrWJufBrCoQhkM>
Subject: [OAUTH-WG] Device Flow: Alternative to Polling
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 21 Oct 2016 22:23:18 -0000

Hi all,

the device flow document outlines the case when an OAuth interaction
gets "outsourced" to a separate device in order to allow user
authentication and collecting the consent.

The exchange is described in Section 1 of
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03.

Here is the step that was raised during the discussions:

      (E) While the end-user authorizes (or denies) the client's request
      (D), the client repeatedly polls the authorization server to find
      out if the end-user completed the end-user authorization step.
      The client includes the verification code and its client
      identifier.

The question was whether we could come up with an alternative to polling
since this step could potentially take some time. Hence, it would be
better if the authorization server has a way to send a message to the
client without polling. Of course, the polling frequency matters and how
quickly one (e.g., user) wants to know about the successful authorization.

So, the first question is whether polling is considered as a problem in
the first place.

If so, then the question is how this could be addressed and (from work
in other areas) there are really only two approaches:

1) We make use of some protocol that keeps the connection open and allow
asynchronous communication. HTTP/2 and Websockets come to mind.

2) The client can be addressed through some push notification mechanism,
such as by running an HTTP server on the device that can then be used by
the authorization server.

Any views about this topic?

Ciao
Hannes