BUILD · SDKS

There is no SDK to install. There is a checksum.

Search this repository for a publishable client library and you find none — no package on any registry, no version somebody has to keep in step with the server by hand. What you find instead is a small reference implementation, checksum-gated against the platform's own verification code so the two cannot quietly drift apart. That is not a gap this page is apologizing for. It is the design.

The wire format — a signed token over HTTP — is simple enough that a library is a convenience, never a requirement.

What is published: nothing

There is no npm install for this platform, no PyPI package, no Maven artefact. Nothing in this repository declares a publishConfig, sits in a registry's namespace, or ships a changelog of its own. If a page anywhere on this estate implies otherwise, that page is wrong and this one is not going to repeat the error to look more complete.

What exists instead: a reference you can read

A small package lives in this repository at contracts/verify-sdk — zero runtime dependencies, Apache-2.0, one function that verifies a signed verification result and a thin wrapper around three HTTP calls. It is not fetched from a registry by anyone outside this repository today. What makes it worth naming here is not distribution — it is that its verification core is a byte-for-byte vendored copy of the platform's own verifier, and a dedicated test refuses to pass if the two files ever diverge by a single byte. An integrator and the platform are made to agree about nothing by construction, rather than by two people remembering to keep two files in sync.

What it is

A verification function, read from platform/src/verify/result.ts, vendored verbatim.
A checksum test — platform/security/planted/verify-sdk-vendor-drift.test.ts — that fails the build the moment the copy and the original disagree.
A documented example flow in docs/integrator/QUICKSTART.md: open a session server-side, read the answer server-side, never trust what a browser said.

What it is not

Not published to any package registry.
Not versioned independently of the platform it is vendored from.
Not required — the same four checks it runs are described in full on how checking works, and any language can reimplement them against the vectors on the conformance page.

What the old site claims, and why this repository does not match it

The company's own developer page at orbis.id/developers — not this build, a separate deployment — states plainly that a package called @orbis-id/verifier is published on npm, Apache-2.0, and that its conformance runner needs no install: npx orbis-conformance --cmd <your-verifier>. That is a specific, checkable claim, and this repository does not carry it. What exists here is @orbis/verify-sdk — a different package name, version 1.0.0, same license, zero dependencies, and, as the section above states, not published to any registry. Searching this repository finds no orbis-conformance command anywhere.

This page does not pick a side. It is possible the published package is real, on a different deployment of the same platform, built from a different commit — the harvest itself is dated 2026-08-27, the same day as this build's own probes, and nothing here resolves which one an integrator should trust. What this page will not do is repeat the old site's claim as if it were true of this repository, or quietly drop it as if the conflict did not exist. Both facts are printed, and the difference is reported rather than smoothed over.

Why the wire format is the actual contract

The reference implementation names its signature algorithm as a literal, on purpose, rather than reading it out of the token being checked — an acceptance set decided by the token it is meant to constrain is not a check. That single design choice is the whole argument for not needing an SDK: the thing being verified is a signed JSON Web Signature over HTTP, checkable with three widely available primitives — base64url decoding, ECDSA verification, and a clock. Every language already has all three.

What is real here.

The reference implementation and its checksum gate exist and are enforced in this repository's own test suite. What does not exist is a published, installable package, in any language, from any registry.

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.

2 of the 3 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.

issuance-flow
presentation-flow

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

Can I npm install an ORBIS SDK today?: No. Nothing this platform ships is on any package registry.
Is there source code I can read instead?: Yes — contracts/verify-sdk, and it is kept honest by a checksum test rather than by a promise.
Do I need it to write my own verifier?: No. The conformance vectors are the contract; the reference implementation is one way to pass them, not the only one.
Does orbis.id/developers really say a package is published?: Yes — @orbis-id/verifier, harvested 2026-08-27. This repository is not that package, and the conflict is stated above rather than resolved.

Do not trust us. Check us.