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

wimse                                                         W. Jackson
Internet-Draft                                         23 September 2026
Intended status: Informational                                          
Expires: 27 March 2027

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

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 the
   Grant & Autonomy Lifecycle (GAL) and Provenance & Trust Context (PTC)
   specifications and from 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 27 March 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Jackson                   Expires 27 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 . . . . . . . . . . . . . . . .   5
   4.  Evaluation Rules  . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Process Every Entry or Reject . . . . . . . . . . . . . .   5
     4.2.  Fail Closed Per Path  . . . . . . . . . . . . . . . . . .   5
     4.3.  Consumption Keyed to the Frozen Call  . . . . . . . . . .   6
     4.4.  Verify Records Under Role-Separated Keys  . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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 27 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.

   [CONNECTED-FLIGHT] Section 4.1 records that its token profiles were
   designed to be evaluable under the rules in Section 4 without
   modification; this document does not restate those profiles, which
   are that document's contribution.

   Two of the rules in Section 4 are exercised in the public reference
   implementation [RI]: consumption keyed to the frozen call, and
   verification under role-separated keys.  The other two are not.  That
   implementation consumes no [RFC9396] authorization_details entries,
   and it has no derived-grant concept, so no call reaches it by a path;
   the lifecycle half of the per-path rule rests on GAL-39, which [GAL]
   marks normative and not yet implemented there.  A rule's force comes
   from the specification that states it, and these notes record what
   has been exercised.  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.  Those four attributes and the action
   class 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.

Jackson                   Expires 27 March 2027                 [Page 3]
Internet-Draft     WIMSE Verifier Evaluation Semantics    September 2026

   _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.

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 does 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)

Jackson                   Expires 27 March 2027                 [Page 4]
Internet-Draft     WIMSE Verifier Evaluation Semantics    September 2026

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.  An identity MUST NOT 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

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.  (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.

   The lifecycle half of this rule is stated normatively in [GAL] as
   GAL-39: a derived grant does not outlive or out-rank the grant it
   derives from, and where a grant is demoted or lapses, every derived
   grant descending from it ceases to confer authority from that
   evaluation instant, whether or not a record of the change has been
   written.  [GAL] Section 1.3 separates that half, which the grant
   standard owns, from path resolution, which it does not.  The scope
   half, that one fully valid path suffices and a broken path never
   neutralizes a valid one, is this document's.

Jackson                   Expires 27 March 2027                 [Page 5]
Internet-Draft     WIMSE Verifier Evaluation Semantics    September 2026

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 is never the key that judges it.  (GAL-37)

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 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
   NOT have 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)

Jackson                   Expires 27 March 2027                 [Page 6]
Internet-Draft     WIMSE Verifier Evaluation Semantics    September 2026

   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>.

   [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., "GAL: Grant & Autonomy Lifecycle,
              Specification", version 0.2.9-draft, 2026,
              <https://github.com/wjatx/ptc-gal-standards/blob/main/GAL-
              SPEC.md>.

   [PTC]      Jackson, W., "PTC: Provenance & Trust Context,
              Specification", version 0.2.7-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>.

Jackson                   Expires 27 March 2027                 [Page 7]
Internet-Draft     WIMSE Verifier Evaluation Semantics    September 2026

   [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-02,
              <https://datatracker.ietf.org/doc/html/draft-seymour-
              wimse-connected-flight-02>.

Acknowledgements

   This document was prepared with AI assistance for drafting, source
   verification and editorial review.  The technical positions are the
   author's.

Author's Address

   Wes Jackson

   Email: c.wesjackson@gmail.com

Author's Address

   Wes Jackson
   Email: c.wesjackson@gmail.com

Jackson                   Expires 27 March 2027                 [Page 8]