Consent proof architecture
What it is: Consent proof architecture is how consent is signed, bound to the attempt, and verified with minimal disclosure—so merchants and verifiers do not need a parallel database of user stories.
Below: what gets signed, how consent binds to the attempt, and how little each party needs to see to verify.
Consent is easy to over-collect and hard to prove. Architecture matters because it decides what gets signed, what gets hashed into the attempt, and what verifiers may learn without turning every merchant into a data custodian. This is the layer beneath the consent framework narrative: how evidence is shaped, not how polite the checkbox copy is.
Signing, binding, and what verifiers learn
- User action — Explicit consent to scope.
- Canonical consent record — Structured fields only.
- Sign — Issuer or delegate signer.
- Present to verifier — Signature + freshness + nonce.
- Map to attempt — Hash inclusion of merchant/amount/currency.
Where current systems fail
Clickwrap logs without signatures. Marketing consent databases used as payment authorization. Verifiers that phone home full PII.
Risks and attack surfaces
- Consent laundering — Broad terms reused for unrelated purchases.
- Verifier data hoarding — Mitigated by minimal disclosure and egress policies.
Marketing teams want friendly copy; risk teams want hash joins. Architecture is where those reconcile: friendly UX at issuance, strict structure everywhere downstream.
How verification or authorization is enforced
Authorization requires a valid consent proof for the attempt fingerprint. Marketing consent does not satisfy this.
Where stateless verification applies
Verifiers validate signatures and structure without storing user profiles.
How AffixIO approaches this
Consent is modeled as signed structure, not marketing assent. AffixIO keeps verifier logic dumb on purpose: validate signatures, match attempt hashes, check freshness—so consent cannot silently broaden because copy changed on a website.
- Attempt binding — Consent proofs join to specific amounts, merchants, and windows.
- Egress discipline — Parties see the minimum viable fields for their role.
- Revocation that competes with latency — Epoch bumps and lists are checked before authorization, not after settlement.
Where this fits in agentic commerce
Issuers sign; merchants verify presentation; APIs transport proofs; edge caches expiry.
What this system does not solve
Cannot prove user comprehension—only that a signed record existed and matches the attempt.
Frequently asked questions
The framework describes roles and rules; this page describes proof topology and verifier obligations.
Verification that completes without exposing underlying PII to parties that do not require it.
So consent cannot be reused for a different merchant, amount, or currency than the user approved.
Further reading
Implement stateless verification
Request a technical walkthrough or integration review.