Module consent_credential 

Revocable consent credentials with crypto-enforced payload revocation + a durable, attestable conduct record — the mechanism that resolves “revocable data vs durable accountability” (docs/plans/social-worker-support-and-accountability.md §2 + §4).

The consideration (Timothy, 2026-07-06): a person can grant an agent (a social worker — a human) a consent credential to an encrypted payload, and can take it away. When taken away the payload becomes unavailable — not by flipping a flag, but by destroying the key (envelope encryption: the payload is Enc(data_key, payload); the credential carries the wrapped data key; revoke ⇒ the wrapped key is destroyed ⇒ no key, no payload). But the agent’s interaction records persist — how and why they acted — so revoking consent cannot erase a worker’s accountability, and a worker cannot hold the person’s data hostage for accountability. The durable ConductRecord binds to a commitment of the payload (not the payload), and carries an Attestation (a signature and/or a zero-knowledge proof over the real crypto/zk_proofs system) so a court can audit that the agent acted, on what basis, at what time — without re-exposing the revoked private data.

The payload lives in a permissive commons (Timothy, 2026-07-06). The ciphertext is an EncryptedCommonsPayload — stored/replicated by many parties so it cannot be deleted (anti-erasure: not by an agent covering their tracks, not by a hostile actor destroying evidence, not by accidental loss) — yet accessible only to holders of the right credential. Wide storage ≠ wide access: the ciphertext is useless without a key. This resolves anti-deletion vs privacy vs access-control at once, and it sharpens revocation: you cannot delete bytes others hold, so revocation is access, not deletion — revoke a credential ⇒ that holder’s key is destroyed ⇒ they lose access, while the durable commons ciphertext persists for other holders and as un-erasable evidence. The person’s ultimate control is crypto-shredding: destroy all keys ⇒ the ciphertext is permanently unreadable by anyone (effective erasure) even though the bytes survive. (Continuous with the permissive-commons + distributed-memory-custody + erasure-prevention stances elsewhere.)

Credentials are not only self-consent, and need not be unilateral (Timothy, 2026-07-06). A credential’s authority may derive from the subject, from a court (to support proceedings / the audit case), or from another attested authority (a statutory body, a guardian) — see CredentialAuthority. And a credential may be multi-signature (Authorization::MultiSig): an exercise then requires (a) instigation by a participating party — so no outside/authority actor can act alone — and (b) a threshold of party signatures. Even a valid court credential, if multi-sig, cannot be exercised without a participating party setting it in motion and the threshold signing. This is the check on authority: unable to act without instigation of one of the participating parties.

Scope of this module. The pure domain model + the invariants — the commons payload, the revocable per-holder access, the court/authority + multi-sig authorization, and the durable conduct trail. It does not perform the actual envelope encryption, the real Groth16 proof, the replication/seeding, or the consent_store/vault wiring — those compose from wellfair/consent_store.rs (whose flag-revoke this design says should become crypto-enforced), wellfair/vault.rs, the WebTorrent/seeder layer (the commons replication), and qualia-core-db::crypto::zk_proofs (coordinate). This is the shape the wiring must honour.

Structs

ConductRecord

A durable record of how and why an agent acted — the conduct trail. It persists after the consent credential is revoked and the payload is gone (revoking consent does not erase accountability), and it binds to the payload commitment (not the payload), so it proves the agent acted on a specific datum without retaining or re-exposing that datum. Append-only in practice (the store is tamper-evident — signed WAL); this type is the record.

ConsentCredential

A consent credential — grants an agent scoped access to an encrypted payload; revocable, with the revocation crypto-enforced (the wrapped key is destroyed). Its authority may be self-consent, a court, or another authority (CredentialAuthority); its exercise may require multi-sig (Authorization).

EncryptedCommonsPayload

An encrypted payload in a permissive commons — content-addressed ciphertext that many parties may store (replicate) so it cannot be deleted (anti-erasure), but that is accessible only to holders of the right credential (the wrapped decryption key). Wide storage ≠ wide access: without a key the ciphertext is opaque.

ExerciseRequest

A request to exercise a credential: who instigated it, and the party signatures collected.

Party

A participating party in a multi-signature authorization.

Enums

Attestation

The cryptographic attestation on a ConductRecord — attributable + court-auditable.

Authorization

How a credential may be exercised (acted on the payload).

CredentialAuthority

Where a credential’s authority derives from — the basis on which access is granted. Not always self-consent: a court can hold one (to support proceedings), as can another attested authority. Authority-issued credentials are legitimate — and, when multi-sig, still cannot be exercised unilaterally.

Functions

audit_trail_for_credential

Filter a conduct trail to the records taken under one consent credential — the audit view. These are exactly the records that survive that credential’s revocation (the accountability the person cannot erase and the worker cannot withhold).

is_crypto_shredded

Crypto-shredding check. Is this commons payload effectively erased — permanently unreadable — for a given set of credentials at now? True iff no credential grants a live key to it (every credential for this commitment is revoked/expired, or none exists). The bytes may still be replicated across the commons, but with no key anywhere they cannot be decrypted by anyone — the person’s ultimate erasure control, achieved by destroying keys rather than by chasing copies.

Type Aliases

PayloadCommitment

A commitment to a payload — a 32-byte hash/commitment (e.g. BLAKE3/SHA-256, computed by the crypto layer). It survives revocation and binds a ConductRecord to what was acted on, without holding or re-exposing the payload itself. It is also the content address of the EncryptedCommonsPayload.