Кратко

  • Проект устава Web Authentication Working Group включает подписание произвольных данных при посредничестве WebAuthn; ключ подписи должен быть связан с учётными данными, но отделён от ключа аутентификации.
  • В качестве примеров названы агентный ИИ и проверяемые цифровые удостоверения, тогда как низкоуровневый доступ к закрытым ключам и самостоятельные универсальные криптографические API по-прежнему исключены.
  • Область работ не означает зрелость: обсуждение устава продолжается, у Level 4 нет FPWD, pull request sign имеет статус Draft, а explainer не содержит ни пользовательских исследований, ни сигналов Chrome, Firefox, Safari или Edge.
  • Для функции нужен публичный реестр допуска, связывающий полномочие устава с точной версией предложения, границами ключа, сообщения и согласия, рецензированием, тестами, независимыми реализациями, статусом Recommendation и фактическим внедрением.

Устав разрешает вести работу, но не выбирает её результат

Действующий устав Web Authentication Working Group сосредоточен на понятной задаче: сильной аутентификации веб-приложений. В него входят привязанные к origin пары ключей, подтверждение владения, восстановление, резервное копирование и близкие улучшения. Низкоуровневый доступ к криптографическим операциям и материалу ключей исключён. Сайт может запустить церемонию аутентификации, но не получает закрытый ключ аутентификатора.

Новый проект сдвигает эту границу. Пункт 11 допускает работу над подписанием данных за пределами стандартной структуры WebAuthn-аутентификации. Операция остаётся опосредованной WebAuthn, а ключ подписи связан с credential, но отличен от его ключа аутентификации. Текст упоминает агентный ИИ и экосистемы проверяемых цифровых удостоверений. Ещё два новых пункта посвящены сигналам доверия от менеджеров учётных данных и конфиденциальности расширений.

Выбор площадки имеет последствия. Веб-API, способный выдавать обычные подписи, совместимые с другими криптографическими протоколами, нужен не только для входа. Кошельки, токены авторизации, подписи выпусков ПО и другие приложения смогут обращаться к защищённому аппаратурой ключу, не передавая секрет JavaScript-коду.

Однако нынешнее институциональное действие значительно уже. W3C открыл рассмотрение 10 августа; комментарии принимаются до 23:59 UTC 7 сентября, а действующий устав продлён до 30 октября. На дату этой статьи новый устав не принят. Даже положительное решение будет означать лишь право группы разрабатывать такой класс функций. Оно не выбирает API из текущего pull request, не закрывает риски и не обязывает браузеры что-либо внедрять.

Сам проект устава сохраняет дистанцию. Web Authentication Level 4 указан как будущий нормативный результат, но его First Public Working Draft ещё не опубликован, а ожидаемый срок завершения — четвёртый квартал 2028 года. Включить вопрос в рабочую комнату и доставить совместимый код на устройства пользователей — разные события.

Подпись подтверждает работу ключа, а не понимание смысла

Обычная WebAuthn assertion уже использует подпись, но не подписывает challenge relying party в исходном виде. Аутентификатор подписывает определённую конструкцию из собственных данных и хеша клиентских данных. Предложение raw signing намеренно иное: результатом должна быть подпись непосредственно над неизменённым входом приложения.

В этой универсальности и состоит преимущество. Существующий проверяющий компонент может понимать обычную криптографическую подпись и не уметь разбирать оболочку WebAuthn assertion. Стандартная подпись заданного сообщения позволяет веб-приложению участвовать в уже работающих протоколах, оставляя закрытый ключ внутри защищённого устройства.

Проект одновременно пытается перенести сильные ограничения WebAuthn. Ключ подписи должен быть отдельным и криптографически не связанным с родительским credential key, чтобы вредоносная relying party не изготовила через новый механизм допустимую аутентификационную assertion. Привязка к origin должна помешать превращению ключа в межсайтовый идентификатор. Минимальные требования user presence и user verification фиксируются при создании ключа. Веб-уровень не должен обеспечивать автономное подписание без участия человека, хотя нижний протокол между клиентом и аутентификатором может обслуживать нативные приложения с другой моделью.

Это содержательные гарантии. Ни одна из них не доказывает, что человек понял подписываемые данные.

Explainer прямо относит подтверждение транзакции к нецелям. Он допускает непрозрачные двоичные данные и не требует доверенного интерфейса, который покажет их смысл перед подписью. Успешная церемония может доказать, что конкретный ключ сработал при заданной политике присутствия или проверки. Сама по себе она не доказывает, что человек прочитал документ, понял платёж, одобрил конкретное действие автономного агента или согласился с юридическим значением, которое организация позже придаст подписи.

