Digital Credentials API

Un site web apelează navigator.credentials.get() cu o cerere de credențial digital care numește un protocol de prezentare și poartă, ca payload, cererea specifică acelui protocol. Browserul transmite cererea sistemului de operare, care afișează un selector nativ cu portofelele instalate pe dispozitiv, iar portofelul ales de deținător returnează răspunsul protocolului prin același apel. API-ul doar transportă schimbul: ce se cere, ce se dezvăluie și cum se verifică răspunsul rămân definite de protocolul din interior. Un apel complementar, navigator.credentials.create(), face același lucru pentru emitere, astfel încât un site poate transmite în același mod un Credential Offer unui portofel.

Înainte de acesta, o prezentare pe dispozitivul pe care deținătorul îl folosea deja însemna fie un cod QR pe care telefonul care îl afișa nu îl putea scana, fie un deep link care trebuia să ghicească ce portofel este instalat. Direcționarea cererii prin sistemul de operare elimină ambele probleme, deoarece deținătorul primește un singur selector nativ care acoperă toate portofelele de pe dispozitiv, iar site-ul nu trebuie niciodată să detecteze sau să numească el însuși un portofel. Browserul adaugă la cerere și originea apelantului, astfel încât portofelul îi poate arăta deținătorului ce site solicită și poate respinge o cerere copiată din altă parte, iar acest lucru face fluxul rezistent la phishing și la atacuri de tip relay.

API-ul este în mod deliberat neutru față de protocol, iar în ecosistemul EUDI Wallet contează două legături: OpenID4VP își definește propriul profil pentru API, iar ISO/IEC 18013-7 Annex C leagă de acesta același schimb mdoc. EUDI ARF îl tratează drept calea de îmbunătățire a prezentării la distanță, cu condiția ca browserul să furnizeze originea părții care se bazează, astfel încât o Wallet Unit să poată stabili cine solicită, și cu condiția ca un flux între dispozitive să păstreze o verificare de proximitate între cele două dispozitive. Astfel, preluarea de pe dispozitiv din ISO/IEC 18013-5 rămâne canalul pentru interacțiunile față în față, nu ceva ce API-ul de browser înlocuiește.

Suportul nu mai este experimental. API-ul este activat implicit în Chrome pe Android și pe desktop, precum și în Safari în versiunile recente Apple, în timp ce Firefox nu l-a activat. Browserele diferă încă în privința protocoalelor și formatelor de credențiale pe care le acceptă, iar suportul pe desktop funcționează în general prin asocierea cu un telefon care conține portofelul, nu prin stocarea credențialelor în browser. Tratați-l ca pe o îmbunătățire pentru browserele și dispozitivele care îl au și păstrați fluxul cu cod QR sau cu redirecționare pentru cele care nu îl au.