You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The key commitment dictionary should remove the expiry field to follow JWKS and PAT.
Currently expiry is epoch in microseconds and escaped in string form. This is not a common convention for formatting date/times and the precision of microseconds is not necessarily valuable. From a DevEx perspective, the formatting choice is odd.
JWKS do not include an expiration field. Instead, the expectation is that the current list of keys is the authoritative set of keys. It is the responsibility of the origin to prune expired keys and clients to only use the currently published keys.
Private-Access-Token follows this same pattern with .well-known/token-issuer-directory values.
That said, there are colloquial, non-standard, extensions to JWK like exp and nbf that are commonly used to express expires and not-before. The convention here appears to be millisecond precision.
If key commitment should include the expiry, we should conform to either ISO8601 or use the more commonly used precision of epoch time (ms).
The text was updated successfully, but these errors were encountered:
Adding vStandard for migrating to a more standard expiration format in a future version of PST.
For PST, we do need the expiry field in order to allow for issuers to pre-declare their future keys while still allowing the client to enforce restrictions on how many keys are acceptable for the issuer to use at a particular time. This pre-declaration allows for rotation of keys between epochs without having mismatches at the time that either the client or issuer disagree on the current keys.
The key commitment dictionary should remove the
expiry
field to follow JWKS and PAT.Currently
expiry
is epoch in microseconds and escaped in string form. This is not a common convention for formatting date/times and the precision of microseconds is not necessarily valuable. From a DevEx perspective, the formatting choice is odd.JWKS do not include an expiration field. Instead, the expectation is that the current list of keys is the authoritative set of keys. It is the responsibility of the origin to prune expired keys and clients to only use the currently published keys.
Private-Access-Token follows this same pattern with
.well-known/token-issuer-directory
values.That said, there are colloquial, non-standard, extensions to JWK like
exp
andnbf
that are commonly used to express expires and not-before. The convention here appears to be millisecond precision.If key commitment should include the
expiry
, we should conform to either ISO8601 or use the more commonly used precision of epoch time (ms).The text was updated successfully, but these errors were encountered: