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

Zuletzt aktualisiert: 26. März 2026

Hier ist ein schneller Überblick über den Support der Digital Credentials API in den wichtigsten Browsern:

Die Welt der Digital Credentials bewegt sich schnell. Hier ist eine Momentaufnahme der wichtigsten Entwicklungen und Prognosen:

Want to experience digital credentials in action?

Try Digital Credentials

Was hat sich seit Oktober 2025 geändert?

• Wechsel in der Protokoll-Governance: Die W3C FedID WG hat auf dem TPAC (Nov 2025) die offene Protokoll-Registry eliminiert und codiert unterstützte Protokolle nun hart direkt in der Spezifikation: OpenID4VP, OpenID4VCI und ISO 18013-7 Annex C. Die API ist keine „blanke Leitung“ (Dumb Pipe) mehr.
• Issuance kommt: Chrome 143 startete einen Origin Trial für Credential Issuance via navigator.credentials.create(), was die API über reine Präsentation hinaus erweitert.
• Firefox implementiert: Trotz unveränderter negativer Standard-Position hat Mozilla grundlegenden DC API Code in Firefox 149 integriert, wobei noch an der UX gearbeitet wird.
• EU-bedingtes Mandat: Das EUDI Architecture Reference Framework (Topic F) verlangt nun bedingt DC API Support für alle Wallets der Mitgliedstaaten.
• Adoption in der echten Welt: Das California DMV hat seiner OpenCred-Plattform (Feb 2026) DC API Support hinzugefügt.

Digital Credentials sind aktuell ein heißes Thema im Identitätsbereich. Da unser Leben zunehmend mit der digitalen Welt verknüpft ist, war der Bedarf an sicheren, nutzerzentrierten und datenschutzfreundlichen Möglichkeiten, unsere Identität und Qualifikationen online nachzuweisen, noch nie so kritisch. Traditionelle Methoden kommen in die Jahre, und die Nachfrage nach robusteren Lösungen ist spürbar.

In diesem Artikel schauen wir uns den aktuellen Stand der Digital Credentials API an – eine wichtige Entwicklung, die verspricht, neu zu gestalten, wie wir mit Identitätsinformationen im Web interagieren. Wir erkunden die zugrundeliegenden Mechanismen, die unterstützten Protokolle, die aktuelle Browser-Adoption und geben Empfehlungen für sowohl Relying Parties als auch Wallet Issuer, die sich in dieser sich schnell entwickelnden Landschaft bewegen.

Identität zuverlässig und sicher nachzuweisen, ist seit vielen Jahren eine beständige Herausforderung in der Web-Architektur. Während das Internet beispiellose Konnektivität und Informationsaustausch ermöglichte, öffnete es auch neue Wege für falsche Darstellungen und Betrug.

In einigen Ländern entstanden Lösungen, primär getrieben durch frühe Banken-Konsortien, die Dienste entwickelten, um bestehende vertrauenswürdige Beziehungen für die Online-Identifikation zu nutzen. Auch Regierungen schalteten sich ein und schrieben nationale digitale Identitäts- Wallets und Dienste vor oder stellten diese bereit. Diese Lösungen waren jedoch oft isoliert, geografisch begrenzt und nicht universell interoperabel.

Der Rückfall für Identitätsverifikation in vielen Regionen beinhaltete traditionell Prozesse mit hohen Hürden. Physische Verifikation in einer Postfiliale führt beispielsweise zu erheblichen Verzögerungen und Unannehmlichkeiten. Videoanrufe kombiniert mit Dokumenten-Uploads wurden zu einer digitaleren Alternative, gefolgt vom jüngeren Aufstieg des automatisierten Dokumentenscannens und Liveness-Checks. Trotz ihrer Fortschritte haben diese Methoden deutliche Nachteile. Sie können zeitaufwändig sein, anfällig für menschliche Fehler oder Vorurteile und wurden häufig als verwundbar gegenüber ausgefeilten Fälschungen entlarvt.

Die Herausforderung eskaliert dramatisch mit dem Aufkommen von Deepfakes, fortschrittlichen KI-gesteuerten Techniken zur Identitätsfälschung und immer raffinierteren Phishing-Attacken. Diese Technologien können hochrealistische, aber komplett fabrizierte Video-, Audio- und Dokumentenbeweise erstellen, was es für traditionelle Systeme und sogar KI-gestützte Verifikations-Tools unglaublich schwer macht, echte Nutzer von Betrügern zu unterscheiden. Das Potenzial, synthetische Identitäten zu schaffen oder biometrische Daten zu manipulieren, um Prüfungen zu umgehen, ist eine ernsthafte Bedrohung, insbesondere für Finanzinstitute und jeden Dienst, der robuste „Know Your Customer“ (KYC) Prozesse benötigt. Diese eskalierende Bedrohungslage unterstreicht den dringenden Bedarf an sichereren, kryptografisch verifizierbaren Online-Identitäts- und Verifikationsmechanismen.

Want to experience digital credentials in action?

Try Digital Credentials

Um zu verstehen, wie Digital Credentials funktionieren, muss man sich die beteiligten Hauptakteure und die verschiedenen technologischen Schichten ansehen, die ihre Funktionalität ermöglichen.

Im Kern dreht sich das Konzept der Digital Credentials, besonders im Kontext der neuen Web-APIs, um ein Drei-Parteien-Modell:

1. Issuer (Aussteller): Eine Entität (z.B. Regierung, Universität, Arbeitgeber), die autoritativ für bestimmte Informationen über ein Subjekt ist und ein digitales Credential ausstellen kann, das diese Informationen bestätigt.
2. Holder (Inhaber): Das Subjekt der Informationen (d.h. der User), das das Credential vom Issuer empfängt und es in einer digitalen Wallet speichert. Der Holder kontrolliert, wann und welche Informationen aus dem Credential geteilt werden.
3. Verifier (oder Relying Party): Eine Entität (z.B. eine Website, ein Online-Dienst), die bestimmte Informationen über den Holder verifizieren muss, um Zugang zu einem Dienst oder einer Ressource zu gewähren. Der Verifier fordert die notwendigen 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. Anders als bei traditionellen Identitätssystemen, wo Daten zentral gespeichert oder zwischen Parteien ohne direkte Nutzervermittlung geteilt werden könnten, betont dieses Modell die Zustimmung des Nutzers und die selektive Offenlegung (Selective Disclosure). Der Holder entscheidet, welche Teile der Informationen aus einem Credential für eine spezifische Transaktion geteilt werden, anstatt das gesamte Credential offenzulegen.

Ein grundlegender Aspekt dieser Systeme ist der Einsatz von kryptografischen Schlüsselpaaren. Der Issuer signiert das Credential digital und stellt so dessen Authentizität und Integrität sicher. Der Holder nutzt wiederum seinen privaten Schlüssel, oft gesichert in seiner digitalen Wallet (die durch Geräte-Hardware geschützt ist), um die Kontrolle über das Credential zu beweisen und dessen Präsentation gegenüber einem Verifier zu autorisieren. Dies beinhaltet typischerweise, dass der Verifier eine Challenge (ein zufälliges Datenstück) stellt, die die Wallet des Holders mit dem privaten Schlüssel signiert, der mit dem Credential assoziiert ist. Der Verifier kann dann den entsprechenden öffentlichen Schlüssel nutzen, um die Signatur zu bestätigen und so die Präsentation zu authentifizieren.

Diese Erklärung ist protokollneutral, da die Kernprinzipien von Ausstellung (Issuance), Besitz (Holding) und Verifikation durch kryptografische Challenges über verschiedene zugrundeliegende Technologien hinweg gleich sind.

Dieser Artikel konzentriert sich auf die Verifikation von Digital Credentials und das Prinzip der Selective Disclosure, das es Nutzern ermöglicht, spezifische Attribute (z.B. „Ich bin über 18“, „Ich besitze einen gültigen Führerschein“) zu beweisen, ohne das gesamte Quelldokument offenzulegen. Während die zugrundeliegenden Systeme für Digital Credentials Features wie qualifizierte elektronische Signaturen (QES) und Fernsignatur-Fähigkeiten unterstützen können (wie in umfassenden Lösungen wie der EU Digital Identity Wallet für rechtlich bindende Signaturen gesehen), liegt der Fokus hier, besonders für die Digital Credentials API, auf Identitäts-Assertion und Attribut-Verifikation für Online-Interaktionen, nicht primär auf diesen breiteren Signatur-Funktionalitäten.

Um zu verstehen, wie Digital Credentials funktionieren, ist es hilfreich, ein Schichtenmodell zu visualisieren. Jede Schicht adressiert einen anderen Aspekt des Ökosystems, vom Datenformat selbst bis hin zur Art und Weise, wie es einem Nutzer im Webbrowser präsentiert wird. Dieser Artikel konzentriert sich primär auf die Digital Credentials API, die auf der Präsentationsschicht operiert.

Kernbegriffe:

• Digital Credential: Jedes maschinenlesbare Credential (PDF mit Barcode, ISO mDL, W3C VC, SD-JWT, etc.). „Digital“ sagt nichts über kryptografische Verifizierbarkeit aus.
• Verifiable Credential: Eine Art von Digital Credential, 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: Ein REST/HTTP Service-Interface für das Ausstellen, Speichern, Präsentieren und Verifizieren von VCs zwischen Back-End-Systemen (Issuers, Wallets, Verifiers).
• Digital Credentials API (DC API): Eine Browser- / Betriebssystem-API (JavaScript + native Verrohrung), die es einer Website ermöglicht, die geräteseitige Wallet des Nutzers zu bitten, ein unterstütztes Digital Credential (VC, ISO mDoc, SD-JWT …) auf datenschutzfreundliche Weise zu präsentieren.

Denkt an VCs als ein Datenmodell, VC API als eine Back-End-Spezifikation und DC API als die Front-End-Implementierung, die Credentials im Web präsentiert. Alles über Schicht 1 (Datenmodell-Schicht) ist formatagnostisch; alles darunter hängt vom Credential-Format ab.

End-to-End Flow (Beispiel: Online-Altersverifikation):

Das folgende Diagramm illustriert, wie diese Schichten in einem realen Szenario zusammenarbeiten.

Beachtet, wie die Daten ein VC sind, der Transport im Web die DC API ist, das Austauschprotokoll darunter OpenID4VP ist und der serverseitige Check die VC API nutzt.

Warum die Aufteilung existiert:

• Interoperables Datenmodell (kryptografische Beweise, Selective Disclosure): Gelöst durch VC Data Model (& andere Formate).
• Standard REST-Endpunkte für Back-End-Systeme: Gelöst durch VC API.
• Wallet ↔ Website Handshake, der die Privatsphäre wahrt: Gelöst durch DC API.
• Verschiedene Vertrauensniveaus / Dokumententypen (Regierungs-ID vs. Kurszertifikat): Gelöst durch die Nutzung des richtigen Formats (ISO mDoc für Hochsicherheits-IDs; W3C VC für allgemeine Claims) unterhalb der DC API.

Wichtige Erkenntnisse:

1. „Digital Credential“ ist der Überbegriff.
2. Verifiable Credential ist eine Art von Digital Credential mit eingebauter kryptografischer Verifizierbarkeit.
3. VC API ist Server-zu-Server-Technik für Lebenszyklus-Operationen von VCs.
4. Digital Credentials API ist die Brücke vom Browser zur Wallet, die diese Credentials endlich reibungslos in Web-Apps fließen lässt, egal in welchem konkreten Format sie vorliegen.
5. Die drei Teile sind komplementär, nicht konkurrierend – sie sitzen auf verschiedenen Schichten desselben Stacks und ermöglichen gemeinsam sichere, nutzerzentrierte Identität im offenen Web.

Nachdem wir die Teilnehmer und die geschichtete Architektur von Digital Credentials erkundet haben, wird dieser Artikel nun tiefer in die Präsentationsschicht eintauchen und sich spezifisch auf die Digital Credentials API und ihren aktuellen Status konzentrieren.

Als entscheidende Komponente auf der Präsentationsschicht ist die Digital Credentials API ein Web-Standard, der entwickelt wird, um einen sicheren und standardisierten Weg für Websites bereitzustellen, digitale Identitätsinformationen von den digitalen Wallets der Nutzer anzufordern. Diese Bemühung ist primär in der Federated Identity Working Group (FedID WG) des W3C angesiedelt, nachdem sie im April 2025 von der FedID Community Group dorthin migriert ist. Der offizielle Spezifikationsentwurf ist hier zu finden: https://w3c-fedid.github.io/digital-credentials/.

Seit Oktober 2025 wurde die API in stabilen Versionen sowohl in Chrome 141 (30. Sept. 2025) als auch in Safari 26 (15. Sept. 2025) ausgeliefert. Chromes Implementierung unterstützt sowohl OpenID4VP als auch ISO 18013-7 Annex C, während Safari exklusiv das org-iso-mdoc-Protokoll unterstützt.

Wichtig (Update März 2026): Die Beziehung der API zu Protokollen hat sich grundlegend geändert. Auf dem TPAC im November 2025 erzielte die W3C FedID WG Konsens darüber, die offene Protokoll-Registry zu eliminieren und stattdessen eine endliche Liste unterstützter Protokolle direkt in der Spezifikation fest zu codieren: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc (für Präsentation) und openid4vci-v1 (für Issuance). Von User Agents wird erwartet, dass sie nicht gelistete Protokolle ablehnen. Dies macht die Working Group de facto zum „Türsteher“ für zukünftige Protokoll-Ergänzungen – ein bewusster Kompromiss, um eine ganzheitliche Sicherheits- und Datenschutzüberprüfung von allem zu ermöglichen, was durch die API fließt (siehe den aktuellen Working Draft).

Die Spec deckt nun auch Credential Issuance (Ausstellung) via navigator.credentials.create() ab. Chrome 143 startete hierfür einen Origin Trial, der es Websites erlaubt, Wallet-Provisionierungs-Flows mittels OpenID4VCI auszulösen. Jedoch bleibt eine Sicherheitslücke bei der Wallet-Auswahlbindung (Wallet Selection Binding Vulnerability) – bei der eine bösartige Wallet-App Vorab-Autorisierungscodes für die Ausstellung abfangen kann – ein offenes Problem. Regierungs-Aussteller haben signalisiert, dass sie Browser-vermittelte Ausstellung nicht übernehmen werden, bis dies gelöst ist.

Chrome unterstützt die Präsentation nativ auf Android durch sein Credential Manager System und unterstützt auch Cross-Device Digital Credentials API auf dem Desktop via CTAP/BLE-gestützter QR-Übergabe.

Die API erweitert die bestehende Credential Management API, indem sie Anfragen für Digital Credentials durch 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 zu diesem etablierten Interface zurückgekehrt, anstatt das zuvor vorgeschlagene navigator.identity zu nutzen. Eine Website fordert ein Digital Credential an, indem sie navigator.credentials.get() mit spezifischen Parametern für Digital Credentials aufruft.

Hier ist ein illustratives Beispiel, wie eine Website die API aufrufen könnte, um ein Credential mittels OpenID4VP anzufordern:

async function requestCredential() {
    // Prüfen auf Digital Credentials API Support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // Diese Parameter werden typischerweise vom Backend abgerufen.
            // Hier statisch definiert für Illustrationszwecke der Protokollerweiterbarkeit.
            const oid4vp = {
                protocol: "oid4vp", // Ein Beispiel für eine OpenID4VP Anfrage an Wallets. // Basierend auf https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        // Presentation Exchange Anfrage, der Kürze halber weggelassen
                    },
                },
            };
 
            // Erstelle einen Abort Controller
            const controller = new AbortController();
 
            // Rufe die Digital Credentials API mit der Präsentationsanfrage vom Backend auf
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Sende die verschlüsselte Antwort zur Entschlüsselung und Verifikation ans Backend
            // Der Kürze halber weggelassen
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // Fallback-Szenario, nur zur Illustration
        alert("Die Digital Credentials API wird in diesem Browser nicht unterstützt.");
    }
}

