Summary

  • A revisão 01 envia um Credential JWT assinado pelo emissor em Authorization: DPoP e mantém a prova de requisição de RFC 9449.
  • Prova, chave e bytes válidos não classificam o objeto. O servidor precisa separar Credential de access token por iss confiável e typ aceito.
  • Vincular a chave a uma requisição não cria audiência, não atualiza status, não reduz a exposição das claims, não concede acesso e não confirma o efeito do serviço.

O encaixe foi reaproveitado

O Holder põe o Credential inteiro onde normalmente ficaria o token e assina outra JWT com htu, htm, iat, jti, nonce quando exigido e ath. O cálculo de ath continua sendo SHA-256 sobre os bytes US-ASCII recebidos. O Resource Server também compara a chave da prova com cnf.jkt ou com a impressão digital de cnf.jwk.

Essa sequência prova coerência e posse. Ela não escolhe a semântica. No perfil de RFC 9068, um JWT access token requer aud e usa at+jwt. O Credential deste rascunho precisa de um typ definido pelo deployment, diferente de at+jwt e de tipos de ID Token. Um servidor que aceite ambos deve abrir ramos distintos a partir de iss e typ. Caso contrário, aplicará uma política errada a um objeto criptograficamente correto.

A URI não vira audiência

htu e htm identificam a requisição para a qual a prova foi produzida. Eles não registram para quais Verifiers o Issuer quis distribuir uma identidade reutilizável. Essa restrição cabe a aud, quando presente, e só o Issuer a define.

Sem aud, o Credential pode ser apresentado a qualquer Resource Server que confie no mesmo Issuer. O Holder escolhe o destino, mas não cria a audiência. Dois serviços podem confiar nas mesmas chaves e ainda interpretar claims e permissões de modo incompatível. Por isso, a política local deve decidir o acesso depois da validação; o texto proíbe inferir autorização da mera validade do Credential.

Status substitui parte da vida curta

Credentials podem durar mais do que access tokens. O rascunho recomenda uma claim de status; quando ela existe, o Verifier deve consultá-la e rejeitar resultado inválido. Uma política também pode rejeitar um Credential duradouro que não permita revogação.

O cache define o atraso. Se uma lista fica válida por horas, a revogação pode levar horas para ser observada. Assinatura do Issuer, prova DPoP atual e status em cache têm relógios independentes. Tirar o Issuer do caminho crítico melhora latência e privacidade direta, mas a busca da lista ainda pode revelar onde e quando o Credential é usado.

O Credential inteiro atravessa a fronteira

Não há seleção de claims. Cada Verifier recebe tudo, e o mesmo valor assinado pode correlacionar apresentações. Cabeçalhos Authorization também podem parar em logs e proxies. TLS não desfaz uma claim excessiva nem apaga uma cópia persistente.

OpenID4VP atende outro cenário: descoberta, seleção, disclosure parcial ou consentimento humano. Esta proposta pressupõe software que já conhece o destino e qual Credential será aceito. Um SD-JWT VC entra apenas como seu JWT assinado, sem disclosures.

A Minimum Initial Specification de Lu Heng permite compartilhar um mecanismo pequeno sem centralizar todas as decisões nele. Running-Code Primacy exige os recibos da execução: typ, confiança no Issuer, ramo de audiência, idade do status, versão da política e resultado efetivo do recurso.

Sources and limits

As fontes não provam adoção pelo grupo OAuth, consenso IETF, RFC, implementação, interoperabilidade, deployment de agentes, emissão ou revogação real, autorização ou resultado. O Artigo de RFC 9449 mantém a tese geral de sender constraint; este cobre apenas o modelo diferente por trás do mesmo formato.