Digital Credentials API explicat
Digital Credentials API este acordul care permite unui site web să ceară un credențial direct din portofelul dumneavoastră, prin browserul și sistemul de operare ale dispozitivului pe care îl țineți deja în mână. Pe telefonul pe care se află portofelul nu apare niciun cod QR și nu sunteți trimis într-o altă aplicație și apoi înapoi. Atingeți o singură dată, telefonul vă arată cine cere, iar decizia vă aparține. Pe un laptop, browserul afișează propriul cod QR pentru a ajunge la telefonul dumneavoastră.
Ocolișul pe care îl elimină
Până acum, un site care voia ceva de la un portofel trebuia să facă cumva cererea să ajungă la acel portofel. În practică, asta însemna un cod QR pe pagină sau un link care trimite vizitatorul într-o aplicație și, cu puțin noroc, îl aduce înapoi. Ambele funcționează și ambele pierd oameni la fiecare pas.
Cel mai rău este pe telefon, unde codul QR se află pe același ecran cu camera care ar trebui să îl scaneze. Digital Credentials API elimină această problemă, transformând cererea în ceva ce browserul și sistemul de operare pot transporta singure, pentru că știu deja ce portofele se află pe dispozitiv.
Pe același dispozitiv
Vizitatorul folosește telefonul pe care se află portofelul. Aici Digital Credentials API elimină complet codul QR și trecerea dintr-o aplicație în alta.
Între două dispozitive
Vizitatorul este pe un laptop, iar portofelul pe un telefon, așa că este în continuare nevoie de ceva care să le lege. Diferența este că browserul însuși poate afișa și gestiona acel cod.
Cum arată în practică
Pentru vizitator este o singură atingere pe pagina pe care se afla deja. În spate, browserul transmite cererea sistemului de operare, sistemul de operare găsește portofelele care pot răspunde, iar portofelul afișează cererea spre aprobare înainte de a partaja ceva.
1. Site web
Cere browserului un credențial în loc să afișeze un cod QR sau să deschidă o aplicație
2. Browserul și sistemul de operare
Stabilesc care portofele de pe dispozitiv conțin ceva potrivit și le oferă doar pe acestea
3. Deținător
Vede cine cere și ce anume, alege un portofel și aprobă sau refuză
4. Din nou site-ul web
Primește răspunsul aprobat pe aceeași pagină, pe care vizitatorul nu a părăsit-o niciodată
De ce contează implicarea browserului
Un cod QR este o bucată de hârtie sau o imagine pe un ecran și nu vă poate spune cine l-a pus acolo. Pe asta se bazează tot phishingul prin QR: un atacator înlocuiește codul, portofelul se deschide, iar cererea arată complet normal, pentru că nimic din flux nu știe de unde vine de fapt.
Când cererea trece prin browser, browserul este cel care îi spune portofelului ce site cere, iar acesta nu poate fi convins să mintă. Portofelul poate arăta deținătorului site-ul real, iar răspunsul poate fi legat de acel site, așa că o copie interceptată în altă parte nu îi folosește nimănui. Este o reducere reală a expunerii la fraudă, nu doar un ecran mai fluid.
Cum se îmbină cu OpenID4VP și EUDI Wallet
Este ușor să îl vedeți drept încă un standard între care trebuie să alegeți. Nu este. OpenID4VP rămâne limbajul prin care o parte utilizatoare spune de ce are nevoie și citește răspunsul primit, iar Digital Credentials API este pur și simplu un drum mai bun pentru această conversație, mai ales când totul se petrece pe un singur dispozitiv.
Același lucru este valabil pentru credențialul în sine. O atestare EUDI Wallet sau un mdoc sosește exact în formatul în care ar fi sosit printr-un cod scanat, deci verificările pe care un verificator le face deja rămân neschimbate. Ce câștigă o echipă este opțiunea de a evita ocolișul, fără a reconstrui nimic din ce se află în spate.
Suportul apare browser cu browser și platformă cu platformă, nu peste tot deodată, motiv pentru care părțile utilizatoare îl adoptă alături de varianta cu scanare, nu în locul ei. Abordarea practică este să folosiți API-ul acolo unde dispozitivul îl oferă, să reveniți la un cod acolo unde nu îl oferă și să lăsați varianta de rezervă să dispară pe măsură ce acoperirea crește.
Ce înseamnă asta pentru dumneavoastră
Parte utilizatoare
Mai puțini oameni abandonează fluxul, pentru că pașii la care renunțau au dispărut, iar browserul îi spune portofelului cine sunteți cu adevărat, ceea ce elimină o cale de phishing.
Deținător de portofel
O atingere pe pagina pe care vă aflați deja, numele real al celui care cere și nicio posibilitate ca un site să afle ce portofele aveți, decât dacă spuneți da.
Furnizor de portofel
Portofelul dumneavoastră este propus de sistemul de operare ori de câte ori conține ceva potrivit, așa că a fi găsit nu mai depinde de decizia unei părți utilizatoare de a pune un link către dumneavoastră.
Aprofundare tehnică
Această pagină explică ce face tehnologia și pe cine afectează. Documentația noastră pentru dezvoltatori acoperă implementarea propriu-zisă: mesajele, câmpurile și exemplele detaliate de care are nevoie o echipă de integrare.
Citiți documentația tehnicăTermeni conecși
Întrebări frecvente
Înseamnă asta sfârșitul codurilor QR?
Nu, le restrânge rolul și schimbă cine le generează. Transferul unei cereri de pe un laptop pe un telefon are în continuare nevoie de o punte între cele două, iar API-ul acoperă și acest caz: browserul afișează codul, în loc ca fiecare site să își construiască propriul cod. Ceea ce dispare complet este codul de pe telefonul care conține deja portofelul, unde nu a fost niciodată altceva decât o soluție de avarie.
Poate site-ul să vadă ce portofele am instalate?
Nu. Site-ul descrie ce solicită, iar potrivirea o face sistemul de operare, pe dispozitiv. Site-ului nu i se spune niciodată ce portofele sunt instalate sau care dintre ele conțineau o potrivire. Dacă refuzați, tot ce află este că nu s-a primit nimic, ceea ce pentru el arată exact la fel ca situația în care nu aveți deloc un credențial potrivit.
Înlocuiește acesta OpenID4VP?
Nu, cele două funcționează împreună. OpenID4VP este limbajul în care sunt scrise cererea și răspunsul, iar acesta nu se schimbă. Digital Credentials API este calea de livrare pe dispozitiv, în locul unui cod QR sau al unui link personalizat. O parte utilizatoare care folosește deja OpenID4VP își păstrează logica existentă de cerere și de verificare.
Ce trebuie să construiască, concret, o parte utilizatoare?
Mai puțin decât se așteaptă majoritatea echipelor, pentru că partea care se schimbă este front-end-ul. Cererea generată de backend și verificările pe care le face asupra răspunsului rămân aceleași. Ce adăugați este apelul către browser și, cât timp suportul încă se extinde, o variantă de rezervă prin cod QR pentru vizitatorii al căror browser sau dispozitiv nu poate folosi încă API-ul.
Surse
Această pagină are caracter informativ și nu constituie consultanță juridică. Digital Credentials API este încă în evoluție, așa că pentru formularea oficială consultați direct specificația W3C.