Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

should expiry field be removed (or formatted as ISO8601/RFC3339) #246

Open
colinbendell opened this issue May 11, 2023 · 3 comments
Open

Comments

@colinbendell
Copy link

colinbendell commented May 11, 2023

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).

@dvorak42
Copy link
Collaborator

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.

@colinbendell
Copy link
Author

If we follow the PrivacyPass protocol, shouldn't the expiration be determined by the Cache-Control header when requesting the directory?

@colinbendell
Copy link
Author

fwiw, JWKs are intended to be extended this way (See Section4 or RFC 7517)

For example, a JWKS representation of the key commitment would be:

{
  "issuer": "https://example.com",
  "batchsize": 10,
  "keys": [
    {
      "kid": 1, //optional key-id
      "kty": "EC",
      "crv": "P-384",
      "x": "...",
      "y": "...",
      "exp": 168486000, // optional expiration
      "nbf": 1684857014, // optional not-before
    }
  ]
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants