



Independent Submission                                      D. Borthwick
Internet-Draft                                                InsumerAPI
Intended status: Informational                               M. Msebenzi
Expires: 12 November 2026                                Headless Oracle
                                                             11 May 2026


          Verifiable Intent — environment.* Constraint Family
             draft-borthwick-msebenzi-environment-state-00

Abstract

   The Verifiable Intent (VI) mandate format authorises autonomous
   agents to act on behalf of human principals through cryptographically
   signed constraint instances bound into Layer 2 mandates.  VI's
   existing constraint families describe properties of the transaction
   itself — what is being purchased, by whom, for how much, against
   which credential.  They do not describe properties of the environment
   in which the transaction is executed: whether the venue is open,
   whether the source of funds is funded, whether other relevant
   external conditions hold at the moment of execution.

   This document specifies the environment.* constraint family for the
   Verifiable Intent mandate vocabulary.  It defines the membership
   criterion under which a constraint type qualifies as a member of the
   family, the family-wide vocabulary every member uses, the composition
   discipline by which family members compose with each other and with
   constraints from other families, the register discipline under which
   family-wide and per-type prose is written, the family-wide security
   considerations, and the IANA registry mechanics under which new
   family members are registered.  It does not define any individual
   constraint type.  Two reference type specifications
   (environment.market_state and environment.wallet_state) are
   referenced informatively in Appendix A.

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







Borthwick & Msebenzi    Expires 12 November 2026                [Page 1]

Internet-Draft                environment.*                     May 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Relationship to Verifiable Intent . . . . . . . . . . . .   6
     1.4.  Document Organisation . . . . . . . . . . . . . . . . . .   7
   2.  Terminology and References  . . . . . . . . . . . . . . . . .   7
     2.1.  Conventions and Definitions . . . . . . . . . . . . . . .   7
     2.2.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     2.3.  References  . . . . . . . . . . . . . . . . . . . . . . .  10
       2.3.1.  Normative References  . . . . . . . . . . . . . . . .  10
       2.3.2.  Informative References  . . . . . . . . . . . . . . .  10
   3.  The environment.* Constraint Family . . . . . . . . . . . . .  11
     3.1.  Family Definition . . . . . . . . . . . . . . . . . . . .  11
     3.2.  Membership Criterion  . . . . . . . . . . . . . . . . . .  11
     3.3.  Namespace . . . . . . . . . . . . . . . . . . . . . . . .  12
     3.4.  Adding New Family Members . . . . . . . . . . . . . . . .  13
     3.5.  Handling of Weakened Type Specifications  . . . . . . . .  14
     3.6.  Relationship to Other Constraint Families . . . . . . . .  14
   4.  Family-Wide Vocabulary  . . . . . . . . . . . . . . . . . . .  15
     4.1.  Family-Wide Fields  . . . . . . . . . . . . . . . . . . .  16
       4.1.1.  attestation_url . . . . . . . . . . . . . . . . . . .  16
       4.1.2.  max_attestation_age . . . . . . . . . . . . . . . . .  16
     4.2.  Field-Scope Taxonomy  . . . . . . . . . . . . . . . . . .  17
       4.2.1.  Scope Declarations for Family-Wide Fields . . . . . .  18
       4.2.2.  Scope Declarations for Per-Type Fields  . . . . . . .  18
       4.2.3.  Adding Scope Categories . . . . . . . . . . . . . . .  19
     4.3.  Algorithm Agility . . . . . . . . . . . . . . . . . . . .  19
   5.  Family Composition  . . . . . . . . . . . . . . . . . . . . .  20



Borthwick & Msebenzi    Expires 12 November 2026                [Page 2]

Internet-Draft                environment.*                     May 2026


     5.1.  Conjunction Semantics . . . . . . . . . . . . . . . . . .  20
     5.2.  Mixed Pass/Fail . . . . . . . . . . . . . . . . . . . . .  21
     5.3.  L3 Execution Gate and Completeness  . . . . . . . . . . .  21
     5.4.  Per-Member Diagnostic Output  . . . . . . . . . . . . . .  22
     5.5.  Composition with Other Families . . . . . . . . . . . . .  23
     5.6.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .  23
   6.  Register Discipline . . . . . . . . . . . . . . . . . . . . .  24
     6.1.  Normative Register  . . . . . . . . . . . . . . . . . . .  25
     6.2.  Descriptive Register  . . . . . . . . . . . . . . . . . .  25
     6.3.  Redundancy Avoidance  . . . . . . . . . . . . . . . . . .  26
     6.4.  Scope of Application  . . . . . . . . . . . . . . . . . .  26
     6.5.  Forward Rule for New Sections and New Specifications  . .  27
     6.6.  Relationship to Section 2.1 Conventions . . . . . . . . .  27
     6.7.  Open Questions  . . . . . . . . . . . . . . . . . . . . .  27
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
     7.1.  Attestation Replay  . . . . . . . . . . . . . . . . . . .  28
     7.2.  Issuer Trust Bootstrapping  . . . . . . . . . . . . . . .  29
     7.3.  Constraint Stripping and Insertion  . . . . . . . . . . .  30
     7.4.  Substitution of Attestation Endpoints . . . . . . . . . .  30
     7.5.  Mandate-Issuer-Versus-Attestation-Issuer Trust
           Separation  . . . . . . . . . . . . . . . . . . . . . . .  31
     7.6.  Time Synchronisation  . . . . . . . . . . . . . . . . . .  32
     7.7.  SSRF and Other Verifier-Initiated Fetch Risks . . . . . .  32
     7.8.  Signer Failure Handling . . . . . . . . . . . . . . . . .  33
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
     8.1.  The environment.* Namespace . . . . . . . . . . . . . . .  35
     8.2.  The environment.* Constraint Type Registry  . . . . . . .  35
     8.3.  Expert Review Criteria  . . . . . . . . . . . . . . . . .  36
     8.4.  Status Field Lifecycle  . . . . . . . . . . . . . . . . .  37
     8.5.  Updates to This Document  . . . . . . . . . . . . . . . .  38
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  39
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  39
   Appendix A.  Reference Type Specifications  . . . . . . . . . . .  40
     A.1.  environment.market_state  . . . . . . . . . . . . . . . .  41
     A.2.  environment.wallet_state  . . . . . . . . . . . . . . . .  41
     A.3.  Disclaimer  . . . . . . . . . . . . . . . . . . . . . . .  42
   Appendix B.  Reserved . . . . . . . . . . . . . . . . . . . . . .  42
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  42
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  42











Borthwick & Msebenzi    Expires 12 November 2026                [Page 3]

Internet-Draft                environment.*                     May 2026


1.  Introduction

   Autonomous agents executing financial transactions on behalf of human
   principals require cryptographic awareness of external state at the
   moment of execution.  This requirement exists independently of the
   constraints that authorize what the agent may do.  An agent holding a
   valid mandate to purchase a specific asset for a specific amount must
   additionally know, at execution time, whether the venue at which it
   intends to execute is open and whether the source of funds it intends
   to draw from still satisfies the conditions under which the mandate
   was issued.  Neither question is answered by the mandate itself.
   Both must be answered, with cryptographic evidence, before execution
   proceeds.

   This document defines a constraint family — environment.* — for the
   Verifiable Intent (VI) mandate vocabulary that addresses this class
   of requirement.  It does not specify any individual constraint type
   in detail.  Instead, it defines the membership criterion under which
   a constraint type qualifies as a member of the environment.* family,
   the vocabulary by which family members compose with each other and
   with constraints from other families, and the discipline under which
   new family members may be added by future revisions or by independent
   implementations.

1.1.  Motivation

   The Verifiable Intent specification [VI-CONSTRAINTS] defines mandate
   constraints under a single transactional namespace, mandate.*, with
   two sub-namespaces: mandate.checkout.* declares what the agent may
   purchase (allowed merchants, line items), and mandate.payment.*
   declares how the agent may settle (allowed payees, amount ranges,
   budgets, recurrence, payment-mandate reference).  These transactional
   constraint families are sufficient to authorize an agent's intended
   action and to bind that authorization cryptographically to a
   credential the agent presents at the moment of execution.
















Borthwick & Msebenzi    Expires 12 November 2026                [Page 4]

Internet-Draft                environment.*                     May 2026


   They are not sufficient to bind the agent's action to the state of
   the world at the moment of execution.  An agent can present a valid
   mandate to purchase shares of a security listed on a venue that is
   currently halted; the mandate is cryptographically valid and the
   action is unauthorized in the real world.  An agent can present a
   valid mandate to settle a payment in a stablecoin from a wallet that
   no longer holds sufficient balance; the mandate is cryptographically
   valid and the settlement will fail or, worse, succeed against an
   unintended source.  These failure modes are not exotic edge cases.
   They are the autonomous-execution analog of well-documented races in
   financial markets and on-chain settlement, including market-execution
   events such as the 2010 Flash Crash and circuit-breaker session-
   boundary races, and on-chain TOCTOU exploits in the flash-loan-
   enabled class.

   Existing transactional constraint families cannot close this gap
   because they describe properties of the transaction — what is being
   done, by whom, for how much, against what credential.  The gap
   concerns properties of the environment in which the transaction is
   executed — whether the venue is open, whether the source is funded,
   and, by extension, whether other relevant conditions of the world
   hold at execution time.  These properties are not under the control
   of any party to the transaction and cannot be asserted by the agent.
   They must be observed and signed by an entity outside the transaction
   whose identity and signing key are bound into the mandate at issuance
   time.

   A constraint family is therefore the right primitive: each member
   type targets a specific environmental property, signed by an external
   attester, and verified at execution time before the transactional
   constraints are evaluated.  This document defines the family.
   Specific member types are defined in their own specifications;
   reference implementations are cited in Appendix A.

1.2.  Scope

   This document defines:

   (1) the membership criterion under which a constraint type qualifies
   as a member of the environment.* family;

   (2) the vocabulary used by family members, including required and
   optional fields whose semantics are family-wide;

   (3) the composition discipline by which family members compose with
   each other and with constraints from other families;





Borthwick & Msebenzi    Expires 12 November 2026                [Page 5]

Internet-Draft                environment.*                     May 2026


   (4) the register discipline (RFC 2119 keyword usage, normative versus
   informative material) under which family-wide and per-type prose is
   written.

   This document does not define:

   (1) any individual environment.* constraint type.  Two reference type
   specifications (environment.market_state and
   environment.wallet_state) are documented in their own working-group
   submissions and are referenced informatively in Appendix A;

   (2) any algorithm for canonicalising signed attestation payloads.
   Per-type canonicalisation is the responsibility of each type
   specification;

   (3) any specific signing algorithm.  Algorithm agility is family-
   wide; per-type MUST-implement declarations are made by each type
   specification;

   (4) any specific attestation issuer, attestation endpoint, or
   operational detail of any reference implementation;

   (5) any change to the transactional constraint families (mandate.*)
   defined in [VI-CONSTRAINTS].  Family composition is the only surface
   at which environment.* interacts with transactional constraints, and
   this composition is unidirectional: environment.* constraints gate
   execution; transactional constraints are evaluated after
   environment.* constraints have passed.

   The deliberate narrowness of this scope reflects the family's design
   discipline: the document is the contract under which independent type
   authors and implementers can extend the family without coordinating
   with each other or with the authors of this document, provided they
   satisfy the membership criterion and respect the family-wide
   vocabulary and composition rules.

1.3.  Relationship to Verifiable Intent

   This document is a vocabulary specification for the Verifiable Intent
   mandate format.  It does not modify the Verifiable Intent
   specification itself.  It declares a constraint-family namespace
   (environment.*) and the rules under which constraint types within
   that namespace operate, in the same manner that any extension of an
   existing vocabulary declares its own namespace and rules without
   modifying the host vocabulary's grammar.






Borthwick & Msebenzi    Expires 12 November 2026                [Page 6]

Internet-Draft                environment.*                     May 2026


   An open mandate, as used in this document and in
   [VI-CREDENTIAL-FORMAT], Section 4.5, is a Layer 2 mandate carrying
   constraints rather than final values, identified by a vct value with
   the .open suffix. environment.* constraints appear only in open
   mandates.

   VI mandate validators that do not recognize the environment.*
   namespace MUST reject open mandates containing environment.*
   constraints, per [VI-CONSTRAINTS], Section 5.4: open mandates with
   unknown constraint types fail closed regardless of strictness mode,
   because an unevaluable constraint in an open mandate leaves agent
   authority unbounded.  Because environment.* constraints appear only
   in open mandates, the rejection rule applies uniformly to every
   mandate in which environment.* constraints can appear.

   Validators implementing this document MUST evaluate environment.*
   constraints in the order specified in Section 5 and MUST treat any
   failure as terminal for the mandate.

1.4.  Document Organisation

   Section 2 establishes terminology and references.  Section 3 defines
   the constraint family and its membership criterion.  Section 4
   specifies family-wide vocabulary including the fields that appear,
   with identical semantics, on every member type, the field-scope
   taxonomy under which fields are classified, and the algorithm-agility
   framework under which signing-algorithm choice is made.  Section 5
   specifies family composition: conjunction semantics across family
   members, the L3 execution gate and its completeness rule, per-member
   diagnostic output, and the membership-criterion rationale these rules
   collectively encode.  Section 6 specifies register discipline.
   Section 7 covers Security Considerations specific to family-wide
   concerns.  Section 8 covers IANA Considerations including the
   proposed environment.* namespace registry.  Appendix A documents the
   relationship between this specification and the two existing
   reference type specifications.  Appendix B is reserved for future
   family-charter material per Section 6.7 Q3.

2.  Terminology and References

2.1.  Conventions and Definitions

   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.




Borthwick & Msebenzi    Expires 12 November 2026                [Page 7]

Internet-Draft                environment.*                     May 2026


   This document distinguishes between normative register and
   descriptive register, per the discipline catalogued at Section 6.
   Normative register uses RFC 2119 keywords in all capitals to bind
   implementers to specific behaviour.  Descriptive register uses
   lowercase synonyms (or explicit non-keyword phrasing) when the prose
   explains intent, rationale, or context rather than imposing a
   requirement.  The distinction is not stylistic; it determines what is
   conformance-checkable.

2.2.  Terms

   The following terms are defined for use in this document and in any
   specification of an environment.* constraint type that claims
   membership in the family.

   Constraint family.  A set of constraint types that share a common
   membership criterion, a common composition discipline, and a common
   family-wide vocabulary.  The environment.* family is the family this
   document defines.  The mandate.checkout.* and mandate.payment.*
   groupings within [VI-CONSTRAINTS] are not constraint families in the
   sense of this document; they are sub-namespaces of the transactional
   constraint vocabulary that share a prefix but do not share a
   membership criterion.

   Membership criterion.  A property that a constraint type MUST satisfy
   to qualify as a member of a constraint family.  Membership in the
   environment.* family requires that the constraint type's failure mode
   be gating: a failure of the constraint MUST terminate execution
   rather than degrade gracefully.  Section 3 specifies the criterion in
   normative detail.

   Transactional constraint.  A constraint that describes a property of
   the transaction itself — what is being purchased, by whom, for how
   much, against which credential.  The constraint families
   mandate.checkout.* and mandate.payment.* defined in [VI-CONSTRAINTS]
   are transactional.  Transactional constraints are evaluated against
   fulfillment values derived from Layer 3 mandates.  They do not
   require any external state observation at evaluation time.

   Environmental constraint.  A constraint that describes a property of
   the environment in which the transaction is executed — whether a
   venue is open, whether a wallet is funded, whether other relevant
   external conditions hold.  Environmental constraints are evaluated
   against external state observations attested by an entity outside the
   transaction.  The environment.* family is the set of environmental
   constraint types that satisfy the membership criterion of this
   document.




Borthwick & Msebenzi    Expires 12 November 2026                [Page 8]

Internet-Draft                environment.*                     May 2026


   Attestation.  A signed statement, issued by an entity outside the
   transaction, asserting that a specified environmental property held
   at a specified time.  Attestations carry a binding to a subject
   (whose property is described), a binding to an issuer (whose key
   signed the statement), a freshness window (within which the
   attestation is acceptable), and an evaluation result (the property
   held or did not hold).  The wire format and signing algorithm of an
   attestation are per-type concerns, specified by each constraint type.
   The role of the attestation in the verification path is family-wide
   and is specified by this document.

   Issuer.  The entity that produces an attestation by observing
   external state and signing the result.  Each constraint type
   specification names the trust-root mechanism by which a verifier
   discovers an issuer's signing key (for example, [RFC7517] JWKS or
   [RFC8615] well-known key registry).  The mandate-level binding to a
   specific issuer's signing key is enforced by the constraint instance,
   not by the family.

   Mandate issuer.  The party that constructs the Layer 2 mandate
   carrying environment.* constraints.  The mandate issuer selects the
   constraint instances, populates per-instance fields (including the
   trust-root binding to a specific attestation issuer), and signs the
   mandate per [VI-CREDENTIAL-FORMAT].  The mandate issuer and the
   attestation issuer are distinct roles; an entity MAY occupy both
   roles in a deployment but the security analysis treats them
   separately.

   Verifier.  The party that evaluates an environment.* constraint at
   the moment of execution.  A verifier fetches a fresh attestation per
   the constraint's binding, verifies the attestation signature against
   the issuer's published key, applies the family-wide vocabulary checks
   specified in Section 4 (including freshness against the constraint's
   max_attestation_age), and applies the per-type checks specified by
   the constraint type's specification.  A verifier MUST NOT accept an
   agent's claim of constraint satisfaction in place of independent
   verification.

   Agent.  The autonomous principal that constructs Layer 3 mandates
   under the authority delegated by a Layer 2 mandate.  In the family's
   evaluation path, an agent is a pre-Layer-3 verifier: it MUST itself
   satisfy every environment.* constraint before constructing Layer 3,
   with the agent-side discipline specified in Section 5.








Borthwick & Msebenzi    Expires 12 November 2026                [Page 9]

Internet-Draft                environment.*                     May 2026


   Type specification author.  The party that drafts and submits a
   constraint type specification proposing membership in the
   environment.* family.  The type specification author is bound by the
   requirements of Section 3.4 and Section 4.2.2 governing how new types
   are specified.

   Layer 2, Layer 3.  Credential layers as defined in
   [VI-CREDENTIAL-FORMAT].  Layer 2 carries the user-signed mandate that
   includes constraint instances; Layer 3 carries the agent-signed
   fulfillment that the verifier accepts or rejects against the
   constraint instances.  The terms are used in this document only to
   identify the points in the credential lifecycle at which family rules
   apply; this document does not modify the layer definitions.

   Open mandate.  A Layer 2 mandate carrying constraints rather than
   final values, identified by a vct value with the .open suffix per
   [VI-CREDENTIAL-FORMAT], Section 4.5. environment.* constraints appear
   only in open mandates.  The unknown-constraint rejection rule of
   [VI-CONSTRAINTS], Section 5.4 applies uniformly to every mandate in
   which environment.* constraints can appear.

   Family-wide field.  A field whose semantics are identical across
   every constraint type in the family, independent of trust-root or
   evaluation mechanism.  Family-wide fields are specified in this
   document.

   Per-type field.  A field whose semantics depend on the constraint
   type's trust-root mechanism or evaluation mechanism.  Per-type fields
   are specified by each constraint type's specification under the
   field-scope taxonomy of Section 4.

2.3.  References

   Citations in this section are short forms; the canonical reference
   list is in Section 9.

2.3.1.  Normative References

   [RFC2119], [RFC8174], [RFC8126], [VI-CONSTRAINTS],
   [VI-CREDENTIAL-FORMAT].

2.3.2.  Informative References

   [RFC1918], [RFC7517], [RFC7646], [RFC7800], [RFC8615], [RFC8725],
   [RFC8914], [RFC9421], [RFC6982], [RFC-SD-JWT],
   [ENVIRONMENT-MARKET-STATE], [ENVIRONMENT-WALLET-STATE].





Borthwick & Msebenzi    Expires 12 November 2026               [Page 10]

Internet-Draft                environment.*                     May 2026


3.  The environment.* Constraint Family

   This section defines the environment.* constraint family.  It
   specifies the membership criterion under which a constraint type
   qualifies as a member of the family, the namespace under which family
   members are named, and the discipline under which new family members
   may be added.

3.1.  Family Definition

   The environment.* constraint family is the set of Verifiable Intent
   constraint types that:

   (1) declare a property of the environment in which a transaction is
   executed, rather than a property of the transaction itself;

   (2) are evaluated against an attestation produced by an entity
   outside the transaction, rather than against fulfillment values
   derived from a Layer 3 mandate;

   (3) gate execution unconditionally on the result of that attestation;
   and

   (4) are named under the environment.* namespace.

   Constraint types satisfying these four properties MAY claim
   membership in the family by publishing a constraint type
   specification that conforms to this document.  Constraint types that
   satisfy fewer than all four properties are not members of the family,
   regardless of how their type identifier is named.

