Digital Credentials API (2025): Support in Chrome & Safari ist live

Letzte Aktualisierung: 30. Oktober 2025

Ein kurzer Ü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:

Want to experience digital credentials in action?

Try Digital Credentials

Was hat sich seit Juli 2025 geändert?

• Veröffentlicht: Chrome 141 (30. Sept. 2025) & Safari 26 (15. Sept. 2025).
• Chrome: Protokollunabhängig (OpenID4VP und ISO 18013-7 Anhang C), geräteübergreifend auf dem Desktop über CTAP.
• Safari: nur mdoc (org-iso-mdoc), geräteübergreifender Flow via CTAP.
• API-Struktur: navigator.credentials.get(); Benennung requests/data; Feature-Erkennung DigitalCredential.

Digitale Nachweise sind derzeit ein heißes Thema im Bereich der Identität. Da unser Leben zunehmend mit der digitalen Welt vernetzt ist, war die Notwendigkeit sicherer, nutzerzentrierter und datenschutzfreundlicher Methoden zur Bestätigung unserer Identität und Qualifikationen online noch nie so wichtig. Traditionelle Methoden sind in die Jahre gekommen und die Nachfrage nach robusteren Lösungen ist spürbar.

In diesem Artikel besprechen wir den aktuellen Stand der Digital Credentials API, 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 und die aktuelle Browser-Akzeptanz untersuchen 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 beispiellosen Informationsaustausch ermöglichte, eröffnete es auch neue Wege für Täuschung und Betrug.

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

Die Ausweichlösung für die Identitätsprüfung in vielen Regionen umfasste traditionell aufwändige Prozesse. Die physische Überprüfung 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 Dokumentenscannens und der Liveness Checks. Trotz ihrer Fortschritte haben diese Methoden erhebliche Nachteile. Sie können zeitaufwändig, anfällig für menschliche Fehler oder Voreingenommenheit sein und haben sich häufig als anfällig für raffinierte Fälschungen erwiesen.

Die Herausforderung eskaliert dramatisch mit dem Aufkommen von Deepfakes, fortschrittlichen KI-gesteuerten Imitationstechniken und immer ausgefeilteren Phishing-Angriffen. Diese Technologien können äußerst realistische, aber vollständig gefälschte Video-, Audio- und Dokumentenbeweise erstellen, was es für traditionelle Systeme und sogar für KI-gestützte Verifizierungstools unglaublich schwierig macht, echte Nutzer von betrügerischen 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 experience digital credentials in action?

Try Digital Credentials

Um zu verstehen, wie digitale Nachweise funktionieren, müssen wir die beteiligten Hauptakteure und die verschiedenen technologischen Schichten betrachten, 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 User), die den Nachweis vom Issuer erhält und in einer 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 den 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 User (Holder) die Kontrolle über seine eigenen Daten zu geben. Im Gegensatz zu traditionellen Identitätssystemen, bei denen Daten zentral gespeichert oder zwischen Parteien ohne direkte Vermittlung durch den User geteilt werden könnten, betont dieses Modell die Zustimmung des Users 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 seiner digitalen Wallet (geschützt durch die Gerätehardware) aufbewahrt wird, um die Kontrolle über den Nachweis zu beweisen und dessen Vorlage bei einem Verifier zu autorisieren. Dies beinhaltet typischerweise, dass der Verifier eine Challenge (ein zufälliges Datenelement) vorlegt, die die 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 Vorlage zu authentifizieren.

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

Dieser Artikel konzentriert sich auf die Verifizierung digitaler Nachweise und das Prinzip der selektiven Offenlegung, das es Usern 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 in umfassenden Lösungen wie der EU Digital Identity Wallet für rechtsverbindliche Signaturen zu sehen), liegt der Fokus hier, insbesondere bei der Digital Credentials API, auf der Identitäts-Assertion und der Attributverifizierung für Online-Interaktionen, nicht primär auf diesen breiteren Signaturfunktionen.

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

Kernterminologie:

• Digitaler Nachweis: 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. Es fügt Manipulationssicherheit und kryptografischen Beweis hinzu und existiert immer in einer Drei-Parteien-Welt: Issuer → Holder → Verifier.
• Verifiable Credential API: Eine REST/HTTP-Dienstschnittstelle zum Ausstellen, Speichern, Vorlegen 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, die geräteseitige Wallet des Users zu bitten, jeden unterstützten digitalen Nachweis (VC, ISO mDoc, SD-JWT …) auf datenschutzfreundliche Weise vorzulegen.

