Digital Credentials API (2025): Der Stand bei Chrome & Safari (WWDC25)

Letzte Aktualisierung: 15. Juli 2025 (nach der WWDC25)

Ein schneller Überblick über die Unterstützung der Digital Credentials API in den wichtigsten Browsern:

Die Welt der digitalen Nachweise entwickelt sich rasant. Hier ist eine Momentaufnahme der wichtigsten Entwicklungen und Prognosen:

Digitale Nachweise sind derzeit ein heiß diskutiertes Thema im Bereich der digitalen Identität. Da unser Leben immer stärker mit der digitalen Welt verknüpft ist, war der Bedarf an sicheren, nutzerzentrierten und datenschutzfreundlichen Wegen, unsere Identität und Qualifikationen online nachzuweisen, noch nie so groß. Traditionelle Methoden sind in die Jahre gekommen und die Nachfrage nach robusteren Lösungen ist deutlich spürbar.

In diesem Artikel möchten wir den aktuellen Stand der Digital Credentials API beleuchten – eine wichtige Entwicklung, die verspricht, die Art und Weise, wie wir mit Identitätsinformationen im Web interagieren, neu zu gestalten. Wir werden die zugrunde liegenden Mechanismen, die unterstützten Protokolle, die aktuelle Browser-Unterstützung und Empfehlungen für Relying Parties und Wallet-Issuer geben, die sich in dieser sich schnell entwickelnden Landschaft zurechtfinden müssen.

Die zuverlässige und sichere Überprüfung der Identität ist seit vielen Jahren eine beständige Herausforderung in der Architektur des Webs. Während das Internet eine beispiellose Konnektivität und einen nie dagewesenen Informationsaustausch ermöglichte, eröffnete es auch neue Wege für Falschdarstellungen und Betrug.

In einigen Ländern entstanden Lösungen, die hauptsächlich von frühen Bankenkonsortien vorangetrieben wurden. Diese entwickelten Dienste, um bestehende Vertrauensbeziehungen für die Online-Identifizierung zu nutzen. Auch Regierungen griffen ein und führten nationale digitale Identitäts-Wallets und -Dienste ein oder schrieben sie vor. Diese Lösungen waren jedoch oft isoliert, geografisch begrenzt und nicht universell interoperabel.

Die Standardlösung für die Identitätsprüfung in vielen Regionen waren traditionell umständliche Prozesse. Die physische Verifizierung in einer Postfiliale beispielsweise führt zu erheblichen Verzögerungen und Unannehmlichkeiten. Videoanrufe in Kombination mit dem Hochladen von Dokumenten wurden zu einer digitaleren Alternative, gefolgt vom jüngsten Aufkommen des automatisierten Scannens von Dokumenten und Liveness Checks. Trotz ihrer Fortschritte haben diese Methoden erhebliche Nachteile. Sie können zeitaufwändig sein, anfällig für menschliche Fehler oder Voreingenommenheit und haben sich häufig als anfällig für raffinierte Fälschungen erwiesen.

Die Herausforderung verschärft sich dramatisch mit dem Aufkommen von Deepfakes, fortschrittlichen KI-gesteuerten Imitationstechniken und immer raffinierteren Phishing-Angriffen. Diese Technologien können äußerst realistische, aber vollständig gefälschte Video-, Audio- und Dokumentenbeweise erstellen. Das macht es für traditionelle Systeme und sogar für KI-gestützte Verifizierungstools unglaublich schwierig, echte Nutzer von Betrügern zu unterscheiden. Das Potenzial, synthetische Identitäten zu erstellen oder biometrische Daten zu manipulieren, um Prüfungen zu umgehen, stellt eine ernsthafte Bedrohung dar, insbesondere für Finanzinstitute und alle Dienste, die robuste Know-Your-Customer-(KYC)-Prozesse erfordern. Diese eskalierende Bedrohungslandschaft unterstreicht die dringende Notwendigkeit sichererer, kryptografisch verifizierbarer Online-Identitäts- und Verifizierungsmechanismen.

Want to try digital credentials yourself in a demo?

Try Digital Credentials

Um zu verstehen, wie digitale Nachweise funktionieren, müssen wir uns die beteiligten Akteure und die verschiedenen technologischen Ebenen ansehen, die ihre Funktionalität ermöglichen.

Im Kern dreht sich das Konzept der digitalen Nachweise, insbesondere im Kontext der neuen Web-APIs, um ein Drei-Parteien-Modell:

