Resumo

  • A revisão 01 de um Internet-Draft individual limita o alcance do renderizador determinístico: ele detecta divergência entre a ação assinada e a representação declarada, sem provar o que uma tela não confiável mostrou.
  • O recibo de autorização e a evidência de apresentação precisam produzir resultados separados. Uma verificação positiva em qualquer camada não autoriza a ação automaticamente.
  • Daniel Kade propõe um registro de decisão de apresentação que una as provas ao vínculo da chave, mandato humano, raízes de confiança, risco residual e política local. A proposta é editorial, não normativa.

A correção começa pelo sujeito da frase

Na versão anterior, o resumo dizia que uma pessoa identificada havia produzido uma assinatura verificada pelo usuário. A revisão 01 passa a dizer que uma chave cadastrada produziu a assinatura. A mudança é pequena na forma e grande na governança: a criptografia reconhece a chave; saber quem a controlava, se continuava no cargo e quais decisões podia tomar depende de outros registros.

O comparativo 00–01 também elimina a sugestão de que a técnica provaria o conteúdo mostrado à pessoa. O resultado verificável é mais estreito. Um terceiro consegue recalcular, a partir da ação assinada, a representação que deveria corresponder a ela. Não consegue impedir que um cliente comprometido entregue essa representação correta ao verificador e, ao mesmo tempo, mostre outra imagem no monitor.

O Datatracker registra a versão em 12 de setembro de 2026 como Internet-Draft individual ativo. Não há grupo de trabalho, fluxo IETF, Area Director responsável nem status RFC pretendido. A publicação disponibiliza a proposta; não demonstra adoção, consenso ou endosso da IETF.

Determinismo oferece uma comparação auditável

O renderizador deve ser uma função pura de uma ação canônica. Mesma ação significa a mesma saída byte a byte, independentemente de relógio, ambiente, aleatoriedade, idioma do sistema ou acesso externo. O perfil fecha o conjunto e a ordem dos campos importantes e calcula um digest da representação. RFC 8785 fornece a referência de canonicalização JSON usada pelo texto.

Isso resolve um problema concreto. Se o valor, o destinatário ou a regra no documento assinado diferir da representação submetida, o recálculo falha. A revisão também exige tratamento determinístico para controles bidirecionais, caracteres de controle, trechos visualmente confundíveis e valores extensos. Quando não houver forma segura de renderizar, o comportamento correto é recusar, não cortar silenciosamente.

A atestação de tela acrescenta uma declaração assinada do cliente que liga o digest da representação ao digest da ação. Ela fica ao lado do recibo, preservando os formatos anteriores. A assinatura pode ser válida e a representação pode ser reproduzível; ainda assim, confiar no cliente e no caminho físico de exibição é outra avaliação.

Por isso a nova seção 6.1 proíbe dois atalhos. Um recibo válido não vira automaticamente apresentação aceita. Uma evidência de apresentação válida não vira automaticamente autorização. O terceiro que arca com o resultado deve selecionar bases de confiança independentes e manter os resultados separados.

O hardware reduz o espaço de dúvida, mas não cria mandato

O texto cita Android Protected Confirmation como exemplo que poderia ganhar um perfil específico, sem defini-lo. A documentação de ConfirmationPrompt descreve a validação da cadeia da chave, de uma raiz esperada, de um nonce e do texto exato confirmado. Também informa que a garantia depende de hardware dedicado e que o recurso pode ficar indisponível, inclusive em algumas condições de acessibilidade.

Uma política operacional precisa guardar esses detalhes. Deve registrar qual raiz foi aceita, o que a atestação da chave afirmou, qual texto entrou no caminho protegido, quais campos relevantes ficaram de fora e qual alternativa foi usada quando o recurso falhou. Um retorno silencioso para um diálogo comum muda a qualidade da prova e, portanto, exige decisão explícita.

Nem o hardware nem a implementação de referência alegada pelo projeto resolvem a autoridade humana. Testes negativos podem mostrar que um código rejeita uma divergência ou entrada hostil. Não provam revisão independente, implantação, integridade permanente do dispositivo ou competência funcional do aprovador. A versão 01 não pede ação à IANA; o registro de identificadores permanece futuro.

Dar identidade própria à decisão

Daniel Kade propõe um registro de decisão de apresentação mantido pela organização que confia na evidência. Ele deve reunir digest da ação, perfil e resultado do recibo; perfil, versão, idioma, campos materiais e digest do renderizador; resultado da atestação de tela; cliente, cadeia e raiz de confiança; classe do caminho de exibição; evidência que vincula chave e pessoa; função, alçada e vigência; risco residual; política de autorização; decisão e justificativa; revisor, horário, expiração, recusa ou contingência e gatilhos de reavaliação.

O objetivo não é criar um passe universal. Uma instituição pode exigir confirmação protegida e segundo canal para uma transferência irreversível, mas aceitar verificação determinística e revisão dupla numa mudança reversível de rede. A interface comum descreve a evidência; cada autoridade local assume o limiar e a consequência.

A Minimum Initial Specification de Heng Lu sustenta essa divisão entre um núcleo mínimo compartilhado e decisões futuras localizadas. The Policy Mirror pede fidelidade ao que cada autoridade realmente declarou. E Why BTW Media Exists disciplina a notícia: houve uma correção importante num rascunho individual; ainda não houve padronização, adoção nem prova de segurança.

Fontes

  1. Registro no Datatracker
  2. Histórico do documento
  3. API de metadados
  4. Revisão 01
  5. Revisão 00
  6. Diferenças oficiais
  7. Authorization Receipts
  8. Authorization Receipts, revisão 13
  9. RFC 8785
  10. Android ConfirmationPrompt
  11. Android Protected Confirmation
  12. Atestação de chave Android
  13. The Policy Mirror
  14. Minimum Initial Specification
  15. Why BTW Media Exists