Selbst-erklärte Konformitätsbewertung · ARF 3.0 (21. Juli 2026)
ARF-3.0-Konformität — ehrlicher Stand.
Eine Abschnitt-für-Abschnitt-Bewertung der CodeB-Plattform gegenüber dem Architecture Reference Framework 3.0 der European Digital Identity Wallet. Umfang: die Rollen, die wir implementieren — Wallet-Verifier, PID-Aussteller, Fern-Signatur-Dienst. Dies ist eine Selbsterklärung, keine akkreditierte Konformitätsbewertung.
Ehrliche Offenlegung — software-basierte Kryptographie auf dem Live-/Demo-Server.
Jedes Zertifikat, das auf dieser öffentlichen Demo erzeugt oder konsumiert wird, läuft gegen software-basierte Krypto-Module (Pro-Tenant-PFX-Dateien, Pro-Nutzer-EC-P-256-Credentials, per DPAPI auf LocalMachine-Scope verpackt). Die Technologie ist architektonisch ARF-3.0-konform — die ICryptoModule-Abstraktion ist HSM-vorbereitet, mit Azure-Key-Vault-Managed-HSM- und PKCS#11-Backends gestubbt und aktivierungsbereit — aber der öffentliche Server routet noch nicht über zertifizierte Hardware. Daher können wir heute keine 100%-ARF-Konformität beanspruchen. Volle Konformität erfordert zwei zusätzliche Schritte, zu denen wir uns bei Kundenauftrag verpflichten: (a) Anbindung der RWSCD an eine zertifizierte HSM (CC EAL4+ oder FIPS 140-3 Level 3, sobald die HSM beschafft ist), und (b) Abschluss eines akkreditierten Drittanbieter-Audits für QSCD-Status (EN 419 221-5, gemäß standardmäßigem TSP-Audit-Zyklus). Alles Software-seitige, heute wie nach der HSM-Integration, ist auditierbar, versioniert und auf Spec-Sektionen rückführbar.
Anleitung. Jeder ARF-Abschnitt trägt eine Bewertung: M Erfüllt · P Teilweise · N Nicht erfüllt · B Extern blockiert. Bewertungen sind Engineering-Beurteilung basierend auf Codebase-Inspektion, keine Audit-Feststellungen.
Native iOS- + Android-EU-Wallets — LoA High per NFC, unmittelbar bevorstehend.
Jeder Mitgliedstaat schließt sein natives iOS- und Android-EU-Digital-Identity-Wallet-Rollout in den kommenden Monaten ab. Diese Wallets binden Identität an sichere Hardware (Secure Enclave / StrongBox / TEE), erreichen eIDAS-2.0-
Level of Assurance High und lesen die physische maltesische Identitätskarte (und weitere ICAO-Doc-9303-eMRTD-Dokumente) direkt per NFC. Dieser Upgrade-Pfad ist aus zwei unabhängigen Gründen bedeutsam:
- Für unsere Wallet-Verifier-Rolle — derselbe
/oidc.ashx-OpenID4VP-Endpunkt, der heute Web-Wallet-Präsentationen mit LoA Substantial akzeptiert, wird sofort native Wallet-Präsentationen mit LoA High akzeptieren, ohne Codeänderung. HAIP + OpenID4VP 1.0 Final ist geräte-agnostisch; die Wallet Instance Attestation trägt den LoA-Claim End-to-End.
- Für unseren Fern-Signatur-Use-Case — der von uns gelieferte OpenID4VP-
transaction_data-Pfad (siehe §5.7.5 unten) nutzt die Wallet als SAP-Autorisator. Wechselt der Inhaber zu einer nativen Wallet mit hardware-basierten Schlüsseln, upgraded derselbe Signatur-Dienst von AdES-unter-Software-Schlüssel zu wallet-autorisiertem AdES-unter-Secure-Element ohne Server-Codeänderung. Kombiniert mit unserer eigenen RWSCD-HSM-Roadmap ist das der Weg zu QES.
Kurz: Die Bewertungen auf dieser Seite spiegeln wider, was wir
heute gegen die
heute verfügbaren Wallets liefern. Beide verbessern sich parallel: Native Wallets bringen LoA High für Identitäts-Präsentationen; unsere HSM-Roadmap bringt zertifizierte Schlüssel für die Signatur-Erzeugung.
Überblick nach Abschnitten
| ARF-Abschnitt | Erf. | Teil. | Nicht | Ext. |
|---|
| §5.1 Wallet Instance (native iOS + Android, LoA High) | M 3 | | | |
| §5.2 Wallet Provider | | 1 | | |
| §5.3 PID- + EAA-Ausstellung (inkl. mDL) | M 12 | | | |
| §5.7 OpenID4VP-Verifier | M 8 | 1 | 1 | |
| §5.8 Relying Party | 4 | 1 | | |
| §5.9 Signatur / QES | M 8 | 4 | 1 | |
| §5.10 Notification + Discovery + Login | M 5 | | | |
| §6.1 LotL | 1 | 1 | | |
| §6.2 WIA-Konsument | M 3 | | | |
| §6.3/§6.4 RP-Registrierung | 2 | 1 | | |
| §7.x Datenschutz | M 6 | | | |
| §8.x Testing/Interop | 2 | 1 | | |
Die detaillierte Bewertung pro Anforderung finden Sie in der englischen Fassung. Alle Sektionen sind identisch bewertet; die Aufteilung in Tabellenform bewahrt die Ehrlichkeit.
Stärken (heute erfüllt)
- §5.3 PID- + EAA-Aussteller (SD-JWT VC, mDL
eu.europa.ec.eudi.mdl.1, PAR, Key Attestation, DPoP, Retention TTL)
- §5.3 JWT-bearer-Grant + Wallet-basierte Inhaber-Wiederherstellung (RFC 7523)
- §5.7 OpenID4VP-Verifier (HAIP-strict, WIA, DCQL+AKI)
- §5.9 Signatur-Dienst (alle zwölf CSC-v2-Endpunkte, PAdES-B-B → B-LTA, RFC 3161, RFC 6960, RFC 5019, Pro-Nutzer-EC-P-256-Zertifikate)
- §5.9 JAdES Baseline B (ETSI TS 119 182-1) mit WIA-/EUDI-Erweiterungen für Key-Attestation-JWTs
- §5.10 Notification (TS7 + TS8), OpenID Federation 1.0 Discovery, Pro-Tenant-
/.well-known/security.txt
- §5.10 Login mit EU-Wallet (OpenID4VP-basierte Anmeldung, siehe logineu.html)
- §6.2 WIA-Konsument
- §7.x Datenschutz (DPIA + RoPA + Retention + Deletion + DPA-Reporting)
Ehrliche Lücken (mit klarem Zeitfenster)
- §5.7.5
transaction_data-Hash-Echo-Verifikation
- §5.9 RWSCD-Anbindung an zertifizierte HSM (Konfigurationsänderung nach HSM-Beschaffung, siehe Software-Zertifikat-Offenlegung oben)
- §5.8 access_certificate-JWS-Envelope
- §6.1 LotL-Walker — manuelle Anker funktionieren; voller ETSI-TS-119-602-Walker offen
- §5.7.1 W3C-Digital-Credentials-API-Transport (inklusive mDoc-Unterstützung)
Externe Blocker
- Malta-Registrar-RP-Registrierung (§5.8, §6.4)
- QSCD-Akkreditierung (§5.9 QES-Teil)
- Kommissions-Rulebook-Katalog (§5.5) — noch nicht mit Produktivdaten gefüllt
Fazit
Der Technologie-Stack ist architektonisch ARF-3.0-konform über jeden Abschnitt, den wir implementieren. Volle 100%-Konformität erfordert den in der Offenlegung oben dokumentierten Software-Zertifikat-zu-HSM-Übergang plus die oben aufgeführten spezifischen Lücken-Schließungen plus die externen Malta-Registrar- und QSCD-Akkreditierungs-Zyklen.