Resumo

  • A proposta individual Canonical Action Identifier chegou à versão -04 em 28 de setembro de 2026. Para objetos que -03 e -04 aceitam, as suítes, o resumo e a forma canônica permanecem iguais.
  • A nova versão também recusa objetos que podiam ter CAIDs válidos na anterior. Um histórico que só guarda a cadeia do identificador perde a regra sob a qual o registro foi admitido.

Imagine o relatório mensal de uma plataforma que une aprovações e execuções pelo mesmo identificador de ação. Uma atualização do validador ocorre entre o fechamento de dois períodos. O painel continua a agrupar pelo CAID, como se o nome bastasse para dizer que todas as linhas obedeceram à mesma política. Meses depois, uma auditoria reproduz o registro antigo com a versão nova e recebe uma recusa. A equipe pode chamar isso de fraude antiga; outra pode descartar o alerta porque o resumo não mudou. Nenhuma das conclusões está autorizada por esses dados isolados.

É preciso saber qual versão da regra aceitou o objeto original e por que a atual o recusa.

O CAID é uma proposta de Iman Schrock para tornar comparável a identidade material de uma ação registrada em formatos distintos de autorização, delegação, execução e auditoria. Define objeto tipado, procedimento de canonização e resumo, cadeia compacta de identificação e definições de tipo que indicam os campos essenciais. A versão de 28 de setembro é um Internet-Draft individual. O Datatracker do IETF deixa claro que um Internet-Draft desse tipo não possui posição formal no processo de padronização; o documento não demonstra RFC aprovada, adoção por grupo de trabalho, implantação comercial nem incidente.

A formulação da seção 14 evita duas leituras fáceis e erradas. Primeiro, a revisão é substancial para o processamento. Segundo, ela não altera as suítes, o resumo ou a forma canônica de qualquer objeto que as duas versões aceitem. A ressalva final é decisiva. O conjunto de objetos aceitos por ambas não coincide necessariamente com todos os objetos antigos. O texto lista entradas recusadas agora e afirma que algumas correspondiam a objetos de ação com CAIDs válidos em -03. Entre os exemplos estão profundidade acima de 64 níveis, codificação canônica superior a 16.777.216 octetos, cadeias contendo não caracteres Unicode e certos horários escritos com t ou z minúsculo ou segundo igual a 60. Não há base para anunciar uma quebra universal dos identificadores existentes. Há base para exigir um teste explícito da fronteira de aceitação.

Uma sequência de resumo pode ser estável enquanto a elegibilidade para produzi-la ou verificá-la muda. Isso não é contradição. O resumo responde como representar e vincular um objeto aceito segundo determinada suíte; as regras de entrada decidem quais objetos entram no cálculo e com qual definição de tipo. Um verificador antigo e outro novo podem, portanto, discordar sobre a admissão sem que alguém tenha alterado os bytes armazenados. No relatório, o resultado antigo deve continuar atribuído à regra antiga. O novo resultado é uma observação adicional, não uma autorização para reescrever a primeira linha da história.

A revisão ajuda a registrar também a semântica da definição. Ela introduz definition_sha256, uma impressão da parte da definição que governa a validação; uma expectativa divergente pode produzir definition_mismatch. O nome do tipo, sozinho, não garante que duas organizações fixaram os mesmos campos obrigatórios e conjuntos de valores. O registro de referência mantido pelo autor passa à versão 5 e guarda o arquivo da versão 4, sem alterar um byte, como histórico. Essa preservação é útil para repetição de testes. Não equivale a dizer que os sete registros solicitados à IANA já foram criados.

Há ainda maior rigor na leitura de JSON, na ordem das razões de recusa e no tratamento de definições irregulares. Nomes de membros duplicados no texto JSON, inclusive os que se tornam iguais depois de interpretar escapes, são recusados. É uma das mudanças; não é o assunto inteiro. A questão para quem compra uma promessa de interoperabilidade é se as partes conseguem demonstrar que compararam ações sob a mesma definição e as mesmas regras de entrada, não apenas que exibiram a mesma cadeia no visor.

O limite da proposta deve permanecer visível. O resumo do próprio CAID diz que o identificador não estabelece identidade, autoridade, autorização, execução, segurança ou direito de confiar juridicamente na ação. O perfil de mapeamento pode devolver equivalência sob condições fixadas, não equivalência ou indeterminação; indeterminação não vira equivalência por conveniência. O foco desta notícia é anterior até mesmo a uma decisão de confiança: uma aplicação precisa provar em qual versão a ação se tornou elegível para comparação. Outra decisão, feita por outro responsável, determinará se alguém podia executá-la.

Daniel Kade recomenda, como controle editorial para uma eventual implantação, um comprovante de validação com o objeto de origem ou sua referência verificável, CAID e suíte, versão do analisador, impressão da definição ou instantâneo do registro, decisão de aceitar ou recusar, motivo e responsável por eventual migração. Não é um campo obrigatório previsto no Internet-Draft. A utilidade é preservar a diferença entre conteúdo alterado, definição alterada, regra alterada e política local alterada, diferenças que um único selo verde não consegue comunicar.

Fontes