handle client clock skew in fxa issued assertions

[lloyd]

Is there a mechanism to handle deviant client clocks in FxA?

in persona we deliver server time to the client in an inital API request. That request also contains many other goodies that can be batched up front and facilitate various future interactions (CSRF, and more).

We've also experience issues (especially on FxOS) when we infrequently calculate clock delta (@jedp has deets).

This issue can be closed when there is a reliable way to ensure that a FxA issued assertion will be accepted by a verifier with an NTP sync'd clock within 10s of reality.

[rfk]

The persona.org context blob, for reference: https://github.com/mozilla/persona/blob/dev/lib/wsapi/session_context.js#L64

[rfk]

I'm a tentative +1 on doing a similar thing in FxA, perhaps subsuming the functionality of the /v1/get_random_bytes endpoint. Is there other data we could profitably include this this blob?

An alternative we've discussed is to send a "Timestamp" header in all responses. Advantage being that you don't need a separate round-trip to fetch this information.

[lloyd]

Yeah, that makes sense. The timestamp in every response is an interesting idea that would let you solve the problem of long running sessions being vulnerable to skew.

[rfk]

Let's do the Timestamp header for now, we should consider the broader idea of a "context blob" as part of the longer-term API.

[SamPenrose]

FxA/FxOS bug: https://bugzilla.mozilla.org/show_bug.cgi?id=938461

[rfk]

Fixed in #362