<?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-watts-agentic-authority-graph-validation-00" ipr="trust200902" submissionType="IETF" version="3">
  <front>
    <title>Agentic Authority Graph Validation: A Non-Vacuous Interchange Profile for Revocation-Cut Analysis</title>
    <seriesInfo name="Internet-Draft" value="draft-watts-agentic-authority-graph-validation-00"/>
    <author fullname="Deonté O'dell Watts" initials="D. O." surname="Watts">
      <organization>GoodShyt Group Inc.</organization>
      <address><postal><city>San Francisco</city><region>CA</region><country>US</country></postal><email>deonte@goodshyt.fun</email><uri>https://orcid.org/0009-0005-8586-3650</uri></address>
    </author>
    <date year="2026" month="October" day="14"/>
    <area>Security</area>
    <workgroup>Individual Submission</workgroup>
    <keyword>authorization</keyword><keyword>agents</keyword><keyword>revocation</keyword><keyword>graphs</keyword><keyword>conformance</keyword>
    <abstract><t>Agentic and delegated systems can represent authority as a graph whose paths terminate at consequential resources. Abstract graph models are useful, but interoperable validation requires a machine-readable representation and deterministic rules that do not accidentally accept vacuous or incomplete graphs. This document defines Agentic Authority Graph Validation (AAGV), a JSON interchange profile and validation algorithm for authority roots, consequential sinks, declared normal paths, revocation cut sets, and snapshot edge state. AAGV deliberately distinguishes structural cut validity from operational closure. It rejects missing sink sets, missing normal-path inventories, dangling references, non-dominating cuts, and non-revocable cut edges; it returns INDETERMINATE rather than CLOSED when relevant edge state is unknown. AAGV does not define an authorization token, discover hidden paths, or prove physical containment.</t></abstract>
  </front>
  <middle>
    <section anchor="intro"><name>Introduction</name>
      <t>Authorization and revocation mechanisms increasingly operate across delegated agents, exchanged credentials, queues, retries, services, and resource-side enforcement points. A graph abstraction can model these relationships, but a universal statement such as "every path crosses K" can be misleading if the graph omits its sinks or contains no declared normal path. A validator therefore needs explicit anti-vacuity rules in addition to ordinary reachability checks.</t>
      <t>This document specifies a carrier-neutral JSON representation and deterministic validation procedure. Its strongest claim is intentionally narrow: given one declared graph snapshot, AAGV can determine whether the snapshot is structurally well-formed, whether each declared cut set disconnects all declared authority roots from all declared consequential sinks, and whether the snapshot contains an enabled path or relevant unknown state. It does not establish that the graph contains every real path in a deployment.</t>
    </section>
    <section anchor="requirements"><name>Requirements Language</name><t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.</t></section>
    <section anchor="terms"><name>Terminology</name>
      <dl>
        <dt>Authority Root</dt><dd><t>A declared origin of authority whose prospective reachability is being analyzed.</t></dd>
        <dt>Consequential Sink</dt><dd><t>A declared resource or commitment boundary at which a successful operation can create an externally relevant effect.</t></dd>
        <dt>Normal Path</dt><dd><t>An explicitly declared root-to-sink path known to be valid in ordinary operation. Normal paths prevent a cut claim from succeeding only because no path was modeled.</t></dd>
        <dt>Revocation Cut Set</dt><dd><t>A declared set of revocable edges whose removal is intended to disconnect every declared authority root from every declared consequential sink.</t></dd>
        <dt>Relevant Unknown Edge</dt><dd><t>An edge with unknown snapshot state that is reachable from an authority root and whose destination can structurally reach a consequential sink.</t></dd>
      </dl>
    </section>
    <section anchor="model"><name>AAGV JSON Model</name>
      <t>An AAGV object MUST contain: a version, graph identifier, snapshot sequence, capture time, authority-epoch identifier, one or more roots, one or more sinks, node records, edge records, a non-empty normal-path inventory, and one or more revocation cut sets.</t>
      <t>Each node has an identifier, a node kind, and a trust-domain label. Each edge has an identifier, source node, destination node, capability label, snapshot state, and enforcement metadata. Edge state is one of enabled, disabled, or unknown. Enforcement metadata declares whether the edge is revocable, the control domain, and a revocation identifier.</t>
      <t>AAGV does not cryptographically prove that a stated trust domain is independent or that a revocation point is physically enforceable. Those are external assertions. AAGV only prevents such assertions from being silently omitted when a cut is evaluated.</t>
    </section>
    <section anchor="antivacuity"><name>Anti-Vacuity Rules</name>
      <t>A validator MUST reject an object as INVALID if the root set or sink set is empty; if the normal-path inventory is empty; if any listed sink lacks at least one contiguous declared normal path from a listed root; or if there is no structural root-to-sink path in the graph.</t>
      <t>These requirements are deliberate. In classical logic, a universal statement over an empty path set can be true. AAGV does not allow such a vacuous truth to be promoted into a positive security result.</t>
    </section>
    <section anchor="algorithm"><name>Deterministic Validation Algorithm</name>
      <ol>
        <li><t>Validate the JSON object against the AAGV schema and reject duplicate identifiers.</t></li>
        <li><t>Verify that every root, sink, edge endpoint, normal-path edge, and cut-set edge resolves to a declared object.</t></li>
        <li><t>Verify each normal path for contiguity, declared root, and declared sink; require coverage of every listed sink.</t></li>
        <li><t>Compute structural reachability from all roots to all sinks. If no sink is reachable, return INVALID.</t></li>
        <li><t>For each cut set K, verify that every member edge is declared revocable, remove K, recompute reachability, and return INVALID if any listed sink remains reachable from any listed root.</t></li>
        <li><t>Determine whether any unknown-state edge is relevant to a root-to-sink route. If so, return INDETERMINATE.</t></li>
        <li><t>Compute reachability using enabled edges only. If any sink is reachable, return VALID_OPEN; otherwise return VALID_CLOSED.</t></li>
      </ol>
      <t>VALID_CLOSED is a graph-snapshot result, not a claim of physical or deployment-wide revocation closure. A relying party MUST NOT describe VALID_CLOSED as proving absence of undeclared, hidden, future, or out-of-scope paths.</t>
    </section>
    <section anchor="outcomes"><name>Outcome Semantics</name>
      <dl>
        <dt>INVALID</dt><dd><t>The object is malformed, vacuous, internally inconsistent, references nonexistent objects, includes a non-dominating cut, or otherwise fails a required structural rule.</t></dd>
        <dt>INDETERMINATE</dt><dd><t>The structure and cut are valid but relevant snapshot state is unknown. Unknown MUST NOT be treated as closed.</t></dd>
        <dt>VALID_OPEN</dt><dd><t>The structure and cuts are valid and at least one enabled root-to-sink path remains.</t></dd>
        <dt>VALID_CLOSED</dt><dd><t>The structure and cuts are valid and no enabled root-to-sink path exists in this declared snapshot.</t></dd>
      </dl>
    </section>
    <section anchor="relationship"><name>Relationship to Existing Work</name>
      <t>RFC 7009 defines OAuth token revocation but does not define authority-graph interchange. Token Exchange in RFC 8693 can create delegation relationships but does not define this graph profile.</t>
      <t>The Revocation Closure and Boundary Jurisdiction Architecture Internet-Drafts define abstract authority graphs, consequential sinks, cut sets, and closure semantics. AAGV operationalizes only the interchange and deterministic snapshot-validation portion; it does not replace those semantics.</t>
      <t>Actor-chain and agent-credential work can preserve delegation lineage. AAGV additionally represents non-credential components such as queues, enforcement edges, and commitment boundaries. Consequence-path-completeness work emphasizes alternate effect routes; AAGV provides a machine-checkable representation in which such bypass edges cause cut validation to fail.</t>
      <t>This document does not claim invention of directed graphs, graph cuts, capability systems, revocation, delegation, or reachability analysis.</t>
    </section>
    <section anchor="conformance"><name>Conformance and Falsification</name>
      <t>An implementation claiming AAGV-v0.1 conformance MUST reproduce the normative outcome for the published conformance vectors. The suite includes positive cases, missing-sink and missing-normal-path cases, a bypass around the cut, open and unknown snapshot states, dangling references, cycles, multiple roots, invalid cut references, malformed declared paths, and a non-revocable cut member.</t>
      <t>The core falsifier is direct: if a graph accepted as structurally cut-valid contains any declared root-to-sink path after removal of the accepted cut, the validator is non-conformant. If it returns VALID_CLOSED while a relevant edge state is unknown, it is non-conformant.</t>
    </section>
    <section anchor="security"><name>Security Considerations</name>
      <t>AAGV is vulnerable to incomplete modeling. An attacker or operator can omit a bypass path and still produce a structurally valid snapshot. Consumers MUST therefore treat graph coverage as a separate assurance question.</t>
      <t>Trust-domain and revocability labels are declarations. They require deployment evidence outside this format. AAGV validation MUST NOT be presented as proof of independent control, hardware isolation, physical containment, or absence of covert channels.</t>
      <t>Unknown edge state is fail-closed for closure claims. Parsers MUST reject duplicate identifiers and dangling references. Implementations SHOULD bound input size and use reachability algorithms that do not enumerate every simple path, because cyclic graphs can have an exponential number of simple paths.</t>
    </section>
    <section anchor="privacy"><name>Privacy Considerations</name><t>Authority graphs can reveal organizational topology, service relationships, delegation structure, resource names, and security-control placement. Producers SHOULD use scoped identifiers and disclose only the graph elements necessary for the relying party's analysis.</t></section>
    <section anchor="iana"><name>IANA Considerations</name><t>This document has no IANA actions.</t></section>
  </middle>
  <back>
    <references><name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/rfc/rfc2119"><front><title>Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner"/><date year="1997" month="March"/></front><seriesInfo name="RFC" value="2119"/></reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/rfc/rfc8174"><front><title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title><author initials="B." surname="Leiba"/><date year="2017" month="May"/></front><seriesInfo name="RFC" value="8174"/></reference>
      <reference anchor="RFC8259" target="https://www.rfc-editor.org/rfc/rfc8259"><front><title>The JavaScript Object Notation (JSON) Data Interchange Format</title><author initials="T." surname="Bray"/><date year="2017" month="December"/></front><seriesInfo name="RFC" value="8259"/></reference>
    </references>
    <references><name>Informative References</name>
      <reference anchor="RFC7009" target="https://www.rfc-editor.org/rfc/rfc7009"><front><title>OAuth 2.0 Token Revocation</title><author initials="T." surname="Lodderstedt"/><author initials="S." surname="Dronia"/><author initials="M." surname="Scurtescu"/><date year="2013" month="August"/></front><seriesInfo name="RFC" value="7009"/></reference>
      <reference anchor="RFC8693" target="https://www.rfc-editor.org/rfc/rfc8693"><front><title>OAuth 2.0 Token Exchange</title><author initials="M." surname="Jones"/><author initials="A." surname="Nadalin"/><author initials="B." surname="Campbell"/><author initials="J." surname="Bradley"/><author initials="C." surname="Mortimore"/><date year="2020" month="January"/></front><seriesInfo name="RFC" value="8693"/></reference>
      <reference anchor="I-D.watts-revocation-closure" target="https://datatracker.ietf.org/doc/draft-watts-oauth-agent-revocation-closure/"><front><title>Revocation Closure for Agentic Authorization Systems</title><author initials="D." surname="Watts"/><date year="2026" month="October"/></front><seriesInfo name="Internet-Draft" value="draft-watts-oauth-agent-revocation-closure-01"/></reference>
      <reference anchor="I-D.watts-bja" target="https://datatracker.ietf.org/doc/draft-watts-boundary-jurisdiction-architecture/"><front><title>Boundary Jurisdiction Architecture for Agentic and Delegated Systems</title><author initials="D." surname="Watts"/><date year="2026" month="October"/></front><seriesInfo name="Internet-Draft" value="draft-watts-boundary-jurisdiction-architecture-00"/></reference>
      <reference anchor="I-D.actor-chain" target="https://datatracker.ietf.org/doc/draft-mw-spice-actor-chain/"><front><title>Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange</title><author initials="Y." surname="Prasad"/><date year="2026" month="April"/></front><seriesInfo name="Internet-Draft" value="draft-mw-spice-actor-chain-05"/></reference>
      <reference anchor="I-D.acap" target="https://datatracker.ietf.org/doc/draft-yakung-oauth-agent-attestation/"><front><title>Agent Credential Attestation Protocol (ACAP)</title><author initials="Y." surname="Yakung"/><date year="2026" month="March"/></front><seriesInfo name="Internet-Draft" value="draft-yakung-oauth-agent-attestation-00"/></reference>
      <reference anchor="I-D.path-completeness" target="https://datatracker.ietf.org/doc/draft-das-consequence-path-completeness/"><front><title>When the Gate Can Be Bypassed: Consequence-Path Completeness for Execution Finality</title><author initials="S." surname="Das"/><date year="2026" month="September"/></front><seriesInfo name="Internet-Draft" value="draft-das-consequence-path-completeness-00"/></reference>
    </references>
  </back>
</rfc>
