The verification.* Constraint Family: Pre-Action Fail-Closed Gates for AI Agent Decisions
draft-krausz-verification-state-01

Network Working Group                                          J. Krausz
Internet-Draft                                             TK Collective
Intended status: Informational                              12 June 2026
Expires: 14 December 2026

 The verification.* Constraint Family: Pre-Action Fail-Closed Gates for
                           AI Agent Decisions
                   draft-krausz-verification-state-01

Abstract

   This document specifies the verification.* constraint family --- a
   pre-action, fail-closed gate primitive for AI agent decisions,
   sibling in shape to the environment.* family used in Verifiable
   Intent specifications.  A verification.* receipt is a JWS-signed
   artifact ([RFC7515]) carrying a canonical input, a derived binary
   act/halt output, and a versioned mapping identifier that binds them.
   A relying party recomputes the gate locally from signed primitives
   under the named mapping; the verifier never trusts the issuer's
   runtime.  This shape provides decision explainability and
   traceability evidence aligned with EU AI Act Article 12 record-
   keeping obligations and with the Decision Explainability tier of
   Anthropic's Zero Trust for AI Agents framework [ANTHROPIC-ZT].  The
   format is forward-compatible across mapping revisions: receipts
   signed under one mapping ID remain verifiable as correct-under-that-
   mapping after newer mappings ship.

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 14 December 2026.

Krausz                  Expires 14 December 2026                [Page 1]
Internet-Draft            verification.* family                June 2026

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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  The verification.* Constraint Family  . . . . . . . . . . . .   5
     3.1.  Sibling-not-Member Relationship to environment.*  . . . .   5
     3.2.  Composition Rules . . . . . . . . . . . . . . . . . . . .   6
   4.  Receipt Format  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  JWS Envelope  . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Payload Claims --- Canonical, Derived, Mapping-Bound  . .   7
     4.3.  Verification Protocol . . . . . . . . . . . . . . . . . .   8
     4.4.  Claim Binding . . . . . . . . . . . . . . . . . . . . . .   8
     4.5.  Receipt Envelope Example  . . . . . . . . . . . . . . . .   9
     4.6.  Version-Binding Rationale . . . . . . . . . . . . . . . .   9
   5.  Binary-Halt Gate Semantics  . . . . . . . . . . . . . . . . .  10
     5.1.  Decision Table  . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Threshold Rules . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Fail-Closed Mandate . . . . . . . . . . . . . . . . . . .  11
   6.  Multi-Axis Freshness  . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Three Independent Axes  . . . . . . . . . . . . . . . . .  11
     6.2.  Staleness Semantics . . . . . . . . . . . . . . . . . . .  12
   7.  Calibration Anchor Requirements . . . . . . . . . . . . . . .  12
     7.1.  Reproducibility Mandate . . . . . . . . . . . . . . . . .  12
     7.2.  Drift Detection . . . . . . . . . . . . . . . . . . . . .  13
   8.  Relationship to Related Work  . . . . . . . . . . . . . . . .  13
     8.1.  SCITT . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.2.  RATS  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.3.  W3C VC Confidence Method  . . . . . . . . . . . . . . . .  13
     8.4.  VAP Framework . . . . . . . . . . . . . . . . . . . . . .  14
     8.5.  Mastercard Verifiable Intent (environment.*)  . . . . . .  14
     8.6.  Differentiator Summary  . . . . . . . . . . . . . . . . .  14
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14

