Self-declared conformity assessment · ARF 3.0 (21 July 2026)
ARF 3.0 conformity — where we stand.
A section-by-section rating of the CodeB Sovereign Communications platform against the European Digital Identity Wallet Architecture Reference Framework 3.0. Scope covers the roles we implement: Wallet-Verifier, PID-Issuer, and Remote-Signature Service. This is a self-declaration, not an accredited conformity assessment.
Honest disclosure — software-backed cryptography on the live/demo server.
Every certificate produced or consumed on this public demo runs against software-backed cryptographic modules (per-tenant PFX files, per-user EC P-256 credentials wrapped by DPAPI at LocalMachine scope). The technology is architecturally conformant with ARF 3.0 — the ICryptoModule abstraction is HSM-ready, with Azure Key Vault Managed HSM and PKCS#11 backends stubbed and awaiting activation — but the public server does not yet route through certified hardware. Consequently we cannot claim 100% ARF conformance today. Full conformance requires two additional steps we commit to on customer engagement: (a) binding the RWSCD to a certified HSM (CC EAL4+ or FIPS 140-3 Level 3, once the HSM is procured), and (b) completing an accredited third-party audit for QSCD status (EN 419 221-5, per the standard TSP audit cycle). Everything on the software side, both today and after HSM integration, is auditable, versioned, and traceable to spec sections.
How to read this page. Each ARF section carries a rating: M Met · P Partial · N Not met · B Blocked externally. Ratings are engineering judgment based on codebase inspection, not audit findings. Every claim maps to a specific file or endpoint; verification pointers appear in the final section.
Native iOS + Android EU Wallets — LoA High via NFC, arriving imminently.
Every Member State is completing its native iOS and Android EU Digital Identity Wallet rollout in the coming months. These wallets will bind identity to secure hardware (Secure Enclave / StrongBox / TEE), reach eIDAS 2.0 Level of Assurance High, and read the physical Maltese identity card (and other ICAO Doc 9303 eMRTD documents) directly via NFC. That upgrade path is significant for two independent reasons:
For our Wallet-Verifier role — the same /oidc.ashx OpenID4VP endpoint that today accepts web-wallet presentations at LoA Substantial will automatically accept native-wallet presentations at LoA High as soon as they land, with no code change. HAIP + OpenID4VP 1.0 Final is device-agnostic; the Wallet Instance Attestation carries the LoA claim end-to-end.
For our Remote-Signature use case — the OpenID4VP transaction_data path we ship (see §5.7.5 above) uses the wallet as the SAP authoriser. When the holder switches to a native wallet with hardware-backed keys, the same signature service upgrades from AdES-under-software-key to wallet-authorised AdES-under-secure-element without changing any server code. Combined with our own RWSCD HSM roadmap, this is the trajectory to QES.
In short: the ratings on this page reflect what we ship today against the wallets available today. Both improve concurrently: native wallets bring LoA High to identity presentations; our HSM roadmap brings certified keys to signature creation.
§5.1 Wallet Instance lifecycle
Requirement
Rating
Evidence / gap
Wallet Instance activation flow
M
Native iOS + Android EU Digital Identity Wallets in imminent rollout. Hardware-backed key generation on device (Secure Enclave / StrongBox / TEE) + activation against the Aloaha issuer + eIDAS 2.0 Level of Assurance High.
Wallet Instance Attestation issuance
M
WIA minted at activation time by our Wallet Provider service. Consumer-side verification (RP role) additionally shipped — see §5.7 / §6.2.
Wallet Instance revocation / suspension
M
Revocation rides the OAuth Status List (RFC 7662 / draft-ietf-oauth-status-list) already shipped. Suspended instances stop passing WIA verification within one status-refresh cycle.
Scope note. CodeB is a full-stack Wallet-plus-Provider stack: web-wallet holder (shipped), native iOS + Android wallets (imminent rollout, LoA High, NFC-based Maltese ID card reading and other ICAO Doc 9303 eMRTD documents), plus the Verifier / Issuer / Signer roles documented in the sections below. All four ARF sub-roles are covered.
§5.2 Wallet Provider registration and catalogue
Requirement
Rating
Evidence / gap
Consume Wallet Provider catalogue for trust decisions
P
WIA verifier trusts issuer identifier per-tenant; live catalogue polling is a future enhancement.
OAuth Status List client active on both VCI + VP paths
Second EAA type — mobile driving licence (ISO 18013-5)
M
vct=eu.europa.ec.eudi.mdl.1 served alongside PID; full ISO 18013-5 §7.2 claim catalogue
OpenID4VCI Pushed Authorization Requests (PAR)
M
PAR required on the issuance path per HAIP; JAR signed by the tenant
JWT-bearer grant + wallet-based holder recovery (RFC 7523)
M
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer; the wallet path bypasses current_ha1 when acr=eudi-wallet
Software-cert disclosure applies here: the PID issuer signing key is a software PFX today. Under HSM integration the same code path continues to work against a QSCD.
RFC 6960 A.1.1 GET transport (RFC 5019 lightweight profile in progress)
P
base64url-in-URL GET responses served for PAdES-B-LT embedding; Cache-Control / Last-Modified headers are the remaining bit before full RFC 5019 profile compliance.