BUILD · CONFORMANCE
Four vectors. Test yourself, not us.
Point any verifier, in any language, at these vectors and prove it correct. Using our code is optional. The set is the contract.
A conformance set that only contains valid proofs tests nothing. Three of the four below are engineered to fail.
What this build actually holds
This build reads 4 vectors from
src/data/vectors.json, set version 1.0.0, last generated
2026-08-30. The sitemap entry that named this page called for sixteen; the file this
build actually reads holds four, and this page renders that number rather than the one written down elsewhere —
a count this build did not measure is not a count this build gets to print.
curl -s https://id.orbis.id/conformance/vectors | jq '.vectors | length'Every vector, what it tests, what a correct verifier must answer
| id | what it tests | what a correct verifier must answer |
|---|---|---|
| valid | A genuine credential, presented to the stated challenge, whose status bit is clear. | The whole chain is walked and accepted, exactly the disclosed claims are readable, and the withheld claim never appears. (verdict: accept) |
| revoked | The same issuer and the same signed status list, but this credential's bit has been set. | Revocation is actually read from the signed list. Signature and holder binding are still sound, so an implementation that skips the status step accepts this and is caught. (verdict: reject) |
| forged-disclosure | A genuine credential with a fabricated disclosure spliced in before the key-binding JWT — a claim the issuer never signed. | A verifier that only DECODES disclosures for display, without checking each digest is in the signed `_sd` array, shows and accepts a claim the issuer never made. (verdict: reject) |
| tampered-value | A genuine credential whose disclosed `organization` value has been altered after signing. | A verifier that trusts the disclosure bytes without re-hashing them against the signed `_sd` array accepts a changed value. (verdict: reject) |
One row accepts. The other three exist to be rejected — a verifier that accepts any of them is wrong, whatever else it gets right.
Two ways to check yourself against this set
Every one of the 4 vectors carries a verdict
your implementation must reach — that alone is the strict pass/fail bar. All
4 of them also carry either the exact
failure code a correct rejection must report, or the exact claims
a correct acceptance must disclose. Matching verdict alone tells you your implementation
does not fail this specific way; matching the reason too tells you it fails — or succeeds
— for the right one. Neither level needs any tool this platform ships; both are read
straight off the file whose length is printed above.
Why four is not a shortfall
A larger set is not automatically a better one. Each of these four vectors isolates one specific way a plausible implementation fails: skipping the status check, decoding a disclosure without checking its digest is in the signed set, and trusting a disclosed value without re-hashing it. A verifier that passes all four has closed three real gaps that the industry's usual four-check description does not name on its own. Growing the set to catch a fifth or sixth failure mode is a question for the platform that publishes it, not for this page to answer by inventing a number.
What is real here.
The vector set is generated and live-fetchable today. What is not yet true is a register row scoring each capability the vectors exercise — those rows are named below as missing rather than assumed.
- LIVE Publishes deterministic vectors a third party can recompute offline to check their implementation against ours conformance-vectors
The register holds 17 live · 2 partial · 2 planned · 5 not yet.
3 of the 4 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.
- revocation
- selective-disclosure
- key-thumbprint
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
- Are all four vectors supposed to pass?
- No. Only one —
valid— should be accepted. The other three are supposed to be rejected, each for a different reason. - Do I have to use ORBIS's own verifier to test against this set?
- No. That is the entire point — point your own implementation at it.
- Is sixteen the real count?
- No — measured this turn, the file holds four. Anywhere else on this estate that still says sixteen is stale against the file, not this page.
- Does passing these four vectors certify a verifier?
- No. It proves a verifier does not fail these four specific ways. Certification is a different, larger claim this page does not make.
- Is there a CLI this platform ships to check the reason, not just the verdict?
- No. Both levels are readable straight from the vector file's own fields — no separate tool is required to reach either one.
Do not trust us. Check us.