Krausz                  Expires 14 December 2026                [Page 2]
Internet-Draft            verification.* family                June 2026

     9.1.  Composition Non-Interference with environment.* Family  .  14
     9.2.  Other Security Considerations . . . . . . . . . . . . . .  14
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   11. Informative References  . . . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   AI agents increasingly take economic and operational actions on
   probabilistic input.  A customer-service agent posts content; a
   procurement agent commits to a supplier; a research agent files a
   regulatory report.  Each action is preceded by a factual claim the
   agent believes to be true.  Today, the infrastructure verifying
   whether the claim is true _before_ the agent acts on it is fragmented
   across operator logs (after-the-fact), confidence scores (soft
   signals), and ad-hoc validation pipelines (not interoperable).

   This document specifies the verification.* constraint family: a pre-
   action, fail-closed gate primitive shaped identically to the
   environment.* family used in Verifiable Intent specifications
   [VINTENT], but applied to probabilistic predicates rather than
   boolean state.  A verification.* receipt asserts, for a specific
   claim under a specific ruleset at a specific moment, whether an agent
   SHOULD proceed or halt.  The receipt is JWS-signed [RFC7515] and
   structured such that a relying party can recompute the gate decision
   locally from signed primitives, without trusting the issuer's
   runtime.

   The four properties this primitive needs to satisfy together:

   1.  *Pre-action.* The verification happens before the action.
   2.  *Fail-closed.* Anything ambiguous halts; "impossible, not
       tedious."
   3.  *Third-party recomputable.* The verifier never trusts the
       issuer's runtime; signature binds inputs, outputs, and mapping
       identifier together.
   4.  *Forward-compatible.* Receipts signed under one ruleset remain
       verifiable as correct-under-that-ruleset even after newer
       rulesets ship.

Krausz                  Expires 14 December 2026                [Page 3]
Internet-Draft            verification.* family                June 2026

   Property 3 is the load-bearing one and the one most existing
   primitives stop short of.  SCITT [SCITT] signs receipts (necessary
   but not sufficient).  W3C Verifiable Credentials Confidence Method
   [VC-CM] exposes confidence as a verifiable property (useful but not
   gating).  RATS [RFC9334] provides the Evidence->Verifier->AR->RP
   vocabulary (matched here).  None fully recompose the gate verdict
   from signed inputs.  Property 4 is the one that becomes a footgun if
   skipped: rule changes silently invalidate or mis-verify old
   artifacts.

   This document is complementary to security frameworks for AI agent
   deployment, including the Zero Trust framework for AI Agents
   published by Anthropic in May 2026 [ANTHROPIC-ZT], which names
   decision explainability as non-optional for regulated AI systems.
   The verification.* constraint family is one credible artifact shape
   for satisfying that explainability requirement.

1.1.  Requirements Language

   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.

1.2.  Scope

   In scope:

   *  Gate semantics for pre-action verification of factual claims.
   *  Receipt envelope format and required claims.
   *  Calibration anchor requirements and discipline.
   *  Multi-axis freshness model.
   *  Verification protocol for relying parties.

   Out of scope:

   *  Signing key management policy (defers to JWKS standards).
   *  Specific verifier implementations or model architectures.
   *  Claim-extraction techniques (how a claim is identified from agent
      input/output).
   *  Adversarial-probe methodology specifics.

2.  Terminology

   *Verifier* --- Entity issuing a verification receipt.

Krausz                  Expires 14 December 2026                [Page 4]
Internet-Draft            verification.* family                June 2026

   *Relying Party (RP)* --- Agent or downstream system consuming the
   receipt at a gate.

   *Gate* --- The decision point in the RP's code path where act / halt
   is consumed.

   *Calibration anchor* --- The dataset and seed defining confidence
   semantics for the verifier's pipeline.

   *Multi-axis freshness* --- Signature, calibration, and evidence each
   carry independent validity periods.

   *Verdict (raw)* --- One of supported, refuted, unverifiable, unknown.
   The underlying truth label.

   *Recommendation (canonical)* --- One of confident_supported,
   un_probed_not_cleared, vulnerable_supported, weak_supported, refuted,
   unverifiable, error.  Derived from primitives under the named
   mapping.

   *Gate (derived)* --- act or halt.  Derived from recommendation under
   the named mapping.

   *Mapping document* --- A published, immutable document specifying how
   recommendations are derived from primitives and how gates are derived
   from recommendations.  Identified by a stable string identifier
   (e.g., v0.3.0-2026-05-30).

3.  The verification.* Constraint Family

