Trebuie să suport atât mdoc, cât și SD-JWT VC din prima zi?

Ideal, da, sau ar trebui să treci printr-un strat care abstractizează diferențele de format, pentru că suportul portofelelor și emitenților variază de la un stat membru la altul în perioada de implementare, iar utilizatorii nu ar trebui respinși pentru că dețin formatul „greșit”.

Pot cere un document de identitate complet în loc de atribute specifice?

Tehnic, un portofel poate prezenta o credențială PID completă, dar a cere mai mult decât justifică temeiul tău legal subminează încrederea utilizatorului și creează o expunere inutilă din perspectiva protecției datelor. Cere doar ce necesită procesul tău.

Cât de des trebuie rotite certificatele de acces?

Perioadele de valabilitate diferă în funcție de ecosistem și autoritatea emitentă, dar rotația este de regulă necesară cu mult înainte de expirare pentru a evita întreruperi, iar fiecare ecosistem de portofel suportat adaugă propriul ciclu de viață al certificatelor de urmărit.

Cum accepți credențiale din Portofelul EUDI: ghid practic de integrare

Acceptarea credențialelor din Portofelul EUDI înseamnă implementarea unui protocol de prezentare, verificarea unui lanț de semnături și un UX în care utilizatorii au încredere. Iată traseul practic, integral.

Odată ce ai decis să accepți credențiale din Portofelul EUDI, întrebarea se mută de la „de ce” la „cum funcționează exact asta marți după-amiază, în mediul nostru de staging”. Acest ghid parcurge protocolul, alegerea formatelor, logica de verificare și lista de verificări operaționale necesare înainte de lansarea în producție.

Protocolul: OpenID4VP pe scurt

Ecosistemul Portofelului EUDI standardizează OpenID for Verifiable Presentations (OpenID4VP) ca protocol de schimb între o Parte Utilizatoare (tu) și portofel. Fluxul este construit intenționat aproape de tiparele OAuth/OIDC deja cunoscute, ceea ce este o veste bună pentru echipele care rulează deja integrări SSO.

Backend-ul tău construiește o cerere de autorizare care descrie exact ce atribute ai nevoie, exprimată printr-o definiție de prezentare (DCQL sau formatul mai vechi presentation exchange).
Cererea este semnată cu certificatul tău de acces și trimisă către portofel, de obicei printr-un cod QR (cross-device) sau un deep link (same-device).
Portofelul analizează cererea, verifică înregistrarea ta ca Parte Utilizatoare și certificatul față de infrastructura de încredere, apoi arată utilizatorului un ecran de consimțământ care listează exact ce se cere și de către cine.
La consimțământ, portofelul returnează un token VP care conține una sau mai multe prezentări de credențiale semnate către endpointul tău de răspuns.
Backend-ul tău verifică tokenul, extrage atributele divulgate și continuă fluxul de business.

Nimic din acest flux nu te obligă să stochezi o copie a unui act de identitate. Ceri atribute, nu documente — o distincție subtilă, dar cu implicații legale majore pentru politica ta de retenție a datelor.

mdoc vs SD-JWT VC: ce format să ceri

Două formate de credențiale coexistă în ecosistem, iar cererea ta de prezentare ar trebui să le poată gestiona pe amândouă, pentru că portofele și state membre diferite favorizează formate diferite pe durata implementării.

ISO/IEC 18013-5 mdoc — formatul moștenit din permisul de conducere mobil. Codat în CBOR, verificat cu semnături COSE, legare puternică de dispozitiv la nivel hardware. Comun pentru PID și atestări de tip mDL.
SD-JWT VC — un format bazat pe JSON cu divulgare selectivă: emitentul semnează un set de afirmații, iar deținătorul divulgă doar un subset ales, iar semnătura tot se verifică. Mai ușor de parsat și depanat, tot mai preferat pentru EAA necalificate.
Ambele suportă divulgare selectivă și legare criptografică de cheia dispozitivului din portofel, deci alegerea se face după suportul emitenților și stiva ta de parsare, nu după proprietăți de securitate — niciun format nu este intrinsec „mai sigur” decât celălalt.

