Unabhängig geprüft: CodeB stellt digitale Karten exakt nach den europäischen Standards aus und prüft sie

Der CodeB-Credential-Aussteller — die Komponente, die Karten, PIDs und Nachweise in EUDI Wallets bringt — hat die offiziellen Aussteller-Testpläne der OpenID Foundation für OpenID for Verifiable Credential Issuance 1.0 mit dem High Assurance Interoperability Profile (HAIP) 1.0 durchlaufen. Jeder Testplan endete ohne einen einzigen Fehler.

Einfach erklärt

Eine digitale Wallet auf dem Smartphone enthält zum Beispiel den Personalausweis, den Führerschein, eine Mitgliedskarte oder einen Firmenausweis. Jemand muss diese Karten sicher in die Wallet bringen: Das ist die Aufgabe eines Ausstellers. CodeB betreibt einen solchen Aussteller.

Wenn Sie die Karte später benutzen — zum Anmelden, als Altersnachweis, als Mitgliedsnachweis —, muss die Gegenseite sie prüfen: Ist sie echt, noch gültig und wirklich Ihre? Das ist die Aufgabe eines Verifiers. Auch den betreibt CodeB.

Damit das europaweit funktioniert, müssen alle Wallets und alle Aussteller nach demselben Regelwerk arbeiten — sonst ließe sich eine Karte des einen Anbieters in der Wallet des anderen nicht öffnen, wie ein Stecker, der nicht in die Steckdose passt. Diese Regelwerke sind offene, internationale Standards.

„Wir halten uns an den Standard“ auf eine Webseite zu schreiben ist leicht. Es zu beweisen nicht. Die Organisation, die diese Standards veröffentlicht, betreibt ein offizielles, automatisches Testlabor. Es spielt die Rolle einer Wallet, spricht mit dem Aussteller und prüft Hunderte Details: Gibt der Aussteller Karten korrekt aus, schützt er sie vor Diebstahl und Kopie und — genauso wichtig — lehnt er jede falsche, gefälschte oder wiederholte Anfrage ab?

CodeB hat alles durchlaufen: vier vollständige Testpläne mit je 63 Tests für den Aussteller und zwei Testpläne für den Verifier — für beide in Europa genutzten Kartenformate. Die Verifier-Tests legen CodeB außerdem gefälschte, manipulierte und widerrufene Karten vor, die abgelehnt werden müssen. Kein einziger Test ist fehlgeschlagen.

Was das für Sie bedeutet

• Ihre Karten funktionieren in den Wallets von morgen. Von CodeB ausgestellte Karten folgen denselben Regeln wie die offiziellen europäischen Identitäts-Wallets (EUDI Wallets) und sind nicht an eine App oder einen Anbieter gebunden. Wie bei jedem amtlichen Dokument muss die Gegenseite aber auch dem Aussteller vertrauen: Sein Zertifikat muss auf der Vertrauensliste stehen, die die Wallet oder der Dienst verwendet. Die Tests beweisen die technische Seite; die Vertrauenslisten entscheiden, wer akzeptiert wird.
• Schutz auf Bankniveau – geprüft, nicht versprochen. Die Tests prüfen, dass eine Karte nur vom richtigen Smartphone abgeholt werden kann, dass gestohlene oder kopierte Anfragen abgelehnt werden und dass jeder Schritt kryptografisch an die Person gebunden ist, die ihn begonnen hat.
• Keine Herstellerbindung. Weil alles offenen Standards folgt, können Sie die Wallet wechseln, den Aussteller wechseln oder CodeB auf Ihrem eigenen Server betreiben, ohne etwas neu zu bauen — nur die Vertrauenseinrichtung (welche Zertifikate akzeptiert werden) muss stimmen.
• Unabhängiger Nachweis. Das Testlabor betreibt die Standardisierungsorganisation, nicht wir. Jeder einzelne Test mit vollständigem Protokoll ist über die Links weiter unten einsehbar.

Die Begriffe auf dieser Seite, erklärt

Die technischen Details

