Trust Mesh
A Human Authorization Layer for the Internet
An overview for NIST, policymakers, and the public
1. Summary and Request
What I propose is a standardized way for anyone to check evidence of an enrolled person’s authorization of a specific action under a declared assurance profile, without learning who that person is. The reason for the anonymity and unlinkability is simply to not add another attack surface for hackers to exploit, and to prevent unnecessary surveillance that the public will reject. This is a decentralized human authorization layer that operates between hardware and software, intended for integration across supported endpoints. A person approves an action on their own phone, which produces a small digital receipt tied to that exact action. Any integrated app at a bank, newsroom, government office, or software company can automatically check the receipt against the published verification parameters to verify the required credential, action binding, freshness, and permissions before allowing the action to occur. The receipt carries no name or account number, and ordinary receipt proofs are designed to be unlinkable across services under the specification’s stated assumptions and leakage scope. This does not hide a business’s own account records, network metadata, or the relations explicitly disclosed by a particular profile. Verification speed remains a measurement requirement.
I call the system Trust Mesh. It is designed as an open standard governed by a nonprofit foundation that will hold its patents, so no company and no government owns it. The specification describes the protocol and identifies its remaining proof, implementation, and qualification obligations. It has not yet been built or deployed.
I ask NIST to review Trust Mesh as a candidate standard for proving human authorization of consequential actions as a solution to the next era of digital systems security at the edge where today’s identity and login standards stop. NIST’s National Cybersecurity Center of Excellence has begun a project on how AI agents are identified and authorized, with further use cases still to be scoped. Human authorization of agent actions is one of the many use cases this work was built for. Trust Mesh can contribute to that project as a pilot with one relying party under NIST’s observation.
2. The Problem It Solves
Remote fraud runs on stolen access. Criminals take usernames, passwords, session cookies, seed phrases, and signing keys by leveraging human farms: call floors where paid workers run romance scripts, fake support desks, and phishing kits all day, moving from one victim to the next. Many accounts rely on credentials whose theft can let an attacker act as the owner, although existing systems can also require device-bound authenticators, additional checks, and transaction approval. The same new tools empowering the cure for cancer also allow criminals to automate and scale their operations to machine speed.
For most of the internet’s history, faking a person took effort and resources. A forged letter could be caught by its writing, a fake voice by its sound, and a fake profile by the work it took to keep alive. AI has removed most of that cost. A model trained on a company’s emails can write as its CEO. A short public recording can supply material for a convincing voice clone. A finance officer who follows every rule, checks the email, and calls back to confirm can still send millions to a criminal when those checks fail to bind the instruction to an authenticated, authorized source. Business email compromise alone costs billions of dollars a year. The criminals have no need for a frontier lab. They run open models on their own machines, where thousands of agents build a dossier on each target from whatever data they find online, clone the voice, and test which story works best on whom. The schemes run around the clock and get better with every attempt. Phones and inboxes give attackers a large population of possible targets. At machine speed the defense has to hold all of them every time, but the attacker only has to get through one.
The same scams will proliferate across ordinary life. A parent gets a text on a Thursday from an adult child mentioning a Saturday road trip. On Saturday a video call comes in from the side of a road with trees behind and traffic going by, asking for a hundred dollars for gas because they ran out. The face on the screen is a deepfake built from videos the child posted, and the money goes to a scammer’s account. A video of a governor announcing something she never said reaches millions of viewers before anyone can disprove it. A remote hire turns out to be someone else entirely. In each case the question our existing security systems can’t answer is simple: did a real person actually approve this exact action right now? Trust Mesh requires a receipt to verify authorization that a cloned voice or image alone cannot produce, and fills in the gaps left by cybersecurity products.
Agent adoption will stall for the same reason. Businesses want AI agents that book travel, pay invoices, and ship code. But the companies on the receiving end need evidence that distinguishes an authorized action from one outside the agent’s approved scope. Businesses won’t trust outside agents to access their system without a standardized and composable way to verify in real time that they are legitimate. The solution is a decentralized network with locked code that can only be changed by a supermajority of the diverse multi-jurisdictional participants who keep each other in check.
3. Why Detection Loses
Good bots fighting bad bots is the limited strategy most cybersecurity defenses follow today: software built to spot fake voices, fake videos, and fake logins, trying to stay a step ahead. But that race is limited to the people and businesses who deploy it, leaving gaps to exploit everywhere. Betting on the good bots to defeat the bad bots forever means choosing to engage in an endless war. You can’t solve a digital problem at the same level at which it exists. The solution is one level up, requiring human authorization for digital software to have the authority to act at all.
The durable fix moves approval into a protected path tied to the person. Trust Mesh lets an integrated system require authorization for a consequential action, either through a fresh approval or within a previously approved delegation. On the local path, the conforming app checks the person against the certified local marker, the phone performs its required face or fingerprint check, and the protected key signs the action binding. An ordinary receipt does not independently prove that the app performed its local match or that the person saw the correct action on an untrusted display. Network-checked profiles add the specified comparison to the Slot’s current approved reference. A cloned voice or image alone supplies none of these authorizations. The protection still depends on the admitted device and capture profile, the integrity of the relevant software and hardware, and the relying party enforcing the receipt requirement.
Some problems stay outside this design. A flaw in a website’s code is a software defect, which is fixed by better engineering, testing, and formal verification. Trust Mesh addresses the misuse of authority, particularly when a remote person or software acts in a person’s name without that person’s approval because they have the credentials to their bearer accounts. Trust Mesh adds an authorization requirement at integrated gates; its protection depends on the selected profile and on correct enforcement by the relying party.
4. Where It Fits in Existing Standards
Trust Mesh composes with the standards agencies and companies already use, and replaces none of them. NIST SP 800-63-4 governs identity proofing, authentication, and federation. FIDO2 and passkeys provide phishing-resistant authentication bound to an origin. DKIM, SPF, and DMARC authenticate email domains. The EU Digital Identity Wallet presents verified identity attributes with selective disclosure. C2PA records the provenance of media files. Payment schemes bind authentication to transaction context through Secure Payment Confirmation, EMV 3-D Secure, and PSD2 Strong Customer Authentication.
The contribution proposed here is a common, privacy-preserving authorization receipt that integrates with existing controls. Passkeys authenticate an account to an origin; an application can bind an assertion to a transaction, although ordinary WebAuthn does not itself provide a trusted display of the transaction details. Secure Payment Confirmation expressly adds payment-specific confirmation. A DKIM signature authenticates signed message content under a domain’s key, but a compromised executive mailbox can still send validly signed mail. Trust Mesh proposes to combine enrolled-person credentials, action binding, scoped permissions, and ordinary cross-service receipt unlinkability. Verification can be local with the required authenticated parameters and currentness evidence; obtaining or refreshing that evidence and enforcing replay or spend state may require network access. These are different properties, not evidence that existing standards cannot authorize actions.
Under SP 800-63-4, Trust Mesh maps onto existing vocabulary and does not invent a parallel assurance scheme. Its device and capture profiles describe where a holder authorizes and where enrollment captures are taken. Its Path A and Path B credentials and its local and network-checked operation profiles have distinct requirements; they are not automatically NIST assurance levels. Receipts are authorization evidence that composes with identity proofing, authenticator assurance, and federation assertions. The intended contribution is an execution-authorization profile that NIST guidance, sector profiles, or agency procurement rules can reference once a pilot produces operational evidence.
Financial-crime obligations remain where they are. A receipt can strengthen the evidence that a customer or an authorized officer approved a wire, while customer due diligence, sanctions screening, and suspicious activity reporting continue under the Bank Secrecy Act and its equivalents.
5. A Third Account Type
Existing accounts use different combinations of identity records, passwords, cryptographic keys, device-bound authenticators, and transaction checks. A bank generally keeps a named customer relationship and additional controls. A crypto wallet may let whoever controls its signing keys move the assets, although wallet designs also support multiple signers, hardware protection, and recovery policies. Trust Mesh proposes an additional person-bound authorization layer for these systems rather than treating every existing account as the same kind of bearer account.
Trust Mesh creates a third kind of account: a private position backed by one unique, living person, called a Slot. It integrates as a security layer beneath bank accounts, government accounts, and work logins as an extra lock on the actions that matter. It does not replace any of them. A bank keeps its own account, its own know-your-customer checks, and its own records. It simply adds one requirement: before a consequential action like a large bank wire, or even a simple login, may occur, a receipt from the account holder’s Trust Mesh Slot must arrive. The Slot itself carries no name because adding a name or a number would only give fraudsters one more target to attack. People hear “anonymous accounts” and think of the dark web, but that conflates the actual business account, which stays as it is, with the invisible and anonymous Trust Mesh account that exists silently beneath it. The anonymity lives only in the security layer, which proves that the right person approved this action without adding yet another identifier of personal data to the world.
6. Design Invariants
A security layer like Trust Mesh must be able to onboard users and run on consumer devices because this layer has to protect everyone. Specialized readers, kiosks, and tokens serve institutions well, but they cannot cover billions of people in their everyday lives. Many consumer phones have cameras, supported biometric authentication, and hardware that can protect keys, such as Apple’s Secure Enclave or Android hardware-backed keystores. Fingerprint sensors, StrongBox, attestation features, and the capabilities required by each profile are not universal. People without a suitable phone can still be served through certified terminals and supervised enrollment, but at a lower assurance tier, which travels on their receipts until they are able to get a capable phone. Trust Mesh is an additional layer of security, not a mandatory one, but once it is deployed, the reduction in remote fraud, arriving just as fraud scales to machine speed, may drive adoption on its own.
A decentralized security layer means the network must not hold a list of the names of its users. Some enrollment data is kept for the purpose of deduplication and uniqueness checks, but it is the least amount possible. That data is split into encrypted pieces held by independent operators where no single operator can read any of it, and it follows the specified retention and deletion rules, including the three-year inactivity rule and its lawful-hold and protocol-specific exceptions. A database of identifiers is the prize every hacker goes after, so minimizing identifying data reduces what a breach could expose; it does not make attacks impossible or necessarily uneconomic.
The system must not add a global identifier that links ordinary receipts across services. Randomized proofs are designed to prevent a bank and a news website from linking those proofs cryptographically under the specification’s assumptions. That guarantee does not erase identities a business already knows, timing and transport metadata, or the event and protocol relations explicitly disclosed by the selected profile. The protected registry retains the specified row and participation state. The privacy claim must be read with that disclosure inventory.
7. Enrollment and the Uniqueness Problem
One Slot per human is the hard problem underneath every digital system. If one actor can appear as many, then votes get stuffed, promotions get farmed, and every “one per customer” limit stops meaning anything. Blockchains answered this by making it expensive for one person to be many through mining or staking, which puts power with whoever has the most capital. Governments and companies answer it with identity databases, which become targets to attack. Trust Mesh uses the one resource every person has exactly one of that even the most advanced AI agent cannot produce: human biological uniqueness. Enrollment checks the person against the registry under the qualified comparison procedure. Network-checked counted participation adds a fresh comparison against the Slot’s current approved reference and the required event checks. The spec also retains local counting where policy expressly accepts its weaker assurance: it conserves one entitlement per admitted Slot but does not independently establish one unique body per response. A future governed policy could require network checks for all counted participation.
At enrollment, a person opens the Trust Mesh app on their phone and follows a short guided capture of their face and four labeled fingers with prompts and presentation-attack checks whose effectiveness must be measured. In the same session, on the standard route, the person holds a government document, such as a passport or national ID card, to the phone. The phone reads the chip and checks that an accepted government issuer signed it and it belongs to the person in front of the camera. The phone then encrypts the capture, together with the document evidence, and sends it to a group of independent operators under a key that seven of the ten operators must combine their shares to use. Under the admitted protected-computation and custody assumptions, no individual operator receives the plaintext capture or document.
Inside a joint computation, the operators compare the capture against the existing enrollees it most resembles to narrow the pool down as much as possible, and in the same transaction they check that no other Slot already holds the document. Uniqueness is decided by comparing the body against the whole registry. The only answer that comes out is admit, refuse, or send to review. Refuse is reserved for the cases already settled, a body that matches an existing Slot or an applicable installation or request budget that has been exhausted, and it points the person to recovery and to appeal rather than to a second try. Anything the comparison cannot settle goes to review, remote or in person.
A person without a chipped document can get the same full standing in person, through a supervised capture with a trained witness on better sensors, where the witness’s confirmation takes the place of the document, then the same body comparison runs. A person who has no document and cannot attend in person can still enroll remotely for their own security layer on their existing identity accounts so no one is left out, but that Slot cannot join the counted events where one person must count exactly once, such as a vote, a benefit, or a one-per-person allocation, until the person completes the supervised in-person ceremony. The reason is that phone sensors cannot yet guarantee uniqueness by biology alone, which is why the qualifying document or supervised route and the sealed face/fingers reference remain part of the design. The sealed reference is stored on the network under the specified distributed custody and hardware protections.
Two things derived from the document stay behind, each for one job. The first is a reuse token. The phone and the operators compute it from four things on the document: the issuing authority, the document type, the issuer’s own permanent identifier for that document, and the version of the encoding rules, run through a one-way function under a key the operators hold jointly. The token stands for exactly one physical document. Under the keyed-function and protected-computation assumptions, the token does not directly disclose those document fields or provide a similarity measure. Key compromise and access to the evaluation service remain part of the threat model. It sits in a reuse index and answers one question: has this exact document been attached to a Slot before? That closes a specific attack. Someone who slips past the body comparison as a new person (a twin, a close look-alike, or a spoof that got through) could otherwise attach a document already bound to someone else’s Slot. The reuse token blocks that. It cannot do more, which is why the document does not decide uniqueness. A person can hold two genuine documents, through dual citizenship, a renewed passport beside a national ID, or a corrupt issuer handing out a second real one. Different document identifiers normally produce different tokens, so the token alone cannot establish that the holders are different people. And a person who has no document produces no token at all, so a rule that relied on documents for uniqueness would have nothing to check for the hundreds of millions of people without them. Uniqueness therefore rests on the body, compared against the whole registry, and the token only guards the document, which provides the verified details for the second step.
The second step is a small set of sealed facts: the date of birth, the given first name grouped with its common spellings, the kind of document, the kind of issuer, the version of the rules the document was checked under, and the reuse-index value. They are held under the seven-of-ten custody threshold and the protected-release requirements, rather than being available to seven administrators merely on request. No surname, address, document number, government identifier, or image of the document is kept. The birth date and given name are kept because the body comparison has a soft edge, and they are the two facts that sharpen it. The hardest collisions are look-alikes, and the hardest look-alikes are twins. A surname generally does not help distinguish twins, and a birth date commonly does not either. Given names can help distinguish some twins, and birth dates can help distinguish some unrelated look-alikes. Neither is unique or infallible, and together with other information they can be identifying. They are supporting evidence inside the specified protected decision procedure, not proof of biological identity.
They are used in a fixed order. The body comparison runs first and picks its candidates from the whole registry with no filter by name or birth date in front of it. If a name could decide which references get compared, a fraudster would enroll a second time under a different name and never be compared against their own body in the first one. Only after the body has chosen the candidates, and only for the pairs it cannot cleanly determine are the one person or two different people, do the sealed facts come into play inside the joint computation. A matching birth date and given first name support the specified duplicate decision for a borderline pair, subject to the rule’s qualification and appeal path. They do not prove that two captures are one person. A second genuine document does not bypass the body comparison merely because its reuse token is different. A different name or birth date alone can never overturn a match on the body because differing civil facts alone do not establish that the bodies are different.
The rule that would clear a borderline pair as two different people on the strength of differing civil facts is specified but not yet measured empirically, so until it is, those pairs go to human review. Take a new enrollee whose face and fingers land close to an existing Slot. Her sealed facts say Maria, born 1988; the existing Slot’s say Elena, born 1991. Admitting her automatically as a second person based on different civil facts is safe only if a fraudster cannot come back as Maria with a second genuine-looking document from a careless or corrupt government issuer, and how often that happens, per issuer and per country, has not been measured. Until it is, Maria goes to review. The result that comes out is still only admit, refuse, or send to review. On the in-person route, there is no document and there are no sealed facts, so a case that close goes to human review directly.
The rule is one Slot per person, subject to the measured enrollment error rates and the review and appeal procedures. Lending a phone does not create another legitimate Slot. On the local authorization path, the conforming app must perform a fresh match against the certified local marker as well as the required phone biometric check; adding another face to the phone’s settings does not by itself satisfy that second match. But an ordinary receipt does not independently prove the app performed it, and biometric false acceptance, twins, compromised software, coercion, and authorized delegation remain relevant. A person can seek to reclaim their Slot through the governed recovery process. The specification names lent uniqueness as a residual; it does not prove that renting bodies is impossible, limited to one physical location, or economically unscalable.
This changes the work required for credential-based fraud where the relying party enforces the receipt profile. Stolen passwords alone do not satisfy the additional authorization requirement. It does not eliminate organized coercion, recruited participants, fraudulent approvals by real people, or shared software and hardware failures. Their scale and cost must be assessed rather than assumed away.
What comes out of enrollment is a Slot, a private position in the network bound to keys on the person’s phone and no name. The network keeps the sealed reference, in shares, for future duplicate checks, and the phone keeps its own certified sample of the person’s face and fingers, which it will use to check later approvals made on that phone. The phone also computes the blinded marker, a one-way value from the body that no decision reads yet, and the network stores it beside the reference for the governed field study of whether repeatable markers could eventually replace reference comparison under measured error and privacy requirements. That is the ultimate aspiration.
Trust Mesh separates two jobs most systems combine. Telling one person apart from eight billion is the uniqueness problem, and the network addresses it at enrollment and the other required comparison ceremonies. Confirming the same person is present right now for this exact action is a local authentication problem, and the conforming phone app addresses it on the local path, with network comparison added where the operation profile requires it. The two jobs use different materials kept in different places. The design calls this split the Fork. The same enrollment process also creates a third, separate path for recovering a lost phone, but that path cannot approve actions or look anyone up.
This process is the result of dozens of adversarial rounds examining ways a fraudster might obtain a second Slot or use someone else’s. Each attack, what bounds it today, and what closes it are set out in Appendix A. They leave several distinct open or measured boundaries, including capture injection, issuer and witness failures, biometric error, local-check enforcement, recovery, and coercion. Qualified sensor and display protections could strengthen particular boundaries; they do not close every residual.
8. What the Network Holds
The inventory is short. For each Slot, the network keeps a sealed reference of the person’s face and fingers, used by the specified protected enrollment, reference, and operation checks. It keeps a row of derived values used for fast comparison, a blinded marker held for research and read by no decision, and a protected recovery reference under its own custody, used only by the recovery lane. If the person attached an identity document, six facts from it are kept sealed beside the reference: the verified date of birth, the given name grouped with its common equivalent forms, the kind of document, the kind of issuer, the version of the rules it was checked under, and a value that stops the same document from backing a second Slot. The civil disambiguation facts are consulted only at the specified comparison stage; the document reuse value also serves its separate uniqueness-of-document check. No surname, address, document number, government ID number, or image is kept, and the document itself is discarded once it is checked. Every item is split into encrypted shares held by independent operators, ten at launch, and reconstructing custody values requires the applicable threshold of actual shares and defeat of the corresponding protected release controls, except for authorized releases under the protocol.
The three-year inactivity rule applies when the Slot neither renews its permissions nor performs another qualifying network ceremony, subject to lawful holds and the specification’s object-specific retention, deletion, and recovery rules. In the required hardware deployment, administrative control of seven operators alone does not expose their shares or permit arbitrary outputs. If an attacker defeats enough custody protections to obtain seven actual coordinates, stored references and associated retained facts can be exposed. Effective signing or state compromise is a separate power: four to six effective faults in the launch ten-member state machine can permit conflicting histories when the attacker can obtain the required conflicting votes; seven arbitrary certification shares can forge that authority’s assertions. Custody disclosure alone does not confer signing authority. None of these powers automatically reveals an uncompromised holder’s existing phone keys or supplies the separate votes required to change policy. Correlated vendor, software, or root failures can defeat multiple seats and must not be treated as independent hardware attacks.
That is the intended advantage of the permissioned network. Approved independent clients belong to one governed release supplied through the Trust Mesh nonprofit’s release process, and validators must run the approved software under the required hardware enforcement. The trust model does not depend on an administrator choosing to remain honest when the enforced path is intact. It does depend on the approved predicates being correct and on live isolation, protected state, anti-rollback and anti-cloning controls, key confinement, and attestation roots doing their jobs. Those implementation and hardware qualification results remain open; naming a major-vendor TEE does not establish them. Public logs, committee rotation, and resharing provide their specified protections, but they do not guarantee that every compromised computation is observable or that every copied secret expires. There is no trustless system. The specification separates administrative control, effective signing/state compromise, custody disclosure, and governance authority so each claim carries the right assumptions.
9. The Blinded Marker Aspiration
Phone sensors today cannot reliably turn the same face into exactly the same number every time across changes in lighting, age, and phone model. Comparing likenesses works with today’s sensors because it never requires an exact match.
The blinded marker of the original design remains the ultimate goal. From the first enrollment the phone also computes a one-way value from the person’s body, blinded under a key the operators hold jointly, under the stated privacy assumptions. The network keeps it beside the sealed reference, where no decision reads it, and measures it against every real enrollment decision. That produces field data, on real phones with real people, showing how often the marker misses the same person and how often it confuses two different people. If the measured rates and all required security and migration conditions qualify, a governed change can let the marker take over the duplicate check, with the sealed reference kept behind for disputes and recovery. At that point the network would no longer need to compare bodies for everyday enrollment at all, with the migration requirements determined by the admitted construction. Retiring references would require a separate governed decision and a qualified replacement for every purpose they still serve, including recovery and disputes. Marker qualification alone does not establish that the network retains no personal or linkable data.
10. Unlinkable Receipts
Each receipt is a fresh cryptographic proof. It shows that the holder has a valid credential from the network without showing the credential itself, using a BBS+ signature with a zero-knowledge proof. Every time the phone proves it holds a valid Slot credential, it produces a new, randomized proof that looks unrelated to every earlier one, so comparing ordinary proof bytes does not reveal a shared holder under the stated assumptions. Account context, metadata, and profile-specific disclosed relations remain outside that narrower guarantee.
A relying party verifies a receipt offline, against the network’s published parameters, using the required authenticated parameters and currentness evidence. It first confirms the credential proof under the published parameters. Then it compares the action in the receipt with the action it is about to accept. Last, it checks that the receipt is fresh and the permission behind it was current and in scope. The specification sets these out as nine exact steps. A receipt never contains a Slot number, a device number, or any biometric value, and ordinary receipt proofs provide no global holder identifier. A business may still know the person through its own account relationship, and the operation profile determines any purpose-specific bindings. Offline cryptographic verification does not eliminate freshness, replay, spend-state, or parameter-update requirements.
11. Leases, Epochs, and Revocation
Scoped leases are short-lived permissions. Before the phone can produce the applicable receipt, it needs a current lease covering that kind of action, such as signing in or approving a wire. The specification’s domain-lock and lease rules control concurrent authority within their defined scope. A lease alone does not prove that arbitrary high-value transactions cannot conflict, nor does it independently prevent every cloned-device attack. The relying party must enforce the relevant action, replay, and state checks along with the receipt’s permissions.
Revocation moves upstream into the leases. Many systems revoke credentials by publishing membership lists of bad ones, which grow forever and can leak information themselves. Trust Mesh revokes by refusing to issue new leases. When the relevant revocation is processed and enforced, new permissions are refused and existing permissions are bounded by the specified validity window and currentness checks. Cancellation is not instantaneous for every offline verifier. The network’s public parameters also roll forward in numbered periods called epochs, so any authority that is not renewed lapses without anyone having to chase it down.
12. Who Runs It
Validators are the institutions that check the network’s work. They form a defined, certified group, such as universities, regulated financial firms, and established infrastructure operators, spread across many countries, and each posts a bond it loses if it misbehaves. They confirm enrollments, issue leases, and finalize records. With the required enforcement intact, their authority is limited to the protocol’s permitted outputs. Defeated signing authority can certify false results within its role, but does not thereby recover an existing holder’s uncompromised phone keys.
Auditors are independent watchers. They monitor the validators, publish reports, and take part in disputes, and anyone who meets published criteria can become one without asking the network’s permission. Custody operators hold the encrypted shares of the sealed references and run the joint computations, ten at launch with the applicable seven-share threshold and protected-release requirements for custody reconstruction. That launch group grows into a larger registered pool of bonded operators, from which a public lottery draws each period’s custody committee. Custody operators carry technical duties and hold no separate policy veto. Users hold the protected keys for their direct approvals; delegated actions follow their separately authorized receipt chain, and they vote in governance one Slot, one vote.
13. Committees, the Beacon, and the Independence Graph
A public randomness beacon chooses which validators check each transaction. The beacon is a lottery whose unpredictability and bias resistance depend on its stated assumptions. A mature network might have a thousand validators, with each transaction checked by a committee of twenty-seven and sixteen signatures required to finish it. An attacker who somehow corrupted a hundred of the thousand would still face about a 1-in-1,400 chance that a given committee held even nine of them, and could not choose which transaction that committee handled. That sampling calculation is not a hardware-failure probability or a complete safety bound. Administrators with intact enforced signing paths can withhold service. An effectively compromised committee can also certify false role outputs under the relevant threshold model, although it does not obtain an uncompromised holder’s existing phone keys. Refusal follows the specified retry and failure rules; penalties require the evidence and adjudication the protocol provides.
The operator-independence graph guards against one hidden owner quietly controlling many operators that claim to be independent. Every operator publishes its ties, including its owners, its funders, and the software it runs. Anyone can challenge a missing connection with evidence, and independence is tested across the whole chain of ownership, so control hidden by a few companies still counts. Structural events, such as changes to the validator set or the rules, are stamped onto a public ledger outside the network’s own control, where the record cannot be quietly rewritten.
14. Recovery
A lost phone does not mean a lost Slot. The person installs the app on a new phone and starts the governed recovery procedure. The new phone captures their face and fingers. A quick check runs first, and if it does not settle the case, a governed comparison runs against the sealed references inside the operators’ joint computation. The result goes only to the recovery process and never to a bank or any other relying party, with the specified query limits and leakage controls; probing and compromised custody remain separate risks. Successful recovery binds to the immutable enrollment reference under the recovery predicate, gives the new phone fresh keys, and retires old authority under the defined fencing and validity rules. Ambiguous or contested cases may require review, and linked accounts retain their own rebinding and high-risk-use policies.
Catastrophic failure has a planned route back. If the network’s governance were captured or its validators failed so badly that ordinary procedures could not restore operation, a predefined procedure called the Phoenix Protocol would rebuild the validator set and the institution from verified records. It can be invoked only when ordinary governance cannot fix the problem, and its rules are written before any crisis begins.
15. Time as Security
Continuity builds up in a Slot through ordinary use over time. An attacker can try to create a fake account today, but he cannot create one with five years of continuity, because the record of when each Slot began and how long it has stayed active is anchored in public logs that cannot be backfilled. A relying party like a bank can require that only Slots older than some threshold, say one year, may wire money above a set amount, and it learns nothing else about the person beyond that time qualification. Time can add evidence of continuity under the log, state, and credential assumptions; age alone does not prove honest activity or prevent later compromise. If children were onboarded in school, by the time they reach the age of transacting in the economy, they would all have years of legitimate use continuity from engaging in school activities, which, if done as policy, could strengthen continuity-based controls, subject to evidence, inclusion safeguards, and the same security assumptions.
Scheduled refresh keeps the sealed reference current as people age and change. Each part of the reference has a published refresh schedule, and the phone warns ahead of each deadline. A Slot whose refresh is overdue loses standing until the refresh is done, and every refresh runs the full duplicate check again. Prior versions follow the specified retention rules. The immutable enrollment reference remains the recovery origin; refreshing the current approved reference does not replace it.
16. The Root
Every trust system has a root, which is the place where final authority sits. For a bank account the root is the bank, for a password manager it is the company that created the software, and for a government ID it is the agency. When one corporation or one government holds the root, a single unilateral decision could be made to freeze accounts, open the records, or shut the system down at will, and a single breach could expose everyone. A corporation also answers to its shareholders, and it can be sold, compelled, or go out of business. For a layer that billions of people and nearly every institution would depend on, any single owner is a single point of failure.
Trust Mesh distributes authority to each person at the moment they act. The power to approve an action is created on that person’s phone and spent into a receipt in the moment of transaction, so it is never pooled anywhere it could be seized. The network has no master key that reveals every holder’s existing protected phone keys. It does hold role authorities for admissions, leases, status, and records. With qualified enforcement intact, administrative capture cannot turn those into unrestricted signers; if that enforcement is defeated, false certification and state failures are possible. Relying-party controls and the specific receipt profile determine the consequences.
Decentralizing the root and requiring a supermajority vote across validators, auditors, and users for any change means no one can change the code unless it is broadly agreed upon. That single feature is why no corporation or government can control this alone. It must be a decentralized network with rules established in locked code.
17. Governance
Rules change through one path. Every proposed change is published in advance with a review period of 30 days for routine changes, 90 for structural ones, and 180 for constitutional ones, and during that time anyone can submit analysis, including the public, regulators, and researchers. When a change is approved, the rules open for exactly that one change, apply it, and lock again. Validators’ signatures count only while they run the approved software, so no operator and no foundation can quietly ship a version that weakens privacy. A version no one approved produces signatures no one honors.
Votes require agreement across three groups whose interests differ. Validators, auditors, and users each vote separately, with users voting one Slot, one vote. Routine changes need two-thirds support overall and at least half of each group. Structural changes need three-quarters support overall and at least half of each group. Constitutional changes need four-fifths within each group separately, so any one group can block them, followed by independent ratification. A small set of privacy protections sits beyond any vote at all. These rules govern the network from its first fee-bearing operation.
The public will accept a layer like this on no other terms. Citizens of democratic countries have good reason to refuse enrollment in any global system whose code they cannot inspect and whose rules a small group could quietly change. The code is published for public audit, and any attempt to weaken privacy would be visible for months before it could take effect, with users holding the votes to block it. This is public infrastructure to benefit the public.
18. The Board
The Foundation seats the parties most able to capture a system like this. Its board is designed to include the device makers whose hardware carries the network trust, governments from several countries whose interests differ, and a public-interest bloc made up of civil-liberties organizations, academic cryptographers, financial institutions, and the user constituency itself. Each of these would be a threat inside a system that could be captured, but here each keeps a check on the others.
Capturing the board buys no power to forge receipts, create Slots, or watch users because none of that authority sits with the board. The board has no protocol authority to bypass enrollment; that protection remains conditional on the admitted enrollment and enforcement assumptions. It cannot open the sealed records because the applicable custody threshold and hardware release controls govern access. It cannot change the rules quietly because every change passes through the public gate. What powerful members bring is cooperation where they already operate with device features, regulatory clarity, and adoption.
19. Lawful Process
Legal process applies through the institutions that already hold accounts. A bank still knows its customers, keeps its records, and answers subpoenas. Trust Mesh adds evidence that a specific action was approved and hides no one from their own bank or from lawful process directed at the bank.
No lookup exists to hand over. The network has no map from a receipt to a person and no search that takes a name and returns a Slot. Ordinary receipt unlinkability is scoped to the stated leakage model. Custody compromise can expose retained biometric and civil facts, but does not by itself create a map from every ordinary receipt to a person. Metadata, account records, and enrollment probing must be assessed separately. Receipts leave know-your-customer checks, sanctions screening, and suspicious activity reporting exactly where they are under existing law.
20. Inclusion and Accessibility
People without a suitable phone can enroll at a certified terminal, placed, for example, at a library, a bank branch, or a government office, or in a supervised session with a trained witness. The design includes a certified-card route for supported approvals, subject to that profile’s implementation and qualification gates. Card counting remains disabled until its proving-capability gate passes. A terminal only takes captures and passes them on. It never counts people and never approves anything. Every route feeds the same duplicate check, and receipts disclose only what their profile requires, including any required assurance distinctions, without adding an unnecessary route identifier.
People without documents, a large population worldwide, enroll through the same body check as everyone else, because uniqueness comes from the body for every enrollee. After enrollment, a Slot’s standing depends on one more step. A person who attached a government document during enrollment, or who completes a supervised capture at a witness desk, holds full standing: everyday approvals on their accounts and the counted events where one person must count exactly once. A person who did neither still holds a working Slot for their own security on the accounts they already have, but that Slot is not counted in any event requiring an exact count until the person completes the supervised step. Both full-standing routes leave the same credential, and nothing in it shows which door the person came through. The enrollment rules include accommodations for disability and limited mobility, including a head-turn path for people who cannot provide fingerprints.
21. Applications
AI agents act under delegation receipts. A person approves a delegation once, on their phone, with limits they choose, such as which accounts the agent may touch, what kinds of actions it may take, and how much it may spend. Every action the agent takes carries a receipt that chains back to that original approval. The receiving business confirms that a person genuinely approved the delegation, the agent presenting it is the one named, and that the action falls inside the limits while the delegation is still active. An agent that exceeds its limits cannot produce a valid receipt, and the person can request cancellation at any moment, with enforcement subject to the defined revocation and validity windows. Agents that hand work to other agents carry the chain forward, so every action traces back to a human. This can provide evidence about authorization and scope alongside the institution’s other controls. It does not by itself establish compliance with the EU AI Act or other legal obligations. There is no viable agent economy without a standardized way for businesses to verify in real time that the agent trying to access their system is acting for a verified user.
Verified communications let a person or an institution bind a message or call to an enrolled account and the applicable authorization profile. A brokerage customer who gets a call urging them to move funds could require a receipt bound to the instruction and to an independently established brokerage role. Enrollment alone does not prove someone is that employee: an impostor may have their own valid Slot. Not every text needs a fresh face scan; ordinary messages and consequential instructions can use different approved policies. A correctly checked receipt supplies evidence of the specified authorization and account binding, not a guarantee that the sender is truthful or uncoerced. A communications network must establish the expected sender relationship and enforce those bindings to resist cloned-voice or image impersonation.
Media provenance can bind an authorization receipt to a photo, video, or article through a C2PA profile. A governor’s office could attach evidence bound to its authenticated publishing role, and a viewer could check that binding. A forger’s own receipt would not establish that role. A receipt does not prove that media is unedited, human-created, or true: a real person can authorize synthetic content, and genuine content may lack a receipt. A reporter working in danger could publish work her newsroom vouches for without adding a public global holder identifier, within the selected profile’s privacy scope.
22. Other Use Cases
Wire and payment authorization is the clearest example. A bank or business can require a receipt from the approving officer before any transfer above a set amount. The email that imitates the CEO carries no receipt, the cloned voice on the callback cannot produce one, and the transfer waits. The protection applies at each step that requires a receipt.
Further uses follow the same pattern. Administrators approving changes to cloud systems or releasing signed software can be required to produce a receipt, so a stolen password alone cannot push malicious code into the supply chain. Doctors can attach receipts to electronic orders, so an order altered after signing fails. Remote notarization and electronic signatures can carry stronger evidence that this signer approved this exact document. A password manager or digital wallet can require a receipt before releasing a stored key, so theft of stored ciphertext alone does not satisfy the authorization requirement, subject to the vault’s own key-custody and release assumptions. Each of these is a profile that adds evidence alongside existing law and compliance programs, and legal recognition remains a decision for each regulator and jurisdiction.
23. Adoption: Coordination and Cold Start
The coordination problem arises when everyone benefits from this layer but no single institution gains enough by itself to build it because the problem is systemic. Each bank, platform, and agency faces the same fraud, and each could cut its losses with shared human authorization. But a layer one company builds for itself protects only that company, and its rivals will not route their security through a competitor. Shared infrastructure that no one is paid to build tends not to get built, even when the combined losses are enormous, but once many institutions use the same layer, the cost and the benefits even out across all of them.
Trust Mesh does not need millions of users before it is useful. A single bank can protect its high-value transfers with only its own customers enrolled, and a single newsroom can verify its reporters’ work with only its staff enrolled. The first deployments create the enrolled people and the operating record that let the next ones follow. The systemic nature of the problem is also why a mandate may eventually make sense, once evidence shows the layer works.
24. Scalability and Mandate
Commercial security products are sold by the seat or by the transaction, so they spread one customer at a time and fragment by vendor. Commercial products can be free or subsidized, but their coverage and interoperability still depend on their deployment and business model. The Trust Mesh app would be free to download because that’s not how it makes money and the standard is open, so any institution can adopt it and any person can enroll without a license. The proposed network earns revenue through small receipt fees paid by relying parties. Software companies can separately earn revenue from SDKs, integration, and customization. Adoption also depends on qualified devices and enrollment routes, integration, operator capacity, funding, and demonstrated performance.
An open standard can reach the whole population in a way a single product cannot. Once pilots show the effectiveness of this missing security layer, governments can speed adoption with tools they already have. Agency procurement rules can require receipts for high-risk federal transactions, sector guidance can recommend them for banks and payment providers, and recognized standards can let private contracts reference them. Mandates come last, after the evidence, and they build on a standard no company owns.
25. Trust Assumptions
The following summarizes major trust assumptions and residual risks; the specification’s register gives the complete, scoped obligations.
Secure hardware and its supported APIs must enforce the admitted phone profile. Protected keys are used inside the hardware boundary where the selected construction requires it; they are not described as being released into app memory on every approval. The phone’s biometric result does not independently prove the Trust Mesh local-marker check, trusted display of the action, or the origin of every camera capture. App integrity, execution-key protection, sensor provenance, and action-display binding are separate requirements. Platform attestation can support some of these properties, but each exact device, operating-system, firmware, and app configuration needs the evidence its profile requires. Attestation vendors remain named trust roots. Recovery to a supported device follows the governed recovery and account-rebinding rules. These are explicit dependencies, not guarantees inferred merely from the presence of a secure chip.
Effective compromise remains below the bound of each authority. At launch, custody disclosure requires seven actual coordinates out of ten under the applicable hardware-release model; state-machine integrity assumes at most three effectively faulty signing/state paths. The twenty-seven-member validator example retains its sixteen-signature certificate rule and its separate stated safety assumptions. Neither number means administrators may freely use intact protected keys, nor does a certificate threshold alone state every safety condition. Correlated root, vendor, software, and state failures remain relevant.
The selected cryptography holds under its actual premises. These include the BBS-family credential and threshold-signature assumptions; the separate marker and wallet-control OPRF roles; native HMAC-SHA256 PRF assumptions for selected protected-computation roles; threshold-sharing and native-computation security; and the exact proof-system assumptions. The NIST edition selects EWProofSuiteV2 for specified relations, combining encrypted witness consistency with the registered arithmetic Fiat–Shamir Bulletproof construction, with its discrete-log relation, DDH, random-oracle, generator, and setup conditions. Production setup requires the stated joint contributions and erasure conditions; it does not retain an extraction service. These are scoped mathematical premises. Implementation equivalence, resources, qualification, and broader composition remain separate obligations. Curve-based components require post-quantum replacements before relying on security against a sufficiently capable quantum adversary.
Some fraud is beyond the scope of cryptography, such as physical coercion or talking someone into sending gift cards.
The last rests on institutions rather than mathematics: that the Foundation keeps to its charter, that operators honor their bonds and answer to courts, that issuer and witness failures remain within the qualified model and are handled by the specified controls, and that lawful process stays lawful. No proof covers these, and they are assumptions that strengthen with time, as the institutions build a record.
Each open claim is entered in a public register that states why the claim is still open, what closing it would cost, and what evidence would close it. Reviewers can see where the design is proven, where it waits on measurement, and where it depends on institutions behaving well. Nothing in this overview claims more than that register supports.
26. Edge Cases and How They Are Bounded
The mathematical results apply under the assumptions and scope stated for each construction. They do not prove that all biometric captures are genuine, that a conforming app always runs, or that every implementation is secure. Administrative validator capture with intact, qualified enforcement can cause withholding; effective signing/state compromise can also permit false certifications or forks. Ordinary receipt unlinkability excludes the metadata and protocol relations listed in the disclosure inventory. Missing proofs and implementation or measurement evidence remain open in the register.
Platform vendors can help strengthen distinct boundaries. Trusted display and action binding address malware that shows one action while requesting authorization for another. Qualified capture provenance addresses whether the committed input came through the admitted sensor path. Build attestation supports software provenance but does not, by itself, establish either property or prove that a phone is uncompromised throughout execution.
Some risks remain outside cryptographic authorization. A person can be coerced or deceived into approving an action, and the authorization evidence can be genuine. Fraud involving real participants can be organized at scale. A shared vendor root, software defect, or hardware failure can affect many devices or seats, rather than only one phone. A false Slot does not automatically control someone else’s existing account, but it can matter for counted participation or wherever an institution relies on its standing. Audits have defined populations, error rates, and trust assumptions; they do not guarantee detection of every false admission, especially when their own authority is compromised. Downstream investigation or reversal depends on the service and payment method. The design aims to limit these risks, and the measurements and qualification work must establish the limits.
27. The Hardware Frontier
Build and app-integrity attestation already exist on supported platforms and can be used by third-party services. Their guarantees vary by platform, configuration, and API. Trust Mesh must qualify the exact attestation and runtime-enforcement profile it uses. A valid attestation is not universal proof that a phone remains uncompromised or that the user saw the action ultimately signed. Trusted display, capture binding, live execution enforcement, and state protection need their own evidence. A profile that requires an unavailable protection cannot silently activate without it.
Trusted-capture attestation and protected privacy-proof execution require specific supported capabilities and qualification. A camera normally supplies image data; an operating-system biometric authentication API commonly supplies an authentication result or authorizes a protected-key operation. Neither alone is a signed proof that the exact Trust Mesh capture came from a live person or that the local marker comparison was correctly performed. Phone secure hardware exposes platform-specific operations, and the selected proof computation cannot be assumed to run wholly inside it. Where proof preparation runs outside that boundary, its exposed material and dependence on the app must be included in the profile. Vendor support for protected computation and sensor/display binding could strengthen the design, but feasibility, performance, and security must be demonstrated. These are engineering and qualification requests, not capabilities established by the specification.
28. Software Supply Chain
Validator independence depends on the software as much as on the owners. If every operator ran the same program, one bug or one compromised release could affect them all at once, however independent their owners were. Trust Mesh treats the software itself as a dimension of independence, and it caps the share of operators any single implementation may run below the level at which a fault could change an outcome.
The design requires reproducible builds, so anyone can confirm that the published code is the code actually running. It requires software bills of materials listing every component and releases approved by a threshold committee and logged in public. The governed release can contain approved independent client implementations; this preserves implementation diversity without allowing operators to run arbitrary code. These practices are consistent with the NIST Secure Software Development Framework.
29. Open Work
Composability is proved only at the scope of each cited result. The selected native/state constructions retain static, sequential scope with abort; a component result does not establish arbitrary concurrent or full-lifecycle composition of the system. The system-wide concurrent and universally composable obligations remain open. The specification does not establish that closing them necessarily requires a permanently trusted, capturable setup authority. Its actual selected setup and erasure requirements must be evaluated separately. A scoped proof can still be useful, but the overview should not turn an unfinished argument into a deliberate impossibility claim.
Post-quantum migration is on the roadmap. The privacy proofs rely on mathematical problems that a large quantum computer could solve, as does most public-key cryptography in use today. The specification treats the replacement of each cryptographic building block as a defined migration path, but replacing a primitive also requires compatible constructions, proofs, migration rules, implementation, and qualification; it is not an automatic swap.
30. Measurement and Pilot
Phase 0 measures what the design depends on before anyone relies on it. The figures that matter are how often the system confuses two people or rejects a genuine one, how well it resists masks, deepfakes, and injected video, and whether those rates differ across age, sex, skin tone, phone model, and conditions like lighting. Published estimates for phone-based biometrics vary too widely to stake an infrastructure system on them. These numbers will come from direct measurement, reported by attack type and by population group, and tested against NIST’s established face recognition and presentation-attack evaluation methods.
A pilot with one relying party produces the operating evidence a NIST profile would need. A bank protecting high-value transfers, or a software organization requiring receipts for release approvals, can run Trust Mesh first in shadow mode, recording receipts beside its existing controls without depending on them, and then require receipts for a capped set of actions. Nothing in the pilot asks an institution to weaken a control it already has. The published results would tell NIST and the public whether the layer does what this overview says it does.
31. Closing
No system is perfect, and this one does not claim to be. But many systems in use today remain vulnerable to stolen credentials, even though device-bound authenticators and additional authorization controls already exist. That design leaves more openings than the cybersecurity industry can close because the problem is not solvable at the same digital level where it lives. Attackers can search a world of exposed endpoints, while defenders have to keep the relevant controls working. Deepfakes are becoming cheap enough to run at scale, and they lower the cost of impersonation. A defense built entirely in software cannot hold against that for long.
The Trust Mesh design adds person-bound authorization under explicitly stated software, hardware, and biometric assumptions. Access to an account and approval of a consequential action are gated by a living human body, confirmed on the person’s own phone, producing a receipt that any business can verify and compose with its own controls: the required authorization or delegation is bound to this action and account context under this profile and validity window. The receipts come from one universal, neutral, decentralized network that no company or government owns, and they add a layer to every existing business in every country without replacing anything those businesses already run.
No corporation or government should control this alone, just as none of them owns the internet. It is infrastructure of the same kind. The internet began as a government research project, and its missing security layer is a candidate for the same kind of start. Public funding would carry the open standard and the pilot that proves it. Everything using that standard is open to industry: software firms building the integration kits and custom tooling, phone makers gaining a reason for every regulated buyer to want their newest hardware, and a public that downloads the app for free.
The returns are not confined to fraud. The AI agent economy needs a way for a business to verify that a person stands behind an agent’s action, and receipts supply it in a way no detection system can. The same receipts verify that a message or a call came from an enrolled person’s phone, and they bind a human author to a piece of media with an authenticated publisher binding, without claiming that authorization proves the media is true or nonsynthetic. At a gate that correctly requires and verifies the applicable receipt, stolen credentials or a cloned voice alone no longer satisfy the additional authorization requirement.
Where a fraudster finds a crack, the consequences depend on the failed component and the relying party’s controls. A false Slot does not automatically open another person’s existing account, but it can undermine services that rely on unique standing. Fresh-check requirements can increase the work of abuse, while delegation, coercion, biometric error, and shared software or root failures have their own consequences. The pilot must measure effectiveness and cost. The remaining risks and open obligations are named in the specification rather than assumed to be small or uneconomic.
A more controlling government could take this design, strip out the privacy protections, and build a surveillance system the rest of the world would reject. Trust Mesh allows the US to build a global system of security that protects everyone, using supported hardware from qualified suppliers and held to public scrutiny, with published governance and privacy constraints intended to resist capture under the stated assumptions.
Here is the full specification, book, and this article as pdf with appendix: Specification, Book, Article Pdf