WICG / trust-token-api

Trust Token API
https://wicg.github.io/trust-token-api/
Other
415 stars 82 forks source link

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

Open colinbendell opened 1 year ago

colinbendell commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

colinbendell commented 1 year ago

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
    }
  ]
}