Resumo

  • Publicado em 8 de setembro de 2026, draft-wei-aic-jwt-01 é um Internet-Draft individual ativo. Não é trabalho adotado pela IETF, padrão aprovado nem prova de implantação; Experimental é apenas o status pretendido pelo autor.
  • O perfil completo coloca um JWT DelegationAuthorization assinado pelo principal dentro de um AIC-JWT assinado pelo emissor. A assinatura interna protege a autorização e agent_id; a externa cobre o DA exato e o claim cnf.
  • A revisão 01 declara que o DA atual liga a autorização à identidade do agente. A inclusão da chave do agente no próprio DA fica para uma versão futura; hoje, cnf identifica a chave de prova de posse no envelope externo.
  • Um recibo de vínculo de chave deve registrar a afirmação de cada assinatura, em vez de reduzir tudo a “duas assinaturas válidas”. Esse recibo é proposta de Daniel Kade, não texto normativo.

A atualização é técnica, não uma aprovação institucional

O anúncio I-D registra a versão 01 às 14h48 UTC de 8 de setembro. O Datatracker a mantém em Individual Submissions, com estado I-D Exists, sem stream de RFC, Area Director responsável ou data de telechat. Qualquer pessoa pode submeter um Internet-Draft. O cabeçalho “Intended status: Experimental” informa a ambição do autor, não adoção, consenso, aprovação ou recomendação de uso.

A disciplina de status importa porque o texto descreve um sistema amplo. AIC-JWT é apresentado como representação na camada de aplicação do modelo AIC definido em outro rascunho para X.509. JWT e JWS levam a estrutura a ambientes HTTP, web e OAuth; eles não criam por si sós os direitos, a semântica das capacidades ou a política de execução.

A comparação oficial mostra uma revisão extensa. O DA passa da versão de claims 1 para 2, recebe campos de RFC 7523 e deve ser rejeitado por implementações 01 quando chegar no formato antigo. A novidade central para governança é deixar de tratar a identidade agente e chave como sinônimos criptográficos.

O principal fecha o conteúdo do DA

No fluxo PKI descrito, o agente gera um par de chaves e monta o pedido com capacidades desejadas, modo de delegação, restrições e nonce. O principal revisa o pedido, assina o DA JWT e o devolve. O agente entrega o DA à CA. No modo de authorization server, apresenta a mesma autorização assinada como JWT bearer grant de RFC 7523.

O DA carrega iss, sub, aud, exp, jti, agent_id, vínculo do principal, motivo, capacidades, modo, restrições, vida solicitada, instante e nonce. A chave usada para verificar a assinatura tem de corresponder ao key_hash do principal. jti e nonce precisam ser iguais. O tipo interno aic+da+jwt impede que o DA seja aceito como token externo.

O envelope mantém no claim da a serialização compacta exata. O verificador não pode reconstruí-la antes da validação. Assim, o emissor não altera capacidade, modo, audiência ou identidade sem quebrar a assinatura do principal. Ao mesmo tempo, a chave do principal não basta para cunhar o AIC-JWT, pois a assinatura externa pertence ao emissor.

O resultado é forte e delimitado: a assinatura interna prova que aquele principal assinou aquela autorização para o agent_id nomeado. Ela não prova que uma impressão digital da chave de apresentação, ausente do DA atual, fez parte dos bytes assinados.

A chave aparece sob a assinatura externa

O claim obrigatório cnf aponta para a chave de prova de posse do agente. O RFC 7800 fornece a semântica e o rascunho recomenda jkt, a impressão digital JWK do RFC 7638. Se DPoP for usado, cnf.jkt deve coincidir com a chave da prova. Em mTLS, a implantação pode comparar também a chave do certificado cliente.

A fronteira aparece nos fluxos PKI e OAuth. Um vínculo da chave diretamente no DA está reservado para uma revisão futura do claim set. Nesta versão, a chave apresentada é vinculada por cnf no consumo. Como cnf está no payload externo, é a assinatura do emissor que cobre esse vínculo junto com o DA intacto.

Isso não quer dizer que o emissor escolhe livremente a chave. O fluxo começa com a geração pelo agente e inclui revisão do pedido pelo principal. A CA ou AS deve verificar assinatura, chave do principal, audiência, prazo, unicidade do nonce e restrições. O token externo não pode sobreviver ao grant assinado pelo principal.

A diferença surge na prova histórica. Duas verificações bem-sucedidas mostram que o principal assinou agent_id e que o emissor assinou um cnf específico. Não mostram automaticamente que o principal assinou essa impressão digital. Se a interface exibiu e confirmou a chave, esse evento precisa de evidência própria no processo de emissão.

Também não se deve transformar presença em aplicação. O rascunho avisa que AIC-JWT não é sender-constrained por natureza. Sem exigir DPoP ou prova equivalente, um token roubado ainda pode funcionar como bearer até expirar. cnf descreve a chave esperada; a decisão do verificador prova que a apresentação demonstrou sua posse.

O recibo precisa separar emissão de apresentação

Eu exigiria um recibo com hash e versão exatos do DA, identificador da chave do principal, agent_id, emissor, hash do token externo, método e impressão digital de cnf, política de emissão, resultado de consumo do nonce, interseção dos prazos, método de prova de posse e decisão do verificador. Uma aprovação explícita da chave pelo principal deve ser anexada como fato separado.

O mesmo cuidado vale para replay. O nonce do DA é consumido na primeira emissão e não pode gerar um segundo token externo. Isso não torna o token emitido descartável após uma apresentação. O controle por requisição vem do jti da prova DPoP ou de mecanismo equivalente. Misturar os dois relógios produz uma garantia para o evento errado.

O recibo pode ser protegido. Impressões digitais persistentes e relações principal-agente são material de correlação. Compromissos, resultados de política e referências de auditoria podem ser revelados conforme a necessidade, sem publicar um mapa de chaves. Minimização e responsabilização não são opostos.

Pelo Policy Mirror de Heng Lu, o principal escolhe a identidade e as capacidades; o emissor aceita o DA e assina o vínculo atual da chave; o verificador decide se a posse e a política local foram satisfeitas; o dono do recurso herda o efeito. Uma tela que mostra só “validado” apaga exatamente essa distribuição de poder.

Fontes