Dieses Beispiel stammt von hier.

Die Digital Credentials API agiert im Wesentlichen als sicherer Wrapper oder Vermittler. Sie erlaubt dem Browser, die Anfrage für Identitätsinformationen zu vermitteln, indem er die Fähigkeiten des zugrundeliegenden Betriebssystems nutzt, um verfügbare Wallets und Credentials zu entdecken, die zur Anfrage passen. Der Browser und das OS können dann ein konsistentes User Interface präsentieren, um das Credential auszuwählen und dessen Freigabe zu autorisieren. Dies erhöht Sicherheit und Datenschutz, indem Nutzerzustimmung sichergestellt und verhindert wird, dass Websites stillschweigend auf sensible Daten zugreifen. Die eigentlichen Credential-Daten in der Antwort sollen für den Browser selbst undurchsichtig (verschlüsselt) sein, wobei Entschlüsselung und Interpretation von der Relying Party und der Wallet/dem Holder gehandhabt werden.

Die Digital Credentials API war ursprünglich so konzipiert, dass sie vollständig protokoll-agnostisch ist und als „blanke Leitung“ (Dumb Pipe) mit einer offenen Registry für jedes Protokoll fungiert. Seit Januar 2026 benennt die Spec jedoch explizit die Protokolle, die sie unterstützt – von User Agents wird erwartet, dass sie nicht gelistete ablehnen. Die zwei Hauptfamilien von Protokollen, die derzeit in der Spec festgeschrieben sind, sind: org.iso.mdoc (abgeleitet von ISO 18013-5 und dessen Erweiterung ISO 18013-7 „Annex C“) und die OpenID for Verifiable Presentations (OpenID4VP) und OpenID for Verifiable Credential Issuance (OpenID4VCI) Spezifikationen der OpenID Foundation.

• Ursprung und Standardisierung: org.iso.mdoc bezieht sich auf das Datenformat und Interaktionsmodell für mobile Dokumente, primär mobile Führerscheine (mDLs), standardisiert durch die Internationale Organisation für Normung (ISO) und die Internationale Elektrotechnische Kommission (IEC). Der grundlegende Standard ist ISO/IEC 18013-5, welcher die mDL Applikation, Datenstruktur und Protokolle für die Präsentation vor Ort (Proximity) mittels Technologien wie NFC, Bluetooth oder QR-Codes definiert. ISO/IEC 18013-7 erweitert dies, um Online-/Remote-Präsentation von mDLs zu ermöglichen. Der Protokoll-String „org.iso.mdoc“ ist spezifisch in ISO/IEC TS 18013-7 (Annex C) für die Nutzung mit APIs wie der Digital Credentials API definiert.

• Datenmodell: mdocs haben eine strikt definierte Datenstruktur basierend auf CBOR (Concise Binary Object Representation) für Kompaktheit und Effizienz. Es spezifiziert Namespaces und Datenelemente für gängige Führerscheinattribute und unterstützt starke kryptografische Sicherheitsfeatures, inklusive Issuer-Authentifizierung, Gerätebindung, Holder-Authentifizierung (via Porträt), Session-Verschlüsselung und Selective Disclosure.

• Typische Anwendungsfälle: Primär von Regierungen ausgestellte Identitätsdokumente wie Führerscheine und nationale Ausweise. Es ist für Hochsicherheits-Szenarien konzipiert, sowohl persönlich (z.B. Verkehrskontrollen, Altersverifikation für beschränkte Waren) als auch online (z.B. Zugang zu Regierungsdiensten, Remote-Identitätsverifikation für Kontoeröffnungen).

