Resumo

  • A versão -01 da proposta individual de atestação do estado de carteiras saiu em 27 de setembro de 2026. O documento não é uma RFC nem demonstra adoção pelo IETF ou uso em produção.
  • No formato JSON, a assinatura cobre id, pass, results e attestedAt. A carteira pode estar em uma condição específica, mas não é identificada obrigatoriamente no objeto assinado.
  • O prazo expiresAt fica fora da assinatura JSON. O JWT opcional assina sub e exp, mas exige verificação própria e, quando acompanha o JSON, conferência de correspondência.

Quem define a validade de um «sim»

O texto revisado propõe que um emissor leia o estado público de uma carteira na cadeia, avalie condições estabelecidas pelo operador e assine um resultado booleano ou um perfil factual. O verificador pode conferir a assinatura sem consultar o emissor naquele momento. Uma resposta simples pode revelar apenas se um requisito foi satisfeito, sem divulgar o saldo. Nada disso, porém, elimina a responsabilidade de dizer até quando aquela observação serve para uma decisão atual.

O formato JSON coloca attestedAt e a referência da cadeia de cada resultado dentro dos dados assinados. Já expiresAt segue como campo adjacente. Segundo a proposta, quem depende do prazo deveria compará-lo com a hora assinada e com a janela de validade documentada pelo emissor. Se a decisão exigir rigor maior, o próprio verificador pode impor idade máxima ao horário e à referência de bloco protegidos. Isso é diferente de confiar em um prazo não assinado porque a assinatura de outro campo foi validada.

Na nova sequência de sete verificações, selecionar chave e esquema, reconstruir bytes, conferir assinatura e recalcular conditionHash são exigências do rascunho. Conferir frescor e expiração é recomendado. O texto não garante que todos os destinatários executarão essas duas últimas etapas. Um serviço que vende uma resposta booleana como autorização instantânea precisaria explicar quem escolheu a tolerância a atraso e quem recebe o risco de usar estado antigo. Esta é uma pergunta de implantação, não uma acusação de falha já observada.

O sujeito pode ficar na requisição anterior

Há também um limite sobre a identidade da carteira consultada. Os quatro membros superiores assinados do JSON são id, pass, results e attestedAt; não existe um campo geral obrigatório para o endereço. Um tipo de condição pode levar esse endereço em evaluatedCondition e, nesse caso, ele estará dentro de results assinados. Mas isso não é promessa universal. O componente que fez a requisição sabe qual carteira informou. Um segundo componente que receba somente o resultado pode não saber. A assinatura não produz o vínculo que se perdeu no trajeto.

Recalcular conditionHash impede que uma condição transmitida seja trocada discretamente. Não responde, sozinho, a pergunta sobre o endereço se a condição não o trouxer. Da mesma forma, um kid ausente ou desconhecido não autoriza tentar outra chave por aproximação. A revisão diz que esse caso é não verificável; uma assinatura que falha com a chave indicada é refutada. Os dois resultados impedem aceitação, mas devem ser comunicados de modo distinto. Um conjunto JWKS em cache pode ser atualizado e a verificação repetida, sem transformar uma chave não encontrada em uma chave presumida.

A alternativa JWT tem assinatura própria

Quando solicitada, a forma JWT é enviada ao lado do JSON. Seu sub nomeia a carteira efetivamente avaliada, exp traz o prazo assinado e o cabeçalho protegido contém kid. Quem usa essas informações precisa verificar o JWT, não apenas o JSON vizinho. Recebidos os dois, a proposta também descreve uma comparação entre eles; um token inválido ou incompatível rejeita a resposta. É incorreto dizer que a presença do JWT alterou o escopo da assinatura JSON ou que verificar esta última prova automaticamente as alegações do token.

Uma prova de Merkle pode ser pedida em condições e cadeias que a comportem. O próprio documento reconhece indisponibilidade em muitos casos. Onde existir, poderá revelar valores brutos, como o saldo que o modo booleano deixava oculto. Assim, mais verificabilidade pode custar mais exposição. A escolha não resolve, por si, qual requisição e qual carteira estão vinculadas à decisão final.

A revisão -01 acrescenta um esquema JSON com separação de domínio, uma assinatura companheira opcional e regras mais explícitas de rejeição. Ela não inventa agora o formato anterior: o autor diz que assinaturas da versão -00 continuam válidas. A novidade relevante é tornar mais nítido o perímetro já existente e como um verificador deve tratá-lo. O Datatracker classifica o material como Internet-Draft individual ativo, sem fluxo RFC e com estado I-D Exists. Hospedagem no IETF não equivale a aprovação; exemplos de uso citados pelo autor não são, aqui, comprovação independente de implantação.

Fontes