Man kann sich VCs als Datenmodell, die VC API als Backend-Spezifikation und die DC API als die Frontend-Implementierung vorstellen, die Nachweise im Web präsentiert. Alles oberhalb von Schicht 1 (Datenmodellschicht) ist formatunabhängig; alles darunter hängt vom Nachweisformat ab.

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

1. Ausstellen (VC API - Issuer ↔ Wallet): Die staatliche Kfz-Behörde stellt ein Verifiable Credential aus, das besagt: „Holder ist über 18“.
2. Speichern (Wallet-App - BS): Der Nachweis befindet sich mit seinem kryptografischen Beweis in der Wallet des Users.
3. Anfragen (navigator.credentials.get() via DC API - Website → Browser): Die Website eines Bierladens fragt: „Zeigen Sie mir einen Nachweis, dass der User ≥18 ist.“
4. Vorlegen (DC API leitet an Wallet weiter → OpenID4VP (Protokoll) → VC-Payload): Die Wallet zeigt eine Einverständnis-UI an, der User stimmt zu, die Wallet sendet eine Verifiable Presentation zurück.
5. Überprüfen (VC API - Backend des Bierladens): Das Backend der Website überprüft die Signatur und die DID/den öffentlichen Schlüssel des Issuers; gewährt den Zugang.

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

Warum es diese Trennung gibt:

• 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.
• Wallet ↔ Website-Handshake, der die Privatsphäre schützt: Gelöst durch die DC API.
• Unterschiedliche Vertrauensstufen / Dokumententypen (Regierungsausweis vs. Kurszertifikat): Gelöst durch die Verwendung des richtigen Formats (ISO mDoc für hochsichere IDs; W3C VC für allgemeine Behauptungen) unterhalb 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-Anbindung 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 Schichten 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äsentationsschicht eintauchen und sich speziell auf die Digital Credentials API und ihren aktuellen Zustand konzentrieren.

Als entscheidende Komponente auf der Präsentationsschicht ist die Digital Credentials API ein Webstandard, der derzeit entwickelt wird, um eine sichere und standardisierte Methode für Websites bereitzustellen, um digitale Identitätsinformationen von den digitalen Wallets der User 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 migriert wurde. Die offizielle Entwurfsspezifikation findet sich hier: https://w3c-fedid.github.io/digital-credentials/.

Stand Oktober 2025 ist die API in stabilen Versionen von sowohl Chrome 141 (30. Sept. 2025) als auch Safari 26 (15. Sept. 2025) veröffentlicht. Die Implementierung von Chrome ist protokollunabhängig und unterstützt sowohl OpenID4VP als auch ISO 18013-7 Anhang C, während Safari ausschließlich das org-iso-mdoc-Protokoll unterstützt. Chrome unterstützt dies nativ auf Android über sein Credential Manager-System und unterstützt auch die Cross-Device Digital Credentials API auf dem Desktop über eine CTAP/BLE-gestützte QR-Übergabe.

Die API erweitert die bestehende Credential Management API, indem sie Anfragen nach digitalen Nachweisen ü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 die Fähigkeiten des zugrunde liegenden Betriebssystems, um verfügbare Wallets und Nachweise zu finden, die der Anfrage entsprechen. Browser und Betriebssystem können dann eine konsistente Benutzeroberfläche zur Auswahl des Nachweises und zur Autorisierung seiner Freigabe präsentieren, was die Sicherheit und den Datenschutz erhöht, indem die Zustimmung des Users sichergestellt und verhindert wird, dass Websites unbemerkt auf sensible Daten zugreifen. Die tatsächlichen 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 der Wallet/Holder gehandhabt wird.

Die Digital Credentials API ist so konzipiert, dass sie protokollunabhängig ist, was bedeutet, dass sie verschiedene zugrunde liegende Protokolle für den Nachweis-Austausch unterstützen kann. Zwei Hauptprotokollfamilien 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).