• Ursprung und Standardisierung: OpenID4VP (für Präsentation) und OpenID4VCI (für 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 breite Interoperabilität für diverse Credential-Typen abzielen, nicht nur Regierungsdokumente. Stand Anfang 2025 ist OpenID4VP in fortgeschrittenen Entwurfsstadien (z.B. Draft 28 im April). OpenID4VCI reift ebenfalls.
• Datenmodell: OpenID4VP/VCI sind so konzipiert, dass sie Credential-formatagnostisch sind. Sie können W3C Verifiable Credentials (VCs) in JSON/JSON-LD oder JWT Formaten, mdocs, SD-JWTs und andere Formate transportieren. Das Interaktionsmodell beinhaltet einen Authorization Request vom Verifier (RP) und eine Antwort von der Wallet des Holders, die einen vp_token (Verifiable Presentation Token) enthält. Selective Disclosure wird typischerweise mittels Abfragesprachen wie Presentation Exchange (DIF PE) oder der neueren Digital Credentials Query Language DCQL verwaltet.
• Typische Anwendungsfälle: Ein breites Spektrum an Anwendungen, inklusive Identitätsverifikation, Nachweis von Qualifikationen (z.B. Bildungsdiplome, professionelle Zertifizierungen), Mitgliedschafts-Attestierungen und mehr. Sie eignen sich gut für Online-Interaktionen, wo eine Relying Party Claims von verschiedenen Issuern verifizieren muss.

Es ist wichtig zu erkennen, dass diese sich nicht immer gegenseitig ausschließen. OpenID4VP kann zum Beispiel genutzt werden, um ein [org.iso.mdoc] anzufordern und zu transportieren. Die Wahl hängt oft vom spezifischen Anwendungsfall, dem Typ des Credentials und den Teilnehmern im Ökosystem ab.

Die European Union Digital Identity (EUDI) Wallet ist eine große Initiative mit dem Ziel, allen EU-Bürgern und Einwohnern eine sichere digitale Wallet für Identitätsdokumente und Attestierungen bereitzustellen. Die Architektur und das Rahmenwerk der EUDI Wallet planen explizit, sowohl mdoc (insbesondere für mobile Führerscheine) als auch W3C Verifiable Credentials zu unterstützen, wobei OpenID4VP und OpenID4VCI für Präsentations- und Ausstellungs-Flows genutzt werden. Die Referenzimplementierung beinhaltet Support für OpenID4VP zum Transfer von mDocs und OpenID4VCI zur Ausstellung von PIDs und mDLs in mDoc und SD-JWT-VC Formaten. Dieser duale Support durch ein solches Großprojekt unterstreicht die Wichtigkeit beider Protokollfamilien.

Update März 2026: Das Bekenntnis der EU zur Digital Credentials API ist konkreter geworden. Das EUDI Architecture Reference Framework (ARF) Topic F fordert nun bedingt, dass EUDI Wallet Units und Relying Parties die DC API für Remote-Präsentation und Attestierungs-Ausstellungs-Flows unterstützen. Die Bedingungen beinhalten, dass die DC API den Status einer W3C Recommendation erreicht und Erwartungen rund um Funktionalität, Browser-/OS-Neutralität, Datenschutz und Denial-of-Service-Schutz erfüllt. Das European Wallet Consortium (EWC) hat DC API Testfälle in sein Konformitäts-Testprogramm aufgenommen, und das NOBID Konsortium hat Zahlungs-Piloten unter Nutzung von OpenID4VP abgeschlossen – jenes Protokoll, das die DC API nun transportiert.

Diese Richtung ist jedoch nicht ohne Kritik, da einige Beobachter anmerken, dass die Digital Credentials API, stark beeinflusst von „US Bigtech“-Firmen, tief in die finalen EUDI Wallet Spezifikationen integriert werden könnte. Bedenken wurden laut bezüglich des potenziellen Einflusses von Nicht-EU-Entitäten auf ein kritisches Stück EU-Infrastruktur, wie in Community-Foren wie dieser GitHub Diskussion erörtert. Separat hat die Entscheidung, die ISO 18013-7 Referenz fest zu codieren, einen Einspruch von Ping Identity nach sich gezogen, mit dem Argument, dass die normative Referenzierung einer kostenpflichtigen Spezifikation Prinzipien des offenen Webs widerspricht – ein Anliegen, das als formaler Einspruch (Formal Objection) wieder auftauchen könnte, wenn die Spec zur Candidate Recommendation übergeht.

Die Browser-Landschaft für die Digital Credentials API hat nun Gestalt angenommen, wobei Chrome 141 und Safari 26 im September 2025 stabilen Support ausgeliefert haben. Es gibt bemerkenswerte Unterschiede im Ansatz und Support-Level zwischen den Browsern.

Chrome lieferte die Digital Credentials API in Chrome 141 (30. Sept. 2025) aus. Chromes Implementierung ist protokoll-agnostisch: kompatibel mit OpenID4VP und ISO 18013-7 Annex C (mdoc online). Desktop unterstützt Cross-Device Präsentation von mobilen Wallets via einen CTAP/BLE-gestützten Kanal (QR-Übergabe), wobei die Antwort für den Browser undurchsichtig (opaque) ist. Die API-Form wechselte zu navigator.credentials.get(); Parameter umbenannt: providers → requests, request → data.

Feature Detection:

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API unterstützt
}

Androids Credential Manager unterstützt nativ OpenID4VP zur Präsentation und OpenID4VCI zur Ausstellung, was es Android Apps erlaubt, als Credential Holder und Verifier unter Nutzung dieser Standards zu agieren. Google merkt wachsenden Wallet-Support an; Google Wallet ist ein früher Anwender, Samsung Wallet und 1Password sind angekündigt.

In früheren Versionen dieses Artikels sagten wir voraus, dass Apples Ansatz von Googles abweichen würde, indem man sich auf das org.iso.mdoc Protokoll konzentriert. Historisch gesehen war unsere Begründung wie folgt:

Wie wir korrekt erwartet haben, bestätigte die WWDC25 diese Strategie. Safari 26 (iOS/iPadOS/macOS) wurde am 15. Sept. 2025 mit Digital Credentials API Support ausgeliefert, was bestätigt, dass ihre Implementierung exklusiv das org-iso-mdoc Protokoll (mit Bindestrich) zur Präsentation unterstützt.

Dies wurde in der WWDC25 Session Verify identity documents on the web detailliert. Die API erlaubt es Websites, verifizierbare Informationen von Identitätsdokumenten, wie einem Führerschein, die in Apple Wallet oder in Drittanbieter-Dokumenten-Provider-Apps gespeichert sind, anzufordern.

Hauptmerkmale von Apples Implementierung:

