Die Digital Credentials API erklärt
Die Digital Credentials API ist die Vereinbarung, mit der eine Website einen Nachweis direkt aus Ihrer Wallet anfragen kann, über den Browser und das Betriebssystem des Geräts, das Sie ohnehin in der Hand halten. Auf dem Smartphone mit Ihrer Wallet erscheint kein QR-Code, und Sie werden nicht in eine andere App und wieder zurück geschickt. Sie tippen einmal, Ihr Smartphone zeigt, wer anfragt, und Sie entscheiden. Auf einem Laptop zeigt der Browser seinen eigenen QR-Code an, um Ihr Smartphone zu erreichen.
Der Umweg, der wegfällt
Bisher musste eine Website, die etwas aus einer Wallet wollte, die Anfrage irgendwie zu dieser Wallet bringen. In der Praxis hieß das: ein QR-Code auf der Seite oder ein Link, der den Besucher an eine App übergibt und ihn hoffentlich zurückbringt. Beides funktioniert, und bei beidem springen an jedem Schritt Menschen ab.
Am schlimmsten ist es auf dem Smartphone, wo der QR-Code auf demselben Bildschirm steht wie die Kamera, die ihn scannen soll. Die Digital Credentials API schließt diese Lücke, indem die Anfrage zu etwas wird, das Browser und Betriebssystem selbst übermitteln können, denn sie wissen bereits, welche Wallets auf dem Gerät liegen.
Auf demselben Gerät
Der Besucher ist auf dem Smartphone, auf dem die Wallet liegt. Hier macht die Digital Credentials API den QR-Code und den Wechsel in eine andere App komplett überflüssig.
Über zwei Geräte
Der Besucher sitzt am Laptop und die Wallet liegt auf dem Smartphone, also muss weiterhin etwas die beiden verbinden. Der Unterschied: Der Browser kann diesen Code jetzt selbst anzeigen und verwalten.
Wie es in der Praxis aussieht
Für den Besucher ist es ein einziges Tippen auf der Seite, auf der er ohnehin war. Im Hintergrund reicht der Browser die Anfrage an das Betriebssystem weiter, das Betriebssystem findet die Wallets, die sie beantworten können, und die Wallet zeigt die Anfrage zur Freigabe an, bevor irgendetwas geteilt wird.
1. Website
Bittet den Browser um einen Nachweis, statt einen QR-Code anzuzeigen oder eine App zu öffnen
2. Browser und Betriebssystem
Ermitteln, welche Wallets auf dem Gerät etwas Passendes enthalten, und bieten nur diese an
3. Inhaber
Sieht, wer anfragt und wofür, wählt eine Wallet und stimmt zu oder lehnt ab
4. Wieder die Website
Erhält die freigegebene Antwort auf derselben Seite, die der Besucher nie verlassen hat
Warum es zählt, dass der Browser beteiligt ist
Ein QR-Code ist ein Stück Papier oder ein Bild auf einem Bildschirm, und er kann Ihnen nicht sagen, wer ihn dort platziert hat. Genau darauf beruht QR-Phishing: Ein Angreifer tauscht den Code aus, die Wallet öffnet sich, und die Anfrage wirkt völlig normal, weil nichts im Ablauf weiß, woher sie wirklich stammt.
Läuft die Anfrage über den Browser, ist es der Browser, der der Wallet mitteilt, welche Website anfragt, und davon lässt er sich nicht abbringen. Die Wallet kann dem Inhaber die echte Seite anzeigen, und die Antwort lässt sich an diese Seite binden, sodass eine anderswo abgefangene Kopie für niemanden etwas wert ist. Das senkt das Betrugsrisiko spürbar und sorgt nicht nur für einen glatteren Bildschirm.
Wie es zu OpenID4VP und der EUDI Wallet passt
Man könnte das leicht als einen weiteren Standard lesen, zwischen dem man wählen muss. Das ist es nicht. OpenID4VP bleibt die Sprache, in der eine vertrauende Partei sagt, was sie braucht, und die Antwort liest, die sie zurückbekommt. Die Digital Credentials API ist schlicht ein besserer Weg für dieses Gespräch, vor allem wenn alles auf einem Gerät passiert.
Dasselbe gilt für den Nachweis selbst. Eine EUDI Wallet-Attestierung oder ein mdoc kommt in genau dem Format an, in dem sie auch über einen gescannten Code angekommen wäre, sodass die Prüfungen, die ein Prüfer bereits durchführt, unverändert bleiben. Ein Team gewinnt die Möglichkeit, den Umweg auszulassen, ohne dahinter etwas neu zu bauen.
Die Unterstützung kommt Browser für Browser und Plattform für Plattform, nicht überall gleichzeitig. Deshalb führen vertrauende Parteien sie neben dem Weg über den gescannten Code ein, nicht an seiner Stelle. Der praktische Ansatz: die API nutzen, wo das Gerät sie anbietet, auf einen Code zurückfallen, wo nicht, und den Rückfallweg auslaufen lassen, während die Abdeckung wächst.
Was das für Sie bedeutet
Vertrauende Partei
Weniger Menschen brechen ab, weil die Schritte, an denen sie früher ausgestiegen sind, wegfallen, und der Browser teilt der Wallet mit, wer Sie wirklich sind, was einen Weg für Phishing ausschließt.
Wallet-Inhaber
Ein Tippen auf der Seite, auf der Sie schon sind, ein ehrlicher Name für den, der anfragt, und keine Möglichkeit für eine Website zu erfahren, welche Wallets Sie nutzen, solange Sie nicht zustimmen.
Wallet-Anbieter
Das Betriebssystem bietet Ihre Wallet an, sobald sie etwas Passendes enthält. Gefunden zu werden hängt also nicht mehr davon ab, dass eine vertrauende Partei sich entscheidet, auf Sie zu verlinken.
Technische Vertiefung
Diese Seite erklärt, was die Technologie leistet und wen sie betrifft. Unsere Entwicklerdokumentation behandelt die Umsetzung selbst: die Nachrichten, die Felder und die ausgearbeiteten Beispiele, die ein Integrationsteam braucht.
Technische Dokumentation lesenVerwandte Begriffe
Häufig gestellte Fragen
Ist das das Ende der QR-Codes?
Nein, aber es grenzt ein, wofür sie da sind, und ändert, wer sie erzeugt. Eine Anfrage vom Laptop auf das Smartphone zu bringen, braucht weiterhin eine Brücke zwischen beiden, und auch diesen Fall deckt die API ab: Der Browser zeigt den Code an, statt dass jede Website ihren eigenen baut. Komplett wegfallen wird der Code auf einem Smartphone, auf dem die Wallet bereits liegt. Dort war er nie mehr als eine Notlösung.
Sieht die Website, welche Wallets ich installiert habe?
Nein. Die Website beschreibt, wonach sie fragt, und das Betriebssystem gleicht das auf dem Gerät ab. Die Seite erfährt nie, welche Wallets installiert sind oder in welcher sich etwas Passendes fand. Lehnen Sie ab, erfährt sie nur, dass nichts zurückkam, und das sieht für sie genauso aus, als hätten Sie gar keinen passenden Nachweis.
Ersetzt das OpenID4VP?
Nein, beide arbeiten zusammen. OpenID4VP ist die Sprache, in der Anfrage und Antwort formuliert sind, und daran ändert sich nichts. Die Digital Credentials API ist der Zustellweg auf dem Gerät und tritt an die Stelle eines QR-Codes oder eines eigenen Links. Eine vertrauende Partei, die bereits OpenID4VP spricht, behält ihre bestehende Anfrage- und Prüflogik.
Was muss eine vertrauende Partei eigentlich bauen?
Weniger, als die meisten Teams erwarten, denn es ändert sich nur das Frontend. Die Anfrage, die Ihr Backend erzeugt, und die Prüfungen, die es auf die Antwort anwendet, bleiben gleich. Hinzu kommen der Aufruf im Browser und, solange sich die Unterstützung noch verbreitet, ein Rückfall auf den QR-Code für Besucher, deren Browser oder Gerät die API noch nicht nutzen kann.
Quellen
Diese Seite dient der Information und stellt keine Rechtsberatung dar. Die Digital Credentials API entwickelt sich noch weiter. Maßgeblich ist der Wortlaut der W3C-Spezifikation selbst.