Verifier-Side Evaluation Semantics for Delegated Authority Chains
draft-jackson-wimse-evaluation-00

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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

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,
              <https://www.rfc-editor.org/rfc/rfc9396>.

   [RFC9728]  Jones, M. and T. Lodderstedt, "OAuth 2.0 Protected
              Resource Metadata", RFC 9728, DOI 10.17487/RFC9728,
              October 2024, <https://www.rfc-editor.org/rfc/rfc9728>.

7.2.  Informative References

   [GAL]      Jackson, W., "Grant Authority Ledger (GAL) Specification",
              version 0.2.6-draft, 2026, <https://github.com/wjatx/ptc-
              gal-standards/blob/main/GAL-SPEC.md>.

   [PTC]      Jackson, W., "Policy Trust Chain (PTC) Specification",
              version 0.2.5-draft, 2026, <https://github.com/wjatx/ptc-
              gal-standards/blob/main/PTC-SPEC.md>.

   [RI]       wjatx, "ptc-gal-reference", Public reference
              implementation of GAL and PTC; the code this document's
              rules are drawn from,
              <https://github.com/wjatx/ptc-gal-reference>.

   [DELEGATION-CHAIN]
              Asor, R., "Verifiable Attenuated Delegation Chains for AI
              Agents", Work in Progress, Internet-Draft, draft-asor-
              wimse-agent-delegation-chain-01,
              <https://datatracker.ietf.org/doc/html/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,
              <https://datatracker.ietf.org/doc/html/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]