W dniu 29 kwietnia 2026 r. Komisja Europejska opublikowała projekt rozporządzenia wykonawczego w sprawie rejestru DPP oraz jednocześnie ogłosiła czterotygodniowy okres na zgłaszanie uwag. Do 27 maja 2026 r. każda osoba i każda organizacja w UE oraz poza nią może zgłaszać uwagi za pośrednictwem portalu „Have Your Say”. Uwagi są jawne, każda z nich jest podpisana imieniem i nazwiskiem lub nazwą organizacji, a ich treść zostanie oficjalnie uwzględniona w ostatecznej wersji rozporządzenia.
Szczegółowo omówiliśmy ten projekt na naszym blogu. Niniejszy wpis poświęcamy kwestii tego, co przekazaliśmy Komisji w naszych ## uwagach.
Dlaczego złożyliśmy cztery oddzielne uwagi
Portal akceptuje 4 000 znaków na jedną uwagę. Moglibyśmy zmieścić wszystkie punkty w jednym długim wpisie. Byłoby to jednak mniej wygodne w czytaniu i trudniejsze do cytowania dla pracowników Komisji, którzy w maju będą przeglądać dziesiątki zgłoszeń. Cztery oddzielne zgłoszenia są łatwe do odnalezienia na publicznej liście, a na każde z nich można odpowiedzieć - lub je odrzucić - osobno, bez wpływu na pozostałe kwestie.
Zgłosiliśmy następujące cztery tematy:
1. Określenie minimalnych wymagań dla dostawców usług DPP
Projekt rozporządzenia prawidłowo definiuje model zdecentralizowany: Dane DPP są przechowywane u podmiotu gospodarczego lub u jego dostawcy usług DPP, a rejestr Komisji przechowuje jedynie odniesienia. W odniesieniu do dostawców usług DPP (art. 2 pkt 32 rozporządzenia ESPR) przewidziano oficjalny wykaz zatwierdzonych dostawców.
Brakuje jednak określenia, jakie obowiązki musi faktycznie spełniać dostawca usług, aby znaleźć się na tej liście i pozostać na niej. Przypuszczalnie istotne obowiązki zostaną określone w akcie delegowanym zgodnie z art. 4 rozporządzenia macierzystego ESPR. Rejestr zostanie jednak uruchomiony przed opublikowaniem tego aktu.
Nasza propozycja: albo bezpośrednio w niniejszym rozporządzeniu wykonawczym należy określić minimalne kryteria dla dostawców usług, albo podać wiążący termin, w którym akt delegowany zostanie przedłożony. Do proponowanych minimalnych wymagań należą:
- dostępność publicznego interfejsu odczytu DPP na poziomie co najmniej 99,5 procent miesięcznie
- umowa o gwarantowanym poziomie usług określająca, jak szybko nowa wersja DPP musi trafić do kopii zapasowej (propozycja: 24 godziny lub w czasie rzeczywistym, o ile jest to technicznie możliwe)
- Obowiązkowa weryfikacja kryptograficzna przychodzących wersji przez dostawcę usług
- Publikacja kluczy publicznych podmiotu gospodarczego w standardowej ścieżce (RFC 8615, propozycja
/.well-known/dpp-keys/) - Określony proces zmiany dostawcy i postępowania upadłościowego, aby dane DPP mogły zostać w uporządkowany sposób przeniesione do innego dostawcy w przypadku upadłości dotychczasowego dostawcy
Obowiązki te nie wiążą się z żadnymi kosztami dla rzetelnego dostawcy - i tak je spełnia - zapobiegają jednak wyścigowi w dół wśród tanich dostawców, który ostatecznie podważa wiarygodność rejestru.
2. Długoterminowa weryfikowalność zarejestrowanych DPP
Artykuł 9 ust. 4 ogranicza dostępność potwierdzenia rejestracji do 90 dni kalendarzowych. W tym terminie rejestr ponownie generuje potwierdzenie na żądanie. Jest to odpowiednie rozwiązanie dla bieżącej działalności, ale nie pasuje do cyklu życia związanego z obowiązkiem dotyczącym DPP: art. 10 ust. 3 ustala standardowy okres przechowywania na 10 lat od daty rejestracji, przy czym przepisy sektorowe mogą wymagać dłuższego okresu.
Organ nadzoru rynku, urzędnik celny, podmiot zajmujący się recyklingiem lub badacz w 2032 r. powinien mieć możliwość sprawdzenia, czy DPP zarejestrowany w 2026 r. rzeczywiście był zarejestrowany, bez konieczności polegania na tym, że pierwotny podmiot gospodarczy nadal istnieje i może wystąpić o nowe potwierdzenie.
Nasze dwie propozycje są łatwe do wdrożenia:
- Wyraźnie wyjaśnić, że bajty dowodowe opatrzone kwalifikowaną pieczęcią Komisji mogą być tymczasowo przechowywane, archiwizowane i dalej rozpowszechniane przez podmiot gospodarczy lub dostawcę usług. Kwalifikowany podpis zgodnie z art. 35 ust. 2 rozporządzenia eIDAS zapewnia domniemanie integralności i pochodzenia niezależnie od tego, gdzie znajdują się te bajty.
- Utworzenie publicznego, nieautoryzowanego punktu końcowego weryfikacji w rejestrze, który dostarcza podpisaną odpowiedź na podstawie identyfikatora rejestracyjnego. Obecnie każda weryfikacja przez stronę trzecią wymaga aktywnego działania podmiotu gospodarczego - jest to niewłaściwa forma dla dokumentu dowodowego, który musi przetrwać wydawcę.
Ponadto zaproponowaliśmy deterministyczne określenie generowania skrótu: SHA-256 jako funkcję skrótu, schemat kanonizacji JSON (RFC 8785) jako serializację, poza blokiem podpisu. W ekosystemie W3C jest to zestaw kryptograficzny eddsa-jcs-2022, za pomocą którego Transpareo bezpośrednio podpisuje dokumenty. Bez tego określenia przypisania dwóch dostawców usług serializowałoby ten sam DPP do różnych skrótów, a pole skrótu w potwierdzeniu rejestracji nie byłoby możliwe do odtworzenia.
3. Artykuł 17 nie może ograniczać dostępu do publicznych danych DPP
Artykuł 17 wymienia „masowe pobieranie danych” jako potencjalne nadużycie rejestru. W odniesieniu do metadanych administracyjnych znajdujących się w samym rejestrze (tożsamości, logi, ślady audytowe) jest to słuszne - nie powinny one być przedmiotem masowego pobierania.
Jednak publiczne dane DPP u producenta lub dostawcy usług stanowią właśnie ten obszar, do którego ESPR chce zapewnić szeroki dostęp. Firmy zajmujące się recyklingiem, które pozyskują dane kompozycyjne dotyczące flot produktów; badania naukowe, w ramach których przeprowadza się przekrojową analizę oświadczeń dotyczących zrównoważonego rozwoju; organy nadzoru rynku, które przeprowadzają analizy porównawcze - to wszystko są formy „masowego pobierania danych” z publicznej warstwy DPP i wszystkie są to celowe zastosowania, dla których rozporządzenie zostało opracowane.
Proponujemy dodanie zdania wyjaśniającego w art. 17, które ograniczy zakres stosowania do danych rejestrowych, a w odniesieniu do danych DPP odsyła do odpowiednich sektorowych aktów delegowanych. W przeciwnym razie dostawcy usług staną przed wyborem na początku działalności: albo dla bezpieczeństwa agresywnie ograniczyć limit żądań w dostępie publicznym - i zepsuć doświadczenia konsumentów - albo pozostawić go otwartym i ryzykować, że później zostanie to zakwalifikowane jako nadużycie w rozumieniu art. 17.
4. Opublikowanie specyfikacji OpenAPI i środowiska testowego przed uruchomieniem
Artykuł 3 lit. b) wymaga udostępnienia interfejsu API do rejestracji. Artykuł 8 ust. 5 określa go jako jeden z dwóch kanałów rejestracji. Rozporządzenie nie zawiera jednak żadnych wskazówek dotyczących terminu opublikowania specyfikacji API.
Każdy, kto automatyzuje procesy rejestracji - każdy dostawca usług i każdy podmiot gospodarczy dysponujący większym katalogiem - potrzebuje specyfikacji API na długo przed uruchomieniem, aby ją wdrożyć i przetestować na prawdziwym punkcie końcowym. Udostępnienie specyfikacji w tygodniu poprzedzającym wejście w życie przenosi ryzyko związane z integracją na wszystkich dostawców w ekosystemie.
W związku z tym zaproponowaliśmy:
- Opublikowanie specyfikacji OpenAPI 3.1 co najmniej osiem tygodni przed wejściem w życie - w przypadku terminu rozpoczęcia 19 lipca 2026 r. oznacza to termin do 24 maja 2026 r.
- równoległe udostępnienie środowiska testowego (sandbox), w którym dostawcy usług i producenci będą mogli przeprowadzać integrację oraz testować automatyczną weryfikację zgodnie z art. 8 ust. 6
- politykę wersjonowania zgodną z Semver, z co najmniej 18-miesięcznym okresem wypowiedzenia
Dodatkowe sugestie projektowe: klucze idempotencji w wywołaniach rejestracji, rejestracja zbiorcza dla dużych katalogów, rejestracja asynchroniczna z wywołaniem zwrotnym webhook oraz kodami błędów nadających się do odczytu maszynowego w przypadku niepowodzeń automatycznej weryfikacji.
Dlaczego to robimy
Konsultacje nie są grą polegającą na zbieraniu punktów. Jeśli każda uwaga przyczyni się do doprecyzowania choćby jednego zdania w ostatecznej wersji, spełniła swój cel. Komisja faktycznie zapoznaje się z tymi zgłoszeniami - doświadczenia z samego procesu ESPR pokazują, że zgłoszenia oparte na wiedzy technicznej często znajdują odzwierciedlenie w ostatecznych tekstach.
I tak zamierzamy ubiegać się o wpisanie na listę dostawców usług DPP, gdy tylko procedura rekrutacyjna zostanie opublikowana. Leży więc w naszym bezpośrednim interesie, aby zasady, na podstawie których startujemy, były precyzyjne i określały równe warunki konkurencji. Te cztery uwagi są naszym konkretnym wkładem w zapewnienie, że lista nie stanie się jedynie marketingową etykietką.
Kto chce wziąć udział
Okres zgłaszania uwag trwa do 27 maja 2026 r. Uwagi można zgłaszać w każdym języku urzędowym UE; wymagają one rejestracji na portalu i zostaną opublikowane. Każdy, kto będzie wydawał lub weryfikował paszporty produktów cyfrowych (DPP) - producenci, dostawcy usług, podmioty zajmujące się recyklingiem, organy administracji - powinien przynajmniej raz zapoznać się z inicjatywą na stronie Have Your Say. Nawet krótka, merytorycznie precyzyjna wypowiedź ma znaczenie.
Nasze narzędzie do weryfikacji Transpareo Time Machine rozwiązuje zresztą potrzebę weryfikacji, o której mowa w punkcie 2, już w praktyce opartej na otwartym kodzie źródłowym: każdy, kto chce niezależnie zweryfikować paszport produktu cyfrowego Transpareo, może to zrobić już dziś za pomocą tego narzędzia, bez konieczności oczekiwania na formalnie ustanowiony punkt końcowy weryfikacji w rejestrze Komisji.