29 квітня 2026 року Європейська комісія опублікувала проект виконавчого регламенту щодо реєстру DPP та одночасно відкрила чотиритижневий період для подання відгуків. До 27 травня 2026 року кожна особа та кожна організація в ЄС та за його межами може надати свої коментарі через портал «Have Your Say». Коментарі є публічними, кожен з них підписаний ім’ям або назвою організації, і вони офіційно враховуються при підготовці остаточної редакції регламенту.
Ми детально обговорили цей проект тут, у блозі. Цю публікацію ми присвячуємо питанню, що саме ми відповіли Комісії.
Чому ми подали чотири окремі коментарі
Портал приймає до 4 000 символів на один коментар. Ми могли б вмістити всі пункти в один довгий коментар. Це було б незручніше для читання та складніше для цитування співробітникам Комісії, які у травні опрацьовуватимуть десятки коментарів. Чотири окремі коментарі можна легко знайти в публічному списку, і на кожен із них можна відповісти - або відхилити - окремо, не впливаючи на інші пункти.
Ми подали такі чотири теми:
1. Визначити мінімальні вимоги до постачальників послуг DPP
Проект регламенту правильно визначає децентралізовану модель: Дані DPP зберігаються у суб’єкта господарювання або у його постачальника послуг DPP, а реєстр Комісії зберігає лише посилання. Для постачальників послуг DPP (ст. 2, п. 32 ESPR) передбачено офіційний перелік затверджених постачальників.
Чого бракує, так це визначення того, що саме повинен робити постачальник послуг, щоб потрапити до цього переліку та залишатися в ньому. Імовірно, суттєві обов’язки будуть викладені в делегованому правовому акті відповідно до статті 4 основного регламенту ESPR. Однак реєстр почне діяти до опублікування цього правового акту.
Наша пропозиція: або безпосередньо в цьому виконавчому регламенті закріпити мінімальні критерії для постачальників послуг, або вказати обов’язковий термін, до якого має бути подано делегований правовий акт. До запропонованих мінімальних вимог належать:
- Доступність публічного інтерфейсу для читання DPP на рівні не менше 99,5 відсотка на місяць
- Угода про рівень обслуговування, що визначає, як швидко нова версія DPP має надійти до резервної копії (пропозиція: 24 години або в режимі реального часу, де це технічно можливо)
- Обов’язкова криптографічна верифікація вхідних версій з боку постачальника послуг
- Публікація відкритих ключів суб’єкта господарювання за стандартизованим шляхом (RFC 8615, пропозиція
/.well-known/dpp-keys/) - Чітко визначений процес переходу та банкрутства, щоб у разі виходу з ладу одного постачальника дані DPP упорядковано мігрували до іншого постачальника
Ці зобов’язання нічого не коштують серйозному постачальнику - він і так їх виконує - , але запобігають «гонці до дна» серед дешевих постачальників, яка в кінцевому підсумку підриває авторитет реєстру.
2. Можливість довгострокової верифікації зареєстрованих DPP
Стаття 9(4) обмежує термін дії підтвердження реєстрації 90 календарними днями. Протягом цього терміну реєстр за запитом відновлює підтвердження. Це цілком прийнятно для поточної діяльності, але не відповідає життєвому циклу пов’язаного з цим обов’язку щодо DPP: стаття 10(3) встановлює стандартний термін зберігання на 10 років з моменту реєстрації, а галузеве законодавство може вимагати довший термін.
Орган ринкового нагляду, митний службовець, переробник або дослідник у 2032 році повинен мати можливість перевірити, чи дійсно DPP, зареєстрований у 2026 році, був зареєстрований, не покладаючись на те, що початковий суб’єкт господарювання ще існує і може подати запит на отримання нового підтвердження.
Наші дві пропозиції є вигідними з точки зору реалізації:
- Чітко зазначити, що байти підтвердження, на які Комісія наклала кваліфіковану печатку, можуть тимчасово зберігатися, архівуватися та поширюватися суб’єктом господарювання або постачальником послуг. Кваліфікована печатка відповідно до статті 35(2) Регламенту eIDAS гарантує презумпцію цілісності та походження незалежно від того, де знаходяться ці байти.
- Створити публічну, неавтентифіковану точку перевірки в реєстрі, яка надає підписану відповідь на ідентифікатор реєстрації. Наразі будь-яка перевірка третьою стороною вимагає активних дій з боку суб’єкта господарювання - це неправильний підхід до документа-доказу, який має зберігатися довше, ніж існуватиме його видавець.
Крім того, ми запропонували детерміновано визначити формування хешу: SHA-256 як хеш-функцію, Схема канонізації JSON (RFC 8785) як серіалізацію, поза блоком підпису. В екосистемі W3C це криптосуїта eddsa-jcs-2022, за допомогою якої Transpareo безпосередньо підписує документи. Без такого визначення прив’язки два постачальники послуг серіалізували б один і той самий DPP у різні хеші, і поле хешу в підтвердженні реєстрації було б неможливо відтворити.
3. Стаття 17 не повинна обмежувати доступ до публічних даних DPP
Стаття 17 називає «масове завантаження даних» можливим зловживанням реєстром. Щодо адміністративних метаданих, які містяться в самому реєстрі (ідентифікатори, журнали, аудиторські сліди), це правильно - вони не підлягають масовому завантаженню.
Однак публічні дані DPP у виробника або постачальника послуг - це саме та сфера, до якої ESPR прагне забезпечити широкий доступ. Переробники, які збирають дані про склад парків продукції; науковці, які проводять перехресний аналіз заяв щодо сталого розвитку; органи ринкового нагляду, які проводять порівняльні аналізи, - це все форми «масового завантаження даних» з публічного шару DPP, і все це є цільовим використанням, для якого й було розроблено цей регламент.
Ми пропонуємо додати до статті 17 уточнювальне речення, яке обмежить сферу застосування даними реєстру, а щодо даних DPP - посилатиметься на відповідні делеговані правові акти для конкретних секторів. Інакше постачальники послуг на початку своєї діяльності опиняться перед вибором: або, задля безпеки, жорстко обмежити кількість запитів у публічному доступі - і тим самим зіпсувати споживчий досвід, - або залишити його відкритим і ризикнути, що пізніше це буде кваліфіковано як зловживання у розумінні статті 17.
4. Опублікувати специфікацію OpenAPI та пісочницю до запуску
Стаття 3(b) вимагає наявності API для реєстрації. Стаття 8(5) визначає його як один із двох каналів реєстрації. Однак у Регламенті нічого не сказано про те, коли має бути опубліковано угоду про API.
Тим, хто автоматизує робочі процеси реєстрації - кожному постачальнику послуг та кожному суб’єкту господарювання з великим каталогом - потрібна специфікація API значно раніше запуск, щоб її впровадити та протестувати на реальному кінцевому пункті. Отримання специфікації за тиждень до набрання чинності перекладає ризик інтеграції на всіх постачальників у екосистемі.
Тому ми запропонували:
- опублікувати специфікацію OpenAPI 3.1 щонайменше за вісім тижнів до набрання чинності - тобто для запуску 19 липня 2026 року - до 24 травня 2026 року
- Паралельно створити тестове середовище (sandbox), у якому постачальники послуг та виробники зможуть інтегруватися та протестувати автоматичну верифікацію відповідно до статті 8(6)
- Впровадити політику версійності за стандартом Semver із терміном попередження про припинення підтримки щонайменше 18 місяців
Додаткові пропозиції щодо проектування: ключі ідемпотентності для викликів реєстрації, пакетна реєстрація для великих каталогів, асинхронна реєстрація з зворотним викликом через веб-хук та машиночитані коди помилок для випадків помилок під час автоматичної верифікації.
Чому ми це робимо
Консультація - це не гра, де потрібно набирати бали. Якщо кожна пропозиція допомагає зробити хоча б одне речення в остаточній редакції точнішим, вона виконала своє призначення. Комісія дійсно читає ці пропозиції - досвід самого процесу ESPR показує, що технічно обґрунтовані пропозиції часто знаходять відображення в остаточних текстах.
Ми все одно подамо заявку на включення до переліку постачальників послуг DPP, щойно буде опубліковано процедуру прийому. Отже, у наших безпосередніх інтересах, щоб правила, за якими ми беремо участь, були чіткими та визначали рівні умови для всіх. Ці чотири коментарі - це наш конкретний внесок у те, щоб перелік не перетворився на суто маркетинговий ярлик.
Хто хоче долучитися
Період збору відгуків триватиме до 27 травня 2026 року. Коментарі можна залишати будь-якою офіційною мовою ЄС, для цього потрібно зареєструватися на порталі, і вони стануть загальнодоступними. Тим, хто видаватиме або перевірятиме DPP - виробникам, постачальникам послуг, підприємствам з переробки, державним органам - слід хоча б раз ознайомитися з ініціативою на сайті Have Your Say. Навіть короткий, технічно точний коментар має значення.
Наш інструмент верифікації Transpareo Time Machine , до речі, вже вирішує проблему верифікації, про яку йшлося у пункті 2, у практиці відкритого коду: хто хоче незалежно перевірити Transpareo-DPP, може зробити це за допомогою цього інструменту вже сьогодні, не чекаючи на офіційно затверджену точку верифікації в реєстрі Європейської комісії.