• Ursprung 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 (nahe) Vorlage unter Verwendung von Technologien wie NFC, Bluetooth oder QR-Codes definiert. ISO/IEC 18013-7 erweitert dies, um die Online-/Fernvorlage von mDLs zu ermöglichen. Der Protokollstring „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 Sicherheitsfunktionen, einschließlich der Authentifizierung des Issuers, der Gerätebindung, der Authentifizierung des Holders (über ein Porträt), der Sitzungsverschlüsselung und der selektiven Offenlegung.

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

• Ursprung und Standardisierung: OpenID4VP (für die Vorlage) 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 Nachweistypen 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 nachweisformatunabhängig sind. Sie können W3C Verifiable Credentials (VCs) im JSON/JSON-LD- oder JWT-Format, mdocs, SD-JWTs und andere Formate transportieren. Das Interaktionsmodell umfasst eine Autorisierungsanfrage vom Verifier (RP) und eine Antwort von der Wallet des Holders, die einen 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, Berufszeugnisse), Mitgliedschafts-Attestations und mehr. Sie eignen sich gut für Online-Interaktionen, bei denen eine Relying Party Ansprüche von verschiedenen Issuers ü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 Ökosystemteilnehmern ab.

Die Europäische Union Digital Identity (EUDI) Wallet ist eine große Initiative, die darauf abzielt, allen EU-Bürgern und Einwohnern eine sichere digitale Wallet für Identitätsdokumente und Attestations bereitzustellen. Die Architektur und das Referenz-Framework der EUDI Wallet planen explizit die Unterstützung von sowohl mdoc (insbesondere für mobile Führerscheine) als auch W3C Verifiable Credentials, wobei OpenID4VP und OpenID4VCI für Präsentations- und Ausstellungsabläufe verwendet werden. Die Referenzimplementierung umfasst die Unterstützung für OpenID4VP, das mDocs überträgt, und OpenID4VCI für die Ausstellung 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-amerikanischen Big-Tech-Unternehmen“ beeinflusst wird, tief in die endgültigen Spezifikationen der EUDI Wallet integriert werden könnte. Es wurden Bedenken hinsichtlich des potenziellen Einflusses von Nicht-EU-Unternehmen auf ein kritisches Stück EU-Infrastruktur geäußert, wie in Community-Foren wie dieser GitHub-Diskussion diskutiert wird.

Die Browser-Landschaft für die Digital Credentials API hat sich nun geformt, wobei Chrome 141 und Safari 26 im September 2025 stabilen Support veröffentlicht haben. Es gibt bemerkenswerte Unterschiede in den Ansätzen und Unterstützungsniveaus zwischen den Browsern.

Chrome veröffentlichte die Digital Credentials API in Chrome 141 (30. Sept. 2025). Die Implementierung von Chrome ist protokollunabhängig: kompatibel mit OpenID4VP und ISO 18013-7 Anhang C (mdoc online). Der Desktop unterstützt die geräteübergreifende Präsentation von mobilen Wallets über einen CTAP/BLE-gestützten Kanal (QR-Übergabe), wobei die Antwort für den Browser opak ist. Die API-Struktur wurde auf navigator.credentials.get() umgestellt; Parameter umbenannt: providers → requests, request → data.

Feature-Erkennung:

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API supported
}

Der Credential Manager von Android unterstützt nativ OpenID4VP für die Präsentation und OpenID4VCI für die Ausstellung, was es Android-Apps ermöglicht, als Nachweisinhaber und Verifizierer unter Verwendung dieser Standards zu agieren. Google stellt eine wachsende Wallet-Unterstützung fest; Google Wallet ist ein früher Anwender, Samsung Wallet und 1Password wurden angekündigt.

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 Begründung:

Wie wir richtig erwartet hatten, bestätigte die WWDC25 diese Strategie. Safari 26 (iOS/iPadOS/macOS) wurde am 15. September 2025 mit Unterstützung für die Digital Credentials API veröffentlicht, was bestätigt, dass ihre Implementierung ausschließlich das org-iso-mdoc-Protokoll (mit Bindestrich) 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 anzufordern, wie z. B. einem Führerschein, der in der Apple Wallet oder in Drittanbieter-Dokumenten-Apps gespeichert ist.

Wichtige Erkenntnisse aus Apples Implementierung:

• Nur MDOC: Die API verwendet ausschließlich den Protokollstring "org-iso-mdoc", basierend auf dem Standard ISO/IEC 18013-7 Anhang C. Es gibt keine Unterstützung für OpenID4VP in der Implementierung der Digital Credentials API durch Safari.
• Nur Präsentation: Die API dient zur Präsentation (Verifizierung) bestehender Nachweise. Die Ausstellung in die Apple Wallet oder andere Apps bleibt ein separater, nicht-browserbasierter Prozess.
• Nutzerzentriert & Sicher: Der Ablauf wird durch eine User-Geste initiiert und nutzt einen „partiellen Anfrage“-Mechanismus, bei dem das Betriebssystem die Anfrage zuerst in einer Sandbox parst und validiert, bevor es sie an die Wallet-Anwendung weiterleitet, 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.
• Geräteübergreifende Unterstützung: Die geräteübergreifende Präsentation von Nicht-Apple-Plattformen verwendet CTAP für die Nähe nach einer QR-Code-Übergabe; die JS-Antwort bleibt für den Browser verschlüsselt/opak.

Apple lieferte ein klares Codebeispiel dafür, 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 Browser-Markt. 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 Standardisierungsposition zur Digital Credentials API in ihrer jetzigen Form geäußert. Ihre Bedenken sind umfassend und wurzeln in ihrer Mission, die Privatsphäre der User und deren Handlungsfähigkeit zu schützen sowie ein offenes, gerechtes Web zu gewährleisten.

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 alltäglich werden.
• Ausschluss von Usern: Risiko, dass Personen, die digitale Nachweise nicht 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 Unverknüpfbarkeitsgarantien umgesetzt wird oder wenn die User nicht vollständig verstehen, was geteilt wird.
• Zentralisierung von Vertrauen und User-Handlungsfähigkeit: Befürchtungen, dass die API zu einer verstärkten Zentralisierung von Vertrauen und einer Verringerung der User-Handlungsfähigkeit führen und bestehende gesellschaftliche Machtungleichgewichte aufrechterhalten könnte.

