Same-device- en cross-device-flows uitgelegd
Telkens wanneer een wallet iets aantoont aan een website, moeten die twee elkaar eerst vinden. Soms staan ze al op dezelfde telefoon en is de overdracht één tik. Soms staat de website op een bureau en zit de wallet in een broekzak, en is een code op het scherm de enige brug. Dat zijn de same-device-flow en de cross-device-flow, en bijna elke praktische vraag over digitale credentials komt terug op de vraag in welke van de twee u zit.
Twee vormen van dezelfde uitwisseling
Wat de twee flows gemeen hebben, is alles wat er voor de organisatie toe doet: dezelfde vraag wordt gesteld, dezelfde persoon keurt hem goed en hetzelfde bewijs komt terug. Wat u mag opvragen en waarop u daarna kunt vertrouwen, hangt er niet van af in welke flow u zit.
Wat verschilt, is de route. In de ene is de wallet één tik verwijderd en geeft hij het antwoord direct terug aan de pagina die erom vroeg. In de andere reist het antwoord van een tweede apparaat naar uw servers, en moet de pagina waar de gebruiker naar kijkt te horen krijgen dat het is aangekomen.
Same-device
Eén telefoon. Website en wallet op hetzelfde scherm.
- De bezoeker is in de browser op zijn telefoon op de site en wil iets aantonen.
- De site opent de wallet met een deeplink of een redirect.
- De wallet toont wie iets vraagt en waarvoor, en de bezoeker keurt het goed.
- De wallet stuurt de bezoeker met het antwoord terug naar de site, in dezelfde browsersessie waarin alles begon.
Cross-device
Twee apparaten. Website op een desktop, wallet op een telefoon.
- De bezoeker is in een desktopbrowser op de site en wil iets aantonen.
- De site toont een QR-code met daarin het verzoek.
- De wallet op de telefoon scant de code en toont wie iets vraagt, en de bezoeker keurt het goed.
- De wallet stuurt het antwoord naar de backend van de site, die de desktoppagina laat weten dat de uitwisseling klaar is.
Wanneer welke flow optreedt
U mag niet kiezen. Een klant die onderweg uw onboardingpagina op zijn telefoon opent, zit in een same-device-flow. Dezelfde klant die de volgende ochtend hetzelfde formulier aan een bureau afmaakt, zit in een cross-device-flow. De wallet staat op een telefoon, dus de flow volgt waar de rest van het werk gebeurt.
Daarom beschrijven beide protocollen in het Europese ecosysteem allebei de flows. Presentatie, waarbij u iemand vraagt iets aan te tonen, noemt de twee flows expliciet. Uitgifte, waarbij u iemand een credential geeft, maakt hetzelfde onderscheid voor het aanbod waarmee het begint: dat kan verschijnen op het apparaat waarop de wallet staat, of via elke andere route binnenkomen, tot en met een brief met een gedrukte code.
Een dienst die alleen binnen uw eigen organisatie wordt gebruikt, op beheerde desktops, kan redelijkerwijs met één flow starten. Alles wat een burger of klant op eigen gelegenheid bereikt, heeft beide nodig, en een dienst die maar op één manier werkt, wordt gemeld als kapot en niet als niet ondersteund.
Wat elke flow de gebruiker kost
Same-device is de kortere route. Er is geen tweede scherm, geen camera, geen moment van heen en weer kijken tussen apparaten, en de gebruiker komt terug waar hij begon. Als het misgaat, gaat het meestal vroeg en zichtbaar mis: er is geen wallet geïnstalleerd, of de link opent iets dat helemaal geen wallet is.
Cross-device kost een scan, maar levert iets wezenlijks op. De gebruiker blijft op het grote scherm waar hij een lang formulier invulde, een contract las of opties vergeleek, en alleen het bewijs zelf verhuist naar de telefoon. Voor alles wat meer dan een minuut typen kost, is dat de betere plek.
De fouten zijn stiller en verdienen aandacht in het ontwerp. Een code die verliep terwijl iemand zijn telefoon zocht, een telefoon zonder bereik, een camera die niet scherpstelt. De pagina met de code moet vermelden hoe lang die geldig is, een nieuwe aanbieden zonder het formulier eronder kwijt te raken, en de gebruiker nooit laten raden of er iets is gebeurd.
Waar ze echt verschillen: beveiliging
In een same-device-flow komt het antwoord terug langs de weg die de gebruiker ging: een redirect, op het apparaat waarop de wallet draait, naar de browsersessie die de uitwisseling startte. Wie het verzoek van zijn eigen scherm kopieert, kan het resultaat op geen enkele manier ontvangen, omdat het wordt afgeleverd op het apparaat dat de goedkeuring gaf.
In een cross-device-flow komt het antwoord helemaal niet terug via de browser. Het gaat van de telefoon naar uw servers, buiten het zicht van de pagina die de code toonde. Daar zit het gat: tenzij u de code koppelt aan de sessie die hem toonde, kan uw dienst geen onderscheid maken tussen de persoon die ervoor zit en iemand die dezelfde code aan een slachtoffer heeft voorgelegd en heeft afgewacht.
Die aanval heeft een naam en een remedie. De code moet bij één sessie horen en alleen bij die sessie, en een resultaat dat voor een andere sessie binnenkomt, moet worden geweigerd. Het kost een paar regels denkwerk tijdens het ontwerp en is een bekend lek als u het overslaat. Daarom heeft de IETF een best current practice voor cross-device-flows geschreven in plaats van het aan elke implementatie over te laten.
Het tweede risico is phishing, en dat hoort bij de code zelf. Een vierkantje zwart-wit zegt de gebruiker niets over wie er aan de andere kant zit, dus een code op een sticker die over een echte is geplakt, is een geloofwaardige aanval. De verdediging is dat de wallet, niet de code, de vragende organisatie noemt en precies opsomt wat die wil voordat er iets wordt gedeeld. Uitgifte voegt nog een slot toe: een aanbod kan een korte code vereisen die wordt geleverd via het kanaal dat de persoon al identificeerde, zodat een onderschept aanbod door niemand anders kan worden ingewisseld.
Wat dit voor u betekent
Vertrouwende partij
Plan vanaf het begin voor beide. Het extra werk zit in uw front-end en in het koppelen van de code aan een sessie, niet in een tweede integratie, en die koppeling achteraf inbouwen is het deel dat misgaat.
Uitgever
Bepaal hoe uw aanbod mensen bereikt. Op het scherm naast een login, in een e-mail of op papier: elk komt in een andere flow terecht, en de routes die uw kanaal verlaten, zijn de routes die een aparte code nodig hebben om in te wisselen.
Wallethouder
Lees wat de wallet u toont, niet wat de pagina of de code beweert. De wallet is de enige plek die noemt wie er vraagt en wat die wil, en het laatste moment waarop u nee kunt zeggen.
Gerelateerde termen
Veelgestelde vragen
Wie bepaalt welke flow wordt gebruikt?
De situatie, niet een instelling. Zit iemand al op het apparaat waarop zijn wallet staat, dan geeft de site direct over. Zit hij achter een desktop en zit de wallet in zijn broekzak, dan is een code om te scannen de enige brug. Een dienst die open staat voor het publiek krijgt in de eerste week al met allebei te maken.
Betekent beide ondersteunen dat u alles twee keer bouwt?
Nee. Het verzoek dat u doet en het antwoord dat u controleert zijn in beide gevallen hetzelfde. Wat verschilt, is hoe het verzoek de wallet bereikt en hoe het antwoord terugkomt op uw pagina: een redirect die de browser volgt, of een code op het scherm plus een manier waarop die pagina hoort dat de uitwisseling klaar is. In de praktijk is dat één extra route in uw front-end, geen tweede integratie.
Is een QR-code hiervoor veilig?
Ja, als de uitwisseling eromheen goed is gebouwd. Een code zegt de gebruiker op zichzelf niets over wie er vraagt, dus er moeten twee dingen kloppen: de wallet moet de identiteit van de vragende organisatie tonen voordat er iets wordt gedeeld, en uw eigen dienst moet een antwoord weigeren dat binnenkomt voor een andere sessie dan de sessie die de code toonde. Beide zijn gangbare praktijk en staan allebei in de specificaties.
Is een controle aan een balie een cross-device-flow?
Nee, dat is een derde geval. Same-device en cross-device beschrijven allebei een uitwisseling via internet. Een controle van persoon tot persoon, waarbij de twee apparaten naast elkaar worden gehouden, gebruikt in plaats daarvan een proximity-standaard via Bluetooth of NFC. Voor wie de telefoon vasthoudt lijkt het op elkaar, maar er gaat niets via uw website.
Bronnen
Deze pagina is informatief en vormt geen juridisch advies. Raadpleeg voor gezaghebbende richtlijnen rechtstreeks de specificaties van OpenID en de IETF.