token endpoint response when client polls quicker than 'interval' may be unclear

[Joseph Heenan]

7.3. Successful Authentication Request Acknowledgement says:

interval OPTIONAL. The minimum amount of time in seconds that the Client MUST wait between polling requests to the token endpoint.

I think it's unclear what error an AS should return if a client violates the rule - I think it would be valid to return 'slow_down' but I think it's possible to form an argument that 'invalid_request' or another error might also be valid.

It may be in the interests of interoperability to define the behaviour in this case.

I think I would tend towards treating it as a hard error to ensure that clients that accidentally poll more often than they should are discovered and fixed.

[Dave Tonge]

I think we should prob discuss this. But I don't think it needs to stop the implementers draft.

[Brian Campbell]

What is returned in that situation is at the AS's discretion and could be slow_down or authorization_pending. It could also go with a hard error of invalid_grant if it wanted to invalidate the whole transaction. However, I don't believe a particular error should be mandated, especially if it were to require that the AS to keep track of polling frequency for each auth_req_id.

[Brian Campbell]

Discussed on Jan 8th 2019 call http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20190107/001408.html and decided "Joseph to propose text" which might be a new specific error code. cc @josephheenan because I don't seem to be able to actually assign to him

[Joseph Heenan]

I suggest new text in 11. Token Error Response :

If the server wishes to indicate to the client that the client is not respecting "slow_down" or "interval" and the authentication has been aborted, it MAY return HTTP status code 429 Too Many Requests. If a client receives a HTTP status 429 response, it MUST NOT make any further requests for that auth_req_id.

Though it feels appropriate, I'm also not feeling quite 100% confident about using a HTTP error code as I'm wondering if their are situations where an API gateway might return a 429 error for other situations. I am not sure if that matters. Opinions welcome.

[Brian Campbell]

Not particularly liking the idea of tying application specific logic to an HTTP status code.

[Dave Tonge]

Dave to talk to Brian about this - maybe we need a new error code?

[Joseph Heenan]

Discussed on today’s call - invalid_request (potentially with a helpful error_description) is an equally valid response.

The spec should then probably have a clause to make clear that if a polling client receives invalid_request it must never retry.

[Joseph Heenan]

7.3. Successful Authentication Request Acknowledgement says:

interval OPTIONAL. The minimum amount of time in seconds that the Client MUST wait between polling requests to the token endpoint.

I think it's unclear what error an AS should return if a client violates the rule - I think it would be valid to return 'slow_down' but I think it's possible to form an argument that 'invalid_request' or another error might also be valid.

It may be in the interests of interoperability to define the behaviour in this case.

I think I would tend towards treating it as a hard error to ensure that clients that accidentally poll more often than they should are discovered and fixed.

[Dave Tonge]

If a Client continually polls quicker than the interval, the OP may return a “invalid_request” error.

If a Client receive an invalid_request error it must not make any further requests for that auth_req_id.

[Dave Tonge]

https://bitbucket.org/openid/mobile/pull-requests/74/add-guidance-around-clients-who-poll-to/diff

[Brian Campbell]

Merged in i135 (pull request #74) to fix issue #135

Add guidance around clients who poll to quickly

Approved-by: Brian Campbell Approved-by: Bjorn Hjelm → <<cset 581e56f7c9a1>>