• MDOC-Only: Die API nutzt exklusiv den Protokoll-String "org-iso-mdoc", basierend auf dem ISO/IEC 18013-7 Annex C Standard. Es gibt keinen Support für OpenID4VP in Safaris Implementierung der Digital Credentials API.
• Nur Präsentation: Die API dient der Präsentation (Verifikation) existierender Credentials. Ausstellung in die Apple Wallet oder andere Apps bleibt ein separater Prozess außerhalb des Browsers.
• Nutzerzentriert & Sicher: Der Flow wird durch eine Nutzergeste initiiert und nutzt einen „Partial Request“ Mechanismus, bei dem das OS zuerst die Anfrage in einer Sandbox parst und validiert, bevor es sie an die Wallet-Applikation weitergibt, was die Sicherheit erhöht.
• Erweiterbar für Apps: Zusätzlich zu Apple Wallet können Drittanbieter-Apps als Dokumenten-Provider agieren, indem sie das neue IdentityDocumentServices Framework und eine App Extension implementieren.
• Cross-Device Support: Cross-Device Präsentation von Nicht-Apple-Plattformen nutzt CTAP für die Nähe nach einer QR-Code Übergabe; die JS-Antwort bleibt verschlüsselt/undurchsichtig für den Browser.

Apple stellte ein klares Code-Beispiel bereit, wie eine Relying Party die API nutzen würde:

async function verifyIdentity() {
    try {
        // Server generiert und signiert die Anfragedaten kryptografisch.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // Die Anfrage spezifiziert das 'org-iso-mdoc' Protokoll.
        const request = {
            protocol: "org-iso-mdoc",
            // data enthält den kryptografisch signierten mdoc Request.
            data,
        };
 
        // Die API muss aus einer Nutzergeste heraus aufgerufen werden.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Sende die verschlüsselte Antwort von der Wallet an den Server zur Entschlüsselung und Validierung.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Zeige die verifizierten Details an...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Fehlerbehandlung, z.B. Abbruch durch Nutzer.
    }
}

Diese Bestätigung festigt die divergenten Strategien im Browsermarkt. Während Chrome auf die flexible OpenID4VP Transportschicht baut, nutzt Apple sein tiefes Investment im ISO mdoc Ökosystem, um eine hoch integrierte und sichere, wenn auch weniger flexible Lösung zu bieten, die auf offizielle Identitätsdokumente zugeschnitten ist.

Mozilla äußerte ursprünglich eine negative Standard-Position zur Digital Credentials API. Ihre Bedenken, im Detail dokumentiert, sind umfassend und verwurzelt in ihrer Mission, Nutzer-Privatsphäre und Handlungsfähigkeit zu schützen und ein offenes, gerechtes Web sicherzustellen.

Zu den Hauptbedenken von Mozilla gehören:

• Datenschutzrisiken: Potenzial für erhöhtes Teilen persönlicher Daten und eine Reduktion der Online-Anonymität, wenn Anfragen für Digital Credentials für triviale Interaktionen alltäglich werden.
• Nutzer-Ausschluss: Risiko, dass Individuen, die Digital Credentials nicht nutzen können oder wollen, von Online-Diensten und Gemeinschaften ausgeschlossen werden könnten. Von der Regierung ausgestellte Credentials, ein Hauptanwendungsfall, stimmen möglicherweise nicht mit der Wahl der Identitätspräsentation eines Individuums überein.
• Interoperabilitäts-Probleme: Bedenken über eine Verbreitung von Credential-Formaten, was zu einem fragmentierten Ökosystem statt zu einem universell interoperablen führt.
• Selective Disclosure: Sorgen, dass die Datenschutzvorteile von Selective Disclosure untergraben werden könnten, wenn sie nicht mit starken Garantien der Unverknüpfbarkeit (Unlinkability) implementiert werden, oder wenn Nutzer nicht vollständig verstehen, was geteilt wird.
• Zentralisierung von Vertrauen und Nutzer-Handlungsfähigkeit: Ängste, dass die API zu erhöhter Zentralisierung von Vertrauen und einer Reduktion der Nutzer-Handlungsfähigkeit führen könnte, was bestehende gesellschaftliche Machtungleichgewichte verstetigt.

Während ein W3C Council einen formalen Einspruch überstimmte, der sich auf diese Bedenken bezog (um die Arbeit innerhalb des W3C fortzusetzen statt an potenziell weniger transparenten Orten), empfahl das Council, dass die Working Group aktiv daran arbeiten soll, diese potenziellen Schäden zu mindern.

Update März 2026 – Implementierung läuft: Obwohl die formale negative Position technisch unverändert bleibt, hat Mozilla begonnen, die Digital Credentials API aktiv zu implementieren. In Q1 2026 landete grundlegender DC API Support in Firefox 149 (hinter einem Preference-Flag), getrackt unter Meta Bug 2004828. Der Quellcode ist in mozilla-central, inklusive DigitalCredential.cpp, WebIDL Bindings und IPC Verrohrung. Arbeit an Desktop- und Android-Berechtigungsabfragen (Bug 2010091, Bug 2010093) ist im Gange.

Drei Mozilla-Ingenieure – John Schanck, Martin Thomson und Benjamin VanderSloot – sind aktive Mitglieder der W3C FedID Working Group, und Schanck liefert substanzielles, durch Implementierung informiertes Feedback zu wichtigen Spec-PRs, einschließlich des Credential Präsentations-Algorithmus und des Anfrage-Vorbereitungs-Algorithmus.

