Developers
Open at the edges.
Standards-first by design.
The protocol contract — Mandate, delegation, Key presentation, Gate challenge, Decision and Receipt schemas, with their conformance fixtures — is published pre-1.0. Gate middleware, SDKs and agent-framework integrations are in development.
01 What actually exists
Status, stated plainly.
Nothing on this page is an installable package today. When that changes, this table changes with it.
| Surface | What it is | Status |
|---|---|---|
| Protocol contract | Eight objects, eleven invariants, JSON Schema 2020-12, RFC 8785 canonicalisation and Ed25519 signing rules. | Published · pre-1.0 |
| Conformance fixtures | Positive, structural-negative and adversarial semantic vectors with a runnable checker. | Published · pre-1.0 |
| Gate Core | The enforcement runtime that applies the contract at request time. | In development |
| SDKs | Client libraries for issuing, presenting and verifying authority. | In development |
| Agent-framework integration | MCP and agent-framework middleware. | In development |
| Reference sandbox | The in-browser decision examples that ran on the previous site are being rebuilt against Gate Core. Until then the conformance fixtures are the runnable artefact. | Rebuilding |
| DMI Runtime | An evaluation-stage product line under the master brand: native-first execution — structured reads and bounded answers from any website for your agents, with a free sandbox and a runnable conformance kit. operator.worldauth.com | Evaluation |
8
Signed objects: Mandate, Key, Challenge, Decision, Delegation, Receipt, Status, Revocation
3
Decisions. ALLOW, STEP-UP, DENY — nothing else
RFC 8785
One canonical form; JSON Schema 2020-12 for every object
Ed25519
Signatures today; hybrid post-quantum suites on the roadmap
02 The rules that will not move
What you can build against.
Field names and wire shapes are pre-1.0 and may change before the contract is frozen. These properties will not.
Decisions
Exactly three
A Gate returns ALLOW, DENY or STEP-UP. Nothing else is a decision. A conditioned result is an ALLOW carrying obligations.
Delegation
Only ever narrower
A delegated Mandate may equal or narrow its parent in every dimension — actions, resources, value, count, rate, audience, expiry and depth. It may never widen.
Possession
Never enough on its own
A presented Key must carry proof of possession bound to a server-issued challenge and the concrete request. A stolen presentation is not a bearer right.
Failure
Never widens authority
Parser, network, clock, status or policy failure maps to a non-authorising outcome. Uncertainty never becomes ALLOW.
03 Interoperability
Adapters, not replacements.
WorldAuth profiles and integrates existing substrates rather than recreating them. AuthZEN 1.0 is an interoperability target reached through an adapter — it is not the Gate’s public outcome.
| Layer | Substrate | Position |
|---|---|---|
| Decision API | AuthZEN 1.0 — PEP/PDP interface | Interoperability target |
| Policy evaluation | Cedar and other engines | Supported, not mandatory |
| Request integrity | RFC 9421 HTTP Message Signatures | Signer attribution — not identity |
| Proof of possession | RFC 9449 DPoP | Supported substrate · Key proof of possession stays protocol-defined |
| Selective disclosure | RFC 9901 SD-JWT | Proposed Standard |
| Status & revocation | Token Status List · CAEP 1.0 / Shared Signals | Draft, monitored · external signals |
| Workload identity | SPIFFE | Identity input — never authority |
| Agent transport | MCP 2026-07-28 | Supported target |
04 The standards register
What we use, and how firmly.
This is a dependency and adapter register. Listing a standard is not a claim that WorldAuth implements it today. Each entry states the standard’s actual status, not a flattering one.
| Standard | Role in WorldAuth | Status |
|---|---|---|
| AuthZEN 1.0 | Standard interface between a policy enforcement point and a customer’s policy decision point, so customers keep their own authorisation systems. | OpenID Final · interop target |
| Cedar | Reference local policy engine with default-deny semantics. Not mandatory — another engine can be used, preferably through AuthZEN. | Supported, not required |
| RFC 9421 | HTTP Message Signatures for request integrity and signer attribution. It does not establish identity. | IETF Proposed Standard |
| RFC 9449 (DPoP) | Sender-constrained OAuth and a useful proof-of-possession substrate. WorldAuth Key proof of possession remains protocol-defined. | IETF Proposed Standard |
| RFC 9700 | OAuth 2.0 security best current practice for our OAuth-facing adapters. | BCP 240 |
| RFC 9728 | Protected resource metadata for discovery of OAuth-backed actions. | IETF Standards Track |
| RFC 9901 (SD-JWT) | Selective disclosure for evidence presented without over-sharing. | IETF Proposed Standard |
| OpenID4VP / OpenID4VCI | Presentation and issuance of verifiable credentials as assurance input. | OpenID Final |
| OpenID Federation 1.0 | Multi-party trust establishment between issuers and relying parties. | OpenID Final |
| Shared Signals / CAEP 1.0 | External security and state signals feeding revocation and re-evaluation. Not a universal kill switch. | OpenID Final |
| Token Status List | Cacheable status material for revocation. Watched, not yet depended on. | IETF draft — monitored |
| SPIFFE | Workload identity as an input to assurance. Workload identity is never authority. | Supported target |
| MCP 2026-07-28 | Agent transport and tool integration surface. | Final specification |
| A2A · AP2 | Agent-to-agent and agent-payment protocols the Gate is designed to sit in front of. | Interop targets |
| C2PA 2.4 | Content provenance as an input to DMI Evidence. | Supported target |
| Web Bot Auth | Agent identity at the HTTP layer; an input, never authority. | Interop target |
| Attenuating tokens (AAT) | Emerging work on attenuating authorisation for agent delegation chains. Adjacent to our delegation model; tracked, not adopted. | IETF draft — monitored |
Statuses verified 19 August 2026. Where a specification is still a draft we say so, and we do not build a hard dependency on it. WorldAuth invents no cryptography, no policy engine and no decision API. What it adds is the authority semantics, the Mandate model and the Gate enforcement design — and where none exists for a layer, it publishes its own specification and intends to submit it for open standardisation.
05 Machine surface
Legible to agents.
This site treats AI agents as first-class visitors. These files are the honest description of what is here; none of them is an authority endpoint and none returns decisions.
- /.well-known/worldauth — discovery document: posture, vocabulary, invariants, status, contactsJSON
- /.well-known/agent-policy.json — what agents may do here, and the identities we acceptJSON
- /llms.txt — a plain-text summary for language modelstext
- /.well-known/security.txt — where to report a vulnerabilityRFC 9116
- /robots.txt — agents are welcometext