Code change:
claims.  This limitation needs to be taken into account by Issuers when creating the structure of the SD-JWT. <ins> 8.9. This specification does not define how signature verification keys of Issuers are distributed to Verifiers.  However, it is RECOMMENDED that Issuers publish their keys in a way that allows for efficient and secure key rotation and revocation, for example, by publishing keys at a predefined location using the JSON Web Key Set (JWKS) format RFC7517.  Verifiers need to ensure that they are not using expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method. </ins> 9. 9.1. <ins> Wherever End-User data is stored, it represents a potential target for an attacker.  This target can be of particularly high value when the data is signed by a trusted authority like an official national identity service.  For example, in OpenID Connect, signed ID Tokens can be stored by Relying Parties.  In the case of SD-JWT, Holders have to store signed SD-JWTs and associated Disclosures, and Issuers and Verifiers may decide to do so as well. Not surprisingly, a leak of such data risks revealing private data of End-Users to third parties.  Signed End-User data, the authenticity of which can be easily verified by third parties, further exacerbates the risk.  As discussed in holder_binding_security, leaked SD-JWTs may also allow attackers to impersonate Holders unless Holder Binding is enforced and the attacker does not have access to the Holder's cryptographic keys.  Altogether, leaked SD-JWT credentials may have a high monetary value on black markets. Due to these risks, systems implementing SD-JWT SHOULD be designed to minimize the amount of data that is stored.  All involved parties SHOULD store SD-JWTs only for as long as needed, including in log files. Issuers SHOULD NOT store SD-JWTs after issuance. Holders SHOULD store SD-JWTs and associated Disclosures only in encrypted form, and, wherever possible, use hardware-backed encryption in particular for the private Holder Binding key. Decentralized storage of data, e.g., on End-User devices, SHOULD be preferred for End-User credentials over centralized storage.  Expired SD-JWTs SHOULD be deleted as soon as possible. Verifiers SHOULD NOT store SD-JWTs after verification.  It may be sufficient to store the result of the verification and any End-User data that is needed for the application. If reliable and secure key rotation and revocation is ensured according to issuer_signature_key_distribution, Issuers may MAY opt to publish expired or revoked private signing keys (after a grace period that ensures that the keys are not cached any longer at any Verifier).  This reduces the value of any leaked credentials as the signatures on them can no longer be trusted to originate from the Issuer. 9.2. </ins> If the SD-JWT and associated Disclosures are transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the End-User's personal data or correlate

Related discussion:
text: As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity