Resumo

  • draft-ietf-oauth-transaction-tokens-11 especifica um JWT assinado e de vida curta para levar identidade e contexto da transação pela Call Chain dentro do Trust Domain delimitado por aud. É Internet-Draft ativo de Standards Track, em WG Consensus: Waiting for Write-Up, não RFC nem aprovação final do IETF.
  • O destinatário deve validar assinatura JWS, audience e expiração. Isso comprova integridade e destino do contêiner, mas não informa sozinho se cada valor de rctx ou tctx foi fornecido, observado, derivado ou atestado de forma independente.
  • Daniel Kade propõe um envelope de origem para cada alegação usada na decisão: fonte, validação executada, observador, tempo, transformação, versão de política, atualidade, uso permitido, contradições e resultado. O envelope pode guardar hashes ou referências, sem o token completo ou dados pessoais desnecessários, e não é exigência do IETF.

O relatório de acesso tinha todos os sinais de organização: identificador de transação, emissor, data, assinatura válida e account_verified: true. Quando surgiu a pergunta sobre qual verificação sustentava o último campo, o relatório ofereceu apenas o próprio token. Ninguém sabia se a informação vinha de uma credencial, de uma consulta recente ou de um JSON entregue pelo solicitante.

Os bytes tinham autoria e integridade. A afirmação já não tinha história.

Esse desencontro é fácil de ocultar em uma arquitetura distribuída. JWS responde qual chave assinou determinada representação e se ela mudou depois. O TTS responde quais claims decidiu disponibilizar. Para uma autorização sensível, falta uma terceira resposta: como cada fato entrou no sistema, qual teste passou, quando foi observado e até que tipo de decisão aquela prova sustenta.

A revisão 11 permanece um Internet-Draft

O Datatracker registra a revisão 11, de 30 de julho de 2026, como Internet-Draft ativo do OAuth Working Group, destinado a Standards Track. No corte desta pesquisa, o estado do grupo era WG Consensus: Waiting for Write-Up, e o do IESG, I-D Exists. Não havia Area Director responsável nem data de telechat. É avanço processual, mas não é RFC ou aprovação final.

O histórico e o diff oficial 10→11 mostram que a mudança corrige um erro no histórico do documento. O modelo de confiança analisado aqui já estava na revisão 10. O anúncio do I-D confirma a publicação da nova versão, não o encerramento do processo IETF.

A proposta enfrenta um problema real. Uma transação pode percorrer vários workloads, cada um precisando de identidade, finalidade, scope e detalhes do pedido. Reapresentar a credencial externa em todos os saltos amplia exposição e exige que cada serviço a interprete. O Transaction Token oferece um JWT assinado, válido por pouco tempo, para transportar contexto comum dentro do Trust Domain identificado por aud.

Existe exatamente um Transaction Token Service lógico por domínio, embora várias instâncias possam executá-lo. O TTS autentica o workload solicitante, verifica se ele pode obter o token, seleciona as informações e assina o resultado. JWT define o formato de claims, JWS a representação assinada e o OAuth WG conduz o trabalho.

Três verificações não encerram a autorização

O workload que recebe o token precisa validar a assinatura JWS, confirmar que aud aponta para seu Trust Domain e rejeitar um objeto expirado. As três obrigações dão uma conclusão importante: o domínio recebeu, no prazo, os bytes que o TTS assinou.

Depois disso, a aplicação pode usar os dados para tomar uma decisão local de autorização, cujo método está fora do escopo do draft. A divisão é saudável. O emissor fornece contexto comum; quem causa a consequência continua responsável por compreender o campo que usou.

O documento também diz que Transaction Token não é credencial de autenticação e não pode ser usado como OAuth access token. No OAuth 2.0, access token representa concessão de autoridade. Transaction Token representa contexto de uma transação. A semelhança de codificação não transforma contexto em grant.

Também não há resistência intrínseca a replay. O txn único ajuda a detectar repetição ou implementar uso único. Em uma Call Chain distribuída, a aplicação estrita pode depender de estado compartilhado inviável. A assinatura detecta alteração; não impede que o mesmo objeto seja apresentado novamente.

O TTS escolhe o conjunto, não uma origem única

scope é obrigatório e determinado pelo TTS. O serviço não pode ampliar o scope representado pelo subject token original. Se não compreender o scope de entrada, deve recusar, em vez de tratar o desconhecido como irrestrito. Essa é uma garantia normativa específica de não ampliação.

rctx, recomendado, pode conter contexto da requisição ou do ambiente. Quando o solicitante fornece esse contexto, o TTS deve avaliá-lo. O valor publicado pode ser igual à entrada, derivado dela ou uma alegação independente do próprio TTS. Ser autoridade sobre o conjunto disponibilizado não significa ter observado e validado cada membro do conjunto pelo mesmo processo.

tctx, também recomendado, contém detalhes que devem permanecer imutáveis na Call Chain. Eles podem copiar a requisição, resultar de uma transformação ou ser acrescentados pelo TTS. Imutabilidade depois da emissão responde se o valor mudou. Não responde onde ele nasceu.

