RFC 0xDEAD: Mortal Certificate Revocation via the AT Protocol

1. Abstract #

This specification defines a succession protocol for AT Protocol identities. When the holder of a did:plc identity dies, a pre-declared successor assumes control of the identity through DID PLC key rotation, triggered by threshold death attestations from designated verifiers. The protocol uses an inverted liveness model: instead of requiring the owner to periodically prove they're alive, multiple independent entities — services, professionals, and designated contacts — passively attest to the owner's liveness through privacy-preserving blinded heartbeats. When those heartbeats go silent, the protocol escalates.

The core insight: AT Protocol already solved account portability — moving your identity to a new provider. Succession is the same operation with a different destination. Instead of moving your identity to a new server, you transfer it to a new person.

No court orders required to execute. No waiting for probate. No "please fax a death certificate to our legal department." Succession is a cryptographic operation that completes in 72 hours — legal challenges can follow, but the transfer doesn't wait for them.

2. The Problem #

3,072,666 Americans died in 2024. Most of them had approximately 168 online accounts each and no machine-readable plan for any of them.

When someone dies today:

• Their domains expire and get squatted by domainers
• Their private repos die with them
• Their AWS accounts run up bills behind MFA locks
• Their self-custodied crypto becomes mathematically unrecoverable
• Their AT Protocol identity — posts, connections, reputation — enters limbo

The SSA Death Master File, America's primary death verification system, now captures only 16% of actual deaths. In April 2025, it erroneously classified 6,000+ living Americans as dead. There is no public, machine-readable, real-time death verification API anywhere in the world.

Zero domain registrars offer a beneficiary field. Zero. Across the entire ICANN ecosystem.

AT Protocol solved one version of this problem: if your hosting provider disappears, you can migrate your identity to a new PDS. But if you disappear — if the human behind the DID experiences a permanent cessation of operation — the protocol has no answer. Your did:plc persists. Your data persists. But nobody can access it, update it, or transfer it.

This specification fills that gap.

3. Prior Art & Inspiration #

The OCSP Analogy #

OCSP (Online Certificate Status Protocol) works like this: a certificate holder periodically fetches a signed proof — "this certificate is still valid" — and staples it to the TLS handshake. If the staple goes stale, clients get suspicious. If the CA issues a revocation, the certificate is done.

The 0xDEAD protocol is this model applied to human identity, with one inversion: instead of the certificate holder self-stapling, multiple independent parties attest to the holder's liveness. This is closer to how OCSP responders actually work — they're third parties affirming validity, not the certificate holder self-certifying.

The certificate lifecycle — issuance, validation, revocation — is defined in RFC 5280, the foundational spec for X.509 PKI. Let's Encrypt moved from OCSP to CRLs in August 2025 (Mozilla compresses these into CRLite for browser-side checking). The mechanism changed; the model of periodic liveness attestation with revocation didn't.

AT Protocol's Account Portability #

AT Protocol separates identity (did:plc), data (PDS repository), and hosting (PDS provider) into three independently mutable components. Only the DID is permanent. This architecture already enables:

• Key rotation — changing who can sign repo commits
• PDS migration — moving your data to a new host
• Handle changes — pointing your identity at a new domain

Existing Platform Tools #

Google's Inactive Account Manager, Apple Legacy Contact, Facebook Legacy Contact, and GitHub Account Successors all exist. They're siloed, all different, and limited. No domain registrar offers anything. AT Protocol has no succession mechanism at all.

4. Architecture #

Three Layers #

Layer 1 — Declarations (Public). A space.0xdead.succession.declaration record in the owner's PDS repository. Discoverable, auditable, self-authenticating via repo commit signature. "I designate did:plc:bob as my successor."

Layer 2 — Heartbeats & Attestations (Private). Multiple independent entities attest to the owner's liveness through blinded heartbeats submitted to a Succession Service. Death attestations from designated verifiers follow the same private channel. The service publishes HMAC-SHA256(nonce, CBOR({subject_did, attester_category, timestamp})) proofs — the public ledger shows that a heartbeat occurred, not whose.

