Every number on this site, with its artifact.
This page is built from the lab artifacts themselves — suite scorecards, wire captures, theorem maps, campaign results. Each entry carries its source path and run date; the standards table and the do-not-claim register live here too. If we can't reproduce a claim on request, we don't make it.
OpenID Foundation conformance — local run, reproducible
Self-run against the official OpenID Foundation conformance suite. Every result bundle is signed by the suite's own key and archived; runs are reproducible. This is self-run evidence — not an OpenID Foundation certification; we are not listed on openid.net/certification.
| Run | Scope | Result | Status | Source artifact |
|---|---|---|---|---|
| 2026-06-01 independently reproduced 2026-06-04 |
Full suite — OID4VCI, OID4VP and OpenID Federation test plans | 319/332 passed, 0 failed 11 warnings, 2 skipped |
pass | tier3_results/oidf_conformance/SCORECARD.json [OIDF-1] |
| 2026-05-26 re-confirmed 2026-06-04 |
FAPI 2.0 Security Profile (Final) test modules embedded in the OID4VCI issuer plans | 78/80 passed, 0 failed 2 warnings |
pass | tier3_results/local_oidf_20260526_122209_mdoc_keyatt/summary.json [OIDF-2] |
| 2026-05-26 | Earlier full-suite baseline | 210/218 passed, 0 failed 7 warnings, 1 skipped |
pass | tier3_results/local_oidf_20260526_122209_mdoc_keyatt/summary.json [OIDF-3] |
| all runs | Signed result bundles — each export signed by the suite's own key and archived | archived | provenance | conformance_results/test-log-*.zip [OIDF-4] |
Tested against real wallets, on the wire
Wire-level results from lab captures. Coverage varies per wallet — each row states exactly what was tested, and nothing more. Tested against ≠ endorsed by.
| Wallet / stack | What was tested | Result | Status | Source artifact |
|---|---|---|---|---|
| walt.id wallet stack | 22 credential types, in 43 issuer configurations (SD-JWT VC and ISO mdoc formats), each issued and stored end-to-end over live OID4VCI | 22 types · 43 configs | pass | auto_research/scripts/wallet_baselines.json [WAL-1] |
| vck library (A-SIT — the engine behind the ID-Austria Valera wallet) | Presented an SD-JWT PID to the PSDP verifier over OID4VP 1.0 Final (direct_post + DCQL); PSDP verified the issuer signature and the Key-Binding JWT and accepted (2026-06-08, reproducible harness). Scope: the vck library, not the Valera app binary; dc+sd-jwt only — not JARM, not mso_mdoc | KB-JWT verified, accepted | pass | scripts/vck-vp-holder/README.md [WAL-2] |
| Wallet clients identifying as Paradym/Credo, Sphereon and Lissi | The live PSDP issuer served complete OID4VCI issuance flows (metadata → offer → token → credential, all HTTP 200), logged 2026-06-04. The log records user agents, not proof of the physical app | full HTTP-200 chains | pass | tier3_results/wallet_attempts/attempts.jsonl [WAL-4] |
| Real Android wallet apps on physical devices — Paradym, Sphereon, EUDI reference, Procivis | Captured device logs (adb/logcat) against live PSDP endpoints. Device-traffic evidence only — no completed end-to-end real-phone flow is claimed | device logs captured | partial | tier3_results/android_config_sweep_* [WAL-3] |
Formal verification — the honest count
33 protocol theorems tracked: 15 discharged (machine-checked), 18 partial. We publish the split — partial means exactly that. A theorem map without gaps is a theorem map you should distrust.
| Track | Scope | Result | Status | Source artifact |
|---|---|---|---|---|
| Theorem map | 33 protocol theorems tracked across the protocol | 15 discharged · 18 partial | partial | auto_research/knowledge/theorem_map.json [FV-1] |
| Tamarin prover (Dolev-Yao adversary) | Protocol model machine-checked across 7 theory files | 36 lemmas verified — 32 trace + 4 observational-equivalence (≈5,500 proof steps) | pass | conformance_results/EVIDENCE_PACKAGE.json [FV-2] |
| Unlinkability — discharged | Identifier-hiding (T10a), audit/verifier-split (T10d) and nullifier-unlinkability / private-presentation theorems | discharged | pass | auto_research/knowledge/theorem_map.json [FV-3] |
| Unlinkability — partial | Verifier-view unlinkability, issuer hiding and selective-disclosure privacy — modeled with machine-verified observational-equivalence lemmas but partial overall. Never "unlinkability-certified" | partial | partial | auto_research/knowledge/theorem_map.json [FV-3] |
| ZK circuit checks (circom reference circuits) | Picus (Veridise, Z3): "properly constrained"; Circomspect (Trail of Bits): "no issues found"; April 2026 evidence package. The live verify path is the arkworks Groth16 backend, not these circom artifacts | 14/14 negative-witness tests | pass | conformance_results/EVIDENCE_PACKAGE.json [FV-4] |
Organizational identity in zero knowledge — K5
A reference-grade zero-knowledge proof of vLEI role-membership: a holder proves control of a GLEIF-rooted organizational role credential without revealing the entity, LEI, or role-holder, with a per-verifier scoped nullifier (unlinkable across verifiers, rate-limitable within one). It is classical Groth16/BN254 — NOT post-quantum, uses a single-party trusted setup (demonstration-grade soundness, not a multi-party ceremony), and runs on self-minted credentials in the GLEIF test ecosystem. The vLEI/KERI ecosystem has no zero-knowledge story anywhere; this is a novel reference implementation — NOT adopted, endorsed, integrated, or used by GLEIF. [K5-1]
| What | Scope | Source artifact |
|---|---|---|
| Design spec | The K5 construction and its honest claim string | docs/superpowers/specs/2026-07-02-k5-zk-vlei-membership-design.md |
| Circuit + prover | Groth16/BN254 membership circuit (classical, single-party setup) | prover/arkworks/src/bin/psdp-arkworks-vlei-membership.rs |
| Verifier modules | Accumulator, presentation verify, live route | src/psdp_ref/vlei_zk_membership.py · src/psdp_ref/vlei_accumulator.py · src/psdp_ref/vlei_zk_route.py |
| Tests, incl. the boundary test | Circuit tests, mutation-tested tier- and nullifier-binding, and the test that proves the ZK path cannot run on real GLEIF fixtures (no role credential + no holder key) | tests/keri/test_vlei_zk_* · tests/keri/test_k5_real_gleif_boundary.py |
| Live demo | The accept + every adversarial reject, decided on this deployment | GET /vlei/zk/demo — run it on the front page |
The EU trust fabric — verified, not joined
In a dated live campaign, independently authenticates the EU LOTL against Official Journal notice C/2026/1944 (TLv6, sequence 389), evaluates all 31 national-list pointers, fetches 29 of 31, accepts 28 of 31 under strict transport, profile, freshness and exact-signer checks, and parses 4,677 service records. Separately, it walks EBSI's multi-hop accreditation chains (Trusted Issuer → TAO → Root TAO) against the live EBSI Pilot registries, fail-closed at every hop, adversarially tested (a tampered signature is rejected; an untrusted root is rejected). This is interop evidence: we VERIFY the trust fabric — we are NOT listed on any trusted list, NOT eIDAS-qualified, and NOT an accredited EBSI issuer. [TRUST-1]
| What | Result | Source artifact |
|---|---|---|
| eIDAS national trusted lists (from the live EU LOTL) | 29/31 fetched · 28/31 strict-profile accepted · 4,677 service records | pki/lotl_campaign/campaign_results-20260728T202113Z.json · pki/lotl_campaign/CAMPAIGN_REPORT.md |
| EBSI multi-hop accreditation chains (Trusted Issuer → TAO → Root TAO) | real Pilot chain verified to a pinned Root TAO; tampered TI signature rejected; untrusted root rejected | src/psdp_ref/did_ebsi.py · tests/did/test_did_ebsi_real_pilot.py |
The per-country issuer breakdown is one row per territory in
the campaign artifact itself, pki/lotl_campaign/campaign_results-20260728T202113Z.json.
Hungary is accepted with 339 records and France with 355; IE, SK and UK are the
three fail-closed results.
What's post-quantum here — and what isn't
Hybrid post-quantum key establishment (X25519 + ML-KEM-768) and hybrid issuer signatures (ES256/EdDSA + ML-DSA-65, FIPS 204) are implemented in the reference stack. [PQ-2]
PQC-hybrid authentication (ML-DSA-65) + confidentiality (ML-KEM-768). The zero-knowledge layer is classical Groth16/BN254, with a de-risked (not yet live, not yet formally sound) transparent PQ-STARK backend on the roadmap. [PQ-1] You will not find "post-quantum ZK" anywhere on this site, because it isn't true yet.
| Layer | What ships | Post-quantum? | Source artifact |
|---|---|---|---|
| Key establishment (confidentiality) | Hybrid post-quantum X25519 + ML-KEM-768, implemented in the reference stack |
hybrid PQ | src/psdp_ref/pqc_credentials.py [PQ-2] |
| Issuer signatures (authentication) | Hybrid ES256/EdDSA + ML-DSA-65 (FIPS 204), implemented in the reference stack |
hybrid PQ | src/psdp_ref/issuer_signatures.py [PQ-2] |
| Zero-knowledge proofs | The shipping ZK backend is classical Groth16/BN254 |
not PQ | docs/PQ_ZK_STATUS.md [PQ-1] |
| PQ-STARK backend (roadmap) | Transparent proving spike (hash-based, no trusted setup), de-risked: fused proof ≈73 KB, prove time ≈16 s on 2016 laptop hardware — not live, not formally sound, not production-ready | not live | docs/PQ_ZK_STATUS.md [PQ-3] |
Security posture — stated plainly
PSDP is a reference implementation; production hardening is in progress. That sentence is the ceiling — no stronger readiness wording appears anywhere on this site. [SEC-3]
| Control | What the code does | Source artifact |
|---|---|---|
| Mock-proof rejection in production | In production mode (PSDP_PRODUCTION=1) the verifier refuses mock
proofs — submissions are rejected with
mock_crypto_rejected_in_production — and startup checks enforce
production configuration before serving |
src/psdp_ref/age_verification.pysrc/psdp_ref/startup_checks.py [SEC-1] |
| Real ZK exercised in CI | Real Groth16/BN254 verification is exercised in CI: a blocking job builds the
Rust provers and runs the suite with PSDP_REQUIRE_ZK=1, so a
missing prover is a hard failure, not a silent skip |
.github/workflows/ci.yml [SEC-2] |
| Production-mode issuer trust | Fail-closed in production mode: real Ed25519 issuer-signature verification, expiry, registry/revocation status — any failure rejects — and one-time-use nullifiers persist across restarts via a file-backed replay guard. Scoped to the production layer; not a blanket "fail-closed everywhere" claim | src/psdp_ref/production.py [SEC-4] |
| Licensing — open-core | Most of the project is Apache-2.0 (open source) — protocol, PKI, verifier, trust-lists, BBS+, and prior-art crypto; a focused 16-file moat (the ZK proving + optimized verify engine, the unlinkable-presentation assembly, the PQ-STARK W-OTS+ AIR, and the packaged product modules) is Business Source License 1.1 — source-available, not open source; converts to Apache-2.0 on the Change Date | .moat-manifest · LICENSE-BSL · LICENSING.md [LIC-1] |
| Readiness ceiling | PSDP is a reference implementation; production hardening is in progress. Informed by a 2026-06-09 production-readiness audit and its ongoing remediation | 2026-06-09 production-readiness audit [SEC-3] |
Standards — the claim, the qualifier, the artifact
The rail speaks the standards the EU wallet ecosystem runs on. For each one, this table states what was actually tested and links the evidence — and where a standard's legal machinery exists (certification, eIDAS status), it says plainly that we hold none of it.
| Standard | What the evidence shows | Evidence |
|---|---|---|
| OID4VCI · OID4VP · OpenID Federation | Tested against the official OpenID Foundation conformance suite (local run, reproducible): 319/332 test modules passed, 0 failed, across the OID4VCI, OID4VP and OpenID Federation test plans. Self-run evidence — not an OpenID Foundation certification; we are not listed on openid.net/certification | tier3_results/oidf_conformance/SCORECARD.json · §01 [OIDF-1, OIDF-4] |
| FAPI 2.0 Security Profile (Final) | The FAPI 2.0 test modules embedded in the OID4VCI issuer plans: 78 of 80 passed, 0 failed (2 warnings) — local run of the official OIDF suite | tier3_results/local_oidf_20260526_122209_mdoc_keyatt/summary.json [OIDF-2] |
| SD-JWT VC · ISO mdoc | 22 credential types, in 43 issuer configurations (both formats), each issued and stored end-to-end against the walt.id wallet stack over live OID4VCI | auto_research/scripts/wallet_baselines.json · §02 [WAL-1] |
| OID4VP 1.0 Final (direct_post + DCQL), Key-Binding JWT | Austria's vck library (A-SIT / the engine behind the ID-Austria Valera wallet) presented an SD-JWT PID to the PSDP verifier; PSDP verified the issuer signature and the Key-Binding JWT and accepted (2026-06-08, reproducible harness). The vck library, not the Valera app; dc+sd-jwt only | scripts/vck-vp-holder/README.md [WAL-2] |
| WebAuthn (passkeys) | Real WebAuthn passkey step-up: a federated login (AAL1) is upgraded to passkey-bound AAL2 via a real ECDSA-P256 assertion + a same-holder possession proof; the upgraded credential is Ed25519-signed and carries faithful multi-axis assurance (IAL/AAL/FAL). The demo IdP is simulated — faithful labelling, not a certification | live step-up demo [MFA-1] |
| Zero-knowledge proofs — Groth16/BN254 (classical) | The public POST /verify/age endpoint mints and verifies a real
Groth16/BN254 zero-knowledge proof end to end, revealing no date of birth.
Reference-grade: a single-party deterministic trusted setup — not a multi-party
ceremony — checked against a 6,000,000-member issuer set (an over-18 proof is
unlinkable among ~4,920,000 adults; a reference scale, not internet-scale). A
real proof takes about 10–15 seconds |
src/psdp_ref/age_verification.py · tests/test_age_real_zk.py [AGE-ZK-1] |
The cryptographic layers, including the post-quantum boundary and its mandatory limitation, are in §06; issuer trust and licensing in §07; the trust ecosystems (eIDAS trusted lists, EBSI, GLEIF vLEI) in §04–§05. All of it is interop evidence, not eIDAS legal status — no qualified, notified, or recognized status of any kind is claimed.
Re-run it yourself
The three live proofs run on the front page, and each decides in front of you: over-18 without identity · a GLEIF-rooted role without the organization · an agent denied at its cap. Below, the artifacts behind every table on this page, by path (relative to the PSDP lab tree). The signed OIDF bundles and the vck harness include their own rerun instructions.
- Try it with your own EUDI wallet — the
standard OID4VCI issuance + OID4VP presentation flow (selective disclosure), by
QR: a demo issuer mints an EU PID (SD-JWT VC, demo data) and the verifier accepts
a presentation that discloses only
age_over_18. A per-presentation check with holder key-binding, not the cross-relying-party-unlinkable PSDP proof. [WALLET-1] - Passkey step-up — a federated login (AAL1) upgraded to passkey-bound AAL2 via a real ECDSA-P256 assertion; the demo IdP is simulated. [MFA-1]
- Payments — a reference-grade payment-flow demo. [SEC-3]
- Exact-action banking-to-network composite — two local CLI runs show an
ordinary approval with no dispatch and a synthetic risk step-up bound to one
ActionAuthorization v2. The provider is an in-process mock; this is not carrier fulfilment or CAMARA conformance. [ACTION-1]
Want the full evidence pack for a procurement file? Talk to us →
The do-not-claim register
The register of claims we refuse to make is published next to the numbers — same repository, same review gate. The short version:
- "Post-quantum zero-knowledge proofs" — the live ZK layer is classical Groth16/BN254.
- Sub-kilobyte "post-quantum" proof sizes — the honest PQ-STARK size is ≈73 KB.
- "Certified", "conformance-signed", or any published OpenID Foundation certification — we are not on openid.net/certification.
- Any eIDAS legal status — qualified, notified, or trusted-list recognition. All PKI and EUDI work is interop evidence, not legal status.
- Being listed on a trusted list, eIDAS-qualified, an accredited or registered EBSI issuer, or recognized/trusted by the EU trust framework — we only verify it.
- That GLEIF (or any GLEIF/QVI/vLEI party) uses, adopted, integrated, endorses, or is a customer of the K5 zero-knowledge proof. It is a solo reference; GLEIF is unaware of it. Never "trustless", "live GLEIF membership", or "production-secure" for K5.
- A company, customers, a team, or revenue — PSDP is a pre-incorporation, single-founder project.
- "Production-ready", "battle-tested", "enterprise-grade" — the ceiling is: reference implementation, production hardening in progress.
- "Unlinkability-certified" or "proven unlinkable in production".
- Blanket "fully open source" — the project is open-core: the rail is Apache-2.0, the 16-file moat is BUSL-1.1 (source-available, not open source).
- "All security findings fixed" or "zero known vulnerabilities".
The full claims register — every allowed phrasing, its source
artifact, and the claims rejected during audit — is published next to the numbers, at
/claims-register.