Summary

  • Revision 01 of an individual OAuth authorization-evidence Internet-Draft signs only the evidence id and the entire user_confirmation: the exact display, recorded action and timestamp.
  • The adjacent audit_trail is deliberately excluded even though it is meant to explain how intent became authorized operations. Our local construction changed that trail while leaving the specified signature input identical.
  • An intact signed JWT still protects the whole embedded token. The portability gap matters most after evidence is returned from an opaque-token endpoint, where TLS protects retrieval but does not enlarge the detached signature.

One confirmation, two incompatible expansions

Consider a user shown this sentence: “Buy cheap headphones.” The authorization server records the display, the confirmation action and the time. One evidence object labels the semantic expansion medium and points to a proposal capped at $50. A second preserves the same confirmation but labels the expansion high and points to a proposal capped at $500.

Those are not equivalent operating instructions. Yet Section 3.6 of draft-liu-oauth-authorization-evidence-01 tells an implementation to build a fresh JSON object containing only id and user_confirmation, canonicalize it with RFC 8785 JCS, and sign those bytes as a detached JWS. Extension fields beyond id, user_confirmation and as_signature must not be included. The audit_trail sits outside that input by rule, not by accident.

Our local reproduction instantiated the two objects. Their complete canonical representations and SHA-256 hashes differed. Their Section 3.6 projections were identical, with SHA-256 aec26fa5351ab57f144fd6b387b297969f73e34ec3ea5a557592a0b2d3a7b512. This is a construction-level observation only. It does not validate the draft's abbreviated JWS, demonstrate an exploit, accuse an authorization server, or show a real transaction.

The useful question is therefore not whether the signature verifies. It is: which proposition did the signature make portable?

The signed proposition is precise and limited

The draft's core structure requires an evidence identifier, a user_confirmation object and an authorization-server signature. The confirmation contains the exact displayed content, a description of the user's action and a NumericDate timestamp. Verification can establish that those bytes belong to the record the authorization server signed.

That is valuable. It prevents later prose from quietly replacing the sentence that was shown. But the draft itself draws the trust boundary carefully: the signature proves that the authorization server recorded a confirmation. It does not independently prove the person actually consented. The server controls the interaction and the signing key; stronger non-repudiation needs a user-side signature or independent audit.

Nor is confirmation an execution receipt. The resource server logs the evidence identifier, confirmation time and display summary separately from the operation performed and its success or failure. A valid confirmation can coexist with a denied request, a changed runtime context, a failed tool call or an external outcome that never occurred.

The explanation sits in an optional neighbour

Section 4 gives audit_trail the job of semantic traceability: explaining how user intent was interpreted and translated into authorized operations. It can carry an evidence reference, an expansion level and a proposal_ref. The four labels range from no expansion to a broad goal expanded into a multi-step plan. They are classifications, not machine-readable diffs.

The proposal reference is more consequential than its compact syntax suggests. It is an opaque URI assigned by the authorization server, intended to identify the proposal before policy evaluation, scope reduction or consent modification. Revision 01 defines no retrieval protocol, content hash, retention period or access rule for the referenced proposal. A later auditor may possess a valid confirmation and still be unable to recover the precise transformation dossier.

This is not proof of a vulnerability. It is an unfilled portability contract. A deployment can retain the proposal immutably, sign a larger envelope or bind a response to a durable record. The draft does not require those choices here.

Carrier choice changes what survives extraction

When the evidence remains inside an RFC 9068 signed JWT access token, the outer token signature covers the complete embedded token-level object, including its audit trail. Altering the trail inside that intact token would break the outer signature. The narrower inner signature does not erase that protection.

Opaque access tokens create a different evidence journey. A resource server obtains metadata through RFC 7662 introspection or a dedicated endpoint. The draft calls as_signature the sole integrity protection for the evidence record in that case and requires TLS. TLS authenticates and protects the live retrieval channel. Once the evidence object is extracted, stored or forwarded, TLS is no longer a portable signature over the adjacent audit metadata. The detached JWS still covers only the confirmation projection.

Introspection also answers a current authorization question. Its active result is authorization-server dependent, responses may vary by resource server, and caching trades freshness for load. It is not automatically a durable receipt for how a sentence became a resolved operation.

Policy and evidence answer different questions

The companion Rego-policy draft makes the separation visible. Authorization evidence records why an operation was authorized; a sibling rego_policy object defines what an agent may do and what the resource server evaluates. The inner evidence signature does not bind that sibling policy's URI, entry point or evaluation inputs. Again, an intact outer JWT can bind the combined representation. An opaque-token system needs its own accountable retrieval and retention design.

This is a reality-layer problem. Display, server-recorded confirmation, interpretation metadata, policy evaluation, resource-server decision, dispatch, execution and external effect are different records. Collapsing them into the word “authorized” transfers authority to whichever component supplies the missing interpretation later.

A portable interpretation passport

For consequential agent actions, the missing bridge should be explicit. An interpretation passport could bind the evidence and confirmation identifiers; display hash and locale; immutable proposal bytes or hash; resolved operation and constraints; semantic diff and the component that produced it; policy identifier, hash, entry point and inputs; issuer, audience, subject, agent, client and expiry; resource-server decision; dispatched operation hash; execution receipt; and separately observed outcome.

That proposal is Daniel Kade's analysis, not a requirement in revision 01. Sensitive material need not be copied into every token. Hash-bound, access-controlled records can preserve the transformation while keeping the common layer small. The minimum specification is not “store everything.” It is “name enough immutable objects that another authorized party can reconstruct the decision.”

Sources and limits

The observations were frozen on 30 September 2026 Asia/Shanghai. Revision 01 is an active individual Internet-Draft, not an RFC, OAuth working-group consensus or evidence of adoption. The local reproduction establishes only the specified signature projection. It does not establish broken JWS or JCS, malicious conduct, an implementation defect, in-transit modification, operational loss or any completed action. The draft may change, be replaced or expire.