Layer 3 — Signaling (Mortality Labeler). An AT Protocol labeler service publishes account-level mortality status labels: liveness-current, liveness-declining, liveness-overdue, succession-pending, deceased, estate-managed. Other services subscribe to these labels to learn about an account's mortality status.

Core Mechanism: Succession = DID PLC Key Rotation #

did:plc has a rotationKeys array ordered by descending authority. A higher-priority key can override a lower-priority key's operations within 72 hours. This is the succession primitive.

rotationKeys: [
  key[0]: Owner's recovery key       ← highest authority, the "I'm alive" veto
  key[1]: Succession service key     ← can initiate rotation, owner can override
  key[2]: PDS operational key        ← day-to-day operations
]

The 72-hour window is the safety valve, not the death detection mechanism. Death detection happens at the application layer — heartbeat monitoring plus threshold death attestations. The 72-hour window is the last chance for a living person to contest. "I'm not dead yet" as a protocol state.

Two important nuances: The 72-hour clock starts from the operation's submission timestamp to the PLC directory, not from when the owner becomes aware. And a rotation key can modify the rotationKeys array itself — the succession service at position 1 could remove the owner's key at position 0 in the same operation. The 72-hour override window is the safeguard, but after it expires, the succession is cryptographically irreversible. This is by design: the dead don't contest. Note also that the 72-hour window is PLC server policy, not a cryptographic constraint — see Section 8.6 on PLC Directory Trust.

5. Lexicon Definitions #

space.0xdead.succession.declaration #

Stored in the owner's PDS repo. Public. Convention: one per successor. PDS cannot enforce uniqueness constraints on custom lexicons — the Succession Service validates this at the application layer.

{
  "lexicon": 1,
  "id": "space.0xdead.succession.declaration",

  "defs": {
    "main": {
      "type": "record",
      "key": "tid", // ATProto record key — one TID per record

      "record": {
        "type": "object",
        "required": [
          "successor", "deathThreshold", "deathVerifiers",
          "livenessThreshold", "heartbeatSources",
          "heartbeatWindow", "createdAt"
        ],

        "properties": {

          // --- Who inherits ---
          "successor": {
            "type": "string",
            "format": "did", // did:plc or did:web
            "description": "DID of the designated successor"
          },

          // --- Death verification thresholds ---
          "deathThreshold": {
            "type": "integer",
            "minimum": 1,
            "maximum": 5, // how many verifiers must attest death
            "description": "Death attestations required to trigger succession"
          },
          "deathVerifiers": {
            "type": "array",
            "items": { "ref": "#verifier" }, // ref, not $ref — ATProto Lexicon syntax
            "minLength": 1, // minLength, not minItems — Lexicon convention
            "maxLength": 5
          },

          // --- Liveness monitoring ---
          "livenessThreshold": { // minimum active sources required within window
            "type": "integer",
            "minimum": 1,
            "maximum": 10,
            "description": "Minimum heartbeat sources within window"
          },
          "heartbeatSources": { // total registered sources (services, contacts, etc.)
            "type": "integer",
            "minimum": 1,
            "maximum": 20,
            "description": "Total registered heartbeat sources"
          },
          "heartbeatWindow": {
            "type": "string", // duration string, e.g. "30d", "90d"
            "description": "Liveness window (e.g., 30d, 90d)"
          },

          "createdAt": {
            "type": "string",
            "format": "datetime" // RFC 3339 timestamp
          }
        }
      }
    },

    // --- Verifier definition (referenced by deathVerifiers above) ---
    "verifier": {
      "type": "object",
      "required": ["did", "role"],
      "properties": {
        "did": {
          "type": "string",
          "format": "did" // DID of the designated verifier
        },
        "role": {
          "type": "string",
          "knownValues": [ // open enum — not a closed set
            "attorney",
            "notary",
            "family",
            "executor",
            "medical"
          ]
        }
      }
    }
  }
}

space.0xdead.succession.attestation #

Stored in the Succession Service's repo. Blinded. Privacy-preserving.

