Platform
Two primitives.
One control point.
A Key carries authority; a Gate checks it before anything happens. Everything else — how a Mandate is granted, how a Decision is made, what a Receipt proves — hangs off those two.
01 The chain
One sequence, from the person accountable
to the record of what happened.
Every part of WorldAuth sits somewhere on this line. Nothing in the system creates authority except the first step.
Identity answers who is acting.
WorldAuth answers what they are allowed to do.
02 WorldAuth Key™
Permission you can carry.
A Key shows who or what is acting, who authorised them, what they are allowed to do, where that permission applies and when it expires — and a Gate can verify what matters without the Key exposing more than necessary.
A Key is minted from a Mandate for a single request: request-bound, short-lived, cryptographically sealed. It reveals only what the Gate needs to decide — not who you are. Nothing standing exists to steal, replay or phish. Possession alone grants nothing: every presentation carries proof of possession bound to a server-issued challenge and the concrete request.
A Key is not a password and not a profile.
It is proof of permission — nothing more, and never less.
Speed
Faster access. Authorised users and systems present proof of permission without repeating the same approval process.
Scope
Clear limits. Permission applies only to the actions, places or systems you choose.
Time
Temporary access. Permission for a specific task or period, without creating permanent access.
Control
Immediate control. Permissions are changed or withdrawn when circumstances change; revocation takes effect on the next decision.
03 WorldAuth Gate™
Your business. Your rules.
When something requests access or tries to perform an action, the Gate checks whether the required permission exists. It verifies the Key locally, evaluates it against the Mandate and your policy, coordinates depleting authority when needed, and answers — deny by default.
In the protocol these are the only three decisions. Limits and conditions are obligations carried by an ALLOW, not a separate outcome. The Gate speaks a standard decision API and drops in as middleware, a sidecar, at the edge, or inside a sovereign perimeter.
A Gate, deciding
Stop treating every request the same.
Authorised actions move
Permission is clear, so the action continues. The password proved who logged in; the Gate proves what they are allowed to do.
Unauthorised actions stop
Where the permission is not there, nothing happens and the attempt is recorded. No unnecessary access, no silent over-reach.
Over-ceiling requests step up
A request above the limit is not treated as malicious. It asks the principal for legitimate additional authority before anything moves.
- 09:41:07
- Authorised supplier action · permission confirmed
Allowed - 09:41:12
- AI assistant requests a booking on a customer’s behalf · covers booking, not payment changes
Allowed, with limits - 09:41:31
- Spend request over the agreed limit · nothing moved
Step-up requested
A specimen, not production decisions. WorldAuth Gate Core is in development; see what exists today.
04 Mandates
Delegation with edges.
A Mandate is a machine-native power of attorney: a scoped grant of authority from an accountable principal.
A Mandate names the actor, the action class, the resource, the limits — amount, count, geography, time window — the expiry, and whether authority may be sub-delegated and how far. It is signed by the principal and revocable at will.
Delegation may only attenuate. A delegate can equal or narrow what it was given in every dimension — actions, resources, value, count, rate, audience, expiry and depth — and can never widen it. Every hop is checked in every dimension and the chain is rebuilt from its root; widening, chain splicing and unrelated-parent substitution are rejected.
- Who may act, and for whomActor · principal
- On what, for which actionsResource · action class
- Within which limitsValue · count · rate · geography
- For how longWindow · expiry
- How far it may be passed onDelegation depth
- Withdrawn when circumstances changeRevocation on next decision
05 Decisions and Receipts
Every consequential action leaves proof.
Each decision emits a Receipt bound to the exact request — signed, attributable, and held where it belongs.
Decided locally
Nothing phones home
The Gate verifies signed artefacts it already holds. No cloud call sits on the decision path; nothing central sees the request.
Nothing personal
What was authorised, not who
A Receipt records what was authorised — never a person’s documents, face or history. There is no ledger of who did what.
Attributable
One signed object
Ed25519 over an RFC 8785 canonical form. Any party holding the Gate’s public key can verify a Receipt; only that Gate could have issued it.
Separated
A decision is not an outcome
Deciding and doing are separate records. Decision evidence cannot be presented as proof that something was executed.
06 Two kinds of check
Some authority can be checked locally.
Some has to be coordinated.
Authority checks divide into two classes with different consistency requirements, and each runs where it belongs.
Non-consumable
Checked where the action happens
“May this agent read this record?” does not deplete. Non-consumable authority is designed for local Gate verification wherever the required status material is available.
Consumable
Coordinated before it is spent
“May this agent spend £4,200 of a £5,000 budget?” depletes. Before consuming shared bounded authority, the Gate obtains an atomic reservation, so two systems cannot independently spend the same limit.
Reserve → decide → execute → commit, with release on failure or cancellation. The Mandate defines the limit; coordination governs actual use.
07 The Assurance Firewall
Evidence informs authority.
It never becomes authority.
Identity, KYC and KYB, workload identity, KYA, capability evidence, insurance, legal authority and media provenance may all inform a decision to grant or accept authority. None of them silently widens a Mandate. That separation is the Assurance Firewall — and it is what keeps WorldAuth neutral.
| Input | What it establishes | Effect on authority |
|---|---|---|
| Identity | Who the principal or actor is, established by an external identity source you already use. | Input only |
| KYA & controls | What an operator’s controls, processes and operating practice actually look like. | Input only |
| Capability | Whether an actor is technically able to perform the action safely and within its stated envelope. | Input only |
| Legal & insurance | Accountability and financial standing behind an action. | Input only |
| Provenance | Where an artefact, model or claim came from. | Input only |
| Authority | Bounded permission delegated by an accountable principal, presented as a WorldAuth Key and decided at a Gate. | The only thing that permits |
Know Your Agent (KYA) is a question, not a certificate. It asks whether an actor is fit to be relied on for a class of action; it does not answer what the actor is authorised to do, and it is not a WorldAuth certification. WorldAuth publishes no universal assurance level, no global score and no badge that makes an agent acceptable everywhere. Status: architectural direction.
08 Boundaries
What WorldAuth is not.
Deliberate exclusions, not configuration options.
Not identity
Not an identity provider
WorldAuth works with the identity and workload systems you already run. It does not become your system of record and does not ask you to reissue identities.
Not a score
No global trust or reputation score
There is no universal ranking of people, companies or agents. Authority is specific, bounded and granted — not earned by reputation.
Not money
Not a payment network or wallet
Payment systems can be resources governed by WorldAuth authority. Money movement stays on the rails you already use.
Not surveillance
No central activity ledger
Sensitive evidence and Receipts stay under your control by default. WorldAuth is designed to know as little as it needs to.