Кратко

  • 25 августа 2026 года W3C опубликовал Web Authentication Level 3 как Рекомендацию и связал её с фиксированным отчётом о реализациях по состоянию на 26 июня.
  • Отчёт заявляет 53 теста и 415 подтестов для конкретных сборок Chrome, Firefox, Safari Preview и Edge; для каждой указаны среда, дата и один и тот же commit WPT.
  • Финальная запись сообщает лишь, что часть Chrome отличается от Edge. Для проверяемости нужен ключ по функциям: слой реализации, основание независимости, наблюдаемый результат и роль доказательства в решении.

Что именно доказывают четыре столбца

Документ Web Authentication: An API for accessing Public Key Credentials — Level 3 определяет интерфейс, через который веб-приложения создают и используют ограниченные конкретной relying party учётные данные с открытым ключом. Доступ опосредуют пользовательский агент и аутентификатор. Версия от 25 августа имеет статус W3C Recommendation, рекомендует широкое внедрение и сообщает, что после Candidate Recommendation Snapshot от 26 мая существенных изменений не было.

В шапке документа приведён фиксированный Implementation Report. Страница называет себя снимком web-platform-tests на 26 июня, предупреждает, что не обновляется, и отправляет за текущими результатами к живому сервису. В каталоге /webauthn/ она насчитывает 53 теста и 415 подтестов.

Контекст запусков записан подробно. Chrome 151 и Firefox 154 alpha выполнялись 25 июня в Linux. Safari 246 Preview был запущен на следующий день в macOS, Edge 151 — в Windows. Все четыре записи ссылаются на WPT commit d41367df1e. Матрица сохраняет состояния PASS, FAIL, TIMEOUT, ERROR, NOTRUN и отсутствие результата.

Эти данные хорошо отвечают на вопрос: какое поведение показала данная сборка продукта в данной среде на данной редакции тестов? Однако W3C Process задаёт и другой вопрос: имеются ли независимые совместимые реализации спецификации? Название продукта устанавливает место наблюдения, но само по себе не раскрывает происхождение компонента, который обеспечил функцию.

Было бы грубо считать четыре торговых названия четырьмя независимыми реализациями. Столь же грубо заранее объявить Chrome и Edge одной реализацией для всех функций. Браузерный продукт может соединять движок, службы операционной системы, платформенный аутентификатор и собственные компоненты поставщика. Для одной функции существенный путь может совпадать, для другой — расходиться. Независимость требует указания функции и слоя.

Рабочая группа обсуждала слои, а итог оставил «часть»

В финальном issue о переходе под заголовком «Implementation» стоят ссылки на живые результаты WPT и зафиксированный снимок. Следующей строкой говорится, что часть реализации в Chrome отличается от реализации в Edge.

Оговорка полезна: она не позволяет автоматически слить два столбца из-за общих оснований продуктов. Но слово «часть» не называет ни функцию, ни группу тестов, ни границу компонента. Запись также не ссылается на источник такого вывода и не сообщает, использовалась ли конкретная пара результатов Chrome и Edge как доказательство независимости для определённого положения перехода.

Протокол заседания Рабочей группы от 18 марта хранит более точный контекст. В теме «Testing» зафиксировано, что у Edge есть некоторые технические отличия от «обычного Chrome». Затем участники спрашивают, работает ли Microsoft Authenticator через Android или iOS, и применительно к одному расширению называют эти пути двумя реализациями на уровне WebAuthn. Позже протокол отмечает консенсус без возражений: запросить Recommendation после решения оставшихся вопросов.

Следовательно, утверждать, что группа не думала о независимости, нельзя. Она обсуждала конкретные слои. Потеря происходит при сжатии рассуждения в публичную итоговую квитанцию: расширение и уровень исчезают, остаётся неразмеченная «часть». Матрица результатов и утверждение о происхождении открыты, но ключа между ними нет.

Решение при этом завершено. В issue записаны одобрение Team 17 июля, окончание рассмотрения Advisory Committee 18 августа с консенсусом и без Formal Objections, разрешение на публикацию 19 августа и адрес Рекомендации 25 августа. Недостаточная детализация публичного поля не отменяет эти действия и не доказывает отсутствия дополнительных материалов у W3C.

Process не предлагает считать браузеры

Раздел 6.3.2 W3C Process намеренно не задаёт универсальной формулы. Опыт реализации должен показывать, что спецификация достаточно ясна, полна и востребована, чтобы независимые совместимые реализации каждой функции могли появиться. Team может учитывать реализацию каждой функции, независимость и совместимость, участие людей помимо авторов текста, публичное развёртывание, опыт на разных уровнях экосистемы и сообщения о трудностях.

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

Смешанные исходы нельзя превращать и в рейтинг безопасности. FAIL может означать отсутствие поддержки, иное решение либо необходимость проверить ожидание теста. TIMEOUT и пустая ячейка говорят ещё меньше. Переход в Recommendation не требует, чтобы каждая ячейка каждого продукта стала зелёной; эта статья не создаёт такого барьера.

Функциональный ключ без раскрытия исходного кода

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

В той же строке хранится наблюдение о совместимости и указание, применялось ли оно при переходе. Если Chrome и Edge используют разные пути для определённого расширения, вывод привязывается только к нему. Если для другой функции существенный путь общий, два продуктовых столбца не становятся молча двумя независимыми реализациями. Тот же функциональный подход нужен для Firefox, Safari, Android, iOS, аутентификаторов и ПО relying parties.

Это не аудит исходного кода и не новый орган одобрения. W3C Team сохраняет контекстную оценку, которую ему доверяет Process. Ключ лишь разделяет три положения: где выполнялся тест, какое поведение наблюдалось и почему реализация считается независимой для названной цели.

Lu Heng в Minimum Initial Specification отделяет рекомендацию как координационный артефакт от реализации, проверки, развёртывания и принятия. Та же сдержанность нужна уровнем раньше: название браузера доказывает, какой продукт тестировали, но не удостоверяет всю реализацию под ним.

Источники