Draft: draft-ietf-privacypass-protocol

Commentary: Most likely , clients and origins will be caching issuer directories . Is it worth offering any guidance to client / origin implementations regarding caching ? Is honoring cache - control response headers sufficient ? And if so , should that be called out explicitly as a reminder to implementers ( who might be building a custom cache or perhaps caching the parsed  content separately from an existing HTTP layer ) ? Is it worth offering any guidance to issuers about how long they should assume directory changes will take to reach ~100 % of clients and issuers ? ( My gut says no to this one -- but I am throwing it out in case others think it is worthwhile . ) 
 Using cache control directives for this key material seems fine , provided it 's done in accordance with your key rotation schedule . 
 The proposed change addresses the primary concern of this issue . Typo ? Should it be " results in " ? 
 Yep , fixed . 
 I believe there is a race condition if an issuer tries to add or remove s in its directory . When adding a token type , a client may see the a key for the new in the directory and use it even though the origin may have a slightly stale directory . When removing a token , a client may see still see the key for the old in a slightly stale directory and use it even the the origin may already have refreshed its directory . One potential way to address this would be to extend or replace key ordering with a designation of which key(s ) are " active . " The client would only pick " active " keys to make requests to an issuer , but origins would verify against all listed keys . A could then be " rotated " in / out of use by having it appear for some time as inactive before activating it or removing it entirely . 
  , unless there 's some sort of additional consistency mechanism in place , clients are not really expected to fetch or inspect the issuer 's configuration . This is only useful information for the origin . This relates to how the information is cached , so I think we can address this and at the same time . 
 There is still some potential for skew even with cache - control . The update includes a new to refetch the config if there is evidence that it 's stale , and that certainly could help in many cases . Presumably an issuer must still support a key for some amount of time after removing it from the directory for at least the cache max - age . ( Is that worth mentioning explicitly ? ) A client that is using consistency may fail to validate a token key if it has a fresher directory than the origin and the tokentype has been removed . One option would be for consistency providers to keep old keys around for some time after they are removed from the directory . Another option would be for the client to try other tokentypes that were offered by the origin . Would it be helpful to mention somewhere ( issuance protocol or maybe the http auth scheme ? ) that clients should try a different ( supported ) token_type if the first attempt fails ? 
 There will always be potential for skew in a distributed system like this . We already note that the issuer can advertise multiple keys ( sorted by order of preference ) to address this particular problem : I do n't think we need to say anything more without just being confusing .
Issuers SHOULD use HTTP caching to permit caching of this resource
RFC5861.  The cache lifetime depends on the Issuer's key rotation
schedule.  Regular rotation of token keys is recommended to minimize
the risk of key compromise.
Consumers of the Issuer directory resource SHOULD follow the usual
HTTP caching RFC9111 semantics when processing this resource.  Long
cache lifetimes may result in use of stale Issuer configuration
information, whereas short lifetimes may result in decreased
performance.  When use of an Issuer configuration results in token
issuance failures, e.g., because the configuration information is too
stale, the directory SHOULD be fetched and revalidated.