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