3.2.  Membership Criterion

   The membership criterion of the environment.* family is that the
   constraint type's failure mode MUST be gating.  A constraint type's
   failure mode is gating if and only if every defined failure path of
   the type's verification algorithm produces termination of execution
   rather than partial fulfillment, retry, or graceful degradation.













Borthwick & Msebenzi    Expires 12 November 2026               [Page 11]

Internet-Draft                environment.*                     May 2026


   A constraint type whose failure mode is OR-tolerable — that is, a
   type whose failure can be survived by composition with other passing
   constraints, or whose failure leads to a permitted reduced-
   functionality execution path — is by definition outside this family.
   The reasoning is structural: a constraint that does not gate
   execution is not load-bearing for execution safety, and a constraint
   that is not load-bearing for execution safety does not require the
   family-wide vocabulary, composition discipline, or trust-root
   machinery this document specifies.  Such a constraint may belong to
   some other family, or to no family at all, but it does not belong
   here.

   The membership criterion is not a per-type design choice that the
   type specification author makes when proposing a new type.  It is a
   property the type specification author MUST establish before
   proposing the type for the family.  A proposed type whose failure
   mode is not demonstrably gating MUST be rejected from the family on
   this ground alone.

3.3.  Namespace

   Family members are named under the environment.* namespace, using the
   dot-notation pattern of [VI-CONSTRAINTS].  The first component of the
   type identifier is the literal string environment; the second
   component identifies the specific environmental property the type
   addresses; further components MAY be used by future revisions for
   sub-classification.

   The environment.* namespace is registered for this purpose by
   Section 8 (IANA Considerations).  Names within the namespace SHOULD
   be chosen to identify the environmental property addressed (for
   example, market_state, wallet_state, regulatory_status) rather than
   the implementation, the issuer, or the wire format.

   IANA MUST NOT register a type identifier within the environment.*
   namespace that does not satisfy the membership criterion of
   Section 3.2.  The namespace and the criterion are coupled by design:
   a registered type within environment.* is, by registration, a member
   of the family in good standing, and a verifier encountering an
   environment.* identifier MAY rely on the family's discipline holding
   for that type.  Permitting the namespace to contain types that do not
   satisfy the criterion would defeat this property and is non-
   conforming.








Borthwick & Msebenzi    Expires 12 November 2026               [Page 12]

Internet-Draft                environment.*                     May 2026


3.4.  Adding New Family Members

   A new constraint type MAY be proposed for the environment.* family by
   a type specification author publishing a constraint type
   specification that:

   (1) demonstrates that the proposed type satisfies the membership
   criterion of Section 3.2;

   (2) specifies a trust-root mechanism (for example, [RFC7517] JWKS,
   [RFC8615] well-known key registry, or another mechanism with
   comparable security properties — meaning a mechanism that provides
   cryptographically authenticated key discovery, supports key rotation,
   and binds the discovered key to a specific issuer identity) under
   which a verifier discovers the issuer's signing key;

   (3) specifies a verification algorithm that consumes attestations
   produced under the trust-root mechanism and produces either
   constraint-satisfied or constraint-violated as terminal states, with
   no other terminal states;

   (4) declares the per-type fields the type adds to the family-wide
   vocabulary, classifying each under the field-scope taxonomy of
   Section 4.2;

   (5) declares the per-type MUST-implement signing algorithm and the
   per-type SHOULD/MAY extension set under the algorithm-agility
   framework of Section 4.3;

   (6) declares the per-type distinguishing field used for per-member
   diagnostic disambiguation under the family composition discipline of
   Section 5.4, with a fallback specified for cases where the
   distinguishing field is not present in a failing instance; and

   (7) conforms to the register discipline of Section 6 throughout.

   These seven requirements correspond to the Expert Review criteria
   specified in Section 8.3 for IANA registry purposes.  A constraint
   type specification meeting all seven requirements is conforming.  A
   specification missing any requirement is not conforming and the
   proposed type MUST NOT be registered until the gap is closed.

   The relationship among Section 3.1, Section 3.2, and this section is
   as follows.  Section 3.1 specifies the four properties that
   characterise a family member.  Section 3.2 names the gating-failure-
   mode property — property (3) of Section 3.1 — as the membership
   criterion.  This section's seven requirements establish the
   operational obligations a type specification must satisfy to



Borthwick & Msebenzi    Expires 12 November 2026               [Page 13]

Internet-Draft                environment.*                     May 2026


   demonstrate the four properties: requirement (1) demonstrates
   property (3) of Section 3.1 directly; requirements (2) and (3)
   establish the operational basis for property (2) (attestation-driven
   evaluation); requirements (4) through (7) establish the family-wide
   vocabulary, composition, and register obligations a member type must
   respect.  Property (1) of Section 3.1 (environmental, not
   transactional) and property (4) (named under the environment.*
   namespace) are pre-conditions that the type specification author
   asserts before invoking the seven requirements.  Together, Sections
   3.1, 3.2, and 3.4 specify the same family membership relation from
   descriptive, normative, and operational viewpoints respectively.

   This document does not prescribe the working-group process under
   which a conforming specification is reviewed and registered; that
   process is the responsibility of the standards body owning the
   environment.* registry.  This document specifies only the technical
   conditions a specification MUST meet to be eligible for registration.

3.5.  Handling of Weakened Type Specifications

   A registered family member's specification may be revised over its
   lifetime.  If a revision weakens the type's failure mode below
   gating, the type's specification no longer satisfies the membership
   criterion of Section 3.2, even though the type's registration in the
   environment.* registry still asserts membership.  This is a
   contradiction between registry state and specification content that
   this document does not resolve directly; resolution is a working-
   group concern, typically through deprecation per Section 8.4 followed
   by registration of a successor type.

   Implementations MUST NOT silently accept the weakened semantics.  If
   an implementation determines that a registered type's current
   specification no longer satisfies the membership criterion, the
   implementation MUST reject mandates containing instances of that type
   and SHOULD report the contradiction to the working group rather than
   continue verification under the weakened specification.  The MUST is
   the family's fail-closed posture; the SHOULD is on discoverability of
   the contradiction by the registry's governance body.

3.6.  Relationship to Other Constraint Families

   The environment.* family is one constraint family among potentially
   many in the Verifiable Intent ecosystem.  The mandate.checkout.* and
   mandate.payment.* groupings defined by [VI-CONSTRAINTS] are sub-
   namespaces of the transactional constraint vocabulary; they are not
   constraint families in the sense of this document because they do not
   share a single membership criterion across their members.  A future
   specification MAY define additional constraint families under the



Borthwick & Msebenzi    Expires 12 November 2026               [Page 14]

Internet-Draft                environment.*                     May 2026


   same family-definition discipline this document establishes, with
   their own namespaces, membership criteria, and per-family
   vocabularies.

   Composition of environment.* constraints with constraints from other
   families is specified in Section 5.  The family relationship is
   unidirectional: environment.* constraints gate execution and are
   evaluated before transactional constraints; transactional constraints
   do not gate environment.* evaluation.  This ordering is normative
   regardless of whether other families are defined in the future.

   Constraint frameworks that bind agent authority to credential layers
   via Selective Disclosure JWT [RFC-SD-JWT] or HTTP Message Signatures
   [RFC9421], including Verifiable Intent's Layer 2 mandate format and
   similar agent-authorization protocols, are interoperable with the
   environment.* family without modification to either side.  An
   environment.* constraint instance, embedded in the Layer 2 mandate's
   constraint list and covered by the mandate's JWS signature, inherits
   the mandate's [RFC7800] cnf-claim binding to the agent's proof-of-
   possession key.  The verifier's evaluation path under Section 5.5
   (environment.* before transactional constraints) sequences correctly
   with the host framework's own Layer-2-to-Layer-3 verification path:
   environment.* constraints gate the entire mandate evaluation,
   including any transactional constraints the host framework specifies.
   No registration of environment.* identifiers in the host framework's
   constraint registry is required for this interoperability;
   recognition of the environment.* namespace is sufficient for a host
   framework's verifier to delegate evaluation to an environment.*-aware
   verification path.  Per [VI-CONSTRAINTS], Section 5.4 and Section 1.3
   of this document, host frameworks whose validators encounter
   environment.* constraint instances without recognizing the namespace
   will reject the containing open mandates.  This rejection is
   automatic; environment.*-aware verification paths operate against
   open mandates that the host-framework validator does recognize,
   without requiring host-framework registration of the environment.*
   namespace as a precondition.

4.  Family-Wide Vocabulary

   This section specifies the vocabulary that all environment.*
   constraint types share.  Three classes of vocabulary are family-wide:

   (1) fields whose semantics are identical across every member type,
   specified in Section 4.1;

   (2) the field-scope taxonomy under which fields are classified as
   family-wide or per-type, specified in Section 4.2;




Borthwick & Msebenzi    Expires 12 November 2026               [Page 15]

Internet-Draft                environment.*                     May 2026


   (3) the algorithm-agility framework under which signing-algorithm
   choice is made, specified in Section 4.3.

   Per-type vocabulary — fields, signing algorithms, evaluation outputs,
   distinguishing identifiers — is specified by each constraint type's
   specification under the framework this section establishes.  This
   section does not specify per-type vocabulary.

4.1.  Family-Wide Fields

   The following fields appear, with identical semantics, on every
   environment.* constraint instance.

4.1.1.  attestation_url

   Type: string (HTTPS URL).  Required: Yes.

   The HTTPS endpoint at which the verifier fetches the signed
   attestation for this constraint instance.  The semantic role of
   attestation_url is identical across every environment.* constraint
   type: it names the location at which a fresh attestation can be
   obtained.  Per-type variance in the wire protocol (HTTP method,
   request body shape, response envelope) is carried by per-type fields
   and per-type interface specifications under Section 4.2.3, not by
   attestation_url.

   Verifiers MUST reject constraint instances whose attestation_url does
   not use the https scheme.  This rejection is fail-closed: an
   attestation fetched over an unencrypted channel is by definition
   untrusted, and the constraint instance carrying such a URL is
   malformed regardless of whether the unencrypted endpoint would have
   returned a valid signature.  Verifiers SHOULD apply additional
   transport-layer protections appropriate to the deployment context,
   including but not limited to rejection of URLs resolving to private
   address ranges, strict request timeouts, and bounded redirect
   handling.  The specifics of these protections are deployment-defined.

   The security implications of attestation_url — including server-side
   request forgery considerations and connection-time defences — are
   addressed in Section 7.7.

