Summary

  • Version -02 of an individual verifier-evaluation draft says an unsupported authorization-details entry must cause refusal of the presented token, not disappear while the rest is approved.
  • The same revision proposes that the caller recognize a refusal that cannot be fixed by retrying that token, without learning which entry, path or grant failed. A detailed reason belongs with the operator, not in the cross-domain response.

An agent presents a token with several authorization entries. One entry has a type the receiving verifier cannot evaluate. Silently discarding it would make the response look like an approval of the entire request even though a piece of requested authority was never checked. Refusing the token is straightforward. Deciding what to say about that refusal is not. If the caller receives only an undifferentiated transient-looking failure, it may resend the same bytes repeatedly. If it receives a map of the failed grant, it may learn more about another organization's delegation state than it was entitled to know.

That is the narrow but consequential change in Wes Jackson's Verifier-Side Evaluation Semantics for Delegated Authority Chains, revision -02, dated 29 September 2026. The IETF Datatracker lists it as an active individual Internet-Draft in I-D Exists state, with no standards stream. It is not a WIMSE working-group adoption, an RFC or evidence of a deployed protocol. The prior -01 version titled its first rule “Process Every Entry or Reject.” The new revision uses “Refuse” for the verifier's disposition, distinguishing it from an approver's terminal rejection of a held call. These are distinct decisions at different boundaries, not cosmetic synonyms.

Under the author's Section 4.1 proposal, a verifier processes every presented authorization_details entry or refuses the token. A type it cannot evaluate is not an invitation to ignore that entry and approve the rest. The text calls refusal permanent for the presented token: sending the same token again cannot add support for the missing type. That is a bounded claim. It does not say a caller can never obtain a different credential or that every failed request has the same remedy.

Section 5 then gives the refusal two audiences. The caller should, where the transport permits, be able to distinguish that this very token cannot succeed on retry. The caller need not learn the name of the failed authorization entry, the failed delegation path or the state of a parent grant. Exposing those details would let an external participant probe the verifier as an oracle for a private authority graph. The draft permits disclosure of verifier properties it already publishes, such as supported authorization-detail types, while directing the evaluation-specific reason into the verifier's audit record for its operator.

The practical design is a coarse external outcome paired with a precise, access-controlled internal explanation; that pairing is Daniel Kade's operational framing, not a new prescribed receipt format.

Existing OAuth codes illustrate why this boundary cannot be solved by pasting one error string everywhere. RFC 9396 Section 5 defines invalid_authorization_details for an authorization server handling unknown or malformed authorization details; its registration is for authorization and token endpoints. RFC 6750 defines invalid_token for a bearer-token resource server; there, a client may request a new access token and retry. Jackson's draft cites those contexts but registers no code and defines no response format. “Permanent” describes repeating the same presented token under the relevant refusal, not an unconditional ban on a new-token attempt. Which signal can be sent without leaking grant state is a question for the actual transport and trust boundary.

Nothing in the public draft proves that sites are currently leaking delegation paths, that agents are generating a measurable retry storm or that all verifiers implement the proposed rule. The reference implementation notes in the document are selective: it does not consume authorization_details entries or exercise a derived-grant path. The news is a proposal that makes an often-overlooked design conflict explicit. Refusal must be final enough to stop a useless loop, yet quiet enough not to become an inventory service for another party's authority.

Sources