Digitale Nachweise und Passkeys: Gemeinsamkeiten und Unterschiede

• 🔑 Passkeys: Für sichere Logins. Sie beweisen, wer Sie sind (Authentifizierung) und bekämpfen Phishing effektiv.
• 📄 Digitale Nachweise: Für überprüfbare Belege. Sie beweisen Fakten über Sie (Bestätigung, z. B. Ihr Ausweis, Ihre Fähigkeiten), und Sie kontrollieren, was geteilt wird.
• 🤝 Gemeinsamkeiten: Beide nutzen starke Kryptografie für bessere Sicherheit und eine reibungslosere Nutzererfahrung im Vergleich zu Passwörtern.
• 🎯 Unterschiede: Passkeys dienen hauptsächlich dem Zugriff auf Dienste. Digitale Nachweise dienen der Bereitstellung verifizierter Informationen über Sie selbst.

Die digitale Landschaft verändert sich rasant. Dieser Wandel geschieht nicht nur, weil traditionelle Passwörter und geteilte Geheimnisse immer wieder versagen, sondern auch, weil Angriffe wie Phishing und KI-gesteuerte Deepfakes immer besser und schwerer zu erkennen sind. Diese fortschrittlichen Bedrohungen können selbst vorsichtige Nutzer täuschen und alte Methoden der Identitätsprüfung unzuverlässig machen. Das zeigt deutlich, dass digitale kryptografische Nachweise der einzig wirklich sichere Weg sind, um die Identität einer Person zu bestätigen. In dieser schwierigen Situation benötigen wir dringend sicherere, benutzerfreundlichere und kryptografisch überprüfbare Wege für Online-Interaktionen. Dieser Bedarf hat zwei Schlüsseltechnologien in den Vordergrund gerückt: Passkeys, die bereits weit verbreitet sind, und digitale Nachweise, die gerade erst am Anfang stehen. Diese Technologien verlassen sich nicht auf Behauptungen, die von Menschen geprüft werden – und die zunehmend leicht zu fälschen sind –, sondern nutzen maschinell überprüfbare kryptografische Beweise, um echtes Vertrauen aufzubauen.

Passkeys erlebten in den Jahren 2023-2025 einen starken Anstieg in der Nutzung, dank der massiven Unterstützung durch große Unternehmen wie Apple, Google und Microsoft sowie der FIDO Alliance. Basierend auf dem soliden W3C-WebAuthn-Standard stellen Passkeys eine grundlegende Abkehr von schwachen, geteilten Geheimnissen dar. Anstelle von Passwörtern verwenden sie Public-Key-Kryptografie. Dabei signiert ein privater Schlüssel, der sicher auf dem Gerät des Nutzers gespeichert ist, Anfragen (Challenges) der Relying Party (RP). Dies beweist, dass der Nutzer den Schlüssel besitzt, ohne den Schlüssel selbst preiszugeben.

Diese Kryptografie macht Passkeys sehr schwer zu phishen – ein großer Vorteil, da Phishing-Angriffe immer raffinierter werden und manchmal Deepfakes verwenden, um noch echter zu wirken. Da ein Passkey an die spezifische Website oder App gebunden ist, für die er erstellt wurde, können Nutzer ihn nicht versehentlich auf gefälschten Seiten verwenden. Dies ist ein häufiges Problem bei älteren Anmeldemethoden, die für solche fortgeschrittenen Tricks anfällig sind. Passkeys verhindern auch die Wiederverwendung von Passwörtern und die Gefahren von Credential Stuffing nach Datenlecks. Über die Sicherheit hinaus verbessern Passkeys das Anmeldeerlebnis erheblich: Es ist schneller und erfordert oft nur einen biometrischen Scan (wie Face ID oder Fingerabdruck), sodass sich Nutzer keine langen Passwörter merken oder eingeben müssen. Diese Mischung aus verbesserter Sicherheit und Benutzerfreundlichkeit hat sie schnell populär gemacht.

Gleichzeitig sind digitale Nachweise, die oft in digitalen Identitäts-Wallets aufbewahrt werden, viel stärker in den Fokus gerückt. Die EU Digital Identity Wallet (EUDI Wallet) ist ein gutes Beispiel für diesen Trend.

Im Gegensatz zu Passkeys, die hauptsächlich zur Authentifizierung dienen (also beweisen, wer Sie sind, indem Sie die Kontrolle über einen privaten Schlüssel nachweisen), geht es bei digitalen Nachweisen (basierend auf Standards wie W3C Verifiable Credentials (VCs) oder ISO mdocs) um kryptografisch überprüfbare Bestätigungen (also beweisen, was über Sie wahr ist, mit digital signierten Behauptungen). Die Fähigkeit, diese Behauptungen zuverlässig zu verifizieren, ist wichtig, besonders jetzt, wo Deepfakes überzeugende Fälschungen traditioneller Beweismittel erstellen können. Ohne kryptografische Prüfungen können selbst Experten nur schwer erkennen, was echt ist. Sie ermöglichen es Menschen, verifizierte Informationen – wie Name, Geburtsdatum, Führerschein, Bildungs- oder Arbeitszeugnisse – digital mit sich zu führen und vorzuzeigen. Dies geschieht auf eine Weise, die kryptografisch sicher ist, die Privatsphäre respektiert (indem Nutzer nur das Nötigste teilen) und von Maschinen überprüft werden kann.