4.1.2.  max_attestation_age

   Type: integer (seconds).  Required: Yes.

   The maximum age in seconds, measured from the attestation's signing
   time to the verifier's evaluation time, beyond which the attestation
   MUST NOT be accepted.  The mandate issuer declares this value at



Borthwick & Msebenzi    Expires 12 November 2026               [Page 16]

Internet-Draft                environment.*                     May 2026


   constraint-instance construction time.  Verifiers MUST reject
   attestations whose age exceeds max_attestation_age, regardless of
   whether the attestation's own expiry has not yet passed.

   max_attestation_age MUST be a positive integer.  A constraint
   instance lacking an explicit max_attestation_age is malformed and
   verifiers MUST reject it.  There is no default value at the family
   layer; specifications adding default values per constraint type are
   non-conforming because the freshness window is the family's primary
   security property, and a default at any layer recreates the implicit-
   freshness exposure the family is designed to close.

   The freshness window is the primary exploitable surface of any
   environment.* constraint.  The window is the period during which a
   signed attestation, valid at the moment of signing, may no longer
   reflect the current state of the property the constraint addresses.
   An attestation that is technically still inside its issuer's TTL but
   is operationally stale — that is, its signing time predates a
   relevant change in the underlying environmental property — is the
   canonical failure case: market state can change between signing and
   execution, wallet state can change between signing and execution, and
   any environmental property the family addresses can change between
   signing and execution.  The mandate issuer is the party best
   positioned to declare the maximum tolerable window for the gated
   decision; max_attestation_age is the field through which that
   declaration is made.

   The attestation issuer's TTL (the issuer-side time after which the
   issuer no longer claims the attestation is valid) and
   max_attestation_age (the consumer-side time after which the verifier
   no longer accepts the attestation) serve different parties and MUST
   be independently configurable.  A verifier MUST honour both: an
   attestation that has passed either bound is unacceptable.  The
   narrower of the two governs in practice.

   The security implications of max_attestation_age — including
   attestation replay considerations — are addressed in Section 7.1.

4.2.  Field-Scope Taxonomy

   The environment.* constraint family contains fields that appear under
   identical names in multiple constraint types.  A shared field name
   does not, by itself, imply shared semantics: some fields carry
   identical meaning across types, while others have parallel-but-
   mechanism-specific meaning tied to each type's trust-root or
   evaluation mechanism.  To prevent ambiguity, each field in the family
   MUST be classified by its specification author under one of the
   categories defined below.



Borthwick & Msebenzi    Expires 12 November 2026               [Page 17]

Internet-Draft                environment.*                     May 2026


   The family currently recognises three scope categories:

   family-wide-trust-root-agnostic.  The field carries identical
   semantics across every environment.* constraint type, independent of
   the trust-root mechanism each type uses.  A single verification code
   path handles the field for every type in the family.

   per-type-trust-root-mechanism-bound.  The field's operational
   semantics depend on the specific trust-root mechanism of the
   constraint type ([RFC7517] JWKS, [RFC8615] well-known key registry,
   or another mechanism).  The field name may appear in multiple
   specifications with parallel but mechanism-specific semantics.

   per-type-evaluation-mechanism-bound.  The field's operational
   semantics depend on the constraint type's evaluation mechanism: the
   output shape the evaluator produces or the wire-protocol binding to
   the evaluator.  The field name may appear in multiple specifications
   with parallel but evaluation-specific semantics; distinct from per-
   type-trust-root-mechanism-bound in that the binding is to how the
   attestation is produced and shaped, not to how the signing key is
   discovered.

   Within Section 4.2, the term "field" encompasses both constraint
   schema fields and, where operationally relevant, claims within the
   signed attestation payload.

4.2.1.  Scope Declarations for Family-Wide Fields

   The family-wide fields specified in Section 4.1 are classified as
   follows:

   attestation_url: family-wide-trust-root-agnostic.  Its semantic role
   — the HTTPS endpoint at which the verifier fetches the signed
   attestation — is identical across every environment.* constraint
   type.  Per-type variance in HTTP method or request body is carried by
   neighbouring per-type fields, not by the URL field itself.

   max_attestation_age: family-wide-trust-root-agnostic.  The freshness
   window is a temporal property of the attestation signing event,
   independent of how the verifier retrieves the signing key.

4.2.2.  Scope Declarations for Per-Type Fields

   Type specification authors MUST declare the scope of every per-type
   field they introduce.  Declarations MUST appear in a Field Scope
   Declaration section of the type specification.  The declaration MUST
   classify the field under one of the three categories of Section 4.2
   and MUST justify the classification in prose.



Borthwick & Msebenzi    Expires 12 November 2026               [Page 18]

Internet-Draft                environment.*                     May 2026


   The type specifications referenced in Appendix A carry such
   declarations for the per-type fields they introduce.  This document
   does not enumerate those fields, because doing so would couple the
   family-definition layer to the current set of registered types in a
   way that future revisions of either type's specification could
   invalidate.

4.2.3.  Adding Scope Categories

   The three categories of Section 4.2 are sufficient for every field
   introduced by every member type registered at the time of this
   document's publication.  Type specification authors proposing new
   fields SHOULD place them under one of the three existing categories.

   A type specification author MAY propose a new scope category.  Such a
   proposal is a working-group revision of this document, not a per-type
   design choice.  The proposing specification MUST demonstrate that no
   existing category is sufficient for the field's classification, and
   the working group MUST converge on the new category's definition and
   integration with the existing three before any registered type uses
   it.

4.3.  Algorithm Agility

   The environment.* constraint family is algorithm-agnostic at the
   family layer.  This document does not name a signing algorithm that
   all family members must use, and it does not prefer any algorithm
   over any other.  Algorithm choice is a per-type concern, made by each
   constraint type specification under the framework this section
   establishes.

   The framework follows the discipline of [RFC8725], Section 3.1: each
   constraint type specification MUST declare a single MUST-implement
   signing algorithm that all conformant verifiers for that type MUST
   support, and MAY declare a SHOULD-implement extension set and a MAY-
   implement extension set.  Verifiers negotiate the algorithm per
   constraint instance by reading the attestation's algorithm
   declaration and confirming that the declared algorithm is in their
   supported set for the constraint type.  Verifiers MUST reject
   attestations whose algorithm is not in the type's supported set; this
   rejection is fail-closed and is not a permitted silent downgrade.

   Algorithm deprecation within a registered family member is a per-type
   concern.  Type specification authors SHOULD specify, in the type's
   specification, a deprecation mechanism for the type's MUST-implement
   algorithm before that algorithm is needed — including the conditions
   under which the algorithm is deprecated, the timeline for verifier
   migration to a successor MUST-implement, and the backward-



Borthwick & Msebenzi    Expires 12 November 2026               [Page 19]

Internet-Draft                environment.*                     May 2026


   compatibility guarantees during the transition.  The family-wide
   obligation is structural: every type specification MUST declare its
   current MUST-implement algorithm, and verifiers MUST honour the
   declaration without fallback.  Deprecation discipline ensures that
   the family does not inherit a brittle commitment to any specific
   algorithm beyond the cryptographic lifetime that algorithm provides.

   The framework is deliberately minimal at the family layer because the
   security properties of signing-algorithm choice are well-specified by
   the JOSE family of specifications and by [RFC8725].  The family-layer
   obligation is structural: every type specification MUST declare its
   choice explicitly, and verifiers MUST honour the declaration without
   fallback.  This obligation prevents the family from accidentally
   inheriting a single-algorithm constraint by implementation
   convergence rather than by specification.

   A type specification's choice of MUST-implement algorithm is not
   constrained by this document.  The choice is properly made on the
   basis of the reference implementation's signing stack, the wider VI
   ecosystem's existing JWS infrastructure, the operational properties
   of the algorithm at the type's expected verification volume, and the
   security properties relevant to the type's threat model.  This
   document is silent on these factors because they are per-type
   concerns; it requires only that the choice be made, declared, and
   respected.

5.  Family Composition

   This section specifies how environment.* constraints compose with
   each other and with constraints from other families.  Six concerns
   are addressed: conjunction semantics across family members
   (Section 5.1), mixed pass/fail handling (Section 5.2), the L3
   execution gate and its completeness rule (Section 5.3), per-member
   diagnostic output (Section 5.4), composition with other families
   (Section 5.5), and the rationale these rules collectively encode
   (Section 5.6).

5.1.  Conjunction Semantics

   The environment.* family is a conjunction.  A mandate satisfies the
   family's gate if and only if every environment.* constraint instance
   in the mandate passes.  There is no partial-fulfillment path within
   the family, no quorum across members, and no precedence by which one
   member can override another.

   This semantic is family-wide and is not a per-type design choice.  A
   constraint type whose composition with sibling family members is
   anything other than conjunction is by definition outside the family,



Borthwick & Msebenzi    Expires 12 November 2026               [Page 20]

Internet-Draft                environment.*                     May 2026


   because the membership criterion of Section 3.2 requires that each
   type's failure mode be gating, and a gating failure cannot be
   survived by composition with passing siblings.

5.2.  Mixed Pass/Fail

   When one environment.* constraint instance passes and another fails
   in the same mandate, the family's gate fails.  The passing instance
   does not rescue the failing instance.  This rule applies regardless
   of:

   (1) whether the instances are of the same type or different types;

   (2) whether the instances bind to the same subject or to different
   subjects;

   (3) the order in which the instances appear in the mandate; and

   (4) the order in which the verifier evaluated the instances.

   A verifier that returns a passing result for a mandate containing one
   passing and one failing environment.* constraint is non-conforming.

5.3.  L3 Execution Gate and Completeness

   The environment.* family gates Layer 3 acceptance.  A verifier MUST
   NOT accept a Layer 3 mandate whose Layer 2 mandate carries any failed
   environment.* constraint, regardless of whether the verifier
   evaluated the failed constraint first, last, or in any other order.

   The verifier MUST evaluate every environment.* constraint in the
   mandate to completion before refusing Layer 3, even after the first
   failure has been observed.  This is the completeness requirement.
   Short-circuit evaluation of environment.* constraints — terminating
   the family-evaluation pass at the first failure without evaluating
   subsequent members — is non-conforming because it denies downstream
   consumers the per-member evidence the family's diagnostic output
   (Section 5.4) depends on.













