Open-source identity infrastructure · pre-pilot

Identity built to be checked, not trusted.

Polaris issues identity credentials signed with ML-DSA-65 and verifies them offline, against published keys, with no server and no network. Its OpenID4VP verifier, polaris-oid4vp 1.0.0rc7, is OpenID Certified to the OpenID4VP 1.0 + HAIP 1.0 Verifier profile, and wallets nobody here wrote have presented to it.

Check it in one minute Read what it is not

OpenID CertifiedOpenID4VP 1.0 + HAIP 1.0 verifier, rc7
6 independent walletsunmodified, presented and accepted
IETF SD-JWTlisted among the implementations
Apache-2.0on PyPI and npm

One minute, from an empty folder.

Do not take this page's word for anything. The script below installs the verifier from PyPI, every dependency checked against a pinned hash. It runs eudi-dev, a wallet nobody here wrote that the OpenID Foundation lists as certified, has it present a credential, then sends three tampered presentations that must each be refused.

It needs python3 and a free port. Docker is optional.

The ten-minute version, step by step Tell us where it broke

$ mkdir polaris-quick && cd polaris-quick
$ r=https://raw.githubusercontent.com/EgorKhaklin/polaris-id/main
$ curl -fsSLO $r/lab/interop/eudi-dev/run.sh
$ curl -fsSLO $r/lab/interop/waltid/issue_sdjwt_vc.py
$ curl -fsSLO $r/lab/interop/requirements.txt
$ bash run.sh
wallet     ghcr.io/dominikschlosser/eudi-dev:v2.3.7
installed  polaris-oid4vp 1.0.0rc16
== genuine presentation
  ok    the verifier accepted it
          <- 200 authentic
== control (b): the same request again, after it was answered
  ok    refused at the request stage
== control (c): a launch URI whose client_id is not the signed request's
  ok    the wallet refused the request
== control (a): the verifier trusts a different issuer key under the same kid
  ok    the verifier refused the issuer
RESULT: accepted, and all three controls refused

Recorded 5 October 2026 on macOS with the system Python 3.9: 13 seconds, from an empty folder. Abridged: the full output also shows each step's request and answer.

What other people's software did with it.

Everything else on this page is the project describing itself. These are the results that are not. The authors of that software took no part in the runs, though this project has written to some of them: two fixed a defect reported from here, and later runs re-test the fix. Every run carried controls that had to be refused, because a verifier that accepts everything prints the same success line.

Wallets, unmodified

walt.id Wallet APIKotlin
CredoTypeScript · OpenWallet Foundation
eudi-devGo · OpenID Certified wallet
OID4VCgoGo · OpenID Certified wallet
ProtocolSoupGo · OpenID Certified wallet
Procivis One CoreRust

Libraries, services and test tools

EUDI Wallet OpenID4VP libraryKotlin · European Commission
EUDI Wallet OpenID4VP librarySwift · European Commission
EUDI PID issuerEuropean Commission reference issuer
vckKotlin · A-SIT Plus
MultipazKotlin · OpenWallet Foundation
irmagoGo · Yivi
AxleKotlin · driven by a harness written here
openid4vpRust · SpruceID conformance adapter
ERICATypeScript · verifier testing tool

Dated runs, versions, controls and transcripts: the scoreboard, 15 September to 10 October 2026.

OpenID® Certified™ by Egor Khaklin to the OpenID4VP 1.0 + HAIP 1.0 Verifier profile: polaris-oid4vp 1.0.0rc7, 24 September 2026 (listing). A self-certification the OpenID Foundation approved and lists: not an endorsement, not an audit, and not a certification of the rest of Polaris. OpenID® and OpenID® Certified™ are trademarks of the OpenID Foundation, used under its certification terms.

The scoreboard keeps its zeros

Outside users: 0
Pilot: none
Independent security review: none
Findings from outside: 2, both fixed

A listing is not use, and a download is not a person. These rows change only when a named outside party does something, on a date, that can be pointed at.

III

How it works.

Issue
An authority issues a credential and signs it with ML-DSA-65 under its registered key. Which algorithm signed it is data, not code: algorithm agility under an audited migration path.
Hold
The person holds it, in a wallet over OpenID4VP or as a signed pack, and chooses what to disclose. In zero-knowledge mode the verifier learns no credential identifier at all, so the issuer cannot link where it was shown.
Verify
Anyone checks it two ways. Authenticity is offline: the standalone verifier checks the signature against published keys, with no database and no network. Authorization, whether it counts right now, comes from a relying-party API or a short-lived signed status assertion.

pip install --pre polaris-oid4vp pip install --pre "polaris-verify[cryptography]" pip install --pre polaris-sdk-python npm install polaris-sdk-ts@next

The rules live in the database.

A rule enforced by a trigger, a CHECK constraint or a unique index binds every client and survives every restore. The constitutional guarantees sit there, not in application code, and each is pinned by a check that fails the build if it stops being true.

Guarantee	Where it is enforced
The audit of record is append-only	A trigger on every audit table; the application role cannot reach the purge path
A zero-knowledge verification stores no credential identifier	A two-way CHECK constraint on the verification table
One active credential per person	A partial unique index
Disclosure is decided by the server, not the caller	The form handler, the CHECK above and every read path
Identity is not money	Structural absence: no monetary table or column exists

Coercion

A second code yields a verification that looks identical and quietly records a duress event. Duress-aware, not a defence against everyone: it works on a coercer who does not know the mechanism exists, and the lab measured where it does not.

Total loss

A person who loses every device is recovered through three independent channels, a cool-down and a witness from another authority, never by one operator.

Algorithm migration

Credentials can carry an old and a new signature while an authority moves between algorithms, with a database rule that exactly one is active. Whether ML-DSA itself holds is mathematics, not a property of this repository.

What it is not.

Not production-ready. It has never held real identity data; it runs on notional data.
Not audited. No independent security review has happened yet.
Not piloted, not deployed. No authority operates it and no outside operator has run it.
Not certified as a whole. One package version is certified to one profile.

What remains cannot be built here: the legal basis, key custody, the retention schedule a regulator signs, and an independent penetration test belong to the organization that deploys it. The bound on every claim on this page, including what a break of the underlying lattice problem would and would not cost, is the readiness ledger.

Where to start.

Building a wallet or a verifier polaris-oid4vp An OpenID4VP 1.0 + HAIP verifier for SD-JWT VC, as a library or a server. Accepting credentials The SDKs and the offline verifier Python and TypeScript, checked against published keys with no network. Assessing it for an authority The constitution and the ledger The ten guarantees, what may never be built, and what is not done. Trying to break it Security policy and red-team scope How to report, what is in scope, and the response window.

Run the whole stack locally: installation · system map · API · roadmap