Imagine três claims: request_ip, observado por um proxy autenticado; purchase_total, copiado de um objeto sem assinatura; e risk_class, calculado pelo TTS sob a política 43 a partir de uma credencial validada e um sinal atual. A mesma assinatura cobre tudo. A força probatória do primeiro depende do proxy, a do segundo da autoridade do solicitante e a do terceiro dos dados e da versão do cálculo.

Não é correto concluir que rctx ou tctx sejam inerentemente duvidosos. Um valor pode ter excelente garantia. A questão é tornar visível de qual fonte e validação ela veio. Um token pode legitimamente misturar afirmação declaratória e conclusão verificada; a aplicação só não deve chamá-las pelo mesmo nome probatório.

“Subject token validado” pode descrever controles diferentes

O TTS pode aceitar um token OAuth ou SAML, JWT autoassinado, objeto JSON sem assinatura ou outro formato entendido. Precisa validar o subject token, inclusive a assinatura quando houver. Portanto, a operação varia: emissor, chave, algoritmo, audience, tempo, schema e contrato do canal podem entrar na checagem.

As boas práticas de JWT explicam por que algoritmo e chave não devem ser aceitos por inferência do próprio token. OAuth Token Exchange oferece um quadro relacionado para troca de tokens, enquanto este draft trata do contexto interno. Um JSON sem assinatura pode ser entrada válida em um canal controlado, sem adquirir por isso a origem criptográfica de uma credencial assinada.

O TTS também verifica a autenticação do workload requerente e sua autoridade para pedir o token. A política de emissão e a lógica do negócio ficam a cargo do deployment. Essa liberdade permite adequação local e também faz com que dois sistemas conformes apliquem testes diferentes a um campo de mesmo nome. Sem a versão da política, interoperabilidade de sintaxe parece interoperabilidade de confiança.

Expiração do contêiner não é atualidade de cada fato

Transaction Tokens devem durar minutos ou menos, apenas pelo tempo da invocação prevista. Mesmo assim, podem expirar depois do subject token apresentado, quando a política do TTS permite e avalia o risco. Isso pode evitar que uma chamada já iniciada pare no meio. Também mostra que exp do novo token não comprova nova validação de todos os fatos anteriores.

Um access token pode ser invalidado antes de expirar. Conforme o risco, o TTS pode consultar o estado corrente por introspecção ou mecanismo semelhante. Não é uma obrigação universal de consulta em tempo real. “Dentro do prazo” e “não revogado às 09:17” precisam continuar proposições diferentes.

Tokens substitutos não podem ampliar ações nem mudar txn, sub ou aud. Podem reduzir scope, acrescentar assertions e, sob política, estender a duração. Devem manter a Call Chain de workloads solicitantes, embora o mecanismo fique fora do draft. Quando o registro não identifica qual substituição adicionou uma claim, a versão final apaga a sequência de decisões que a formou.

Fora do aud, o token não é uma autoridade portátil. Continuação entre domínios pertence ao trabalho separado de encadeamento de identidade e autorização OAuth. Verificar a assinatura de outro domínio não importa automaticamente as definições locais dele.

A observação de um revisor não é consenso nem incidente

Em uma mensagem WGLC de 8 de agosto de 2026, um revisor apoiou o avanço e declarou não ter comentário bloqueante. Pediu maior auditabilidade das cadeias de substituição e alertou que implementadores podem confundir informação carregada em token assinado com informação atestada de forma independente pelo emissor.

A atribuição precisa é essencial. Trata-se do alerta de um revisor e de sua experiência declarada. Não é consenso do WG, evidência de adoção ampla, incidente confirmado ou prova de defeito da revisão 11. A mensagem vale como leitura operacional plausível que merece prevenção.

Um envelope de origem junto ao recibo da decisão

A proposta editorial de Daniel Kade é registrar, para cada claim efetivamente usada, um envelope de origem. Ele contém classe e identificador não secreto da fonte, validação realmente executada, observador e horário, transformação e versão do código ou da política, emissor, referência de chave e limite do Trust Domain quando pertinentes, teste de atualidade ou invalidação, usos permitidos, sensibilidade, regra de logging, contradições, decisão downstream, expiração e encerramento.

O envelope pode ficar fora do Transaction Token. Pode referenciar um recibo de emissão, conservar somente o hash do token ou apontar para evidência reduzida. O draft proíbe registrar tokens completos literalmente, por risco de replay e exposição de dados sensíveis. Um hash pode correlacionar com o registro do TTS, e o payload JWS sem assinatura pode ser registrado em condições adequadas; ainda assim, ele pode conter dados pessoais. IP e contexto ambiental podem ser informação pessoal conforme a jurisdição. Este artigo não conclui obrigações legais.

O objetivo é reconstituir por que a decisão pareceu correta, sem construir um segundo estoque de credenciais reaproveitáveis e dados brutos. Registra-se a linhagem, não o segredo.

Fontes