Resumo

  • A proposta de carta do grupo Web Authentication coloca em escopo a assinatura de dados arbitrários sob mediação do WebAuthn, com uma chave ligada à credencial, mas distinta da chave usada para autenticação.
  • IA agêntica e credenciais digitais verificáveis aparecem como exemplos, enquanto o acesso de baixo nível a chaves privadas e APIs criptográficas autônomas de uso geral continuam fora do escopo.
  • Escopo não indica maturidade: a revisão da carta permanece aberta, o Level 4 não tem FPWD, a pull request sign é Draft e o explainer não registra pesquisa com usuários nem sinais de Chrome, Firefox, Safari ou Edge.
  • Um recibo público de admissão da funcionalidade deve ligar o mandato da carta à versão exata da proposta, aos limites de chave, mensagem e consentimento, às revisões, aos testes, às implementações independentes, ao estado de Recommendation e à adoção real.

A carta permite começar o trabalho; não escolhe o resultado

A carta atual do grupo Web Authentication tem um núcleo reconhecível: autenticação forte para aplicações web. Ela abrange pares de chaves vinculados à origem, prova de posse, recuperação, cópia de segurança e aperfeiçoamentos relacionados. O acesso de baixo nível às operações criptográficas ou ao material das chaves fica excluído. O site pode iniciar a cerimônia, mas não recebe a chave privada do autenticador.

O texto substituto altera essa fronteira. O item 11 permite trabalhar na assinatura de outros dados além da estrutura normal de autenticação do WebAuthn. A operação seria mediada pelo WebAuthn, e a chave de assinatura teria relação com a credencial, mas seria diferente da chave de autenticação. A redação menciona agentes de IA e ecossistemas de credenciais verificáveis. Os dois itens seguintes tratam de sinais de confiança emitidos por gerenciadores de credenciais e da confidencialidade de extensões.

É uma escolha importante de foro. Uma API web capaz de produzir assinaturas convencionais, reconhecidas por outros protocolos criptográficos, não serve apenas para entrar em uma conta. Ela poderia atender carteiras, tokens de autorização, assinaturas de distribuição de software e outros usos que precisam de uma chave protegida por hardware sem expor o segredo ao JavaScript.

Mas o ato institucional em curso é bem mais limitado. O W3C abriu a consulta em 10 de agosto, com encerramento às 23h59 UTC de 7 de setembro, e prorrogou a carta vigente até 30 de outubro. No corte desta análise, a substituta ainda não foi aprovada. Mesmo uma decisão favorável diria apenas que o grupo pode desenvolver essa classe de recurso. Não escolheria a API atual, não resolveria seus riscos e não obrigaria qualquer navegador a implementá-la.

A própria carta conserva essa separação. Web Authentication Level 4 aparece como futuro entregável normativo, mas não há First Public Working Draft, e a conclusão estimada está no quarto trimestre de 2028. Admitir um assunto na sala de trabalho é uma decisão real; tratá-lo como código interoperável e pronto para uso é outra.

Assinar bytes não prova que alguém compreendeu a ação

As asserções normais do WebAuthn já contêm assinaturas, porém o autenticador não assina o desafio do site como entrada isolada. Ele assina uma construção definida, formada por dados do autenticador e pelo hash dos dados do cliente. A proposta de assinatura bruta busca algo deliberadamente diferente: produzir uma assinatura sobre a entrada enviada pela aplicação, sem transformá-la.

Essa generalidade explica o interesse. Verificadores existentes podem entender uma assinatura criptográfica comum, mas não o envelope de uma asserção WebAuthn. Com o novo mecanismo, aplicações web poderiam participar de protocolos já implantados usando uma chave protegida, sem entregar a chave privada ao código da página.

O projeto tenta transportar limites importantes do WebAuthn. A chave de assinatura deve ser separada e criptograficamente independente da chave da credencial pai, para que uma relying party maliciosa não use a nova operação para fabricar uma asserção de autenticação válida. A vinculação à origem procura evitar que a chave se transforme em identificador entre sites. Os requisitos mínimos de presença e verificação do usuário são fixados na criação. A camada exposta à web não deveria permitir assinatura autônoma, embora o protocolo inferior entre cliente e autenticador possa atender aplicações nativas com outro modelo.

São compromissos relevantes. Nenhum deles demonstra que a pessoa entendeu os dados.

O explainer declara que confirmação de transação não é objetivo. Ele admite material binário opaco e não exige que uma interface confiável apresente seu significado antes da assinatura. A cerimônia bem-sucedida pode provar que determinada chave operou sob uma política de presença ou verificação. Sozinha, não prova que a pessoa leu um documento, compreendeu um pagamento, aprovou a ação escolhida por um agente ou aceitou a consequência jurídica depois atribuída à assinatura.

