Trust registry for Open X ecosystems
Anyone can claim to be a participant. Directory is where that gets checked.
A trust registry for Open Finance, Open Insurance, Open Health — any ecosystem where institutions need to prove who they are before anyone lets them in.
/Why it exists
Every “Open X” regulation runs into the same question before anything else works: who, exactly, is allowed in this network? Usually the answer lives in a spreadsheet somewhere — updated by hand, trusted by convention, checked by phone call. That doesn't scale past the first dozen participants, and it doesn't hold up when what's at stake is people's financial data or their money.
Directory is the alternative: a registry where every participant's identity, certificates and capabilities are real, checkable and public — not filed away and taken on faith.
/Where it came from
Directory started inside a real payments pilot — connecting real institutions, across more than one country, with real transactions on the line. It needed a trust registry from day one, so it got one properly built: real PKI, real mutual TLS, real dynamic client registration — not a mock standing in for the real thing.
It turned out the problem wasn't specific to that one pilot. Any “Open X” ecosystem — Open Insurance, Open Health, whatever comes next — needs exactly the same piece of infrastructure. So Directory outgrew the program it was born in and became its own project: free to run standalone, by anyone building the next one.
/How it works
01
Prove it
Self-registration triggers a live mutual TLS request to the institution's declared dynamic client registration endpoint (RFC 7591), presenting a certificate issued by Directory's own CA and a signed software statement — plus a live GET against the institution's JWKS endpoint. Nothing is accepted on declaration alone.
02
Get listed
Once both checks pass, the institution's authorisation servers, X.509 certificates and software statements are published through a public, versioned API — the same one every other participant and any ecosystem client reads from.
03
Anyone resolves it
A single unauthenticated GET request is enough for another participant, or the ecosystem's own software, to resolve a participant's certificates and capabilities. No hardcoded allow-list, no manual lookup.
/Capabilities
Participant registry
Organisations, authorisation servers, certificates and software statements — published through a public, versioned API, not a document handed around by email.
Certificate authority
Directory runs its own CA. X.509 certificates are issued, rotated and revoked — never just declared in a registration form.
Dynamic client registration
Functional validation makes a real RFC 7591 call against each participant's declared registration endpoint before activation, alongside a live JWKS fetch.
Sender-constrained tokens
Sessions and service credentials can be bound to a client certificate's SHA-256 thumbprint (RFC 8705). Once bound, a leaked bearer token alone is not enough to authenticate.
/Who it's for
Regulators & ecosystem operators
Deploy a trust registry for an Open X program without building the underlying PKI, DCR validation and registry API from scratch.
Banks & financial institutions
Register once; certificates, authorisation servers and capabilities become resolvable by any other participant through the public API.
Developers integrating Open Finance
Resolve participant identity and capabilities through one API, instead of maintaining a hardcoded list.
Other Open X initiatives
The same trust-registry problem applies to Open Insurance, Open Health and any comparable ecosystem — the implementation is not specific to one regulation.