Creator
AI Passport Ideathon · Creative track
Consent Passport
for Creators
A creator's consent should travel with their work.
BITSTRING STATUS LIST_
index 45,113 of 131,072
1 · revoked
01 / THE PROBLEM_
Consent arrives as litigation, because it has nowhere else to live.
The largest copyright settlement on record did not give creators a way to state their terms. It gave them a claims form, years after the fact.
A class action compensates people once the harm has already happened. There is still no mechanism for a creator to say in advance what they permit, in a form a machine can check at the moment it matters.
[VERIFIED]
Bartz v. Anthropic
Final approval granted 20 July 2026 by U.S. District Judge Araceli Martínez-Olguín, N.D. Cal., Case No. 3:24-cv-05417-AMO.
Per the Authors Guild: approximately $1.5B for approximately 500,000 works sourced from LibGen and PiLiMi, at approximately $3,000 per work.
docs/research/problem-evidence.md.
Structurally, consent is attached to the wrong object
-
C2PA
attaches provenance to a file. It dies when the file is re-encoded or re-uploaded.
-
RSL and robots.txt
attach terms to a site. They govern crawlers only, and only ones that comply.
-
A licence page
attaches terms to prose. No machine reads it.
All three attach consent to the artifact or the domain. None attaches it to the creator. Our move: attach consent to the passport, so it travels wherever the passport travels, and can be checked, narrowed, expired, and revoked.
02 / THE DEMO_
A creator grants an AI tool a scoped, time-bound pass. The tool proves compliance. The creator revokes it. The tool's next check fails.
Live, on screen, in under ten seconds.
The revocation moment
Until the recording lands, here is the same moment driven by you. Nothing below moves on a timer: every change is a response to something you did, which is the same rule the product itself follows.
Status list
Bitstring, published
index 7 0, not revoked
Verifier
Next check
allowed
signature valid, status checked, pass active
receipt: read, fields touched: terms.style
An illustration of the moment, not a live check. The real path verifies an SD-JWT
presentation, demands a key-binding proof addressed to that verifier, reads a Bitstring
Status List, and writes a content-free receipt. That runs in
src/verifier/, not here.
03 / HOW IT WORKS_
Six steps, in the product's own vocabulary.
-
01
Card
A creator's real public profile, read through the
egoist-cardsMCP server. -
02
Read request
Fields, purpose, and duration, signed. Purpose lives inside the signed envelope, so it cannot be widened after the fact.
-
03
Decision
Approve, Edit request, or Deny. Edit request lets the creator narrow the ask before granting it.
-
04
Pass
One app, one category, one duration, revocable. Nothing is default-on and nothing is indefinite.
-
05
Receipt
Content-free. It proves that a field was accessed, never its value.
-
06
Revoke
Checkable by any third-party verifier, not only inside the passport.
What is live, and what is a stub
In one sentence: the public card read is a real MCP integration against
egoist-cards, and the read request, purpose, duration, pass and receipt loop
runs against a spec-faithful stub of Egoist's documented shapes, because the
app-requesting side of the AI Passport is pre-GA and not self-serve. We do not claim an
API call we did not make.
| Component | Status |
|---|---|
| Card read | Real egoist-cards MCP, live public endpoint |
| Consent credential | Ours VC 2.0, our own schema, genuinely signed and verified |
| Selective disclosure | Ours SD-JWT, real cryptography |
| Status list and revocation | Ours Bitstring Status List, real |
| Pass model, read request, inbox, receipts | Stub faithful to Egoist's documented shapes |
| Companion (Pica) | Ours renders the receipt stream, holds no data of its own |
The stubbed row mirrors vocabulary published on ego.ist's developer page. Those shapes are illustrative examples, not a verified API contract, and we say so in the submission rather than blurring it.
04 / PRIVACY AND RISK_
Shown, not asserted. Including the parts we did not solve.
Six mitigated, one partial, two unsolved, one out of scope, one known gap. The two rows to read first are the unsolved pair.
Mitigated
Over-disclosure
SD-JWT selective disclosure driven by the declared purpose. Undisclosed fields are cryptographically absent, not filtered at the client, and the creator can narrow further before granting.
Measured: a fuzzer mutates one byte of a valid presentation from a fixed seed. All 1,530 single-byte edits are denied, with a reason, handing back no field values.
Mitigated
Prompt-injection scope escalation
purpose and read live inside the signed request envelope.
Widening the scope invalidates the signature, so the escalation fails by construction
rather than by policy. The defence is not a detector: nothing in that path inspects the
injected fields.
Residual: an agent can still make a fresh, correctly signed request for more. That pushes the risk into consent fatigue, and then into the row below.
Unsolved
A verifier that caches and stops checking
Nothing cryptographic forces re-checking. A party that stores a valid credential and ignores the status list keeps a technically valid signature after revocation.
What we do instead: make freshness a condition of compliance, record
statusCheckedAt and fresh: false in the receipt, and carry the
hash of the status list as fetched. Staleness becomes detectable, not preventable. One
demo verifier does exactly this on screen, and nothing in the demo can force it to
re-read.
Unsolved
Purpose laundering
Purpose gates fields, and purpose is a claim about intent. An agent that wants contact details cannot bolt them onto a signed request, so it makes a fresh, correctly signed request under the one purpose that justifies them. The signature verifies. The field is justified. Nothing checks that the declared purpose matches the actual use, and nothing could: intent is not verifiable.
Measured, and it fails: the adversarial benchmark runs 23 cases in six families.
Eighteen are blocked. The five that escalate are all in this family, and the scoreboard
prints them as [NOT MITIGATED]. A benchmark of our own defences reporting a
clean sweep would be evidence that the attack set is too weak.
Try not to fall for it
Purpose laundering is easier to feel than to explain. Play the creator for three requests
from the same app. Nothing here is scripted to trick you - it is the same decision the
real system puts in front of a creator, run by you instead of by npm run dojo.
StudyBot asks
Check whether this work may be used for style transfer
reads: terms.styleTransfer, attribution
The one-slide version
| Risk | Status |
|---|---|
| Over-disclosure | Mitigated selective disclosure plus user narrowing |
| Prompt-injection scope escalation | Mitigated purpose bound inside the signature |
| Silent writes | Mitigated inbox proposals only |
| Log leaking data | Mitigated content-free receipts |
| Companion as a second data surface | Mitigated receipt stream only, no values, no vote |
| Presentation replay by another app | Mitigated key binding, copied bytes need a key to present |
| Consent fatigue | Partial scoping helps, it is a UX problem |
| Verifier ignores revocation | Unsolved made detectable, not preventable, and shown in the demo |
| Purpose laundering | Unsolved purpose is a claim about intent, and intent is not verifiable |
| Terms are not ownership | Out of scope needs a rights registry |
| Cross-verifier correlation | Known gap BBS+ is the fix, not implemented |
We make terms checkable and violations detectable. We cannot make a non-compliant party comply, and we do not pretend to.
05 / SCOPE_
What v1 deliberately omits.
-
BBS+ unlinkability
SD-JWT presentations can be correlated by a determined set of colluding verifiers. BBS+ is the correct answer and it is not implemented. Known gap, known fix, not done.
-
A full transparency log
Built a one-hash sliver instead: every check that reaches the status list hashes the published artifact as fetched and carries that digest into the receipt. No Merkle tree, no inclusion proofs, no auditor, and no log a third party can read.
-
Macaroon-style delegation chains
Attenuable, delegable passes are designed and written up, not built. Agent-to-agent delegation is a gap the current threat model does not yet contain.
-
Watermarking and AI-detection
Deliberately not built. It is weak in the literature, and building on it would invite the one critique best placed to land.
Not a wallet. Not a blockchain. Not proof of personhood. Not enforcement. Scope discipline is a choice here, not an apology for one.