eIDAS 2.0: specificații pentru semnături și sigilii electronice în fluxuri API B2B publicate de organismele europene

În ultimele trei luni, Comisia Europeană, împreună cu organismele de standardizare ETSI și comunitatea eIDAS Expert Group, au publicat și consolidat specificații tehnice care clarifică felul în care semnăturile electronice calificate (QES) și sigiliile electronice calificate (QSeal) se aplică în fluxuri API B2B, atât în scenarii EDI, cât și non‑EDI. Pentru directorii generali, financiari, de vânzări, achiziții și logistică, mesajul este dublu: conformitatea devine mai predictibilă, iar automatizarea end‑to‑end a tranzacțiilor digitale – de la comandă la încasare – se poate face cu garanții juridice uniforme în toată UE.

Ce s-a clarificat din perspectiva eIDAS 2.0

Cadrul eIDAS 2.0 (noul regulament privind identitatea digitală europeană) stabilește o bază comună pentru identificare electronică, semnături și sigilii în formate interoperabile. În ultimele luni, documentele tehnice publicate de Comisie și referințele către standardele ETSI au pus accent pe:

• Utilizarea semnăturilor și sigiliilor în fluxuri orientate pe API, nu doar pe documente PDF/XML. În mod specific, maparea semnăturilor la obiecte JSON prin JAdES (ETSI TS 119 182), respectiv împachetarea mesajelor semnate în containere ASiC (ETSI EN 319 162), pentru trasabilitate și probatoriu unitar.
• Profile de încredere pentru semnare la distanță și server‑side, conforme cu eIDAS, folosind module de activare a semnăturii (SAD) și dispozitive calificate (QSCD) operate de furnizori calificați de servicii de încredere (QTSP). Asta face fezabilă semnarea masivă a tranzacțiilor B2B în back‑end.
• Continuitatea și reutilizarea modelului PSD2 pentru protejarea API‑urilor prin certificate eIDAS: QWAC pentru autenticarea TLS a canalului și QSealC pentru sigilarea la nivel de mesaj. ETSI TS 119 495, deja consacrat în open banking, este preluat ca referință în multe profile B2B.
• Interoperabilitatea cu viitorul Portofel European de Identitate Digitală (EUDI Wallet), inclusiv modul în care atribute calificate (QEAA) și semnături/calificări pot fi consumate de aplicații enterprise prin interfețe standard, fără a rupe lanțul de încredere eIDAS.

Implicații concrete pentru API‑urile B2B

Dincolo de conformitate, schimbarea majoră este că “semnarea” nu mai aparține doar documentelor, ci oricărui payload de afaceri. Pentru procesele non‑EDI (REST/JSON), JAdES aduce un echivalent “qualified” al JWS/JWT: acel contract, comanda sau mesaj de livrare poate fi semnat/ștampilat electronic de sistem, cu un QSeal emis pe companie, în timp ce canalul API este securizat cu QWAC.

În EDI, standardele existente sunt întărite. Canalele AS4/ebMS3 rulate pe rețele precum Peppol folosesc deja certificate conforme eIDAS pentru autenticare și non‑repudiere. În e‑facturare, obligațiile naționale (ex. Italia – SDI, România – RO e‑Factura, Franța – PPF/Y‑model) se bazează pe sigilii și validări cu TSP‑uri, iar eIDAS 2.0 încurajează convergența către profile unitare. Practic, același QSeal poate însoți atât factura UBL trimisă pe Peppol, cât și o cerere de plată inițiată pe un API intern.

Cine mișcă deja piața

