Individual Submission T. Jacobs Internet-Draft KTS Global Intended status: Informational 8 August 2026 Expires: 9 February 2027 Web4 Federation Architecture Model draft-jacobs-web4-federation-architecture-00 Abstract This document describes a generic architectural model for Web4 federations, as defined in [JACOBS-TERM], covering node admission, tiering, gateway-mediated inter-node transport, and operational health verification. It generalizes patterns observed in a live, operating multi-node federation, offered as a Reference Implementation under the terminology of [JACOBS-TERM], without specifying vendor-internal computational, cryptographic, or coordinate mechanisms. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 February 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. Jacobs Expires 9 February 2027 [Page 1] Internet-Draft Web4 Federation Architecture August 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 3. Architectural Model . . . . . . . . . . . . . . . . . . . . . 2 3.1. Node Roles . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Admission Mechanism . . . . . . . . . . . . . . . . . . . 3 3.3. Gateway-Mediated Transport . . . . . . . . . . . . . . . 4 3.4. Tiering and Visibility . . . . . . . . . . . . . . . . . 4 3.5. Health and Coherence Verification . . . . . . . . . . . . 4 4. Reference Implementation Notes . . . . . . . . . . . . . . . 5 5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 9. Informative References . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction [JACOBS-TERM] establishes baseline vocabulary for Web4 systems, including "Federation Node," "Tiering," and "Sovereign Entity," without prescribing any specific architecture. This document fills that gap at a generic level: it describes a class of architectures capable of satisfying the Web4 definitions, expressed abstractly enough to apply to independently engineered implementations, while remaining consistent with an operating reference deployment. This document intentionally omits internal computational models, coordinate systems, cryptographic primitives, and vendor-specific optimization techniques. Its purpose is to describe the shape of a Web4 federation -- roles, admission, transport mediation, and verification -- not to standardize any single vendor's engine. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals as shown here. This document uses the terms "Federation Node," "Sovereign Entity," "Tiering," "Conformance Class," and "Reference Implementation" as defined in [JACOBS-TERM]. 3. Architectural Model Jacobs Expires 9 February 2027 [Page 2] Internet-Draft Web4 Federation Architecture August 2026 3.1. Node Roles A Web4 federation MAY distinguish between the following abstract node roles: Coordinating Node: A node responsible for maintaining admission state and routing policy for the federation. A federation MAY designate one or more coordinating nodes. Member Node: A node that participates in the federation subject to admission by a coordinating node, and that exposes a health/status surface for external verification. Gateway: A discrete component, co-located with or adjacent to a coordinating node, that mediates inter-node transport requests and enforces admission policy at the transport layer, distinct from application-layer logic on member nodes. These roles are logical, not physical; a single deployed process MAY perform more than one role. 3.2. Admission Mechanism Federation membership SHOULD be governed by an explicit, inspectable admission mechanism, such as an allowlist keyed by node identity, rather than implicit network reachability. An admission mechanism SHOULD support: * Enumeration: a caller with appropriate authorization can retrieve the current set of admitted node identities and a count of admitted entries. * Modification: node identities can be added to or removed from the admitted set without requiring redeployment of member-node application code. * Auditability: changes to the admitted set SHOULD be attributable to a specific change event, distinguishable from routine operational traffic. This document does not mandate a specific storage technology for the admission mechanism (e.g., key-value store, relational store, or distributed ledger); it mandates only the enumerability, modifiability, and auditability properties above. Jacobs Expires 9 February 2027 [Page 3] Internet-Draft Web4 Federation Architecture August 2026 3.3. Gateway-Mediated Transport Inter-node requests that cross federation-trust boundaries SHOULD pass through a gateway component that: * Validates the source node identity against the current admission mechanism state before permitting the request to proceed. * Applies a distinct versioned identity from the member nodes it serves, such that gateway software can be updated independently of member-node application code. * Rejects requests from unlisted source identities with an explicit, distinguishable error condition rather than silent failure or a generic fallback response. A federation MAY additionally define a relay component, distinct from the gateway, responsible for forwarding admitted traffic after gateway validation. Separating gateway (admission enforcement) from relay (forwarding) is RECOMMENDED so that each component can be versioned and audited independently. 3.4. Tiering and Visibility As defined in [JACOBS-TERM], tiering organizes nodes into layered relationships. This document recommends that a federation maintain an explicit, queryable map of: * Which nodes are currently first-class (fully admitted and participating). * Which nodes are pending, deferred, or held (admitted in principle but not currently exchanging traffic). * Which nodes are excluded, and, to the extent operationally appropriate, why. Maintaining this map as a first-class, independently verifiable artifact, rather than only as implicit configuration state, supports the auditability property described in Section 3.2 and allows external Conformance evaluation as defined in [JACOBS-TERM]. 3.5. Health and Coherence Verification Each member node SHOULD expose a health-status surface, independent of its primary application logic, that reports at minimum: Jacobs Expires 9 February 2027 [Page 4] Internet-Draft Web4 Federation Architecture August 2026 * Whether the node considers itself currently admitted to the federation. * A federation-network identity token, allowing an external verifier to confirm the node believes itself part of the claimed federation rather than an unrelated deployment. * A monotonically advancing sequence value (e.g., an epoch or audit index) that allows an external verifier to distinguish a live, advancing node from a stale or non-responsive one returning a cached or fallback response. This document takes no position on the internal mechanism used to compute or advance such sequence values. 4. Reference Implementation Notes A live, multi-node federation operating under this architectural model has been in continuous operation since January 2026, comprising more than twenty independently addressable member nodes coordinated through a gateway/relay pair, with an enumerable, auditable admission mechanism and per-node health surfaces consistent with Section 3.5. Consistent with [RFC7942] reporting norms, this note is provided to demonstrate that the architecture described in Section 3 is achievable in practice; it does not constitute IETF endorsement of the specific implementation, and no internal coordinate system, cryptographic primitive, or optimization technique used by that implementation is disclosed by this document. 5. Non-Goals This document does not: * Specify a wire protocol, serialization format, or transport encoding. * Specify or constrain the internal computational model by which a node processes, stores, or relates data. * Specify a discovery mechanism by which unrelated federations locate one another. * Certify any particular deployment as conformant; conformance evaluation is out of scope for this document and is addressed separately under the Conformance Class framework of [JACOBS-TERM] and [JACOBS-MEC]. Jacobs Expires 9 February 2027 [Page 5] Internet-Draft Web4 Federation Architecture August 2026 6. Security Considerations An admission mechanism as described in Section 3.2 is a security- critical component: any party able to modify the admitted-node set can affect federation membership. Implementations SHOULD restrict modification access using authenticated, authorized channels distinct from ordinary application traffic, and SHOULD log modification events for audit purposes. A gateway as described in Section 3.3 becomes a single point of trust-boundary enforcement; implementations SHOULD ensure gateway failure results in fail-closed behavior (rejecting unvalidated traffic) rather than fail-open behavior (passing traffic without validation). Health surfaces described in Section 3.5, if unauthenticated, reveal federation topology and operational state to any observer. Implementations SHOULD weigh operational transparency against information disclosure and MAY restrict detailed health data to authenticated callers while exposing only coarse status publicly. This document does not address confidentiality or integrity of payloads carried over inter-node transport, which is left to the choice of underlying transport protocol. 7. IANA Considerations This document has no IANA actions. 8. Normative References [JACOBS-TERM] Jacobs, T., "Web4 Terminology and Definitions", August 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 9. Informative References Jacobs Expires 9 February 2027 [Page 6] Internet-Draft Web4 Federation Architecture August 2026 [JACOBS-MEC] Jacobs, T., "Web4 Sovereign Entity Comprehension: Requirements and External Conformance Framework", August 2026, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, July 2016, . Author's Address Tim Jacobs KTS Global United Arab Emirates Email: tim@ktsglobal.live Jacobs Expires 9 February 2027 [Page 7]