Re: [OAUTH-WG] polling in the device flow
"Manger, James H" <James.H.Manger@team.telstra.com> Wed, 09 June 2010 07:30 UTC
Return-Path: <James.H.Manger@team.telstra.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 7BEAC3A691A for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 00:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.311
X-Spam-Level: **
X-Spam-Status: No, score=2.311 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, HTML_MESSAGE=0.001, RDNS_NONE=0.1, RELAY_IS_203=0.994]
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 Qx4IxBQUsymI for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 00:30:01 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (unknown [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 6DEFC3A6907 for <oauth@ietf.org>; Wed, 9 Jun 2010 00:30:00 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,389,1272808800"; d="scan'208,217";a="4044741"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 09 Jun 2010 17:29:56 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6007"; a="3007223"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcdvi.tcif.telstra.com.au with ESMTP; 09 Jun 2010 17:29:57 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Wed, 9 Jun 2010 17:29:56 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>, Dirk Balfanz <balfanz@google.com>
Date: Wed, 09 Jun 2010 17:29:55 +1000
Thread-Topic: [OAUTH-WG] polling in the device flow
Thread-Index: AcsHo9laAfx079cPSM+mCFS2fVjH1QAAHa1A
Message-ID: <255B9BB34FB7D647A506DC292726F6E11263F7B9FB@WSMSG3153V.srv.dir.telstra.com>
References: <AANLkTimOXzscoFDtf-PO8965xuchEBJvqALiWM3O9fMl@mail.gmail.com> <4C0F3FFF.2050209@lodderstedt.net>
In-Reply-To: <4C0F3FFF.2050209@lodderstedt.net>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11263F7B9FBWSMSG3153Vsrv_"
MIME-Version: 1.0
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: Wed, 09 Jun 2010 07:30:27 -0000
Right on cue a new internet-draft covering the HTTP polling issue has just appeared: Hypertext Transfer Protocol (HTTP) Timeouts<http://tools.ietf.org/html/draft-loreto-http-timeout> draft-loreto-http-timeout [June 2010] See also: Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP<http://tools.ietf.org/html/draft-loreto-http-bidirectional> 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-WG] polling in the device flow Dirk Balfanz
- Re: [OAUTH-WG] polling in the device flow Torsten Lodderstedt
- Re: [OAUTH-WG] polling in the device flow Manger, James H
- Re: [OAUTH-WG] polling in the device flow Torsten Lodderstedt
- Re: [OAUTH-WG] polling in the device flow Manger, James H
- Re: [OAUTH-WG] polling in the device flow David Recordon
- Re: [OAUTH-WG] polling in the device flow Dirk Balfanz
- Re: [OAUTH-WG] polling in the device flow Dirk Balfanz
- Re: [OAUTH-WG] polling in the device flow David Recordon