1. Issuer: Eine Instanz (z. B. eine Regierung, Universität, ein Arbeitgeber), die für bestimmte Informationen über eine Person maßgeblich ist und einen digitalen Nachweis ausstellen kann, der diese Informationen bestätigt.
2. Holder: Die Person, auf die sich die Informationen beziehen (d. h. der Nutzer), die den Nachweis vom Issuer erhält und in einem digitalen Wallet speichert. Der Holder kontrolliert, wann und welche Informationen aus dem Nachweis geteilt werden.
3. Verifier (oder Relying Party): Eine Instanz (z. B. eine Website, ein Online-Dienst), die bestimmte Informationen über den Holder überprüfen muss, um Zugang zu einem Dienst oder einer Ressource zu gewähren. Der Verifier fordert die erforderlichen Informationen vom Holder an.

Dieses Drei-Parteien-Modell ist wichtig, weil es darauf abzielt, dem Nutzer (Holder) die Kontrolle über seine eigenen Daten zu geben. Im Gegensatz zu traditionellen Identitätssystemen, bei denen Daten möglicherweise zentral gespeichert oder ohne direkte Vermittlung durch den Nutzer zwischen den Parteien ausgetauscht werden, betont dieses Modell die Zustimmung des Nutzers und die selektive Offenlegung. Der Holder entscheidet, welche Informationen aus einem Nachweis für eine bestimmte Transaktion geteilt werden, anstatt den gesamten Nachweis preiszugeben.

Ein grundlegender Aspekt dieser Systeme ist die Verwendung von kryptografischen Schlüsselpaaren. Der Issuer signiert den Nachweis digital und gewährleistet so dessen Authentizität und Integrität. Der Holder wiederum verwendet seinen privaten Schlüssel, der oft sicher in seinem digitalen Wallet (geschützt durch Gerätehardware) aufbewahrt wird, um die Kontrolle über den Nachweis zu beweisen und dessen Präsentation gegenüber einem Verifier zu autorisieren. Dies beinhaltet typischerweise, dass der Verifier eine „Challenge“ (eine zufällige Datenmenge) vorlegt, die das Wallet des Holders mit dem mit dem Nachweis verbundenen privaten Schlüssel signiert. Der Verifier kann dann den entsprechenden öffentlichen Schlüssel verwenden, um die Signatur zu bestätigen und so die Präsentation zu authentifizieren.

Diese Erklärung ist protokollneutral, da die Kernprinzipien der Ausstellung, des Haltens und der Verifizierung durch kryptografische Challenges über verschiedene zugrunde liegende Technologien hinweg gleich sind.

Dieser Artikel konzentriert sich auf die Verifizierung digitaler Nachweise und das Prinzip der selektiven Offenlegung, das es Nutzern ermöglicht, bestimmte Attribute nachzuweisen (z. B. „Ich bin über 18“, „Ich besitze einen gültigen Führerschein“), ohne das gesamte Quelldokument preiszugeben. Während die zugrunde liegenden Systeme für digitale Nachweise Funktionen wie qualifizierte elektronische Signaturen (QES) und Fernsignaturfähigkeiten unterstützen können (wie bei umfassenden Lösungen wie dem EU Digital Identity Wallet für rechtsverbindliche Signaturen), liegt der Fokus hier, insbesondere bei der Digital Credentials API, auf der Identitätsbestätigung und der Attributverifizierung für Online-Interaktionen und nicht primär auf diesen breiteren Signaturfunktionen.

Um zu verstehen, wie digitale Nachweise funktionieren, ist es hilfreich, sich ein Ebenenmodell vorzustellen. Jede Ebene befasst sich mit einem anderen Aspekt des Ökosystems, vom Datenformat selbst bis hin zur Darstellung für einen Nutzer in einem Webbrowser. Dieser Artikel konzentriert sich hauptsächlich auf die Digital Credentials API, die auf der Präsentationsebene arbeitet.

Wichtige Begriffe:

• Digitaler Nachweis (Digital Credential): Jeder maschinenlesbare Nachweis (PDF mit Barcode, ISO mDL, W3C VC, SD-JWT usw.). „Digital“ sagt nichts über die kryptografische Überprüfbarkeit aus.
• Verifiable Credential: Eine Art digitaler Nachweis, definiert durch das W3C VC Data Model. Er fügt Manipulationssicherheit und kryptografische Beweise hinzu und existiert immer in einer Drei-Parteien-Welt: Issuer → Holder → Verifier.
• Verifiable Credential API: Eine REST/HTTP-Dienstschnittstelle zum Ausstellen, Speichern, Präsentieren und Überprüfen von VCs zwischen Backend-Systemen (Issuer, Wallets, Verifier).
• Digital Credentials API (DC API): Eine Browser-/Betriebssystem-API (JavaScript + native Anbindung), die es einer Website ermöglicht, das geräteseitige Wallet des Nutzers aufzufordern, einen unterstützten digitalen Nachweis (VC, ISO mDoc, SD-JWT …) datenschutzfreundlich zu präsentieren.

Stellen Sie sich VCs als Datenmodell vor, die VC API als Backend-Spezifikation und die DC API als Frontend-Implementierung, die Nachweise im Web präsentiert. Alles oberhalb von Ebene 1 (Datenmodellebene) ist formatunabhängig; alles darunter hängt vom Nachweisformat ab.

End-to-End-Ablauf (Beispiel: Online-Altersüberprüfung):

1. Ausstellen (VC API - Issuer ↔ Wallet): Die Zulassungsbehörde stellt ein Verifiable Credential aus, das besagt: „Holder ist über 18“.
2. Speichern (Wallet-App - OS): Der Nachweis befindet sich mit seinem kryptografischen Beweis im Wallet des Nutzers.
3. Anfragen (navigator.credentials.get() via DC API - Website → Browser): Die Website eines Spirituosenladens fragt: „Zeige mir einen Beweis, dass der Nutzer ≥18 ist.“
4. Präsentieren (DC API leitet an Wallet weiter → OpenID4VP (Protokoll) → VC-Payload): Das Wallet zeigt eine Einverständniserklärung an, der Nutzer stimmt zu, das Wallet sendet eine Verifiable Presentation zurück.
5. Überprüfen (VC API - Backend des Spirituosenladens): Das Backend der Website überprüft die Signatur und den DID/öffentlichen Schlüssel des Issuers und gewährt den Zugang.

Beachten Sie, wie die Daten ein VC sind, der Transport im Web die DC API ist, das darunter liegende Austauschprotokoll OpenID4VP ist und die serverseitige Überprüfung die VC API verwendet.

Warum gibt es diese Aufteilung?

• Interoperables Datenmodell (kryptografische Beweise, selektive Offenlegung): Gelöst durch das VC Data Model (& andere Formate).
• Standard-REST-Endpunkte für Backend-Systeme: Gelöst durch die VC API.
• Datenschutzfreundlicher Handshake zwischen Wallet ↔ Website: Gelöst durch die DC API.
• Unterschiedliche Vertrauensstufen / Dokumenttypen (Regierungsausweis vs. Kurszertifikat): Gelöst durch die Verwendung des richtigen Formats (ISO mDoc für hochsichere Ausweise; W3C VC für allgemeine Behauptungen) unter der DC API.

Wichtige Erkenntnisse:

1. „Digitaler Nachweis“ ist der Oberbegriff.
2. Ein Verifiable Credential ist eine Art digitaler Nachweis mit eingebauter kryptografischer Überprüfbarkeit.
3. Die VC API ist die Server-zu-Server-Verbindung für Lebenszyklusoperationen von VCs.
4. Die Digital Credentials API ist die Brücke zwischen Browser und Wallet, die es endlich ermöglicht, dass diese Nachweise reibungslos in Web-Apps fließen, egal in welchem konkreten Format sie vorliegen.
5. Die drei Teile ergänzen sich, sie konkurrieren nicht – sie befinden sich auf verschiedenen Ebenen desselben Stacks und ermöglichen zusammen eine sichere, nutzerzentrierte Identität im offenen Web.

Nachdem wir die Teilnehmer und die übergeordnete Schichtenarchitektur digitaler Nachweise untersucht haben, wird dieser Artikel nun tiefer in die Präsentationsebene eintauchen und sich speziell auf die Digital Credentials API und ihren aktuellen Zustand konzentrieren.

Als entscheidende Komponente auf der Präsentationsebene ist die Digital Credentials API ein Webstandard, der derzeit entwickelt wird, um Websites eine sichere und standardisierte Möglichkeit zu bieten, digitale Identitätsinformationen von den digitalen Wallets der Nutzer anzufordern und zu empfangen. Diese Arbeit ist hauptsächlich in der Federated Identity Working Group (FedID WG) des W3C angesiedelt, nachdem sie im April 2025 von der FedID Community Group dorthin migriert wurde. Der offizielle Spezifikationsentwurf findet sich hier: https://w3c-fedid.github.io/digital-credentials/.

Stand 2025 wird die API immer noch als in einer Phase signifikanter Änderungen beschrieben. Dies unterstreicht ihre aktive Entwicklungsphase. Trotzdem ist ihr Potenzial erheblich. Chrome war der erste, der mit seinem Origin Trial etwas Öffentliches ausgeliefert hat, das es Entwicklern ermöglicht, mit seinen Fähigkeiten zu experimentieren. Chrome unterstützt dies auch nativ auf Android über sein Credential Manager-System und hat kürzlich auch die Unterstützung für die Nutzung der Cross-Device Digital Credentials API auf dem Desktop veröffentlicht.

Die API erweitert die bestehende Credential Management API, indem sie Anfragen für digitale Nachweise über navigator.credentials.get() ermöglicht. Laut dem W3C FedID WG Digital Credentials Explainer (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md) ist die API zur Verwendung dieser etablierten Schnittstelle zurückgekehrt, anstatt des zuvor vorgeschlagenen navigator.identity. Eine Website fordert einen digitalen Nachweis an, indem sie navigator.credentials.get() mit spezifischen Parametern für digitale Nachweise aufruft.

Hier ist ein anschauliches Beispiel, wie eine Website die API aufrufen könnte, um einen Nachweis mit OpenID4VP anzufordern:

async function requestCredential() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

Dieses Beispiel stammt von hier.

Die Digital Credentials API fungiert im Wesentlichen als sicherer Wrapper oder Vermittler. Sie ermöglicht es dem Browser, die Anfrage nach Identitätsinformationen zu vermitteln und nutzt dabei die Fähigkeiten des zugrunde liegenden Betriebssystems, um verfügbare Wallets und Nachweise zu finden, die der Anfrage entsprechen. Der Browser und das Betriebssystem können dann eine konsistente Benutzeroberfläche zur Auswahl des Nachweises und zur Autorisierung seiner Freigabe präsentieren. Dies erhöht die Sicherheit und den Datenschutz, indem die Zustimmung des Nutzers sichergestellt und verhindert wird, dass Websites unbemerkt auf sensible Daten zugreifen. Die eigentlichen Nachweisdaten in der Antwort sollen für den Browser selbst opak (verschlüsselt) sein, wobei die Entschlüsselung und Interpretation von der Relying Party und dem Wallet/Holder gehandhabt werden.

Die Digital Credentials API ist protokollagnostisch konzipiert, was bedeutet, dass sie verschiedene zugrunde liegende Protokolle für den Austausch von Nachweisen unterstützen kann. Zwei Hauptfamilien von Protokollen stehen jedoch im Mittelpunkt der aktuellen Implementierungen und Diskussionen: org.iso.mdoc (abgeleitet von ISO 18013-5 und seiner Erweiterung ISO 18013-7 „Anhang C“) und die Spezifikationen der OpenID Foundation, OpenID for Verifiable Presentations (OpenID4VP) und OpenID for Verifiable Credential Issuance (OpenID4VCI).

• Herkunft und Standardisierung: org.iso.mdoc bezieht sich auf das Datenformat und das Interaktionsmodell für mobile Dokumente, hauptsächlich mobile Führerscheine (mDLs), die von der Internationalen Organisation für Normung (ISO) und der Internationalen Elektrotechnischen Kommission (IEC) standardisiert wurden. Der grundlegende Standard ist ISO/IEC 18013-5, der die mDL-Anwendung, die Datenstruktur und die Protokolle für die persönliche (Nahbereich-)Präsentation mit Technologien wie NFC, Bluetooth oder QR-Codes definiert. ISO/IEC 18013-7 erweitert dies, um die Online-/Fernpräsentation von mDLs zu ermöglichen. Der Protokoll-String „org.iso.mdoc“ ist speziell in ISO/IEC TS 18013-7 (Anhang C) für die Verwendung mit APIs wie der Digital Credentials API definiert.

• Datenmodell: mdocs haben eine streng definierte Datenstruktur, die auf CBOR (Concise Binary Object Representation) basiert, um Kompaktheit und Effizienz zu gewährleisten. Es spezifiziert Namensräume und Datenelemente für gängige Führerscheinattribute und unterstützt starke kryptografische Sicherheitsmerkmale, einschließlich Issuer-Authentifizierung, Gerätebindung, Holder-Authentifizierung (über Porträt), Sitzungsverschlüsselung und selektive Offenlegung.

• Typische Anwendungsfälle: Hauptsächlich von Regierungen ausgestellte Identitätsdokumente wie Führerscheine und nationale Ausweise. Es ist für Szenarien mit hohem Sicherheitsanspruch konzipiert, sowohl persönlich (z. B. Verkehrskontrollen, Altersüberprüfung für beschränkte Waren) als auch online (z. B. Zugang zu Regierungsdiensten, Fernidentifizierung für die Eröffnung eines Bankkontos).