{
  "lexicon": 1,
  "id": "space.0xdead.succession.attestation",

  "defs": {
    "main": {
      "type": "record",
      "key": "tid", // ATProto record key

      "record": {
        "type": "object",
        "required": ["attestationType", "proof", "timestamp"],

        "properties": {
          "attestationType": {
            "type": "string",
            "knownValues": [ // open enum — extensible
              "heartbeat", // periodic liveness signal
              "death" // mortality attestation from a verifier
            ]
          },

          "proof": {
            "type": "string",
            "description": "HMAC-SHA256(nonce, CBOR({subject_did, attester_category, timestamp}))"
            // Blinded — reveals nothing about subject or attester on the public ledger.
            // The nonce is shared at registration; CBOR prevents delimiter ambiguity.
          },

          "timestamp": {
            "type": "string",
            "format": "datetime" // RFC 3339 — when the attestation was recorded
          }
        }
      }
    }
  }
}

Two lexicons. That's the entire data model. The declaration is public in the owner's repo. The attestation is blinded in the service's repo. ATProto's relay network propagates both without requiring any relay modifications — relays are lexicon-agnostic by design.

6. Protocol Flow #

Step 1: DECLARE — Create your succession record #

The owner creates a space.0xdead.succession.declaration in their PDS.

• Names successor (DID), death verifiers (DIDs + roles), thresholds
• Specifies heartbeat parameters: how many sources, what window, what liveness threshold
• Record is public, discoverable, signed by repo commit
• The successor is notified and must acknowledge through the Succession Service

Step 2: REGISTER — Add the succession key #

The Succession Service's rotation key is added to the owner's DID PLC document.

• Owner signs a plc_operation with the full rotationKeys array reordered to place the service's key at position 1
• Owner's recovery key stays at position 0 (highest authority — the dead man's veto)
• PDS operational key drops to position 2
• Heartbeat sources are registered with the Succession Service: OAuth for service logins, app enrollment for human attesters

This is the only step that requires a DID PLC operation. Everything else is records and API calls.

Step 3: LIVE — The Heartbeat Protocol #

Heartbeats are the early warning system, not the execution trigger. They detect potential death and escalate to human verification. The actual succession (Step 4 and Step 5) is triggered by death attestations from designated verifiers — real people submitting real evidence. Heartbeats buy time and reduce false positives; they don't replace death certificates.

That said, this is where the protocol diverges from every dead man's switch that came before it.

Instead of asking the owner to periodically click "I'm still alive" — a chore that creates a single point of failure and an annoying UX — multiple independent entities passively attest to the owner's liveness through their normal interactions.

Heartbeat sources:

Note on service login heartbeats: These are the most powerful source but face the highest adoption barrier. No major platform currently exposes authentication events to third parties via webhooks or OAuth callbacks. Near-term implementations will likely rely more heavily on professional contacts, designated contacts, and automated device signals. Service login integration becomes viable as the protocol gains adoption and platforms choose to integrate.

Each heartbeat is submitted privately to the Succession Service via any channel — app, web form, email link, WebAuthn prompt. The service records a blinded proof in its ATProto repo:

HMAC-SHA256(nonce, CBOR({subject_did, attester_category, timestamp}))

The nonce MUST be a minimum 128-bit cryptographically random value, generated by the Succession Service and shared with the attester at registration. Using HMAC with structured CBOR encoding (rather than raw concatenation) prevents delimiter-ambiguity attacks and provides a well-defined input domain. The service retains the unblinded data — the blinding protects against third parties reading the public ledger, not against the service itself.

The public ledger shows: "A heartbeat was recorded at time T." Not by whom. Not for whom. Just: a pulse.

Heartbeat states with progressive disclosure:

As heartbeat confidence drops, the protocol progressively reveals more information to the successor. This turns the blinded ledger into a cryptographic escrow with graduated release — privacy while alive, transparency when it matters.

Progressive disclosure is implemented through server-side access control at the Succession Service. The service holds the unblinded attestation data and gates what the successor can query based on the current heartbeat state. This is not a cryptographic guarantee — it depends on trusting the service to enforce access tiers honestly. A future version could use layered encryption with time-locked key release, but the v1 model is access control with a public audit trail of blinded proofs as the accountability mechanism.

This progressive disclosure enables human judgment. "Your attorney hasn't attested in 60 days — maybe call them?" is better than "click this button or your account gets transferred."

