IETF Logo Mail Archive

Re: [OAUTH-WG] polling in the device flow

David Recordon <recordond@gmail.com> Thu, 10 June 2010 00:03 UTC

Return-Path: <recordond@gmail.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E98B3A69BF for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 17:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.639
X-Spam-Level:
X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTfKkWcSyZ8Z for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 17:03:18 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8E6473A6880 for <oauth@ietf.org>; Wed, 9 Jun 2010 17:03:18 -0700 (PDT)
Received: by iwn42 with SMTP id 42so6368528iwn.31 for <oauth@ietf.org>; Wed, 09 Jun 2010 17:03:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fMkAt3dwGxerYqnYdlV2/cEKoKlcuJzxASNo8J9gW1M=; b=FuRT4d4FQ9kuaCrwkKNvkqoAIUbP0NQljGZMuv8fROkoO0TIj3FDfbYJO2In7/yLd/ JBuTmnwYqFW3+0otM36i8dQ37rLnHzzLPmldZf8gDDvXNQQAxuXID+FF+bpP+K1ma7Q9 mjzRAU/3zAIcB9toNcRm8J1mMqw8EoDwGiuzQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tWw8XNTFNS7z7YocDTkWF+pOslq9gVAsSX2uEye4eiLp3dugASIPF9ngA758V1Ec0r 9Wefs59Mv3GCRP95JEr90DottyAykhy/r1ilaPIBXHSzSerjR3HtS4qlPOVrD6kq7bcF Z20vNHiwfG5i1y70JaSzOM843g0069BUfy8m4=
MIME-Version: 1.0
Received: by 10.231.59.1 with SMTP id j1mr4135866ibh.55.1276128197183; Wed, 09 Jun 2010 17:03:17 -0700 (PDT)
Received: by 10.231.192.4 with HTTP; Wed, 9 Jun 2010 17:03:17 -0700 (PDT)
In-Reply-To: <AANLkTimyolfWkyYLCVw50fUkL7R94ifdtN-dGhe_vPHT@mail.gmail.com>
References: <AANLkTimOXzscoFDtf-PO8965xuchEBJvqALiWM3O9fMl@mail.gmail.com> <4C0F3FFF.2050209@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263F7B9FB@WSMSG3153V.srv.dir.telstra.com> <AANLkTim5tJMXK4mcb7SrxK4ZR6FQqRKpZqRmxZ9QOpY9@mail.gmail.com> <AANLkTimyolfWkyYLCVw50fUkL7R94ifdtN-dGhe_vPHT@mail.gmail.com>
Date: Wed, 09 Jun 2010 17:03:17 -0700
Message-ID: <AANLkTinNvHyJFwEF6B3G6PVJJEgCpB9dXCNdRxoUpTb_@mail.gmail.com>
From: David Recordon <recordond@gmail.com>
To: Dirk Balfanz <balfanz@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [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: Thu, 10 Jun 2010 00:03:19 -0000

I think long polling came up at the face to face and we decided to not
fundamentally change how the flow works until we have implementation
experience.

I'm fine with using 503 since it's not really a fundamental change.

--David


On Wed, Jun 9, 2010 at 4:51 PM, Dirk Balfanz <balfanz@google.com> wrote:
> On Wed, Jun 9, 2010 at 10:58 AM, David Recordon <recordond@gmail.com> wrote:
>>
>> Unless I'm misreading the Timeouts spec, it defines a HTTP request
>> header which the client uses to tell the server how long it will wait.
>
> That's how I read them, too. But that might be an alternative way to pick up
> the token in the device flow - issue a "hanging" request that returns when
> the token is rejected/approved. If you do that, then the timeout specs
> become relevant. Either way, it feels to me like this should be handled at
> the HTTP layer.
>
> Dirk.
>
>>
>> That's a different problem from the server telling the client to back
>> off it's request rate.
>>
>> A 503 with a Retry-After header seems reasonable. We should specify
>> this interaction given that 503 headers will be new to many
>> developers.
>>
>> --David
>>
>>
>> On Wed, Jun 9, 2010 at 12:29 AM, Manger, James H
>> <James.H.Manger@team.telstra.com> wrote:
>> > Right on cue a new internet-draft covering the HTTP polling issue has
>> > just
>> > appeared:
>> >
>> >
>> >
>> >   Hypertext Transfer Protocol (HTTP) Timeouts
>> >
>> >   draft-loreto-http-timeout [June 2010]
>> >
>> >
>> >
>> > See also:
>> >
>> >   Best Practices for the Use of Long Polling and Streaming in
>> > Bidirectional
>> > HTTP
>> >
>> >   draft-loreto-http-bidirectional [Feb 2010]
>> >
>> >
>> >
>> > --
>> >
>> > James Manger
>> >
>> >
>> >
>> > Am 08.06.2010 22:23, schrieb Dirk Balfanz:
>> >
>> > 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.
>> >
>> > http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html
>> >
>> > Dirk.
>> >
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> >
>
>

v2.23.0 | Report a Bug | By Email