Borthwick & Msebenzi    Expires 12 November 2026               [Page 21]

Internet-Draft                environment.*                     May 2026


   The completeness requirement applies to the verifier-side
   L3-acceptance evaluation path.  It does not apply to the agent-side
   pre-L3-creation evaluation path.  An agent constructing Layer 3 MUST
   itself satisfy every environment.* constraint before constructing
   Layer 3, and an agent that observes any environment.* failure during
   pre-L3-creation evaluation MUST halt construction at the first
   failure as a fail-closed agent-side response.  The agent's halt is
   operationally distinct from the verifier's diagnostic-completeness
   obligation: the agent's purpose is to avoid producing a Layer 3 that
   the verifier would refuse; the verifier's purpose is to produce
   complete diagnostic output even when refusing.

   Evaluation of constraints from other families (for example,
   transactional constraints under mandate.*) after a confirmed
   environment.* failure remains implementation-defined.  A verifier MAY
   evaluate them for diagnostic completeness or MAY skip them for
   efficiency, provided the resulting refusal of Layer 3 is unambiguous.

5.4.  Per-Member Diagnostic Output

   Each failed environment.* constraint MUST produce its own entry in
   the verifier's violations output.  Verifiers MUST NOT collapse
   multiple environment.* failures into a single generic violation
   entry.

   Each violation entry MUST carry two identifiers:

   (1) the array index of the failing constraint within the mandate's
   constraints array, as the primary machine identifier.  The index is
   unambiguous across any combination of constraint types and across
   mandates containing multiple instances of the same type;

   (2) a human-readable identifier derived from the failing constraint's
   distinguishing field, as the secondary identifier intended for
   operator diagnostics and dispute resolution.

   The selection of the distinguishing field is a per-type obligation.
   Each constraint type specification author MUST declare which field of
   the type is the distinguishing field, and MUST specify a fallback
   when the distinguishing field is not present in the failing instance
   (for example, when the constraint's signed attestation could not be
   obtained at all).  The reference type specifications cited in
   Appendix A carry such declarations for their respective types.








Borthwick & Msebenzi    Expires 12 November 2026               [Page 22]

Internet-Draft                environment.*                     May 2026


   The diagnostic output requirement is family-wide because the family's
   audit value depends on it.  A mandate carrying multiple environment.*
   constraints — whether multiple instances of the same type or
   instances of multiple types — produces, at refusal, an audit record
   showing exactly which environmental conditions failed and which held.
   Collapsing per-member diagnostics destroys that record.

5.5.  Composition with Other Families

   environment.* constraints MUST be evaluated before constraints from
   other families in the same mandate.  If any environment.* constraint
   fails, the verifier MUST refuse Layer 3 regardless of how constraints
   from other families would evaluate.  The ordering is one-directional:
   environment.* gates execution, and other families do not gate
   environment.* evaluation.

   The rationale is structural.  Evaluating transactional constraints
   (allowed merchants, allowed payees, amount ranges) before confirming
   the execution environment is valid exposes the verifier to a time-of-
   check-to-time-of-use race in which a transactional constraint passes
   against a Layer 3 that names an environment the verifier has not yet
   attested. environment.* evaluation precedes transactional evaluation
   so that the environment is established before the transaction is
   authorised against it.

   This ordering is normative regardless of whether other constraint
   families exist at the time of this document's publication or are
   added later.  A future family with its own membership criterion and
   its own family-definition specification MUST document its own
   ordering relationship to environment.*, but environment.* itself is
   not subject to ordering preemption by any other family.

5.6.  Rationale

   The composition rules of Sections 5.1 through 5.5 are not arbitrary.
   Two arguments, co-equal and reinforcing, motivate them.

   The semantic argument: each member of the environment.* family
   answers an independent question about the world at the moment of
   execution — is this venue open? is this wallet funded? does this
   counterparty's regulatory status hold?  Because the questions are
   independent, their answers compose as conjunction, not disjunction: a
   failure on any member removes the basis for execution.  There is no
   construction in which "the venue is open OR the wallet is funded" is
   the correct gate for an autonomous transaction.  Both must hold.






Borthwick & Msebenzi    Expires 12 November 2026               [Page 23]

Internet-Draft                environment.*                     May 2026


   The architectural argument: conjunction also falls out of the
   family's membership criterion (Section 3.2) directly.  A constraint
   type whose failure mode is OR-tolerable is, by the criterion, outside
   the family.  If a constraint's failure is survivable by composition
   with passing siblings, the constraint is not gating execution; if it
   is not gating execution, it does not satisfy the membership
   criterion; if it does not satisfy the criterion, it is not in the
   family.  Conjunction is therefore not a design choice the working
   group makes when registering each new type — it is a consequence of
   the membership criterion the type satisfied to enter the family in
   the first place.

   The two arguments meet at the same conclusion from independent
   directions.  The semantic argument applies regardless of how the
   family is defined.  The architectural argument applies regardless of
   what the family means.  That both arguments converge on conjunction
   is the strongest evidence that conjunction is the right composition
   rule for environment.*.

   The per-member diagnostic requirement of Section 5.4 follows from the
   same logic.  Collapsing per-member diagnostics would destroy the
   audit trail that makes the family load-bearing for downstream dispute
   resolution.  Preserving per-member diagnostics makes every signed
   attestation recoverable from the verifier's output, and makes dispute
   resolution an application-layer concern with complete evidence rather
   than a debugging exercise.  Both type specifications cited in
   Appendix A already encode this discipline; this document promotes it
   from per-type rationale to family-wide normative requirement so that
   every future family member inherits it without re-litigation.

6.  Register Discipline

   This section specifies the discipline under which RFC 2119 keywords
   are used in this document and in any specification of an
   environment.* constraint type that claims membership in the family.
   The discipline distinguishes normative register from descriptive
   register and constrains the use of each.

   The discipline is family-wide.  A constraint type specification that
   does not conform to this section is non-conforming as a family
   member, regardless of the soundness of its technical content, because
   mixed register defeats the conformance-checkability that makes the
   family's normative statements actionable for implementers.








Borthwick & Msebenzi    Expires 12 November 2026               [Page 24]

Internet-Draft                environment.*                     May 2026


6.1.  Normative Register

   Normative register uses RFC 2119 keywords (MUST, MUST NOT, REQUIRED,
   SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED,
   MAY, OPTIONAL) in all capitals, per [RFC2119] and [RFC8174], to bind
   implementers to specific behaviour.

   Normative register specifies behaviour that an implementation either
   satisfies or fails to satisfy; it is conformance-checkable.  Any RFC
   2119 keyword in all capitals MUST appear only in a sentence that
   imposes a requirement on a named implementer (an agent, a verifier, a
   mandate issuer, an attestation issuer, a type specification author,
   IANA, or a designated expert).  The Section 2.1 boilerplate per
   [RFC8174] binds the interpretation throughout this document.

