Same-Device- vs. Cross-Device-Ablauf

In einem Same-Device-Ablauf liegen Wallet und Website oder App auf demselben Telefon. Die Website übergibt per Deep Link oder Redirect, die Wallet öffnet sich, die Person stimmt dem Angefragten zu, und die Wallet schickt sie auf dem Weg zurück zur Website, auf dem sie gekommen ist. OpenID4VP gibt die Präsentation im Fragment dieses Redirects zurück, sodass die Browsersitzung, die den Austausch gestartet hat, ihn auch abschließt.

In einem Cross-Device-Ablauf beginnt die Person in einem Desktop-Browser, während die Wallet auf ihrem Telefon liegt. Die Website stellt die Anfrage als QR-Code dar, die Wallet scannt ihn und sendet das Ergebnis direkt an das Backend der Website statt an den Browser auf dem Schreibtisch. Die Desktop-Seite muss dann erfahren, dass der Austausch abgeschlossen ist, meist per Polling oder über einen Websocket. Deshalb ist an einem Cross-Device-Ablauf immer das Backend beteiligt.

Beide Protokolle setzen voraus, dass Sie beide Formen unterstützen. OpenID4VP nennt sie als seine zwei Abläufe, und OpenID4VCI beschreibt dieselbe Aufteilung für ein Credential Offer, das den Inhaber auf dem Gerät mit der Wallet oder über jeden anderen Kanal erreichen kann. Welchen Ablauf eine Person bekommt, entscheidet sich danach, wo sie gerade ist, nicht nach einer Einstellung, die Sie einmal wählen. Ein öffentlicher Dienst braucht deshalb beide Wege.

Die Nutzererfahrung unterscheidet sich im Aufwand und in den Fehlerbildern. Same-Device ist der kürzere Weg: kein zweiter Bildschirm, keine Kamera, keine Übergabe zwischen Geräten. Cross-Device kostet einen Scan, hält die Person aber auf dem großen Bildschirm, an dem sie bereits gearbeitet hat, und ist die einzige Option, wenn die Wallet nicht auf dem Gerät liegt, auf dem die Arbeit stattfindet. Ein Same-Device-Ablauf scheitert, wenn keine Wallet installiert ist oder der Deep Link die falsche App öffnet, ein Cross-Device-Ablauf scheitert, wenn der Code abläuft oder das Telefon keine Verbindung hat.

Der Sicherheitsunterschied ist real und spricht für Same-Device. Weil die Wallet die Antwort per Redirect auf ihrem eigenen Gerät zurückgibt, hat ein Angreifer, der die Anfrage kopiert, keine Möglichkeit, die Antwort abzugreifen. Eine Cross-Device-Antwort gelangt out of band an das Backend der Website, also muss die Website selbst den Code an die Browsersitzung binden, die ihn angezeigt hat. Ohne diese Bindung kann jemand einen Code aus einer Sitzung nehmen, die er kontrolliert, ihn einem Opfer vorlegen und die Credentials des Opfers die Anmeldung des Angreifers abschließen lassen.

Ein QR-Code ist außerdem eine Angriffsfläche für Phishing, weil der Code selbst nichts darüber zeigt, wer fragt. Die Wallet, nicht der Code, muss die Identität des Verifizierers und die genaue Anfrage anzeigen, bevor etwas geteilt wird. Die IETF hat für diese Angriffsklasse in Cross-Device-Abläufen eine eigene Best Current Practice, und OpenID4VCI ergänzt ein Angebot aus demselben Grund um einen Transaktionscode: Er kommt über den Kanal, der den Inhaber bereits authentifiziert hat, sodass ein unterwegs abgefangenes Angebot von niemand anderem eingelöst werden kann.