2026 m. balandžio 29 d. Europos Komisija paskelbė DPP registro įgyvendinimo reglamento projektą ir tuo pačiu metu pradėjo keturių savaičių trukmės atsiliepimų teikimo laikotarpį. Iki 2026 m. gegužės 27 d. kiekvienas asmuo ir kiekviena organizacija ES ir už jos ribų gali pateikti atsiliepimus per portalą „Have Your Say“. Atsiliepimai yra vieši, kiekvienas pasirašytas vardu ir pavarde arba organizacijos pavadinimu, ir jie oficialiai įtraukiami į galutinę reglamento redakciją.
Šį projektą išsamiai aptarėme šiame tinklaraštyje. Šį įrašą skiriame klausimui, ką atsakėme Komisijai.
Kodėl pateikėme keturis atskirus atsiliepimus
Portale vienam įrašui leidžiama įvesti 4 000 ženklų. Būtume galėję visus punktus sutalpinti į vieną ilgą įrašą. Tačiau Komisijos darbuotojams, kurie gegužę turės peržiūrėti dešimtis komentarų, tai būtų buvę nepatogiau skaityti ir sunkiau cituoti. Keturios atskiros pastabos viešame sąraše yra lengvai randamos, ir į kiekvieną iš jų galima atsakyti - arba atmesti - atskirai, nedarant įtakos kitiems punktams.
Pateikėme šias keturias temas:
1. Nustatyti minimalius reikalavimus DPP paslaugų teikėjams
Reglamento projekte teisingai apibrėžtas decentralizuotas modelis: DPP duomenys saugomi pas ūkio subjektą arba jo DPP paslaugų teikėją, o Komisijos registre saugomos tik nuorodos. DPP paslaugų teikėjams (ESPR 2 straipsnio 32 punktas) numatytas oficialus patvirtintų teikėjų sąrašas.
Trūksta nuostatos, apibrėžiančios, ką paslaugų teikėjas iš tikrųjų turi atlikti, kad patektų į šį sąrašą ir jame išliktų. Tikėtina, kad esminės pareigos bus nustatytos deleguotajame teisės akte pagal ESPR pagrindinio reglamento 4 straipsnį. Tačiau registras pradės veikti dar prieš paskelbiant šį teisės aktą.
Mūsų pasiūlymas: arba tiesiogiai šiame įgyvendinimo reglamente nustatyti minimalius reikalavimus paslaugų teikėjams, arba nurodyti privalomą terminą, iki kurio turi būti pateiktas deleguotasis teisės aktas. Siūlomi minimalūs reikalavimai apima:
- Viešosios DPP skaitymo sąsajos prieinamumas - ne mažiau kaip 99,5 proc. per mėnesį
- Paslaugų lygio susitarimas, nustatantis, per kiek laiko nauja DPP versija turi būti įtraukta į atsarginę kopiją (pasiūlymas: per 24 valandas arba realiuoju laiku, jei tai techniškai įmanoma)
- Privalomas paslaugų teikėjo atliekamas gaunamų versijų kriptografinis patikrinimas
- Ekonominio subjekto viešųjų raktų paskelbimas standartizuotu keliu (RFC 8615, pasiūlymas
/.well-known/dpp-keys/) - Nustatyta perėjimo ir nemokumo procedūra, kad paslaugų teikėjo veiklos nutraukimo atveju DPP duomenys būtų tvarkingai perkelti kitam teikėjui
Šios prievolės patikimam teikėjui nieko nekainuoja - jis jas vykdo bet kokiu atveju -, tačiau užkerta kelią pigių paslaugų teikėjų „lenktynėms į dugną“, kurios galiausiai pakenktų sąrašui.
2. Registruotų DPP ilgalaikis patikrinamumas
9 straipsnio 4 dalyje numatyta, kad registracijos patvirtinimo galiojimo laikas neviršija 90 kalendorinių dienų. Per šį laikotarpį registras paprašius iš naujo išduoda patvirtinimą. Tai tinka einamajai veiklai, tačiau neatitinka susijusios DPP prievolės gyvavimo ciklo: 10 straipsnio 3 dalyje numatyta, kad standartinis saugojimo laikotarpis yra 10 metų nuo registracijos, o sektorių teisės aktai gali numatyti ilgesnį laikotarpį.
2032 m. rinkos priežiūros institucija, muitinės pareigūnas, perdirbėjas ar tyrėjas turėtų galėti patikrinti, ar 2026 m. užregistruotas DPP iš tiesų buvo užregistruotas, nepriklausydamas nuo to, ar pirminis ūkio subjektas vis dar egzistuoja ir gali paprašyti naujo patvirtinimo.
Mūsų du pasiūlymai yra lengvai įgyvendinami:
- Aiškiai nurodyti, kad Komisijos kvalifikuotai užantspauduoti įrodymų baitai gali būti laikinai saugomi, archyvuojami ir platinami toliau ūkio subjekto arba paslaugų teikėjo. Kvalifikuotas antspaudas pagal eIDAS reglamento 35 straipsnio 2 dalį užtikrina vientisumo ir kilmės prezumpciją, nepriklausomai nuo to, kur yra saugomi baitai.
- Sukurti viešą, neautentifikuotą patikrinimo tašką registre, kuris pateiktų pasirašytą atsakymą pagal registracijos ID. Šiandien kiekvienas trečiosios šalies patikrinimas reikalauja, kad ūkio subjektas imtųsi veiksmų - tai netinkama forma įrodymo dokumentui, kuris turi išlikti ilgiau nei jo išdavėjas.
Be to, pasiūlėme deterministiškai nustatyti hash funkciją: SHA-256 kaip maišos funkciją, JSON kanonizacijos schemą (RFC 8785) kaip serijavimą, už parašo bloko ribų. W3C ekosistemoje tai yra kriptografinis rinkinys „eddsa-jcs-2022“, kuriuo „Transpareo“ tiesiogiai pasirašo. Be šio „pinning“ nustatymo du paslaugų teikėjai tą patį DPP serijizuotų į skirtingus hash’us, o registracijos patvirtinimo hash’o laukas nebūtų atkuriamas.
3. 17 straipsnis neturi riboti prieigos prie viešų DPP duomenų
17 straipsnyje „masinis duomenų atsisiuntimas“ nurodytas kaip galimas registro piktnaudžiavimas. Tai teisinga registrą sudarančių administracinių metaduomenų (tapatybių, žurnalų, audito sekų) atžvilgiu - jos neturėtų būti atsisiunčiamos masiniu būdu.
Tačiau viešieji DPP duomenys, esantys pas gamintoją ar paslaugų teikėją, yra būtent ta sritis, kurią ESPR siekia padaryti plačiai prieinamą. Perdirbėjai, kurie renka sudėtinius duomenis apie produktų parkus; mokslininkai, kurie kryžmiškai vertina tvarumo teiginius; rinkos priežiūros institucijos, atliekančios lyginamąsias analizes - visa tai yra „masinio duomenų atsisiuntimo“ iš viešojo DPP sluoksnio formos, ir visos šios tikslingos naudojimo rūšys, dėl kurių ir buvo parengtas šis reglamentas.
Siūlome į 17 straipsnį įtraukti paaiškinamąjį sakinį, kuris taikymo sritį apribotų registrų duomenimis, o dėl DPP duomenų nukreiptų į atitinkamus sektorių specifinius deleguotuosius teisės aktus. Priešingu atveju paslaugų teikėjai veiklos pradžioje susidurs su dilema: arba saugumo sumetimais griežtai apriboti viešąją prieigą - ir sugadinti vartotojų patirtį - arba palikti ją atvirą ir rizikuoti, kad vėliau tai bus įvertinta kaip piktnaudžiavimas 17 straipsnio prasme.
4. Prieš pradedant veiklą paskelbti „OpenAPI“ specifikaciją ir „sandbox“
3 straipsnio b punkte reikalaujama turėti API registracijoms. 8 straipsnio 5 dalyje ji nurodyta kaip vienas iš dviejų registracijos kanalų. Tačiau reglamente nieko nepasakyta apie tai, kada turi būti paskelbta API sutartis.
Kas automatizuoja registracijos procesus - kiekvienas paslaugų teikėjas ir kiekvienas rinkos dalyvis, turintis didesnį katalogą - turi gauti API specifikaciją gerokai prieš paleidimą, kad galėtų ją įgyvendinti ir išbandyti su tikru galiniu tašku. Jei specifikacija bus paskelbta likus vos savaitei iki įsigaliojimo, integracijos rizika bus perkelta visiems ekosistemos teikėjams.
Todėl mes pasiūlėme:
- Paskelbti „OpenAPI 3.1“ specifikaciją ne vėliau kaip aštuonias savaites prieš įsigaliojimą - taigi, jei įsigaliojimas numatytas 2026 m. liepos 19 d., tai iki 2026 m. gegužės 24 d.
- lygiagrečiai sukurti „sandbox“ aplinką, kurioje paslaugų teikėjai ir gamintojai galėtų integruoti savo sistemas ir išbandyti 8 straipsnio 6 dalyje numatytą automatinį patikrinimą
- taikyti versijų valdymo politiką pagal „Semver“ standartą, numatant ne mažiau kaip 18 mėnesių išankstinio įspėjimo laikotarpį
Papildomi projektavimo pasiūlymai: idempotentiškumo raktus registracijos iškvietimuose, didelių katalogų registraciją partijomis, asinchroninę registraciją su „Webhook“ atgaliniu skambučiu ir mašinai suprantamus klaidų kodus automatinio patikrinimo klaidų atvejais.
Kodėl tai darome
Konsultacijos nėra žaidimas, skirtas taškams rinkti. Jei kiekvienas įnašas padeda patikslinti bent vieną sakinį galutiniame tekste, jis jau pasiekė savo tikslą. Komisija iš tiesų skaito šiuos įnašus - patirtis, įgyta pačiame ESPR procese, rodo, kad techniškai pagrįsti įnašai dažnai palieka pėdsakų galutiniuose tekstuose.
Mes bet kokiu atveju teiksime paraišką įtraukti mus į DPP paslaugų teikėjų sąrašą, kai tik bus paskelbta priėmimo procedūra. Taigi mums tiesiogiai svarbu, kad taisyklės, pagal kurias dalyvaujame, būtų tikslios ir užtikrintų lygias galimybes. Šios keturios pastabos yra mūsų konkretus būdas užtikrinti, kad sąrašas netaptų vien tik rinkodaros etikete.
Kas nori prisidėti
Atsiliepimų teikimo laikotarpis tęsiasi iki 2026 m. gegužės 27 d. Pasiūlymus galima teikti bet kuria ES oficialia kalba, tam reikia užsiregistruoti portale, o pasiūlymai bus viešai matomi. Visi, kurie išduos ar tikrins DPP - gamintojai, paslaugų teikėjai, perdirbėjai, valdžios institucijos - turėtų bent kartą susipažinti su šia iniciatyva svetainėje „Have Your Say“. Net trumpas, techniškai tikslus įnašas yra vertingas.
Mūsų patvirtinimo įrankis „Transpareo Time Machine“ , beje, jau dabar atitinka 2 punkte paminėtą patikrinimo poreikį atvirojo kodo praktikoje: kas nori nepriklausomai patikrinti „Transpareo-DPP“, gali tai padaryti jau šiandien, nelaukdamas oficialiai įsteigto patikrinimo taško Komisijos registre.