TRUST · STANDARDS
Thirteen standards. What each demands. What we actually answer.
A standard is a promise made by a committee, not by us. This row-by-row register says what each one requires, what the cell serving this page actually answers, and — the column most pages like this one omit — whether anyone has watched the answer happen rather than read it off a slide.
A name is not a witness.
Implementing a standard and having somebody watch you pass it are two different claims, and this site will not collapse them into one word. Five of the thirteen rows below are built and not yet witnessed end to end — the table says which, and says why, in the standard's own words rather than a euphemism for them.
The wire, the flows, and the five nobody has witnessed.
| standard | what it demands | what we answer | witnessed |
|---|---|---|---|
| W3C DID Core — did:web | an identifier that resolves to a document naming its public keys, with no registry in the middle | publishes and resolves a did:web document at the platform path. Fetched 2026-08-27 it names did:web:orbis.id and carries two verification methods — the samples elsewhere on the estate still show one, which is a defect of those samples and not of the document. /.well-known/did.json | witnessed |
| RFC 7638 — JWK thumbprint | one canonical fingerprint for a public key, so two parties naming the same key agree on its name | computes thumbprints against the RFC's own published test vector and identifies signing keys by them. /conformance/vectors | witnessed |
| RFC 9116 — security.txt | a machine-readable, unexpired route for reporting a vulnerability | publishes a contact with an expiry regenerated on every response, so the file cannot go stale-invalid. /.well-known/security.txt | witnessed |
| OpenID4VCI — issuer metadata | an issuer to publish, at a well-known path, which credentials it issues and in what format | publishes credential-issuer metadata for a live type, and the matching authorization-server metadata. /.well-known/openid-credential-issuer | witnessed |
| OAuth 2.0 — authorization-server metadata | the grant the wallet will use, described where a wallet can find it before it asks for anything | publishes authorization-server metadata covering the pre-authorized-code grant. /.well-known/oauth-authorization-server | witnessed |
| OpenAPI 3.0.3 | a machine-readable description of an HTTP API that matches the API | generates the document from the live route table on every request, so the document and the server cannot drift apart. /openapi.json | witnessed |
| IETF Token Status List | a signed, compressed bitstring a verifier fetches to learn whether one credential still stands | answers with a signed status-list token. Decoded 2026-08-27 the list inflates to 8,192 bytes carrying 65,536 single-bit entries, none of them set. The cell’s own register still records this path as unanswered; it answers. /status/1 | witnessed |
| SD-JWT VC (draft-ietf-oauth-sd-jwt-vc) | a credential format in which a holder discloses individual claims rather than the whole document | declares dc+sd-jwt as the issued format in live issuer metadata. /.well-known/jwt-vc-issuer | witnessed |
| OpenID4VCI — the full issuance flow | an end-to-end exchange that puts a credential in a holder's wallet | the flow is implemented and covered by its own suite. It is not witnessable end to end by a reader, because no reader can yet hold what it would deliver. | not witnessed |
| OpenID4VP — presentation | a verifier to request specific claims and a holder to answer with a signed presentation bound to that request | the request and response machinery is implemented and tested. No presentation from a real holder has been witnessed. | not witnessed |
| OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0 | a specific, tested combination of OpenID4VCI, OpenID4VP, SD-JWT VC and key binding, so two independent implementations interoperate without negotiating anything | every component the profile names is implemented here. The conformance suite has not been run, so the profile is not claimed — only the parts are, and each part has its own row above. | not witnessed |
| eIDAS 2.0 / EUDI Wallet architecture and reference framework | certification as a conformant issuer or relying party against the European reference architecture | built on the wire the reference architecture selects — SD-JWT VC carried over OpenID4VCI and OpenID4VP. Conformity assessment has not been undertaken. That is a decision, on the record, not an oversight. | not witnessed |
| ISO/IEC 18013-5 — mobile driving licence | the mdoc credential format and its device-retrieval protocols | not built. mdoc is sequenced last on purpose: it needs an IACA root certificate, and an IACA root cannot be re-hosted once it is issued. | not witnessed |
Read from _evidence.ts §1, each row's own evidence pointer re-probed 2026-08-27.
One standard the table above does not carry, because we fail it.
DIF's Well-Known DID Configuration proves cryptographically that a domain controls the DID
it publishes, rather than asking a reader to accept the binding on DNS alone. Probed directly
against this cell this session, /.well-known/did-configuration.json answers 404. It is not a row above because a demand this cell does not implement has no
"what we answer" to print — it is named here instead, in the same voice a live row gets.
Before you go any further.
The rows above are measured directly against the cell, not read from the capability register below — which is why the register names several of these same capabilities as absent even though the table just showed you they answer. Two different instruments, measuring two different things; neither is asked to stand in for the other.
The register underneath this section holds one row. Most of the capabilities this page just described are real and measured, and still have no register entry of their own yet — named here rather than implied.
- PLANNED A wallet a person installs from an app store. wallet-native You cannot hold a credential on a phone you own. Everything a person would do with a proof waits behind this.
The register holds 17 live · 2 partial · 2 planned · 5 not yet.
4 of the 5 capabilities this page depends on have no row in the register yet, so this page will not print a state for them. They are named rather than dropped, because a slice that silently shortens itself is the same defect as a claim with no receipt.
- did-web-anchor
- vc-issuance
- revocation
- selective-disclosure
The register route serves, but it carries no row for these yet. List what it does carry:
curl -s https://id.orbis.id/api/site/register | jq -r '.entries[].slug'Straight answers.
- Does "witnessed" mean an outside body signed off on it?
- No. That would mean a named third party ran a suite and put its own name on the result. Witnessed here means narrower and smaller: this page's own reader can fetch the endpoint and see the same answer we did. No outside body has signed off on any row on this page.
- Is the HAIP profile claimed?
- No. Every component the profile names is implemented, and each has its own row above. The profile is a specific tested combination, its own conformance suite has not been run, and printing the profile's name as a claim would be exactly the kind of rounding up this page exists to refuse.
- Why is mdoc last and unbuilt?
- It needs an IACA root certificate, and an IACA root cannot be re-hosted once issued. Sequencing it last is a decision made once, in public, rather than a gap discovered later.
Do not trust us. Check us.