ORBIS.ID Open the walletWallet

Documentation · Global SSI trust — issue → verify → trust, as a service

How ORBIS.ID works.

What the platform is, the four steps from organization to cryptographic trust, how a relying party verifies a credential with no ORBIS account at all, and which standards the wire actually speaks.

This page and its siblings are written in the vocabulary of the specifications and the source documents, deliberately — they are for readers who already work in this field. The same substance in plain words, for everyone else, is on the front page.

What ORBIS.ID is

ORBIS.ID is a live, multi-tenant Self-Sovereign Identity platform. Any organization gets its own decentralized identifier (did:web), a signing key held in a cloud HSM vault — private keys never touch disk — white-label branding, and immediately issues selectively-disclosable digital credentials that any standards-compliant wallet can hold and any verifier can check, including revocation, without ever calling ORBIS.

A verifiable credential is a digitally signed attestation held in the user’s own wallet, presented selectively (share your age without your address), verifiable against the issuer’s published cryptographic identity, and revocable by signed status lists. It removes the honeypot, defeats synthesis with signatures, and gives the holder control.

The platform has three pillars:

  • The Platform — tenant-in-minutes issuer & verifier infrastructure: per-tenant did:web identity, cloud-HSM key custody, branded credential manifests, hosted verification, trust registry and signed revocation lists.
  • The Wallet — a consumer super-wallet with real device-key custody (biometric-gated, keys born and kept in the device’s secure OS key stores), an encrypted credential engine, and 13 languages with full RTL support.
  • The Trust Rail — open standards end to end, with conformance enforced in CI. No lock-in: relying parties verify with zero ORBIS account.

The four-step flow

Four steps take an organization from nothing to cryptographic trust.

  1. Step 1

    Provision a tenant

    One API call creates the organization’s decentralized identity, HSM-held signing key, branding and credential types.

  2. Step 2

    Issue credentials

    Standards-based issuance over OID4VCI: a QR credential offer is scanned by the wallet, which redeems a pre-authorized code at the token endpoint and collects an SD-JWT VC.

  3. Step 3

    Hold & control

    Credentials live in the holder’s wallet under device-key custody. The user decides what to present, to whom, every time — field by field.

  4. Step 4

    Verify anywhere

    Any relying party checks signature, issuer trust, holder binding and revocation — via SDK or hosted QR flow, no ORBIS account needed.

Verifying with zero ORBIS account

This is the property that makes the rail open rather than a walled garden: a relying party never has to hold an ORBIS account, an API key, or any protocol code to check that a credential is genuine. Everything the check needs is published, cryptographically signed, and served CORS-open to any origin.

The validation chain

Whichever route a relying party takes, the same five links are checked, in order:

  • Trust anchor — is the issuer’s decentralized identifier one you trust? It resolves publicly as a did:web document.
  • Issuer signature — does the credential verify against the key published in that document?
  • Holder binding — was this presentation signed by the device key the credential was issued to?
  • Status — is the credential still valid according to the issuer’s signed status list?
  • Nonce & audience — was the presentation made to you, in response to your challenge? (Replay protection.)

Two ways to do it

Offline — the drop-in SDK

No network dependency on ORBIS

You already hold a presentation (for example from your own OID4VP endpoint). Trust one or more issuer identities and call the verifier. It runs the same server-side validation chain the platform itself runs, so a relying party gets identical guarantees offline — and it tells you which link failed (trust, signature, binding, status, or audience), never just “invalid”.

Hosted — the public verifier

No OID4VP endpoint to run

Use the ORBIS public verifier to request a proof by QR without running any OID4VP endpoint yourself. You can bind the request to your own nonce, audience and origin, so the resulting presentation is provably meant for you. Try it at /verify.

Honesty as code

“Verified” can only be rendered after a real cryptographic round-trip — a product law enforced in code and CI, not a policy promise. If the chain did not actually complete, no ORBIS surface will tell you it did.

Standards it speaks