Mozilla erkennt an, dass eine solche API einen Nutzen gegenüber bestehenden Ad-hoc-Methoden zur Vorlage von Nachweisen bieten könnte, betont aber, dass neue Web-Plattform-Funktionen nachweislich das Web insgesamt verbessern und die Interessen der User priorisieren müssen. Obwohl ein W3C-Rat einen formellen Einspruch im Zusammenhang mit diesen Bedenken überstimmte (um die Arbeit innerhalb des W3C anstatt 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 (Okt. 2025)

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

Angesichts der Tatsache, dass Safari (veröffentlicht am 15. Sept. 2025) ausschließlich direkte org-iso-mdoc-Interaktionen (ISO 18013-7 Anhang C) über die Digital Credentials API unterstützt und Chrome (veröffentlicht am 30. Sept. 2025) protokollunabhängig ist und sowohl OpenID4VP als auch ISO 18013-7 Anhang C (mdoc) unterstützt, sollten RPs, die eine möglichst breite Reichweite anstreben, sich darauf vorbereiten, Interaktionen zu unterstützen, die auf beiden Ansätzen basieren.

Das bedeutet, Systeme zu entwickeln, die:

1. Nachweisanfragen über die navigator.credentials.get()-API initiieren können, wobei je nach Browser-Erkennung oder User-Agent-Fähigkeiten unterschiedliche Protokollparameter ("org-iso-mdoc" für Safari oder "openid4vp" für Chrome/OID4VP-Flows) angegeben werden.
2. Antworten verarbeiten können, die entweder direkt im mdoc-Format (ISO 18013-7 Anhang C) 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 User auf einen einzigen Protokollpfad zu zwingen, wahrscheinlich einen erheblichen Teil der User-Basis ausschließen, entweder diejenigen auf iOS oder diejenigen auf Chrome/Android, je nach gewähltem Pfad. Ein pragmatischer, wenn auch entwicklungsintensiverer Ansatz ist es, Flexibilität zu schaffen, um beides zu handhaben.

Relying Parties müssen sich sehr bewusst sein, dass selbst wenn sie dieselbe logische Information anfordern (z. B. „Ist der User ü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 möglicherweise Presentation Exchange oder DCQL verwendet) erheblich abweichen kann.

• mdoc Selektive Offenlegung: org.iso.mdoc hat seine eigenen Mechanismen für die selektive Offenlegung, die typischerweise beinhalten, dass der Issuer gesalzene Hashes einzelner Datenelemente erstellt. Die 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 bestimmten Elementen ist an vordefinierte Namensräume und Datenelement-Identifikatoren innerhalb des mdoc-Standards gebunden.
• OpenID4VP Selektive Offenlegung: 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 anzugeben. Die Wallet erstellt dann eine Verifiable Presentation, die nur die angeforderten Informationen enthält, sofern dies vom Nachweisformat und der 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, wodurch die besten Praktiken zum Datenschutz und die Grundsätze der Datenminimierung eingehalten werden. Das Format und die Struktur der von der Wallet zurückgegebenen offengelegten Daten können ebenfalls unterschiedlich sein, was eine unterschiedliche Analyse- und Validierungslogik im Backend des RP erfordert.

Für Instanzen, 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 Wallet-Erstellung, 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 Nachweisinhaber zu registrieren. Diese registrierten Holder-Apps können dann an vom System vermittelten Nachweispräsentationsflüssen teilnehmen und auf Anfragen von der Digital Credentials API (über Chrome) oder von nativen App-Verifizierern antworten. Android unterstützt auch explizit OpenID4VCI für die Ausstellung von Nachweisen, sodass User eine kompatible Drittanbieter-Wallet auswählen können, um neu ausgestellte Nachweise zu erhalten. Obwohl native Apps der Hauptfokus für volle Nachweisinhaber-Fähigkeiten sind, ist das System für eine breitere Teilnahme ausgelegt.

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

Apples „Walled Garden“-Ansatz ist gut etabliert, und ihre Implementierung digitaler Nachweise ist keine Ausnahme. Die WWDC25 klärte jedoch den Weg für die Teilnahme von Drittanbietern.

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 vorlegen können.

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

1. Dokumente registrieren: Verwenden Sie den IdentityDocumentProviderRegistrationStore, um die von der App verwalteten mdocs beim Betriebssystem zu registrieren. Diese Registrierung umfasst den Dokumententyp und die vertrauenswürdigen Zertifizierungsstellen für die Anforderungssignierung.
2. Eine App-Erweiterung implementieren: Fügen Sie dem Projekt eine „Identity Document Provider“-UI-App-Erweiterung hinzu. Diese Erweiterung ist für die Anzeige der Autorisierungs-UI für den User verantwortlich, wenn die App während eines webbasierten Verifizierungsflusses ausgewählt wird.

Das bedeutet, dass die Erstellung einer vollständig integrierten Wallet auf iOS den Bau einer nativen Anwendung und die Verwendung der spezifischen Frameworks von Apple 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 agieren. 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, nutzerzentrierteren und datenschutzfreundlicheren Ansatz zur Identitätsüberprüfung und Vorlage von Nachweisen. Mit der Veröffentlichung stabiler Unterstützung in Chrome 141 (30. Sept. 2025) und Safari 26 (15. Sept. 2025) ist die API von experimentell zu produktionsreif übergegangen. Da sich das Ökosystem weiterentwickelt, ist es für Relying Parties und Wallet-Anbieter entscheidend, sich anzupassen und das Potenzial dieser neuen Technologie zu nutzen. Wir werden diesen Artikel auf dem neuesten Stand halten, wenn sich die Landschaft ändert.

Es bleiben jedoch Herausforderungen bestehen. Die Erreichung einer echten globalen Interoperabilität zwischen verschiedenen Nachweisformaten, Protokollen und Wallet-Implementierungen ist eine bedeutende Aufgabe. Die Auseinandersetzung mit den berechtigten Bedenken von Organisationen wie Mozilla bezüglich Datenschutz, Ausgrenzung und User-Handlungsfähigkeit ist von größter Bedeutung, um sicherzustellen, dass diese Technologien der Menschheit dienen. Die unterschiedlichen Ansätze – die protokollunabhängige Implementierung von Chrome gegenüber dem mdoc-only-Fokus von Safari – bedeuten, dass Relying Parties und Wallet-Anbieter auf absehbare Zeit eine duale Protokolllandschaft navigieren müssen.