Das ist eine signifikante Entwicklung: Während Mozilla seine Bedenken über das Missbrauchspotenzial der API aufrechterhält, entscheiden sie sich offensichtlich dafür, die API von innen heraus zu formen – sowohl durch Spec-Arbeit als auch Implementierung – anstatt das Design anderen Browser-Herstellern zu überlassen. Es signalisiert, dass die Digital Credentials API wahrscheinlich auf einem Weg zum Drei-Browser-Support ist, wenngleich Mozilla auf stärkere Datenschutz-Leitplanken drängt (einschließlich eines vorgeschlagenen Transparenz-Logs für Credential-Anfragen).

Tabelle 1: Browser-Support für Digital Credentials API & Protokolle (März 2026)

Für Organisationen (Relying Parties oder RPs), die beabsichtigen, Digital Credentials von Nutzern anzufordern und zu verifizieren, erfordert die aktuelle Landschaft sorgfältige strategische Planung.

Da Safari (ausgeliefert am 15. Sept. 2025) exklusiv direkte org-iso-mdoc Interaktionen (ISO 18013-7 Annex C) durch die Digital Credentials API unterstützt, und Chrome (ausgeliefert am 30. Sept. 2025) protokoll-agnostisch ist und sowohl OpenID4VP als auch ISO 18013-7 Annex C (mdoc) unterstützt, sollten RPs, die auf die breiteste mögliche Reichweite abzielen, sich darauf vorbereiten, Interaktionen basierend auf beiden Ansätzen zu unterstützen.

Das bedeutet, Systeme zu architekturieren, die beide Protokollpfade handhaben können, wie unten gezeigt.

Obwohl dies Komplexität hinzufügt, würde der Versuch, alle Nutzer auf einen einzigen Protokollpfad zu zwingen, wahrscheinlich einen erheblichen Teil der Nutzerbasis ausschließen, entweder jene auf iOS oder jene auf Chrome/Android, abhängig vom gewählten Pfad. Ein pragmatischer, wenn auch entwicklungsintensiverer Ansatz ist es, Flexibilität einzubauen, um beides zu handhaben.

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

• mdoc Selective Disclosure: org.iso.mdoc hat seine eigenen Mechanismen für Selective Disclosure, die typischerweise beinhalten, dass der Issuer gesalzene Hashes von individuellen Datenelementen erstellt. Die Wallet des Holders enthüllt dann nur die angeforderten Elemente zusammen mit ihren Salts, was es dem Verifier erlaubt, sie gegen die Hashes zu bestätigen, ohne andere Daten zu sehen. Die Anfrage für spezifische Elemente ist an vordefinierte Namespaces und Datenelement-Identifikatoren innerhalb des mdoc Standards gebunden.
• OpenID4VP Selective Disclosure: OpenID4VP nutzt typischerweise eine Abfragesprache wie Presentation Exchange (DIF PE) oder die neuere Digital Credentials Query Language (DCQL), eingebettet in die presentation_definition der Anfrage. Dies erlaubt RPs, die Credential-Typen und individuellen Claims zu spezifizieren, die sie benötigen. Die Wallet konstruiert dann eine Verifiable Presentation, die nur die angeforderten Informationen enthält, falls dies vom Credential-Format und der Wallet unterstützt wird.

RPs müssen ihre spezifischen Datenanforderungen auf diese variierenden Protokollstrukturen abbilden. Es ist entscheidend, die Nuancen zu verstehen, wie Selective Disclosure in jedem Protokoll implementiert und angefordert wird, um sicherzustellen, dass nur das Minimum an notwendigen Daten angefordert und verarbeitet wird, und so Datenschutz-Best-Practices und Prinzipien der Datenminimierung einzuhalten. Das Format und die Struktur der offengelegten Daten, die von der Wallet zurückgegeben werden, können ebenfalls abweichen, was unterschiedliche Parsing- und Validierungslogik im Backend der RP erfordert.

Für Entitäten, die Digital Credentials ausstellen und Wallet-Applikationen für Holder bereitstellen wollen, spielt die Betriebssystemumgebung eine entscheidende Rolle.

Wallet Issuer sehen sich auf iOS und Android deutlich unterschiedlichen Landschaften gegenüber, was Wallet-Erstellung, Systemintegration und Interaktion mit der Digital Credentials API betrifft.

• Android: Bietet generell ein offeneres Ökosystem. Der Android Credential Manager beinhaltet eine Holder API, die es Drittanbieter-Native-Apps erlaubt, sich als Credential Holder zu registrieren. Diese registrierten Holder-Apps können dann an Credential-Präsentations-Flows teilnehmen, die vom System vermittelt werden, und auf Anfragen von der Digital Credentials API (via Chrome) oder nativen App Verifiern antworten. Android unterstützt auch explizit OpenID4VCI für Credential Issuance, was es Nutzern erlaubt, eine kompatible Drittanbieter-Wallet zu wählen, um neu ausgestellte Credentials zu empfangen. Während native Apps der primäre Fokus für volle Credential Holder Fähigkeiten sind, ist das System für breitere Partizipation ausgelegt.