Step 4: ATTEST — Death verification #

This is the step that actually matters. Heartbeats detect that something might be wrong. Death attestations confirm it. No succession executes without real evidence from real people.

Death verifiers can submit attestations at any time — not just after heartbeat escalation. When the death attestation threshold is met, EXECUTE proceeds regardless of heartbeat status. This is the critical design decision: heartbeats are advisory, attestations are authoritative. Even if someone fakes heartbeats for a dead person (the Weekend at Bernie's attack), verifier attestations override.

How a death attestation works:

1. A designated verifier (attorney, family member, executor) learns the owner has died
2. The verifier authenticates with the Succession Service using their pre-registered DID
3. The verifier submits a structured attestation containing:
4. Their role (attorney, notary, family, executor, medical)
5. Evidence type (death certificate, personal knowledge, government registry)
6. Jurisdiction (US state, country — relevant for RUFADAA and international law)
7. Supporting reference (e.g., death certificate number, obituary URL, registry record ID)
8. Confidence score (see table below)
9. The Succession Service validates the verifier's identity against the owner's declaration
10. The attestation is recorded as a blinded proof in the service's ATProto repo
11. When the death attestation threshold is met (e.g., 2 of 3 designated verifiers), proceed to EXECUTE

The typical path: An estate attorney who is a designated verifier obtains the death certificate through normal probate proceedings. They authenticate with the Succession Service and submit the attestation with the certificate reference. A family member who is also a designated verifier independently submits their attestation. Two of three verifiers have attested → threshold met → EXECUTE.

The fast path: If a verifier has direct access to a government death registry API (where available — Nordic countries, some US states via EDRS), the attestation can reference a machine-verifiable record. The Succession Service can cross-check automatically. This is rare today but becomes more viable as vital records digitize.

The slow path: Heartbeats go silent. The Succession Service notifies designated verifiers: "Heartbeats for did:plc:owner have been below threshold for 90 days. If you have information about the owner's status, please submit an attestation." Verifiers investigate and respond.

Confidence scoring — suggested values for initial implementations. Operators SHOULD calibrate these based on empirical data as the protocol matures:

Implementations SHOULD require at least one attestation with confidence ≥ 0.85 before executing succession. A threshold of three social media posts should not trigger the transfer of someone's digital identity.

Step 5: EXECUTE — DID key rotation #

The Succession Service uses its rotation key (position 1) to update the owner's DID PLC document:

1. Sign a plc_operation adding the successor's key as the new #atproto verification method
2. Update PDS endpoint if the successor uses a different PDS
3. Update the alsoKnownAs handle if needed
4. The Mortality Labeler publishes deceased on the DID
5. The owner's recovery key (position 0) can override within 72 hours

If no override within 72 hours, the succession is permanent. The DID — and everything attached to it — now belongs to the successor.

What the successor receives:

• Control of the DID (can sign new repo commits)
• Access to the PDS repository (full account data)
• The handle (can keep or change it)
• Full account history (the repo commit chain is append-only — every change is permanently recorded)
• Responsibility for whatever the previous owner posted (choose your successors wisely)

7. The Mortality Labeler #

A dedicated AT Protocol labeler service that publishes mortality status labels on account DIDs.

Labels:

Labels are signed with the labeler's #atproto_label key and include exp (expiration) timestamps. A liveness-current label expires after the heartbeat window, requiring renewal. Natural cadence — no polling needed.

AT Protocol applications can subscribe natively via com.atproto.label.subscribeLabels. Non-ATProto services (domain registrars, package registries) would consume signals via an intermediary API or implement a lightweight ATProto label subscription client — a nontrivial but straightforward integration.

8. Security Considerations #

8.1 Premature Execution (Owner Still Alive) #

The protocol has three independent safeguards against false death:

1. Multiple heartbeat sources. All sources must go silent before escalation begins. One person forgetting to check in is noise. Your lawyer, your bank login, your family, AND your GitHub all going silent simultaneously — that's signal.
2. Death attestation threshold. Multiple independent verifiers must attest. A single false report doesn't trigger succession.
3. 72-hour safety valve. The owner's recovery key (position 0) can override any DID rotation within 72 hours. If you're alive, you can stop it.

The primary false-positive risk is not malice but lifestyle change: someone retires, switches providers, moves countries, or goes off-grid for six months. Multiple heartbeat sources can legitimately go silent without the owner being dead. The progressive disclosure model (Section 6, Step 3) and 72-hour override are the safety nets, but implementations SHOULD calibrate heartbeat windows and thresholds for the owner's actual usage patterns, not theoretical maximums.

The SSA erroneously declares approximately 12,000 living Americans dead per year. This is a real problem the protocol must handle. The multi-layered safeguards above are designed for exactly this failure mode.

8.2 The Weekend at Bernie's Attack #

Threat: Attacker maintains fake heartbeats after the owner dies to prevent succession and maintain control of the identity.

Mitigations: - Source diversity. Automated service logins will naturally stop when someone dies. Hard to fake a bank login, a doctor visit, AND family contact simultaneously. - Verifier override. Death verifiers can submit attestations at any time, regardless of heartbeat status. Threshold death attestation overrides heartbeat signal. - Public ledger audit. Heartbeat patterns are auditable. A sudden shift from diverse, organic heartbeats to a single synthetic source is detectable.

All implementations SHOULD include "Weekend at Bernie's" in threat model documentation.

8.3 Successor Collusion #

Threat: Successor conspires with verifiers to trigger false death and claim the identity.

Mitigations: - Heartbeat ledger is public. Auditors can see heartbeats are still arriving, contradicting death attestations. - 72-hour override. Owner can contest with recovery key. - Category mixing. The declaration should designate verifiers from independent categories — mix professional (attorney, notary) with personal (family) — to reduce collusion risk. - Fraudulent death attestation to trigger unauthorized succession would violate identity theft and fraud statutes in most jurisdictions. Traditional legal remedies apply.

8.4 Proximity Attestation Privacy #

Proximity-based heartbeats (BLE beacon relay) introduce location-adjacent risks that other heartbeat sources don't have.

• No location data in the proof. The blinded heartbeat records co-presence between two 0xDEAD users, not geographic location. The relay device submits HMAC-SHA256(nonce, CBOR({subject_did, "proximity", timestamp})) — no coordinates, no venue, no cell tower.
• Rotating beacon identifiers. The owner's BLE broadcast identifier MUST rotate at least every 15 minutes (aligned with Apple/Google exposure notification design) to prevent tracking by non-participants.
• Relay-only model. The relaying device never learns the owner's DID. It receives an opaque beacon payload and forwards it to the Succession Service, which holds the mapping. The relay device is a dumb pipe.
• Requires critical mass. Proximity attestation is only useful if enough users run the client app. Implementations SHOULD NOT weight proximity heartbeats heavily until the user base supports it — treat it as corroborating signal, not primary evidence.

8.5 Succession Service Trust #

The service holds rotation keys, manages private attestations, and controls the labeler. That's a lot of trust in one entity.

• Key escrow risk. The service could initiate rotation without death verification. Mitigated by: 72-hour override window, public audit trail of blinded proofs, and the fact that unauthorized rotation is cryptographic evidence of malfeasance.
• Privacy risk. The service sees unblinded attestations. Mitigated by: blinded proofs are public for audit, the service can be operated as open-source with multiple operators, and attestation data has limited value without context.
• Availability risk. If the service goes down, succession can't execute. Mitigated by: open-source implementation, multiple operators possible, DID PLC rotation keys can be used manually as a fallback.

8.6 PLC Directory Trust #

The DID PLC directory is currently operated by Bluesky PBC. This is a centralization risk.

• Bluesky has discussed transitioning PLC directory governance to an independent entity
• Community replicas exist (plc.wtf, plcbundle.atscan.net) for independent verification
• DID PLC operations are cryptographically signed — any entity operating a compatible directory can honor them
• The protocol's security depends primarily on the directory being available. The directory could theoretically serve a forked history in a disputed succession, but community replicas enable independent verification of the operation log

9. CRLReason Mapping (RFC 5280 Section 5.3.1) #

Because the analogy is too precise to leave on the table:

Note on superseded(4): Implementations MUST NOT automatically re-issue mortal certificates based on claims of reincarnation without extraordinary evidence, where "extraordinary" is defined as "at minimum, ECDSA-P384."

10. Future Work #

• Cross-platform asset declarations. Extend the declaration lexicon to reference assets on non-ATProto platforms. "asset": {"platform": "namecheap", "type": "domain", "identifier": "importantproject.io"}. Platforms would need to recognize and honor these declarations — the adoption challenge shifts but doesn't disappear.
• Universal succession protocol. Abstract the ATProto-specific implementation into a platform-agnostic spec. ATProto becomes one integration; others follow.
• SCITT integration. Add timestamped transparency receipts alongside ATProto's self-authenticating repos. SCITT provides independent proof of "this declaration existed at time T" — complementary to ATProto's repo signatures.
• Service Heartbeat SDK. A lightweight library for services to emit blinded heartbeats via OAuth integration. npm install @0xdead/heartbeat should be the entire integration for a web service.
• eIDAS 2.0 integration. EU Digital Identity Wallets (due November 2026) could serve as both identity binding and heartbeat sources across European infrastructure.
• Verifiable Credentials. W3C VC v2.0 as an alternative format for death attestations, enabling interoperability with government-issued digital death certificates as they emerge.

11. Informative References #

[DEAD-PARROT]
          Chapman, G., Cleese, J., "Dead Parrot sketch",
          Monty Python's Flying Circus, BBC, 1969.
          (Canonical dispute regarding the liveness status of a
          certificate subject whose custodian refuses to update
          revocation status. "This parrot is no more! It has
          ceased to be!")

[ROBOCOP] Verhoeven, P., "RoboCop", Orion Pictures, 1987.
          (Cautionary tale regarding unauthorized succession
          of human identity to corporate infrastructure without
          threshold attestation or transparency logging.)

[WEEKEND-AT-BERNIES]
          Klane, R., "Weekend at Bernie's", 1989.
          (Threat model: fraudulent liveness attestation using
          compromised biological key material. See Section 8.2.)

[ATPROTO] Bluesky PBC, "AT Protocol Specification", 2024-2026.
          https://atproto.com/specs
          (The protocol this specification extends.)

[DID-PLC] Bluesky PBC, "did:plc Specification v0.1", 2024.
          https://web.plc.directory/spec/v0.1/did-plc
          (DID method providing the key rotation primitive.)

[RFC-5280]
          Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
          Housley, R., Polk, W., "Internet X.509 Public Key
          Infrastructure Certificate and Certificate Revocation
          List (CRL) Profile", RFC 5280, May 2008.
          (Source of CRLReason codes. Section 5.3.1 never
          anticipated this particular application.)

[RFC-6960]
          Santesson, S., Myers, M., Ankney, R., Malpani, A.,
          Galperin, S., Adams, C., "X.509 Internet Public Key
          Infrastructure Online Certificate Status Protocol -
          OCSP", RFC 6960, June 2013.
          (The conceptual ancestor. RIP, OCSP. You served well.)

[RUFADAA]
          Uniform Law Commission, "Revised Uniform Fiduciary
          Access to Digital Assets Act", 2015.
          (Adopted by 48 US states and the District of Columbia.
          Delaware retains the original UFADAA; Louisiana has no
          comparable legislation. Section 4 defines the "online
          tool" tier that this protocol targets.)

IANA / ATProto Considerations #

• NSID registration: space.0xdead.succession.declaration
• NSID registration: space.0xdead.succession.attestation
• Labeler value registrations: liveness-current, liveness-declining, liveness-overdue, succession-pending, deceased, estate-managed
• DNS TXT record: _lexicon.succession.0xdead.space pointing to the lexicon authority DID
• HTTP Status Code 410 (Gone): Noted as particularly appropriate for deceased identity endpoints

Suggested Transparency Log Names #

• "Styx" (the river of death)
• "Anubis" (weigher of souls)
• "Rekor-Mortis" (for Sigstore integration)
• "Charon" (ferryman — appropriate for a service that transports identities across the threshold)