Grant Management Errors - Rate Limiting Requests

[Ralph Bragg]

There will be a need to protect the AS from RP’s hammering for Grant Status Updates when Multi Party / Multi Lateral consents are included. CIBA has a back off retry mechanism that potentially could act as a source of inspiration but in the mean time the errors should be extended to include rate limit breaches.

[Lukasz Jaromin]

Do you mean by Multi Party consents, such consents that include e.g. data access platforms as an additional party?

[Dima Postnikov]

@Ralph Bragg do you mean this section?

If the Client is registered to use the Poll mode, then the Client polls the token endpoint at a reasonable interval, which MUST NOT be more frequent than the minimum interval provided by the OpenID Provider via the "interval" parameter (if provided).

For polling requests, the OP may implement long polling, where the OP responds to the token request only when the authentication result has become available or a timeout has occurred. A timeout of 30 seconds is recommended for long polling requests, as specified in Section 5.5 of RFC6202, Best Practices for Long Polling.

Clients should be prepared to wait at least 30 seconds for a response when using polling mode. The OP should not take longer than 30 seconds to respond to a request, even when using long polling.

The polling interval is measured from the instant when a polling request is sent. To implement long polling the OP may respond slower than interval. A Client MUST NOT send two overlapping requests with the same auth_req_id. Rather the client must always wait until receiving the response to the previous request before sending out the next request. If the interval has passed when the response is received, then the client may immediately send out the next request.

An OP in a meltdown type situation may return an HTTP 503 with a Retry-After response header as described in Section 7.1.3 of HTTP/1.1. Clients should respect such headers and only retry the token request after the time indicated in the header.

Here are some illustrations of how a Client should behave based on different OP responses, assuming a default interval of 5s:

Long PollingThe Client makes a token request and the OP returns an authorization_pending error after 30s. In this case, the Client can immediately make the next token request.Standard PollingThe Client makes a token request and the OP returns an authorization_pending error after 2s. In this case, the Client must wait for 3s before making the next request.OP responds slower than 30sThe Client makes a token request and the OP doesn't return any response within 30s. In this case, the Client may cancel the request and make a new request.

[Stuart Low]

@Ralph Bragg Have created https://bitbucket.org/openid/fapi/pull-requests/new?source=stuart-low/introduce-http-backoff&t=1

[Dima Postnikov]

https://bitbucket.org/openid/fapi/pull-requests/275

[Dima Postnikov]

PR is ready to merge