- changed milestone to CIBA Post-Implementer's Draft
token endpoint response when client polls quicker than 'interval' may be unclear
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.
Comments (14)
-
-
What is returned in that situation is at the AS's discretion and could be
slow_down
orauthorization_pending
. It could also go with a hard error ofinvalid_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 eachauth_req_id
. -
- changed milestone to CIBA Implementer's Draft
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
-
-
assigned issue to
-
assigned issue to
-
reporter 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.
-
Not particularly liking the idea of tying application specific logic to an HTTP status code.
-
- changed milestone to CIBA Post-Implementer's Draft
-
Dave to talk to Brian about this - maybe we need a new error code?
-
reporter 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.
-
reporter 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.
-
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.
-
-
-
assigned issue to
-
assigned issue to
-
- changed status to resolved
Merged in i135 (pull request
#74) to fix issue#135Add guidance around clients who poll to quickly
Approved-by: Brian Campbell Approved-by: Bjorn Hjelm → <<cset 581e56f7c9a1>>
- Log in to comment
I think we should prob discuss this. But I don't think it needs to stop the implementers draft.