Network Working Group J. Williams Internet-Draft Independent Intended status: Informational September 2026 Expires: 8 March 2027 The Intent Token: A Cryptographic Authorization Primitive for Autonomous Agents draft-williams-intent-token-02 Abstract This document specifies the Intent Token, a cryptographic authorization primitive for autonomous AI agent systems. An Intent Token binds an autonomous agent action to a cryptographically signed, human-declared authorization envelope before that action is executed. The Intent Token addresses a fundamental gap in existing authorization frameworks: while OAuth 2.0, OIDC, and related standards govern identity and access at the session level, no standardized primitive exists for governing what an autonomous agent is authorized to DO at the moment of action. The Intent Token provides this primitive. It is model-agnostic, transport-agnostic, and composable with existing authorization infrastructure. Revision -01 extended the specification with Fractal Intent Token (FIT) binding for multi-scale agent systems, Authorization Fluidity for context-sensitive mode switching, and the Fractal Crypto-Temporal Graph (FCTG) as the normative audit trail data structure for continuous adaptive authorization. This revision (-02) corrects the stated patent priority date and dependent date references carried over from -01, adds a fourth documented instance of independent convergence (Broadcom's AgentMinder), and revises the characterization of AI-assisted development work in Section 12 for accuracy. 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/. Williams Expires 8 March 2027 [Page 1] Internet-Draft Intent Token September 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 5 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 3.1. The Authorization Gap Beyond OAuth 2.0 . . . . . . . . . 6 3.2. The Delegation Depth Problem . . . . . . . . . . . . . . 6 3.3. The Confused Deputy Problem in Autonomous Systems . . . . 6 4. The Intent Token . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Token Structure . . . . . . . . . . . . . . . . . . . . . 6 4.2. Required Claims . . . . . . . . . . . . . . . . . . . . . 8 4.3. Temporal Scope and Shard Binding . . . . . . . . . . . . 8 4.4. Delegation Chain Encoding . . . . . . . . . . . . . . . . 8 4.5. Fractal Intent Token (FIT) Binding (NEW) . . . . . . . . 8 5. Intent Certificate . . . . . . . . . . . . . . . . . . . . . 9 6. Enforcement Binding . . . . . . . . . . . . . . . . . . . . . 9 6.1. Pre-Action Validation . . . . . . . . . . . . . . . . . . 9 6.2. SNAP-BACK on Violation . . . . . . . . . . . . . . . . . 10 6.3. Audit Chain Requirements . . . . . . . . . . . . . . . . 10 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Relationship to OAuth 2.0 . . . . . . . . . . . . . . . . 10 7.2. Relationship to Delegation Capability Tokens . . . . . . 10 7.3. Relationship to W3C Verifiable Credentials . . . . . . . 10 7.4. Relationship to Multi-Agent Orchestration Systems (NEW) . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Authorization Fluidity (NEW) . . . . . . . . . . . . . . . . 11 Williams Expires 8 March 2027 [Page 2] Internet-Draft Intent Token September 2026 9.1. Authorization Modes . . . . . . . . . . . . . . . . . . . 11 9.2. Mode Transitions . . . . . . . . . . . . . . . . . . . . 11 9.3. Crisis Detection . . . . . . . . . . . . . . . . . . . . 12 10. Fractal Crypto-Temporal Graph (FCTG) (NEW) . . . . . . . . . 12 10.1. Node Structure . . . . . . . . . . . . . . . . . . . . . 12 10.2. Before-Action Binding in Continuous Flow . . . . . . . . 13 10.3. Query Performance . . . . . . . . . . . . . . . . . . . 13 10.4. Mode Transition Handling . . . . . . . . . . . . . . . . 13 10.5. Relationship to WitnessBound Audit Chain . . . . . . . . 13 11. Convergent Independent Development (NEW) . . . . . . . . . . 13 12. Empirical Validation (NEW) . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Log . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The deployment of autonomous AI agents in consequential domains -- financial services, healthcare, critical infrastructure, autonomous vehicles, and multi-agent orchestration systems -- creates a class of authorization problems that existing standards do not address. OAuth 2.0 [RFC6749] governs whether a principal has access to a resource. OpenID Connect [OIDC] governs whether a principal is who they claim to be. These standards address the WHO question: who is this agent, and what resources may it access? Neither standard addresses the WHAT question: given that an agent has access, what specific actions is it authorized to perform at this moment, on behalf of this principal, within these declared boundaries? The gap between access and action is the authorization gap. In human-operated systems, this gap is bridged by human judgment. In autonomous agent systems, this gap is bridged by the agent itself -- which may interpret its authorization scope in ways the authorizing principal did not intend. This is the intent blindness problem. This document specifies the Intent Token, a cryptographic primitive that closes the authorization gap. An Intent Token is a signed, time-bounded authorization envelope that: * Declares what action a principal authorizes an agent to perform, BEFORE the action is executed; Williams Expires 8 March 2027 [Page 3] Internet-Draft Intent Token September 2026 * Binds that declaration cryptographically to the agent session and the specific action; * Provides a verifiable, tamper-evident record of the authorization for audit purposes; * Propagates the declared intent through delegation chains, preventing sub-agents from exceeding the scope the delegating principal was itself authorized to grant. The Intent Token is the core primitive of the Intent Bound Authorization (IBA) framework, patent application GB2603013.0 (pending, UK IPO, filed 10 February 2026, PCT rights in 150+ countries until August 2028). This revision (-01) extends the -00 specification in response to developments in multi-agent orchestration systems and findings from empirical research conducted via the RSIForge recursive self- improvement research platform [WILLIAMS-2026]. The extensions address authorization at multiple scales simultaneously (Section 4.5), context-sensitive mode switching (Section 9), and a new normative audit trail data structure (Section 10). Independent convergence on the authorization gap was observed in Google DeepMind's Delegation Capability Tokens [DEEPMIND-DCT] (February 12, 2026), Mastercard's Verifiable Intent framework (March 5, 2026), Broadcom's AgentMinder (August 31, 2026), and the authorization gap exposed by Sakana AI's Fugu Ultra orchestration system (June 2026). Section 11 documents this convergence. 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. 2. Terminology Intent Token: A cryptographically signed authorization envelope that declares what action a principal authorizes an autonomous agent to perform, issued before the action is executed, and bound to a specific session shard. Intent Certificate: A persistent, verifiable credential that records the full authorization context for an agent session. Williams Expires 8 March 2027 [Page 4] Internet-Draft Intent Token September 2026 Principal: The human or organizational entity whose declared intent authorizes the agent action. MUST be cryptographically identified in every Intent Token. Authorized Agent: An autonomous system authorized to act within the scope declared in an Intent Token. Shard: A time-bounded cryptographic token issued by the IBA Gate. Default window 512 seconds. IBA Gate: The enforcement point that validates Intent Tokens before permitting agent actions. SNAP-BACK: The mandatory cancellation of an agent action when Intent Token validation fails. MUST occur before the action has market or physical effect. Delegation Chain: The ordered sequence of principals and agents through which authorization has been delegated. Each link is cryptographically signed. No link may grant scope exceeding the scope granted to the delegating entity. TBDE: Temporal Boundary Decision Engine. The runtime component responsible for validating every agent action against the declared Intent Token within the enforcement latency target. FCTG: Fractal Crypto-Temporal Graph. The normative audit trail data structure introduced in this revision (-01). Authorization Fluidity: The capacity for an IBA Gate to switch between authorization modes (STATIC, ADAPTIVE, RECURSIVE) while maintaining cryptographic continuity of the audit trail. WitnessBound Audit Chain: The append-only audit record defined in -00. Superseded by the FCTG. Linear audit chains are a degenerate case of the FCTG. Williams Expires 8 March 2027 [Page 5] Internet-Draft Intent Token September 2026 3. Problem Statement 3.1. The Authorization Gap Beyond OAuth 2.0 OAuth 2.0 access tokens grant access to resource scopes but do not constrain what an autonomous agent does within that scope. Existing mitigations are post-hoc. The Intent Token is pre-hoc: it declares and enforces authorization before action. 3.2. The Delegation Depth Problem Modern autonomous agent architectures are hierarchical. Existing delegation frameworks, including OAuth 2.0 Token Exchange [RFC8693], do not propagate declared human intent through the delegation chain. The Intent Token requires that every link present a valid Intent Token that is a subset of the authorizing token. 3.3. The Confused Deputy Problem in Autonomous Systems The confused deputy problem [HARDY-1988] describes a system with legitimate authority being manipulated into misusing that authority. The Intent Token defends against this: because the authorized action is declared and signed by the principal BEFORE the agent acts, any deviation is detected and blocked at the enforcement layer. 4. The Intent Token 4.1. Token Structure An Intent Token is a JSON Web Token [RFC7519] with "typ": "intent+jwt". The "ibt_ver" claim is "1.1" in this revision. Williams Expires 8 March 2027 [Page 6] Internet-Draft Intent Token September 2026 { "header": { "alg": "ES256", "typ": "intent+jwt" }, "payload": { "iss": "https://intentbound.example.com", "sub": "agent-id:AG-7729-ALPHA", "aud": "iba-gate:production", "exp": 1771234567, "iat": 1771230967, "jti": "a8f3c2d1-4b5e-6f7a-8b9c-0d1e2f3a4b5c", "ibt_ver": "1.1", "ibt_level": "agent", "parent_token_jti": "c3d4e5f6-7a8b-9c0d-1e2f-3a4b5c6d7e8f", "principal": { "id": "user:jeffrey.williams@example.com", "type": "human", "auth_method": "ES256-keypair" }, "declared_intent": { "action_class": "financial:order:equity", "scope": "EQUITIES_US", "bounds": { "max_position_usd": 50000000, "max_single_order_usd": 5000000, "permitted_instruments": ["NYSE:*", "NASDAQ:*"], "prohibited_instruments": ["OTC:*"], "time_window": "09:30-16:00 EST" } }, "shard": { "id": "shard:mmc-nbwc-enyn", "issued_at": 1771230967, "expires_at": 1771231479, "window_seconds": 512 }, "enforcement": { "snap_back": true, "latency_target_ms": 5, "audit_chain": "fctg:production", "auth_mode": "static" } } } Williams Expires 8 March 2027 [Page 7] Internet-Draft Intent Token September 2026 4.2. Required Claims ibt_ver: Version "1.1" for this revision. ibt_level (NEW): MUST be one of "agent", "cluster", "system", or "federation". See Section 4.5. parent_token_jti (NEW): The jti of the authorizing token at the next higher scale. REQUIRED for "agent" and "cluster" level tokens. principal: MUST include "id" (URI) and "type" ("human" or "organization"). declared_intent: MUST include "action_class" and "scope". shard: MUST include "id", "issued_at", "expires_at", "window_seconds". enforcement: MUST include "snap_back" (true), "audit_chain" (FCTG URI), "auth_mode" (NEW). Standard JWT claims iss, sub, aud, exp, iat, and jti are REQUIRED. 4.3. Temporal Scope and Shard Binding Every Intent Token MUST be bound to a time-bounded shard. Default window 512 seconds. Expired shards MUST be rejected. 4.4. Delegation Chain Encoding Delegating agents MUST issue sub-tokens with scope that is a strict subset of their own. The delegation_chain array MUST include all prior delegation records. 4.5. Fractal Intent Token (FIT) Binding (NEW) This revision extends Intent Token binding to four scales simultaneously: Agent Level: Existing single-agent binding as specified in Sections 4.1-4.4. Williams Expires 8 March 2027 [Page 8] Internet-Draft Intent Token September 2026 Cluster Level: A Cluster Intent Token (CIT) binds the collective scope of a coordinated agent group. Individual agent tokens MUST be subsets of the CIT. System Level: A System Intent Token (SIT) binds the global deployment policy. CITs MUST be subsets of the SIT. Cross-System Level: A Federation Intent Token (FedIT) enables cross- organizational authorization. OPTIONAL, requires bilateral trust establishment. The fractal structure is self-similar: the same token schema, cryptographic requirements, and enforcement rules apply at every scale. An IBA Gate at any level MUST reject tokens whose scope exceeds the authorizing token at the next level up. 5. Intent Certificate An Intent Certificate is the persistent audit record of an agent session. MUST contain: principal identity; declared scope; temporal bounds; FCTG endpoint reference; cryptographic hashes of all Intent Tokens; signed summary of all enforcement decisions including SNAP- BACK events. MUST use algorithms from NIST SP 800-57 [NIST-SP-800-57]. MUST support ES256 [RFC7518]. SHOULD support ES384 and EdDSA [RFC8037]. 6. Enforcement Binding 6.1. Pre-Action Validation The IBA Gate MUST validate the Intent Token BEFORE permitting agent action. Validations MUST include: token signature; token and shard expiry; action matches declared_intent; parameters within bounds; delegation chain validity; jti uniqueness; and ibt_level chain validity (NEW). All validations MUST complete within latency_target_ms (target: 5ms). Empirical analysis [WILLIAMS-2026] indicates this target is achievable with caching in the tested implementation: 2-3ms base, sub-1ms cached. Williams Expires 8 March 2027 [Page 9] Internet-Draft Intent Token September 2026 6.2. SNAP-BACK on Violation Validation failure MUST result in: immediate action rejection; SNAP- BACK event recorded in FCTG; structured error returned to agent; no retry without new principal-authorized Intent Token. No partial execution permitted. 6.3. Audit Chain Requirements Every enforcement decision MUST be recorded in the FCTG (Section 10). Each record MUST contain: the Intent Token jti; validation timestamp (nanosecond precision RECOMMENDED); validation result (PASS or SNAP- BACK); cryptographic hash chained to previous record. This is intended to support audit requirements such as those found in the EU AI Act Article 9, MiFID II, FDA Cybersecurity 2023, and HIPAA Security Rule; conformance with any specific regulatory regime has not been independently assessed. 7. Interoperability 7.1. Relationship to OAuth 2.0 Complementary, not competing. OAuth 2.0 governs access; the Intent Token governs action. Compliant implementation: agent obtains OAuth 2.0 access token; principal issues Intent Token; IBA Gate validates Intent Token before action. 7.2. Relationship to Delegation Capability Tokens Google DeepMind introduced DCTs [DEEPMIND-DCT] on February 12, 2026, two days after the IBA patent filing. DCTs govern delegation scope; the Intent Token governs action authorization at the moment of execution. Complementary primitives. 7.3. Relationship to W3C Verifiable Credentials The Intent Certificate MAY be expressed as a W3C Verifiable Credential [W3C-VC] for interoperability with decentralized identity infrastructure. 7.4. Relationship to Multi-Agent Orchestration Systems (NEW) Orchestration systems route tasks to agents. The Intent Token governs what those agents are authorized to do. These are orthogonal functions. A compliant deployment provides: (a) dynamic routing to the best available model, and (b) cryptographic enforcement of action authorization regardless of which model was selected. Williams Expires 8 March 2027 [Page 10] Internet-Draft Intent Token September 2026 When the orchestrating system substitutes one agent for another, the Intent Token framework handles this via FCTG branching (Section 10.4) and Authorization Fluidity mode transitions (Section 9.2). The audit trail is maintained across agent substitution events. 8. Security Considerations Intent Token implementations MUST defend against: replay attacks (jti uniqueness cache); token forgery (key verification and rotation); scope inflation (delegation chain verification at each link, extended to cross-scale in Section 4.5); prompt injection (before-action binding blocks out-of-scope actions regardless of manipulation source); mode manipulation (all mode transitions MUST be principal- authorized and FCTG-recorded); FCTG integrity (append-only, Merkle roots provide tamper evidence). 9. Authorization Fluidity (NEW) 9.1. Authorization Modes STATIC: Fixed rules. Pre-declared scope does not change during session. Default mode. MUST be used when conditions are stable. ADAPTIVE: Scope may be updated by principal. Each update MUST be cryptographically signed and FCTG-recorded. IBA Gate applies most recently signed scope. RECURSIVE: Scope recursively refined through multiple principal confirmation rounds. REQUIRED in crisis conditions. 9.2. Mode Transitions Mode transitions MUST: (a) record transition decision as signed FCTG node before new mode takes effect; (b) maintain unbroken audit trail via FCTG branching (Section 10.4); (c) require principal authorization for STATIC-to-RECURSIVE transitions; (d) complete within latency_target_ms. Williams Expires 8 March 2027 [Page 11] Internet-Draft Intent Token September 2026 9.3. Crisis Detection The IBA Gate MUST implement: a Classifier monitoring agent action patterns and system state; Human-in-the-Loop Validation suspending action and requesting principal confirmation under ambiguous or novel conditions; and optionally a Meta-Agent monitoring classifier performance across multiple IBA Gates. Crisis classification latency MUST be within latency_target_ms. Classification decisions MUST be FCTG-recorded. 10. Fractal Crypto-Temporal Graph (FCTG) (NEW) The FCTG replaces the WitnessBound Audit Chain as the normative audit data structure. It is backward-compatible: a linear WitnessBound chain is a degenerate FCTG with no branching. 10.1. Node Structure Each FCTG node MUST contain: event_id: UUID uniquely identifying this authorization event. REQUIRED. agent_id: Agent identifier. REQUIRED. MUST match "sub" claim of associated Intent Token. action: Action class being authorized. REQUIRED. MUST match declared_intent.action_class. timestamp: Nanosecond-precision timestamp. REQUIRED. MUST be recorded before agent action executes. cryptographic_signature: ES256 signature over concatenation of event_id, agent_id, action, and timestamp. REQUIRED. MUST be computed and verified before agent action executes. This constitutes the cryptographic before-action binding. parent_id: event_id of immediately preceding node. REQUIRED except for root nodes. ibt_level: Authorization scale of this node. REQUIRED. Williams Expires 8 March 2027 [Page 12] Internet-Draft Intent Token September 2026 mode: Authorization mode active at time of this event. REQUIRED. 10.2. Before-Action Binding in Continuous Flow The before-action binding invariant MUST be maintained at every FCTG node regardless of authorization mode. Continuous flow increases the frequency of discrete binding events; it does not eliminate them. 10.3. Query Performance FCTG implementations MUST support historical audit queries at all four authorization scales. Implementations MAY use Merkle tree indexing for O(log n) complexity. When Merkle indexing is used: roots MUST be anchored at agent and cluster levels; proofs MUST be available for cross-scale queries; roots MUST be updated at mode transition boundaries; storage overhead is O(k log n). Localized skip-list augmentation within FCTG subtrees is permitted. A global skip-list is NOT RECOMMENDED due to the non-linear fractal graph structure. 10.4. Mode Transition Handling On mode transition, the FCTG MUST: (a) create new branch at transition boundary; (b) seal previous branch with terminal signature over branch root Merkle hash; (c) link new branch via parent_id; (d) record transition as signed node with action "mode_transition". A verifier MUST traverse complete history across all transitions via parent_id links. 10.5. Relationship to WitnessBound Audit Chain WitnessBound Audit Chain from -00 Section 6.3 is superseded. "audit_chain" MAY reference either endpoint. "ibt_ver" "1.0" implies WitnessBound; "1.1" implies FCTG. 11. Convergent Independent Development (NEW) Since GB2603013.0 (10 February 2026), multiple independent research programs and commercial platforms have converged on the same authorization gap: * Google DeepMind DCTs [DEEPMIND-DCT]: February 12, 2026 (2 days after IBA filing) * Mastercard Verifiable Intent [MASTERCARD-VI]: March 5, 2026 (~23 days after IBA priority date) Williams Expires 8 March 2027 [Page 13] Internet-Draft Intent Token September 2026 * Sakana AI Fugu Ultra [SAKANA-FUGU]: June 2026 -- exposes the authorization gap in production orchestration * Broadcom AgentMinder: August 31, 2026 -- requires every agent to declare intent, not just identity, before it can act on enterprise systems, binding that declared intent to permitted tools and authorized resources at runtime This convergence is offered as evidence that the underlying authorization gap is real and independently recognized across research and industry; it is not offered as evidence of technical equivalence between these systems and the Intent Token specification. 12. Empirical Validation (NEW) The extensions in this revision were developed through an eight-round research process on RSIForge.com using a Human-in-the-Loop methodology [WILLIAMS-2026], with iterative feedback from Grok (xAI) obtained across all eight rounds. This feedback was conversational in nature and does not constitute formal peer review; no independent, credentialed review of these extensions has been conducted to date. Key findings from this process: Authorization Fluidity (no single mode wins all regimes); Meta-Agent (emergent oversight appeared unprompted); FCTG (emerged from audit trail continuity analysis); sub-5ms latency indicated as achievable with caching in the tested implementation. Two empirical gaps remain requiring production data: novelty rate of authorization transitions, and FCTG long-term coherence at scale. 13. IANA Considerations This document requests registration of the "intent+jwt" media type and the following JWT claims: "ibt_ver", "ibt_level", "parent_token_jti", "principal", "declared_intent", "shard", "enforcement". 14. References 14.1. Normative References [NIST-SP-800-57] NIST, "Recommendation for Key Management", NIST SP 800-57, 2020, . Williams Expires 8 March 2027 [Page 14] Internet-Draft Intent Token September 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 14.2. Informative References [DEEPMIND-DCT] Google DeepMind, "Delegation Capability Tokens for Autonomous Agent Systems", February 2026. [HARDY-1988] Hardy, N., "The Confused Deputy (or why capabilities might have been invented)", ACM SIGOPS Operating Systems Review, 1988. [MASTERCARD-VI] Mastercard, "How Verifiable Intent builds trust in agentic AI commerce", March 2026, . [OIDC] Sakimura, N., "OpenID Connect Core 1.0", November 2014, . [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, . Williams Expires 8 March 2027 [Page 15] Internet-Draft Intent Token September 2026 [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [SAKANA-FUGU] Sakana AI, "Fugu Ultra: Multi-Agent Orchestration", June 2026, . [W3C-VC] Sporny, M., "Verifiable Credentials Data Model", 2022, . [WILLIAMS-2026] Williams, J., "Beyond Static Intent: Recursive Authorization Frameworks for Emergent Collective Intelligence", June 2026, . Appendix A. Log -01 to -02 revisions: * Corrected patent priority date throughout from "February 5, 2026" to "10 February 2026" (Sections 1, 11), matching the official UK IPO Electronic Filing Receipt for GB2603013.0 * Corrected Mastercard Verifiable Intent announcement date from "February 2026" to "March 5, 2026" (Sections 1, 11); the previously stated "~23 days after IBA priority date" figure was independently correct and is unchanged * Corrected the DeepMind DCT gap from "seven days after the IBA patent filing" to "two days after" (Sections 1, 7.2, 11), consistent with the corrected priority date * Added Broadcom AgentMinder (August 31, 2026) as a fourth documented instance of independent convergence (Sections 1, 11) * Added [MASTERCARD-VI] entry to Informative References, resolving a reference cited in the -01 Change Log but not previously defined in the bibliography * Revised Section 12 to describe Grok (xAI) involvement as iterative conversational feedback rather than "peer review," and added an explicit statement that no independent, credentialed review has been conducted Williams Expires 8 March 2027 [Page 16] Internet-Draft Intent Token September 2026 * Softened Section 6.3's regulatory-compliance claim from stating the audit chain "satisfies" named regulatory requirements to stating it is "intended to support" them, noting conformance has not been independently assessed * Softened Section 6.1 and 12 latency claims from "confirmed achievable" to "indicated as achievable... in the tested implementation" * Resolved an internal inconsistency between two different expiry dates stated in -01 -00 to -01 revisions: * Added "ibt_level" claim (REQUIRED) for fractal scale identification * Added "parent_token_jti" claim for cross-scale chain verification * Added "auth_mode" field to enforcement object * Updated "ibt_ver" from "1.0" to "1.1" * Added Section 4.5: Fractal Intent Token (FIT) Binding * Added Section 7.4: Relationship to Multi-Agent Orchestration Systems * Added Section 9: Authorization Fluidity * Added Section 10: Fractal Crypto-Temporal Graph (FCTG) * Added Section 11: Convergent Independent Development * Added Section 12: Empirical Validation * Updated Sections 6.1, 6.2, 6.3 to reference FCTG * Added references: WILLIAMS-2026, SAKANA-FUGU, MASTERCARD-VI Author's Address Jeffrey Williams Independent Chiang Mai Thailand Email: urls@live.com URI: https://intentbound.com Williams Expires 8 March 2027 [Page 17]