Capabilities · what is real, and what is not yet
What ORBIS.ID actually does today.
Every capability this platform claims, in one table, with its real state and the method by which that state was established. Nothing on this site may assert a capability without naming an entry here — and where an entry is not live, the caveat travels with the claim wherever it is written.
10 live 5 partial 0 in build 4 planned
Why publish this
A capability page that lists only what works is a brochure. This one lists what does not work, and says so in the same words used internally. If a page on this site reads better with a capability marked live, the page changes — not the register.
How to read a state
- Live
- Implemented, deployed, and checked by the method named in its row. Safe to build against.
- Partial
- Real, but not everywhere or not completely. The row says exactly where the boundary is.
- In build
- Being built now. Some of it exists in the codebase; none of it is something you can use yet.
- Planned
- Not built. Described here so it can be discussed without being mistaken for a product.
4 of 4 live
Verification
| Capability | State | What that means | Checked |
|---|---|---|---|
| Check a credential without an account hosted-verification | Live |
Anyone can verify an ORBIS credential without registering, paying, or asking permission. How this was checked: Live probe: /verify, /verify/request and the OID4VP exchange answer unauthenticated. The verification plane carries a build-time guard that fails the build if it is ever metered. |
2026-08-03 |
| Prove your own verifier is correct conformance-vectors | Live |
Sixteen public test vectors let anyone prove their verifier accepts what it should and refuses what it should not. How this was checked: GET /conformance/vectors answers 200, CORS-open, no credential. Mutation-tested against twelve deliberately broken verifiers. |
2026-08-03 |
| A verifier library you can install verifier-sdk | Live |
A zero-dependency library that checks ORBIS credentials in Node or a browser, and performs no network calls of its own. How this was checked: Published to npm 2026-08-03 as @orbis-id/verifier (Apache-2.0). Installed from the public registry into a clean directory and run against the live vector set: 16/16 at level 1 and level 2. |
2026-08-03 |
| Revocation that does not phone home revocation | Live |
A revoked credential stops verifying, without the issuer learning where or when it was checked. How this was checked: Signed status lists served per issuer; the health probe verifies each token's signature against that issuer's own published did.json key. |
2026-08-03 |
2 of 3 live
Issuance
| Capability | State | What that means | Checked |
|---|---|---|---|
| Issue a credential over open standards vc-issuance | Live |
Issue credentials over OID4VCI as SD-JWT VC — the same wire any standards-compliant wallet already speaks. How this was checked: Live probe: /token and /credential are mounted and answer. Issuer metadata and did:web documents resolve for every configured issuer. |
2026-08-03 |
| Share one fact, not the whole document selective-disclosure | Live |
A holder can prove a single claim — over 18, licensed, employed — without revealing the rest of the credential. What is withheld is genuinely withheld: an undisclosed claim is not transmitted and cannot be recovered from what is. This is SD-JWT VC selective disclosure, which hides CONTENT. It does not make repeated presentations unlinkable — see the separate entry for that. How this was checked: SD-JWT VC selective disclosure is exercised by the conformance vectors, including a vector that fails a verifier which accepts undisclosed claims. |
2026-08-03 |
| Present the same credential twice without the two being linkable unlinkable-presentation | Planned |
Two verifiers who both saw the same credential cannot, by comparing notes, tell that it was the same holder. Not implemented, and not a property of the format in use. Every presentation of an SD-JWT VC carries the issuer signature unchanged, so two verifiers who collude can correlate presentations of the same credential. Unlinkability needs a different proof system (BBS+ or equivalent). Selective disclosure hides WHAT you showed; it does not hide THAT it was you both times. How this was checked: A property of SD-JWT VC as specified, not a deployment gap: the issuer signature is constant across presentations. Recorded after a review on 2026-08-03 found the site copy at risk of implying unlinkability. |
2026-08-03 |
1 of 2 live
Custody
| Capability | State | What that means | Checked |
|---|---|---|---|
| Signing keys held in a hardware-backed vault key-vault-custody | Partial |
Issuer signing keys live in Azure Key Vault, and the platform signs by calling the vault rather than holding the key. Two of fifteen issuers are vault-backed today (the root issuer and xaffiliate). The remaining thirteen — four real tenants and nine demonstration tenants — still hold a software key. Migration is per-issuer and requires an approval ceremony each time. How this was checked: Read from the operator keys register 2026-08-03: backend column reports azure-key-vault for 2 issuers and software for 13. |
2026-08-03 |
| Key operations need a second pair of eyes approval-ceremonies | Live |
Moving or rotating a signing key is composed by one operator and approved by another, with the whole ceremony recorded. A sole-operator override exists for small teams. It is not a silent bypass: it requires a typed confirmation phrase, writes a distinct audit event, and flags the record permanently. How this was checked: Exercised end to end on 2026-08-03 migrating an issuer to Key Vault: request, dry-run preview, approval, execution and audit entry all observed. |
2026-08-03 |
1 of 4 live
Integration
| Capability | State | What that means | Checked |
|---|---|---|---|
| Signed webhooks for credential events webhooks | Live |
Subscribe to credential events over HMAC-signed webhooks, with retries and a dead-letter queue. How this was checked: Mounted and role-gated; outbound calls route through the platform's SSRF guard, closed and tested in PR #127 and #147. |
2026-08-03 |
| Issue your own API keys self-service-keys | Partial |
A partner can mint, rotate and revoke their own API keys within limits an operator granted them. A partner signs in at /portal with a code sent to the contact email on their approved application, then mints, lists, rotates and revokes keys inside the grant an operator attached at go-live — through screens, not only an API. The tenant comes from that stored grant and is never read from the request, so a key cannot be pointed at another customer. Issuing, rotating and revoking are limited to contacts holding the Admin role, re-checked on the server rather than merely hidden in the page. What is still missing is the customer record the grant should hang off — grants are keyed by application reference today — and an operator still attaches that grant at go-live before a partner can issue anything, so this is not yet self-service end to end. How this was checked: Phase 1 merged 2026-08-03 (PR #157): 19 escalation tests, five ceilings each confirmed failing against a weakened implementation. Phase 2 (partner sessions) the same day: 21 tests, five mutations of the non-enumeration property confirmed failing. Phase 3 (routes) merged 2026-08-04 (PR #166): 18 escalation tests, all six operations in the published route inventory. The portal screens merged 2026-08-04 (PRs #181, #182, #183, #184): the session carries the contact’s ROLE and never their address, so a leaked session row names nobody. Checked live on the deployed build: two fabricated partner references both answer 202 with an identical body, so the response distinguishes no real applicant from an invented one; /api/partners/keys, /rotate and /revoke each answer 401 session_required without a session, including against a forged bearer; and every state-changing portal route (keys mint/rotate/revoke, team add/role/remove) answers 403 to a cross-site POST. |
2026-08-03 |
| Prove an integration is ready before go-live partner-certification | Partial |
A partner integration is exercised against a set of scored checks before it is allowed into production. The engine is built and wired into this deployment as an operator-run ceremony. It has not yet been run end to end against a real partner integration, so the exercises are proven by their own tests rather than by a completed run. How this was checked: Source verified 2026-08-03: registered as an approval action with both required effects threaded in the server. No completed run observed. |
2026-08-03 |
| Look up a holder by a hashed identifier holder-directory | Partial |
Find a holder without exchanging their email or phone number in the clear. Answers only where the deployment has been configured with a directory secret; otherwise it refuses rather than degrading. How this was checked: Route mounted and auth-gated; refuses with an explicit unconfigured response where the secret is absent. |
2026-08-03 |
1 of 3 live
Wallet
| Capability | State | What that means | Checked |
|---|---|---|---|
| A wallet that runs in the browser wallet-web | Live |
Holders can receive, hold and present credentials from a browser, with keys created on their own device. How this was checked: Served and reachable; device keys are generated in the browser and the private key is never transmitted. |
2026-08-03 |
| Native iOS and Android apps wallet-native | Planned |
A native app in each app store, with platform biometrics and secure-element key storage. The wallet is web-only today. There are no app-store builds. How this was checked: No app-store build exists; stated as a limitation on the developer portal. |
2026-08-03 |
| Recover your wallet if you lose your device account-recovery | Planned |
Restore your credentials onto a new device after losing the old one. Not implemented. A holder key is created on the device and never leaves it, which is what makes the custody promise real — and it is also why losing the device today means losing access to the credentials held on it. How this was checked: No recovery path exists in the wallet or the platform. Stated as a limitation on the developer portal. |
2026-08-03 |
1 of 2 live
Operations
| Capability | State | What that means | Checked |
|---|---|---|---|
| Someone is told when the service breaks uptime-alerting | Live |
Server errors, an unresponsive service and degraded response times raise an alert. Alerting only. No service-level agreement is offered, and no uptime figure is published. How this was checked: Three alert rules and a platform health check created and verified 2026-08-03 against metrics the platform already collects. |
2026-08-03 |
| Check that the running service is the published source reproducible-build | Partial |
The deployment reports the exact commit it is running so it can be compared against the source. Commit provenance is served. Signed build attestation is not available, because the registry refuses attestations for user-owned private repositories. How this was checked: GET /build returns the running commit and states the attestation gap explicitly rather than omitting it. |
2026-08-03 |
0 of 1 live
Things
| Capability | State | What that means | Checked |
|---|---|---|---|
| Identity for devices, not just people things-device-identity | Planned |
Give a device its own credential so what it reports can be trusted and attributed. Nothing is built. There is no device layer in the platform today — no device enrolment, no device credential type, no device key custody. This entry exists so the idea can be discussed publicly without being mistaken for a shipped capability. How this was checked: No device-related route, credential type or key path exists in the deployed platform as of 2026-08-03. |
2026-08-03 |
Scope
What this register does not do.
- It carries no uptime, latency or throughput figure. None is published, because none is measured for publication.
- It is not a roadmap. A planned entry carries no date, because a date nobody has committed to is a promise nobody made.
- It does not describe commercial availability. A capability being live is a statement about the software, not about whether it is sold.