wimse W. Jackson Internet-Draft 21 September 2026 Intended status: Informational Expires: 25 March 2027 Verifier-Side Evaluation Semantics for Delegated Authority Chains draft-jackson-wimse-evaluation-00 Abstract Delegation chain specifications describe the shape of conveyed authority. They leave the verifier's half of the exchange underdetermined. Two verifiers can check the same chain, both report success, and enforce different policy. This document states what a verifier MUST do: the explicit inputs evaluation depends on, and four rules that keep evaluation fail-closed. The rules are drawn from shipped specification text ([GAL] 0.2.6-draft, [PTC] 0.2.5-draft) and a public reference implementation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Jackson Expires 25 March 2027 [Page 1] Internet-Draft WIMSE Verifier Evaluation Semantics September 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Evaluation Inputs . . . . . . . . . . . . . . . . . . . . . . 4 3.1. The Frozen Call . . . . . . . . . . . . . . . . . . . . . 4 3.2. The Evaluation Instant . . . . . . . . . . . . . . . . . 4 3.3. The On-Behalf-Of Principal . . . . . . . . . . . . . . . 4 3.4. Issuer and Evaluator Keys . . . . . . . . . . . . . . . . 4 4. Evaluation Rules . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Process Every Entry or Reject . . . . . . . . . . . . . . 5 4.2. Fail Closed Per Path . . . . . . . . . . . . . . . . . . 5 4.3. Consumption Keyed to the Frozen Call . . . . . . . . . . 5 4.4. Verify Records Under Role-Separated Keys . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction A delegation chain is a claim about authority. A verifier turns that claim into a decision. Chain formats standardize the claim. This document standardizes the decision. The failure this prevents is silent divergence. A verifier that drops an authorization entry it cannot parse and still approves has enforced nothing while reporting success. A verifier that derives "now" from the records it is judging keeps expired authority alive during quiet periods. A verifier that lets one broken path poison a valid one hands any attacker a veto over legitimate authority. Each of these was observed in running code during WIMSE implementation work. Each is fixed here with a stated rule. Jackson Expires 25 March 2027 [Page 2] Internet-Draft WIMSE Verifier Evaluation Semantics September 2026 This document does not define a chain format, a token envelope, or a policy language. It defines the evaluation function those formats are judged by. It is complementary to chain-format documents such as [DELEGATION-CHAIN] and [CONNECTED-FLIGHT]: those define what is conveyed, this defines how the receiver judges it. The rules in Section 4 are implemented in the public reference implementation [RI]. The key-bootstrapping mechanism discussed in Section 5 is the known open item; it is named as a gap rather than specified. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. _Frozen call:_ the exact action a human was shown and approved: capability, arguments, recipient, and principal, as presented at approval time. _Evaluation instant:_ the instant against which validity, including expiry, is judged. _On-behalf-of principal:_ the principal the chain acts under, distinct from the agent acting at each hop. _Principal:_ the identity tuple a grant is issued to: agent identity, skill, user, and trust tier. The unit of authority is the (principal, action class) pair. The five attributes together name who acts, in what capacity, on whose behalf, at what trust, and over what class of action. The semantics of the trust tier are deployment-defined; this document standardizes the tier's position in the tuple, not its values. _Issuer key:_ the key that signs authority-raising records. _Evaluator key:_ the key that signs authority-lowering records, held by a deliberately separate identity. _Delegation path:_ one chain of delegations from a root of trust to the acting agent. Jackson Expires 25 March 2027 [Page 3] Internet-Draft WIMSE Verifier Evaluation Semantics September 2026 3. Evaluation Inputs A verifier's decision MUST be a function of explicit inputs. Four inputs are required. Anything the verifier needs that is not in this list MUST be supplied explicitly; the verifier MUST NOT guess. 3.1. The Frozen Call The frozen call is the exact action the human was shown and approved. Evaluation and consumption bind to that call as presented, not to a re-serialization, a paraphrase, or an identifier that names it. (GAL-36, GAL Section 4.1) 3.2. The Evaluation Instant The instant against which validity, including expiry, is judged is an explicit input to evaluation. It MUST NOT be derived from the timestamps of the records under evaluation. Deriving "now" from the latest record keeps expired authority alive through quiet periods, because time passes without producing records. (GAL-34) 3.3. The On-Behalf-Of Principal Conveyed evaluation material MUST include the on-behalf-of principal. A verifier that does not share the issuer's log cannot recover the principal from the action chain, so material that omits it authenticates an action without saying whom it was taken for. ([PTC] Section 6.6) Evaluation is against the whole tuple, never the agent identity alone: a verifier that matches on agent identity while ignoring skill, user, or tier has evaluated a different grant. (GAL-36, [GAL] Section 5.1) 3.4. Issuer and Evaluator Keys Authority-raising records (issuance, promotion, tightening) are signed by the issuer key. Authority-lowering records (demotion, lapse) are written by a deliberately separate evaluator identity and signed by the evaluator key. No identity SHALL hold both roles' signing keys. The separation is structural, not conventional: a grant-store write the agent can reach is a promotion bypass. (GAL- 37, [GAL] Section 6.7.2, [GAL] Section 6.10) 4. Evaluation Rules Jackson Expires 25 March 2027 [Page 4] Internet-Draft WIMSE Verifier Evaluation Semantics September 2026 4.1. Process Every Entry or Reject A verifier MUST process every authorization_details entry [RFC9396] presented or reject the token. An entry of a type the verifier cannot evaluate is an entry it cannot process, and the token MUST be rejected. A verifier that silently drops an entry enforces an incomplete policy while reporting success. That is fail-open. (Aligned with the -02 direction of [DELEGATION-CHAIN]. A verifier advertises the types it supports with authorization_details_types_supported [RFC9728].) 4.2. Fail Closed Per Path Where several delegation paths reach the same agent, the verifier MUST evaluate each path independently along its whole length. One fully valid path suffices for authority. A broken path MUST NOT neutralize a valid one, and a valid path MUST NOT excuse a broken one. Discovering which paths exist is the delegation mechanism's work; judging each presented path is the verifier's. ([GAL] 0.2.5 changelog: lifecycle, which the grant standard owns, separated from path resolution, which it does not.) 4.3. Consumption Keyed to the Frozen Call An approval MUST be consumed only by release or rejection of the frozen call it binds, by the whole principal the call was frozen for. Consumption MUST NOT be inferred from the approval's identifier appearing in any record. Otherwise any party able to write a record can burn another party's approval without using it. The release executes the stored call and nothing re-sent. (GAL-36, [GAL] Section 4.1) This document does not standardize approval interaction. It standardizes what the verifier must check about consumption. 4.4. Verify Records Under Role-Separated Keys A verifier MUST select the acceptable signing keys from the record type, MUST refuse a record signed by the other role's key, and MUST refuse a key resolvable under both roles. The key that grants authority MUST NOT be the key that judges it. (GAL-37) Jackson Expires 25 March 2027 [Page 5] Internet-Draft WIMSE Verifier Evaluation Semantics September 2026 5. Security Considerations Clock skew: the evaluation instant is supplied by the evaluating party as an explicit input. When two parties do not share a clock, the party evaluating supplies the instant. The clock source and the skew bound are deployment details, and stating them is REQUIRED: a deployment MUST document which clock supplies the evaluation instant and the maximum skew it tolerates. This document sets no default bound. Key bootstrapping across boundaries: a receiving verifier needs the sending boundary's issuer key before any rule in Section 4 can run. Open issue: the mechanism by which the verifier obtains the sending boundary's issuer key is not specified in this document. The reference implementation resolves keys out of band. This document requires only that the verifier possess the key before any rule in Section 4 runs; the provisioning mechanism is left for the working group. This is the open question put to the WIMSE list alongside this draft. Structural separation: the agent MUST NOT hold signing keys and MUST have no write access to the grant store. Verification authenticates lineage; it does not clean taint and does not substitute for the receiver's own trust map. ([GAL] Section 6.7.2, [PTC] Section 6.6, [PTC] Section 6.7) Misconfigured verification, such as a configured but unusable key source, MUST fail closed loudly and MUST NOT silently degrade to no verification. ([PTC] Section 6.7) 6. IANA Considerations This document makes no request of IANA. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Jackson Expires 25 March 2027 [Page 6] Internet-Draft WIMSE Verifier Evaluation Semantics September 2026 [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, September 2023, . [RFC9728] Jones, M. and T. Lodderstedt, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, October 2024, . 7.2. Informative References [GAL] Jackson, W., "Grant Authority Ledger (GAL) Specification", version 0.2.6-draft, 2026, . [PTC] Jackson, W., "Policy Trust Chain (PTC) Specification", version 0.2.5-draft, 2026, . [RI] wjatx, "ptc-gal-reference", Public reference implementation of GAL and PTC; the code this document's rules are drawn from, . [DELEGATION-CHAIN] Asor, R., "Verifiable Attenuated Delegation Chains for AI Agents", Work in Progress, Internet-Draft, draft-asor- wimse-agent-delegation-chain-01, . [CONNECTED-FLIGHT] Seymour, E., "Connected Flight: A Model for Cross-Tenant Delegation", Work in Progress, Internet-Draft, draft- seymour-wimse-connected-flight-00, . Author's Address Wes Jackson Email: c.wesjackson@gmail.com Author's Address Wes Jackson Email: c.wesjackson@gmail.com Jackson Expires 25 March 2027 [Page 7]