Эта граница не навязана внешними критиками — она опубликована самим предложением. «Пользователь проверен» описывает церемонию. «Пользователь понял эту нагрузку» — другое утверждение. «Пользователь уполномочил агента выбрать эту нагрузку» — третье. Если продукт объединяет их, он приписывает протоколу полномочие, которого тот не подтверждает.

Открытая доказательная база пока соответствует инкубации

Explainer сообщает, что пользовательские исследования не проводились. В таблице заинтересованных сторон нет сигналов от Chrome, Firefox, Safari и Edge. Положительно отмечены один разработчик аутентификатора и один разработчик relying party. Отсутствие сигнала не означает отказ, но и не является молчаливой поддержкой. Это неустановленная позиция.

Расширение sign остаётся Draft в pull request 2078 и привязано к milestone первого публичного проекта Level 4. В сентябре 2024 года автор упомянул грубые внутренние proof-of-concept-компоненты и отсутствие на тот момент обязательств от других участников рабочей группы. Дальнейшие обсуждения и эксперименты показывают движение. В изученной открытой записи они не заменяют отчёт о двух независимых совместимых реализациях.

W3C Process задаёт последовательность, которую нельзя сокращать риторикой. Существенное расширение области требует рассмотрения Advisory Committee и W3C Decision. FPWD начинает публичную работу по стандарту и имеет патентные последствия. Горизонтальные проверки изучают доступность, интернационализацию, приватность и безопасность. Candidate Recommendation собирает финальные отзывы и опыт реализации. Для Recommendation нужны дополнительные доказательства и решение. После этого разработчики браузеров, аутентификаторов и relying parties всё ещё решают, что внедрять.

Каждое состояние отвечает на отдельный вопрос. Устав: может ли группа заниматься темой? Проект: есть ли конкретный дизайн? FPWD: началась ли публичная стандартизация? Горизонтальная проверка: исследованы ли сквозные риски? Открытые тесты: можно ли одинаково проверить заявления? Независимые реализации: работает ли функция за пределами одного стека? Recommendation: одобрил ли процесс W3C спецификацию? Внедрение: приняли ли её действующие системы?

Аргумент Heng Lu о приоритете работающего кода полезен именно на этой узкой границе. Публикация может организовать будущую работу, но не делает изменение операционной реальностью до реализации, проверки и принятия. W3C — не RIR, а веб-стандарт — не реестр номерных ресурсов. Переносима только дисциплина: статус документа, техническое свидетельство и практическое использование не должны подменять друг друга.

Для одной функции нужен один сквозной реестр допуска

В проекте устава уже есть общие критерии успеха группы. Но raw signing нужен также реестр на уровне функции, поскольку его обещание складывается из утверждений, распределённых по документам, тестам и реализациям.

Реестр должен начинаться с точного пункта устава и его статуса, затем указывать версии explainer и текста спецификации. В нём следует записать, подписывается ли полный вход, предварительный хеш или иная оболочка, какой идентификатор алгоритма и правило domain separation применяются. Далее нужны связь родительского credential с ключом подписи, origin-граница, неизменяемая политика присутствия и проверки, фактическое содержимое экрана пользователя.

К ним должны быть привязаны смысл attestation, анализ linkability и fingerprinting, сигналы браузеров, аутентификаторов и relying parties, вопросы горизонтальных проверок и решения, покрытие открытыми тестами, независимые реализации, нерешённые возражения и текущая стадия зрелости.

Закрытым ключам, идентификаторам устройств, персональным тестовым данным и пригодным для атаки подробностям в таком реестре не место. Это и не новый комитет с дополнительным правом вето. Реестр лишь соединяет с версиями и датами публичные материалы, которые уже должен создавать существующий процесс.

Главное свойство — исправимость. Изменится устав — обновится первая строка. Если подтверждение транзакции позже станет целью, исходное ограничение останется видимым. Если браузер затем выступит против, старое «нет сигнала» не будет переписано как давняя оппозиция. Если тест выявит смешение протоколов, результат сохранится вместе с исправлением. Если функция будет снята, появится читаемое конечное состояние, а не вечная цитата из старого устава, похожая на разрешение продукта.

Источники

  1. W3C: приглашение рассмотреть проект устава Web Authentication
  2. Проект устава Web Authentication Working Group
  3. Действующий устав Web Authentication Working Group
  4. Web Authentication Level 3 Recommendation
  5. Explainer расширения raw signing
  6. Draft pull request sign 2078
  7. W3C Process Document от 18 августа 2025 года
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption