Divulgarea selectivă este adesea descrisă ca și cum ar fi o funcție de conformitate GDPR. Nu este — este o capacitate criptografică ce permite unui portofel să dezvăluie doar anumite atribute dintr-o credențială, nu întregul obiect semnat. Dacă această capacitate produce efectiv un flux de date conform cu GDPR depinde în întregime de ce solicită Partea Utilizatoare, de ce anume, și ce se întâmplă cu datele ulterior. Un verificator care cere cincisprezece atribute pentru că portofelul le permite din punct de vedere tehnic nu este mai conform decât unul care încă scanează acte de identitate complete.
Ce schimbă efectiv divulgarea selectivă
În formatele SD-JWT VC și mdoc, un emitent semnează o credențială ce conține mai multe atribute, dar protocolul de prezentare permite deținătorului să dezvăluie doar un subset, păstrând în același timp dovada criptografică că atributele dezvăluite provin dintr-o credențială emisă autentic și nealterată. Practic, aceasta înseamnă că o Parte Utilizatoare poate cere și primi o singură valoare booleană — „are peste 18 ani” — fără să vadă vreodată data nașterii, numărul documentului sau o fotografie.
Aceasta este o îmbunătățire arhitecturală reală față de scanarea documentelor, unde minimizarea era imposibilă deoarece întregul document trebuia capturat pentru a extrage un singur fapt. Dar îmbunătățirea se materializează doar dacă cererea Părții Utilizatoare este efectiv limitată la minimul necesar — protocolul nu impune acest lucru în locul dumneavoastră.
Minimizarea datelor rămâne obligația dumneavoastră legală, nu a protocolului
Articolul 5(1)(c) GDPR impune ca datele cu caracter personal să fie adecvate, relevante și limitate la ceea ce este necesar pentru scop. Când definiți o cerere de prezentare, luați o decizie de protecție a datelor, nu doar una tehnică. Întrebarea la care trebuie să răspundeți înainte de a scrie cererea nu este „ce ne-ar putea spune această credențială”, ci „care este singurul fapt care satisface scopul nostru legal sau contractual real”.
- Verificarea vârstei pentru un produs cu restricții: solicitați o valoare booleană „peste 18 ani”, nu data nașterii.
- Verificarea licenței profesionale: solicitați o valoare booleană „licență valabilă” și categoria licenței, nu întreaga înregistrare din registrul profesional.
- Verificarea statutului de angajat: solicitați un atribut de statut de angajare dintr-o atestare emisă de angajator, nu un extras complet al contractului de muncă.
- Verificări de rezidență în scopuri de reglementare: solicitați atributul „țară de reședință”, nu adresa completă.
Fiecare dintre aceste înlocuiri este posibilă doar pentru că atestările necalificate și câmpurile PID sunt suficient de granulare pentru a susține cereri la nivel de atribut. Proiectarea acestei liste de cerere este, în practică, principala decizie de proiectare din perspectiva protecției datelor într-o integrare cu portofelul.
Temeiul juridic nu dispare pentru că datele sunt verificate
O concepție greșită comună este că, deoarece o credențială din portofel este verificată criptografic și consimțită în momentul prezentării, obligațiile Părții Utilizatoare privind temeiul juridic GDPR sunt cumva simplificate. Nu sunt. Ecranul de consimțământ al portofelului guvernează decizia de divulgare a utilizatorului în ecosistemul portofelului; el nu constituie, prin el însuși, temeiul juridic al organizației dumneavoastră conform Articolului 6. Tot trebuie să identificați și să documentați dacă temeiul dumneavoastră este necesitatea contractuală, obligația legală, interesul legitim sau consimțământul obținut prin propria notificare de confidențialitate — și acesta trebuie să corespundă exact setului de atribute pe care îl solicitați.
Ecranul de consimțământ al portofelului îi spune utilizatorului ce solicitați. Nu îi spune responsabilului dumneavoastră cu protecția datelor de ce aveți dreptul legal să solicitați acest lucru.
Obligații DPIA pentru Părțile Utilizatoare
Verificarea la scară a credențialelor din portofel implică de regulă prelucrarea sistematică a atributelor de identitate legate de un identificator unic, legat criptografic, ceea ce declanșează de obicei criteriile pentru o Evaluare a Impactului asupra Protecției Datelor (DPIA) conform Articolului 35, în special acolo unde sunt implicate date de categorie specială, prelucrare la scară largă sau luare de decizii automatizate pe baza atributelor verificate. O DPIA pentru o integrare cu portofelul ar trebui să abordeze în mod specific:
- Setul exact de atribute solicitate și justificarea necesității pentru fiecare dintre ele.
- Perioadele de retenție atât pentru răspunsul brut de prezentare, cât și pentru orice înregistrare derivată (precum „vârsta verificată la data [data]”).
- Dacă rezultatele verificării sunt înregistrate într-un mod care ar putea fi reidentificat sau combinat cu alte date pentru a construi un profil mai amplu.
- Rolul și fluxurile de date ale oricărei Părți Utilizatoare intermediare folosite pentru verificarea tehnică, inclusiv ce reține aceasta față de ce transmite mai departe.
- Implicațiile transferurilor transfrontaliere dacă intermediarul sau emitentul se află în infrastructura de încredere a altui stat membru.
Riscul de solicitare excesivă este acum vizibil
Onboardingul bazat pe documente ascundea supra-colectarea într-un singur pas de captură — nimeni nu vedea exact ce era extras dintr-un act scanat. Cererile de prezentare din portofel sunt opusul: portofelul utilizatorului afișează exact ce atribute sunt solicitate și de către ce organizație, înainte de consimțământ. O cerere pentru adresa de domiciliu în scopul verificării vârstei, sau o cerere pentru numele complet și identificatorul național pentru verificarea statutului de licență profesională, este acum vizibilă utilizatorului chiar în momentul solicitării, nu ascunsă într-o politică de confidențialitate. Solicitarea excesivă este acum un risc reputațional și de reglementare vizibil utilizatorului prin proiectare, ceea ce crește costul practic al unei erori în definirea sferei cererii.
Retenția: verificat nu înseamnă stocabil
Un atribut verificat rămâne date cu caracter personal odată stocat, iar principiul limitării stocării din GDPR se aplică întocmai ca oricăror altor date personale. În majoritatea scenariilor de onboarding, tiparul apărabil este să reținem doar rezultatul verificării (o valoare booleană, o marcă temporală și o referință la evenimentul de verificare), nu valoarea atributului subiacent, și să definim o perioadă de retenție legată de scop — de exemplu, durata unei relații contractuale active plus orice perioadă legală de retenție, nu o stocare nedefinită pe motiv că verificarea a fost convenabil de obținut.
Cum afectează intermedierea tabloul de conformitate
Folosirea unei Părți Utilizatoare intermediare schimbă fluxul de date, iar DPIA și registrul dumneavoastră de activități de prelucrare trebuie să reflecte corect acest lucru: intermediarul gestionează de regulă verificarea brută a semnăturii și verificările lanțului de încredere, și transmite sistemelor dumneavoastră doar rezultatul specific al atributului solicitat. Acesta este, în sine, un beneficiu de minimizare — infrastructura dumneavoastră nu atinge niciodată sarcinile utile ale credențialelor semnate de care nu are nevoie — dar înseamnă și că acordul de prelucrare cu intermediarul trebuie să definească clar ce se prelucrează în numele dumneavoastră, ce reține intermediarul pentru propriile obligații de audit și conformitate, și pentru cât timp. Modelul Arkadiz este construit în jurul transmiterii doar a rezultatului atributului solicitat către Părțile Utilizatoare, ceea ce păstrează integral beneficiul de minimizare al divulgării selective, în loc să reintroducă supra-colectarea la nivelul intermediarului.