c.wesjackson@gmail.com

sec wimse workload identity delegation verifier evaluation 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.

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. 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 and : those define what is conveyed, this defines how the receiver judges it. Section 4.1 maps its credentials onto the inputs in and the rules in . It records the consumption rule of 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. defines the boundary at which an executor admits, consumes authority for, and classifies the outcome of a consequential action, and 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 are exercised in the public reference implementation : consumption keyed to the frozen call, and verification under role-separated keys. The other two are not. That implementation consumes no 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 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. Issuer standing () and the directional rules for fetched inputs and clock skew are new in this revision, and this document makes no claim that the reference implementation exercises them. The key-bootstrapping mechanism discussed in is the known open item; it is named as a gap rather than specified.

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 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 . 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. 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. 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. Issuer standing: whether the party an issuer key speaks for still holds the role it issued under.

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 safe under failure. The requirements in this section are written so that every fetched input fails toward less authority. 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.

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

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 , narrows that attack. When the verifier compares the instant with a time asserted under another party's clock, it MUST apply the skew bound () in the direction that confers less authority. An expiry, 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 than it asserts. 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.

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. ( 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, Section 5.1) 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 Section 2 carries the same requirement.

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, Section 6.7.2, Section 6.10)

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 decides the token. Standing carried only in the presented token MUST NOT be accepted as its own source. The source is a deployment choice. A 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. 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.

Evaluation Rules

Process Every Entry or Refuse A verifier MUST process every authorization_details entry 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 .) 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 .

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

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

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)

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; 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 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 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 (), a signature that does not verify, an expired grant, 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. A refusal SHOULD be distinguishable by the caller as one or the other. A refusal that surfaces as a generic failure gets retried, often at once and at length, which costs both parties availability, and a transient refusal reported as permanent stops a caller whose token would succeed later. Where the transport already defines a code, that code is the one to use. At the authorization server, Section 5 defines invalid_authorization_details for an unknown authorization details type, and Section 4.1.2.1 defines temporarily_unavailable. A resource server using bearer tokens has invalid_token for a permanent refusal, and status code 503 with a Retry-After field 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 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 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 (), 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. 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. 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 ( Section 10). A deployment that needs to know how the issuer authenticated carries that separately, for example as the acr and amr claims of Section 2. 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. ( Section 6.7.2, Section 6.6, 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. ( Section 6.7)

IANA Considerations This document makes no request of IANA.

References Normative References Informative References version 0.2.9-draft version 0.2.7-draft wjatx Public reference implementation of GAL and PTC; the code this document's rules are drawn from OpenID Foundation Proceedings of the Twelfth ACM Symposium on Operating Systems Principles (SOSP '89)

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. This document was prepared with AI assistance for drafting, source verification and editorial review. The technical positions are the author's.