Der Aufstieg beider Technologien ist kein Zufall. Er zeigt einen breiteren Wandel in der Branche weg von zentralisierten, passwortbasierten Identitätssystemen hin zu einem dezentraleren, nutzerzentrierten Modell, das auf kryptografischem Vertrauen basiert. Passwörter sind eine bekannte Schwachstelle in der Online-Sicherheit. Alte Methoden zum Teilen von Identitätsdaten sind oft umständlich, unsicher oder geben zu viele Daten preis, was die Privatsphäre der Nutzer verletzt. Passkeys beheben die Schwachstelle der Authentifizierung direkt. Digitale Nachweise kümmern sich um das sichere Teilen von Attributen mit Nutzerkontrolle. Beide verwenden ähnliche Kryptografie und sind zunehmend auf Plattformintegration und sichere Hardware angewiesen, was eine gemeinsame Anstrengung zeigt, unsere digitalen Identitätssysteme erheblich zu verbessern.

Während Passkeys das „Anmelden“ und digitale Nachweise das „Nachweisen von Attributen“ übernehmen, nutzen sie ähnliche kryptografische Grundlagen und spielen ergänzende Rollen beim Aufbau vertrauenswürdiger digitaler Interaktionen. Dies ist etwas, das wir dringend benötigen, da aktuelle Bedrohungen wie raffiniertes Phishing und Deepfakes ältere, nicht-kryptografische Methoden der Identitätsprüfung unsicher machen. Das bringt uns zur zentralen Frage: Wie hängen Passkeys und digitale Nachweise zusammen und wie können sie in alltäglichen Nutzersituationen zusammenarbeiten?

Dieser Artikel untersucht diese Synergie. Wir werden ihre Unterschiede und Gemeinsamkeiten, die Protokolle, die sie ermöglichen, ihre gemeinsame Abhängigkeit von sicherer Hardware und wie sie in Szenarien wie der Nutzerregistrierung, dem Login mit Step-up-Authentifizierung und der Gerätemigration ineinandergreifen können, beleuchten. Wir werden auch darauf eingehen, wie aufkommende Browser-Standards wie die Digital Credentials API darauf abzielen, diese Welten zu überbrücken. Dieser Beitrag konzentriert sich speziell auf das Zusammenspiel dieser Technologien und ergänzt die bereits verfügbare, tiefere technische Untersuchung der Digital Credentials API.

Um zu verstehen, wie Passkeys und digitale Nachweise zusammenarbeiten können, ist es wichtig, zunächst ihre unterschiedlichen Eigenschaften und die technologischen Schichten, die ihnen zugrunde liegen, zu erfassen.

Die folgende Tabelle bietet einen groben Vergleich:

Dieser Vergleich zeigt, dass beide zwar auf Kryptografie für Vertrauen setzen, ihre Hauptfunktionen und typischen Nutzungsmuster sich jedoch erheblich unterscheiden. Passkeys sind für häufige, sichere Authentifizierung optimiert, während digitale Nachweise sich hervorragend eignen, um überprüfbare Attribute mit Zustimmung des Nutzers bereitzustellen.

Passkeys werden durch das Zusammenspiel mehrerer wichtiger Standards zum Leben erweckt:

• WebAuthn (Web Authentication): Dieser W3C-Standard definiert die JavaScript-API, die Webanwendungen zur Interaktion mit Authenticators für die Registrierung (navigator.credentials.create()) und Authentifizierung (navigator.credentials.get()) von Passkeys verwenden. Er fungiert als Brücke zwischen der Webanwendung der Relying Party und dem Browser oder Betriebssystem des Nutzers. WebAuthn erweitert die allgemeine Credential Management API des W3C.

• CTAP (Client to Authenticator Protocol): Definiert von der FIDO Alliance, legt CTAP fest, wie der Client (Browser oder Betriebssystem) mit dem Authenticator-Gerät kommuniziert. Dies kann ein in das Gerät integrierter Plattform-Authenticator sein (der sichere Hardware wie ein TPM oder eine Secure Enclave verwendet) oder ein Roaming-Authenticator wie ein USB-Sicherheitsschlüssel oder sogar ein Telefon, das als Authenticator für ein anderes Gerät fungiert. CTAP2 ist die Version, die auf FIDO2 und Passkeys abgestimmt ist und verschiedene Übertragungswege wie USB, NFC und Bluetooth Low Energy (BLE) unterstützt.

• Erweiterte Vertrauenssignale & Gerätebindung (Überlegungen zu synchronisierten Passkeys): Als sich Passkeys zu synchronisierbaren Anmeldedaten über mehrere Geräte hinweg entwickelten („multi-device credentials“), mussten Relying Parties (RPs) manchmal das spezifische physische Gerät identifizieren, das während der Authentifizierung zur Risikobewertung verwendet wurde. Frühe Ideen wie die Erweiterungen devicePubKey und supplementalPubKeys versuchten dies zu lösen, wurden aber später verworfen. Die Arbeitsgruppe für Vertrauenssignale der FIDO Alliance entwickelt nun Ersatzlösungen. Die Hauptidee dabei ist, dass ein Authenticator mit einem synchronisierten Passkey zusätzlich ein zweites, an das Gerät gebundenes Schlüsselpaar erstellen und verwenden könnte. Während der Authentifizierung könnte der Authenticator dann Signaturen sowohl vom synchronisierten Hauptschlüssel als auch von diesem zweiten gerätegebundenen Schlüssel bereitstellen. Dies würde es RPs ermöglichen, ein bestimmtes vertrauenswürdiges Gerät zu erkennen. Das könnte weniger Reibung bedeuten (z. B. das Überspringen zusätzlicher Abfragen), selbst wenn der Haupt-Passkey über viele Geräte synchronisiert wird, ohne den Hauptvorteil synchronisierter Passkeys zu verlieren: die geräteübergreifende Nutzbarkeit. Obwohl es hierfür noch keinen endgültigen Standard gibt, würde eine solche Funktion einen wichtigen Bedarf für RPs mit hohen Sicherheitsanforderungen decken und es ihnen ermöglichen, die Nutzung neuer Geräte besser zu erkennen oder interne Regeln zur Starken Kundenauthentifizierung (SCA) zu erfüllen.

