Digital Credentials API

Eine Website ruft navigator.credentials.get() mit einer Anfrage nach einem digitalen Credential auf, die ein Präsentationsprotokoll benennt und die eigene Anfrage dieses Protokolls als Payload mitführt. Der Browser reicht die Anfrage an das Betriebssystem weiter, das eine systemeigene Auswahl der auf dem Gerät installierten Wallets anzeigt, und die Wallet, die der Inhaber wählt, gibt ihre Protokollantwort über denselben Aufruf zurück. Die API transportiert nur den Austausch: Was angefragt wird, was offengelegt wird und wie die Antwort geprüft wird, legt weiterhin das Protokoll darin fest. Ein ergänzender Aufruf navigator.credentials.create() leistet dasselbe für die Ausstellung, sodass eine Website ein Credential Offer auf die gleiche Weise an eine Wallet übergeben kann.

Vorher bedeutete eine Präsentation auf dem Gerät, das der Inhaber ohnehin nutzte, entweder einen QR-Code, den das Smartphone, auf dem er angezeigt wurde, nicht scannen konnte, oder einen Deep Link, der raten musste, welche Wallet installiert war. Die Weiterleitung der Anfrage über das Betriebssystem löst beide Probleme: Der Inhaber erhält eine einzige systemeigene Auswahl für alle Wallets auf dem Gerät, und die Website muss nie selbst eine Wallet erkennen oder benennen. Der Browser fügt der Anfrage außerdem den aufrufenden Origin hinzu, sodass die Wallet dem Inhaber zeigen kann, welche Website anfragt, und eine Anfrage ablehnen kann, die von anderswo kopiert wurde. Das macht den Ablauf widerstandsfähig gegen Phishing- und Relay-Angriffe.

Die API ist bewusst protokollneutral, und im EUDI Wallet-Ökosystem zählen zwei Anbindungen: OpenID4VP definiert ein eigenes Profil für die API, und ISO/IEC 18013-7 Annex C bindet denselben mdoc-Austausch daran an. Das EUDI ARF behandelt sie als Weg, die Präsentation aus der Ferne zu verbessern, sofern der Browser den Origin der vertrauenden Partei mitliefert, damit eine Wallet Unit erkennen kann, wer anfragt, und sofern ein Cross-Device-Ablauf eine Näheprüfung zwischen den beiden Geräten beibehält. ISO/IEC 18013-5 Device Retrieval bleibt damit der Kanal für die Vorlage vor Ort und wird nicht durch die Browser-API ersetzt.

Die Unterstützung ist nicht mehr experimentell. Die API ist in Chrome auf Android und auf dem Desktop sowie in Safari auf aktuellen Apple-Versionen standardmäßig aktiviert, während Firefox sie nicht aktiviert hat. Browser unterscheiden sich noch darin, welche Protokolle und Credential-Formate sie akzeptieren, und auf dem Desktop funktioniert es in der Regel über die Kopplung mit einem Smartphone, auf dem die Wallet liegt, nicht über im Browser gespeicherte Credentials. Behandeln Sie sie als Verbesserung für die Browser und Geräte, die sie unterstützen, und behalten Sie den QR-Code- oder Redirect-Ablauf für alle anderen bei.