Same-Device- und Cross-Device-Ablauf erklärt
Jedes Mal, wenn eine Wallet einer Website etwas nachweist, müssen die beiden erst zueinanderfinden. Manchmal liegen sie schon auf demselben Telefon, und die Übergabe ist ein einziges Tippen. Manchmal steht die Website auf dem Schreibtisch und die Wallet steckt in der Tasche, und die einzige Brücke zwischen beiden ist ein Code auf dem Bildschirm. Das sind der Same-Device- und der Cross-Device-Ablauf, und fast jede praktische Frage zu digitalen Credentials läuft darauf hinaus, in welchem der beiden Sie sich befinden.
Zwei Formen desselben Austauschs
Gemeinsam haben die beiden Abläufe alles, was für das Geschäft zählt: Dieselbe Frage wird gestellt, dieselbe Person stimmt zu, und derselbe Nachweis kommt zurück. Was Sie anfragen dürfen und worauf Sie sich danach verlassen können, hängt nicht davon ab, in welchem Ablauf Sie sich befinden.
Unterschiedlich ist der Weg. Im einen ist die Wallet nur ein Tippen entfernt und gibt die Antwort direkt an die Seite zurück, die gefragt hat. Im anderen reist die Antwort von einem zweiten Gerät zu Ihren Servern, und die Seite, die die Person gerade ansieht, muss erfahren, dass sie angekommen ist.
Same-Device
Ein Telefon. Website und Wallet auf demselben Bildschirm.
- Die Person ist im Browser ihres Telefons auf der Website und möchte etwas nachweisen.
- Die Website öffnet die Wallet per Deep Link oder Redirect.
- Die Wallet zeigt, wer fragt und wofür, und die Person stimmt zu.
- Die Wallet leitet mit der Antwort zurück zur Website, in dieselbe Browsersitzung, in der alles begann.
Cross-Device
Zwei Geräte. Website auf dem Desktop, Wallet auf dem Telefon.
- Die Person ist in einem Desktop-Browser auf der Website und möchte etwas nachweisen.
- Die Website zeigt einen QR-Code, der die Anfrage enthält.
- Die Wallet auf dem Telefon scannt ihn, zeigt, wer fragt, und die Person stimmt zu.
- Die Wallet sendet die Antwort an das Backend der Website, das der Desktop-Seite meldet, dass der Austausch abgeschlossen ist.
Wann welcher Ablauf eintritt
Sie können es sich nicht aussuchen. Eine Kundin, die Ihre Onboarding-Seite auf dem Weg zur Arbeit auf dem Telefon öffnet, ist in einem Same-Device-Ablauf. Dieselbe Kundin, die am nächsten Morgen dasselbe Formular am Schreibtisch abschließt, ist in einem Cross-Device-Ablauf. Die Wallet liegt auf einem Telefon, also folgt der Ablauf dorthin, wo der Rest der Arbeit gerade stattfindet.
Deshalb beschreiben beide Protokolle im europäischen Ökosystem beide Abläufe. Die Vorlage, bei der Sie jemanden bitten, etwas nachzuweisen, benennt die zwei Abläufe ausdrücklich. Die Ausstellung, bei der Sie jemandem ein Credential übergeben, trifft dieselbe Unterscheidung für das Angebot, mit dem sie beginnt: Es kann auf dem Gerät erscheinen, auf dem die Wallet liegt, oder auf jedem anderen Weg eintreffen, bis hin zu einem Brief mit einem gedruckten Code.
Ein Dienst, der nur innerhalb Ihrer eigenen Organisation auf verwalteten Desktops genutzt wird, kann durchaus mit einem Ablauf starten. Alles, was Bürger oder Kunden auf eigene Faust erreichen, braucht beide, und ein Dienst, der nur auf eine Weise funktioniert, wird als defekt gemeldet, nicht als nicht unterstützt.
Was jeder Ablauf die Nutzer kostet
Same-Device ist der kürzere Weg. Es gibt keinen zweiten Bildschirm, keine Kamera, keinen Blick von einem Gerät zum anderen, und die Person landet wieder dort, wo sie angefangen hat. Wenn es scheitert, dann meist früh und sichtbar: keine Wallet installiert, oder der Link öffnet etwas, das gar keine Wallet ist.
Cross-Device kostet einen Scan, bringt aber einen echten Vorteil. Die Person bleibt auf dem großen Bildschirm, auf dem sie ein langes Formular ausgefüllt, einen Vertrag gelesen oder Optionen verglichen hat, und nur der Nachweis selbst wandert auf das Telefon. Für alles, was mehr als eine Minute Tipparbeit erfordert, ist das der bessere Ort.
Seine Fehler sind leiser und verdienen Aufmerksamkeit im Design. Ein Code, der abgelaufen ist, während jemand sein Telefon gesucht hat, ein Telefon ohne Empfang, eine Kamera, die nicht scharfstellt. Die Seite mit dem Code sollte sagen, wie lange er gültig ist, einen neuen anbieten, ohne das Formular darunter zu verlieren, und die Person nie im Unklaren lassen, ob etwas passiert ist.
Wo sich beide wirklich unterscheiden: Sicherheit
In einem Same-Device-Ablauf kommt die Antwort auf dem Weg zurück, den die Person genommen hat: ein Redirect, auf dem Gerät, auf dem die Wallet läuft, in die Browsersitzung, die den Austausch gestartet hat. Wer die Anfrage von seinem eigenen Bildschirm kopiert, hat keine Möglichkeit, das Ergebnis zu empfangen, weil es an das Gerät geliefert wird, auf dem zugestimmt wurde.
In einem Cross-Device-Ablauf kommt die Antwort gar nicht über den Browser zurück. Sie geht vom Telefon an Ihre Server, außer Sichtweite der Seite, die den Code gezeigt hat. Genau dort liegt die Lücke: Solange Sie den Code nicht an die Sitzung binden, die ihn angezeigt hat, kann Ihr Dienst nicht unterscheiden zwischen der Person davor und jemandem, der denselben Code einem Opfer vorgelegt und abgewartet hat.
Dieser Angriff hat einen Namen und ein Gegenmittel. Der Code muss zu genau einer Sitzung gehören, und ein Ergebnis, das für eine andere Sitzung eintrifft, muss abgelehnt werden. Das sind ein paar Gedanken beim Entwurf und eine bekannte Lücke, wenn man sie weglässt. Deshalb hat die IETF eine Best Current Practice für Cross-Device-Abläufe geschrieben, statt es jeder Implementierung selbst zu überlassen.
Das zweite Risiko ist Phishing, und es gehört zum Code selbst. Ein schwarz-weißes Quadrat verrät der Person nichts darüber, wer am anderen Ende sitzt, deshalb ist ein Code auf einem Aufkleber, der über einen echten geklebt wurde, ein glaubwürdiger Angriff. Die Abwehr besteht darin, dass die Wallet, nicht der Code, die anfragende Organisation nennt und genau auflistet, was sie will, bevor etwas geteilt wird. Die Ausstellung fügt ein weiteres Schloss hinzu: Ein Angebot kann einen kurzen Code verlangen, der über den Kanal geliefert wird, der die Person bereits identifiziert hat, sodass ein unterwegs abgefangenes Angebot von niemand anderem eingelöst werden kann.
Was das für Sie bedeutet
Vertrauende Partei
Planen Sie von Anfang an für beide. Der Mehraufwand liegt in Ihrem Frontend und in der Bindung des Codes an eine Sitzung, nicht in einer zweiten Integration, und genau diese Bindung nachträglich einzubauen ist der Teil, der schiefgeht.
Aussteller
Legen Sie fest, wie Ihr Angebot die Menschen erreicht. Auf dem Bildschirm neben einem Login, in einer E-Mail oder auf Papier: Jeder Weg landet in einem anderen Ablauf, und die Wege, die Ihren Kanal verlassen, sind die, die einen separaten Code zum Einlösen brauchen.
Wallet-Inhaber
Lesen Sie, was die Wallet Ihnen zeigt, nicht was die Seite oder der Code behauptet. Die Wallet ist der einzige Ort, der nennt, wer fragt und was er will, und der letzte Punkt, an dem Sie Nein sagen können.
Verwandte Begriffe
Häufig gestellte Fragen
Wer entscheidet, welcher Ablauf genutzt wird?
Die Situation, keine Einstellung. Ist die Person bereits auf dem Gerät, auf dem ihre Wallet liegt, übergibt die Website direkt. Sitzt sie am Desktop und hat die Wallet in der Tasche, führt der einzige Weg hinüber über einen Code zum Scannen. Ein öffentlich zugänglicher Dienst begegnet beiden schon in der ersten Woche.
Heißt beides zu unterstützen, alles doppelt zu bauen?
Nein. Die Anfrage, die Sie stellen, und die Antwort, die Sie prüfen, sind in beiden Fällen gleich. Unterschiedlich ist, wie die Anfrage die Wallet erreicht und wie die Antwort zu Ihrer Seite zurückkommt: ein Redirect, dem der Browser folgt, oder ein Code auf dem Bildschirm plus ein Weg, auf dem diese Seite erfährt, dass der Austausch abgeschlossen ist. In der Praxis ist das ein zusätzlicher Pfad in Ihrem Frontend, keine zweite Integration.
Ist ein QR-Code dafür sicher?
Ja, wenn der Austausch drumherum richtig gebaut ist. Ein Code allein verrät der Person nichts darüber, wer fragt. Deshalb müssen zwei Dinge stimmen: Die Wallet muss die Identität der anfragenden Organisation anzeigen, bevor etwas geteilt wird, und Ihr eigener Dienst muss eine Antwort ablehnen, die für eine andere Sitzung eintrifft als die, die den Code angezeigt hat. Beides ist gängige Praxis und beides steht in den Spezifikationen.
Ist eine Prüfung am Schalter ein Cross-Device-Ablauf?
Nein, das ist ein dritter Fall. Same-Device und Cross-Device beschreiben beide einen Austausch über das Internet. Eine Prüfung von Angesicht zu Angesicht, bei der die beiden Geräte nebeneinander gehalten werden, nutzt stattdessen einen Nahbereichsstandard über Bluetooth oder NFC. Für die Person mit dem Telefon sieht es ähnlich aus, aber nichts läuft über Ihre Website.
Quellen
Diese Seite dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Verbindliche Hinweise finden Sie direkt in den Spezifikationen von OpenID und der IETF.