Ähnlich stützt sich das Ökosystem der digitalen Nachweise auf eine Reihe von Protokollen und aufkommenden APIs, um zu funktionieren:

• Digital Credentials API: Dies ist eine aufkommende W3C-Spezifikationsbemühung, die darauf abzielt, die navigator.credentials.get()-API zu erweitern, um Webanwendungen zu ermöglichen, Verifiable Credentials aus der digitalen Wallet eines Nutzers auf standardisierte Weise anzufordern. Sie dient einem ähnlichen Zweck wie WebAuthn, konzentriert sich aber auf VCs anstelle von Passkeys.
• OpenID for Verifiable Presentations (OpenID4VP): Dies definiert ein Protokoll, das auf OAuth 2.0 aufbaut, wie ein Prüfer (die RP, die Nachweise anfordert) VCs von der Wallet eines Inhabers anfordern kann. Schlüsselelemente sind die presentation_definition (die die erforderlichen Nachweise und Behauptungen spezifiziert), die Wallet, die als Autorisierungsserver fungiert, und das vp_token, das die Verifiable Presentation zurück zum Prüfer trägt.
• OpenID for Verifiable Credential Issuance (OpenID4VCI): Ergänzend zu OpenID4VP standardisiert dies, wie ein Aussteller VCs an die Wallet eines Inhabers liefert, wiederum unter Verwendung von OAuth 2.0-Mechanismen. Es beinhaltet Konzepte wie Credential Offers, vorautorisierte oder Autorisierungscode-Flüsse und dedizierte Credential-Endpunkte.
• ISO-Standards (z. B. ISO/IEC 18013-7, ISO/IEC 23220): Diese internationalen Standards sind besonders wichtig für mobile Führerscheine (mDLs) und andere Arten von mobilen Dokumenten (mdoc). ISO 18013-5 definiert die Kern-mDL-Datenstruktur und die Offline-Präsentation (NFC, BLE), während ISO 18013-7 und 23220 Online-Präsentationsmechanismen spezifizieren, einschließlich REST-APIs und Integrationsprofilen mit OpenID4VP (Anhang B von 18013-7). Plattformen wie Google Wallet und Apple Wallet nutzen diese ISO-Standards.

Trotz ihrer unterschiedlichen Zwecke und Protokolle teilen sich Passkeys und digitale Nachweise grundlegende Bausteine:

• Asymmetrische Kryptografie: Beide stützen sich stark auf Public-Private-Schlüsselpaare. Passkeys verwenden den privaten Schlüssel, um den Besitz während der Authentifizierung nachzuweisen. Digitale Nachweise verwenden den privaten Schlüssel des Ausstellers, um den Nachweis zu signieren und so seine Authentizität und Integrität zu gewährleisten, und der Inhaber könnte seinen privaten Schlüssel verwenden, um eine Präsentation mit dem Nachweis zu signieren.
• Sichere Hardware: Der Schutz der privaten Schlüssel ist von größter Bedeutung. Beide Technologien profitieren immens von sicheren Hardwarekomponenten, die in moderne Geräte integriert sind:
  • TPM (Trusted Platform Module): Ein dedizierter Chip, der oft in Laptops und Desktops zu finden ist und eine sichere Schlüsselgenerierung, -speicherung und kryptografische Operationen bietet. Er wird häufig von Plattform-Authenticators wie Windows Hello verwendet.
  • Secure Enclave: Apples hardwarebasierter Schlüsselmanager, der vom Hauptprozessor auf iPhones, iPads und Macs isoliert ist und zum Schutz sensibler Daten, einschließlich der privaten Schlüssel von Passkeys, verwendet wird.
  • Android Keystore System / StrongBox Keymaster: Android bietet einen hardwaregestützten Keystore, der oft mit einem dedizierten sicheren Prozessor (StrongBox Keymaster) implementiert ist und einen starken Schutz für kryptografische Schlüssel auf Android-Geräten bietet. Während einige Passwort-Manager den Namen „Strongbox“ verwenden, ist das zugrunde liegende sichere Hardwareelement, das vom Betriebssystem bereitgestellt wird, hier der entscheidende Faktor.

Die Verwendung der gleichen sicheren Hardwareelemente (TPM, Secure Enclave, Androids hardwaregestützter Keystore) sowohl für Passkey-Operationen als auch potenziell für die Sicherung der privaten Schlüssel in digitalen Wallets schafft erhebliche Synergien. Plattformen benötigen keine separaten sicheren Chips für jede Funktion. Stattdessen können sie eine einzige, starke Hardwarebasis und zugehörige Betriebssystem-APIs (wie die für den Android Keystore oder Apples Secure Enclave) nutzen, um sowohl Authentifizierungs-Credentials (Passkeys) als auch Bestätigungs-Credentials (VCs) stark zu schützen. Dies erleichtert die Entwicklung, verbessert die Sicherheitskonsistenz und nutzt bestehende Plattforminvestitionen gut.

