Resumo

  • A extensão remoteClientDataJSON é negada por padrão e exige autorização por origem. Esse consentimento abre uma capacidade local, mas não prova que o cliente remoto validou corretamente a origem e o RP ID.
  • O controle adequado é um recibo entre clientes, vinculado à sessão, à política e ao hash dos dados exatos, sem fazer o navegador local repetir toda a lógica de validação do lado remoto.

O First Public Working Draft do Web Authentication Level 4, publicado em 15 de setembro de 2026, muda uma fronteira de confiança. Essa alteração é mais importante do que o simples acréscimo de uma extensão à API.

No fluxo comum do WebAuthn, o navegador conhece a origem de quem o chamou. Em regra, o RP ID precisa ser igual ao domínio efetivo dessa origem ou a um de seus sufixos de domínio registráveis; origens relacionadas seguem um procedimento específico. O navegador monta clientDataJSON, o autenticador assina o hash desses bytes, e o servidor do relying party verifica o tipo da cerimônia, o desafio, a origem esperada e o hash do RP ID.

Um desktop remoto pela web separa essas funções. O site que pede autenticação roda no host remoto, enquanto o autenticador está no dispositivo local. Se o navegador local reconstruir os dados usando seu próprio contexto, inserirá a origem do cliente web de desktop remoto, não a origem do RP dentro da sessão. E diferenças de ordem de campos, propriedades opcionais ou espaços no JSON já bastam para alterar o hash.

remoteClientDataJSON permite que um cliente autorizado entregue a string completa gerada no ambiente remoto. O navegador local faz o parse, mas não pode acrescentar, retirar ou alterar nada. Ao serializar os dados do cliente, ele usa a string recebida, de modo que o autenticador assine os mesmos bytes que a máquina remota espera.

O rascunho não libera a função de maneira ampla. publickey-credentials-remote-client-data-json é definida como recurso poderoso e como recurso controlado por Permissions Policy. O estado padrão é denied, e a lista padrão indicada é 'none'. A configuração deve ser feita por origem; uma autorização global para todos os sites é proibida. O texto recomenda política administrada ou adesão explícita para uma origem nas configurações do cliente, em vez de um pedido oportunista durante a cerimônia.

Essa defesa responde à pergunta local: esta origem pode invocar a extensão? Ela não responde à pergunta remota: o cliente identificou corretamente a origem do RP e aplicou as regras certas ao relacioná-la ao RP ID?

O algoritmo deixa a divisão evidente. Sem estado granted, o navegador rejeita a operação. O RP ID precisa ser fornecido explicitamente, e o JSON remoto é analisado. Em seguida, porém, o navegador local pula o teste normal entre o RP ID e o campo origin recebido. O rascunho diz que todas as verificações de origem ligadas ao RP ID são delegadas ao cliente remoto. A seção de segurança acrescenta que o user agent precisa confiar que o chamador apresentou a origem remota com precisão e que o cliente remoto fez a validação de forma honesta e correta.

O retorno booleano da extensão tem alcance restrito. true só indica que ela foi executada. Não contém a identidade da sessão remota, a versão da política, o algoritmo, o resultado ou a prova usada para origens relacionadas. A preservação byte a byte também prova apenas que o navegador local não refez os dados. Não garante que a declaração de origem dentro deles seja verdadeira, atual ou autorizada.

A assinatura do autenticador vincula o resultado ao hash do client data e aos dados do autenticador. O RP continua obrigado a verificar tipo, desafio e origem e a comparar rpIdHash com o RP ID esperado. Esses controles são indispensáveis, mas podem não registrar qual cliente remoto tomou a decisão delegada, qual versão de política estava vigente e qual canal remoto foi associado à chamada local.

Isso não é alegação de vulnerabilidade, exploração ou incidente. Level 4 é um primeiro rascunho público, não uma Recomendação do W3C, nem evidência de implementação, interoperabilidade ou uso em produção. A própria seção de status informa que a publicação não significa endosso e que o documento pode mudar, ser substituído ou se tornar obsoleto. Há ainda uma issue aberta no repositório W3C WebAuthn sobre uma dependência de terminologia: o comportamento de negação padrão é claro, mas 'none' ainda não era um valor normativo definido no rascunho de Permissions Policy. A issue não pede mudança de comportamento.

Portanto, a resposta de governança não deve desfazer a delegação. O lado remoto tem contexto que talvez não exista no navegador local, como documentos de origens relacionadas e associações de aplicativo específicas da plataforma. Obrigar o ambiente local a repetir tudo criaria dois validadores capazes de divergir silenciosamente.

O ajuste mais preciso é gerar um recibo de validação de origem entre clientes. Ele deve ligar a origem local e a concessão — sujeito, fonte, versão e validade — à sessão remota e ao canal autenticado. Deve registrar origem remota, RP ID, algoritmo e versão, resultado e referências às evidências de origens relacionadas ou associação de aplicativo. Um hash dos bytes exatos de remoteClientDataJSON conecta a decisão ao que foi assinado; o resultado da validação no servidor RP fecha a cadeia. Exceções, revogações e correções entram como novos eventos, sem apagar a decisão original.

Esse recibo é uma proposta operacional, não um requisito que este artigo atribua à especificação. Ele mantém separados cinco fatos: a capacidade local foi autorizada; a validação remota ocorreu; os bytes foram preservados; o usuário interagiu com o autenticador; e o RP aceitou ou rejeitou. Um único indicador verde de sucesso não comprova todos eles.

Fontes