I prefer to keep this as seconds. In most cases, this will be good enough and
will not require any clock sync. Servers should not issue tokens with durations
that are too short and likely to expire during processing. If clock sync is
requires, the client can use the server's Date response header
-WG] expires_in RE: OAuth meeting notes on -05 (with updates)
Hey Axel,
We had previously decided (I can try to dig up the link) that relative
times will be easier for client developers. It means no timezone
handling but being able to store the expiration as time() +
expires_in. No, it's not
Hey Axel,
We had previously decided (I can try to dig up the link) that relative
times will be easier for client developers. It means no timezone
handling but being able to store the expiration as time() +
expires_in. No, it's not going to be perfect to the second but the AS
could always send an ex
During the meeting we had a (short) discussion about the expires_in parameter.
I propose to change it to a notonorafter parameter with a GMT/UTC date as value.
If the time slew between server is bigger or nearly equal to the life time of
the expires_in value than the token receiver has no chance