• iOS: Apple behält striktere Kontrolle über sein Ökosystem. Während Drittanbieter-Wallet-Apps im App Store existieren können, unterliegt ihre Fähigkeit, sich tief als System-Level Credential Holder für Hochsicherheits-Credentials (wie mDLs, die für Apple Wallet gedacht sind) zu integrieren, oft Apples spezifischen Prozessen und Berechtigungen (Entitlements). Eine ID zur Apple Wallet hinzuzufügen, ist beispielsweise ein kontrollierter Flow, der staatliche Ausstellungsbehörden und Apples Verifikation involviert. Für die Digital Credentials API in Safari werden Interaktionen wahrscheinlich eng gemanagt, mit einem primären Fokus auf org.iso.mdoc, präsentiert von autorisierten Quellen, namentlich Apple Wallet selbst und registrierten Drittanbieter-Dokumenten-Provider-Apps.

Apples „Walled Garden“-Ansatz ist wohlbekannt, und ihre Implementierung von Digital Credentials ist keine Ausnahme. Die WWDC25 klärte jedoch den Pfad für Drittanbieter-Partizipation.

Während Apple Wallet der primäre, eingebaute Provider für Credentials wie staatliche mDLs ist, hat Apple das IdentityDocumentServices Framework für native iOS Apps eingeführt. Dies erlaubt Drittanbieter-Entwicklern, Applikationen zu bauen, die ihre eigenen Identitätsdokumente provisionieren und präsentieren können.

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

1. Dokumente registrieren: Den IdentityDocumentProviderRegistrationStore nutzen, um die mdocs, die die App verwaltet, beim Betriebssystem zu registrieren. Diese Registrierung beinhaltet den Dokumententyp und die vertrauenswürdigen Zertifizierungsstellen für das Signieren von Anfragen.
2. Eine App Extension implementieren: Eine „Identity Document Provider“ UI App Extension zum Projekt hinzufügen. Diese Extension ist verantwortlich dafür, dem Nutzer die Autorisierungs-UI anzuzeigen, wenn die App während eines webbasierten Verifikations-Flows ausgewählt wird.

Das bedeutet, dass, während das Erstellen einer voll integrierten Wallet auf iOS das Bauen einer nativen Applikation und die Nutzung von Apples spezifischen Frameworks erfordert – nicht Web-Technologien wie PWAs –, es einen klaren, wenn auch streng kontrollierten Mechanismus für Drittanbieter-Apps gibt, als Dokumenten-Provider neben Apple Wallet zu agieren. Dies bestätigt, dass die Interaktion mit der Digital Credentials API in Safari vom OS gemanagt wird, welches dann Anfragen an Apple Wallet oder jede andere registrierte und autorisierte Dokumenten-Provider-App verteilt.

Die Digital Credentials API repräsentiert einen signifikanten Fortschritt im Bereich der digitalen Identität und bietet einen sichereren, nutzerzentrierten und datenschutzfreundlicheren Ansatz für Identitätsverifikation und Credential-Präsentation. Mit Chrome 141 (30. Sept. 2025) und Safari 26 (15. Sept. 2025), die stabilen Präsentations-Support auslieferten, und Firefox 149, der nun grundlegenden Implementierungscode enthält, ist die API auf dem Weg zu einer Abdeckung durch alle drei Browser. Wir werden diesen Artikel aktuell halten, während sich die Landschaft verändert.

Die Periode seit Oktober 2025 wurde durch die Reifung der API von einer experimentellen Leitung zu einem verwalteten Standard definiert. Die Eliminierung der offenen Protokoll-Registry auf dem TPAC (November 2025) ist das klarste Signal: Die W3C FedID WG benennt und verwaltet nun explizit die Protokolle, die die API unterstützt. Dies ermöglicht umfassende Sicherheits- und Datenschutzüberprüfungen, macht die Working Group aber auch zum Türsteher – ein bewusster Kompromiss, mit dem sich nicht alle Teilnehmer wohlfühlen (notabel bleibt der ISO Paywall Einspruch von Ping Identity ungelöst).

Währenddessen erweitert sich die API von der Präsentation zum vollen Lebenszyklus: Chrome 143s Issuance Origin Trial via navigator.credentials.create() erlaubt es Websites, Wallet-Provisionierung auszulösen. Aber eine Sicherheitslücke bei der Wallet-Auswahlbindung – bei der bösartige Wallet-Apps Issuance-Codes abfangen können – blockiert die Adoption dieses Features durch Regierungen.

An der regulatorischen Front fordert das ARF Topic F der EU bedingt DC API Support für alle EUDI Wallets der Mitgliedstaaten, abhängig davon, dass die Spec W3C Recommendation erreicht. Die Adoption in der echten Welt beschleunigt sich: Das California DMV hat DC API Support hinzugefügt, und Konformitäts-Testsuiten werden vom European Wallet Consortium entwickelt.

Herausforderungen bleiben. Die Realität der zwei Protokolle (Chromes Multi-Protokoll-Support versus Safaris mdoc-only Fokus) besteht für Relying Parties fort. Die Frage, ob Browser alle gelisteten Protokolle oder nur eines unterstützen müssen, ist ungelöst – direkt verknüpft mit Apples Plattform-Beschränkungen. Und Datenschutz-Überlegungen bleiben die einzelne größte Lücke, die den Fortschritt zur Candidate Recommendation verhindert, wobei normative Anforderungen für Protokoll-Aufnahmekriterien noch ungeschrieben sind. Es wird geschätzt, dass die Spec noch 1–2 Jahre von der W3C Recommendation entfernt ist.