ARF este un document obligatoriu din punct de vedere legal?

Nu direct — Regulamentul eIDAS și actele sale de punere în aplicare sunt textele juridice obligatorii. ARF este specificația tehnică ce operaționalizează aceste cerințe, dar cadrele naționale și actele de punere în aplicare îl referențiază sau îl încorporează frecvent, ceea ce îi conferă o forță practică puternică.

Cât de des se schimbă ARF?

ARF este publicat și actualizat iterativ, nu pe un ciclu anual fix, cu revizuiri determinate de feedbackul din pilotări, de testele de interoperabilitate și de alinierea cu actele de punere în aplicare pe măsură ce sunt finalizate.

Fiecare Parte Utilizatoare trebuie să urmărească direct versiunile ARF?

Doar dacă te integrezi direct cu portofelele. Organizațiile care folosesc o Parte Utilizatoare intermediară se bazează pe aceasta pentru a urmări și adopta schimbările ARF, ceea ce elimină nevoia unei funcții interne permanente de conformitate pentru acest domeniu specific.

Cadrul de Arhitectură și Referință (ARF): ghid pentru integratori

ARF este manualul tehnic viu din spatele fiecărui portofel, emitent și Parte Utilizatoare din ecosistem. A înțelege cum se schimbă contează la fel de mult ca a înțelege ce spune azi.

Cadrul de Arhitectură și Referință, cunoscut în ecosistem simplu drept ARF, este specificația tehnică ce transpune textul juridic al Regulamentului eIDAS revizuit într-o arhitectură implementabilă: protocoale, formate de date, modele de încredere și cerințe de securitate. Dacă regulamentul spune ce trebuie realizat, ARF spune cum se construiește — iar orice integrare de portofel, emitent sau Parte Utilizatoare se leagă în cele din urmă de el.

Unde se situează ARF în stiva de reglementare

ARF este produs și menținut colaborativ de statele membre și Comisia Europeană, alimentat de programele pilot (Large-Scale Pilots) care au testat sub presiune versiunile timpurii în implementări reale. Se situează între Regulamentul eIDAS și actele sale de punere în aplicare, pe de o parte, și soluțiile de portofel efective și implementările de referință, pe de altă parte.

Regulamentul eIDAS și actele de punere în aplicare — cerințele juridice obligatorii.
ARF — arhitectura tehnică și specificațiile care îndeplinesc aceste cerințe.
Soluțiile naționale de portofel și implementările de referință — software concret construit conform ARF.

Blocurile principale

Pentru un integrator, ARF se înțelege cel mai ușor ca un set de blocuri, fiecare acoperind un strat al ecosistemului de încredere.

Arhitectura portofelului — instanța de portofel, atestarea unității de portofel și modelul de legare de dispozitiv care garantează că o credențială este legată de un portofel specific și autentic.
Formate și protocoale de credențiale — mdoc (ISO/IEC 18013-5) și SD-JWT VC ca formate standardizate de prezentare, schimbate prin OpenID4VCI pentru emitere și OpenID4VP pentru prezentare.
Modelul de încredere — înregistrarea, emiterea certificatelor și Listele de Încredere ale UE care permit oricărui participant să verifice că un altul face legitim parte din ecosistem.
Cerințe de confidențialitate și securitate — divulgare selectivă, considerații privind nelegabilitatea (unlinkability) și cerințe despre ce pot și ce nu pot păstra emitenții și Părțile Utilizatoare.
Guvernanță — procesele prin care statele membre, Comisia și grupurile tehnice de lucru propun, analizează și adoptă schimbări.

ARF nu este o specificație pe care o implementezi o singură dată. Este o specificație cu care integrarea ta are o relație continuă.

Cum evoluează ARF

ARF este versionat și publicat iterativ, nu înghețat la o singură ediție. Schimbările vin din mai multe direcții simultan: grupuri tehnice de lucru care rafinează detalii de protocol, state membre care raportează friction din pilotări reale și Comisia care aliniază cadrul cu actele de punere în aplicare pe măsură ce sunt finalizate.

O schimbare este propusă, adesea pe baza testelor de interoperabilitate sau a feedbackului din pilotări.
Este discutată și rafinată cu reprezentanții tehnici ai statelor membre și grupurile de lucru relevante.
Se publică o nouă versiune ARF, de obicei cu note despre ce s-a schimbat și de ce.
Implementările de referință și soluțiile naționale de portofel se actualizează pentru a reflecta noua versiune, în ritmul propriu.
Părțile Utilizatoare și emitenții sunt așteptați să urmărească și să adopte schimbările relevante pentru integrarea lor.

Asta înseamnă că două portofele aflate simultan în producție pot fi construite pe revizii ARF ușor diferite, mai ales în perioada actuală de implementare. O integrare robustă tratează flexibilitatea de protocol și de format ca pe o cerință de bază, nu ca pe un caz marginal.

Conformitatea: ce acoperă efectiv

Conformitatea în acest ecosistem nu este un certificat unic, obținut o singură dată. Acoperă mai multe straturi: soluțiile de portofel trebuie să treacă teste de conformitate față de specificațiile tehnice ale ARF, Părțile Utilizatoare trebuie să îndeplinească cerințe de înregistrare și de certificare stabilite de cadrele naționale derivate din ARF, iar emitenții de credențiale trebuie să implementeze protocoalele de emitere și mecanismele de status definite de ARF.

Testarea de conformitate implică de regulă suite de teste de interoperabilitate rulate față de implementări de referință și, uneori, participarea la evenimente de testare coordonate la nivelul statelor membre.
Conformitatea nu este permanentă: o nouă versiune ARF poate introduce cerințe pe care o integrare deja implementată nu le mai îndeplinește integral.
Autoritățile naționale de supraveghere interpretează și aplică cerințele derivate din ARF în propriile procese de înregistrare, ceea ce adaugă un strat de variație locală peste baza tehnică comună.

Ce înseamnă o schimbare de versiune pentru integrarea ta

Când ARF trece la o nouă versiune, impactul practic pentru un integrator variază de la neglijabil la semnificativ, în funcție de ce s-a schimbat. Categoriile tipice includ:

Clarificări — nu necesită modificări de cod, dar merită verificate față de propriile presupuneri de implementare.
Capabilități opționale noi — pot fi adoptate oportunist, adesea pentru a îmbunătăți UX sau a reduce datele cerute.
Schimbări ale formatelor obligatorii, ale detaliilor modelului de încredere sau ale cerințelor de securitate — acestea necesită de regulă modificări de cod, retestare și, uneori, recertificare într-o perioadă de tranziție definită.

Urmărirea schimbărilor ARF nu este o sarcină de conformitate punctuală; este un input ingineresc recurent, similar cu urmărirea depreciărilor TLS sau a actualizărilor de bune practici de securitate OAuth, cu diferența că termenele sunt stabilite de procesul de reglementare, nu de propria ta foaie de parcurs.

Reducerea efortului de mentenanță

Organizațiile care se integrează direct alocă de regulă un responsabil permanent pentru monitorizarea ARF și a actelor de punere în aplicare, pentru că ratarea unei ferestre obligatorii de schimbare poate însemna că un portofel încetează să mai accepte cererile tale de prezentare fără avertisment. Alternativa este integrarea printr-o Parte Utilizatoare intermediară care urmărește deja aceste schimbări în fiecare stat membru în care operează. Acesta este modelul oferit de Arkadiz: menține conformitatea cu ARF, suportul de formate și actualizările modelului de încredere în numele tău, astfel încât o schimbare de versiune în cadru este absorbită în amonte, nu devine un tichet de urgență în restanța echipei tale de inginerie.