6.2.  Descriptive Register

   Descriptive register explains intent, rationale, precedent, context,
   or structural reasoning.  It uses lowercase synonyms (or explicit
   non-keyword phrasing) where RFC 2119 keywords would otherwise appear.

   Descriptive register is not conformance-checkable.  It exists to make
   the normative register actionable: a reader of normative requirements
   is better served by descriptive prose explaining why the requirement
   holds than by the requirement standing alone without context.
   Descriptive prose SHOULD use lowercase synonyms ("must" rather than
   MUST, "should" rather than SHOULD, "may" rather than MAY) when no new
   requirement is being imposed.  Where the lowercase synonym would be
   ambiguous about whether it imposes a requirement, explicit non-
   keyword phrasing ("the section establishes", "the type specification
   author's choice is", "the framework requires") is preferred over
   either capitalisation.

   The discipline matters because a specification that mixes normative
   and descriptive register — for example, by using all-capitals MUST in
   a rationale paragraph that does not impose a requirement — produces
   ambiguous conformance: a reviewer or implementer reading prose with
   all-capitals keywords in descriptive context cannot tell whether the
   text imposes a requirement or merely describes one.  Resolving such
   ambiguity requires reading the surrounding sentences to infer intent,
   which is precisely the work the discipline is designed to avoid.










Borthwick & Msebenzi    Expires 12 November 2026               [Page 25]

Internet-Draft                environment.*                     May 2026


6.3.  Redundancy Avoidance

   [RFC2119], Section 3 establishes that SHOULD and RECOMMENDED carry
   identical normative force; [RFC2119], Section 5 establishes that MAY
   and OPTIONAL carry identical normative force.  Field labels, section
   headers, and parenthetical qualifiers that duplicate the normative
   keyword present in the containing sentence add visual weight without
   adding normative content.

   A specification SHOULD NOT pair a label such as "(RECOMMENDED)" with
   a sentence whose verb is already SHOULD, and SHOULD NOT pair a label
   such as "(OPTIONAL)" with a sentence whose verb is already MAY.  The
   keyword in the containing sentence carries the requirement; the
   parenthetical label adds register noise.

   This rule applies to specification authors as a stylistic discipline.
   A specification that violates it remains technically conformant; the
   rule's purpose is to keep the document surface clean enough that the
   discipline of Sections 6.1 and 6.2 is visible to a reviewer scanning
   for register issues.

6.4.  Scope of Application

   Normative requirements MUST name the implementer they bind.  A
   requirement that does not name its implementer is ambiguous and the
   ambiguity is not resolved by context.

   Where a requirement could be read at multiple layers of the stack —
   for example, "verifiers MUST re-verify" read as a network-transport
   obligation versus an application-layer obligation — the specification
   text MUST name the application-layer scope explicitly.  A sentence
   such as "verifiers MUST re-verify the attestation against the chain's
   then-current state at settlement time" reads ambiguously without
   scope: it could bind a chain client, an RPC layer, a cryptographic
   library, or the VI verifier's L3-acceptance logic.  The specification
   text MUST name which.

   The application-layer scope of family-wide requirements in this
   document is the VI verifier's L3-acceptance logic.  Requirements at
   other layers (network transport, cryptographic library, chain client)
   are out of this document's scope and are governed by the
   specifications appropriate to those layers.









Borthwick & Msebenzi    Expires 12 November 2026               [Page 26]

Internet-Draft                environment.*                     May 2026


6.5.  Forward Rule for New Sections and New Specifications

   New sections introduced in future revisions of this document, and all
   sections of any constraint type specification that claims membership
   in the environment.* family, MUST apply the rules of Sections 6.1
   through 6.4 at introduction.

   Editorial register polish — conversion of all-capitals to lowercase
   in descriptive context, removal of RECOMMENDED/SHOULD redundancy,
   application-layer scope naming — is a patch-level revision and does
   not require a minor-version bump in any specification that adopts
   patch-level versioning.  The rule is not that the discipline be
   applied perfectly on first draft, but that it be applied without
   exception by the time a specification is presented for working-group
   adoption.

6.6.  Relationship to Section 2.1 Conventions

   This section extends the Section 2.1 Conventions and Definitions
   statement.  Section 2.1 binds the interpretation of RFC 2119 keywords
   when they appear in all capitals per [RFC8174].  This Section 6
   specifies the editorial discipline for when RFC 2119 keywords SHOULD
   appear in all capitals (Section 6.1, normative register) versus when
   they SHOULD NOT (Section 6.2, descriptive register).  Together,
   Section 2.1 and Section 6 establish the register discipline of the
   environment.* family.

6.7.  Open Questions

   This section reproduces three questions that the type specifications
   cited in Appendix A raise about register discipline and that the
   working group has not yet converged on.  The questions are reproduced
   here so that working-group review of this document addresses them as
   family-wide concerns rather than per-type concerns.  The current
   draft takes provisional positions on each; the working group is
   invited to revise.

   Q1.  Is this section informative — describing the discipline that the
   family's normative sections already follow — or normative — binding
   future type specifications to the rules at Sections 6.1 through 6.5?
   Provisional position: Sections 6.1 through 6.5 are treated as
   normative (with all-capitals RFC 2119 keywords throughout) and
   Sections 6.6 and 6.7 as informative.  The working group may
   reclassify any subsection.

   Q2.  Should the family adopt a formal register-discipline audit
   cadence — for example, a pre-release audit before each minor version
   of a type specification — or is the ad-hoc audit pattern established



Borthwick & Msebenzi    Expires 12 November 2026               [Page 27]

Internet-Draft                environment.*                     May 2026


   by the type specifications cited in Appendix A sufficient?
   Provisional position: The current draft does not mandate a cadence;
   the rule of Section 6.5 is that the discipline be applied by the time
   a specification is presented for adoption.

   Q3.  What is the relationship between this section and other family-
   charter material that may be added to future revisions?  Provider
   neutrality, peer-author coordination discipline, patch-level
   versioning conventions, and lockstep commit patterns across sibling
   specifications are family-charter concerns that the type
   specifications cited in Appendix A have raised.  Provisional
   position: The working group decides whether such material
   consolidates into a future revision of this section, into a separate
   family-charter section, or into a hybrid structure; the current draft
   does not foreclose.

7.  Security Considerations

   This section enumerates security concerns that apply family-wide to
   environment.* constraints.  Per-type security considerations — those
   tied to a specific trust-root mechanism, a specific signing
   algorithm, or a specific evaluation mechanism — are addressed by each
   constraint type's specification.  The family-wide concerns below
   apply to every member type and to every implementation of every
   member type.

7.1.  Attestation Replay

   A signed attestation is a bearer artifact within its acceptance
   window.  Any party in possession of a valid signed attestation may
   present it to a verifier, and the verifier — applying only the
   cryptographic checks the attestation supports — will accept it.  The
   acceptance window is bounded by the attestation's expiry and further
   narrowed by the constraint instance's max_attestation_age
   (Section 4.1.2), but within that window the attestation is
   replayable.

   For deployment contexts where attestation reuse would authorise
   duplicate state changes (for example, payment execution, where an
   attestation justifying one settlement could otherwise justify a
   second settlement against the same wallet within the freshness
   window), verifiers MUST maintain a per-attestation deduplication
   cache keyed on the attestation's unique identifier.  For deployment
   contexts where attestation reuse is benign (for example, idempotent
   read-only operations), verifiers SHOULD maintain a per-attestation
   deduplication cache as defence in depth, but MAY rely on the
   freshness window alone.  The unique identifier and the cache TTL are
   per-type concerns: each constraint type specification names the field



Borthwick & Msebenzi    Expires 12 November 2026               [Page 28]

Internet-Draft                environment.*                     May 2026


   its attestations carry as the unique identifier, and the cache TTL is
   bounded by max_attestation_age plus an implementation-defined margin
   to absorb clock skew.

   The replay surface is family-wide because it follows from the bearer-
   artifact property of signed attestations, which is itself family-
   wide: every environment.* attestation is a signed statement that a
   verifier accepts on the strength of the signature, and any signed
   statement that travels over the wire is replayable to any verifier
   that accepts the same signature.  The specific mitigation varies by
   deployment context.

7.2.  Issuer Trust Bootstrapping

   The security of any environment.* constraint depends on the verifier
   correctly establishing the attestation issuer's signing key.  Each
   constraint type names a trust-root mechanism (Section 4.2) under
   which a verifier discovers the key — JWKS at a known HTTPS URL, a
   well-known key registry per [RFC8615], or another mechanism — but
   every trust-root mechanism reduces, eventually, to an out-of-band
   initial trust establishment.

   Verifiers SHOULD establish initial trust in an attestation issuer
   through at least one channel independent of the trust-root mechanism:
   DNSSEC for the issuer's domain, certificate transparency log
   inspection for the issuer's TLS certificates, published key
   fingerprints in a venue independent of the issuer's primary
   infrastructure, or out-of-band fingerprint comparison with a known-
   good party.  The specifics of initial-trust channels are deployment-
   defined; the family-wide requirement is that no implementation rely
   on the trust-root mechanism alone to bootstrap trust in a previously-
   unknown issuer.

   This concern is family-wide because the trust-root mechanism's job is
   to make ongoing key discovery secure once initial trust is
   established, not to establish initial trust ex nihilo.  A verifier
   that fetches an unknown issuer's JWKS over HTTPS and accepts whatever
   keys are returned has authenticated only that the JWKS was served by
   the host named in the URL.  It has not authenticated that the host
   named in the URL is the issuer the mandate intended.  Initial trust
   is the gap between those two facts.










Borthwick & Msebenzi    Expires 12 November 2026               [Page 29]

Internet-Draft                environment.*                     May 2026


7.3.  Constraint Stripping and Insertion

   An attacker with the ability to modify a Layer 2 mandate could remove
   environment.* constraint instances from the mandate before the agent
   or verifier evaluates it.  A mandate with environment.* constraints
   stripped expands the agent's authority to environments the user did
   not authorise.

   The defence against constraint stripping is the Layer 2 signature,
   which covers the full constraint list as presented at issuance time.
   Any modification to the constraint list — including removal or
   insertion of an unauthorised constraint — invalidates the signature.
   Verifiers MUST reject any Layer 2 mandate whose signature does not
   validate over the full constraint list as presented, and
   implementations MUST NOT accept mandates whose verified signature
   covers only a subset of the declared constraints.

   The same defence applies to constraint insertion: a mandate issuer
   acting outside the user's authorisation cannot add a constraint
   instance to a user-signed mandate without invalidating the user's
   signature.  Note that this defence depends on the mandate issuer's
   honesty regarding what the user authorised at the time the mandate
   was signed; it does not protect against a mandate issuer who
   constructs a mandate with constraint instances the user did not
   authorise.  Trust in the mandate issuer's faithfulness to user intent
   is a deployment-level concern outside the scope of this document.

   This concern is family-wide because it follows from the family's
   insertion into Verifiable Intent's Layer 2 mandate format: any
   constraint in any family is subject to stripping and insertion, and
   the Layer 2 signature is the family-agnostic defence.  The family
   inherits the defence; it does not add new defences.

7.4.  Substitution of Attestation Endpoints

   A more subtle attack than stripping is substitution: an attacker who
   can modify a Layer 2 mandate replaces a constraint's attestation_url
   with a URL pointing to an attacker-controlled endpoint that returns
   valid-looking signed responses.  The signature on the substituted
   attestation is, by construction, valid against whatever key the
   attacker chose; the trust-root mechanism's binding to a specific
   issuer's key is what defeats the attack.

   The defence is per-type, but its family-wide minimum is specified
   here.  Each constraint type specification MUST identify, at minimum,
   two binding fields signed into the Layer 2 mandate alongside
   attestation_url: an issuer-identifier binding (the field that names
   which attestation issuer's key is acceptable) and a key-identifier



Borthwick & Msebenzi    Expires 12 November 2026               [Page 30]

Internet-Draft                environment.*                     May 2026


   binding (the field that names which specific key, within that
   issuer's key set, is acceptable).  For [RFC7517] JWKS-based types,
   this typically means a JWKS URL, a key identifier, and an issuer
   identifier; for [RFC8615] well-known key registry-based types, this
   typically means a key identifier together with the issuer identity
   from which the key registry URL is derived.  An attacker who
   substitutes attestation_url MUST also substitute every binding field
   to evade detection, and the substitution is detectable provided the
   verifier honours every binding.

   The family-wide minimum is that every constraint type's binding
   fields — at minimum, the issuer-identifier binding and the key-
   identifier binding — MUST be signed into the Layer 2 mandate by the
   mandate issuer at issuance time and MUST be honoured by verifiers at
   evaluation time.  A type specification whose verification algorithm
   does not honour every declared binding field, or whose declared
   binding fields do not satisfy the family-wide minimum, is non-
   conforming.  This minimum applies independent of trust-root
   mechanism: future trust-root mechanisms admitted under Section 3.4(2)
   ("comparable security properties") inherit the same issuer-identifier
   and key-identifier binding obligations.

7.5.  Mandate-Issuer-Versus-Attestation-Issuer Trust Separation

   Section 2.2 distinguishes the mandate issuer (the party that
   constructs the Layer 2 mandate) from the attestation issuer (the
   party that signs the attestation the verifier evaluates against).
   The two roles are separately trusted and separately compromised.  A
   compromised mandate issuer could construct mandates with attestation
   bindings pointing to compromised attestation issuers; a compromised
   attestation issuer could sign valid attestations for false world-
   states.  Each compromise is independently consequential, and each
   role's trust establishment is independently the deployment's
   responsibility.

   The family does not specify formal trust-establishment procedures for
   either role; that work belongs in Verifiable Intent's threat model
   and in deployment-specific operational documentation.  The family-
   wide requirement is that the two roles MUST NOT be conflated by an
   implementation.  An implementation that treats a mandate issuer's
   signature as evidence about the attestation issuer's signing key — or
   vice versa — is non-conforming because the two signatures bind
   different facts and a verifier acting on one as evidence for the
   other has reduced its security to whichever role is currently more
   trusted.






Borthwick & Msebenzi    Expires 12 November 2026               [Page 31]

Internet-Draft                environment.*                     May 2026


   A concrete check that follows from this requirement: a verifier MUST
   NOT use the mandate issuer's identity (or any binding field attesting
   to the mandate issuer) as input to the verification of the
   attestation's signature.  The attestation signature is verified
   against the attestation issuer's key, discovered through the trust-
   root mechanism, with no mandate-issuer-derived inputs.  This check is
   conformance-testable.

   This concern is family-wide because the role distinction is family-
   wide: every environment.* constraint instance carries both a mandate-
   issuer signature (over the Layer 2 mandate) and an attestation-issuer
   signature (over the attestation the constraint binds to), and every
   verification path involves both signatures.  Conflating them is a
   verification-path error rather than a per-type error.

7.6.  Time Synchronisation

   The freshness check of Section 4.1.2 (max_attestation_age) requires
   that the verifier's clock is reasonably synchronised with the
   attestation issuer's clock.  A clock skew exceeding
   max_attestation_age would cause the verifier to reject all
   attestations from a correctly-operating issuer.

   Implementations SHOULD use clock-synchronisation mechanisms
   appropriate to the deployment context (such as NTP) and SHOULD log
   clock-skew-related verification failures distinctly from other
   failure modes to aid diagnosis.  The family does not specify a clock-
   synchronisation mechanism; the family-wide requirement is that
   implementations use a mechanism whose accuracy is bounded below the
   smallest max_attestation_age value the implementation expects to
   encounter in production.

   This concern is family-wide because max_attestation_age is family-
   wide.  A constraint type specification that uses a clock-anchored
   field other than max_attestation_age inherits the same concern; this
   section's requirement applies to whichever clock-anchored field the
   type uses.

7.7.  SSRF and Other Verifier-Initiated Fetch Risks

   The attestation_url field of every environment.* constraint instance
   is a mandate-controlled URL that the verifier will fetch.  Without
   protection, this is a server-side request forgery primitive: an
   attacker who can modify the Layer 2 mandate (or who can introduce
   constraint instances at mandate construction time) can direct the
   verifier to fetch arbitrary URLs.





Borthwick & Msebenzi    Expires 12 November 2026               [Page 32]

Internet-Draft                environment.*                     May 2026


   Verifiers MUST apply transport-layer protections appropriate to the
   deployment context.  Family-wide minimum requirements:

   (1) reject URLs that do not use the https scheme (already required by
   Section 4.1.1);

   (2) reject URLs whose hostnames resolve to address ranges not
   appropriate for outbound verifier traffic.  At minimum, this includes
   the [RFC1918] private address ranges (10.0.0.0/8, 172.16.0.0/12,
   192.168.0.0/16), loopback (127.0.0.0/8), link-local (169.254.0.0/16),
   and any deployment-specific exclusion list;

   (3) bound request timeouts to a value short enough that verifier-side
   SSRF attempts cannot extract significant information through timing
   observation;

   (4) bound redirect handling to at most one redirect, and apply the
   same address-range and scheme checks to redirect targets;

   (5) re-resolve the hostname at connection time and apply the address-
   range checks of (2) to the resolved IP, defending against DNS
   rebinding attacks where a domain resolves to a public IP at fetch-
   time and a private IP at connection-time.

   The specific timeout values, deployment-specific exclusion list
   extensions, and redirect-handling specifics beyond the minima above
   are deployment-defined.  Per-type specifications MAY tighten these
   requirements but MUST NOT relax them; a type specification that
   permits non-HTTPS URLs, omits any of the address-range exclusions in
   (2), or admits unbounded redirects is non-conforming.

   This concern is family-wide because every environment.* constraint
   instance carries an attestation_url and every verifier fetches it.
   The mitigation is family-wide minimum plus deployment-specific
   tightening.

7.8.  Signer Failure Handling

   The trust-root mechanisms specified by per-type specifications (e.g.,
   [RFC7517] JWKS, [RFC8615] well-known key registry) provide
   cryptographically authenticated key discovery under correct
   operation.  They do not address the failure mode in which an
   attestation issuer publishes signatures or key material that, while
   cryptographically well-formed, are operationally incorrect — for
   example, signatures over stale or misconfigured state, or key-
   rotation events that publish keys in an inconsistent intermediate
   state.  Such failures are not theoretical: cryptographic
   infrastructure depending on similar trust-root mechanisms (DNSSEC



Borthwick & Msebenzi    Expires 12 November 2026               [Page 33]

Internet-Draft                environment.*                     May 2026


   zone-signing key rollovers, certificate transparency log misissuance)
   has experienced documented outages of this class.

   A constraint type's verification algorithm under Section 3.4(3)
   terminates as constraint-satisfied or constraint-violated; it does
   not have a third terminal state for "issuer is currently
   malfunctioning."  Verifiers SHOULD therefore implement an
   application-layer mechanism analogous to the Negative Trust Anchor
   pattern of [RFC7646] under which a verifier MAY temporarily decline
   to validate against a specific issuer's keys when that issuer is
   known to be publishing incorrect attestations.  Verifiers SHOULD
   additionally surface the reason for declined verification through a
   mechanism analogous to Extended DNS Errors [RFC8914], so that
   downstream consumers (agents, mandate issuers, audit systems) can
   distinguish issuer-failure refusals from constraint-violation
   refusals.

   The family-wide requirement is operational rather than cryptographic:
   the verification algorithm continues to fail closed regardless of
   whether issuer-failure handling is implemented, and an agent
   observing any failure halts construction of Layer 3 per Section 5.3.
   The Negative Trust Anchor and Extended DNS Errors patterns do not
   weaken the failure-closed posture; they make the cause of refusal
   diagnosable by humans and audit systems.  Implementations choosing
   not to implement these patterns inherit a coarser failure mode in
   which all verifications against a malfunctioning issuer fail without
   distinguishing cause, which is conformant but operationally degraded.

   This concern is family-wide because every environment.* constraint
   type relies on a trust-root mechanism whose failure modes are
   external to the cryptographic verification path, and the operational
   consequences of those failures (mass agent halt, indistinguishable
   refusal causes) are family-wide regardless of which trust-root
   mechanism the type uses.

8.  IANA Considerations

   This document requests that IANA establish a registry for
   environment.* constraint type identifiers and register this document
   as the family-definition document for the namespace.  The registry's
   scope, registration policy, and expert review criteria are specified
   below.









Borthwick & Msebenzi    Expires 12 November 2026               [Page 34]

Internet-Draft                environment.*                     May 2026


   The Verifiable Intent specification [VI-CONSTRAINTS] establishes a
   Constraint Type Registry for VI mandate constraint types.  The
   environment.* registry described here is either a sub-registry of
   that VI Constraint Type Registry or a separate registry coordinated
   with it; the working group's choice between these two structures does
   not affect the registration content this document specifies and is
   left to the working group at adoption time.

8.1.  The environment.* Namespace

   IANA is requested to register the environment.* namespace as a
   constraint type prefix in the registry of Section 8.2.  The namespace
   is the literal string environment followed by a dot followed by one
   or more dot-separated components identifying a specific environmental
   property and, optionally, sub-classifications.

   This document is registered as the family-definition document for the
   environment.* namespace.  Specifications proposing new environment.*
   type identifiers MUST conform to this document.  IANA MUST NOT
   register a specification that does not conform, regardless of the
   technical merit of the proposed type.

8.2.  The environment.* Constraint Type Registry

   IANA is requested to establish a registry titled "Verifiable Intent
   environment.* Constraint Types" (or a name the working group prefers)
   with the following structure.

   Registry fields.  Each registration entry has the following fields:

   *  Type identifier — the dot-separated string under the environment.*
      namespace (for example, environment.market_state,
      environment.wallet_state).

   *  Defined In — a reference to the constraint type specification
      document that defines the type.  The reference SHOULD be a stable
      identifier (RFC number, Internet-Draft name and revision, or a
      permanent published-document URL).

   *  Version — the version of the type specification at the time of
      registration.

   *  Status — one of: Provisional, Stable, Deprecated.








Borthwick & Msebenzi    Expires 12 November 2026               [Page 35]

Internet-Draft                environment.*                     May 2026


   *  Distinguishing Field — the field per Section 5.4 that the type's
      diagnostic output uses for per-member identification.  The
      fallback for cases where the distinguishing field is not present
      in a failing instance MUST be either listed here or referenced
      from the Defined-In document.

   *  MUST-Implement Algorithm — the per-type signing algorithm declared
      per Section 4.3.

   *  Notes — implementation-status references per [RFC6982], known-
      issues references, or coordination references with sibling
      specifications.  May be empty.

   Initial registry contents.  This document does not register any
   specific type identifier.  The two reference type specifications
   cited in Appendix A are expected to register environment.market_state
   and environment.wallet_state respectively under their own working-
   group-adoption procedures.  Registration of those types is the
   responsibility of their respective specifications, not of this
   document.

   Registration policy.  Registration follows the Specification Required
   policy of [RFC8126], Section 4.6 with Expert Review by designated
   experts the working group appoints.  The criteria the experts apply
   are specified in Section 8.3.

8.3.  Expert Review Criteria

   Designated experts evaluating a proposed registration MUST verify
   that the proposed type satisfies all seven requirements of
   Section 3.4:

   (1) the type satisfies the membership criterion of Section 3.2
   (failure mode is gating);

   (2) the type's specification names a trust-root mechanism with
   comparable security properties as defined in Section 3.4(2);

   (3) the type's verification algorithm produces only constraint-
   satisfied or constraint-violated as terminal states;

   (4) the type's per-type fields are classified under the field-scope
   taxonomy of Section 4.2;

   (5) the type's per-type MUST-implement signing algorithm and
   extension sets are declared per Section 4.3;





Borthwick & Msebenzi    Expires 12 November 2026               [Page 36]

Internet-Draft                environment.*                     May 2026


   (6) the type's per-type distinguishing field for diagnostic
   disambiguation is declared per Section 5.4, with a fallback
   specified;

   (7) the type specification conforms to the register discipline of
   Section 6.

   A proposed registration that fails any of these checks MUST be
   rejected by the designated experts.  Rejection is not punitive; it
   indicates that the gap should be closed in the proposed specification
   before the registration is reconsidered.  Designated experts SHOULD
   provide specific feedback identifying which check the proposed
   registration failed and what closure of the gap would look like.

   Designated experts SHOULD also evaluate proposed registrations for:

   *  Namespace coherence.  The proposed identifier SHOULD identify the
      environmental property the type addresses (for example,
      market_state, wallet_state, regulatory_status), not the
      implementation, the issuer, or the wire format.  An identifier
      such as environment.fooissuer_jwt is poorly chosen even if its
      specification is technically conformant.

   *  Coordination with sibling types.  Where a proposed type's
      vocabulary overlaps with a registered type's vocabulary, the
      proposed specification SHOULD use the existing field name with the
      existing semantics, or SHOULD justify why a divergent name or
      semantics is necessary.  Proliferation of near-synonymous fields
      across types defeats the family's vocabulary discipline.

   *  Implementation status.  Proposed registrations from specifications
      that document at least one running implementation per [RFC6982]
      SHOULD be preferred over proposed registrations from
      specifications without running implementations, because the
      family's discipline depends on every member being implementable
      end-to-end with the family's vocabulary.

   These additional criteria are guidance for designated experts.  They
   are not normative requirements that proposed registrations MUST
   satisfy.

8.4.  Status Field Lifecycle

   The Status field of Section 8.2 has three values:







Borthwick & Msebenzi    Expires 12 November 2026               [Page 37]

Internet-Draft                environment.*                     May 2026


   Provisional.  The type's specification has been adopted by the
   working group but has not yet been published as an RFC or equivalent
   stable document.  Implementations of provisional types are encouraged
   but should expect specification changes during the provisional
   period.

   Stable.  The type's specification has been published as an RFC or
   equivalent stable document.  Implementations rely on a stable
   contract; specification changes after the Stable transition follow
   normal protocol-evolution procedures (errata, new versions,
   deprecation).

   Deprecated.  The type's specification has been superseded or
   withdrawn.  Deprecation does not suspend the membership criterion of
   Section 3.2; a deprecated type whose specification still satisfies
   the criterion remains a family member in good standing for backward-
   compatibility purposes, while a deprecated type whose specification
   no longer satisfies the criterion enters the contradiction state of
   Section 3.5.  The Notes field SHOULD reference the superseding
   specification or document the reason for withdrawal.  Verifiers MAY
   continue to support deprecated types for backward compatibility but
   SHOULD log their use distinctly to surface candidates for migration.

   A type's Status field is updated by the working group as the type's
   specification matures, by the same Expert Review process specified in
   Section 8.2.  A status transition MUST NOT change a registered type's
   field-scope classifications (per Section 4.2) or its distinguishing
   field (per Section 5.4); changes to either are working-group
   revisions of the type's specification, not administrative status
   updates.

8.5.  Updates to This Document

   Future revisions of this document that change the registry structure,
   the registration policy, or the Expert Review criteria are working-
   group revisions and MUST be processed by the working group through
   the same procedures that produced the current document.  Editorial
   revisions that do not change the registry's substantive structure are
   patch-level revisions per Section 6.5.

   A future revision that adds a new scope category to Section 4.2.3
   implicitly affects the Expert Review criteria of Section 8.3
   (criterion 4 is updated to include the new category).  Such a
   revision MUST update Section 8.3 explicitly so the criteria remain
   self-contained.

9.  References




Borthwick & Msebenzi    Expires 12 November 2026               [Page 38]

Internet-Draft                environment.*                     May 2026


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

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.

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

   [VI-CONSTRAINTS]
              Verifiable Intent Working Group, "Verifiable Intent —
              Constraint Type Definitions and Validation Rules", Work in
              Progress, Internet-Draft, v0.1-draft, February 2026,
              <https://verifiableintent.dev/spec/constraints/>.

   [VI-CREDENTIAL-FORMAT]
              Verifiable Intent Working Group, "Verifiable Intent —
              Credential Format Specification", Work in Progress,
              Internet-Draft, v0.1-draft, February 2026,
              <https://verifiableintent.dev/spec/credential-format/>.

9.2.  Informative References

   [ENVIRONMENT-MARKET-STATE]
              Headless Oracle Project, "Verifiable Intent — External
              State Attestation Constraint Proposal
              (environment.market_state)", Work in
              Progress v0.5.11-draft, 2026.

   [ENVIRONMENT-WALLET-STATE]
              Borthwick, D., "Verifiable Intent — Wallet State
              Attestation Constraint Proposal
              (environment.wallet_state)", Work in
              Progress v0.6.5-draft, 2026.

   [RFC-SD-JWT]
              Fett, D., Yasuda, K., and B. Campbell, "Selective
              Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-
              Draft, draft-ietf-oauth-selective-disclosure-jwt-22, 2025,
              <https://datatracker.ietf.org/doc/draft-ietf-oauth-
              selective-disclosure-jwt/>.



Borthwick & Msebenzi    Expires 12 November 2026               [Page 39]

Internet-Draft                environment.*                     May 2026


   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.

   [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982,
              DOI 10.17487/RFC6982, July 2013,
              <https://www.rfc-editor.org/rfc/rfc6982>.

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

   [RFC7646]  Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
              and R. Weber, "Definition and Use of DNSSEC Negative Trust
              Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
              <https://www.rfc-editor.org/rfc/rfc7646>.

   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/rfc/rfc7800>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8615>.

   [RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
              Current Practices", BCP 225, RFC 8725,
              DOI 10.17487/RFC8725, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8725>.

   [RFC8914]  Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
              Lawrence, "Extended DNS Errors", RFC 8914,
              DOI 10.17487/RFC8914, October 2020,
              <https://www.rfc-editor.org/rfc/rfc8914>.

   [RFC9421]  Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
              Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
              February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

Appendix A.  Reference Type Specifications

   This appendix records the constraint type specifications that have
   proposed registration in the environment.* namespace at the time of
   this document's publication.  The appendix is informative, per
   [RFC6982].



Borthwick & Msebenzi    Expires 12 November 2026               [Page 40]

Internet-Draft                environment.*                     May 2026


   This appendix is intended to be removed by the RFC Editor before
   final publication, per [RFC6982], Section 2.  The version-control
   history of this document retains the appendix permanently as evidence
   of the family's running-code state during working-group review.

A.1.  environment.market_state

   [ENVIRONMENT-MARKET-STATE] proposes environment.market_state as a
   member of the environment.* family.  The type addresses market-
   session state at a named exchange, with an attestation issued by an
   exchange-state oracle and verified against an [RFC8615] well-known
   key registry.

   The reference implementation associated with
   [ENVIRONMENT-MARKET-STATE] is documented in that specification per
   [RFC6982] in its own Implementation Status appendix; this document
   does not duplicate that content.

   Conformance to this document by [ENVIRONMENT-MARKET-STATE] at
   v0.5.11-draft covers Sections 3.1 through 3.4 (family definition and
   addition rules), Section 4.1 (family-wide fields), Section 4.2
   (field-scope taxonomy), Section 4.3 (algorithm-agility framework),
   Section 5 (family composition, including conjunction, completeness,
   and per-member diagnostic output), Section 6 (register discipline),
   and the applicable subsections of Section 7 (Security
   Considerations).

A.2.  environment.wallet_state

   [ENVIRONMENT-WALLET-STATE] proposes environment.wallet_state as a
   member of the environment.* family.  The type addresses on-chain
   wallet state under a specified condition predicate, with an
   attestation issued by an on-chain-state attestation issuer and
   verified against an [RFC7517] JWKS.

   The reference implementation associated with
   [ENVIRONMENT-WALLET-STATE] is documented in that specification per
   [RFC6982] in its own Implementation Status appendix; this document
   does not duplicate that content.

   Conformance to this document by [ENVIRONMENT-WALLET-STATE] at
   v0.6.5-draft covers Sections 3.1 through 3.4 (family definition and
   addition rules), Section 4.1 (family-wide fields), Section 4.2
   (field-scope taxonomy), Section 4.3 (algorithm-agility framework),
   Section 5 (family composition, including conjunction, completeness,
   and per-member diagnostic output), Section 6 (register discipline),
   and the applicable subsections of Section 7 (Security
   Considerations).  [ENVIRONMENT-WALLET-STATE] additionally specifies



Borthwick & Msebenzi    Expires 12 November 2026               [Page 41]

Internet-Draft                environment.*                     May 2026


   cross-chain temporal consistency at its own Section 6.9; the family-
   wide implications of cross-chain temporal consistency are out of this
   document's scope and are addressed at the type-specification layer.

A.3.  Disclaimer

   Listing in this appendix does not imply endorsement of either type
   specification by the editors of this document, by the working group,
   or by IANA.  Each type specification is independently reviewed under
   the registration process of Section 8.  Verifiers MUST independently
   verify attestations from any implementation per the verification
   algorithm of the implementation's type specification.

Appendix B.  Reserved

   This appendix is reserved for a future revision of this document.
   Per Section 6.7 Q3, broader family-charter material — provider
   neutrality, peer-author coordination discipline, patch-level
   versioning conventions, lockstep commit patterns across sibling
   specifications, and a catalog of register-discipline instances across
   registered family members — may be consolidated under this appendix
   in a future revision, may be relocated to a separate appendix, or may
   be distributed across the relevant specification sections.  The
   choice is a working-group decision the current revision does not
   foreclose.

   This appendix is informative.

Acknowledgments

   The authors thank the Verifiable Intent Working Group for the host
   specification on which this family-definition document depends.  The
   authors additionally acknowledge the contributors and reviewers of
   [ENVIRONMENT-MARKET-STATE] and [ENVIRONMENT-WALLET-STATE], whose
   parallel review work converged the family-wide vocabulary,
   composition discipline, and register practices that this document
   formalises.

Authors' Addresses

   Douglas Borthwick
   InsumerAPI
   New Canaan, CT
   United States of America
   Email: douglas@insumermodel.com
   URI:   https://insumermodel.com





Borthwick & Msebenzi    Expires 12 November 2026               [Page 42]

Internet-Draft                environment.*                     May 2026


   Michael Msebenzi
   Headless Oracle
   Midrand
   South Africa
   Email: info@bytecraftresults.com
   URI:   https://headlessoracle.com













































Borthwick & Msebenzi    Expires 12 November 2026               [Page 43]