• Herkunft und Standardisierung: OpenID4VP (für die Präsentation) und OpenID4VCI (für die Ausstellung) sind Spezifikationen, die von der OpenID Foundation entwickelt wurden. Sie erweitern OAuth 2.0, um den Austausch von Verifiable Credentials zu unterstützen. Dies sind offene Standards, die auf eine breite Interoperabilität für verschiedene Arten von Nachweisen abzielen, nicht nur für staatliche. Anfang 2025 befindet sich OpenID4VP in fortgeschrittenen Entwurfsstadien (z. B. Entwurf 28 im April). OpenID4VCI reift ebenfalls heran.
• Datenmodell: OpenID4VP/VCI sind so konzipiert, dass sie formatunabhängig sind. Sie können W3C Verifiable Credentials (VCs) in JSON/JSON-LD- oder JWT-Formaten, mdocs, SD-JWTs und anderen Formaten transportieren. Das Interaktionsmodell umfasst eine Autorisierungsanfrage vom Verifier (RP) und eine Antwort vom Wallet des Holders, die ein vp_token (Verifiable Presentation Token) enthält. Die selektive Offenlegung wird typischerweise mit Abfragesprachen wie Presentation Exchange (DIF PE) oder der neueren Digital Credentials Query Language DCQL verwaltet.
• Typische Anwendungsfälle: Breites Anwendungsspektrum, einschließlich Identitätsprüfung, Nachweis von Qualifikationen (z. B. Bildungsabschlüsse, Berufszertifikate), Mitgliedschafts-Bescheinigungen und mehr. Sie eignen sich gut für Online-Interaktionen, bei denen eine Relying Party Behauptungen von verschiedenen Issuern überprüfen muss.

Es ist wichtig zu erkennen, dass sich diese nicht immer gegenseitig ausschließen. OpenID4VP kann beispielsweise verwendet werden, um ein [org.iso.mdoc] anzufordern und zu transportieren. Die Wahl hängt oft vom spezifischen Anwendungsfall, der Art des Nachweises und den Teilnehmern des Ökosystems ab.

Das European Union Digital Identity (EUDI) Wallet ist eine große Initiative, die allen EU-Bürgern und Einwohnern ein sicheres digitales Wallet für Identitätsdokumente und Bescheinigungen zur Verfügung stellen soll. Die Architektur und das Referenz-Framework des EUDI Wallets sehen explizit die Unterstützung von sowohl mdoc (insbesondere für mobile Führerscheine) als auch W3C Verifiable Credentials vor, wobei OpenID4VP und OpenID4VCI für Präsentations- und Ausstellungsabläufe verwendet werden. Die Referenzimplementierung umfasst die Unterstützung für OpenID4VP zum Übertragen von mDocs und OpenID4VCI zum Ausstellen von PIDs und mDLs in mDoc- und SD-JWT-VC-Formaten. Diese duale Unterstützung durch ein so groß angelegtes Projekt unterstreicht die Bedeutung beider Protokollfamilien. Diese Richtung ist jedoch nicht unumstritten, da einige Beobachter anmerken, dass die Digital Credentials API, die stark von „US-Bigtech“-Unternehmen beeinflusst wird, tief in die endgültigen EUDI-Wallet-Spezifikationen integriert werden könnte. Es wurden Bedenken hinsichtlich des potenziellen Einflusses von Nicht-EU-Entitäten auf einen kritischen Teil der EU-Infrastruktur geäußert, wie in Community-Foren wie dieser GitHub-Diskussion diskutiert wird.

Die Browser-Landschaft für die Digital Credentials API nimmt noch Gestalt an, mit bemerkenswerten Unterschieden in Ansatz und Unterstützungsgrad.

Google Chrome, insbesondere auf Android, war ein früher Anwender und Implementierer der Digital Credentials API. Sie haben Origin Trials durchgeführt und sie in den nativen Credential Manager von Android integriert. Die Implementierung von Chrome nutzt hauptsächlich OpenID4VP als Protokoll zur Anforderung von Nachweisen über den navigator.credentials.get() API-Aufruf. Während OpenID4VP selbst formatunabhängig ist und org.iso.mdoc oder W3C Verifiable Credentials als Payloads transportieren kann, scheint der praktische Schwerpunkt von Google auf dem OpenID4VP-Fluss als Transportmechanismus zu liegen. Der Credential Manager von Android unterstützt auch nativ OpenID4VP für die Präsentation und OpenID4VCI für die Ausstellung. Dies ermöglicht es Android-Apps, als Holder und Verifier von Nachweisen unter Verwendung dieser Standards zu agieren.

In früheren Versionen dieses Artikels haben wir vorausgesagt, dass Apples Ansatz von dem von Google abweichen würde, indem er sich auf das org.iso.mdoc-Protokoll konzentriert. Aus historischem Kontext hier unsere damalige Begründung:

Wie wir richtig erwartet hatten, bestätigte die WWDC25 diese Strategie. Auf der Konferenz kündigte Apple offiziell die Unterstützung für die API in Safari 26 an (wird mit iOS 26 und anderen Betriebssystem-Updates im Herbst 2025 ausgeliefert) und bestätigte, dass ihre Implementierung ausschließlich das org.iso.mdoc-Protokoll für die Präsentation unterstützt.

