Solidus ↔ EUDI ARF mapping
This document maps Solidus protocol features to the European Digital Identity Architecture Reference Framework (EUDI ARF) — the technical specification maintained by the European Commission for the European Digital Identity Wallet (EUDIW) under the eIDAS 2.0 regulation (EU 2024/1183 ).
Solidus is not a Member-State PID provider and does not claim EUDIW conformance. The protocol implements the same underlying standards as the ARF (OpenID4VCI, OpenID4VP, SD-JWT VC, W3C VC Data Model 2.0, W3C DIDs) so that credentials issued via Solidus are technically interoperable with EUDIW-compatible verifiers, and so that Solidus components can be deployed inside a Member-State stack as third-party building blocks. Where Solidus diverges from the ARF — most importantly on the trust framework — we say so explicitly.
What is the ARF
The EUDI ARF is a set of high-level requirements (HLRs) and technical specifications covering:
- The EUDI Wallet lifecycle (instantiation, attestation, recovery).
- The PID (Personal Identification Data) credential issued by Member-State authorities.
- (Q)EAA — (Qualified) Electronic Attestation of Attributes — third- party credentials about the holder.
- The wire protocols for issuance (OID4VCI), presentation (OID4VP), and device-bound proof of possession.
- The trust framework — registries of authorised PID/(Q)EAA issuers and relying parties under eIDAS qualified trust services.
The current ARF as of writing is version 1.x; specifics evolve. Pin to the official repository for normative text.
Standards alignment
| ARF requirement / standard | Solidus support | Where it lives |
|---|---|---|
| OpenID4VCI (issuance) | ✅ Shipped on testnet | verify-api — /v1/oid4vci/* endpoints (verify backend), oid4vci_grants table for pre-authorized code grants |
| OpenID4VP (presentation) | ✅ Shipped on testnet | auth.solidus.network — oid4vp module, oid4vp_requests table |
| SD-JWT VC (credential format) | ✅ Shipped on testnet | @solidus-network/sdk — sdjwt/ module supports issuance, holder presentation (KB-JWT), nested-path disclosure, status list / revocation |
| W3C VC Data Model 2.0 | ✅ Shipped | @solidus-network/types — validFrom / validUntil per VCDM 2.0 |
| W3C DID Core 1.0 | ✅ Shipped | did:solidus method — on-chain DID registry, full verification relationships (authentication, assertionMethod, keyAgreement, capabilityInvocation, capabilityDelegation), key rotation, controller reassignment, deactivation with spec-conformant didDocumentMetadata.deactivated |
| did:solidus method registration | ✅ Registered | w3c/did-extensions#713 — merged 2026-07-04; methods/solidus.json, "status": "registered". A registry listing, not a W3C standard or endorsement. |
| mdoc / ISO 18013-5 (alternative credential format used for EU PID) | ❌ Not shipped | Roadmap. EU PID requires mdoc; SD-JWT VC is also accepted in the ARF but mdoc is the canonical PID format. |
| SIOPv2 (Self-Issued OpenID Provider v2) | 🟡 Partial | OID4VP verifier accepts SIOP-style holder bindings via the OID4VP flow; standalone SIOPv2 flow is not separately exposed. |
| OAuth 2.0 / OIDC (Relying-Party-facing) | ✅ Shipped | auth.solidus.network — full OIDC provider with consent UI, ID Token issuance, session delegation |
Selective disclosure
The ARF requires selective disclosure for any attribute presentation. Two disclosure schemes are supported in EUDIW deployments:
| Scheme | Solidus support | Notes |
|---|---|---|
| SD-JWT VC (salted-hash disclosure) | ✅ Shipped on testnet | Per-attribute SD via _sd claim digests + holder-provided disclosures. KB-JWT for key binding. Nested-path SD supported. |
| BBS+ (cryptographic SD, multi-message signatures) | ✅ Shipped on testnet | Solidus implements BBS+ end-to-end (zkryptium 0.6 + digitalbazaar 3.0 byte-compatible). Not part of the EUDI ARF default suite, but useful for unlinkable presentations across verifiers and for credentials issued outside the EUDIW envelope. |
| mdoc selective disclosure (per-element salted hashes) | ❌ Not shipped | Tied to the mdoc credential format on the roadmap. |
| Predicate proofs (e.g., “age ≥ 18 without DOB”) via ZK-SNARKs | ❌ Not shipped | Roadmap — Groth16 circuits for age / location bounds proofs. |
Trust framework
This is the largest pragmatic divergence between Solidus and the EUDI ARF.
The ARF assumes a PKI-based trust framework: PID issuers and (Q)EAA providers operate under eIDAS-qualified trust service providers (QTSPs). Issuer authenticity is established via x.509 certificates rooted in the EU Trusted List. Verifier (Relying Party) authentication uses Relying- Party access certificates issued by a Member-State authority.
Solidus uses on-chain DID-based trust:
| ARF mechanism | Solidus equivalent |
|---|---|
| EU Trusted List of QTSPs | On-chain registry of did:solidus issuer documents with assertionMethod keys; the chain’s BFT consensus is the root of trust. |
| x.509 issuer certificate | The issuer’s published did:solidus:... document, verified against on-chain state. |
| Relying Party access certificate | OID4VP client_id resolved to a did:solidus document; relying parties can be permissioned at the application layer if a deployment requires it (no such gate is enforced at the protocol layer today). |
| Certificate revocation (CRL / OCSP) | On-chain DidDeactivate transaction immediately reflects in solidus_didResolve returning didDocumentMetadata.deactivated: true. |
| Status List for credentials | Bitstring Status List, anchored via CredentialIssue / CredentialRevoke transactions; SD-JWT VC status claim references the on-chain list. |
This divergence is deliberate: the eIDAS PKI model centralises trust on Member-State authorities and incumbent QTSPs, which is exactly what identity-as-data-product platforms (Sumsub, Okta, Worldcoin) replicate at the corporate layer. Solidus’s bet is that decentralised on-chain trust provides an equivalent or stronger guarantee with significantly lower operating cost and no privileged registrar.
A Solidus credential can be wrapped into an EUDIW-style presentation when interoperability with a Member-State verifier is required, by operating a Solidus-issued credential as an EAA under the existing EU trust framework. That path requires a partner with QTSP status — out of scope for the protocol itself.
PID alignment
The EUDI PID (Personal Identification Data) is a Member-State-issued credential containing a fixed schema: given name, family name, birth date, optional nationality, optional birth place, etc. (defined in the ARF PID data model).
Solidus issues KYC credentials (KycLevel1Credential, KycLevel2Credential,
KycLevel3Credential) which carry verification-level metadata and country
of verification, but do not map 1:1 to the PID schema. A PID-shaped
credential could be issued via the same OID4VCI pipeline by extending the
issuer’s supported credential types — no protocol-level change needed.
Wallet attestation and device binding
The ARF requires the wallet itself to be attested (proof that the wallet software meets security requirements) and credentials to be bound to a key held in a secure element / TEE on the holder’s device. This is the “high-trust” device binding model.
| ARF requirement | Solidus support |
|---|---|
| Wallet attestation | ❌ Not shipped — Solidus credentials today are bound to a holder DID, not to a wallet-instance certificate. |
| Hardware-backed key binding | ❌ Not shipped — keys are stored client-side (browser local storage or backend session for hosted flows); secure-element binding is on the roadmap when the native holder wallet ships (NLnet Commons Fund deliverable D4). |
| Wallet Trusted Application (WTA) | ❌ Not applicable until native wallet ships. |
OpenID4VCI conformance notes
The Solidus OID4VCI issuer (verify backend) supports:
- Pre-authorized code flow (the EUDI ARF default for PID and most EAA issuance).
- Credential offer via
credential_offer_uri. - Notification endpoint for credential delivery events.
- Batch credential issuance — single request returns multiple credential formats (e.g., SD-JWT VC + BBS+ JSON-LD VC for the same attribute set).
Not yet supported, relevant to full ARF conformance:
- Authorization code flow with pushed authorization request (PAR) — the ARF expects PAR-secured authorization for issuance flows that require user authentication; Solidus uses pre-authorized code today.
- Wallet-attestation-bound credential issuance — requires the wallet attestation work above.
OpenID4VP conformance notes
The Solidus OID4VP verifier (auth.solidus.network) supports:
- Presentation Definition / Submission per DIF spec.
- API-key auth on the internal verifier endpoints used by Solidus applications.
- Chain-backed DID resolution for verifying issuer signatures on presented credentials.
- SD-JWT VC as the presentation credential format.
Not yet supported:
- mdoc-cbor presentations — tied to the mdoc credential format gap.
- JWT VP (the older W3C VP-in-JWT format) — Solidus uses SD-JWT VC directly without an outer VP wrapper, which the ARF permits.
Roadmap
The remaining EUDI-relevant work, in rough priority order:
- mdoc / ISO 18013-5 credential format — required for true EU PID interoperability. Largest single gap.
- Native holder wallet (iOS + Android, React Native, Apache-2.0) — NLnet Commons Fund deliverable D4. Enables hardware-backed key binding and a clear path to wallet attestation.
- PID-shaped credential type — issue
EudiPidCredentialvia OID4VCI using the ARF PID schema, behind a partner deployment. - W3C
bbs-2023cryptosuite — bring our shipped BBS+ implementation into spec-form via the W3C Data Integrity 1.0 BBS Cryptosuites profile (NLnet Commons Fund deliverable D10). - PAR-secured authorization code flow for OID4VCI.
References
- eIDAS 2.0 (EU 2024/1183) — the EU regulation.
- EUDI ARF repository — normative architecture document.
- EUDI reference implementation — Member-State + reference wallet code, useful as a behavioural cross-check.
- OpenID4VCI — credential issuance.
- OpenID4VP — presentation.
- SD-JWT VC — credential format (IETF draft).
- W3C VC Data Model 2.0 .
- W3C DID Core 1.0 .
- ISO/IEC 18013-5 — mdoc credential format.
Document version 0.1 — 2026-05-14. Track gaps and new shipped features in todos.txt and .claude/PROGRESS_REPORT.md. PRs welcome at github.com/solidusnetwork/solidus .