Resumo

  • Seis tipos distinguem EAT em CWT e JWT, bundles destacados em CBOR e JSON e conjuntos de claims desprotegidos nos dois formatos; +cwt e números CoAP completam a classificação.
  • O parâmetro eat_profile dá ao roteador uma pista antes de abrir o corpo, mas o receptor ainda precisa comparar a claim interna e executar todas as regras do perfil.
  • Parse válido, proteção válida, claims confiáveis, appraisal favorável e autorização da parte dependente são eventos diferentes e precisam de recibos diferentes.

A utilidade está em chegar ao processador certo

Evidence e Attestation Results circulam entre Attester, Verifier e Relying Party. O RFC 9782 não muda esses papéis. Ele resolve um problema anterior: como uma API identifica a representação que recebeu sem depender de nomes locais ou de um parser universal.

Os registros são application/eat+cwt, application/eat+jwt, dois tipos de detached bundle e dois tipos para UCCS/UJCS. Os seis recebem Content-Formats CoAP de 263 a 268. O sufixo +cwt permite que software genérico reconheça a sintaxe CWT. Com isso, um gateway pode rejeitar cedo uma forma desconhecida, negociar a resposta em Accept e escolher um processador mais estreito.

Essa pista não autentica nada. O sufixo não indica signatário, algoritmo aceito, chave, claims obrigatórias, frescor nem política. Um tipo de bundle não prova os digests. Um tipo UCCS não acrescenta assinatura a um claims set desprotegido.

O RFC 9781 exige, nesse último caso, um canal que autentique o remetente e proteja integridade; confidencialidade também exige autenticação do destinatário. Quando o objeto sai do canal, essa garantia termina. Persisti-lo ou repassá-lo cria uma nova fronteira. Já um CWT completo transportado no canal continua dependendo de sua própria proteção COSE: TLS não endossa o token interno.

eat_profile reduz a ambiguidade sem eliminar a verificação

Perfis EAT fecham escolhas de codificação, estruturas COSE/JOSE, algoritmos, identificação de chaves, bundles, claims e frescor. O token pode carregar eat_profile internamente. O RFC 9782 deixa o mesmo identificador aparecer como parâmetro externo, permitindo que o gateway despache antes de inspecionar o corpo.

Isso evita que todo conteúdo atravesse um único parser permissivo. Também torna um perfil não suportado visível na borda. Porém, o parâmetro continua sendo uma declaração do remetente. Depois da decodificação segura, o sistema precisa registrar se o identificador interno está ausente, coincide ou diverge. Uma divergência pode revelar cliente confuso, intermediário antigo ou substituição; não deve ser corrigida em silêncio.

Coincidência também não é conformidade. O RFC 9711 determina que eat_profile não identifique perfil parcial. Um perfil completo precisa permitir que um receptor conforme decodifique, verifique e confira o frescor de qualquer EAT de um emissor conforme. O URI certo pode acompanhar algoritmo proibido, claim ausente ou nonce inválido. A etiqueta escolhe o checklist; apenas o código executado o completa.

O corpo real tem de vencer o rótulo

O RFC 9782 trata media types como pistas para a aplicação e exige verificar que os dados correspondem ao formato esperado, interrompendo o processamento em caso contrário. Aceitar o que um decoder tolerante conseguir “adivinhar” abre espaço para ataques entre protocolos e elevação de privilégio. O RFC 9110 alerta para riscos semelhantes no content sniffing, e o RFC 8725 recomenda tipagem explícita e regras mutuamente exclusivas entre usos de JWT.

Uma cadeia defensável registra primeiro o tipo anunciado e o hash dos bytes. Depois registra rota, versão do parser e gramática aceita. Em seguida registra envelope, algoritmo, key ID, âncora e resultado, ou o escopo do canal autenticado. Bundles precisam comprovar cada vínculo de digest.

Só então começam as claims. O RFC 9711 define semântica, não o nível de segurança do componente que mediu. Assinatura válida atribui bytes sob um modelo de chaves; não prova que o sensor é fiel. O Verifier usa conhecimento da implementação, endorsements, valores de referência e appraisal policy.

Frescor é um controle separado e obrigatório para evitar replay. Nonce é uma opção, e o perfil define o mecanismo aceito. Um token pode ser autêntntico e antigo. Juntar assinatura e frescor em um único “passou” destrói a causa de falha.

Por fim, o Verifier produz Attestation Results; o Relying Party aplica uma política própria a uma ação concreta. Resultado correto pode levar a recusa por recurso, horário, risco ou obrigação jurídica. Resultado incerto pode permitir privilégio menor e temporário. O RFC 9782 conduz o objeto até o decisor; não decide por ele.

O encadeamento completo é tipo e perfil externo → bytes → handler → proteção → perfil e claims internos → conformidade e frescor → appraisal → ação. Registro IANA pertence à camada simbólica. Como observa Heng Lu, a realidade operacional só aparece quando implementações executam e observam os mesmos limites.

Fontes