W3C Опубликовал Кандидатскую Рекомендацию уровня WebAuthn 3

Что произошло

13 января 2026 года W3C опубликовал снимок Кандидатской Рекомендации уровня 3 Веб-аутентификации (WebAuthn). Обновление консолидирует поведение паролей на нескольких устройствах, добавляет несколько новых клиентских API и вспомогательных функций сериализации, уточняет обработку аттестации/связанных источников и разъясняет взаимодействие iframe и Политики Разрешений. Документ сейчас находится на стадии Кандидатской Рекомендации, пока разработчики собирают тестовые данные для окончательного утверждения. (w3.org)

Почему это важно для полностековых команд

• Пароли и многоустройственные учетные данные больше не являются просто расширениями поставщиков — Уровень 3 формализует API и опции, которые делают синхронизированные пароли и регистрацию на нескольких устройствах первоклассными поведениями.
• Новые клиентские методы (например, getClientCapabilities(), вспомогательные функции десериализации JSON, такие как parseCreationOptionsFromJSON/parseRequestOptionsFromJSON(), и методы сигналов учетных данных) изменяют то, как приложения определяют поддержку, сериализуют опции и реагируют на сигналы аутентификаторов — с прямым влиянием на форматы полезных нагрузок сервер↔клиент и SDK.
• Правила аттестации и связанных источников имеют более четкие указания; стороны, принимающие аттестацию, должны проверять обновленные форматы аттестации и правила сертификатов, описанные в спецификации.
• Политика Разрешений, использование iframe и проверка связанных источников кросс-домена явно рассматриваются — это важно для команд, встраивающих аутентификационные потоки в фреймы или использующих кросс-доменные потоки входа для делегированного входа или SSO.
• Статус Кандидатской Рекомендации спецификации означает, что W3C ожидает тестирования реализации перед финализацией; браузеры и поставщики платформ будут использовать этот снимок для добавления поддержки функций или флагов.

Ключевые практические изменения (высокое влияние)

• Обнаружение возможностей клиента: стандартизированный API для запроса возможностей аутентификатора перед началом потоков регистрации/аутентификации (уменьшает эвристики обнаружения функций).
• JSON (де)сериализаторы: вспомогательные функции parse*, которые нормализуют, как серверы должны отправлять и получать опции WebAuthn (уменьшает различия в интероперабельности между библиотеками серверов и реализациями браузеров).
• Методы сигналов: новые способы для страниц отправлять контекстную информацию аутентификаторам (например, детали текущего пользователя, списки учетных данных), чтобы улучшить тихие/дискавери-потоки и уменьшить трение для пользователей.
• Уточнения аттестации: обновленные правила для упакованных/TPM/Android форматов аттестации и проверки сертификатов, которые серверные проверяющие должны реализовать, чтобы оставаться совместимыми и безопасными.
• iframe / связанные источники: явная обработка и схемы проверки для использования WebAuthn внутри iframe и между связанными источниками (критично для встроенных виджетов, потоков SSO и многопользовательских настроек).
• Интеграция Политики Разрешений: регистрирует, как встраиваемые страницы могут включать/выключать операции WebAuthn через заголовки политики.

Немедленные действия для инженерных команд

1. Прочитайте снимок Кандидатской Рекомендации и сопоставьте различия с вашим стеком (серверные библиотеки, клиентский код, сторонние SDK). (w3.org)
2. Проверьте библиотеки серверной проверки (библиотеки fido2 / webauthn): убедитесь, что они принимают форматы аттестации уровня 3 и ограничения сертификатов или подготовьтесь к обновлению, когда появятся патчи от поставщиков. Тестовое покрытие векторов имеет решающее значение.
3. Стандартизируйте интероперабельность JSON: примите рекомендованную спецификацией сериализацию для опций создания/запроса в ваших API-контрактах, чтобы избежать несоответствий между браузерами.
4. Добавьте проверки возможностей: используйте getClientCapabilities() (или плавное обнаружение функций), чтобы предоставить соответствующий UX (резидентные ключи, обнаруживаемые учетные данные, синхронизированные пароли).
5. Проверьте использование iframe и Политики Разрешений: если ваш продукт встраивает аутентификационные потоки, подтвердите разрешенные поведения и протестируйте потоки проверки связанных источников в современных браузерах.
6. Тестируйте на экспериментальных браузерах: поскольку это Кандидатская Рекомендация, ранняя поддержка браузеров может быть доступна только за флагами — проводите интеграционные тесты на этих сборках, чтобы выявить проблемы интероперабельности.
7. Координируйте продукт и безопасность: обновите модели угроз и планы развертывания, чтобы учесть синхронизированные пароли (разные соображения по восстановлению учетной записи и фишингу).

Рекомендуемый план развертывания (короткий)

• Неделя 0–2: инвентаризация использования WebAuthn (конечные точки, SDK, потоки iframe/встраивания), добавление автоматизированных тестов для текущего поведения.
• Неделя 2–6: запуск интеграционных тестов против сборок браузеров, открывающих функции уровня 3; обновление серверных библиотек или закрепление исправлений от поставщиков.
• Неделя 6–12: этап контролируемого развертывания (флаг функции) для UX, управляемого возможностями клиента; мониторинг ошибок и журналов проверки аттестации.
• Постоянно: подписка на обновления тестов W3C и примечания к выпускам браузеров — спецификация ожидает тестирования реализации перед финализацией (документ отмечает прогресс к Рекомендации после опыта реализации). (w3.org)

Итог

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

Источник

Веб-аутентификация: API для доступа к Учетным Записям Публичных Ключей — Уровень 3 (снимок Кандидатской Рекомендации W3C, 13 января 2026 года). (w3.org)

Источник

• Source