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 Wallet und Chips von Pass und Ausweis.
Die CodeB Wallet für Android (geschlossene Testphase) hält ihre Schlüssel im hardwaregestützten Schlüsselspeicher des Telefons. Sie liest den Chip von Reisepässen und Ausweisen (ICAO Doc 9303 eMRTD) per NFC, und der CodeB-Server prüft diesen Chip selbst: gesicherter Zugang (PACE oder BAC), Chip- oder Active Authentication und Passive Authentication gegen die CSCA-Masterliste und die Sperrlisten. Siehe
Chip-Prüfung für Reisepass & Ausweis. Ausgerichtet auf ETSI TS 119 461 v2.1.1 und ARF 3.0; nicht zertifiziert, und es wird kein Vertrauensniveau beansprucht. Die Bewertungen auf dieser Seite spiegeln wider, was wir heute liefern.
Überblick nach Abschnitten
| ARF-Abschnitt | Erf. | Teil. | Nicht | Ext. |
|---|
| §5.1 Wallet Instance (CodeB Wallet für Android) | 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 | | | |
| §5.11 Einwilligungs-Lebenszyklus (ISO 27560) | 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)
- §5.11 Einwilligungs-Lebenszyklus & Betroffenenrechte (ISO/IEC TS 27560:2023 Data Agreement Store mit Revisionen, signierte Einwilligungs-Belege, subjektbezogene Zugriffshistorie, betroffenenseitiges privacy-dashboard.html). Endpunkte
?action=da-*|receipt-*|access-log. Kochbuch: data-agreements-cookbook.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.