Darüber hinaus ist die Credential Management API des Browsers (navigator.credentials) eine wichtige organisatorische Schicht. Zuerst von WebAuthn für Passkeys erweitert, wird sie nun von der Digital Credentials API für VCs weiter ausgebaut. Dies deutet auf einen klaren Plan hin: RPs einen Hauptweg zu geben, um verschiedene Credentials anzufordern, und den Nutzern eine vertraute Möglichkeit zu geben, sie auszuwählen (wie über den Android Credential Manager oder eingebaute Browser-Passwortmanager). Dies würde die komplexen technischen Details von Protokollen wie CTAP, OID4VP und ISO verbergen und die Dinge für Entwickler und Nutzer einfacher machen.

Aus der Perspektive einer Relying Party (RP) ist es entscheidend zu verstehen, wie man Passkeys und digitale Nachweise effektiv integriert und nutzt, um die Sicherheit zu erhöhen, die Benutzererfahrung zu verbessern und regulatorische Anforderungen zu erfüllen. Dieser Abschnitt analysiert, wie RPs diese Technologien in verschiedenen gängigen Szenarien und Ökosystemen einsetzen können.

Die optimale Integrationsstrategie für Passkeys und digitale Nachweise variiert erheblich je nach spezifischem Anwendungsfall und dem damit verbundenen Risikoprofil und den Anforderungen. Die folgende Tabelle bietet einen groben Vergleich über gängige Szenarien hinweg:

Vergleich der Ökosystem-Szenarien

Legende:

• Rolle der VCs 🆔: Beschreibt die Rolle während der Hauptinteraktion, wobei anerkannt wird, dass VCs oft für das anfängliche Onboarding/KYC in allen Szenarien verwendet werden.
• Gerätebindung? 🔗: Bezieht sich auf die Notwendigkeit einer expliziten Gerätebindung über die standardmäßige Passkey-Herkunftsbindung hinaus, was besonders für synchronisierte Passkeys relevant ist.
• EU-EUDI-Wallet-Mandat*: Dieses Szenario spiegelt die Anforderungen der kommenden eIDAS-2-Verordnung wider, die voraussichtlich ca. 36 Monate nach Inkrafttreten der endgültigen Durchführungsrechtsakte gelten wird (wahrscheinlich Ende der 2020er Jahre).

Dieser Vergleich bietet einen schnellen Überblick; die folgenden Abschnitte gehen auf die Besonderheiten jedes Szenarios aus der Integrationsperspektive der RP ein.

• Ziel: Schneller, reibungsloser Zugang mit guter Basissicherheit.
• Wahrscheinlicher Ablauf:
  • Primäre Authentifizierung: Passkeys werden dominieren. Ihre Phishing-Resistenz und nahtlose UX (oft nur ein Biometrie-/PIN-Scan) machen sie ideal, um Passwörter in häufigen Anmeldeszenarien zu ersetzen.
  • Rolle der digitalen Nachweise: Minimal für den Kern-Login. VCs könnten optional nach dem Login für spezifische Aktionen wie die Altersüberprüfung (z. B. beim Kauf von eingeschränkten Waren), die Personalisierung auf Basis verifizierter Attribute (z. B. Treuestatus) oder die beschleunigte Profilvervollständigung bei der Erstanmeldung verwendet werden.
• Zusammenspiel: Der Passkey übernimmt den Kern-Login; VCs sind für optionale, attributbasierte Interaktionen reserviert.

• Ziel: Hochsicherer Login und, wo nötig, verifizierte Identitäts-Bestätigung.
• Wahrscheinlicher Ablauf:
  • Passkeys als eigenständige 2FA/MFA: Passkeys erfüllen von Natur aus die Anforderungen der Zwei-Faktor-Authentifizierung, wenn während des Anmeldevorgangs eine Nutzerverifizierung (PIN/Biometrie) stattfindet. Sie kombinieren:
    • Besitz: Nachweis der Kontrolle über den privaten Schlüssel.
    • Wissen/Inhärenz: Nutzerverifizierung über PIN oder Biometrie. Dies macht den Passkey-Login selbst zu einer starken, Phishing-resistenten MFA-Methode, die für viele Hochsicherheitsszenarien ausreicht, ohne einen separaten zweiten Schritt nur zur Erreichung von 2FA zu benötigen.
  • Step-Up zur Identitätsprüfung (einmalig): Die Notwendigkeit eines zusätzlichen Schritts mit digitalen Nachweisen entsteht hauptsächlich dann, wenn der Dienst die Identität explizit verifizieren muss, anstatt nur einen wiederkehrenden Nutzer zu authentifizieren. Diese Art der starken, kryptografischen Überprüfung ist unerlässlich, wenn Deepfakes überzeugend visuelle oder dokumentenbasierte Ausweise fälschen können. Nur ein digitaler kryptografischer Nachweis von einer vertrauenswürdigen Quelle kann dann ein Attribut zuverlässig bestätigen. Dies könnte erforderlich sein:
    • Während des anfänglichen Onboardings.
    • Für spezifische risikoreiche Aktionen, die bestätigte Identitätsattribute erfordern. In diesen Fällen fordert die RP eine Präsentation eines spezifischen Verifiable Credential (z. B. eines PID, eines nationalen ID-Nachweises) aus der Wallet des Nutzers nach dem Passkey-Login an.
  • Identität zur Wiederherstellung: Sobald die Identität eines Nutzers stark verifiziert wurde (z. B. durch einen VC-Präsentations-Step-up), könnten diese verifizierten Identitätsinformationen potenziell in sicheren Kontowiederherstellungsabläufen genutzt werden. Wenn ein Nutzer beispielsweise alle seine Passkey-Authenticators verliert, könnte die Vorlage eines hochsicheren Identitätsnachweises Teil eines Prozesses sein, um den Zugang wiederzuerlangen und neue Passkeys zu registrieren.
