A10. Revocation and purge
Status: normative. Document version 1.0-draft-1.
Ending a grant stops future reads immediately. It does not remotely erase a recipient's existing copy. A provider issues a signed purge instruction for every ended grant with persistence rights; notices for transient grants may also be sent. The person can see delivery and acknowledgement state.
The payload follows purge-instruction.json, signed as compact JWT with ES256, protected typ:autonym-purge+jwt and, as kid, the A5.4 key ID of a key in the provider's trusted key set. Its signed time is iat, so a recipient rejects a token whose iat is at or after that key's exp (A5.4). It binds provider issuer, pairwise subject, recipient audience, instruction ID, issue/expiry timestamps, grant ID and deadline. The reason is identical for revocation and expiry:
{ "reason": "grant_ended" }scope:all means copies obtained under that grant, including derived recipient copies. No explanation of why it ended is disclosed. Default acknowledgement deadline is seven days after issue; JWT validity is 30 days. Fetching an outstanding expired notice issues a fresh signed delivery with the same instruction ID/deadline, not a new erasure obligation.
Delivery uses registered HTTPS autonym_purge_uri through the SSRF-safe client. Retry after 1 minute, 5 minutes, 30 minutes, 2 hours, 12 hours and then daily until acknowledgement or 30 days. Each attempt revalidates destination ownership and DNS/address safety. A recipient may poll outstanding notices using authenticated client credentials bound to its registration; this lifecycle channel does not require a still-active read grant and confers no record-read authority. Do not drop a notice merely because the triggering grant expired.
purge-ack.json binds instruction ID, time and purged, not_held or legal_hold, plus a bounded explanation. Where the recipient has a registered key, it signs the acknowledgement by the A5.4 method: a detached JWS over the UTF-8 RFC 8785 canonical JSON of the complete acknowledgement without proof, with protected alg:ES256, typ:autonym-purge-ack+jws and the registered key's A5.4 key ID as kid, carried in proof. Its signed time is at. The provider verifies it as A5.4 describes, against that recipient's registered keys only. Without a registered key, proof is null and the provider records the authenticated but unsigned assurance explicitly. Validate client/instruction binding. An acknowledgement is the recipient's attestation, signed where it holds a registered key, of the outcome it reports: purged, not_held or legal_hold. It proves only that the recipient made that attestation; even purged does not prove that every copy has gone. A provider MUST NOT present an acknowledgement, to the person or anywhere else, as proof of erasure or as evidence that no copy remains (PURGE-01). legal_hold records an exception claim, not completed purge.
Missing acknowledgement past the deadline remains visible to the person. The default status-retention period is 12 months, subject to a shorter period required by applicable law or necessity, or the owner's shorter lawful retention choice. Any longer retention needs the specific lawful justification and safeguards in A16.5. Do not expose it to other recipients. No registry standing or certification is inferred in v1.
Checks: PURGE-01, ADS-02, SIGN-01, KEY-01, CORE-01.
References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.