Flöde på samma enhet vs mellan enheter

I ett flöde på samma enhet finns plånboken och webbplatsen eller appen i samma telefon. Webbplatsen lämnar över besökaren med en djuplänk eller en omdirigering, plånboken öppnas, personen godkänner det som efterfrågas och plånboken skickar tillbaka dem till webbplatsen samma väg som de kom. OpenID4VP returnerar presentationen i fragmentet i den omdirigeringen, så den webbläsarsession som startade utbytet är också den som avslutar det.

I ett flöde mellan enheter börjar besökaren i en webbläsare på en dator medan plånboken finns i telefonen. Webbplatsen visar förfrågan som en QR-kod, plånboken skannar den och skickar resultatet direkt till webbplatsens backend i stället för till webbläsaren på skrivbordet. Sidan på datorn måste sedan få veta att utbytet är klart, oftast genom polling eller via en websocket, och därför involverar ett flöde mellan enheter alltid backend.

Båda protokollen utgår från att ni stöder båda formerna. OpenID4VP namnger dem som sina två flöden, och OpenID4VCI beskriver samma uppdelning för ett Credential Offer, som kan nå innehavaren på enheten där plånboken finns eller via vilken annan kanal som helst. Vilket flöde en besökare får avgörs av var den råkar befinna sig, inte av en inställning ni väljer en gång, så en tjänst för allmänheten behöver att båda vägarna fungerar.

Användarupplevelsen skiljer sig i ansträngning och i hur det kan gå fel. Samma enhet är den kortare vägen: ingen andra skärm, ingen kamera, ingen överlämning mellan enheter. Mellan enheter kostar en skanning, men låter besökaren stanna kvar på den stora skärm där den redan arbetade, och det är det enda alternativet när plånboken inte finns på enheten som används. Ett flöde på samma enhet går sönder när ingen plånbok är installerad eller djuplänken öppnar fel app, medan ett flöde mellan enheter går sönder när koden går ut eller telefonen saknar uppkoppling.

Säkerhetsskillnaden är verklig och den talar för samma enhet. Eftersom plånboken returnerar svaret via en omdirigering på sin egen enhet har en angripare som kopierar förfrågan inget sätt att hämta svaret. Ett svar mellan enheter går utanför bandet till webbplatsens backend, så webbplatsen måste själv knyta koden till den webbläsarsession som visade den. Utan den kopplingen kan någon ta en kod från en session de kontrollerar, sätta den framför ett offer och låta offrets intyg slutföra angriparens inloggning.

En QR-kod är också en yta för nätfiske, eftersom koden i sig inte visar läsaren något om vem som frågar. Det är plånboken, inte koden, som måste visa verifierarens identitet och den exakta förfrågan innan något delas. IETF har en särskild best current practice för den här typen av attacker i flöden mellan enheter, och OpenID4VCI lägger till en transaktionskod i ett erbjudande av samma skäl: koden kommer via den kanal som redan har autentiserat innehavaren, så ett erbjudande som snappas upp på vägen inte kan lösas in av någon annan.