• Zusammenspiel: Passkeys bieten eine robuste, eigenständige 2FA/MFA für die Authentifizierung. VCs werden strategisch für die explizite Identitätsprüfung eingesetzt, wenn dies erforderlich ist, und diese verifizierte Identität kann auch sichere Mechanismen zur Kontowiederherstellung unterstützen.

• Ziel: Optimierter, sicherer Checkout oder Initiierung von Zahlungen, bei minimaler Reibung für den Nutzer.
• Wahrscheinlicher Ablauf:
  • Authentifizierung für die Zahlung: Passkeys sind ideal, um den Nutzer bei seinem Konto des Zahlungsdienstleisters (PSP) (z. B. PayPal) oder direkt im Checkout-Prozess des Händlers zu authentifizieren. Dies ersetzt Passwörter und bietet eine schnelle, sichere Bestätigung zur Initiierung der Zahlung.
  • Onboarding/KYC: VCs bleiben entscheidend während der Onboarding- oder Kontoeinrichtungsphase beim PSP oder Händler, um verifizierte Identitätsinformationen (KYC/AML-Prüfungen) bereitzustellen, die zur Aktivierung der Zahlungsfunktionen erforderlich sind.
  • Bedenken hinsichtlich der Transaktionsreibung: Das Einführen eines separaten Präsentationsschritts für Verifiable Credentials während des Kern-Zahlungsautorisierungsflusses (der eine Interaktion mit einer digitalen Identitäts-Wallet erfordert) würde im Vergleich zu einem nahtlosen Passkey-Bestätigungsschritt erhebliche Reibung hinzufügen. Diese Störung der Benutzererfahrung würde wahrscheinlich die Conversion-Raten beeinträchtigen und ist daher für typische reibungsarme Zahlungsszenarien ungeeignet.
• Zusammenspiel: Der Passkey sichert die Authentifizierung für den Zahlungsvorgang selbst. VCs übernehmen die notwendige, oft einmalige Identitätsprüfung/KYC, die zur Einrichtung des Zahlungskontos erforderlich ist, werden aber aus dem kritischen, reibungsempfindlichen Zahlungsbestätigungsschritt herausgehalten. (Das komplexe Thema der direkten Verwendung von digitalen Nachweisen als Zahlungsinstrumente, einschließlich wie verschiedene Wallet-Typen und aufkommende Browser-APIs solche zahlungsspezifischen VCs ermöglichen oder mit ihnen interagieren könnten, wird in unserem kommenden ergänzenden Artikel ausführlich behandelt: Digitale Nachweise und Zahlungen.)

• Ziel: Sicherer Banking-Zugang mit einer signifikanten Reduzierung von Betrug, insbesondere Phishing-bezogenem, durch ein Upgrade von veralteten Authentifizierungsmethoden.
• Wahrscheinlicher Ablauf:
  • Ersetzen von veralteter MFA: Viele Finanzinstitute verlassen sich derzeit auf Passwörter in Kombination mit phishbaren zweiten Faktoren wie SMS-OTPs. Passkeys bieten eine weitaus überlegene Alternative, die eine starke Authentifizierung bietet, die von Natur aus resistent gegen Phishing ist, und das in einer einzigen Nutzergeste.
  • Primärer Login mit Passkeys: Die Einführung von Passkeys für den primären Login erhöht die Sicherheit sofort aufgrund ihrer Phishing-Resistenz. Die kryptografische Natur von Passkeys entschärft die häufigsten Angriffsvektoren, die traditionelle Anmeldedaten plagen.
  • Risikobasierter Step-Up – Sorgfältige Abwägung von Gerätesignalen: Für risikoreichere Operationen (z. B. große Überweisungen, Änderung von Kontaktdaten) können Finanzinstitute eine Step-up-Verifizierung in Betracht ziehen. Obwohl mit Passkeys verbundene Gerätesignale eine Option sind, sollte ihre Notwendigkeit sorgfältig bewertet werden. Die Phishing-Resistenz der primären Passkey-Authentifizierung selbst mindert viele Risiken erheblich.
  • Ergebnisorientierte Sicherheit & Betrugsreduzierung: Die signifikante Reduzierung des Phishing-Risikos durch Passkeys ist ein entscheidender Faktor. Ein ergebnisorientierter Sicherheitsansatz, der sich auf die Stärke und Phishing-Resistenz der Authentifizierungsmethode konzentriert, kann zu einer erheblichen Betrugsreduzierung führen. Das Gewicht eines Phishing-resistenten Faktors wie eines Passkeys ist erheblich höher als das Hinzufügen weiterer phishbarer Faktoren. Dies muss im Mittelpunkt der Strategie eines Finanzinstituts stehen, wenn es von älteren Methoden migriert.
  • VCs für Onboarding/Identitätsprüfung: Wie in anderen Szenarien bleiben VCs für eine robuste anfängliche KYC/AML und für die sichere Aktualisierung von Kundenidentitätsattributen unter Verwendung verifizierter Informationen unerlässlich, um eine vertrauenswürdige Grundlage für die Banking-Beziehung zu schaffen.
• Zusammenspiel: Passkeys dienen als leistungsstarke, Phishing-resistente primäre Authentifizierungsmethode, die das Betrugsrisiko durch veraltete Systeme drastisch reduziert. Gerätesignale für den Step-up sind eine taktische Option. Die inhärente Stärke von Passkeys sollte eine risikobasierte Sicherheitsposition informieren und möglicherweise die übermäßige Abhängigkeit von zusätzlichen, weniger Phishing-resistenten Faktoren verringern. VCs bieten grundlegende Identitätssicherheit.

