ANCHORED SUBJECT-RIGHTS RECEIPTS

Anchored Subject-Rights Receipts

Records the lifecycle of a data-subject rights request — access, rectification, restriction, portability, and objection. One chain per request; profile-typed events per right. Composes with ARR for erasure execution evidence.

ASR · Shipped9 wire typesApache-2.0 · CC0 spec
← All familiesVerify a receipt →

WIRE TYPES

ar.subject_rights.v1 (request.received)

Records receipt of a subject-rights request. Starts a per-request chain. The right type (access, rectification, erasure, restriction, portability, objection) is declared via profile.

ar.subject_rights.v1 (request.identity_verified)

Records that the requesting subject's identity was verified before processing the request.

ar.subject_rights.v1 (request.scope_clarified)

Records a clarification of the request scope — when the initial request was ambiguous or overly broad.

ar.subject_rights.v1 (request.extended)

Records an extension of the one-month response deadline under Art. 12(3), including the reason for extension.

ar.subject_rights.v1 (request.partially_honoured)

Records partial fulfilment — which parts of the request were honoured and which were declined with reasons.

ar.subject_rights.v1 (request.fulfilled)

Records full fulfilment of the request. For Art. 17 erasure, MUST cross-link to an ARR execution receipt.

ar.subject_rights.v1 (request.refused)

Records refusal with the legal basis for refusal and information about the right to lodge a complaint with a supervisory authority.

ar.subject_rights.v1 (request.escalated)

Records that the request has been escalated — to a DPO, supervisory authority, or judicial remedy.

ar.subject_rights.v1 (request.recipient_notified)

Records Art. 19 notification to recipients of rectification, erasure, or restriction.

WHAT IT PROVES

  • A subject-rights request was received before a specific UTC date (Merkle inclusion proof).
  • The request was processed within the one-month deadline or a justified extension was recorded.
  • Identity was verified before processing (chain walk confirms ordering).
  • For erasure requests: the deletion was actually executed (mandatory ARR cross-link on fulfilment).

WHAT IT DOESN'T PROVE

  • The response was substantively complete or accurate.
  • All data stores and processors were properly notified.
  • The subject was satisfied with the response.
  • The refusal grounds were legally sufficient.

COMPOSES WITH

ASR receipts reference other family members via body-level composition pointers — verifier-coordinated, not signature-mandated.

ARRAnchored Retention Receipts

Art. 17 fulfilment MUST reference an ARR erasure receipt — the execution evidence for the honoured-within-deadline proof bundle.

ALRAnchored Lineage Receipts

Art. 19 recipient notification references ALR disclosed history to compute the set of recipients to notify.

ATRAnchored Transfer Receipts

Art. 20 portability requests may reference ATR receipts for the transfer mechanism used.

APuRAnchored Purpose Receipts

Art. 21 objection terminates a purpose binding — the ASR objection event may emit a corresponding APuR unbinding.

Verify any
ASR receipt.

verify.dekimu.com ↗

Paste any claim ID to verify a receipt, check its anchor, and inspect the issuer signature.

REFERENCES

GDPR Art. 15 — Right of access (EUR-Lex)
GDPR Art. 16 — Right to rectification (EUR-Lex)
GDPR Art. 18 — Right to restriction (EUR-Lex)
GDPR Art. 20 — Right to data portability (EUR-Lex)
GDPR Art. 21 — Right to object (EUR-Lex)

Anchored Subject-Rights Receipts are cryptographic provenance and privacy-lifecycle protocols. verify.dekimu.com is a reference implementation, not a qualified trust service under Regulation (EU) No 910/2014 (eIDAS) or successor.