Proiectul de lege privind spațiul electronic de comunicare și cel de notificări este o inițiativă benefică și lăudabilă, sunt necesare însă câteva ajustări pentru a asigura coerența legală și tehnică.
Proiectul susține o comunicare unidirecțională, doar de la administrație către cetățean. În acest sens este necesară o clarificare în Art.2 , respectiv textul „comunicarea electronica dintre autoritățile si instituțiile publice și cetățeni” să fie sub forma „comunicarea electronica dinspre autoritățile si instituțiile publice către cetățeni”.
În prezent și, mai ales, în viitor, cetățenii vor dori să acceseze spațiul electronic de comunicare nu doar într-o interfață web ci si cu ajutorul unor aplicații terțe sau chiar a agenților AI. Art.5 (3) impune utilizarea permanentă a unui mijloc de identificare „legalizat” precum CEI, ROeID, etc. Încă nu există mijloace de identificare „legalizate” specifice tehnic protocoalelor API sau MCP. Propun următoarea formulare: „Accesul efectiv al titularului la spațiul electronic de comunicare se realizează la data primei autentificări printr-un mijloc de identificare electronică admis de Lege, ulterior utilizatorul poate genera mijloace de autentificare specifice interoperabilității mașină-la-mașină, în condițiile standardelor tehnice aprobate prin normele metodologice de aplicare a legii.”
Filozofia generală a proiectului implică că spațiul electronic de comunicare este alimentat cu documente de către instituțiile publice încă dinainte ca respectivul cetățean să fi accesat pentru prima dată platforma. Acest lucru este corelat cu obligația instituțiilor publice de a trimite toate documentele generate în relația cu cetățenii. Totuși Art.11 (1) prevede „încetarea utilizării” la inițiativa cetățeanului. Alin (3) prevede că după opt-out spațiul electronic nu mai poate fi utilizat pentru comunicări. Astfel Art.11, în forma actuală, ridică dubii cu privire la punerea sa în aplicare. De unde știe o instituție că un cetățean a optat pentru încetarea contului? Dacă trimite documentul fără a ști de încetare, ce va face platforma (ADR) cu acest document? Îl șterge? Dacă îl șterge se mai jurnalizează această operație? Alin (3) introduce „excepții prevăzute de lege” – dacă platforma (ADR) nu are dreptul să acceseze conținutul documentului, cum se poate identifica condiția de excepție? Vor marca emitenții documentului, în metadate, natura acestuia? Dacă da, nu este aceasta o încălcare a confidențialității mai gravă decât existența unui document pe care nu-l citește nimeni? Dacă este considerată importantă existența mecanismului de opt-out atunci propun renunțarea in Art.11 (3) la excepțiile prevăzute de lege (care nici nu există astăzi cât timp această platformă nu există).
Art.20 (primul – există o eroare de numerotare) ridică probleme serioase de coerență legislativă, cel mai simplu de înțeles este să-l analizăm în corelație cu SPV. Legislația fiscală prevede că un document este comunicat prin punerea la dispoziție în SPV indiferent dacă contribuabilul a accesat ulterior SPV. Acest proiect impune ca documentul fiscal (ex. decizie de impunere) să fie comunicat atât în SPV cât și în platformă. Art. 20 (1) este divergent față de normele SPV, practic avem același document, emitent, dar efectul juridic diferă în funcție de platformă. Art.20 (5) spune că cetățeanul poate opta pentru cea mai favorabilă legislație, asta înseamnă direct că acest tip de documente, care există și în SPV, își pierd valoare juridică (data comunicării care stă la baza termenelor de plată). Va accepta ANAF să trimită documente în această nouă platformă cât timp este subminată valoarea lor juridică? Observație: prevederile (3) nu rezolvă această problemă – utilizator își poate șterge contul din SPV caz în care nu mai există o „lege specială aplicabilă”. Propun reformularea Art.20 astfel: 1) Punerea la dispoziție a comunicării oficiale în spatiu nu produce, prin ea însăși, față de titular, efectele juridice ale comunicării și nu determină curgerea vreunui termen, cu excepția cazului în care, pentru respectivul tip de comunicare, există legislație specială dedicată transmiterii electronice a comunicării, caz în care se aplică respectiva legislație mutatis-mutandis. 2) Se elimină – este redundant cu (1) 3) Se elimină – este redundant cu (1) 4) Se elimină – acesta prevedere contravine principiilor juridice de bază. Efectul juridic al unei comunicări nu poate fi decis decât de emitent. Tot emitentul trebuie să știe, pentru buna organizare a afacerilor sale juridice, care este statusul actelor emise de el. Se poate înlocui cu o prevedere prin care titularul poate opta să nu primească comunicări de la o listă de instituții (black list) dar astfel rămâne problema explicată la Art.11. 5) Se elimină – practic acest aliniat modifică efectul unui număr necunoscut de legi speciale ... De principiu, un Termen este invocat de partea care solicită, nu poate fi ales de subiectul acestuia.
Art.20 (bis) – (1) ar putea fi modificat în forma „ poate invoca în raporturile cu autoritățile publice și în justiție ...” Alin (2) corelat fiind cu 20 (4) ridică aceleași două probleme, chiar întărește incertitudinea emitentului dacă poate invoca documentul.
Art.23 (4) prin expresia „se stochează și se transmit exclusiv în forma criptată” implică, tehnic, criptare „in transit” și criptare „at rest”. Alin (6) impune „acces exclusiv” prin „utilizarea cheii de decriptare asociate acestuia” adică criptare „end-to-end”. Se ridică întrebarea – de unde obține creatorul comunicării cheia publică a destinatarului astfel încât să poată cripta documentul înainte ca acesta să ajungă în perimetrul și sub controlul platformei? Acest lucru este imposibil în cazul utilizatorilor care încă nu au utilizat platforma. Singura soluție tehnică este ca platforma să genereze certificate pentru fiecare utilizator, la primirea primului document de către acesta, o soluție fără sens atât timp cât declarativ platforma nu poate avea acces la conținutul comunicării. Secretul poate fi asigurat doar dacă certificatul asociat utilizatorului este emis de un terț, diferit de operatorul platformei. Acest obiectiv extrem de important (confidențialitatea în fața platformei) poate fi abordat rezonabil prin următoarele opțiuni: Opțiunea ambițioasă – criptare end to end. Legea trebuie să prevadă un repository sau mecanism de distribuție a cheii publice utilizate de cetățean iar emitentul comunicării să descarce cheia (prin API) și să cripteze cu ea comunicarea înainte de a o trimite către platformă Opțiunea decentă – criptarea at rest. La primirea comunicării platforma criptează comunicarea cu cheia publică aferentă cetățeanului. Această cheie provine, în ordine de precedență, dintr-un certificat uploadat de utilizator, de pe CEI pentru cei care încă nu au accesat platforma (prin interoperabilitate cu MAI), dintr-un certificat generat de platformă pentru cei fără CEI.
În orice caz, este absolut necesară evitarea scenariului în care se emit doar certificate pentru utilizatori interne platformei. În acest sens propun următoarea formă a Art.23 (6) „Accesul la conținutul comunicărilor oficiale se realizează exclusiv de către titular, prin utilizarea cheii de decriptare asociate acestuia, aferentă unui certificat furnizat de utilizator sau furnizat de platformă în lipsa exercitării acestei opțiuni, în condițiile stabilite prim normele metodologice de aplicare a Legii.”. Evident, utilizarea unui certificat propriu este aliniată conceptului „bring your own key” și impune acestei categorii de utilizatori accesarea comunicării prin descărcarea acesteia, nu în browser – nu va fi un procent foarte mare de opțiuni în acest sens dar este obligatorie respectarea nevoii de garanție de confidențialitate a acestor utilizatori.
Art. 28 – se referă eronat pe el însuși, ar trebui să refere Art.27. Iarăși ideea ciudată că Poliția are competențele profesionale necesare pentru a constata încălcări ale unei legi cu specific de interoperabilitate informatică !