EU-Digital-Identity-Wallet · Architektur
CodeB deckt die ganze Kette der Europäischen Digitalen Identitäts-Wallet ab: vom Lesen des Pass-Chips bis zur Ausstellung der PID, von der Wallet auf dem Telefon bis zur Website, die danach fragt, von der Signatur bis zu ihrer Prüfung. Klicken Sie auf einen Kasten oder spielen Sie einen Ablauf ab.
ARF 3.0 · OpenID4VCI 1.0 · OpenID4VP 1.0 · HAIP 1.0 · SD-JWT VC · ISO mdoc · ETSI TS 119 475 · ICAO 9303
Wählen Sie einen Ablauf: Das Bild hebt die beteiligten Bausteine hervor, die Schritte darunter führen hindurch.
Klicken Sie auf einen Kasten für Details. Pfeile zeigen, wer wem was schickt. Auf kleinen Bildschirmen das Bild seitlich wischen.
Dieselben Bausteine wie im Bild, als Liste.
Vertrauensanker, gegen die jede Seite prüft: die EU-Liste der Vertrauenslisten für Aussteller und Wallet-Anbieter sowie die Masterliste der Behörden, die Pässe und Ausweise signieren (mit ihren Sperrlisten). Wird automatisch aktuell gehalten. Mehr →
Jeder Nachweis und jede Wallet verweist auf einen Eintrag in einer Statusliste. Geht ein Telefon verloren oder wird ein Nachweis zurückgezogen, kippt das Bit, und jede vertrauende Partei sieht es bei der nächsten Prüfung – ohne zu erfahren, wer sonst geprüft wurde. Mehr →
Vertrauende Parteien signieren jede Wallet-Anfrage mit einem Zugangszertifikat und hängen ein Registrierungszertifikat an, das genau die registrierten Daten nennt. Die Wallet zeigt Name und Zweck und lehnt Anfragen ab, die mehr verlangen. Mehr →
Die Person hält Pass oder Ausweis an das Telefon. Der Chip wird per NFC gelesen und auf dem Server geprüft: Chip-Authentisierung und die Signaturkette bis zum ausstellenden Staat. Grundlage für ein Onboarding auf hohem Vertrauensniveau. Mehr →
Stellt Nachweise per OpenID for Verifiable Credential Issuance in Wallets aus: SD-JWT VC und ISO mdoc, an einen Schlüssel der Wallet gebunden, mit einem Statuslisten-Eintrag je Nachweis. Mehr →
Personenidentifizierungsdaten (PID), mobiler Führerschein, Lichtbildausweis, Mitglieds- und Mitarbeiterkarten, NFC-Zutrittskarten für Türen, NFC-Speicherkarten und PKI-Karten (beschreibbar und nur lesbar), die das Telefon zur Smartcard machen. Jeder Nachweis gibt nur preis, was die Person freigibt. Mehr →
Die Wallet auf dem Telefon: bewahrt die Dokumente der Person auf, fragt vor jeder Weitergabe (wer fragt, wozu, genau welche Daten; PIN oder Fingerabdruck), zeigt Dokumente vor Ort per QR-Code oder NFC, prüft Ausweis oder Alter anderer, signiert PDFs, öffnet Türen, liest Pass-Chips, arbeitet am PC als Smartcard, verwaltet Einmalcodes und erstellt eine verschlüsselte Sicherung. Die Schlüssel liegen in der sicheren Hardware des Telefons. Mehr →
Bestätigt Ausstellern und vertrauenden Parteien, dass eine Wallet eine echte, aktuelle CodeB Wallet auf einem intakten Telefon ist (Wallet-Instanz-Attestierung) und dass ihre Schlüssel hardwaregeschützt sind (Schlüssel-Attestierung). Ein verlorenes Telefon wird hier gesperrt. Mehr →
Bewahrt die PID-Schlüssel auf dem Server statt auf dem Telefon auf. Das Telefon beweist, dass es die registrierte Wallet ist, und die Person beweist die Wallet-PIN; Fehlversuche zählt der Server. Eine neue PIN oder ein neues Telefon behält dieselben Schlüssel, die PID bleibt gültig.
Eine Wallet, die im Browser läuft: für Menschen ohne geeignetes Telefon und für die Arbeit am Desktop. Dieselben Nachweise und Protokolle wie die App. Mehr →
Eine gemeinsame Wallet für eine Organisation: Mehrere Personen verwalten Unternehmensnachweise, signieren im Namen des Unternehmens und legen Unternehmensdaten gegenüber Partnern und Behörden vor. Mehr →
Fragt Wallets nach genau den Daten, die ein Dienst braucht, prüft die Antwort kryptografisch, gegen die Vertrauenslisten und die Statuslisten, und gibt das geprüfte Ergebnis an den Dienst. Mehr →
Websites und Apps binden sich per Standard-OpenID-Connect an und erhalten die geprüften Wallet-Daten als ID-Token. Passkeys und Passwörter laufen über dieselbe Anmeldung. Mehr →
Spricht im Auftrag vieler kleinerer vertrauender Parteien mit Wallets. Jede erscheint in der Wallet trotzdem unter eigenem Namen und Zweck, mit eigenem Registrierungszertifikat, das den Intermediär nennt. Mehr →
Ein PDF mit der Wallet signieren oder andere per QR-Code signieren lassen. Die Wallet signiert per Fernsignatur mit dem CodeB-Signaturdienst über die API des Cloud Signature Consortium oder mit der eigenen Signaturkarte der Person; Zeitstempel (RFC 3161) und Zertifikatsstatus (OCSP) kommen aus der eigenen Installation. Mehr →
Jede und jeder kann einen Nachweis oder eine Vorlage prüfen: Signatur, Aussteller, Schlüsselbindung und Status. Dieselben Prüfungen laufen im Prüfer. Mehr →
Vorlagen für die Datenschutz-Folgenabschätzung und das Verzeichnis der Verarbeitungstätigkeiten, ein Datenschutz-Cockpit für die Person, Löschanfragen an vertrauende Parteien und Audit-Logs auf jeder Seite. Nirgends Tracker. Mehr →
Selbst erklärte Konformität, nicht zertifiziert. Im Testmodus ausgestellte Nachweise dienen nur Tests.
Nein. Jeder Baustein arbeitet auch allein mit anderen standardkonformen Wallets, Ausstellern und vertrauenden Parteien. Eine Website, die nur die Anmeldung mit der Wallet will, braucht das Relying Party Gateway oder den Intermediär; ein Aussteller nur den Aussteller.
Ja, soweit diese denselben offenen Standards folgen (OpenID4VCI, OpenID4VP, HAIP, SD-JWT VC, ISO mdoc) und denselben Listen vertrauen.
Standardmäßig in der sicheren Hardware des Telefons. Für die PID können sie auch im entfernten Schlüsselspeicher auf dem Server liegen, geschützt durch das Telefon und die Wallet-PIN.
Ja. Jeder Baustein läuft in Ihrer eigenen Installation in der EU, ohne Datenbank und ohne Tracker Dritter; Aloaha kann ihn auch für Sie betreiben.
Als von Aloaha betriebener Dienst oder als eigene Installation. Sagen Sie uns, was Sie brauchen.