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
ISO 18013-5 mDoc PID issuance (mso_mdoc format)
M
Second wire format for the PID: CBOR + COSE_Sign1 IssuerAuth with MSO per ISO 18013-5 §9.1.2.4. Wallets choose format via credentials[].format at the credential endpoint; both dc+sd-jwt and mso_mdoc flows return a working PID against the same tenant issuer key.
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.
vp-start ?strict_haip / ?lotl_require_chain / ?status_list_check; refused when profile is production
DCQL query language
M
Includes trusted_authorities + AKI support
Wallet Attestation (§5.11)
M
Full WIA + PoP + trust-anchor gate; wallet_attestation_required in JAR
Same-device redirect binding
M
vp_bind_<sid> HttpOnly cookie
§5.7.5 transaction_data (SCA use case)
P
Server SENDS transaction_data verbatim in JAR (shipped 2026-07-27). Server-side hash echo-back verification pending inside vp-response.
verifier_attestation client_id scheme
N
On backlog. Enhancement, not blocker.
x509_san_dns + x509_hash client_id schemes
M
Per-tenant selection, prefix-locked at vp-start
ISO 18013-5 mDoc VP-response acceptance (mso_mdoc format)
M
Full ISO 18013-5 §9 device-response verify: MSO signature check, DeviceAuth COSE_Sign1 verify against wallet-bound device key, MSO digest re-computation across disclosed IssuerSignedItems, SessionTranscript hashing per OID4VP profile.
Metadata advertises both wire formats
M
vp_formats_supported in /.well-known/openid-configuration, verifier-metadata and RP metadata all list bothdc+sd-jwt and mso_mdoc with their respective alg-value sets, so wallets can discover and choose either.
§5.8 Relying Party (Verifier)
Requirement
Rating
Evidence / gap
Emit registration_certificate in Verifier metadata
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.
Shared WebPhone.Auth.OidcRevocationStore in App_Code lets the OIDC token endpoint and the Cloud Signature Consortium sign-out endpoint mark and probe revoked access-token JTIs and refresh tokens in-process (no reentrant HTTP hop) so revocations initiated on either side are honoured on the very next token use.
§5.11 Consent lifecycle & individual rights (ISO/IEC TS 27560:2023)
Requirement
Rating
Evidence / gap
Data Agreement store (ISO/IEC TS 27560:2023) with versioned revisions
M
Shared WebPhone.Consent.DataAgreementStore in App_Code. Per-tenant flat JSON under App_Data/<tenant>/data-agreements/<da-id>.json. Atomic writes with .backup. Per-file lock table. Revision cap 200. CRUD + revision list + delete exposed via /oidc.ashx?action=da-create|read|update|delete|list|list-revisions, admin-gated (Bearer role admin/superuser or HMAC).
Signed consent receipts keyed to subject + DA revision
M
Receipts stored under App_Data/<tenant>/consent-receipts/<sha256(sub)-first16>/<da-id>.json. Each signature carries receipt_id, rev, opt_in, signed_at, revoked_at. Revoke keeps the record and flips opt_in plus stamps revoked_at per audit-trail requirements. Endpoints: ?action=receipt-sign|revoke|list.
Per-subject access log (append-only)
M
One JSONL file per (subject-hash, YYYY-MM) under App_Data/<tenant>/access-log/. Rotates on 512 KB. Read via ?action=access-log for the caller's own subject (or admin overrides). Belt-and-brace redaction drops sub/email/phone/password keys from the extra payload even if a caller supplies them.
Individual-facing privacy dashboard
M
privacy-dashboard.html (EN) + DE mirror. Self-contained single-file page — lists every consent receipt with per-row download / revoke, lists every access-log entry with download, and offers a one-click Article-17 deletion request via the existing TS7 queue.
Machine-readable consent-receipt discovery
M
OP metadata advertises data_agreement_endpoint, data_agreement_list_endpoint, consent_receipt_endpoint, consent_receipt_list_endpoint, subject_access_log_endpoint so wallets + downstream RPs can discover the lifecycle URLs without hardcoding query-string form.
Why this row matters. Data-protection authorities increasingly require a machine-readable consent receipt keyed to a versioned Data Agreement, not merely a "you clicked accept" log line. This category makes it a first-class, per-tenant, subject-visible capability. See the data-agreements cookbook to integrate it into your own app.
§6.1 Trust Anchor + List of Trusted Lists (LotL)
Requirement
Rating
Evidence / gap
LotL fetcher (ETSI TS 119 602)
P
Oidc:LotlRequireChain gate shipped, full LoTE fetcher + chain-walker pending. Manual per-tenant trust anchors work today.
Trust List signature verification
M
Signature verifier present, chained to local anchors
Both wallet rows on wallet-interop-matrix.html now show mDoc = yes end-to-end (reference wallet on the verify path; Aloaha Web Wallet on both holder + presentation paths via the browser-side CBOR + COSE_Sign1 + mDoc primitives).
WCAG accessibility assessment
M
EN 301 549 / WCAG 2.1 assessment complete
Verification pointers
Every claim above is exercised through a public endpoint on this platform. Documentation and live entry points:
§5.3 PID + EAA issuance → GET /vci.ashx?action=info credential-issuer metadata; vct=eu.europa.ec.eudi.pid.1 + vct=eu.europa.ec.eudi.mdl.1
§5.7 OpenID4VP → POST /oidc.ashx?action=vp-start, GET /oidc.ashx?action=vp-request, POST /oidc.ashx?action=vp-response
§5.7.5 transaction_data → passed to vp-start, echoed inside the signed JAR