3.1.  Sibling-not-Member Relationship to environment.*

       +===========+======================+=======================+
       | Property  | environment.*        | verification.*        |
       +===========+======================+=======================+
       | Predicate | Boolean (state       | Probabilistic in      |
       |           | matches or does not) | [0,1]                 |
       +-----------+----------------------+-----------------------+
       | Threshold | Oracle-defined,      | Calibration-anchored, |
       | ownership | fixed-semantic       | mapping-versioned     |
       +-----------+----------------------+-----------------------+
       | Freshness | Single TTL           | Multi-axis            |
       +-----------+----------------------+-----------------------+
       | Gate      | Binary halt          | Binary halt           |
       | shape     |                      |                       |
       +-----------+----------------------+-----------------------+

                                 Table 1

Krausz                  Expires 14 December 2026                [Page 5]
Internet-Draft            verification.* family                June 2026

   Both families produce a binary fail-closed gate primitive.  They
   differ in predicate shape (boolean vs probabilistic) and threshold
   provenance (fixed vs calibration-anchored).  This difference is
   sufficient to warrant a sibling family rather than a member entry
   under environment.*: probabilistic predicates require calibration
   discipline that boolean predicates do not, and the version-binding
   mechanism described in Section 4 is specific to mappings between
   probabilistic primitives and binary outputs.

   Read sibling-to-sibling: environment.* attests a deterministic read
   of the world (state matches or does not, with a fixed-semantic
   threshold), while verification.* attests an irreducibly probabilistic
   statement about a proposition (calibration-anchored confidence over a
   claim, with a mapping-versioned threshold).  Both produce the same
   binary gate output; they differ in what kind of fact the threshold is
   being applied to.  This split is structural: the receipt envelope,
   JCS canonicalization, signed-primitives discipline, and offline-
   verifiable-against-published-JWKS verification model are identical
   across the two families.  See [ENV-STATE] for the world-state-read
   sibling.

3.2.  Composition Rules

   *Conjunction:* Multiple verification.* constraints in a single
   mandate combine with AND (orthogonal+conjunctive).  All constraints
   MUST resolve to act for the action to proceed.

   *Ordering with environment.*:* environment.* constraints MUST short-
   circuit before verification.* constraints per [ENV-STATE] §5.5.
   Environment evaluation is typically cheaper (no oracle roundtrip) and
   a failed environment constraint moots the verification.  See also
   Section 9 for the non-interference security property this ordering
   provides.

4.  Receipt Format

4.1.  JWS Envelope

   Verification receipts MUST be issued as JSON Web Signatures (JWS)
   [RFC7515].  Both compact serialization and JSON serialization
   (flattened form) are conforming.  The v0.3 reference fixture pair
   uses JWS JSON (flattened) serialization because it preserves the
   protected/unprotected/signature object structure the verification
   protocol walks (Section 4.3); compact serialization remains valid for
   profiles that prefer it.  A relying party MUST accept both
   serializations.

Krausz                  Expires 14 December 2026                [Page 6]
Internet-Draft            verification.* family                June 2026

   *  alg: A conforming implementation MUST accept both EdDSA (Ed25519,
      [RFC8037]) and ES256 ([RFC7518]).  The v0.3 reference fixture pair
      signs with EdDSA; ES256 remains valid for profiles that prefer it.
      Other algorithms are optional and SHOULD follow the IANA JOSE
      Algorithms registry.
   *  kid: MUST resolve to a key in the issuer's published JWKS
      [RFC7517] at /.well-known/jwks.json unless an alternate JWKS
      location is published in the issuer's metadata.
   *  typ: verification-receipt+jws.