• Ziel: Einhaltung der eIDAS-2-Vorschriften (Art. 5f), die die Akzeptanz der EU Digital Identity Wallet durch bestimmte Relying Parties (öffentliche Stellen, große private Unternehmen in regulierten Sektoren, VLOPs) vorschreiben und sowohl einen datenschutzfreundlichen pseudonymen Login als auch eine hochsichere Identitäts-/Attributüberprüfung ermöglichen, wenn dies gesetzlich vorgeschrieben ist.
• Wahrscheinlicher Ablauf:
  • Pseudonymer Login (Standard): Der Nutzer initiiert den Login. Die RP fordert die Authentifizierung über die EUDI Wallet an. Die Wallet verwendet ihren eingebauten „pseudonymen Schlüssel“ – einen hardwaregebundenen, RP-spezifischen WebAuthn Resident Key, der im zertifizierten sicheren Element (WSCD) des Geräts gespeichert ist –, um den Nutzer zu authentifizieren. Dies bietet eine starke, SCA-konforme Authentifizierung (Besitz + Nutzerverifizierung), während die bürgerliche Identität des Nutzers standardmäßig pseudonym bleibt.
  • Step-Up für Identität/Attribute (gesetzlich vorgeschrieben): Nur wenn die RP eine spezifische Rechtsgrundlage nach Unions- oder nationalem Recht hat (z. B. PSD2, AML, Telekommunikations-Registrierung), um eine Identitätsprüfung oder spezifische Attribute zu verlangen, initiiert sie einen zweiten Schritt. Die RP fordert eine Präsentation (über OpenID4VP) der erforderlichen Personenidentifikationsdaten (PID) oder der qualifizierten Bestätigung von Attributen (QAA) aus der Wallet an. Der Nutzer muss der Weitergabe dieser identifizierten Daten ausdrücklich zustimmen.
  • Wallet- & RP-Authentifizierung: Der Ablauf beinhaltet eine gegenseitige Authentifizierung. Die RP authentifiziert sich gegenüber der Wallet (basierend auf ihrer offiziellen Registrierung), und die Wallet bestätigt ihre Authentizität und die Gültigkeit des Nachweises gegenüber der RP, wobei sie die sichere Hardware (WSCD) und die zugehörige Zertifizierungs-Infrastruktur nutzt.
• Zusammenspiel: Die EUDI Wallet fungiert als einheitlicher Authenticator. Ihr integrierter WebAuthn-Passkey (pseudonymer Schlüssel) übernimmt den Standard-Login und bietet eine starke, datenschutzfreundliche Authentifizierung. Die VC-Fähigkeiten der Wallet werden selektiv für explizite, gesetzlich vorgeschriebene Identitäts- oder Attributoffenlegungen aufgerufen, um standardmäßig Datenminimierung zu gewährleisten.

Das Navigieren in dieser sich entwickelnden Landschaft erfordert strategische Planung. Hier sind wichtige Überlegungen für Relying Parties (RPs).

Für RPs sollte die Hauptaktion heute darin bestehen, die Nutzung von Passkeys für die Authentifizierung zu ermöglichen und zu fördern. Passkeys sind standardisiert, werden von Plattformen breit unterstützt und bieten sofortige, große Vorteile in Bezug auf Sicherheit (Phishing-Resistenz) und Benutzererfahrung (schnellere, einfachere Logins). Dies bedeutet weniger Abhängigkeit von Passwörtern und unsicheren MFA-Methoden wie SMS-OTPs. Es kann auch die Supportkosten durch Passwort-Zurücksetzungen und Kontowiederherstellung senken. Das Anstreben einer breiten Passkey-Nutzung schafft eine moderne, sichere Basis für die Nutzerauthentifizierung. Auch wenn die Akzeptanz anfangs langsam sein mag, kann die Aufklärung der Nutzer über die Vorteile im Voraus und eine einfache Registrierung helfen, den Einstieg zu erleichtern.

Obwohl Passkeys selbst einen bedeutenden Schritt in Richtung robuster Authentifizierung darstellen und die Anforderungen der Starken Kundenauthentifizierung (SCA) erfüllen können, haben einige Organisationen möglicherweise interne Compliance-Frameworks mit noch strengeren Auslegungen oder spezifischen Bedenken, insbesondere in Bezug auf synchronisierte Passkeys. Für Relying Parties (RPs), die mit solchen Szenarien konfrontiert sind, in denen Compliance-Abteilungen weitere Zusicherungen suchen, ist es nützlich zu wissen, dass zusätzliche Maßnahmen Passkey-Implementierungen ergänzen können. Diese können helfen, wahrgenommene SCA-Lücken zu schließen oder diese erhöhten internen Anforderungen zu erfüllen. Eine gängige Strategie ist die Nutzung von Gerätevertrauenssignalen, ein Ansatz, den Dienste wie PayPal verfolgen.

PayPal erlaubt es Nutzern beispielsweise, ein Gerät als „erinnert“ zu markieren, wie auf ihrer Hilfeseite beschrieben:

Das bedeutet, wenn sich ein Nutzer mit seinem Passwort (etwas, das er weiß) von einem erinnerten Gerät (etwas, das er hat) anmeldet, kann PayPal dies in vielen Fällen als ausreichend für SCA betrachten. Sie geben jedoch auch an: „Es kann Fälle geben, in denen wir Sie dennoch um eine weitere Verifizierung bitten, um sicherzustellen, dass Ihr Konto sicher ist.“ Dies könnte das Senden eines Einmal-Passcodes per SMS oder die Aufforderung zur Bestätigung über die PayPal-App beinhalten.

