[OAUTH-WG] polling in the device flow

Dirk Balfanz <balfanz@google.com> Tue, 08 June 2010 20:24 UTC

Return-Path: <balfanz@google.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 75C4F3A6823 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 13:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.562
X-Spam-Status: No, score=-99.562 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id VT3vzk-wgESa for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 13:24:05 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com []) by core3.amsl.com (Postfix) with ESMTP id BF46C3A684D for <oauth@ietf.org>; Tue, 8 Jun 2010 13:23:44 -0700 (PDT)
Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com []) by smtp-out.google.com with ESMTP id o58KNhrd000937 for <oauth@ietf.org>; Tue, 8 Jun 2010 13:23:43 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276028623; bh=6rbf8MFe/2QTasYvUahfEsVvLcw=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=hztZtGH/bfuJNPLXTNNhE4/TiILgyxDoF7He4FJeLVzZq9NUeBHJujPiz7R10xQfQ 4AdJ2DFvKu8Qz2wbvJ2GQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type; b=dk0TQ0PrKqHM+qTMrNVNya/ThtYdex+bAoQsAJGqis2mYlmLbkE2SkzqnFHd4ZhzC 7naYrnxpT5m4vuAs2qTFw==
Received: from iwn3 (iwn3.prod.google.com []) by hpaq1.eem.corp.google.com with ESMTP id o58KNgna016555 for <oauth@ietf.org>; Tue, 8 Jun 2010 13:23:43 -0700
Received: by iwn3 with SMTP id 3so1961166iwn.30 for <oauth@ietf.org>; Tue, 08 Jun 2010 13:23:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id 10mr717363icp.35.1276028622050; Tue, 08 Jun 2010 13:23:42 -0700 (PDT)
Received: by with HTTP; Tue, 8 Jun 2010 13:23:41 -0700 (PDT)
Date: Tue, 8 Jun 2010 13:23:41 -0700
Message-ID: <AANLkTimOXzscoFDtf-PO8965xuchEBJvqALiWM3O9fMl@mail.gmail.com>
From: Dirk Balfanz <balfanz@google.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=00163691fd97bd94c404888a9048
Subject: [OAUTH-WG] polling in the device flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 08 Jun 2010 20:24:10 -0000

Hi guys,

currently, we specify how polling should work in the device flow as part of
the OAuth2 spec.

I would argue that that polling should be handled at a lower layer of the
stack, and that OAuth2 should be silent on the issue of polling. The benefit
will be a simpler spec.

HTTP specifies the 503 response code with the (optional) Retry-After
response header. ASs could just use that mechanism to throttle clients,
instead of handling it at the OAuth layer.

The OAuth spec could say something like: "The client requests the access
token after the user approves or rejects authorization. If the client cannot
determine when the user has approved or rejected the authorization, the
client MAY poll the server. The server MAY use throttling mechanisms such as
503 HTTP response codes and Retry-After response headers which, if used, the
client MUST obey."

What do you guys think?

BTW, there is some precedence for this. Google's APIs use 503 response codes
to throttle servers, e.g.