A worked example of per-venue key derivation, age-only projection, and cross-disclosure unlinkability in the identity variant of the ABT methodology family.
The ABT-I variant applies the foundational envelope-tier architecture to identity disclosure, with age-gated venue access as the canonical scenario. The variant-specific architectural elements are: per-venue per-disclosure key derivation, such that each disclosure event produces a cryptographically independent token derived from the patron's persistent identity key but sharing no common value with any other disclosure token; attribute-only projection, in which the venue receives solely the claimed attribute (age_verified: true) and nothing that could reconstruct the patron's identity; and structural cross-disclosure unlinkability, in which two disclosures by the same patron to two different venues on the same evening are computationally unlinkable without participation of the patron's first-party device. This memorandum follows Pita Faleolo across two venues on a single evening, traces each disclosure event to its cryptographic boundary, and identifies the legal significance of each architectural property.
Faleolo holds a persistent identity key on her personal device, registered at enrollment. She derives a per-venue per-disclosure token before any data is transmitted. Bar Alcazar receives a projection — not the key.
| Actor | Endpoint | Holds at this stage |
|---|---|---|
Pita Faleolo Patron · first party | Personal device | Persistent identity key ik_faleolo; derives per-disclosure token disc_alcazar_e4b1 locally before transmission |
Bar Alcazar Venue · age-verification recipient · second party | Venue point of entry | Venue key for Alcazar; can decrypt the age-only projection authored for Alcazar; holds no other credential |
Disclosure Registry Neutral witness | Independent oversight infrastructure | Receives notification of disclosure event; records hash-chained witness entry; holds no decryption material for the projection |
The disclosure token disc_alcazar_e4b1 is derived on Faleolo's device as: KDF(ik_faleolo, venue_id_alcazar, session_nonce). The derivation is irreversible: possessing disc_alcazar_e4b1 does not enable recovery of ik_faleolo. No common value between disc_alcazar_e4b1 and any future disclosure token is exposed at this step.
The projection authored for Bar Alcazar contains one attribute: age_verified: true. It is encrypted to Alcazar's venue key. No name, address, date of birth, or government credential number is included in the Alcazar-addressable projection.
age_verified: true and discloses nothing beyond that purpose. Under CCPA § 1798.100(a), a business shall not require a consumer to provide personal information beyond what is reasonably necessary to provide the requested service. Venue entry is the requested service; the age attribute is sufficient.
The projection is decrypted at Bar Alcazar's endpoint. The result: a single boolean attribute. Alcazar's venue key cannot decrypt anything outside the Alcazar-addressed projection layer.
The registry records that a disclosure event occurred. It does not record who disclosed. The witness entry contains the disclosure token identifier, a timestamp, and the hash-chain extension. No patron identity appears in the registry's witness log.
The registry does not hold, and does not receive, Faleolo's persistent identity key ik_faleolo. The witness entry is keyed to the disclosure token disc_alcazar_e4b1. The registry cannot reverse disc_alcazar_e4b1 to ik_faleolo because the derivation is a one-way KDF. The registry cannot link disc_alcazar_e4b1 to any subsequent disclosure token without participation of Faleolo's device.
Later that evening, Faleolo presents at Bar Verde. Her device derives a new disclosure token for Verde, using Verde's venue_id and a fresh session nonce. The derivation produces disc_verde_9c3a — a token that shares no common identifier with the Alcazar disclosure.
Bar Verde receives disc_verde_9c3a. Bar Alcazar holds disc_alcazar_e4b1. The two tokens share no common field. There is no session identifier, patron pseudonym, or shared nonce that appears in both projections. The only element that could connect the two disclosures is ik_faleolo — and that key never left Faleolo's device.
Verde's projection contains the same age attribute. It is addressed to Verde's venue key. It is a separate cryptographic event, not a re-use of the Alcazar disclosure.
Bar Verde does not know that Faleolo visited Bar Alcazar earlier. The Verde projection contains no reference to the Alcazar event. Verde's venue key cannot decrypt the Alcazar projection. The two disclosure events are independent cryptographic transactions.
A party in possession of both venue logs cannot correlate the two entries to the same patron. The unlinkability is not an anonymization technique — it is a property of the derivation architecture.
For a third party to correlate disc_alcazar_e4b1 with disc_verde_9c3a, they would need to demonstrate that both tokens derive from the same root key. That computation requires ik_faleolo. That key is held only on Faleolo's personal device. No venue, no registry, no data broker, and no subpoena directed at Alcazar or Verde can compel its production — because none of those parties hold it.
The only entity capable of proving that both disclosures originate from the same patron is Faleolo herself. Linkability is a first-party power. This is the core structural claim of ABT-I: cross-disclosure correlation requires active participation of the disclosing party, not administrative access to a platform credential.
The following properties hold by cryptographic construction, not by policy or contractual commitment.
| Property | Guarantee | Legal relevance |
|---|---|---|
| Per-venue key derivation | Each disclosure token is cryptographically independent; sharing no common value with any token issued for a different venue | Structural data minimisation; each venue receives only what its derivation scope addresses |
| Attribute-only projection | Venue receives the claimed attribute (age_verified: true) and no other personal information | Satisfies GDPR Art. 11 purpose-limited processing; CCPA minimum necessary standard |
| No PII in transit | Faleolo's name, date of birth, and government credential never traverse the network in any projection layer | Eliminates basis for compelled production of PII from venue or registry — data not held cannot be produced |
| Cross-disclosure unlinkability | Two projections from the same patron to two different venues cannot be correlated without the patron's persistent identity key | Third-party data aggregation structurally precluded; law enforcement correlation requires first-party participation or device seizure |
| Witness-mode registry | Registry records disclosure event tokens and timestamps; holds no patron identity material | Registry subpoena yields tamper-evident log of events — no PII; cannot satisfy a request keyed to patron identity |
| Patron-controlled linkability | Only the patron's device can prove two disclosures originate from the same identity key | Linkability is a first-party right; not accessible to venues, registry, or third-party processors |
ABT-I does not guarantee anonymity against a party who has lawfully seized the patron's device and extracted ik_faleolo. Device seizure under lawful process may produce the root key, from which all prior disclosure tokens can be derived and correlated. The protocol guarantees only that correlation is not possible from venue or registry records alone. The cryptographic boundary is the device — not the venue, not the network, and not the registry.