4.2.  Payload Claims --- Canonical, Derived, Mapping-Bound

   The payload signs three structurally distinct field groups plus their
   bindings.

   *Canonical input (signed primitives):*

   *  v_verdict (string, REQUIRED) --- One of supported, refuted,
      unverifiable, unknown.
   *  v_confidence (number, REQUIRED) --- Float in [0, 1].
   *  v_adversarial_result (string, REQUIRED) --- One of resilient,
      vulnerable, not_checked.

   *Canonical derived (signed):*

   *  v_recommendation (string, REQUIRED) --- One of
      confident_supported, vulnerable_supported, weak_supported,
      refuted, unverifiable, error.  Derived deterministically from the
      canonical input under the named mapping.

   *Derived output (signed):*

   *  v_gate (string, REQUIRED) --- One of act, halt.  Derived from
      v_recommendation under the named mapping.

   *Binding (signed):*

   *  v_gate_mapping (string, REQUIRED) --- Stable identifier of the
      published mapping document used at issuance (e.g.,
      v0.3.0-2026-05-30).  The mapping document is immutable after
      publication; future revisions ship as new identifiers.
   *  v_gate_mapping_hash (string, REQUIRED) --- SHA-256 hex digest of
      the canonical serialization of the mapping document identified by
      v_gate_mapping.  MUST be present in every receipt.  Receipts MUST
      bind to a content-addressed mapping; the absence of
      v_gate_mapping_hash is a malformed-receipt condition and MUST
      result in gate decision halt.

Krausz                  Expires 14 December 2026                [Page 7]
Internet-Draft            verification.* family                June 2026

   *Provenance (signed, not gating):*

   *  v_method (string, OPTIONAL) --- Self-describing verifier pipeline
      identifier.
   *  v_calibration (object, OPTIONAL) --- Calibration anchor metadata.
      See Section 7.
   *  v_sources_used (array of strings, OPTIONAL) --- Source labels
      actually consulted in this evaluation.
   *  v_evidence (string, OPTIONAL) --- URI pointer to evidence corpus,
      if persisted.

   *Standard JWT claims [RFC7519]:*

   *  iss (REQUIRED), sub (RECOMMENDED), iat (REQUIRED), exp (REQUIRED),
      nbf (OPTIONAL).

4.3.  Verification Protocol

   A relying party verifying a receipt MUST execute the following
   sequence and treat any failure as a malformed receipt with gate
   decision halt:

   1. Verify JWS signature against issuer's published JWKS (RFC 7515).
   2. Resolve v_gate_mapping -> fetch the named immutable mapping document.
      MUST verify the SHA-256 digest of the fetched document matches
      v_gate_mapping_hash (hex-encoded). Digest mismatch -> malformed;
      gate decision = halt. This binding is mandatory; receipts without
      v_gate_mapping_hash are malformed.
   3. Recompute candidate_recommendation from
      (v_verdict, v_confidence, v_adversarial_result)
      using the mapping's rules and the threshold recovered from the
      mapping document.
   4. Confirm candidate_recommendation == v_recommendation.
   5. Compute candidate_gate = mapping(v_recommendation).
   6. Confirm candidate_gate == v_gate.
   7. Verify exp/nbf against current time, subject to clock tolerance
      per Section 6.
   8. If all match -> receipt is valid AND internally consistent under
      the named mapping. Any mismatch -> malformed; gate decision = halt.

   The relying party never trusts the issuer's runtime to have applied
   the mapping correctly.  The signature binds inputs, outputs, and
   mapping identifier together; the verifier recomputes locally.

4.4.  Claim Binding

   The verified claim MUST be bound to the receipt via v_claim:

Krausz                  Expires 14 December 2026                [Page 8]
Internet-Draft            verification.* family                June 2026

   "v_claim": {
     "text": "string (OPTIONAL when caller marks input as PII-sensitive)",
     "hash": "hex-encoded SHA-256 of canonicalized claim text (REQUIRED when text is omitted)"
   }

   Hash-only mode permits PII-sensitive verification while preserving
   the receipt's auditability --- the verifier can confirm a future
   caller's claim hash matches the issued receipt's bound hash without
   exposing the claim text.

4.5.  Receipt Envelope Example

   The following is a non-normative example of a receipt envelope
   payload illustrating the mandatory v_gate_mapping_hash binding
   alongside v_gate_mapping:

   {
     "iss": "https://verifier.example.com",
     "sub": "claim:sha256:a3f1...",
     "iat": 1748649600,
     "exp": 1748736000,
     "v_verdict": "supported",
     "v_confidence": 0.91,
     "v_adversarial_result": "resilient",
     "v_recommendation": "confident_supported",
     "v_gate": "act",
     "v_gate_mapping": "v0.3.0-2026-05-30",
     "v_gate_mapping_hash": "sha256:1ad513cd0cfcc1fcd78136375268ba85c50cc267de8d9f92a9a3e61f5d672288",
     "v_claim": {
       "hash": "a3f1c2d4e5b6789012345678abcdef0123456789abcdef0123456789abcdef01"
     }
   }

   The v_gate_mapping_hash field carries the hex-encoded SHA-256 digest
   of the canonical serialization of the mapping document identified by
   v_gate_mapping.  This field MUST be present in all conforming
   receipts; its absence is a malformed-receipt condition.

4.6.  Version-Binding Rationale

   Gate-derivation rules will evolve.  A receipt issued under mapping
   v0.3.0-... MUST remain verifiable as _correct-under-v0.3.0_ after a
   newer mapping ships.  The mapping identifier in v_gate_mapping is the
   binding that makes this true: a verifier fetches the _same_ mapping
   document the issuer used at issuance, regardless of newer revisions.
   Receipts never silently re-verify to a different gate.

Krausz                  Expires 14 December 2026                [Page 9]
Internet-Draft            verification.* family                June 2026

   Mapping document publishers MUST treat published mappings as
   immutable.  New rules ship under new mapping identifiers.  Errata
   (typographical corrections only) MAY be appended to a published
   mapping document's metadata, but the normative rule tables MUST NOT
   change after first publication.

5.  Binary-Halt Gate Semantics

5.1.  Decision Table

   The reference mapping v0.3.0-2026-05-30 defines the following
   decision table.  Future mappings MAY tighten or extend this table;
   the structural shape (binary act/halt output derived from canonical
   recommendation) MUST be preserved.

   +============+============+====================+=====================+======+
   |v_verdict   |v_confidence|v_adversarial_result|v_recommendation     |v_gate|
   |            |vs threshold|                    |                     |      |
   +============+============+====================+=====================+======+
   |supported   |>= threshold|resilient           |confident_supported  |act   |
   +------------+------------+--------------------+---------------------+------+
   |supported   |>= threshold|not_checked         |un_probed_not_cleared|halt  |
   +------------+------------+--------------------+---------------------+------+
   |supported   |(any)       |vulnerable          |vulnerable_supported |halt  |
   +------------+------------+--------------------+---------------------+------+
   |supported   |< threshold |resilient or        |weak_supported       |halt  |
   |            |            |not_checked         |                     |      |
   +------------+------------+--------------------+---------------------+------+
   |refuted     |(any)       |(any)               |refuted              |halt  |
   +------------+------------+--------------------+---------------------+------+
   |unverifiable|(any)       |(any)               |unverifiable         |halt  |
   |or unknown  |            |                    |                     |      |
   +------------+------------+--------------------+---------------------+------+
   |(error      |N/A         |N/A                 |error                |halt  |
   |condition)  |            |                    |                     |      |
   +------------+------------+--------------------+---------------------+------+

                                  Table 2

5.2.  Threshold Rules

   The confidence threshold used to derive v_recommendation is specified
   in the named mapping document, not in the individual receipt.
   Receipts reference the mapping by v_gate_mapping identifier, and the
   threshold is recovered from that mapping.  This ensures that the
   threshold is auditable, versioned, and consistent across all receipts
   issued under the same mapping: two receipts under the same mapping ID
   MUST gate against the same threshold; threshold changes require a new

Krausz                  Expires 14 December 2026               [Page 10]
Internet-Draft            verification.* family                June 2026

   mapping version with a new ID.

   For a strict fail-closed gate, un-probed adversarial state is not
   equivalent to resilient --- it represents uncertainty about a
   dimension that can be exploited by adversarial input.  Per the fail-
   closed property, uncertainty MUST halt.  A claim may be confidently
   supported on its face, but if adversarial probing was not performed,
   the confidence applies only to the base claim, not to the claim under
   adversarial pressure.  The un_probed_not_cleared recommendation
   reflects this: the gate treats the absence of probing as a distinct
   unresolved risk, not as a cleared risk.

   Relying parties MAY require a higher threshold mapping for their own
   gate policies by requiring receipts under a different mapping ID that
   specifies a higher threshold.  They MUST NOT treat a receipt as
   conformant under a mapping that specifies a different threshold than
   the one in that mapping document.