• Bănci și open banking: BNP Paribas, ING, Santander și Deutsche Bank operează de ani buni API‑uri expuse cu QWAC/QSealC conform eIDAS în cadrul PSD2. Modelul lor este acum replicat în B2B non‑financiar, de la portaluri de furnizori la platforme logistice.
• Furnizori QTSP: InfoCert (Tinexta), Namirial, D‑Trust (Bundesdruckerei), GlobalSign, LuxTrust, Camerfirma sau Intesi Group oferă certificate QES/QSeal și componente de semnare la distanță compatibile cu fluxuri API. Multe au SDK‑uri pentru JAdES și ASiC, ușurând integrarea în aplicații enterprise.
• Digitalizare EDI și non‑EDI: SAP (Document and Reporting Compliance), OpenText, Pagero, Comarch, IBM Sterling și Basware integrează eIDAS în e‑invoicing/e‑delivery. În zona non‑EDI, platforme precum Microsoft Azure API Management, Kong sau Apigee pot ancora politici mTLS cu QWAC și validare de sigilii pe mesaj.
• Mari ecosisteme de supply chain: DHL, Maersk, DB Schenker sau Amazon Business susțin interfețe API la scară, iar adoptarea eIDAS pentru identificare și sigilare pe mesaj reduce disputele operaționale (cine a trimis ce, când) și accelerează reconcilierea.

Ce înseamnă asta pentru CFO, CEO și liderii comerciali

eIDAS 2.0 nu este doar un proiect de conformitate IT. Este o oportunitate să “semnați” automat fiecare punct critic din Order‑to‑Cash sau Procure‑to‑Pay:

• Comenzi, oferte, confirmări de livrare și avize de expediție pot fi sigilate electronic la nivel de sistem. Dispare nevoia de dovezi suplimentare în litigii – lanțul probatoriu este nativ în mesaj.
• Facturile emise și primite pot fi semnate/sigilate și validate automat cu biblioteci conforme (ex. DSS open‑source), reducând costurile de audit și timpul de închidere lunară.
• Onboarding de parteneri cu identități verificate: combinația dintre eIDAS și viitorul EUDI Wallet simplifică know‑your‑business pentru furnizori/distribuitori, fără schimb de PDF‑uri și ștampile umede.

Pași recomandați în următoarele 90 de zile

1. Evaluați expunerile API critice (EDI și non‑EDI): ce mesaje trebuie semnate, ce canale trebuie autentificate cu QWAC, ce entități (persoană vs. companie) semnează.
2. Selectați un QTSP pentru QSeal/QES și un mod de semnare: client‑side (token/HSM propriu) sau remote signing prin QSCD operat de QTSP. Verificați prezența în EU Trusted List (EUTL).
3. Implementați JAdES pentru payload‑uri JSON și ASiC pentru pachete multi‑fișier. Pentru documente PDF, păstrați PAdES; pentru XML, XAdES. Standardele pot coexista.
4. Actualizați gateway‑ul API: mutual TLS cu QWAC, validare CRL/OCSP, pinning pe autorități din EUTL, loguri imutabile pentru audit.
5. Aliniați politicile de arhivare electronică cu cerințele de conservare și verificabilitate pe termen lung (profiluri “-LTA” acolo unde este cazul).

Capcane de evitat

• “Semnătură” ≠ doar criptare TLS. TLS protejează canalul; semnătura/sigilul protejează mesajul. Regulile probatorii depind de acesta din urmă.
• Certificate non‑calificate pentru procese critice. În unele piețe și industrii, doar QES/QSeal oferă prezumția legală puternică dorită în disputele comerciale.
• Ignorarea verificării automate. Fără validare OCSP/CRL și contrasemnătură de timp, câștigați puțin în audit. Automatizați validarea la recepție.

De ce acum

În contextul eIDAS 2.0, Comisia a făcut în ultimele luni un pas decisiv: a legat explicit standardele ETSI de scenariile API, nu doar de documente. Experiența PSD2 a validat deja modelul QWAC/QSeal pentru milioane de apeluri API zilnic în bănci precum ING sau BNP Paribas. Același model se aplică acum contractelor, comenzilor, facturilor și notificărilor logistice, indiferent dacă trec printr‑un VAN EDI sau printr‑un endpoint REST.

Concluzie

eIDAS 2.0 transformă semnătura electronică dintr‑un accesoriu juridic într‑un atribut nativ al tranzacțiilor B2B. Cu JAdES și ASiC pentru API‑uri, cu QWAC/QSeal pentru canal și mesaj, liderii de business pot reduce fricțiunea operațională, pot crește rata de automatizare și pot obține o apărare juridică solidă la cost marginal. Fie că rulați EDI clasic sau microservicii moderne, este momentul să tratați “semnătura” ca pe un control de produs, nu ca pe un proiect punctual de conformitate.