Dezentrale Authentifizierung mit Digital Wallets (OIDC4VP) in WeCare Resolve
Lernen Sie, wie Sie die Authentifizierung mittels Digital Wallets basierend auf dem OpenID for Verifiable Presentations (OIDC4VP)-Standard in WeCare Resolve verwenden können.
Warum Digital Wallets und OIDC4VP?
Datenminimierung:
Über digitale Wallets können Nutzende kryptografisch nachweisbare Identitätsdaten (Verifiable Credentials) direkt aus ihrer eigenen Wallet-App freigeben. WeCare Resolve speichert dabei keinerlei Passwörter. Die Identitätsprüfung erfolgt dezentral und nutzerzentriert, was die Angriffsfläche für Identitätsdiebstahl drastisch minimiert.Unterstützung offener Standards:
Die Integration basiert auf dem herstellerunabhängigen OIDC4VP-Standard. Dadurch ist das System zukunftssicher und kompatibel mit einer Vielzahl von Ökosystemen weltweit – wie beispielsweise dem europäischen EUDI-Wallet-Framework oder globalen dezentralen Identitätsnetzwerken.Nahtlose User Experience:
Nutzende können sich schnell und sicher per QR-Code-Scan oder direktem Deeplink über ihre bevorzugte Wallet-App auf ihrem Smartphone anmelden, ohne neue Zugangsdaten erstellen zu müssen.
Funktionsweise der Wallet-Anmeldung
Wenn die OIDC4VP-Funktion aktiviert ist, delegiert WeCare Resolve die Identitätsprüfung an eine vom Nutzenden installierte, kompatible Wallet-App:
Nutzende wählen auf der Anmeldeseite die Option zur Anmeldung mit einer digitalen Wallet.
Die Anwendung generiert eine Präsentationsanforderung (Presentation Request) und zeigt diese als QR-Code oder Mobil-Deeplink an.
Nutzende scannen den Code mit ihrer Wallet-App, prüfen die angeforderten Daten (z. B. Vorname, Nachname, E-Mail) und geben diese explizit frei.
Die Wallet signiert die Daten kryptografisch und sendet sie an WeCare Resolve zurück, wo die Signatur gegen die konfigurierten Vertrauensanker (Trusted Issuers) geprüft und der Zugriff gewährt wird.
So konfigurieren Sie Digital Wallets in WeCare Resolve
Voraussetzungen
Mindestens ein vertrauenswürdiger Credential-Aussteller (Trusted Issuer), für den entweder eine JWKS-URI, ein Inline-JWK-Set oder eine X.509-Zertifikatskette vorliegt.
Ein gültiges Schlüsselpaar bzw. eine entsprechende Identitätsmethode basierend auf dem gewählten Client-ID-Scheme (siehe unten).
Schritt-für-Schritt-Konfiguration
Melden Sie sich in der Verwaltungsoberfläche an. Navigieren Sie zu Einstellungen > Anmeldung.
Aktivieren Sie den Schalter Digital Wallets. Klicken oder Tippen Sie anschließend auf die Schaltfläche Details.
Allgemeine Einstellungen festlegen:
Wallet-Name: Geben Sie den Namen ein, der den Nutzenden auf der Anmeldeschaltfläche angezeigt werden soll (z. B. Digital Wallet oder eine spezifische Bezeichnung Ihres Ökosystems).
Verifier-Client-ID: Geben Sie die Kennung ein, die der Wallet als Identifikator für diesen Verifizierer angezeigt wird (z. B. Ihre Domain).
Client-ID-Schema wählen: Wählen Sie unter Client-ID-Schema die Methode, mit der Wallets das Vertrauen zu dieser Instanz überprüfen sollen:
x509_san_dns/x509_hash: Erfordert eine Zertifikatskette und den dazugehörigen privaten Schlüssel (siehe Schritt 7).did:web: Verwendet eine dezentrale ID. Hierbei muss Ihre Instanz-Domain öffentlich erreichbar sein, damit Wallets die zugehörigedid.jsonabrufen können. Zertifikatseingaben sind in diesem Modus nicht erforderlich.
Credential-Anforderung konfigurieren:
Nachweistyp (vct): Tragen Sie den genauen Typ des Credentials (vct) ein, der von der Wallet angefordert werden soll.
Nachweisformat: Wählen Sie das gewünschte Datenformat aus der Liste der unterstützten Formate (z. B.
dc+sd-jwt).Wallet-Deeplink-Schema: Hinterlegen Sie das URI-Schema für den Deeplink (Standard:
openid4vp://).Angeforderte PID-Claims: Definieren Sie die spezifischen Attribute, die aus der Wallet abgefragt werden sollen (durch Leerzeichen oder Komma getrennt, z. B.
family_name given_name email_address).Subjekt-Claim: Bestimmen Sie, welches Attribut aus dem verifizierten Credential als stabile, eindeutige Benutzer-ID (subject) verwendet werden soll (z. B.
sub).
Vertrauenswürdige Aussteller pflegen: Im Abschnitt Vertrauenswürdige Aussteller verwalten Sie die Aussteller, deren Credentials akzeptiert werden, in einer Tabelle. Bestehende Einträge lassen sich pro Zeile über Bearbeiten anpassen oder über Entfernen entfernen.
Um einen neuen Aussteller anzulegen, klicken oder tippen Sie auf Vertrauenswürdigen Aussteller hinzufügen. Es öffnet sich ein Dialog mit folgenden Feldern:
Aussteller-URL: Die
iss-URL des Ausstellers, wie sie im SD-JWT VC erscheint.Schlüsselquelle: Legen Sie über die Optionsschaltflächen fest, woher der Schlüssel zur Signaturprüfung bezogen wird. Anschließend wird das passende Eingabefeld eingeblendet:
JWKS-URI: HTTPS-URL auf den JWKS-Endpunkt des Ausstellers. Der Endpunkt wird serverseitig abgerufen und zwischengespeichert.
Inline-JWKS: Inline-JWK-Set als JSON-Objekt der Form
{ "keys": [...] }– geeignet z. B. für isolierte Umgebungen oder fest verankerte Schlüssel.x5c-Kette: X.509-Zertifikatskette mit einem base64-DER-Zertifikat pro Zeile, beginnend mit dem Leaf-Zertifikat.
Bestätigen Sie den Dialog mit OK; der neue Eintrag erscheint in der Tabelle. Wiederholen Sie diesen Schritt für jeden weiteren Aussteller.
Schlüsselmaterial für
x509-Schemata hinterlegen (entfällt beidid:web):Zertifikatskette des Verifizierers (x5c): Fügen Sie die Zertifikatskette des Verifizierers ein. Ist bereits eine Kette hinterlegt, bleibt diese erhalten, solange Sie das Feld leer lassen.
Privater Schlüssel des Verifizierers: Fügen Sie den zur Kette gehörenden privaten Schlüssel ein. Auch hier bleibt ein bestehender Schlüssel erhalten, wenn Sie das Feld leer lassen.
Speichern Sie die Einstellungen.
Wichtiger Hinweis zur Schlüsselgenerierung
Ein kryptografisches Schlüsselpaar zur Signierung der Wallet-Anfragen wird bei der ersten Nutzung (bzw. sofort beim Speichern unter dem did:web-Schema) automatisch generiert. Der öffentliche Schlüssel kann als JWK eingesehen und kopiert werden. Ein nachträgliches Regenerieren dieses Schlüssels unter Schlüsselpaar neu generieren macht bestehende Verifizierer-Registrierungen ungültig und führt zu Fehlern beim Anmeldevorgang, bis der neue öffentliche Schlüssel im Ökosystem verteilt wurde.