5.3.  Fail-Closed Mandate

   If a receipt is missing, malformed, expired, signature-invalid, or
   its mapping ID cannot be resolved, the relying party MUST treat the
   gate decision as halt.  Implementations MUST NOT default to act under
   any error condition.  This is the "impossible, not tedious" design
   principle: friction-based controls bypass under adversarial pressure;
   hard barriers do not.

6.  Multi-Axis Freshness

6.1.  Three Independent Axes

   Verification receipts have three independent staleness axes, each
   with its own validity window:

Krausz                  Expires 14 December 2026               [Page 11]
Internet-Draft            verification.* family                June 2026

   +=============+===========================+========================+
   | Axis        | Field                     | Remediation            |
   +=============+===========================+========================+
   | Signature   | exp                       | Key rotation; verifier |
   |             |                           | MUST reject expired    |
   |             |                           | signatures             |
   +-------------+---------------------------+------------------------+
   | Calibration | v_calibration.valid_until | Recalibrate verifier   |
   |             |                           | pipeline against       |
   |             |                           | current anchor         |
   +-------------+---------------------------+------------------------+
   | Evidence    | v_evidence.valid_until    | Re-fetch evidence;     |
   |             | (OPTIONAL)                | usually shorter window |
   |             |                           | than calibration       |
   +-------------+---------------------------+------------------------+

                                 Table 3

6.2.  Staleness Semantics

   *  *Stale signature* --- Receipt is invalid; relying party MUST treat
      as halt.
   *  *Stale calibration* --- Receipt SHOULD be re-evaluated; relying
      party MAY honor as soft-stale per its own policy.  Verifier
      issuers SHOULD publish recalibration cadence in metadata.
   *  *Stale evidence* --- Receipt SHOULD be re-evaluated.  MAY be
      honored for retrospective audit purposes (e.g., post-incident
      review of a past action) but MUST NOT be honored as a gate signal
      for new actions.

   Each axis has a different remediation path; collapsing them into a
   single TTL would force the most-restrictive cadence to govern all
   three.

7.  Calibration Anchor Requirements

7.1.  Reproducibility Mandate

   Verifier issuers MUST publish:

   *  Anchor dataset name and version.
   *  Anchor seed (or seeded run identifier).
   *  Anchor scoring methodology.

Krausz                  Expires 14 December 2026               [Page 12]
Internet-Draft            verification.* family                June 2026

   Verifier issuers SHOULD publish a reference reproduction harness
   under a permissive open-source license (Apache 2.0, MIT, or BSD).  A
   working reference implementation reproducing 57.6% on AVeriTeC
   [AVERITEC] is available at https://github.com/TKCollective/
   agentoracle-eval-harness (https://github.com/TKCollective/
   agentoracle-eval-harness) as one example of conformance.

7.2.  Drift Detection

   Verifier issuers SHOULD publish a recalibration cadence in the JWKS
   metadata or the verifier's well-known endpoint.  The
   v_calibration.valid_until field in receipts SHOULD reflect this
   cadence.  Relying parties consuming receipts with stale calibration
   SHOULD log and surface the staleness rather than silently accept.

8.  Relationship to Related Work

8.1.  SCITT

   The SCITT WG architecture document [SCITT] defines the Supply Chain
   Integrity, Transparency, and Trust signing and receipt envelope.
   This document is SCITT-compatible: a verification.* receipt MAY be
   wrapped in a SCITT envelope, and SCITT receipts MAY carry
   verification.* payloads.  SCITT specifies the signing infrastructure;
   this document specifies a gate primitive that may be transported via
   SCITT or via plain JWS.