• EUDI Wallets sprechen OID4VCI und HAIP. HAIP 1.0 ist das Hochsicherheitsprofil, auf dem die EUDI-Architektur aufbaut. Ein Aussteller, der diese Pläne besteht, kann Nachweise an jede Wallet geben, die denselben Standards folgt — ohne bilaterales Integrationsprojekt, ohne Hersteller-Plug-in. Ob eine bestimmte Wallet eine Karte annimmt, hängt trotzdem vom Vertrauen ab: Die Wallet muss dem Zertifikat des Ausstellers vertrauen (Vertrauensliste oder Registrierung), so wie der Verifier den Ausstellern vertrauen muss, deren Karten er annimmt.
• Sicherheit wird geprüft, nicht behauptet. Die Pläne prüfen Pushed Authorization Requests (PAR), PKCE, an den Absender gebundene Tokens (DPoP), Wallet-Client-Attestierung, Schlüssel-Attestierung, Besitznachweis, Nonce-Behandlung, Refresh-Token-Regeln aus dem FAPI-2.0-Sicherheitsprofil und Dutzende Negativfälle, in denen ein korrekter Aussteller ablehnen muss.
• Beide Credential-Formate. SD-JWT VC (selektive Offenlegung, JSON) und ISO/IEC 18013-5 mdoc (CBOR, die Familie des mobilen Führerscheins) haben dieselben Pläne bestanden — im wallet-initiierten und im ausstellerinitiierten Ablauf (Credential Offer).
• Unabhängig und nachvollziehbar. Die Testumgebung betreibt die Standardisierungsorganisation, nicht wir. Mit den Links unten lässt sich jede Anfrage, jede Antwort und jede Prüfung einsehen.

Mehr als 20 Jahre Erfahrung — und es zahlt sich aus

Darauf sind wir ein bisschen stolz. Aloaha entwickelt seit 2003 Signatur-, PKI- und Identitätssoftware — seit mehr als zwanzig Jahren genau in diesem Bereich. In all diesen Jahren sind wir einer Regel gefolgt, und auf ihr ist CodeB von der ersten Codezeile an aufgebaut: die veröffentlichten Standards exakt umsetzen, im eigenen Haus, ohne Herstellerbindung und ohne proprietäre Abkürzungen. Dass wir jeden Testplan dieser brandneuen Standards ohne einen Fehler bestehen, ist das Ergebnis dieser Disziplin: zwei Jahrzehnte Erfahrung plus konsequente Standardtreue zahlen sich aus. Der Testlauf hat Details gefunden, bei denen die Spezifikationen strenger sind als der Wallet-Alltag — etwa beim Umgang mit Refresh-Tokens nach FAPI 2.0, beim Ort der Zertifikatskette in einer mdoc-Statusliste und beim datenschutzfreundlichen Runden von Zeitangaben — und jedes davon wurde standardkonform behoben statt umgangen. Genau darum testen wir gegen die Referenz: Interoperabilität, auf die man sich verlassen kann, heute und mit den Wallets, die noch kommen.

Ergebnisse je Testplan

Was die Warnungen bedeuten

• Zwei zusätzliche Metadatenfelder. Die Aussteller-Metadaten enthalten zwei CodeB-Erweiterungen, die Wallets ignorieren dürfen (ob eine Karte nur auf Einladung ausgegeben wird, und Anzeigeinformationen zum Aussteller). Die Suite markiert jedes Feld, das sie nicht kennt; am Protokoll ändern sie nichts.
• TLS 1.3. HAIP empfiehlt TLS 1.3. Der Entwicklungsmandant läuft auf Windows Server 2019, dessen TLS-Stack TLS 1.2 anbietet; neuere Windows-Server-Versionen bringen TLS 1.3 mit.
• Geprüft und übersprungen. Vier Tests verlangen einen Screenshot, auf dem der Aussteller eine fehlerhafte Anfrage ablehnt; diese prüft ein Mensch statt einer Automatik. Ein Test wird übersprungen, weil CodeB bewusst einen Nachweis je Anfrage ausstellt. In den Verifier-Plänen zeigen die geprüften Tests einen Screenshot der Ergebnisseite des Verifiers, nachdem er die Testkarte akzeptiert hat.

Nachweise

Lese-Links zu den vollständigen Testplänen in der Testsuite, zehn Jahre gültig. Jeder Link zeigt alle Tests mit vollständigem Protokoll. Wir sind überzeugt, dass Transparenz Vertrauen in das EUDI-Ökosystem schafft. Deshalb veröffentlichen wir unsere vollständigen Testprotokolle und ermutigen alle Anbieter von Wallets, Ausstellern und Verifiern, dasselbe zu tun.

Details zu den Testläufen

Zuletzt aktualisiert am 02.11.2026. Verwandte Seiten: OpenID-Connect-OP-Konformität · HAIP-OID4VP-Verifier-Konformität · Verifizierte Meetings · Cyber-Resilienz