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

Require servers to allow for clock skew

Issue #603 resolved
Joseph Heenan created an issue

As per the suggestion from Filip here:

https://gitlab.com/openid/conformance-suite/-/issues/1038#note_1424925163

It is proposed that FAPI2 should require servers to allow for some small amount of clock skew, as that is good for general interoperability and the dpop spec allows server to do this but doesn’t require them to. (And it’s preferable that we don’t add conformance tests that require clock skew to be allowed unless there’s a normative requirement in the specification requiring it.)

Comments (15)

  1. Dave Tonge

    We had a long discussion on the call today. Suggestion that we have a new clause something like:

    to accommodate for clock offsets, the server shall accept JWTs with an iat or nbf time in the reasonably near future (on the order of seconds or minutes)

    The idea is to make it general, not DPoP specific, but also not to define a specific value.

    The conformance test could then try sending a DPoP proof a few seconds in the future as a test for this clause

    The above text still needs WG discussion and approval.

    ‌

  3. Nat Sakimura

    Suggestions from the Pacific call. Maybe we can amend it to (on the order of seconds or a minute)?

  4. Mark Verstege

    I agree with Nat. Having an upper ‘acceptable’ bound is important to remove subjective interpretation. Perhaps saying “in the order of seconds but not more than 60 seconds”.

  5. Dave Tonge

    we discussed on the call changing the bracket to say (at least 10 seconds, but not more than 60 seconds)

    the reason being, that we need 10 seconds to test reliably.

    ‌

  6. Dave Tonge

    we discussed again on the call:
    - shall for 10 seconds
    - should for 60 seconds (with note that ecosystems may want to adjust)

  8. Chris Michael

    Agree with the spec change. However,

    a) would be better to not encourage variances by ecosystem

    b) not sure there is any value in adding a conformance test for this unless someone can spell out what interoperability issues we are looking to mitigate

  9. Joseph Heenan reporter

    b) not sure there is any value in adding a conformance test for this unless someone can spell out what interoperability issues we are looking to mitigate

    The interoperability issue is where a percentage of calls fail as the server refuses to accept JWTs where iat is say 100ms in the future. If the server is required to accept tokens like that (which I think it should be) we can test for it.

    ‌

  10. Mark Verstege

    I’m not clear with the shall and should whether that imposes an upper bound. How do you see those constraints being phrased as requirements @Dave Tonge ? Dealing with clock skew makes sense provided there isn’t an open ended interpretation that accommodation for clock offsets isn’t 5 minutes, 10 minutes, 60 minutes.

    Would it make more sense that the “should” for 60 seconds be rephrased as a “should not be more than 60 seconds”? This allows for ecosystem variability if required (though I agree with Chris I can’t think of any immediate reason why different ecosystems would differ).

  16. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
FAPI2: Security Profile
Milestone
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!