Resumo

  • O W3C publicou Web Authentication Level 3 como Recomendação em 25 de agosto de 2026, com um relatório de implementação congelado em 26 de junho.
  • A página declara 53 testes e 415 subtestes em versões identificadas de Chrome, Firefox, Safari Preview e Edge, todas associadas ao mesmo commit do WPT.
  • O registro final informa apenas que parte do Chrome difere do Edge. Uma chave por recurso deveria registrar a camada, a justificativa de independência, a evidência e o uso daquela conclusão na transição.

Um bom registro do ensaio, não da linhagem

Web Authentication: An API for accessing Public Key Credentials — Level 3 descreve como aplicações web criam e usam credenciais de chave pública restritas a uma parte confiável, mediadas por agentes de usuário e autenticadores. A versão datada de 25 de agosto é uma Recomendação, incentiva ampla implantação e afirma que não houve mudanças substanciais desde o Candidate Recommendation Snapshot de 26 de maio.

O cabeçalho traz um relatório de implementação fixo. A página se identifica como snapshot de 26 de junho, avisa que não é mantida e remete ao serviço ao vivo para resultados atuais. Ela contabiliza 53 testes e 415 subtestes no diretório /webauthn/.

As condições de execução são detalhadas. Chrome 151 e Firefox 154 alpha rodaram no Linux em 25 de junho. Safari 246 Preview rodou no macOS e Edge 151 no Windows em 26 de junho. Todos apontam para o commit WPT d41367df1e. A matriz mantém resultados PASS, FAIL, TIMEOUT, ERROR, NOTRUN e ausentes.

Esse desenho responde muito bem a uma pergunta: o que determinada compilação observou, neste ambiente, contra esta revisão dos testes? Mas a experiência de implementação exigida pelo Processo também envolve outra pergunta: há implementações independentes e interoperáveis do recurso? Um rótulo de produto não fornece, sozinho, a genealogia do componente que executou a função.

Não basta somar quatro marcas. Tampouco é correto declarar Chrome e Edge uma única implementação em todos os casos. Um navegador pode reunir motor, serviços do sistema operacional, autenticador de plataforma e componentes próprios. A mesma dupla pode compartilhar o caminho relevante para um recurso e usar caminhos diferentes em outro. Independência precisa de escopo técnico.

O grupo fez a pergunta; o recibo perdeu a granularidade

O issue final de transição liga os resultados WPT ao vivo e o snapshot fixo sob “Implementation”. Em seguida, registra que parte da implementação no Chrome é diferente da do Edge.

A ressalva impede apagar toda diferença entre os produtos. Porém, “parte” não nomeia recurso, grupo de testes, limite de componente nem fonte da conclusão. Também não explica se algum par Chrome-Edge foi usado como evidência de independência para uma proposição específica da passagem a Recomendação.

A ata de 18 de março mostra um debate mais concreto. No tópico “Testing”, um participante registra diferenças técnicas no Edge em relação ao “Chrome normal”. A conversa pergunta se o Microsoft Authenticator opera por Android ou iOS e, para uma extensão, descreve esses caminhos como duas implementações na camada WebAuthn. Depois, o grupo alcança consenso sem objeção para propor a Recomendação quando as pendências fossem resolvidas.

Portanto, não há base para dizer que o grupo ignorou a questão. Ele discutiu camadas. A lacuna aparece na compressão entre a reunião e o registro público final: a extensão e o nível técnico desaparecem, restando uma frase geral. A matriz e a afirmação de independência são públicas, mas não há chave que as relacione.

O processo decisório terminou. O issue registra aprovação da Equipe em 17 de julho, conclusão da revisão do Comitê Consultivo em 18 de agosto com consenso e sem Objeções Formais, aprovação de publicação no dia 19 e o endereço da Recomendação em 25 de agosto. Uma lacuna de documentação pública não anula esses atos nem prova que não havia evidência adicional.

O Processo não define uma contagem de navegadores

O W3C Process evita deliberadamente uma fórmula universal. A experiência deve mostrar que a especificação é clara, completa e relevante o suficiente para permitir implementações independentes e interoperáveis de cada recurso. A Equipe pode considerar a implementação de cada função, a independência, a existência de implementadores além dos autores, a implantação pública, a experiência nas várias camadas do ecossistema e os problemas relatados.

Essas perguntas não são equivalentes. Um PASS registra comportamento observado. Sem procedência adicional, não prova independência de autoria nem de caminho de código. Sistemas operacionais diferentes podem ser decisivos para uma função de plataforma e irrelevantes para outra. O commit WPT comum torna os ensaios comparáveis, mas não descreve o software testado.

Resultados mistos também não formam um ranking de segurança. FAIL pode indicar falta de suporte, escolha divergente ou uma expectativa de teste que precisa de análise. TIMEOUT ou dado ausente informa ainda menos. A transição não exige que todas as células de todos os produtos fiquem verdes, e este texto não cria esse requisito.

Uma chave funcional e limitada

O complemento pode ser pequeno. Para cada recurso ou grupo de testes usado como evidência, uma linha indicaria a versão da especificação, o commit dos testes, o produto, a compilação e a camada de implementação relevante. Em seguida, faria uma afirmação limitada de independência e apontaria uma fonte pública ou uma declaração atribuível quando detalhes não pudessem ser divulgados.

A linha incluiria a observação de interoperabilidade e diria se ela sustentou a transição. Se Chrome e Edge usam caminhos distintos numa extensão, a informação fica ligada àquela extensão. Se compartilham o caminho relevante em outro recurso, duas colunas não se transformam silenciosamente em duas implementações. O mesmo método valeria para Firefox, Safari, Android, iOS, autenticadores e software das partes confiáveis.

Isso não é auditoria de código-fonte nem nova etapa de aprovação. A Equipe do W3C mantém o juízo contextual previsto no Processo. A chave apenas separa onde o teste rodou, qual comportamento apareceu e por que aquela implementação foi considerada independente para um fim declarado.

Lu Heng, em Minimum Initial Specification, trata uma recomendação como artefato de coordenação e mantém implementação, validação, implantação e adoção como fatos distintos. A mesma modéstia deve valer para o relatório: o nome do navegador identifica o produto testado, não toda a linhagem abaixo dele.

Fontes