O limite não foi inventado por críticos; está no próprio registro da proposta. “Usuário verificado” descreve a cerimônia. “Usuário compreendeu esta carga” é outra afirmação. “O agente recebeu autorização para escolher esta carga” é uma terceira. Um produto que mistura as três cria autoridade sem que o protocolo a tenha fornecido.

A proposta ainda precisa conquistar evidência

O documento explicativo informa que não houve pesquisa com usuários. Na tabela de partes interessadas, não há sinais de Chrome, Firefox, Safari nem Edge. Há manifestação positiva de um implementador de autenticador e de um implementador de relying party. Ausência de sinal não é rejeição, mas também não é apoio implícito: é um estado ainda sem posição.

A extensão sign continua na pull request 2078, marcada como Draft e ligada ao marco do primeiro rascunho público do Level 4. Em setembro de 2024, o autor mencionou componentes internos preliminares de prova de conceito e nenhuma promessa de outros participantes naquele momento. Discussões e experiências posteriores mostram que há atividade. Não substituem, no material consultado, um relatório aberto de duas implementações independentes e interoperáveis.

O Processo do W3C oferece a sequência que falta. Mudança importante de escopo passa pela revisão do Advisory Committee e por uma W3C Decision. O FPWD inicia o trabalho público na trilha de padrões e produz efeitos de patentes. Revisões horizontais avaliam acessibilidade, internacionalização, privacidade e segurança. Candidate Recommendation reúne revisão final e experiência de implementação. Recommendation exige mais evidência e nova decisão. Depois disso, implementadores e relying parties ainda decidem se a função será implantada.

Cada estado responde a uma pergunta diferente. A carta responde se o grupo pode trabalhar. Uma proposta mostra um desenho inspecionável. O FPWD torna pública a trilha de padronização. A revisão horizontal testa riscos transversais. Testes abertos permitem verificar alegações de forma comum. Implementações independentes demonstram interoperabilidade fora de uma única pilha. Recommendation expressa o endosso do processo. Implantação mostra o que entrou em sistemas em execução.

O argumento de Heng Lu sobre a primazia do código em execução é útil neste limite específico. Publicar ou registrar algo organiza o trabalho futuro, mas não torna uma mudança operacionalmente real sem implementação, validação e adoção. W3C não é um RIR, e padrão web não é registro de recursos numéricos. A disciplina transferível é mais simples: estado documental, evidência técnica e adoção não devem fingir que são a mesma coisa.

Um recibo por funcionalidade preservaria toda a cadeia

A carta proposta já contém critérios gerais de sucesso. A assinatura bruta merece também um registro no nível da funcionalidade, porque sua promessa depende de alegações distribuídas entre documentos, testes e implementações.

O recibo começaria com o item da carta e seu estado. Identificaria a revisão exata do explainer e do texto normativo. Diria se a operação assina a entrada completa, um prehash ou outro envelope; qual é o identificador de algoritmo; e qual convenção de separação de domínio vale. Registraria a relação entre a credencial pai e a chave de assinatura, a fronteira de origem, a política fixa de presença e verificação e o que a pessoa realmente vê.

Também ligaria o significado da atestação, a análise de correlação e fingerprinting, os sinais dos navegadores, autenticadores e sites, os pontos de revisão horizontal e suas soluções, a cobertura de testes, as implementações independentes, as objeções em aberto e o estágio atual do W3C.

Esse índice não deve conter chaves privadas, identificadores de dispositivos, dados pessoais de teste nem pormenores exploráveis. Tampouco precisa criar um novo comitê com poder de veto. Sua função é unir, com versões e datas, registros públicos que o processo existente já deveria produzir.

O benefício aparece quando os fatos mudam. Uma nova redação da carta altera a primeira linha. Se confirmação de transação virar objetivo, a antiga limitação continua visível. Se um navegador publicar posição negativa, o novo estado não reescreve o antigo “sem sinal” como oposição histórica. Se um teste revelar confusão entre protocolos, o resultado e a correção permanecem ligados. Se a proposta for abandonada, terá estado terminal legível, em vez de sobreviver como uma frase de carta citada fora do tempo.

Fontes

  1. W3C — chamada para revisão da proposta de carta do Web Authentication
  2. Proposta de carta do grupo Web Authentication
  3. Carta vigente do grupo Web Authentication
  4. Recomendação Web Authentication Level 3
  5. Explainer da extensão de assinatura bruta
  6. Pull request Draft sign 2078
  7. Processo do W3C, 18 de agosto de 2025
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption