1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. mobile
  4. Issues

"interval" and "slow_down" may not give the OP enough control

Issue #136 resolved
Joseph Heenan created an issue

The current draft says:

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

Something more along the lines of "must leave at least this duration since it received the last successful response" may be better than "more frequent" and "minimum interval", and similarly for "slow_down".

My thinking is that if the OP is in a meltdown type situation where it is taking 20+ seconds to reply to a request, the current draft seems to allow:

If we start at T=0, a client polling every 5 seconds and an AS taking 20 seconds to reply - I think the current spec allows the client to poll again at T=5 even though it's not have the previous response. Even if client waited to poll at T=25, the AS tells the client to slow_down it could legitimately poll again at T=35. (I'm not sure that's a clear explanation, please ask if it's not clear what I'm getting at.)

Comments (16)

  2. Brian Campbell

    A server in a meltdown type situation could always return an HTTP 503 with a Retry-After response header

  3. Dave Tonge

    Dave to speak to Brian - maybe we can propose text. No one on the call objected to the use of 503, but we felt that it would be good to provide guidance.

  5. Petteri Stenius

    Some thoughts on definiton of interval

    We need to clarify how interval is to be implemented by clients, in particular when long polling scenarios are considered.

    Basically I think there are two possible ways a client could implement interval:

    1. Interval is time to wait after previous request was sent, before sending next request
    2. Interval is time to wait after receiving response to previous request, before sending next request

    In addition for option 1: A client must not send two overlapping polling requests with same auth_req_id. Instead client must always wait until receiving response to previous request before sending out next polling request. If interval has passed, when response is received, then client can immediately send out next polling request.

    Neither CIBA nor Device Flow are very clear how clients should be implemented.

    Personally I think option 1 is safer and gives OP full control to work in either short or long polling mode.

    My reasoning is there is risk with option 2 and long polling. To benefit from long polling, when clients implement option 2, interval needs to be short for example 0. This could in some scenarios cause clients behave badly.

    Best practices for long polling (https://tools.ietf.org/html/rfc6202)) recommend a timeout of 30 seconds.

  8. Brian Campbell

    Suggest these minor changes to the second part of the text from @Petteri but otherwise good by me.

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

  10. Dave Tonge

    We need to add a note explaining the different scenarios.

    The scenarios as I understand are:

    Interval = 30s

    1. OP returns authorization_pending after 30s, RP immediately makes next request
    2. OP returns authorization_pending after 2s, RP must wait 28s before making next request
    3. OP doesn’t return response after 30s, RP may cancel the request and immediately make a new request, but should typically wait longer…

    ‌

    ‌

  11. Dave Tonge

    Clients MUST wait at least 30 seconds for a response when using polling mode. Servers should not take longer than 30 seconds to respond to a request, even when doing long polling.

    ‌

  12. Dave Tonge

    A server in a meltdown type situation could always return an HTTP 503 with a Retry-After response header

    ‌

  17. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
CIBA
Milestone
CIBA Post-Implementer's Draft
Votes
0
Watchers
0
Jira: the preferred issue tracker for Bitbucket. Join the team!