A Digital Credentials API elmagyarázva
A Digital Credentials API az a megállapodás, amely lehetővé teszi, hogy egy weboldal közvetlenül az Ön tárcájától kérjen igazolást, annak az eszköznek a böngészőjén és operációs rendszerén keresztül, amely már a kezében van. A tárcát tartalmazó telefonon nem jelenik meg QR-kód, és senki nem küldi át egy másik alkalmazásba, majd vissza. Egyszer koppint, a telefon megmutatja, ki kér, és Ön dönt. Laptopon a böngésző saját QR-kódot jelenít meg, hogy elérje a telefonját.
A kerülőút, amelyet megszüntet
Eddig annak a weboldalnak, amely valamit kért egy tárcától, valahogy el kellett juttatnia hozzá a kérést. A gyakorlatban ez egy QR-kódot jelentett az oldalon, vagy egy hivatkozást, amely átadja a látogatót egy alkalmazásnak, és jó esetben vissza is hozza. Mindkettő működik, és mindkettőnél minden lépésnél elvesznek emberek.
Telefonon a legrosszabb, ahol a QR-kód ugyanazon a képernyőn van, mint a kamera, amellyel be kellene olvasni. A Digital Credentials API ezt a rést úgy zárja be, hogy a kérést olyasmivé teszi, amit a böngésző és az operációs rendszer maguk is továbbítani tudnak, hiszen már tudják, mely tárcák vannak az eszközön.
Ugyanaz az eszköz
A látogató azon a telefonon van, amelyen a tárca is található. A Digital Credentials API itt teljesen megszünteti a QR-kódot és az alkalmazásváltást.
Két eszköz között
A látogató laptopon van, a tárca pedig a telefonon, így valaminek továbbra is össze kell kötnie a kettőt. A különbség az, hogy ezt a kódot maga a böngésző tudja megjeleníteni és kezelni.
Hogyan néz ki a gyakorlatban
A látogató szemszögéből ez egyetlen koppintás azon az oldalon, ahol már eddig is volt. A háttérben a böngésző átadja a kérést az operációs rendszernek, az operációs rendszer megkeresi a válaszolni képes tárcákat, a tárca pedig jóváhagyásra megjeleníti a kérést, mielőtt bármi megosztásra kerülne.
1. Weboldal
QR-kód megjelenítése vagy alkalmazás megnyitása helyett a böngészőtől kér igazolást
2. Böngésző és operációs rendszer
Megállapítja, mely tárcák tartalmaznak megfelelő adatot az eszközön, és csak azokat kínálja fel
3. Birtokos
Látja, ki kér és mit, kiválaszt egy tárcát, majd jóváhagyja vagy elutasítja
4. Ismét a weboldal
A jóváhagyott választ ugyanazon az oldalon kapja meg, amelyet a látogató el sem hagyott
Miért számít, hogy a böngésző is részt vesz
A QR-kód egy darab papír vagy egy kép a képernyőn, és nem tudja megmondani, ki tette oda. Erre épül az egész QR-phishing: a támadó kicseréli a kódot, a tárca megnyílik, és a kérés teljesen normálisnak tűnik, mert a folyamatban semmi sem tudja, valójában honnan érkezett.
Ha a kérés a böngészőn keresztül halad, a böngésző mondja meg a tárcának, melyik weboldal kér, és nem lehet rávenni, hogy mást állítson. A tárca megmutathatja a birtokosnak a valódi oldalt, a válasz pedig ehhez az oldalhoz köthető, így egy máshol elfogott másolat senkinek sem ér semmit. Ez érdemben csökkenti a csalási kockázatot, nem csupán gördülékenyebb képernyőt jelent.
Hogyan illeszkedik az OpenID4VP-hez és az EUDI Wallethez
Könnyű úgy érteni, mintha ez újabb szabvány lenne, amelyek közül választani kell. Nem az. Az OpenID4VP marad az a nyelv, amelyen az igénybe vevő fél elmondja, mire van szüksége, és elolvassa a visszakapott választ, a Digital Credentials API pedig egyszerűen jobb út ehhez a párbeszédhez, leginkább akkor, ha minden egyetlen eszközön történik.
Ugyanez igaz magára az igazolásra is. Egy EUDI Wallet tanúsítvány vagy egy mdoc pontosan ugyanabban a formátumban érkezik, mint egy beolvasott kódon keresztül, így az ellenőrző fél által már futtatott ellenőrzések változatlanok. A csapat azt nyeri, hogy kihagyhatja a kerülőutat anélkül, hogy bármit újraépítene mögötte.
A támogatás böngészőről böngészőre és platformról platformra érkezik, nem egyszerre mindenhol, ezért az igénybe vevő felek a kódbeolvasás mellett vezetik be, nem helyette. A gyakorlati megközelítés az, hogy ahol az eszköz kínálja, ott az API-t használják, ahol nem, ott a kódot, és a lefedettség növekedésével a tartalékút fokozatosan háttérbe szorul.
Mit jelent ez Önnek
Igénybe vevő fél
Kevesebben hagyják félbe a folyamatot, mert eltűntek azok a lépések, ahol korábban lemorzsolódtak, a böngésző pedig megmondja a tárcának, ki Ön valójában, ami egy phishing-lehetőséget kizár.
Tárcabirtokos
Egyetlen koppintás azon az oldalon, ahol már most is van, a kérő fél valódi neve, és semmilyen mód arra, hogy egy oldal megtudja, milyen tárcái vannak, hacsak Ön bele nem egyezik.
Tárcaszolgáltató
Az operációs rendszer felkínálja a tárcáját, valahányszor az tartalmaz valami megfelelőt, így a megtalálhatósága már nem azon múlik, hogy egy igénybe vevő fél úgy dönt-e, hogy hivatkozik Önre.
Technikai elmélyülés
Ez az oldal azt magyarázza el, mit csinál a technológia, és kit érint. A fejlesztői dokumentációnk magával a megvalósítással foglalkozik: az üzenetekkel, a mezőkkel és a kidolgozott példákkal, amelyekre egy integrációs csapatnak szüksége van.
Műszaki dokumentáció megtekintéseKapcsolódó fogalmak
Gyakori kérdések
Ez a QR-kódok végét jelenti?
Nem, de szűkül a szerepük, és megváltozik, ki jeleníti meg őket. Ha egy kérést laptopról telefonra kell átvinni, továbbra is kell valami, ami összeköti a két eszközt, és az API ezt az esetet is lefedi: a kódot a böngésző jeleníti meg, ahelyett hogy minden weboldal saját kódot készítene. Teljesen eltűnik viszont a kód azon a telefonon, amelyen már ott a tárca, hiszen ott sosem volt több egy kerülőmegoldásnál.
Láthatja a weboldal, hogy milyen tárcák vannak telepítve nálam?
Nem. A weboldal leírja, mit kér, az egyeztetést pedig az operációs rendszer végzi az eszközön. Az oldal soha nem tudja meg, mely tárcák vannak telepítve, vagy melyikben volt egyezés. Ha elutasítja, csak annyit tud meg, hogy nem érkezett semmi, ami számára pontosan ugyanúgy néz ki, mintha eleve nem is lenne megfelelő igazolása.
Ez az OpenID4VP helyettesítője?
Nem, a kettő együtt működik. Az OpenID4VP az a nyelv, amelyen a kérés és a válasz íródik, és ez itt nem változik. A Digital Credentials API az eszközön belüli kézbesítési útvonal, amely a QR-kód vagy egy egyedi hivatkozás helyébe lép. Az az igénybe vevő fél, amely már használja az OpenID4VP-t, megtartja meglévő kérés- és ellenőrzési logikáját.
Mit kell ténylegesen kiépítenie egy igénybe vevő félnek?
Kevesebbet, mint a legtöbb csapat gondolná, mert csak a frontend változik. A backend által előállított kérés és a válaszon futtatott ellenőrzések ugyanazok maradnak. Hozzá kell adni a böngészőhívást, és amíg a támogatás még terjed, egy QR-kódos tartalékutat azoknak a látogatóknak, akiknek a böngészője vagy eszköze még nem tudja használni az API-t.
Források
Ez az oldal tájékoztató jellegű, és nem minősül jogi tanácsadásnak. A Digital Credentials API még fejlődik, ezért a hiteles megfogalmazásért forduljon közvetlenül a W3C specifikációjához.