Întrebați o echipă de inginerie cât durează acceptarea unei credențiale din Portofelul EUDI și veți primi, de obicei, un răspuns limitat la fluxul de cerere și verificare OpenID4VP: două până la patru săptămâni. Estimarea nu este greșită, dar măsoară aproximativ 20% din proiectul real. Celelalte 80% reprezintă înregistrarea de reglementare, operarea certificatelor și efortul de mentenanță pentru a rămâne conform pe măsură ce Cadrul de Arhitectură și Referință evoluează. Acest articol detaliază ambele jumătăți, astfel încât să puteți compara construirea internă cu folosirea unui intermediar, pe cifre realiste.
Faza 1: Efortul de inginerie pentru integrarea protocolului
Stratul de protocol în sine — emiterea unei cereri de prezentare, verificarea unui răspuns mdoc sau SD-JWT VC, verificarea statusului de revocare și a prezenței emitentului pe Lista de Încredere a UE — este realmente gestionabil pentru o echipă backend competentă. Așteptați-vă la următoarele dacă construiți intern:
- 2-4 săptămâni pentru un flux funcțional de cerere/răspuns OpenID4VP față de o implementare de referință a unui portofel.
- 1-2 săptămâni pentru a adăuga corect verificarea semnăturilor, validarea lanțului de încredere și verificările de revocare, inclusiv cazurile limită de atestări expirate sau suspendate.
- 1-3 săptămâni pentru fiecare ecosistem suplimentar de portofel, atunci când trebuie susținute portofele din mai multe state membre, deoarece implementările variază subtil, dar real, în ciuda standardului comun.
- 1-2 săptămâni de revizuire de securitate și testare de penetrare înainte de producție, având în vedere că acest flux se află direct în perimetrul de identitate și fraudă.
O estimare realistă de inginerie internă pentru un pilot cu un singur portofel și o singură țară este de 6-10 săptămâni pentru un inginer backend senior, plus revizuire de securitate part-time. Înmulțiți aproximativ cu numărul de ecosisteme de portofel și state membre pe care trebuie să le susțineți în paralel.
Faza 2: Timpul de înregistrare de reglementare
Aceasta este faza pe care aproape niciun plan intern de proiect nu o contabilizează corect. Pentru a solicita prezentări de atribute de la portofele, o organizație trebuie să se înregistreze ca Parte Utilizatoare conform procesului național al fiecărui stat membru în care operează, ceea ce implică de obicei:
- Verificarea entității juridice și depunerea documentației de înregistrare ca Parte Utilizatoare la autoritatea națională de supraveghere.
- Definirea și justificarea setului specific de atribute pe care intenționați să îl solicitați, deoarece înregistrarea este limitată la cazuri de utilizare declarate, nu deschisă.
- Cicluri de revizuire și aprobare care, pe baza proceselor comparabile de înregistrare a prestatorilor de servicii de încredere sub regulamentul eIDAS inițial, durează de obicei 6-16 săptămâni per stat membru și pot dura mai mult în fazele timpurii de implementare, când autoritățile își construiesc încă propria capacitate de procesare.
- Repetarea separată a acestui proces pentru fiecare stat membru suplimentar în care aveți nevoie de statut de Parte Utilizatoare, deoarece nu există o înregistrare unică paneuropeană.
Pentru o companie care operează în trei state membre, doar înregistrarea națională poate adăuga trei până la douăsprezece luni de timp scurs înainte de a putea solicita legal o singură prezentare de atribute — independent de cât de repede termină echipa de inginerie lucrul la protocol.
Faza 3: Operarea certificatelor
Cererile de prezentare trebuie semnate cu certificate de acces emise în cadrul de încredere, iar aceste certificate expiră și trebuie rotite fără întreruperi. Intern, aceasta înseamnă:
- Stabilirea unei relații de emitere a certificatelor pentru fiecare stat membru și, în unele cazuri, pentru fiecare furnizor de portofel.
- Construirea automatizării de rotație și a monitorizării, astfel încât un certificat expirat să nu întrerupă silent onboardingul.
- Gestionarea procedurilor de revocare și reemitere dacă o cheie privată este compromisă sau o autoritate de certificare intermediară își schimbă lanțul.
- Repetarea independentă a tuturor celor de mai sus pentru fiecare ecosistem susținut, deoarece certificatele nu sunt portabile între cadre de încredere.
Aceasta nu este o construcție unică. Este o funcție operațională recurentă care are nevoie de un responsabil, alertare și un manual de proceduri — comparabilă ca amploare cu gestionarea certificatelor TLS la scară enterprise, dar cu mai puține instrumente mature disponibile astăzi.
Faza 4: Mentenanța continuă a conformității
ARF și actele sale de punere în aplicare sunt încă în curs de rafinare. O integrare a verificatorului conformă astăzi poate necesita refacere atunci când un nou act de punere în aplicare clarifică un format de date, un nou tip de credențial este adăugat în ecosistem sau un furnizor de portofel își actualizează SDK-ul. Bugetați acest lucru ca pe o linie permanentă, nu ca pe un cost unic — realist, 10-20% din efortul inițial de inginerie pe an, concentrat în valuri imprevizibile, nu într-un flux constant.
Partea pe care toată lumea o bugetează sunt cele patru săptămâni de lucru la API. Partea care determină de fapt costul total de proprietate sunt cele optsprezece luni de după lansare.
Costul total de proprietate: construire vs. cumpărare
Construirea internă în trei state membre și două ecosisteme de portofel, pe un orizont de doi ani, implică de obicei:
- Inginerie: 3-5 luni de timp de inginerie senior distribuite între construcția inițială și variantele pentru fiecare ecosistem.
- Înregistrare: 3-12 luni de timp calendaristic scurs și ore de personal juridic/conformitate pe mai multe procese naționale, derulate în mare parte în paralel cu ingineria, dar care condiționează lansarea.
- Operarea certificatelor: un responsabil operațional continuu, de regulă o fracțiune de normă întreagă, plus instrumentele aferente.
- Mentenanța conformității: 10-20% din costul inițial de inginerie anual, plus costul de oportunitate al unei echipe care trebuie să rămână la curent cu standardele tehnice europene în evoluție.
Folosirea unei Părți Utilizatoare intermediare precum Arkadiz reduce cea mai mare parte din toate acestea la o singură integrare și o taxă de abonament sau bazată pe utilizare: intermediarul este deja înregistrat în statele membre, operează deja rotația certificatelor și absoarbe deja central schimbările de conformitate pentru toți clienții săi. Efortul de inginerie din partea dumneavoastră scade la integrarea unui singur API, nu a unui stivă întregi de protocol, iar fazele de înregistrare și certificate se mută din calea dumneavoastră critică în cea a intermediarului, care le-a parcurs deja o dată pentru fiecare client pe care îl deservește.
Când construirea internă rămâne justificată
Platformele foarte mari care operează în toate statele membre, cu echipe dedicate de conformitate, sau organizațiile pentru care verificarea prin portofel este un element central de diferențiere a produsului, nu doar o capacitate suport, pot considera justificat costul fix al unei echipe interne pe un orizont suficient de lung. Pentru majoritatea platformelor de dimensiune medie care adaugă acceptarea portofelului ca una dintre mai multe metode de identitate, ruta intermediarului ajunge mai rapid în producție și scoate riscul de conformitate continuă din foaia de parcurs a ingineriei.