8.2.  RATS

   RFC 9334 [RFC9334] defines the Remote Attestation Architecture's
   Evidence->Verifier->Attestation Result->Relying Party vocabulary.  A
   verification.* receipt is an Attestation Result whose gate field
   (v_gate) is the RP-consumable primitive.  This document is consistent
   with the RATS vocabulary and may be considered a verification-
   specific Attestation Result profile.

8.3.  W3C VC Confidence Method

   The W3C Verifiable Credentials Confidence Method [VC-CM] defines
   confidence-as-a-verifiable-property within Verifiable Credentials.
   This document adopts the same pattern for v_confidence (signed
   metadata, not gating).  Confidence is provenance; the gate is the
   contract.  Alignment, not overlap.

Krausz                  Expires 14 December 2026               [Page 13]
Internet-Draft            verification.* family                June 2026

8.4.  VAP Framework

   The Verifier Abstraction Pattern framework [VAP-FW] is an individual
   Internet-Draft providing verifier abstraction conventions.  A
   verification.* receipt issuer MAY be considered a verifier profile
   under the VAP umbrella.  (Editorial note: this section's citation
   MUST be pinned to a specific VAP version at submission time;
   individual drafts move and expire.)

8.5.  Mastercard Verifiable Intent (environment.*)

   The environment.* constraint family for pre-action attestation of
   environment state is specified in [ENV-STATE], as part of the
   Verifiable Intent framework [VINTENT].  This document extends the
   constraint-family pattern to probabilistic predicates with
   calibration discipline, as a sibling family rather than a member
   entry.  See Section 3.

8.6.  Differentiator Summary

   Pre-action fail-closed gate.  Not signing machinery (covered by
   SCITT).  Not confidence quantification (covered by W3C VC CM).  Not
   just an Attestation Result (covered by RATS).  The gate primitive
   itself, with the version-binding necessary to outlive ruleset
   evolution.

9.  Security Considerations

9.1.  Composition Non-Interference with environment.* Family

   When verification.* composes alongside environment.* on the same
   mandate, the ordering specified in §3.2 (environment.* short-circuits
   before verification.*) MUST hold.  This document inherits that
   ordering directly from [ENV-STATE] §5.5, which specifies that
   environment.* is not subject to ordering preemption by any other
   constraint family.  A verification.* ACT outcome MUST NOT mask an
   environment.* HALT outcome; if environment.* halts on any constraint,
   that halt is final regardless of the verification.* state.
   Implementations MUST evaluate environment.* to its terminal state
   before evaluating any verification.* constraint, and a verification.*
   state SHALL NOT be reached if environment.* has already halted.

9.2.  Other Security Considerations

   *Key compromise.* Verifier issuers MUST rotate JWKS keys on a
   published cadence.  Receipts signed under a compromised key remain
   verifiable against historical key state during the rotation horizon.
   RPs MUST honor key revocation lists where published.

Krausz                  Expires 14 December 2026               [Page 14]
Internet-Draft            verification.* family                June 2026

   *Replay attacks.* Receipts include iat and exp.  RPs MUST verify both
   against current time, subject to clock tolerance.  Claim-binding via
   v_claim.hash provides resistance to receipt-reuse against a different
   claim payload.

   *Confidence inflation attacks.* A verifier issuer who inflates
   v_confidence to push more receipts to act would diverge from their
   published calibration anchor.  The reproducibility mandate
   (Section 7) makes this detectable.  RPs SHOULD periodically sample
   receipts against the issuer's published harness.

   *Selective disclosure.* Hash-only claim binding (Section 4.4) permits
   PII-sensitive verification without exposing claim text in the receipt
   envelope.

   *Downgrade attacks.* A future relying party MUST NOT accept a
   v0.3-spec receipt against a v0.4-spec gate.  The receipt format
   version is implicitly bound by v_gate_mapping; mismatches between
   expected and signed mapping IDs are malformed-receipt conditions per
   Section 4.3.

   *Mapping document tampering.* Receipts MUST bind to a content-
   addressed mapping via the v_gate_mapping_hash field (SHA-256).
   Mapping documents MUST be hosted such that the SHA-256 digest of the
   canonical serialization is stable and independently verifiable (e.g.,
   at a content-addressed URL or via a git-tagged manifest).  Verifier
   implementations MUST verify the SHA-256 digest of the fetched mapping
   document against v_gate_mapping_hash before use; a digest mismatch
   MUST result in gate decision halt.  A relying party that cannot
   independently verify the mapping document's hash MUST treat the
   receipt as malformed.

10.  IANA Considerations

   This document requests the following IANA registrations:

   *Media type:* verification-receipt+jws (to be registered in the IANA
   Media Types registry following the procedures of RFC 6838).

   *JWT claim names:* v_verdict, v_confidence, v_adversarial_result,
   v_recommendation, v_gate, v_gate_mapping, v_gate_mapping_hash,
   v_method, v_calibration, v_sources_used, v_evidence, v_claim (to be
   registered in the JSON Web Token Claims registry).

   *Well-known URI:* Verification issuers using HTTPS SHOULD publish
   their JWKS at /.well-known/jwks.json per existing [RFC7517]
   Section 4.7 conventions.  No new well-known URI is requested.

Krausz                  Expires 14 December 2026               [Page 15]
Internet-Draft            verification.* family                June 2026

   The verification.* and environment.* constraint families are related
   sibling namespaces.  Coordination on a joint constraint-family
   registry shared with the environment.* family ([ENV-STATE]) is
   deferred to all interested parties (Krausz, Borthwick, Msebenzi) for
   resolution outside the scope of this document.  This document does
   not commit to a specific registry structure, nor does it assert
   agreement from the environment.* authors on any registry arrangement.
   The cross-referencing between verification.* and environment.* as
   related constraint families stands as documented, independent of any
   future registry decision.

11.  Informative References

   [ANTHROPIC-ZT]
              Anthropic, "Zero Trust for AI Agents: A security framework
              for deploying autonomous AI agents in the enterprise",
              PDF, 36 pages, May 2026.

   [AVERITEC] Schlichtkrull, M., "AVeriTeC: A Dataset for Real-World
              Claim Verification with Evidence from the Web", 2024.

   [ENV-STATE]
              Borthwick, D. and M. Msebenzi, "Verifiable Intent ---
              environment.* Constraint Family", Work in Progress,
              Internet-Draft, draft-borthwick-msebenzi-environment-
              state-00, May 2026,
              <https://datatracker.ietf.org/doc/html/draft-borthwick-
              msebenzi-environment-state-00>.

   [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/info/rfc2119>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/info/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/info/rfc7518>.

Krausz                  Expires 14 December 2026               [Page 16]
Internet-Draft            verification.* family                June 2026

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC8037]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
              and Signatures in JSON Object Signing and Encryption
              (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
              <https://www.rfc-editor.org/info/rfc8037>.

   [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/info/rfc8174>.

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
              2023, <https://www.rfc-editor.org/info/rfc9334>.

   [SCITT]    IETF SCITT Working Group, "An Architecture for Trustworthy
              and Transparent Digital Supply Chains", Work in Progress,
              Internet-Draft, draft-ietf-scitt-architecture, 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-
              architecture>.

   [VAP-FW]   Kamimura, K., "Verifier Abstraction Pattern Framework",
              Work in Progress, Internet-Draft, draft-kamimura-vap-
              framework, 2024, <https://datatracker.ietf.org/doc/html/
              draft-kamimura-vap-framework>.

   [VC-CM]    World Wide Web Consortium, "Verifiable Credentials
              Confidence Method", W3C Working Draft, 2024.

   [VINTENT]  Verifiable Intent Working Group, "Verifiable Intent ---
              Constraint Type Definitions and Validation Rules",
              Verifiable Intent Working Group Draft v0.1, February 2026.

Author's Address

   Joe Krausz
   TK Collective
   Los Angeles, CA
   United States of America
   Email: Joe@agentoracle.co
   URI:   https://agentoracle.co

Krausz                  Expires 14 December 2026               [Page 17]