Кратко

  • remoteClientDataJSON по умолчанию недоступно и требует разрешения для каждого источника. Такое разрешение открывает локальную возможность, но не доказывает правильность удалённой проверки источника и RP ID.
  • Внедрению нужна межклиентская квитанция, связанная с удалённой сессией, версией политики и хешем точных данных, а не повтор всей удалённой логики в локальном браузере.

В First Public Working Draft документа Web Authentication Level 4 от 15 сентября 2026 года важнейшее изменение касается не нового криптографического примитива, а переноса ответственности за проверку.

В обычной модели WebAuthn браузер получает источник вызывающей страницы из собственного контекста исполнения. RP ID, как правило, должен совпадать с эффективным доменом источника либо быть его регистрируемым доменным суффиксом; для связанных источников действует отдельная процедура. Браузер формирует clientDataJSON, аутентификатор подписывает хеш этих байтов, после чего relying party проверяет тип церемонии, challenge, ожидаемый источник и хеш RP ID.

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

Расширение remoteClientDataJSON позволяет авторизованному клиенту передать полную строку, подготовленную удалённым хостом. Локальный браузер разбирает JSON, но не должен ничего добавлять, удалять или изменять. При сериализации он использует полученную строку, чтобы аутентификатор подписал именно те байты, которых ожидает удалённая машина.

Проект не превращает это в общий обход ограничений. publickey-credentials-remote-client-data-json определено одновременно как powerful feature и как функция под управлением Permissions Policy. Состояние разрешения по умолчанию — denied, указанная default allowlist — 'none'. Настройка должна быть привязана к источнику; возможность разрешить все источники запрещена. Текст предлагает управляемую политику браузера или устройства либо явный выбор конкретного источника в настройках клиента, а не случайный запрос во время церемонии.

Этот барьер отвечает на локальный вопрос: может ли данный источник вызвать расширение? Он не отвечает на удалённый вопрос: точно ли клиент указал источник RP и правильно ли применил правило, связывающее этот источник с RP ID?

Алгоритм проводит границу явно. Если разрешение не равно granted, локальный браузер отклоняет операцию. RP ID необходимо передать явно, а полученный JSON должен быть разобран. Затем, однако, браузер пропускает обычную проверку отношения между RP ID и значением origin внутри удалённых данных. Проект прямо говорит, что все связанные с RP ID проверки источника делегируются удалённому клиенту. Раздел о безопасности добавляет: user agent, выдавший разрешение, должен доверять вызывающей стороне в точности удалённого источника и доверять удалённому клиенту в честности и правильности проверки RP ID.

Булев результат расширения имеет узкий смысл. true означает только, что расширение было применено. В нём нет идентификатора удалённой сессии, версии политики, алгоритма, результата или доказательств для связанных источников. Побайтовая сохранность также доказывает лишь отсутствие пересборки данных локальным браузером. Она не подтверждает, что записанное внутри утверждение об источнике правдиво, актуально и разрешено.

Подпись аутентификатора связывает результат с хешем клиентских данных и данными аутентификатора. RP по-прежнему обязан проверить тип, challenge и источник, а также сопоставить rpIdHash с ожидаемым RP ID. Это необходимые меры. Но они не обязательно сохраняют сведения о том, какой удалённый клиент принял делегированное решение, какая версия политики действовала и какой аутентифицированный канал связывал удалённую сессию с локальной операцией.

Это не сообщение об уязвимости, эксплуатации или инциденте. Level 4 пока является первым публичным рабочим проектом, а не W3C Recommendation и не доказательством реализации, совместимости или промышленного внедрения. Раздел о статусе говорит, что публикация не означает одобрения W3C и её участников, а документ может быть обновлён, заменён или признан устаревшим. Открытый issue 2430 в репозитории W3C WebAuthn отслеживает терминологическую зависимость: намерение запретить функцию по умолчанию ясно, однако 'none' ещё не было нормативно определено как значение default allowlist в зависимом проекте Permissions Policy. Изменение поведения в issue не запрашивается.

Поэтому правильный ответ управления — не отменить делегирование. Удалённая сторона может располагать контекстом, которого нет у локального браузера: документом связанных источников или платформенными связями с приложением. Если заставить локальную сторону повторить всю проверку, появятся два валидатора, способные незаметно разойтись.

Более узкая мера — квитанция проверки источника между клиентами. Она должна связать локальный вызывающий источник и разрешение — субъект, источник выдачи, версию и срок — с удалённой сессией и аутентифицированным каналом. В ней нужны удалённый источник, RP ID, алгоритм и версия, результат и ссылки на доказательства связанных источников или привязки приложения. Хеш точных байтов remoteClientDataJSON соединит решение с подписанными данными, а результат проверки на сервере RP замкнёт цепочку. Исключения, отзыв и исправления должны дополнять историю, а не стирать исходное решение.

Такая квитанция — предложение по эксплуатационному контролю, а не требование WebAuthn. Она сохраняет различие между пятью фактами: локальная возможность разрешена, удалённая проверка выполнена, байты сохранены, пользователь взаимодействовал с аутентификатором, RP принял или отклонил результат. Один зелёный статус WebAuthn не доказывает их одновременно.

Источники