Dies wurde in der WWDC25-Session Verify identity documents on the web detailliert beschrieben. Die API ermöglicht es Websites, verifizierbare Informationen aus Identitätsdokumenten wie einem Führerschein anzufordern, die in der Apple Wallet oder in Dokumentenanbieter-Apps von Drittanbietern gespeichert sind.

Die wichtigsten Erkenntnisse aus Apples Implementierung:

• Nur MDOC: Die API verwendet ausschließlich den Protokoll-String "org-iso-mdoc", basierend auf dem Standard ISO/IEC 18013-7 Anhang C. Es gibt keine Unterstützung für OpenID4VP in der Safari-Implementierung der Digital Credentials API.
• Nur Präsentation: Die API dient der Präsentation (Verifizierung) bestehender Nachweise. Die Ausstellung in die Apple Wallet oder andere Apps bleibt ein separater, nicht-browserbasierter Prozess.
• Nutzerzentriert & Sicher: Der Fluss wird durch eine Nutzergeste initiiert und nutzt einen „Partial Request“-Mechanismus, bei dem das Betriebssystem die Anfrage zuerst in einer Sandbox parst und validiert, bevor es sie an die Wallet-Anwendung weitergibt, was die Sicherheit erhöht.
• Erweiterbar auf Apps: Zusätzlich zur Apple Wallet können Drittanbieter-Apps als Dokumentenanbieter fungieren, indem sie das neue IdentityDocumentServices-Framework und eine App-Erweiterung implementieren.

Apple lieferte ein klares Code-Beispiel, wie eine Relying Party die API verwenden würde:

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

Diese Bestätigung festigt die unterschiedlichen Strategien auf dem Browsermarkt. Während Chrome auf der flexiblen OpenID4VP-Transportschicht aufbaut, nutzt Apple seine tiefgreifende Investition in das ISO-mdoc-Ökosystem, um eine hochintegrierte und sichere, wenn auch weniger flexible Lösung anzubieten, die auf offizielle Identitätsdokumente zugeschnitten ist.

Mozilla hat formell eine „negative“ Position zum Vorschlag der Digital Credentials API in ihrer jetzigen Form geäußert. Ihre Bedenken sind umfassend und wurzeln in ihrer Mission, die Privatsphäre der Nutzer, ihre Handlungsfähigkeit und ein offenes, gerechtes Web zu schützen.

Zu den von Mozilla geäußerten Hauptbedenken gehören:

• Datenschutzrisiken: Potenzial für eine verstärkte Weitergabe personenbezogener Daten und eine Verringerung der Online-Anonymität, wenn Anfragen nach digitalen Nachweisen für triviale Interaktionen zur Norm werden.
• Ausschluss von Nutzern: Risiko, dass Personen, die keine digitalen Nachweise verwenden können oder wollen, von Online-Diensten und -Gemeinschaften ausgeschlossen werden könnten. Von der Regierung ausgestellte Nachweise, ein primärer Anwendungsfall, stimmen möglicherweise nicht mit der Wahl der Identitätspräsentation einer Person überein.
• Interoperabilitätsprobleme: Bedenken hinsichtlich einer Verbreitung von Nachweisformaten, die zu einem fragmentierten Ökosystem anstelle eines universell interoperablen führen.
• Selektive Offenlegung: Sorgen, dass die Datenschutzvorteile der selektiven Offenlegung untergraben werden könnten, wenn sie nicht mit starken Garantien zur Entkoppelung implementiert wird oder wenn die Nutzer nicht vollständig verstehen, was geteilt wird.
• Zentralisierung von Vertrauen und Nutzerautonomie: Befürchtungen, dass die API zu einer verstärkten Zentralisierung von Vertrauen und einer Verringerung der Nutzerautonomie führen könnte, was bestehende gesellschaftliche Machtungleichgewichte fortsetzt.

Mozilla erkennt an, dass eine solche API einen Nutzen gegenüber bestehenden Ad-hoc-Methoden zur Präsentation von Nachweisen bieten könnte, betont jedoch, dass neue Web-Plattform-Funktionen nachweislich das Web insgesamt verbessern und die Interessen der Nutzer in den Vordergrund stellen müssen. Obwohl ein W3C Council einen formellen Einspruch im Zusammenhang mit diesen Bedenken überstimmt hat (um die Arbeit innerhalb des W3C und nicht in potenziell weniger transparenten Gremien fortzusetzen), empfahl der Rat der Arbeitsgruppe, aktiv daran zu arbeiten, diese potenziellen Schäden zu mindern.

Tabelle 1: Browser-Unterstützung für Digital Credentials API & Protokolle

Für Organisationen (Relying Parties oder RPs), die beabsichtigen, digitale Nachweise von Nutzern anzufordern und zu überprüfen, erfordert die aktuelle Landschaft eine sorgfältige strategische Planung.

Angesichts der Tatsache, dass Safari mit seinem bedeutenden Marktanteil wahrscheinlich direkte org.iso.mdoc-Interaktionen über die Digital Credentials API priorisieren wird und Chrome/Android OpenID4VP (das mdocs oder andere Verifiable Credential-Formate transportieren kann) betonen, sollten RPs, die eine möglichst breite Reichweite anstreben, sich darauf vorbereiten, Interaktionen auf Basis beider Ansätze zu unterstützen.

Das bedeutet, Systeme so zu gestalten, dass sie:

1. Nachweisanfragen über die navigator.credentials.get()-API initiieren können, möglicherweise unter Angabe unterschiedlicher Protokollparameter („org.iso.mdoc“ oder „openid4vp“) basierend auf der Browser-Erkennung oder den User-Agent-Fähigkeiten.
2. Antworten verarbeiten können, die entweder direkt im mdoc-Format oder als vp_token über OpenID4VP kommen, der dann geparst werden muss, um den zugrunde liegenden Nachweis (der selbst ein mdoc oder ein anderes VC-Format sein könnte) zu extrahieren.

Obwohl dies die Komplexität erhöht, wird der Versuch, alle Nutzer auf einen einzigen Protokollpfad zu zwingen, wahrscheinlich einen erheblichen Teil der Nutzerbasis ausschließen, entweder diejenigen auf iOS oder diejenigen auf Android/Chrome, je nach gewähltem Pfad. Ein pragmatischer, wenn auch entwicklungsintensiverer Ansatz besteht darin, Flexibilität für beide zu schaffen.

Relying Parties müssen sich sehr bewusst sein, dass selbst wenn sie dieselbe logische Information anfordern (z. B. „Ist der Nutzer über 21?“), die Art und Weise, wie dies in einer Anfrage definiert und in einer Antwort zurückgegeben wird, zwischen einer direkten mdoc-Abfrage und einer OpenID4VP-Abfrage (die Presentation Exchange oder DCQL verwenden könnte) erheblich abweichen kann.

• mdoc Selective Disclosure: org.iso.mdoc hat seine eigenen Mechanismen für die selektive Offenlegung, die typischerweise die Erstellung von gesalzenen Hashes einzelner Datenelemente durch den Issuer beinhalten. Das Wallet des Holders gibt dann nur die angeforderten Elemente zusammen mit ihren Salzen preis, sodass der Verifier sie mit den Hashes abgleichen kann, ohne andere Daten zu sehen. Die Anfrage nach spezifischen Elementen ist an vordefinierte Namensräume und Datenelement-Identifikatoren innerhalb des mdoc-Standards gebunden.
• OpenID4VP Selective Disclosure: OpenID4VP verwendet typischerweise eine Abfragesprache wie Presentation Exchange (DIF PE) oder die neuere Digital Credentials Query Language (DCQL), die in die presentation_definition der Anfrage eingebettet ist. Dies ermöglicht es RPs, die benötigten Nachweistypen und einzelnen Claims zu spezifizieren. Das Wallet konstruiert dann eine Verifiable Presentation, die nur die angeforderten Informationen enthält, sofern dies vom Nachweisformat und dem Wallet unterstützt wird.

Rps müssen ihre spezifischen Datenanforderungen auf diese unterschiedlichen Protokollstrukturen abbilden. Es ist entscheidend, die Nuancen zu verstehen, wie die selektive Offenlegung in jedem Protokoll implementiert und angefordert wird, um sicherzustellen, dass nur die minimal notwendigen Daten angefordert und verarbeitet werden, und somit den Best Practices für den Datenschutz und den Grundsätzen der Datenminimierung zu entsprechen. Das Format und die Struktur der vom Wallet zurückgegebenen offengelegten Daten können ebenfalls unterschiedlich sein, was eine separate Parsing- und Validierungslogik auf dem Backend des RPs erfordert.

Für Entitäten, die digitale Nachweise ausstellen und Wallet-Anwendungen für Holder bereitstellen möchten, spielt die Betriebssystemumgebung eine entscheidende Rolle.

Wallet-Issuer stehen auf iOS und Android vor deutlich unterschiedlichen Landschaften in Bezug auf die Erstellung von Wallets, die Systemintegration und die Interaktion mit der Digital Credentials API.

• Android: Bietet im Allgemeinen ein offeneres Ökosystem. Der Android Credential Manager enthält eine Holder-API, die es nativen Drittanbieter-Anwendungen ermöglicht, sich als Holder von Nachweisen zu registrieren. Diese registrierten Holder-Apps können dann an vom System vermittelten Präsentationsabläufen teilnehmen und auf Anfragen der Digital Credentials API (über Chrome) oder von nativen App-Verifiern reagieren. Android unterstützt auch explizit OpenID4VCI für die Ausstellung von Nachweisen, sodass Nutzer ein kompatibles Drittanbieter-Wallet wählen können, um neu ausgestellte Nachweise zu erhalten. Obwohl native Apps der Hauptfokus für volle Holder-Fähigkeiten sind, ist das System für eine breitere Beteiligung konzipiert.

• iOS: Apple behält eine strengere Kontrolle über sein Ökosystem. Während Drittanbieter-Wallet-Apps im App Store existieren können, unterliegt ihre Fähigkeit, sich tief als systemweite Holder für hochsichere Nachweise (wie mDLs, die für die Apple Wallet bestimmt sind) zu integrieren, oft den spezifischen Prozessen und Berechtigungen von Apple. Das Hinzufügen eines Ausweises zur Apple Wallet ist beispielsweise ein kontrollierter Ablauf, der staatliche Ausstellungsbehörden und Apples Verifizierung einbezieht. Für die Digital Credentials API in Safari werden Interaktionen wahrscheinlich eng verwaltet, mit einem Hauptfokus auf org.iso.mdoc, das von autorisierten Quellen präsentiert wird, nämlich der Apple Wallet selbst und registrierten Drittanbieter-Dokumentenanbieter-Apps.

Apples „Walled Garden“-Ansatz (geschlossenes Ökosystem) ist altbekannt, und ihre Implementierung von digitalen Nachweisen ist keine Ausnahme. Die WWDC25 hat jedoch den Weg für die Teilnahme von Drittanbietern geklärt.

Während die Apple Wallet der primäre, eingebaute Anbieter für Nachweise wie staatliche mDLs ist, hat Apple das IdentityDocumentServices-Framework für native iOS-Apps eingeführt. Dies ermöglicht es Drittentwicklern, Anwendungen zu erstellen, die ihre eigenen Identitätsdokumente bereitstellen und präsentieren können.

Um am Web-Flow teilzunehmen, muss eine native App:

1. Dokumente registrieren: Den IdentityDocumentProviderRegistrationStore verwenden, um die von der App verwalteten mdocs beim Betriebssystem zu registrieren. Diese Registrierung umfasst den Dokumenttyp und die vertrauenswürdigen Zertifizierungsstellen für die Signierung von Anfragen.
2. Eine App-Erweiterung implementieren: Eine „Identity Document Provider“ UI App Extension zum Projekt hinzufügen. Diese Erweiterung ist dafür verantwortlich, die Autorisierungs-UI für den Nutzer anzuzeigen, wenn die App während eines webbasierten Verifizierungsflusses ausgewählt wird.

Das bedeutet, dass die Erstellung eines vollständig integrierten Wallets auf iOS den Bau einer nativen Anwendung und die Verwendung von Apples spezifischen Frameworks erfordert – nicht von Web-Technologien wie PWAs. Es gibt jedoch einen klaren, wenn auch streng kontrollierten Mechanismus für Drittanbieter-Apps, um neben der Apple Wallet als Dokumentenanbieter zu fungieren. Dies bestätigt, dass die Interaktion mit der Digital Credentials API in Safari vom Betriebssystem verwaltet wird, das dann Anfragen an die Apple Wallet oder eine andere registrierte und autorisierte Dokumentenanbieter-App weiterleitet.

Die Digital Credentials API stellt einen bedeutenden Fortschritt im Bereich der digitalen Identität dar und bietet einen sichereren, nutzerzentrierten und datenschutzfreundlicheren Ansatz zur Identitätsprüfung und Präsentation von Nachweisen. Während sich das Ökosystem weiterentwickelt, ist es für Relying Parties und Wallet-Issuer entscheidend, sich anzupassen und das Potenzial dieser neuen Technologie zu nutzen. Wir werden diesen Artikel auf dem neuesten Stand halten, während sich die Landschaft verändert.

Allerdings bleiben Herausforderungen bestehen. Die Erreichung einer echten globalen Interoperabilität zwischen verschiedenen Nachweisformaten, Protokollen und Wallet-Implementierungen ist ein bedeutendes Unterfangen. Die Auseinandersetzung mit den berechtigten Bedenken von Organisationen wie Mozilla bezüglich Datenschutz, Ausgrenzung und Nutzerautonomie ist von größter Bedeutung, um sicherzustellen, dass diese Technologien der Menschheit dienen. Die derzeitige Fragmentierung bei der Browser-Unterstützung und dem Protokollfokus bedeutet, dass Relying Parties und Wallet-Issuer vorerst eine komplexe Landschaft navigieren müssen.