How long should Transmitters hold onto a JWK used to sign a SET?
Closed this issue · 2 comments
Section 11.1.5 says that the exp claim MUST NOT be used in SSF SETs. If a SET has no expiration time, does that imply that the Transmitter MUST provide the JWK used to sign/encrypt that SET forever? If not, are there expectations for how long a Transmitter SHOULD make a particular JWK available?
Good question. There are a couple of "expirations" that express different things in the IETF specs.
- JWT - exp is used to state when the thing being expressed (e.g. an authorization) expires. In the case of a SET, the nature is historical: "an event has occurred". Therefore since an event is historical it cannot expire. Its just a statement of fact. This is why "exp" is not used in SETs
When transferring SETs, the issue of retention comes up. How long should a set be kept for?
The short answer is that the SET Transfer specs (RFC8935, RFC8936) specify that once an event is "acknowledged" the publisher may forget (e.g. delete) the event. The ack process is intended to ensure a client has received an event and has stored it in a way that meets its own recovery and lookup requirements. A SET that is not acknowledged may then be re-transferred on the next exchange cycle.
The long answer is that the SECEVENT group was clear that the publisher should not have any constraints placed on the publisher for retaining events for itself or its receivers in terms of how long. Publisher with 100s or even 100ks of receivers would be quickly overwhelmed storing copies of events for different audiences. Long term storage of SETs would unreasonably inter-twine independent organizations forcing each organization to tightly integrate with each others recovery systems. By focusing on on "was the transfer complete" using an "ack" signal, meant that each receiver can implement recovery according to its own needs. The value of the event is in the hands of the receiver and not the publisher.
The design of SET transfer specs was shifted to make "recovery" the responsibility of the client receiver. The publisher would only be obliged to retain events to cover scenarios when SET transfer (Push or Poll) were offline due to communication disruption. This would limit publisher responsibility to retain events to hours or days (not months or years). In the SET transfer protocol, the "ACK" function tells the publisher that the client has successfully stored the event and that it is no longer needed. Once "acked" the event can be removed on the publisher side. Long-term recovery must always be handled by the receiver. Since the events are signed, there is no informational value in recovering an event from a publisher directly vs. recovering locally.
Thank you. This makes sense. If I understand correctly, there is no requirement on how long a Transmitter needs to maintain a JWK.