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

From: Dirk Balfanz <[email-masked]>
Date: Tue, 8 Jun 2010 13:23:41 -0700

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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 09 Jun 2010 09:17:19 +0200

using mechanisms provided by the HTTP protocol sound reasonable to me.

I see two questions:

1) Is 503 intended for that purpose? 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says: "The server 
is currently unable to handle the request due to a temporary overloading 
or maintenance of the server"
2) Do HTTP clients supports the Retry-After header?

regards,
Torsten.

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.
>
> 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. 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 9 Jun 2010 17:29:55 +1000

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

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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 09 Jun 2010 09:58:51 +0200

What conclusions would you draw from this internet-draft? Shall we move 
for long polling and "Timeout" headers?

regards,
Torsten.

Am 09.06.2010 09:29, schrieb Manger, James H:
> Hypertext Transfer Protocol (HTTP) Timeouts 
> <http://tools.ietf.org/html/draft-loreto-http-timeout>
>
> Best Practices for the Use of Long Polling and Streaming in 
> Bidirectional HTTP 
> <http://tools.ietf.org/html/draft-loreto-http-bidirectional>
>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 10 Jun 2010 00:06:27 +1000

> What conclusions would you draw from this internet-draft?

> Shall we move for long polling and "Timeout" headers?

I have not been following the polling issue deeply, but I agree with Dirk that OAuth2 should try leave the polling issue to other specs as much as possible.

Suggesting long polling be used, with a (informative) reference to those 2 drafts, would be a decent solution for OAuth2.

--

James Manger

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Wednesday, 9 June 2010 5:59 PM
To: Manger, James H
Cc: Dirk Balfanz; OAuth WG
Subject: Re: [OAUTH-WG] polling in the device flow

What conclusions would you draw from this internet-draft? Shall we move for long polling and "Timeout" headers?

regards,
Torsten.

See also:

--

James Manger

Hi guys,

What do you guys think?

Dirk.

---

From: David Recordon <[email-masked]>
Date: Wed, 9 Jun 2010 10:58:13 -0700

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 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
<[email-masked]> wrote:
>   Best Practices for the Use of Long Polling and Streaming in Bidirectional
> HTTP
>

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 9 Jun 2010 16:51:55 -0700

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

> > Right on cue a new internet-draft covering the HTTP polling issue has
> just
> > appeared:
> >
> >
> >
> Bidirectional

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 9 Jun 2010 17:02:47 -0700

On Wed, Jun 9, 2010 at 12:17 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> is currently unable to handle the request due to a temporary overloading or
> maintenance of the server"

Both good question. It's probably fair to say that the original intention
for 503 did not include telling clients that the resource they're requesting
isn't quite ready yet. On the other hand, the original "overloading"
language does suggest that it's perfectly within the intentions of the
founding fathers to throttle clients if they become too pesky. Which is what
we're trying to do here: As far as OAuth is concerned, the client could just
sit there and loop and keep asking the server every 2 milliseconds. We
thought that wasn't a good idea because (among other things) that might
*overload* the server, not because OAuth wouldn't work if the clients did
that. So a 503 seems like a reasonable response there, especially since it
has that Retry-After header, which indicates that the original intent of a
503 at least included the case where the inability-to-serve was due to the
fact that he clients were coming in too fast.

As for library support for this - I'm not sure. I briefly looked at the
Apache commons client and couldn't find a, say, simple flag that would
enable some retry mechanism based on 503s and retry-after headers. Maybe I
didn't look hard enough. But it should be fairly easy to add supprot for
this to any HTTP client library, right?

Dirk.

> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: David Recordon <[email-masked]>
Date: Wed, 9 Jun 2010 17:03:17 -0700

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 <[email-masked]> wrote:
>> > the