Verifier-Side Evaluation Semantics for Delegated Authority Chains
draft-jackson-wimse-evaluation-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Wes Jackson | ||
| Last updated | 2026-10-10 (Latest revision 2026-09-30) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jackson-wimse-evaluation-04
wimse W. Jackson
Internet-Draft 10 October 2026
Intended status: Informational
Expires: 13 April 2027
Verifier-Side Evaluation Semantics for Delegated Authority Chains
draft-jackson-wimse-evaluation-04
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, how
those inputs behave when their sources are stale or unavailable, 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 13 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Jackson Expires 13 April 2027 [Page 1]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Evaluation Inputs . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Frozen Call . . . . . . . . . . . . . . . . . . . . . 7
3.2. The Evaluation Instant . . . . . . . . . . . . . . . . . 7
3.3. The On-Behalf-Of Principal . . . . . . . . . . . . . . . 8
3.4. Issuer and Evaluator Keys . . . . . . . . . . . . . . . . 9
3.5. Issuer Standing . . . . . . . . . . . . . . . . . . . . . 9
4. Evaluation Rules . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Process Every Entry or Refuse . . . . . . . . . . . . . . 11
4.2. Fail Closed Per Path . . . . . . . . . . . . . . . . . . 11
4.3. Consumption Keyed to the Frozen Call . . . . . . . . . . 11
4.4. Verify Records Under Role-Separated Keys . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Conformance Cases . . . . . . . . . . . . . . . . . 20
A.1. An Approval at Its Expiry . . . . . . . . . . . . . . . . 20
A.2. Records Under a Valid Signature . . . . . . . . . . . . . 21
A.3. The Age of a Fetched Input . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
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 13 April 2027 [Page 2]
Internet-Draft WIMSE Verifier Evaluation Semantics October 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 verifier specified here is deterministic. Its decision is a
function of the inputs in Section 3, with no model and no judgment of
content anywhere in it. In the terms of [PTC] it is the receiving
boundary, which that specification calls the airlock: one party's
enforcement point presents to another party's airlock, and how the
receiver classifies the sender is the receiver's own deterministic
decision ([PTC] Section 6.1). It is never a claim carried in the
message and never the sending agent's to make.
[CONNECTED-FLIGHT] Section 4.1 maps its credentials onto the inputs
in Section 3 and the rules in Section 4. It records the consumption
rule of Section 4.3 as only partially addressed by those credentials,
since scope and expiry bound a credential's validity without making
it single-use. This document does not restate those profiles, which
are that document's contribution.
This document is the verifier-side counterpart to executor-side work.
[AEB] defines the boundary at which an executor admits, consumes
authority for, and classifies the outcome of a consequential action,
and [CAID] defines how two representations of one action are
compared. Where a rule here needs those mechanisms, it states the
property and points to them rather than defining its own.
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.
Several requirements here are stated ahead of that implementation.
Issuer standing (Section 3.5), the direction in which clock skew is
applied (Section 3.2), and the as-of time and maximum age of a
fetched input (Section 3) are clauses of [GAL] (GAL-41, GAL-42, GAL-
43) and of [PTC] (PTC-49, PTC-50), and each is marked there as not
yet implemented. So is the caller-facing classification of a refusal
(Section 5, PTC-44). Of what this revision adds to the fourth rule
(Section 4.4), [GAL] marks continuity for records the issuer signs as
not yet implemented. This document states each of these rules and
Jackson Expires 13 April 2027 [Page 3]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
makes no claim that the reference implementation demonstrates them.
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, principal, and the authority the
call was evaluated under, as presented at approval time.
_Authorization instance:_ one approval bound to one frozen call, from
the moment the call is held until a terminal disposition closes it.
_Refuse:_ what a verifier does to a token or record that fails
evaluation under Section 4. A refusal is the verifier's decision and
involves no human.
_Reject:_ what an approver does to a held frozen call as a terminal
disposition. A rejection closes the authorization instance without
executing the call. The expiry of an approval is not a rejection
(Section 4.3).
_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.
_Level:_ the position a grant holds on an ordered scale of autonomy.
[GAL] Section 4.1 defines one such scale.
_Record:_ a signed statement of one write to a grant.
Jackson Expires 13 April 2027 [Page 4]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
_Ledger:_ the append-only sequence of records for one (principal,
action class) pair.
_Issuer key:_ the key that signs the records an issuing ceremony
writes. Those records raise a level (issuance, promotion), lower it
voluntarily (tightening), or re-issue a grant at the level it already
holds (re-attestation). It is the only key under which a level is
raised.
_Evaluator key:_ the key that signs the records the automatic
evaluator writes (demotion, lapse), which may only lower a level. It
is held by a deliberately separate identity.
_As-of time:_ the instant as of which a verifier established an input
it fetched from a source. It is the instant the verifier obtained
the input from the source, or, where the source states when the input
was current, the earlier of that time and the instant the verifier
obtained it. Taking the earlier of the two resolves doubt toward
less authority: a replayed answer carries its old time and ages out,
and a source whose clock runs fast cannot make its answer look
fresher than the moment it was fetched. (GAL-43, PTC-50)
_Maximum age:_ the longest interval after its as-of time for which a
fetched input may be used, pinned by the relying party for each
input. The as-of time plus the maximum age is the input's horizon.
_Delegation path:_ one chain of delegations from a root of trust to
the acting agent.
_Issuer standing:_ whether the party an issuer key speaks for still
holds the role it issued under.
3. Evaluation Inputs
A verifier's decision MUST be a function of explicit inputs. Five
inputs are required. Anything the verifier needs that is not in this
list MUST be supplied explicitly; the verifier does not guess.
Some inputs come from sources the verifier does not control: status,
keys, and records. Each fails in a direction. An input that confers
authority only while fresh, such as a short-lived grant, fails toward
less authority when its source is unavailable, because nothing renews
it. An input that removes authority, such as a revocation entry or a
demotion record, fails toward more, because its absence reads the
same as good news. That property is what makes a lease [LEASES] safe
under failure. The requirements in this section are written so that
every fetched input fails toward less authority.
Jackson Expires 13 April 2027 [Page 5]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
A verifier MUST NOT accept a status assertion, key set, or record set
from a source after it has accepted a later one from the same source,
where "later" is by that source's own ordering, such as a sequence
number or an issuance time. Otherwise an attacker who can replay an
earlier signed response restores a key or an issuer that the source
has since withdrawn.
Every fetched input also has an age. For each input a decision
depended on that was fetched from a source, the verifier MUST record
the input's as-of time. A verifier MUST NOT use a fetched input at
an evaluation instant at or past its horizon, which is its as-of time
plus the maximum age the relying party pins for it. Past the horizon
the input is not established. The verifier obtains it again, or
treats it as unavailable, and an evaluation that needs an unavailable
input ends in a transient refusal (Section 5). Without a maximum
age, an input that was true when fetched stays in force for as long
as the process that fetched it keeps running, so a key withdrawn or a
standing lost after the fetch is still honored. Without a recorded
as-of time, a later reader of the decision cannot tell one made on
current inputs from one made on stale ones. (GAL-43, [GAL]
Section 6.15; PTC-50, [PTC] Section 6.13)
Each input is judged on its own horizon. A decision that depended on
several fetched inputs holds only while every one of them is inside
its maximum age, and the as-of times are recorded per input, never as
one time for the decision. The decision does have a horizon of its
own, which is the earliest of its inputs' horizons: a decision is
good no longer than its shortest-lived input. A verifier MUST record
that instant, and a decision MUST NOT be relied on past it. A call
held on the decision, or carried on from it to another party, is
evaluated again. Otherwise a call is permitted and held, the key
that verified its chain is withdrawn while it waits, and the hold is
released on the strength of the earlier decision: every input was in
date when it was read, and the action still runs on a withdrawn key.
A record that keeps a resolved input without its horizon cannot
separate a live admission from one that outlived its window. The
horizon is a validity condition judged at the evaluation instant
(Section 3.2), in the way an expiry is. Passing it is not a refusal
by the source and is not evidence that the input changed. The as-of
time and the maximum age are properties of how the inputs below are
held; they are not a sixth input. How a record encodes them belongs
to the record format, for which see [AUDIT-RECORD]. This document
defines no encoding.
Jackson Expires 13 April 2027 [Page 6]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
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)
"As presented" needs a basis for comparison once the same action can
arrive in more than one representation; otherwise two artifacts
describing one action carry digests that cannot be compared without
guessing. A verifier MUST compare a candidate call to the frozen
call over the material fields declared for the action's type, under a
canonicalization or mapping profile pinned by the relying party. It
MUST NOT infer equivalence from field names, descriptions, or
identifiers, and a comparison the pinned profile cannot make is a
mismatch. [CAID] supplies both halves: action types that declare
their material fields (Section 4.2), and an Action-Mapping Profile
that the relying party pins and that yields INDETERMINATE, never a
match, when the mapping would lose or cannot cover a material field
(Section 8). This document requires the property and does not define
a canonicalization of its own.
The authority a call runs under is part of what the approver
approved. An approval covers the visible coordinates of the call
under the authority shown at approval time, so two calls with the
same visible fields under different authority are different calls. A
release that runs under a different delegation than the one shown
breaks what-you-see-is-what-you-execute even when every other
coordinate matches. A verifier MUST be able to verify that the
authority under which a call is released is equivalent to the
authority approved. This document does not prescribe whether that
equivalence is carried explicitly with the approval or reconstructed
from immutable records of the frozen call.
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)
The instant MUST come from a clock the verifier trusts and MUST NOT
be taken from data the presenter controls. A presenter that supplies
the instant chooses which grants are live. The verifier's own clock
is also an attack surface: set back, it revives expired authority;
set forward, it refuses everything. Authenticated time, such as
Network Time Security [RFC8915], narrows that attack.
Jackson Expires 13 April 2027 [Page 7]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
When the verifier compares the instant with a time asserted under
another party's clock, it MUST apply the skew bound (Section 5) in
the direction that confers less authority. An expiry or a term, and
an authority-lowering record such as a demotion, a lapse, or a
withdrawal of issuer standing, is treated as effective up to the
bound earlier. An authority-raising record, and a not-before time,
is treated as effective up to the bound later. A symmetric leeway
lets skew extend authority past the point where it ended, and whoever
benefits from a slow clock gets that window for nothing. (GAL-42,
[GAL] Section 6.7.6; PTC-49, [PTC] Section 6.13)
A record carries more than one time, so which one the verifier
compares needs stating. A record's timestamp is the instant its
writer appended it, and nothing else. The instant a transition took
effect is taken from the record's own typed field for that instant
where the record type has one, and never from the timestamp. A lapse
is the case that matters. Authority fell when the grant's term
expired, and the lapse record is written at or after that instant,
possibly much later. The effective instant of a lapse is the expired
term, which the grant carries and the lapse record may carry beside
its timestamp. A verifier MUST NOT infer from a record's timestamp
the time of any event the record does not carry as a field of its
own. A verifier that reads a lapse record's timestamp as the moment
of the lapse honors the grant for the interval between the term and
the write, and a verifier that waits for the record honors it until
somebody writes one. (GAL-34, GAL-40, [GAL] Section 5.2, [GAL]
Section 6.7.6)
Expiry is a validity condition judged at the evaluation instant: an
approval, a grant, or a term has expired when the instant is at or
after the time it states. Expiry is never a disposition, and it is
never the approver's rejection (Section 4.3).
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 13 April 2027 [Page 8]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
A party that assigns an identifier used in the tuple, or an
identifier for an issuer, MUST NOT reassign it to a different
subject. The relying party MUST pin, for each identifier namespace
it joins on, an assigning party that meets this requirement.
Standing, lapse, and audit records join to a chain by identifier.
Where an identifier can be reassigned, a check of a departed issuer's
standing returns the standing of whoever holds the identifier now.
The subject identifier of [OIDC-CORE] Section 2 carries the same
requirement.
3.4. Issuer and Evaluator Keys
Records are signed under one of two roles, and a record's type names
its role. The issuer key signs the records an issuing ceremony
writes: issuance and promotion, which raise a level; tightening,
which lowers one voluntarily; and re-attestation, which re-issues a
grant at the level it already holds after the declared bounds the
grant is bound to have changed. The evaluator key signs the records
the automatic evaluator writes, demotion and lapse, which may only
lower a level. The evaluator is a deliberately separate identity.
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.
The two roles divide records by who writes them, and the direction of
the change does not decide the role. Every record that raises a
level is signed by the issuer key. Two kinds of issuer-signed record
raise nothing: a tightening lowers, and a re-attestation changes no
level at all. (GAL-37, [GAL] Section 4.3, [GAL] Section 6.7.2, [GAL]
Section 6.10)
3.5. Issuer Standing
Whether a chain was valid when issued and whether it is valid when
evaluated are different questions. A chain whose root or
intermediate issuer has been disabled, or has lost the role it issued
under, can carry valid signatures and unexpired grants after its
authority is gone.
A verifier MUST establish the standing of every issuer on a path, at
the evaluation instant, from a source the relying party pins and
within a maximum age the relying party pins. A path through an
issuer whose standing is withdrawn, or cannot be established within
that age, is not fully valid, and Section 4.2 decides the token.
Standing carried only in the presented token MUST NOT be accepted as
its own source.
Jackson Expires 13 April 2027 [Page 9]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
Standing is established by the verifier, at the evaluation instant,
from sources the verifier holds and the relying party has pinned.
The chain supplies the identities of the issuers on the path, and
that is all the standing check takes from it. The check for each
issuer is a lookup made beside the chain against those identities,
and a lookup that cannot complete fails closed the way a timeout
does. Standing therefore needs no claim surface in any chain format.
A chain may name the actor at each hop, as the act claim of [RFC8693]
Section 4.1 does. Those names are attribution: they tell the
verifier which parties acted and confer no standing on any of them.
A statement of standing that a chain does carry is not an input to
this check.
Attribution is attested at each hop and composed afterward. A
verifier records the actor it was presented with and the as-of time
of that observation. It establishes standing for every issuer on the
path at its own evaluation instant. It does not re-derive the
attribution that an upstream verifier attested, and it does not vouch
for it. Reconstructing a chain across hops composes the per-hop
records.
The source is a deployment choice. A status list [STATUS-LIST] or a
directory query satisfies it. So do grant lifetimes no longer than
the pinned maximum age, where each renewal re-establishes the
issuer's standing; that form needs no fetch at evaluation and fails
toward less authority by construction. [DELEGATION-CHAIN]
Section 9.5 describes the window between a withdrawal and a
verifier's next fetch. The pinned maximum age is the bound on that
window.
Standing is the one input that can require a live source at
evaluation time, which is why it is listed rather than left to
deployment.
[GAL] Section 6.10 states the rule for a stored grant (GAL-41): a
verifier establishes that the key which signed the record a grant's
level rests on has not been withdrawn, and a grant whose issuer has
lost standing is enforced at the fallback level the grant itself
declares. That fall belongs to the enforcer inside the grant's own
domain, where the fallback level is known. The same section states
the other case: a verifier in another domain holds no such level for
the grant, because a conveyed chain declares no fallback, so a path
through an issuer without standing confers nothing.
4. Evaluation Rules
Jackson Expires 13 April 2027 [Page 10]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
4.1. Process Every Entry or Refuse
A verifier MUST process every authorization_details entry [RFC9396]
presented or refuse the token. An entry of a type the verifier
cannot evaluate is an entry it cannot process, and the token MUST be
refused. 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].)
Such a refusal is permanent for the presented token: no retry of the
same token can succeed, because the caller cannot change which types
the verifier supports. What the caller is told is stated in
Section 5.
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. Where no presented path is fully valid, the token confers no
authority. 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.
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)
Rejection here means the approver's terminal disposition, the one
that closes the authorization instance. A non-terminal disposition,
such as a deferral or a request for changes, is neither release nor
Jackson Expires 13 April 2027 [Page 11]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
rejection: the approval stays pending and nothing is consumed. Each
authorization instance has at most one consumption event, and it is
the release or the rejection of its frozen call.
This document bounds release and does not bound pending. A held call
confers no authority while it is pending, so an approval that stays
pending without limit fails closed by construction. Where an
approval carries an expiry, the expiry is a validity condition judged
at the evaluation instant (Section 3.2): a release presented at or
after it is refused. Expiry is not a disposition. It consumes
nothing, and it is not the approver's rejection, because the approver
decided nothing. The verifier's record of an expired approval says
that it expired ([PTC] Section 6.12 states the record-side rule as
PTC-53). Whether a pending instance is given a lifetime at all
belongs to the lifecycle of the instance, at the authorization server
or in the grant standard, and this document sets none. Appendix A.1
gives the cases.
Consumption keys on the closure of the authorization instance, never
on the outcome of an execution. Whether a released call executed,
failed, or ended in an indeterminate state is a separate dimension,
which executor-side documents classify ([AEB] Section 5.13). Once a
release has begun execution, an indeterminate outcome MUST NOT return
the approval to pending, because a retry under it could duplicate an
effect that did occur. [AEB] Section 5.11 describes the executor-
side counterpart of this rule, an atomic consume-or-reserve before
invocation.
Where the verifier cannot establish that an approval is unconsumed,
because its consumption state is unavailable, it MUST refuse.
Restoring consumption state from an earlier point MUST NOT make a
consumed approval presentable again. A deployment that restores
either carries the consumed set forward from a source the restore did
not roll back, or refuses every unexpired approval issued before the
restore point. [AEB] Section 10 describes the same effect for a
change of authority namespace, which makes consumed grants look
unused.
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)
Jackson Expires 13 April 2027 [Page 12]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
A signature under the right key says who wrote a record. It does not
say the record is one that writer may write. Two further checks
apply to a correctly signed record, and each closes a way of raising
authority that the key check passes.
Direction: a verifier MUST refuse a record signed under the evaluator
role whose resulting level ranks above its starting level. The
evaluator runs with no human in its path, and its key exists to
lower. A demotion or a lapse that raises a level is authority minted
by the side that must never mint it, and it verifies under the
evaluator key exactly as an honest demotion does. An honest
evaluator writes no such record, so this check only ever meets one
that was planted in the store or written with a stolen evaluator key.
(GAL-17, [GAL] Section 4.3)
Continuity: a verifier that reads a grant's ledger MUST refuse a
record, under either role, that does not start from the level the
ledger held immediately before it. The first record of a ledger
starts from no level. The direction check does not cover this. A
demotion from the highest level to the middle one lowers on its own
terms, and placed on a ledger that stood at the lowest level it
leaves the derived level raised under the evaluator's signature. For
the issuer's records, the ceremony reads the level it moves from, so
a break in continuity marks a record that did not come through the
ceremony, and a promotion that restates its starting level can hide a
skipped step. (GAL-37, [GAL] Section 6.10)
A re-attestation record changes no level. A verifier that derives a
grant's level from its ledger, or that looks for the record a level
rests on, MUST pass over a re-attestation record: the level and the
record that earned it are the ones the ledger held immediately before
it. Without this, two verifiers read one ledger and name different
records as the one that earned the level. The one that names the re-
attestation checks the standing of a different signer (Section 3.5),
and it finds no term on that record, where the promotion carries the
term its ratifier agreed to. ([GAL] Section 4.3, [GAL] Section 6.6)
A grant whose ledger contains a record refused under this section has
no level the verifier can derive. A path through that grant is not
fully valid, and Section 4.2 decides the token.
The level a verifier evaluates a grant at is the level its records
derive. [GAL] Section 6.6 requires that no write to a grant go
unrecorded and that a re-attestation always be signed under the
issuer role (GAL-15), so grant state that no record accounts for is
the trace of a write made outside the ceremony. It is not evidence
of authority. A verifier that holds both a grant and its ledger MUST
evaluate the grant at the lower of the level the grant states and the
Jackson Expires 13 April 2027 [Page 13]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
level its records derive, and MUST record the difference where there
is one ([GAL] Section 6.11). Without this rule, one verifier trusts
the stated level and another the derived one, and the two reach
different decisions on the same evidence, which is the divergence
this document exists to remove.
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; Section 3.2 fixes
the direction in which the bound is applied.
Key bootstrapping across boundaries: a receiving verifier needs the
sending boundary's issuer key before any rule in Section 4 can run.
Open issue: this document does not specify how the verifier comes to
hold the sending boundary's issuer key. That is three questions, and
they are separable:
1. how candidate key material is obtained;
2. how that material is bound to the organization it is claimed for;
and
3. whether the relying party chooses to trust that binding.
A discovery mechanism can answer the first without answering the
second, and a binding that answers the second still leaves the third
to the relying party's own policy. The reference implementation
answers all three at once by provisioning keys out of band, which
requires a prior arrangement with each peer. This document requires
only that the verifier hold a key it has decided to trust before any
rule in Section 4 runs; the mechanism for each question is left for
the working group.
Refusals: a refusal is either permanent for the presented token or
transient. It is permanent when no retry of the same token can
succeed: an unsupported entry type (Section 4.1), a signature that
does not verify, an expired grant or approval, a record refused under
Section 4.4, an issuer whose standing is withdrawn. It is transient
when the verifier could not evaluate because an input it needs was
unavailable: a standing source, a key source, or consumption state.
An input past its maximum age that the verifier could not obtain
again is unavailable in the same sense (Section 3).
Jackson Expires 13 April 2027 [Page 14]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
Toward a caller the verifier authenticated before evaluating, and
that it serves, a refusal MUST be distinguishable as permanent or
transient. A transient refusal reported as permanent stops a caller
whose token would succeed later, and a generic failure is retried at
length. Toward any other caller the verifier MUST NOT make the two
distinguishable. A refusal on the content of a message is not an
outcome of evaluation under this document.
The first requirement was a recommendation in earlier revisions. A
recommendation is how a transient refusal comes to be reported as
permanent in practice, and the harm of that misreport falls on a
caller that did nothing wrong: it abandons a token that would have
succeeded, or it retries a token that never will, which costs both
parties availability. The second requirement exists because of who
else can ask. To a party probing the verifier without being one of
its callers, any difference between two refusals is a map of the
verifier's configuration, and an answer of "transient" reports that
an attack on a key source or a status source is working. [PTC]
Section 6.1 states the same rule for the receiving boundary (PTC-44),
together with the rule this document leaves to it: a refusal on
content looks the same as acceptance to every sender.
Where the transport already defines a code, that code is the one to
use toward a caller the verifier serves. At the authorization
server, [RFC9396] Section 5 defines invalid_authorization_details for
an unknown authorization details type, and [RFC6749] Section 4.1.2.1
defines temporarily_unavailable. A resource server using bearer
tokens has invalid_token [RFC6750] for a permanent refusal, and
status code 503 with a Retry-After field [RFC9110] for a transient
one. This document defines no new code and no response format.
Whether a refusal is permanent or transient describes the verifier's
state, not the caller's chain, so disclosing it to a caller the
verifier serves is consistent with the rule below. The verifier's
own record of a refusal MUST distinguish a token it evaluated and
refused from a token it could not evaluate, and MUST name the input
that was unavailable. Collapsing the two makes every missing input
look like a policy decision to whoever reads the record later.
The record member that carries this distinction is the evaluation
member of [AUDIT-RECORD] Section 5.4, and this document uses that
vocabulary and defines none of its own. A transient refusal is
recorded with a status of not-evaluated and names each unavailable
input from the closed set that document enumerates. A permanent
refusal is recorded with a status of evaluated and a reported
decision of deny. The names this section gives to unavailable inputs
(standing source, key source, consumption state) are members of that
set. The requirement in the preceding paragraph can be checked in a
Jackson Expires 13 April 2027 [Page 15]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
record only because that member exists: without it, the record of a
verifier that lost an input and refused is identical to the record of
a refusal it evaluated. [EVAL-STATE] states the same distinction as
requirements independent of encoding, for agent protocol decisions
beyond verifier evaluation.
The refusal MUST NOT disclose which delegation path or grant failed
evaluation, or the standing of any issuer. A verifier consumes
tokens from another trust domain, and at that boundary an informative
error is an oracle: naming the path that broke, or the parent grant
that lapsed, lets the caller map the delegation graph and enumerate
grant state it cannot otherwise see. The rule is to disclose
properties of the verifier, which are public, and never the evaluated
state of the caller's chain. The detail belongs in the verifier's
audit record, where the operator reads it. A caller may still
believe it holds authority after a grant above it has lapsed; the
verifier does not owe it a correction.
An unsupported entry is a different case. The entry types are in the
caller's own token and the supported types are published
(Section 4.1), so whenever one entry carries a type the verifier does
not advertise, the caller can already tell which entry it was.
Naming that entry discloses nothing further, and this document
neither requires nor forbids it.
Timing carries the same information as content. A verifier that
stops at the first broken path answers sooner for some chains than
for others, and the difference can locate the break. Where chain
state is sensitive, a verifier evaluates every path before it
answers. The same holds for the difference between permanent and
transient toward a caller that is not to learn it: a refusal that
waited on a source answers later than one that did not.
Dependency availability: every source a verifier fetches from is also
a way to stop it. An attacker who can make a standing source, a key
source, or consumption state unavailable turns fail-closed evaluation
into a denial of service for every chain that depends on that source.
This document does not relax fail-closed to avoid that. Whether an
agent that cannot act is the safe outcome depends on what the agent
does, so the response (redundant sources, caching within the pinned
maximum age, alerting) is deployment policy.
Audit availability: where the verifier cannot write its own record,
the detail this section sends there is lost. A deployment MUST
document whether a verifier that cannot write its record continues to
admit.
Jackson Expires 13 April 2027 [Page 16]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
Standing and human presence: issuer standing establishes that an
issuer still holds its role. It does not establish that a human was
present when the issuer key signed; a signature establishes control
of a key ([AEB] Section 10). A deployment that needs to know how the
issuer authenticated carries that separately, for example as the acr
and amr claims of [OIDC-CORE] Section 2.
Key scope: a key the verifier knows is not thereby a key that may
speak for every subject. Which party and which identities a key may
sign for is the verifier's own configuration, established before
evaluation and never taken from the chain. (PTC-46, [PTC]
Section 6.7)
Key custody: a signature shows that a key was used and does not show
where the key is held. A chain looks the same whether or not the
signer's agent can reach the signing key, so what a verifier knows
about custody is a record in its own configuration, and a record its
operator declared is not a check performed on the signer. (PTC-48,
[PTC] Section 7.1)
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)
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 13 April 2027 [Page 17]
Internet-Draft WIMSE Verifier Evaluation Semantics October 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>.
[AUDIT-RECORD]
Gilda, S., "An Audit Record Format for AI Agent
Authorization Decisions", Work in Progress, Internet-
Draft, draft-gilda-wimse-agent-audit-record-02, 4 October
2026, <https://datatracker.ietf.org/doc/html/draft-gilda-
wimse-agent-audit-record-02>.
7.2. Informative References
[GAL] Jackson, W., "GAL: Grant & Autonomy Lifecycle,
Specification", version 0.6.1-draft, 2026,
<https://github.com/wjatx/ptc-gal-standards/blob/main/GAL-
SPEC.md>.
[PTC] Jackson, W., "PTC: Provenance & Trust Context,
Specification", version 0.5.1-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., "Zero Trust Fabric Layer Agent-to-Agent
Chained Trust on a Connected Flight", Work in Progress,
Internet-Draft, draft-seymour-wimse-connected-flight-06, 1
October 2026, <https://datatracker.ietf.org/doc/html/
draft-seymour-wimse-connected-flight-06>.
Jackson Expires 13 April 2027 [Page 18]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
[AEB] Schrock, I., "The Action Evidence Boundary for
Consequential Agent Effects", Work in Progress, Internet-
Draft, draft-schrock-action-evidence-boundary-07, 25
September 2026, <https://datatracker.ietf.org/doc/html/
draft-schrock-action-evidence-boundary-07>.
[CAID] Schrock, I., "The Canonical Action Identifier (CAID)",
Work in Progress, Internet-Draft, draft-schrock-canonical-
action-identifier-05, 2 October 2026,
<https://datatracker.ietf.org/doc/html/draft-schrock-
canonical-action-identifier-05>.
[EVAL-STATE]
Konda, G., "Preserving Evaluation State in Agent Protocol
Decisions", Work in Progress, Internet-Draft, draft-konda-
agentproto-evaluation-state-01, 10 October 2026,
<https://datatracker.ietf.org/doc/html/draft-konda-
agentproto-evaluation-state-01>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/rfc/rfc6750>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/rfc/rfc8915>.
[OIDC-CORE]
Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D.,
Mortimore, C., and OpenID Foundation, "OpenID Connect Core
1.0",
<https://openid.net/specs/openid-connect-core-1_0.html>.
Jackson Expires 13 April 2027 [Page 19]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
[STATUS-LIST]
Looker, T., Bastian, P., and C. Bormann, "Token Status
List", Work in Progress, Internet-Draft, draft-ietf-oauth-
status-list-21, 21 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
status-list-21>.
[LEASES] Gray, C. and D. Cheriton, "Leases: An Efficient Fault-
Tolerant Mechanism for Distributed File Cache
Consistency", Proceedings of the Twelfth ACM Symposium on
Operating Systems Principles (SOSP '89), December 1989.
Appendix A. Conformance Cases
These cases restate requirements of Sections 3, 4 and 5 as checks.
They add no requirement. Each gives the expected verdict and the
expected reason, and a verifier that returns the verdict for a
different reason has not passed the case: a verifier that refuses
everything returns "refuse" wherever it is expected. The reason is
what the verifier's own record carries (Section 5). The caller
learns at most whether a refusal is permanent or transient. The
reasons are written as prose; this document defines no reason codes.
A.1. An Approval at Its Expiry
One held call is pending under an approval that expires at E. Every
other input is valid. B is the pinned skew bound where E was
asserted under another party's clock, and zero where it was asserted
under the verifier's own. The evaluation instant t comes from the
verifier's trusted clock and from nothing the presenter supplies
(Section 3.2). The same call is presented for release in each case.
+======+=================+===========+=============================+
| Case | Condition | Verdict | Reason the record carries |
+======+=================+===========+=============================+
| E1 | t earlier than | release | The approval is valid at t |
| | E minus B | | and unconsumed. The |
| | | | release is the one |
| | | | consumption event of the |
| | | | instance. |
+------+-----------------+-----------+-----------------------------+
| E2 | t at or after E | refuse, | The approval expired at the |
| | | permanent | evaluation instant. |
| | | | Recorded as evaluated. Not |
| | | | a rejection: no approver |
| | | | disposition exists, and |
| | | | nothing is consumed. |
+------+-----------------+-----------+-----------------------------+
Jackson Expires 13 April 2027 [Page 20]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
| E3 | B above zero; t | refuse, | As E2. The bound is |
| | at or after E | permanent | applied toward less |
| | minus B and | | authority. |
| | earlier than E | | |
+------+-----------------+-----------+-----------------------------+
| E4 | As E2; every | refuse, | As E2. A verifier that |
| | timestamp in | permanent | releases derived the |
| | the presented | | instant from the records. |
| | records is | | |
| | earlier than E | | |
| | minus B | | |
+------+-----------------+-----------+-----------------------------+
| E5 | As E2; the | refuse, | As E2. A verifier that |
| | presenter | permanent | releases took the instant |
| | asserts a | | from the presenter. |
| | current time | | |
| | earlier than E | | |
| | minus B | | |
+------+-----------------+-----------+-----------------------------+
| E6 | The E1 | refuse, | The approval was consumed |
| | presentation | permanent | by the release. Not |
| | repeated after | | expiry. |
| | the E1 release, | | |
| | t still earlier | | |
| | than E minus B | | |
+------+-----------------+-----------+-----------------------------+
| E7 | As E1; | refuse, | Could not evaluate; |
| | consumption | transient | consumption state |
| | state | | unavailable. Recorded as |
| | unavailable | | not-evaluated. Not expiry |
| | | | and not consumption. |
+------+-----------------+-----------+-----------------------------+
Table 1: Expiry cases
E1 and E2 are the pair that matters: the same call, just before and
just after its approval expires, against an instant supplied
independently of the call. E4 and E5 hold the instant after expiry
while everything the presenter controls says otherwise.
A.2. Records Under a Valid Signature
A grant has a ledger. Levels are written L1, L2 and L3, lowest
first. Every record in these cases carries a signature that verifies
under the key named. In R1 to R4 the grant has no level the verifier
can derive, a path through it is not fully valid, and a refusal that
follows is permanent (Section 4.4).
Jackson Expires 13 April 2027 [Page 21]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
+======+==================+==========+==============================+
| Case | Record | Verdict | Reason the record carries |
+======+==================+==========+==============================+
| R1 | A demotion from | refuse | Direction: a record under |
| | L1 to L2, signed | the | the evaluator role raises |
| | by the evaluator | record | a level. Not a signature |
| | key | | failure. |
+------+------------------+----------+------------------------------+
| R2 | The ledger | refuse | Continuity: the record |
| | stands at L1. A | the | does not start from the |
| | demotion from L3 | record | level the ledger held. |
| | to L2, signed by | | Not direction, since the |
| | the evaluator | | record lowers on its own |
| | key | | terms. |
+------+------------------+----------+------------------------------+
| R3 | The ledger | refuse | Continuity, as R2. |
| | stands at L1. A | the | |
| | promotion from | record | |
| | L2 to L3, signed | | |
| | by the issuer | | |
| | key | | |
+------+------------------+----------+------------------------------+
| R4 | A promotion | refuse | The record is signed by |
| | signed by the | the | the other role's key. |
| | evaluator key | record | |
+------+------------------+----------+------------------------------+
| R5 | The ledger holds | level L2 | The record the level rests |
| | a promotion to | | on is the promotion. The |
| | L2, then a re- | | re-attestation is passed |
| | attestation at | | over. A verifier that |
| | L2 by a | | names the re-attestation |
| | different signer | | fails the case although it |
| | | | reports L2. |
+------+------------------+----------+------------------------------+
| R6 | The grant states | evaluate | No record accounts for L3. |
| | L3. Its records | at L2 | The difference is |
| | derive L2, and | | recorded. |
| | none is refused | | |
+------+------------------+----------+------------------------------+
Table 2: Record cases
A.3. The Age of a Fetched Input
The standing of one issuer was fetched from a pinned source with an
as-of time of A. The pinned maximum age is M, so the horizon is A
plus M. Every other input is valid.
Jackson Expires 13 April 2027 [Page 22]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
+======+====================+===========+==========================+
| Case | Condition | Verdict | Reason the record |
| | | | carries |
+======+====================+===========+==========================+
| G1 | t earlier than A | admit | Standing established as |
| | plus M; standing | | of A. The record |
| | held | | carries A for this |
| | | | input. |
+------+--------------------+-----------+--------------------------+
| G2 | t at or after A | admit | Standing established as |
| | plus M; the source | | of the new fetch. The |
| | answers, standing | | record carries the new |
| | held | | as-of time, not A. |
+------+--------------------+-----------+--------------------------+
| G3 | t at or after A | refuse, | Could not evaluate; |
| | plus M; the source | transient | standing source |
| | does not answer | | unavailable. Recorded |
| | | | as not-evaluated. Not a |
| | | | withdrawal of standing. |
+------+--------------------+-----------+--------------------------+
| G4 | t earlier than A | refuse, | Issuer standing |
| | plus M; standing | permanent | withdrawn. Recorded as |
| | withdrawn as of A | | evaluated. |
+------+--------------------+-----------+--------------------------+
| G5 | The source's | answer | Earlier than an accepted |
| | answer is earlier, | not | answer from the same |
| | by the source's | accepted | source. The accepted |
| | own ordering, than | | answer stays in force |
| | one already | | until its own horizon. |
| | accepted from it | | |
+------+--------------------+-----------+--------------------------+
Table 3: Input age cases
Acknowledgements
Theo Adam contributed the test vector for the consumption rule and
the argument that the authority a call runs under belongs in the
frozen call, and separated closure of an authorization instance from
the outcome of its execution. Iman Schrock raised the terminal
meaning of rejection, the comparison basis for "as presented", and
the three-way split of key bootstrapping. Girish Konda raised what a
refused caller is told, the collision between refusal and rejection,
and the difference between disclosing a failed entry and disclosing a
failed path. Cliff Singletary raised issuer standing as an
evaluation input, the difference between a denial and an evaluation
that could not complete, and identifiers that survive re-
provisioning.
Jackson Expires 13 April 2027 [Page 23]
Internet-Draft WIMSE Verifier Evaluation Semantics October 2026
For this revision: Errol Seymour raised whether a pending approval is
bounded and whether issuer standing needs a claim surface in the
chain. Iman Schrock raised that expiry is never the approver's
rejection, and the review case of one held call presented on either
side of its approval's expiry. Girish Konda raised that the caller-
facing classification of a refusal should be a requirement, and that
the protocol side and the record side of a decision with unresolved
inputs have to change together, and the horizon for which a resolved
input is good. Sankalp Gilda defined the evaluation member of the
audit record, on a construction Cliff Singletary proposed. Kieran
Sweeney raised the boundary between attribution carried in a chain
and authority. Jijie Wei raised a third outcome for a decision with
unresolved inputs, and an as-of time for each input established at a
different time, and that a decision has a horizon of its own, no
later than that of its shortest-lived input.
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
Jackson Expires 13 April 2027 [Page 24]