Expose clock skew errors to reliant parties

[G1itcher]

Currently, clock skew errors (future token and already expired token) aren't detectable without interrogating the error messages directly, which isn't great practice.

My current clients have many offices and some of their users manually change their clocks. We need to be able to report issues like that back properly to the user.

[swiftone]

This is an interesting feature request. We don't currently have a method to calculate the client clock skew, but it is on our backlog.

You may want to contact [email protected] with your use case if you have an urgent need. We'd recommend as a work-around checking the client clock against your servers to detect skewed clients, as out-of-sync clients are going to be a problem in any distributed encryption system.

[jchabotamica]

@swiftone is this enhancement specifically for clock skew errors? I noticed other error messages that come back with generic error codes but the error message can be different. For example, password reset errors where it fails a password check against "commonly used passwords". We have to interrogate the error message directly instead of a specific error code in order to relay a user friendly message to the customer.

[kaburnside]

Is there currently any updates on this? We have clients who set their clocks manually that would be more than an hour time difference than the servers current time. Is there a possible workaround for the time being?