Proiectarea cererii de prezentare

Cea mai frecventă greșeală de integrare este cererea excesivă de atribute. Fiecare atribut din cerere trebuie să corespundă unei nevoi legale sau de business reale, pentru că ecranul de consimțământ al portofelului le listează literal pentru utilizator — o cerere umflată pare suspectă și crește rata de abandon.

Pornește de la decizia pe care trebuie să o iei (vârstă peste un prag, valabilitatea unei licențe, statut de angajat) și lucrează invers către setul minim de atribute.
Preferă divulgările tip predicat („peste 18 ani: adevărat”) în locul valorilor brute (data nașterii), oricând formatul și emitentul o permit.
Definește cererile pentru fiecare caz de utilizare, în loc să refolosești un șablon larg în tot produsul.

Verificarea: ce trebuie efectiv confirmat

Primirea unui token VP este partea ușoară. Un verificator corect efectuează mai multe verificări independente, iar omiterea oricăreia dintre ele transformă integrarea ta într-un risc de conformitate.

Validitatea semnăturii credențialei și, unde există, a prezentării în sine (dovada de legare a cheii).
Încrederea în emitent: certificatul emitentului este ancorat în Lista de Încredere a UE aplicabilă sau în lista națională de încredere?
Statusul de revocare al credențialei, verificat față de mecanismul emitentului (listă de status, mecanism tip OCSP sau echivalent).
Prospețimea: legarea de nonce și de audiență pentru a preveni reluarea unei prezentări capturate.
Verificări de schemă și semantică asupra afirmațiilor divulgate, înainte ca acestea să ajungă în logica de business.

Un verificator care verifică semnătura dar nu lista de încredere, sau lista de încredere dar nu revocarea, nu este pe jumătate sigur — este un vector de fraudă care așteaptă să fie găsit.

UX: fluxuri de consimțământ pe care oamenii chiar le finalizează

Verificarea prin portofel este mai rapidă decât încărcarea de documente, dar numai dacă fluxul din jur nu reintroduce fricțiune. Testează fluxul cross-device cu cod QR pe un al doilea telefon real, nu doar într-un simulator, și proiectează un fallback explicit pentru utilizatorii care încă nu au un portofel compatibil — această populație se va reduce, dar nu va fi zero în anii de implementare.

Testare și checklist de lansare

Testează cu fiecare portofel de conformitate/test al statelor membre pe care le vizezi, nu doar cu o singură implementare de referință.
Verifică faptul că rotația certificatelor nu întrerupe cererile aflate în desfășurare într-o fereastră de deployment.
Testează la sarcină calea de semnare a cererilor de prezentare — este o operațiune criptografică nouă pe traseul critic de cereri.
Confirmă că logica ta de retenție a datelor elimină efectiv atributele pe care nu ai dreptul legal să le păstrezi.
Rulează un test comun cu identitatea ta de Parte Utilizatoare înregistrată, în mediul de acceptanță al cel puțin unui stat membru, înainte de lansarea publică.

Unde un intermediar schimbă ecuația

Tot ce ai citit mai sus este muncă standard, bine documentată, de protocol — și, totodată, o suprafață de mentenanță permanentă odată ce intră în joc mai multe state membre, versiuni de portofel și cicluri de certificate. Arkadiz operează ca Parte Utilizatoare intermediară înregistrată: trimiți o singură cerere de verificare către un singur API, iar Arkadiz gestionează transportul OpenID4VP, negocierea formatului, verificarea listelor de încredere și revocarea pentru toate portofelele suportate, astfel încât echipa ta livrează fluxul de produs în loc să retesteze o stivă de protocol de fiecare dată când se schimbă un act de punere în aplicare.