Six-stage walkthrough of a concrete ABT-C transaction annotated with the legal significance of each stage. Covers plaintext custody allocation, per-tier structural retention destruction, and the architectural property that makes first-party authorization a structural requirement — not a policy promise.
This document is a technical reference prepared for counsel review. It does not constitute legal advice. Statements about data custody, retention, and production compellability reflect the technical architecture of the ABT-C protocol as currently implemented at cinematiccard.com. Counsel should independently assess applicability to specific regulatory or litigation contexts.
The consumer's device holds a persistent cryptographic key. From it, the device derives a tokenized decryption key scoped to this single transaction. Neither the root key nor any plaintext leaves the device during this stage.
api_key_maya) from which all per-transaction tokens are derived exists only on Maya's device.
api_key_maya) exists exclusively on the consumer's device. No party — merchant, vault operator, registry — ever holds or can compel production of this key from any system other than Maya's device.
The vault stores the encrypted envelope and the tokenized decryption key. The vault holds ciphertext — not plaintext. The decryption key is released only upon authorization from the consumer's device. The merchant holds neither the envelope nor the key.
operational_consumer, operational_merchant, taxation, and 15 placeholder reservations for future tier authorities (regulatory, compliance, audit, etc.) not yet onboarded to the registry.
The cafe requests the merchant-tier token slice. The vault forwards the request to Maya's device. Maya's device verifies the merchant and releases a scoped slice — restricted to the merchant tier only. Decryption occurs at the cafe's endpoint. The consumer identity and taxation layers remain cryptographically sealed to the merchant at all times.
At retention expiration, the decryption pathway for the consumer identity tier is irreversibly destroyed. This is structural: no policy override, no administrative extension, no recovery. The merchant and taxation tiers remain accessible to their respective authorized parties.
The consumer identity tier is destroyed. The merchant cannot bind a refund to the original buyer without Maya's participation. The refund request, signed by Maya's device, travels through the registry for signature verification and is forwarded to the merchant. The merchant awaits a fresh token from Maya's device.
Maya's device derives a refund-scoped token from the on-device root key. The vault uses it to reconstruct the consumer identity layer with a 7-day retention window. The merchant processes the refund. After 7 days, the new window closes and the consumer identity returns to destroyed state.
| Property | Technical basis and legal relevance |
|---|---|
| No plaintext in transit | Plaintext is never transmitted over the network at any stage. What moves is ciphertext and per-tier token slices. Interception of network traffic at any point in the protocol yields only encrypted bytes. Relevant to: breach notification threshold; negligence analysis; GDPR Art. 32 technical measures. |
| Merchant access limited by cryptographic structure | The merchant receives only the merchant-tier projection of the transaction envelope. The consumer identity and taxation tiers are cryptographically sealed to the merchant — not by access policy, but by the cryptographic structure of the envelope itself. A subpoena to the merchant produces only what they can decrypt, which is limited to their tier by design. |
| Vault holds encrypted bytes, not personal data | The vault operator holds ciphertext that cannot be read without decryption material controlled by the consumer's device. In the functional sense, the vault is not in possession of personal data — it is in possession of data that cannot be acted upon or disclosed in intelligible form without consumer participation. |
| Retention enforcement is structural | At retention expiration, the decryption pathway for the consumer identity tier is cryptographically destroyed. This is not a deletion policy — the cryptographic material is gone. No administrative override, no extension, no recovery is possible by any party. Relevant to: right-to-erasure compliance; deletion verification; data minimization. |
| Post-retention production is impossible | After day 30, no party — merchant, vault operator, registry operator, or any compelled third party — can produce Maya's identity from this transaction. A subpoena served after retention expiration on any system in the protocol cannot compel production of information that no longer exists in decryptable form in any system. |
| Refund requires first-party participation | Post-retention refunds structurally require Maya's device to derive a fresh token. No third party can derive this token. No court order directed to the merchant, vault, or registry can compel a refund that binds to Maya's identity. The first-party requirement is architectural, not policy-based. |
| Registry is witness, not controller | The registry maintains hash-chained witness logs. It verifies signatures and routes refund requests. It does not route or gate transactions. It does not hold decryption material for any tier. A subpoena to the registry produces: signature verification records, routing records, and the public side of the key pair — not decryption capability. |
| Tamper-evident audit log | All registry-witnessed events extend a hash chain. The chain is tamper-evident: any modification of a prior record breaks the chain in a verifiable way. Records in the chain can be authenticated without access to the plaintext content of any tier. |