Dieser Ansatz ermöglicht eine reibungslosere Benutzererfahrung auf vertrauenswürdigen Geräten und bietet gleichzeitig Mechanismen für die Step-up-Authentifizierung, wenn die Risiken höher sind oder Vorschriften dies erfordern. RPs können ähnliche Modelle in Betracht ziehen, bei denen eine Kombination aus primärer Authentifizierung (wie einem Passkey) und Gerätevertrauen (potenziell außerhalb der direkten Mechanismen von WebAuthn verwaltet, falls erforderlich) helfen kann, SCA-Konformitätslücken zu schließen. Für einen integrierteren und standardisierten Ansatz für gerätespezifische Vertrauenssignale innerhalb des WebAuthn-Frameworks selbst richtet sich die Aufmerksamkeit jedoch auf laufende Entwicklungen in diesem Bereich.

In Bezug auf solche WebAuthn-integrierten Ansätze für ein stärkeres Gerätevertrauen sollten RPs in Hochsicherheitsumgebungen die Geschichte und die zukünftige Richtung verstehen. Frühere Vorschläge für WebAuthn-Erweiterungen wie devicePubKey und supplementalPubKeys zielten darauf ab, diese gerätespezifischen Vertrauenssignale bereitzustellen. Dies waren Versuche, die Sicherheitsüberlegungen von synchronisierten Passkeys anzugehen, die zwar entscheidende Benutzerfreundlichkeit für die Massenakzeptanz bieten, aber andere Risikoprofile (z. B. Abhängigkeit von der Cloud-Kontowiederherstellung) im Vergleich zu gerätegebundenen Schlüsseln aufweisen. Die Idee hinter solchen Erweiterungen war, RPs eine zusätzliche Sicherheitsebene zu geben, indem sie eine Signatur von einem Schlüssel überprüfen, der spezifisch an das verwendete physische Gerät gebunden ist, selbst wenn der Haupt-Passkey selbst synchronisiert ist.

Obwohl diese spezifischen Erweiterungen (devicePubKey und supplementalPubKeys) eingestellt wurden, bleibt die Herausforderung, stärkere gerätebindende Signale für synchronisierte Passkeys zu erhalten, bestehen. RPs sollten daher die Entwicklung und Standardisierung von Nachfolgelösungen in diesem Bereich beobachten. Solche Lösungen könnten RPs helfen, Risiken besser einzuschätzen (z. B. einen Login von einem bekannten, vertrauenswürdigen Gerät von einem neu synchronisierten zu unterscheiden), ohne alle Nutzer zu zwingen, weniger bequeme gerätegebundene Passkeys zu verwenden. Dieser Kontext stellt RPs vor eine komplexere Wahl als nur „synchronisiert vs. gerätegebunden“. Synchronisierte Passkeys (normalerweise AAL2-konform) bieten den größten Komfort und die beste Chance auf Akzeptanz, was für Verbraucher-Apps entscheidend ist. Gerätegebundene Passkeys (möglicherweise AAL3) bieten die höchste Sicherheit, können aber schwieriger zu verwenden sein. Das Ziel der eingestellten Erweiterungen war es, einen Mittelweg zu finden – die Sicherheit für synchronisierte Schlüssel zu verbessern, indem ein gerätespezifisches Vertrauenssignal wieder hinzugefügt wird. Dies könnte helfen, einige Risiken zu reduzieren, wenn die Cloud-Synchronisierung kompromittiert wird, ohne den gesamten Komfort der Synchronisierung zu verlieren. RPs sollten daher nach Nachfolgelösungen Ausschau halten, die dies anstreben. Die beste Strategie wird von der spezifischen Risikotoleranz einer RP, ihrer Nutzerbasis und der Reife neuer Standards abhängen.

Über die spezifischen Mechanismen innerhalb von WebAuthn für Gerätevertrauen hinaus beginnen einige Relying Parties (RPs) – insbesondere in Sektoren wie Banking, Versicherungen und Zahlungsdiensten – digitale Nachweise (Verifiable Credentials oder VCs) als ergänzende oder sogar nächste Komponente in ihren Identitäts- und Sicherheitsstrategien zu bewerten.

Ein wesentlicher Faktor, der dieses Interesse antreibt, ist die robuste Gerätebindung, die oft mit digitalen Nachweisen verbunden ist, insbesondere wenn sie in sicheren digitalen Identitäts-Wallets verwaltet werden. Diese Wallets können hardwaregestützte Sicherheit (wie Secure Enclaves oder TPMs) nutzen, um die Nachweise und die privaten Schlüssel, die zu ihrer Präsentation verwendet werden, zu schützen. Aussteller und Wallet-Anbieter können auch Richtlinien durchsetzen, die bestimmte hochwertige Nachweise von Natur aus gerätegebunden machen, was ein Maß an Kontrolle bietet, das für Hochsicherheitsszenarien attraktiv ist.

Es ist entscheidend zu erkennen, dass, obwohl diese verbesserte Gerätebindungsfähigkeit ein überzeugendes Merkmal für diese RPs ist, der Hauptzweck von digitalen Nachweisen (Bestätigung von Attributen und Behauptungen) sich von dem von Passkeys (Nutzerauthentifizierung) unterscheidet. Passkeys bestätigen, wer der Nutzer ist, während digitale Nachweise bestätigen, was über den Nutzer wahr ist. Trotz dieses grundlegenden Unterschieds im Zweck machen die starken Sicherheitsmerkmale von in Wallets gehaltenen VCs sie zu einem Bereich aktiver Überlegung für RPs, die zusätzliche Sicherheiten schaffen möchten. Dies führt die Diskussion natürlich zu den Anbietern dieser digitalen Identitäts-Wallets und dem Ökosystem, das die Ausstellung, Speicherung und Präsentation solcher Nachweise ermöglicht.

