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, может сделать это с помощью этого инструмента уже сегодня, не дожидаясь официально утверждённого конечного пункта верификации в реестре Комиссии.