The standards war is over, and ORBIS.ID implemented the winners early: OpenID4VP 1.0, OpenID4VCI 1.0, W3C Verifiable Credentials 2.0, SD-JWT (RFC 9901) and the high-assurance interop profile all reached final status in 2025. The platform runs this exact stack, with conformance re-proven automatically on every deploy — 5 of 5 DIIP v5 checks, enforced in CI.

  • OID4VCI — credential issuance: QR offer, pre-authorized code, token endpoint, credential endpoint.
  • OID4VP — credential presentation: request with nonce and audience, direct_post response.
  • SD-JWT VC — the credential format, selectively disclosable field by field.
  • DCQL — the query language a verifier uses to ask for exactly the claims it needs.
  • did:web — the issuer’s public identity, resolvable by anyone over plain HTTPS.
  • Token status lists — signed, versioned revocation, served per tenant.

Standards & conformance in full

The wallet

The ORBIS Wallet is a consumer super-wallet, not an SDK or a white-label kit. Holder keys are born in the device’s secure OS key stores, biometric-gated, and zeroized after every use; the credential store is encrypted; live signature verification runs on device; and the interface ships in 13 locales including full right-to-left Arabic and Hebrew.

Open it on the web at /wallet, or step through the guided walkthrough at /wallet/inv exactly as a person would.

Stated plainly

The wallet is web-only today. There are no native app-store builds yet, account recovery is not yet implemented, and hardware-enclave custody is designed as a drop-in swap — not shipped. Demo surfaces inside the wallet are labeled as demos, in-app, by a code-enforced disclosure ledger.

Compliance operations

GDPR operations ship inside the product rather than as a separate procurement: data-subject access requests with an export bundle, verified erasure, retention rules per data class, records of processing, an incident register with the 72-hour clock, and role-separation attestations. Every privileged action lands in an append-only audit log, and high-risk operations pass an approvals ladder.

Regulations, GDPR operations and the compliance clock

Live, built & gated, planned

Consistent with the platform’s honesty law, capabilities are always labeled by state. This is the position as of 29 July 2026, as recorded in the platform documents.

Live in production
  • Tenant provisioning in minutes — identity, HSM-held signing key, branded manifest and palette.
  • Credential issuance over OID4VCI with QR offers and selective disclosure; 3 credential types live, including one provisioned partner tenant.
  • The full verification loop — request, wallet presentation, validation, revocation check — exercised live on production with caller-supplied nonce/audience binding.
  • Hosted verify + drop-in SDK; relying parties verify with zero account and zero protocol code.
  • Trust registry & revocation: signed issuer directory, signed versioned status lists per tenant.
  • Operator console and back office with role-based access, an approvals ladder, append-only audit, key rotation, health and drift checks.
  • Compliance suite: DSAR export, verified erasure, retention rules, records of processing, incident register.
  • Consumer wallet (web) with real device-key custody and 13 locales including RTL.
Built & gated (activation-ready)
  • Business-event deposit rail — external systems post events; ORBIS mints verified attestations into holders’ wallets. Built and tested, awaiting first external caller.
  • Webhook event plane — HMAC-signed, retried, dead-lettered; 10 event types.
  • Sealed 1:1 E2EE calls — production-grade engine, tested, enabled in a controlled build profile; relay live (EU-hosted), provably content-blind.
  • Credit-credential spine — typed money claims with per-element disclosure, merged and hardened, held behind kill-switches until partners and audits land.

What is not yet true

  • Pre-revenue, pre-scale. No revenue, user counts or credential volumes are claimed; one production tenant is provisioned — a sibling platform, not an external customer.
  • Single-region, lean infrastructure. The platform runs on a single cloud app with SQLite storage; the Postgres/Redis migration is the highest-leverage roadmap item.
  • Identity verification is not production-grade yet. KYC capture today is a demonstration around one real issuer round-trip; a production IDV provider is a later milestone.
  • No money moves. All financial rails are inert by design behind owner-gated kill-switches until licensing, audits and partners are in place.
  • Integrations are staged. xNEXT is integration-ready, not integrated; webhooks await their first live subscriber; pen-test, GDPR audit and SOC 2 are scheduled, not done.

Surfaces & routes

Every public surface of this deployment, and who each is for.

Public validation /verify

Request a proof by QR and watch the whole chain check out. No account.

 ORBIS Wallet /wallet

The consumer wallet on the web — device-key custody, 13 languages.

 Identity Console /console

Issue, verify and manage credentials, types, trust and revocation.

 Administration /admin

Back office: operations, tenants, people & access, compliance.