OpenID4VCI erklärt: wie Nachweise in die Wallet kommen
OpenID for Verifiable Credential Issuance (OpenID4VCI) 1.0 bringt Nachweise in die Wallet. Rollen, Ablauf, Sicherheit und Rolle in der EU-Wallet erklärt.
StandardsVeröffentlicht
OpenID4VCI steht für OpenID for Verifiable Credential Issuance und ist der Standard, mit dem ein Aussteller einen digitalen Nachweis in die Wallet einer Person liefert. Aussteller kann eine Behörde sein, die einen Identitätsnachweis ausgibt, eine Führerscheinstelle oder eine Hochschule, die ein Zeugnis erstellt. Das Protokoll stellt sicher, dass die richtige Person den Nachweis erhält und er an einen Schlüssel in der Wallet dieser Person gebunden ist.
Wofür es OpenID4VCI gibt
Eine digitale Wallet ist nur nützlich, wenn man sie sicher und einheitlich mit Nachweisen füllen kann. Ohne gemeinsames Protokoll bräuchte jeder Aussteller eine eigene App und eine eigene Schnittstelle. OpenID4VCI legt einen gemeinsamen Weg fest, auf dem jede Wallet bei jedem kompatiblen Aussteller einen Nachweis anfragen kann. Es ist das Gegenstück zu OpenID4VP, das das spätere Vorzeigen regelt. Was ein Nachweis ist und wie sich die Formate unterscheiden, behandelt Verifiable Credentials erklärt.
Die Spezifikation entsteht in der Arbeitsgruppe Digital Credentials Protocols der OpenID Foundation und liegt unter openid.net/specs. openideurope.eu ist ein unabhängiger Ratgeber und nicht mit der Foundation verbunden.
Die Rollen
| Rolle | Aufgabe | Beispiel |
|---|---|---|
| Credential Issuer (Aussteller) | Erstellt und signiert den Nachweis, veröffentlicht Metadaten | Melderegister, Führerscheinstelle, Hochschule |
| Authorization Server | Authentifiziert den Nutzer und stellt Access-Token aus | Oft vom Aussteller betrieben, manchmal getrennt |
| Wallet | Fragt den Nachweis an, empfängt und speichert ihn | Die EUDI-Wallet-App |
| Nutzer (Holder) | Gibt die Ausstellung frei | Sie |
So läuft die Ausstellung ab
- Angebot. Der Aussteller zeigt ein Credential Offer, meist einen QR-Code oder einen Link in der App des Ausstellers. Es nennt, welcher Nachweis bereitsteht und welcher Ablauf gilt, direkt oder über eine Referenz.
- Erkundung. Die Wallet liest die Metadaten des Ausstellers (unter einer festgelegten Adresse veröffentlicht), um Endpunkte sowie Nachweistypen, Formate und Schlüsselanforderungen zu erfahren.
- Autorisierung. Die Wallet erhält ein Access-Token auf einem von zwei Wegen:
- Authorization-Code-Ablauf: Die Wallet schickt Sie zum Login des Ausstellers. Sie authentifizieren sich, etwa mit einer nationalen eID, und willigen ein. Die Wallet erhält einen Code und tauscht ihn gegen ein Token, nach demselben Muster wie bei OAuth 2.0.
- Pre-Authorized-Code-Ablauf: Der Aussteller hat Sie bereits identifiziert, zum Beispiel am Schalter oder im Online-Konto, und legt einen einmaligen Code ins Angebot. Zusätzlich kann ein Transaktionscode verlangt werden, der über einen anderen Kanal kommt.
- Nonce. Die Wallet kann beim Aussteller eine frische Nonce anfordern, um Aktualität zu belegen.
- Besitznachweis. Die Wallet erzeugt ein Schlüsselpaar oder nutzt einen Schlüssel in einem Secure Element und signiert die Nonce, um die Kontrolle über den Schlüssel zu zeigen. Optional fügt sie eine Key Attestation bei, die belegt, dass der Schlüssel in zertifizierter Hardware liegt.
- Nachweisanfrage. Die Wallet ruft den Credential-Endpunkt des Ausstellers mit Access-Token und Beleg auf.
- Nachweisantwort. Der Aussteller liefert den signierten, an den Wallet-Schlüssel gebundenen Nachweis. Braucht er Zeit, etwa für manuelle Prüfungen, antwortet er mit einer Transaktions-ID für verzögerte Ausstellung, und die Wallet holt den Nachweis später ab.
- Benachrichtigung. Die Wallet kann dem Aussteller melden, ob der Nachweis angenommen oder gelöscht wurde.
Ein gekürztes Credential Offer sieht so aus:
{
"credential_issuer": "https://issuer.example.gov",
"credential_configuration_ids": ["eu.example.pid"],
"grants": {
"urn:ietf:params:oauth:grant-type:pre-authorized_code": {
"pre-authorized_code": "oaKazRN8I0IbtZ0C7JuMn5",
"tx_code": { "input_mode": "numeric", "length": 4 }
}
}
}
Beispiele aus dem Alltag
- Sie scannen in der App einer Kommune einen QR-Code, melden sich mit Ihrer nationalen eID an, und Ihre Identitätsdaten landen in der Wallet.
- Eine Führerscheinstelle lässt Sie nach einem Online-Antrag einen digitalen Führerschein in die Wallet legen, siehe Der digitale Führerschein in Europa.
- Eine Hochschule schickt Absolventen ein Zeugnis als Nachweis per Link in die Wallet.
- Ein Arbeitgeber stellt Beschäftigten einen Beschäftigungsnachweis aus.
Sicherheitsaspekte
- Starke Authentifizierung beim Aussteller. Was der Nachweis wert ist, hängt davon ab, wie gründlich der Aussteller Sie geprüft hat. Die EU beschreibt das über Vertrauensniveaus.
- Bindung an den Inhaber. Da der Nachweis an den Schlüssel der Wallet gebunden ist, nützt eine kopierte Nachweisdatei niemandem sonst.
- Wallet- und Key-Attestation. Aussteller können belegen lassen, dass die Wallet-App echt ist und Schlüssel in sicherer Hardware liegen, was vor geklonten oder manipulierten Wallets schützt. Das wirft auch Fragen der Herstellerbindung auf, die EU-Regeln zu adressieren versuchen.
- Risiken beim Pre-Authorized-Code. Wird ein Einmalcode abgefangen oder das Angebot der falschen Person gezeigt, kann ein Nachweis in der falschen Wallet landen. Der optionale Transaktionscode ist eine Gegenmaßnahme.
- Phishing-Angebote. Nehmen Sie nur Angebote an, die Sie erwartet haben, von Ausstellern, denen Sie vertrauen. Ein untergeschobener QR-Code kann eine Anmeldung auf einer gefälschten Seite auslösen.
- Übliche OAuth-Hygiene. PKCE, exakte Redirect-URIs und kurzlebige Token gelten auch hier, siehe RFC 9700.
Status und Versionen
OpenID for Verifiable Credential Issuance 1.0 wurde von den Mitgliedern der OpenID Foundation als Final Specification verabschiedet und am 16. September 2025 veröffentlicht. Es unterstützt mehrere Nachweisformate, darunter ISO mdoc und IETF SD-JWT VC (siehe SD-JWT und mdoc und ISO 18013-5) sowie das W3C-Format. Frühere Entwürfe änderten Namen und Endpunkte, so kam der Nonce-Endpunkt später hinzu, weshalb ältere Anleitungen nicht zum Endtext passen müssen.
Verhältnis zu anderen Standards
OpenID4VCI ist eine OAuth-2.0-Erweiterung: Es ergänzt ein bestehendes Rahmenwerk um einen Credential-Endpunkt und neue Grant-Angaben. Die Anmeldung, die die Ausstellung autorisiert, kann ihrerseits OpenID Connect nutzen. Das Schwesterprotokoll OpenID4VP übernimmt, sobald der Nachweis in der Wallet liegt.
Rolle in der EUDI-Wallet
In der EUDI-Wallet gelangen Personenidentifizierungsdaten (PID) und weitere Attestierungen per OpenID4VCI in die Wallet. Die Durchführungsverordnung (EU) 2024/2982 zu Wallet-Protokollen und Schnittstellen (siehe EUR-Lex) und der Architecture and Reference Framework stützen sich für diesen Schritt auf OpenID4VCI. Die Mitgliedstaaten sollen bis Ende 2026 Wallets anbieten, und nationale PID-Aussteller, private Attestierungsanbieter und qualifizierte Vertrauensdiensteanbieter werden dieses Protokoll nutzen, um Ihre Wallet zu erreichen. Wann und wie Sie Ihren Ausweis in Deutschland, Österreich oder der Schweiz laden können, hängt vom Start der jeweiligen nationalen Lösung ab.
Häufige Fragen
Was ist der Unterschied zwischen OpenID4VCI und OpenID4VP?
OpenID4VCI liefert einen Nachweis vom Aussteller in die Wallet. OpenID4VP zeigt einen Nachweis aus der Wallet einem Prüfer vor. Ausgestellt wird selten, vorgezeigt oft.
Muss ich mich anmelden, um einen Nachweis zu erhalten?
Meist ja. Im Authorization-Code-Ablauf authentifiziert der Aussteller Sie, etwa mit einer nationalen eID, und stellt dann aus. Im Pre-Authorized-Code-Ablauf hat der Aussteller Sie schon geprüft und gibt einen einmaligen Code aus, manchmal mit zusätzlicher PIN.
Warum braucht die Wallet einen eigenen Schlüssel?
Der Nachweis wird an einen in der Wallet erzeugten Schlüssel gebunden. Beim späteren Vorzeigen signieren Sie mit diesem Schlüssel, sodass jemand, der die Nachweisdatei kopiert, sie nicht nutzen kann.
Ist OpenID4VCI final?
Version 1.0 wurde als Final Specification der OpenID Foundation verabschiedet und im September 2025 veröffentlicht. Umsetzungsprofile wie HAIP und die technischen Vorgaben der EU legen weitere Anforderungen fest.
Mehr aus Standards
Dezentrale Identifikatoren (DIDs): Was sie sind und leisten
Eine DID ist eine W3C-Kennung, die Sie ohne zentrales Register kontrollieren. Wie DID-Dokumente funktionieren, Bezug zu Nachweisen und Rolle in der EUDI-Wallet.
FIDO2 und WebAuthn erklärt: die Standards hinter Passkeys
FIDO2 vereint WebAuthn und CTAP und ersetzt Passwörter durch phishing-resistente Schlüsselpaare. Ablauf, Neuerungen von Level 3 und Bezug zur EU-Wallet.
Identitätsföderation erklärt: ein Login für viele Dienste
Bei der Identitätsföderation bürgt ein vertrauter Anbieter für Sie bei vielen Diensten. Wie sie funktioniert, welche Standards sie nutzt, was die Wallet ändert.
OpenID 2.0 erklärt: das ursprüngliche dezentrale Login
OpenID 1.x und 2.0 erlaubten das Login mit einer eigenen URL. Wie Discovery, Delegation und Provider arbeiteten und warum OpenID Connect sie ablöste.
OpenID Connect erklärt: Login auf Basis von OAuth 2.0
OpenID Connect (OIDC) lässt eine App über einen Anbieter wie Google prüfen, wer Sie sind. Ablauf, ID-Token, Risiken und die Rolle neben der EU-Wallet erklärt.
OpenID vs. OAuth: Authentifizierung vs. Autorisierung
OAuth regelt, was eine App darf, OpenID Connect belegt, wer sich angemeldet hat. Die Unterschiede in einer Tabelle, mit Analogie und typischen Fehlern.