Während Passkeys eine direkte Authentifizierung bieten, werden digitale Nachweise (VCs) über digitale Identitäts-Wallets verwaltet und Relying Parties vorgelegt. Diese Wallets, ob native Plattformlösungen (wie Apple Wallet, Google Wallet) oder Drittanbieteranwendungen (wie die EUDI Wallet), entwickeln sich weiter, um aufkommende Browser-Standards wie die Digital Credentials API für eine reibungslosere Online-Identitätsprüfung (z. B. Alterskontrollen, Teilen von digitalen ID-Attributen) zu nutzen.

Die detaillierten Mechanismen verschiedener Wallet-Typen, spezifische Plattformstrategien für die VC-Integration (einschließlich Apples mDoc-Fokus für Browser-Interaktionen im Gegensatz zu Androids breiterer OpenID4VP-Unterstützung über seinen Credential Manager), wie diese Wallets die Attributbestätigung erleichtern, und die völlig separaten Überlegungen für jegliche Zahlungsfunktionalitäten sind komplexe Themen. Diese werden in unserem kommenden ergänzenden Artikel ausführlich behandelt: Digitale Nachweise und Zahlungen.

Dieser aktuelle Artikel behält seinen Fokus auf dem grundlegenden Zusammenspiel zwischen Passkeys für die Authentifizierung und der allgemeinen Rolle digitaler Nachweise zur Bestätigung von Attributen.

Passkeys und digitale Nachweise stellen, obwohl sie sich in ihrem Hauptzweck unterscheiden, zwei Säulen einer modernen, sichereren und nutzerorientierten digitalen Identitätszukunft dar. Zu verstehen, wie sie zusammenhängen und sich gegenseitig unterstützen können, ist der Schlüssel zum Aufbau der nächsten Welle von Online-Diensten.

Basierend auf dem aktuellen Stand und der Entwicklung dieser Technologien ergeben sich zwei zentrale Handlungsempfehlungen für Relying Parties:

• Passkeys heute überall einsetzen: Die Standards sind ausgereift, die Plattformunterstützung ist weit verbreitet und die Vorteile gegenüber Passwörtern sind klar und erheblich. Machen Sie Passkeys zum Standardziel für die Nutzerauthentifizierung, um die Sicherheit und Benutzerfreundlichkeit sofort zu verbessern.
• Wallet-Step-up hinzufügen, wo AML/KYC wichtig ist: Für Prozesse, die eine höhere Sicherheit oder spezifische verifizierte Attribute erfordern – wie die Erfüllung von Anti-Geldwäsche- (AML) / Know-Your-Customer- (KYC) Vorschriften, die Durchführung zuverlässiger Altersüberprüfungen oder die Bestätigung beruflicher Qualifikationen – integrieren Sie Präsentationsflüsse für Verifiable Credentials, um kryptografisch überprüfbare Attribute zu erhalten. Diese sind unerlässlich, um Identität und Behauptungen in einer Ära hochentwickelter digitaler Fälschungen und Deepfakes zu vertrauen. Nutzen Sie die Digital Credentials API, wo immer möglich, aber implementieren Sie robuste QR-/Deep-Link-Fallbacks, um eine plattformübergreifende Reichweite zu gewährleisten, bis die API stabil ist. Dies bietet gezielte hohe Sicherheit, ohne jeden Login zu belasten.

Mit Blick auf die Zukunft können wir weitere Konvergenz und Verbesserungen erwarten:

• Verbesserte Portabilität von Nachweisen: Methoden zur Übertragung von Gerät zu Gerät werden sich wahrscheinlich verbessern. Dies könnte über die geräteübergreifende Authentifizierung von CTAP 2.2 für Passkeys hinausgehen und reibungslosere Wege zum Verschieben von VCs zwischen Wallets umfassen, obwohl die Standardisierung hier noch nicht so weit fortgeschritten ist.
• Konsolidierte Browser-APIs: Die Digital Credentials API wird wahrscheinlich ausreifen und konsistenter über Browser hinweg unterstützt werden. Dies wird RPs einen standardisierteren Weg bieten, um sowohl Passkeys als auch VCs über navigator.credentials anzufordern.
• Einheitliche Nutzererfahrung: Letztendlich sollten Nutzer weniger einen technischen Unterschied zwischen der Authentifizierung mit einem Passkey und der Präsentation von Attributen mit einem VC sehen. Plattform-Credential-Manager und Wallets werden diese Interaktionen wahrscheinlich reibungslos im Hintergrund verwalten. Sie werden gemeinsame kryptografische Werkzeuge und sichere Hardware verwenden, sodass Nutzer Anfragen einfach mit vertrauten biometrischen oder PIN-Eingaben genehmigen können, egal ob ein Passkey oder ein VC verwendet wird. Darüber hinaus könnten Konzepte wie die Kontinuierliche Passive Authentifizierung (CPA), die Nutzer ständig im Hintergrund anhand von Verhaltensbiometrie und anderen Signalen verifiziert, diese nahtlose Sicherheit weiter verbessern und potenziell neben aktiven Authentifikatoren wie Passkeys arbeiten.

Um diese integrierte Zukunft zu erreichen, bedarf es weiterer Arbeit an Standards, deren Unterstützung durch Plattformen und deren Nutzung durch Apps. Indem Organisationen jetzt Passkeys einsetzen und digitale Nachweise durchdacht hinzufügen, können sie sich auf diesen Wandel zu einer digitalen Welt vorbereiten, die passwortlos ist und den Nutzern mehr Kontrolle über ihre Daten gibt.