Summary

  • draft-lee-oauth-dpop-credential-presentation-01 places a whole issuer-signed JWT Credential in Authorization: DPoP and binds it to a request with the same proof fields used for a DPoP access token.
  • Wire equivalence is not semantic equivalence. A verifier must distinguish Credential from access token through trusted iss and accepted typ, then apply different audience and status rules.
  • A valid proof establishes possession for one request. It does not supply a missing issuer audience, make all claims appropriate for every verifier, grant resource authority or prove the operation succeeded.

One slot, two meanings

The proposal starts from a practical observation. OAuth resource servers already know how to receive a sender-constrained value: one header carries the value, another carries a signed DPoP proof. Instead of creating a new presentation envelope for software-to-software credentials, revision 01 places the Credential in the token slot:

Authorization: DPoP <Credential>

DPoP: <proof JWT>

The Holder signs htu, htm, iat, jti, an optional required nonce and ath. The ath calculation does not acquire a new meaning or encoding rule; it hashes the US-ASCII bytes of the Credential exactly as received. The resource server checks the proof signature and freshness, recomputes that hash and matches the proof key to cnf.jkt or the thumbprint of cnf.jwk.

Those checks can all pass while the verifier still has not answered the decisive question: what kind of object occupied the slot? RFC 9068's JWT access-token profile requires an audience and uses at+jwt. This draft requires a deployment-defined Credential type that must not be at+jwt or an ID-token type. A server that accepts both forms must branch on trusted iss and typ. If it merely sees valid DPoP, it can apply the wrong trust model to perfectly well-formed bytes.

The request is not the audience

DPoP makes a strong, narrow statement. The holder of the confirmed private key produced a fresh proof for a method and URI, and bound that proof to the presented value. That is request-level possession. It is not an issuer decision about every recipient allowed to consume a reusable Credential.

In the proposal, aud is optional. When present, only the Issuer sets it, and the verifier must find its configured identifier there. When absent, the Credential may be presented to every resource server that trusts the Issuer. Choosing a target does not let the Holder manufacture an audience, and matching htu does not narrow the Issuer's original distribution decision.

That distinction turns trust topology into an operating surface. Two services may trust the same identity provider while having very different reasons to accept a claim set. Without aud, both are inside the potential reuse radius. Local authorization can still deny access, but only if the deployment treats Credential validity as an input rather than a verdict.

Long life moves the clock to status

An access token is often made disposable through a short expiry. The proposed Credential may be longer-lived, so a recommended status claim becomes a separate current-state lookup. If status exists, the verifier must check it and reject an invalid result. If a long-lived Credential has no status, local policy may reject it.

The control is not instantaneous. A cached status list creates a measurable revocation delay. A valid signature proves what the Issuer signed; a matching DPoP proof demonstrates current key use; a previously fetched status list reports what that list said at its own freshness boundary. None of those receipts silently updates the others.

The Issuer is deliberately absent from the request path. That reduces latency and limits direct presentation telemetry, but status retrieval can still reveal usage patterns. Cache policy therefore governs both privacy and the time during which a revoked Credential may continue to appear valid.

Whole means whole

This is not a selective-disclosure protocol. The entire JWT goes to every verifier, and its stable signature can correlate presentations across them. Headers can also reach server access logs or intermediaries. TLS protects transit, not an overbroad claim vocabulary or an Authorization header copied into durable logs.

The draft draws the applicability line clearly. Use this shape when software already knows the target, knows which Credential the target accepts and needs no person or verifier-driven negotiation at presentation time. Use a presentation protocol such as OpenID4VP when claims must be discovered, selected or consented to. An SD-JWT VC fits this proposal only as its issuer-signed JWT without disclosures.

Lu Heng's Minimum Initial Specification is useful here because the proposal reuses a small common mechanism without pretending to settle every future policy. Running-Code Primacy then asks for the evidence the deployed verifier actually produced: accepted type, trusted Issuer, audience branch, status age, authorization version and observed operation. The reality layers remain separate even when the two headers are identical.

Sources and limits

The sources establish a proposed model, not working-group adoption, IETF consensus, an RFC, implementation, interoperability, AI-agent deployment, a credential issuance or revocation event, an authorization decision or a service result. The prior RFC 9449 Article retains the generic sender-constraint thesis; this Article owns only the same-wire/different-authority fork in revision 01.