Web4 Node State and Admission Requirements
draft-jacobs-web4-node-state-admission-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tim Jacobs | ||
| Last updated | 2026-08-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jacobs-web4-node-state-admission-00
Network Working Group T. Jacobs
Internet-Draft KTS Global
Intended status: Informational 16 August 2026
Expires: 17 February 2027
Web4 Node State and Admission Requirements
draft-jacobs-web4-node-state-admission-00
Abstract
This document defines implementation-neutral requirements for
persistent node identity, declared state, governed admission,
suspension, revocation, re-admission, and succession in Web4-class
federations. It distinguishes a node from its network and credential
representations, identifies the minimum information required for
externally inspectable participation, and specifies lifecycle and
failure semantics that future protocol bindings can implement. The
requirements permit heterogeneous internal architectures and do not
mandate a transport, serialization, credential technology, storage
system, computational model, or proprietary coordination mechanism.
The document extends prior Web4 terminology, conformance, and
federation-architecture work by supplying a public requirements layer
between architecture and future interoperable bindings.
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 17 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jacobs Expires 17 February 2027 [Page 1]
Internet-Draft Web4 Node State and Admission August 2026
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. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 3
2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
4. Requirements Model . . . . . . . . . . . . . . . . . . . . . 5
5. Persistent Node Identity Requirements . . . . . . . . . . . . 6
5.1. Identity and Representation . . . . . . . . . . . . . . . 6
5.2. Operator Responsibility . . . . . . . . . . . . . . . . . 6
5.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Node-State Declaration Requirements . . . . . . . . . . . . . 7
7. Admission Request Requirements . . . . . . . . . . . . . . . 8
8. Admission Decision Requirements . . . . . . . . . . . . . . . 8
9. Admission Lifecycle . . . . . . . . . . . . . . . . . . . . . 9
10. Authority and Delegation . . . . . . . . . . . . . . . . . . 10
11. Suspension, Revocation, and Re-Admission . . . . . . . . . . 10
11.1. Suspension . . . . . . . . . . . . . . . . . . . . . . . 10
11.2. Revocation . . . . . . . . . . . . . . . . . . . . . . . 11
11.3. Re-Admission . . . . . . . . . . . . . . . . . . . . . . 11
12. Node Succession . . . . . . . . . . . . . . . . . . . . . . . 11
13. Freshness, Versioning, and Extensibility . . . . . . . . . . 12
14. Dependencies and Conformance References . . . . . . . . . . . 12
15. Failure Semantics . . . . . . . . . . . . . . . . . . . . . . 12
16. Abstract Information Model . . . . . . . . . . . . . . . . . 13
16.1. Node-State Declaration Example . . . . . . . . . . . . . 13
16.2. Admission Request Example . . . . . . . . . . . . . . . 14
16.3. Admission Decision Example . . . . . . . . . . . . . . . 15
17. Operational Considerations . . . . . . . . . . . . . . . . . 15
18. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
19. Security Considerations . . . . . . . . . . . . . . . . . . . 16
19.1. Node Impersonation and Binding Substitution . . . . . . 16
19.2. Authority Compromise . . . . . . . . . . . . . . . . . . 16
19.3. Replay and Stale State . . . . . . . . . . . . . . . . . 16
19.4. Version and Policy Downgrade . . . . . . . . . . . . . . 16
19.5. Confused Deputy . . . . . . . . . . . . . . . . . . . . 17
19.6. Denial of Service and Resource Exhaustion . . . . . . . 17
19.7. Operational Disclosure . . . . . . . . . . . . . . . . . 17
Jacobs Expires 17 February 2027 [Page 2]
Internet-Draft Web4 Node State and Admission August 2026
20. Privacy and Governance Considerations . . . . . . . . . . . . 17
21. Future Protocol Bindings . . . . . . . . . . . . . . . . . . 18
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
23. Normative References . . . . . . . . . . . . . . . . . . . . 18
24. Informative References . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
Existing Internet protocols establish addressing, connectivity,
authentication, transport, and application exchange. Those functions
do not, by themselves, establish whether a reachable endpoint
represents a persistent governed node, whether the node was admitted
by an identified authority, which policy applies to its
participation, which state is material to its claimed behavior, or
how suspension, revocation, and replacement affect its identity and
authority.
A reachable endpoint is not automatically a governed participant. In
a Web4-class federation, participation binds persistent node
identity, operator responsibility, declared state, authority, policy,
and lifecycle into an inspectable record.
[JACOBS-TERM] defines baseline Web4 terminology. [JACOBS-ARCH]
describes an implementation-neutral federation architecture,
including node roles, admission, gateway-mediated transport, tiering,
and health verification. [JACOBS-MEC] defines external Machine
Entity Comprehension and sovereignty requirements. This document
defines the node-state and admission requirements needed to
operationalize those concepts without prescribing a vendor-specific
internal implementation.
This document defines requirements and an abstract information model.
It does not define a complete wire protocol. Future specifications
can bind these requirements to JSON, CBOR, HTTP, message-oriented
transport, store-and-forward exchange, or another suitable mechanism.
2. Scope and Non-Goals
2.1. Scope
This document specifies:
* persistent node identity and the distinction between identity and
representation;
* a minimum node-state declaration;
Jacobs Expires 17 February 2027 [Page 3]
Internet-Draft Web4 Node State and Admission August 2026
* admission request and decision requirements;
* admission lifecycle states and transitions;
* authority and delegation requirements;
* suspension, revocation, re-admission, and succession behavior;
* freshness, versioning, dependency, and conformance references;
* explicit failure semantics;
* security, privacy, governance, and operational considerations; and
* an abstract, non-normative example data model.
2.2. Non-Goals
This document does not:
* define a new Internet transport or replace HTTP, TCP, QUIC, DNS,
or existing identity protocols;
* mandate a wire encoding, media type, URI scheme, well-known URI,
credential technology, cloud, database, or model family;
* mandate blockchain, a distributed ledger, a consensus algorithm,
or a single coordinating authority;
* define a proprietary coordinate system, computational model, trust
calculation, reasoning process, or synchronization mechanism;
* require publication of source code, model parameters, internal
reasoning traces, confidential topology, or security-sensitive
configuration;
* define an evidence-envelope, policy-profile, or conformance-report
wire binding;
* certify any deployment or implementation; or
* grant IETF endorsement or standards status to any implementation.
Jacobs Expires 17 February 2027 [Page 4]
Internet-Draft Web4 Node State and Admission August 2026
3. 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 "Web4", "Sovereign Entity", "Federation Node",
"Conformance Class", "Reference Implementation", and "Adjudication
Record" as defined by [JACOBS-TERM].
Node Identity: The persistent identity of a federation node,
independent of any current endpoint, credential, deployment,
certificate, process, or hosting location.
Identity Binding: A current representation or credential associated
with a node identity, such as a domain name, URI, certificate,
public key, endpoint, or platform identifier.
Node-State Declaration: A versioned account of node state material
to participation, policy, dependency, and conformance claims.
Admission Authority: An entity authorized under a declared policy to
admit, condition, suspend, revoke, or retire node participation.
Admission Record: A versioned record of an admission decision,
including authority, policy, scope, conditions, effective time,
and supporting evidence references.
Material Update: A change affecting identity bindings, operator,
role, authority, policy, dependency, admission, conformance, or
another field declared material by policy.
Succession Record: An explicit record linking a predecessor node to
a successor without silently transferring authority, admission,
evidence, or conformance.
Declaration Consumer: An authorized party that evaluates a node-
state declaration or admission record.
4. Requirements Model
The model separates identity, representation, lifecycle, role,
authority, evidence, conformance, availability, and policy.
Implementations MUST NOT collapse these dimensions into a single
undifferentiated trust value when doing so prevents a declaration
consumer from determining which property was evaluated.
Jacobs Expires 17 February 2027 [Page 5]
Internet-Draft Web4 Node State and Admission August 2026
A high operational role does not imply stronger substantive
authority. Availability does not imply admission. Admission does
not prove evidence quality. Conformance does not establish universal
validity. Node count does not establish independent
interoperability.
Persistent Node Identity
|
+-- Identity Bindings
+-- Operator and Roles
+-- Declared State
+-- Admission Records
+-- Policy References
+-- Dependency References
+-- Conformance References
+-- Lifecycle History
5. Persistent Node Identity Requirements
5.1. Identity and Representation
A node MUST have an identifier distinguishable from its current
identity bindings. A change to a domain name, address, certificate,
credential, process, container, cloud account, or endpoint MUST NOT
by itself create a new node identity.
A declaration MUST identify the scope in which the node identifier is
unique. A globally scoped identifier SHOULD be collision resistant.
A federation-local identifier MUST identify the federation or naming
authority defining its scope.
Identity bindings MUST be versioned or attributable to a material
update. A declaration consumer MUST be able to determine whether a
binding is current, historical, revoked, or unknown.
5.2. Operator Responsibility
A node declaration MUST identify the operator responsible for the
node. If operational responsibility is delegated, the declaration
MUST identify the relevant authority or delegation reference.
A change of operator is a material update. It MUST NOT silently
preserve delegated authority, admission scope, or conformance claims
unless policy explicitly permits continuity and the change is
recorded.
Jacobs Expires 17 February 2027 [Page 6]
Internet-Draft Web4 Node State and Admission August 2026
5.3. Roles
A node MAY declare one or more logical roles, including coordinating
node, member node, gateway, relay, evaluator, or evidence service. A
role declaration MUST NOT be interpreted as authority to perform an
action unless a corresponding authority or admission scope permits
it.
6. Node-State Declaration Requirements
A participating node MUST make a current node-state declaration
available to authorized declaration consumers. Availability MAY be
local, remote, online, offline, or mediated by a federation service.
This document does not require a public unauthenticated endpoint.
A node-state declaration MUST contain:
* a schema or model version;
* the persistent node identifier and identifier scope;
* the federation or network identifier, if applicable;
* the operator identifier and declared roles;
* the current admission state;
* current identity bindings or references;
* applicable policy-profile identifiers;
* the implementation version or integrity reference;
* material dependency references;
* conformance-report references, if claimed;
* a declaration version or advancing sequence;
* the declaration time and last material update; and
* an integrity mechanism or reference appropriate to the deployment.
A node MUST NOT present an unknown, unavailable, withheld, or
inapplicable value as confirmed. If policy permits withholding, the
declaration SHOULD distinguish WITHHELD from UNKNOWN and UNAVAILABLE.
Jacobs Expires 17 February 2027 [Page 7]
Internet-Draft Web4 Node State and Admission August 2026
A declaration MUST NOT claim that liveness proves evidence validity,
authority, conformance, or substantive correctness.
7. Admission Request Requirements
A candidate node seeking participation MUST submit or make available
an admission request containing:
* a request identifier;
* the candidate node identifier;
* the requested federation or participation domain;
* the operator identifier;
* requested roles, scope, and operations;
* identity bindings or binding references;
* the requested policy profile;
* material dependency declarations;
* a node-state declaration reference;
* evidence and conformance references required by policy;
* the request time; and
* an integrity mechanism or reference.
An admission authority MUST NOT infer requested authority solely from
network reachability, endpoint ownership, or role labels. Requested
scope MUST be evaluated under the applicable policy.
An admission request MAY reference confidential evidence available
only to an authorized reviewer. The shared request need not
reproduce confidential evidence when a stable evidence reference and
access policy are sufficient.
8. Admission Decision Requirements
An admission decision MUST identify:
* the admission-record and admission-request identifiers;
* the node identifier and decision;
Jacobs Expires 17 February 2027 [Page 8]
Internet-Draft Web4 Node State and Admission August 2026
* the admission authority;
* the applicable policy profile and version;
* the admitted roles, scope, and operations;
* conditions and limitations;
* supporting evidence or adjudication references;
* the effective time and any review or expiration time;
* the governance or change-event identifier; and
* an integrity mechanism or reference.
The decision value MUST be ADMITTED, REJECTED, CONDITIONAL, or
INDETERMINATE unless a future binding defines an extensible
equivalent. A recipient encountering an unknown decision value MUST
NOT treat it as ADMITTED.
Admission MUST be scoped. A node admitted for one role, operation,
federation, policy, or interval MUST NOT infer admission for another
scope.
9. Admission Lifecycle
CANDIDATE -> UNDER-REVIEW -> ADMITTED -> ACTIVE
| | | |
+-> REJECTED +-> REJECTED +-> SUSPENDED
+-> REVOKED
+-> RETIRED
CANDIDATE: The node is a potential participant; no review is
implied.
UNDER-REVIEW: An admission authority is evaluating the request.
ADMITTED: An admission decision exists, but activation conditions
might remain.
ACTIVE: The node is currently permitted to participate within the
admitted scope.
REJECTED: The request was not accepted.
SUSPENDED: Participation is temporarily disabled while identity and
history are preserved.
Jacobs Expires 17 February 2027 [Page 9]
Internet-Draft Web4 Node State and Admission August 2026
REVOKED: Admission has ended by authority decision.
RETIRED: The node has ended participation through planned lifecycle
closure.
A node MUST NOT represent itself as ACTIVE unless its admission
record is effective, its conditions are satisfied, and no effective
suspension or revocation exists.
Lifecycle transitions MUST be attributable to a decision or
governance event. Implementations MUST preserve sufficient history
to determine prior state and the event that changed it.
10. Authority and Delegation
An admission authority MUST be identifiable. Its authority MUST be
scoped by federation, role, operation, policy, time, or another
declared boundary.
Delegation MUST be explicit, attributable, scoped, and revocable. A
delegated authority MUST NOT exercise powers outside the recorded
delegation. Delegation SHOULD identify the delegating authority,
delegate, permitted decisions, effective interval, policy, and
revocation status.
A coordinating role MUST NOT be treated as automatic substantive
authority. A gateway enforcing admission at a transport boundary
MUST NOT infer authority to validate the truth of transported
evidence unless separately authorized.
Where multiple authorities can issue conflicting decisions, policy
MUST define precedence, conflict handling, or an INDETERMINATE
result.
11. Suspension, Revocation, and Re-Admission
11.1. Suspension
A suspension record MUST identify the node, authority, reason class,
scope, effective time, review or expiration conditions, applicable
policy, and governance event. It SHOULD identify whether sessions,
queued messages, credentials, or cached decisions remain valid.
Suspension MUST preserve node identity and historical admission
records.
Jacobs Expires 17 February 2027 [Page 10]
Internet-Draft Web4 Node State and Admission August 2026
11.2. Revocation
A revocation record MUST identify the node, authority, scope,
effective time, policy, reason class, and governance event.
Revocation MUST NOT erase historical exchanges, conformance reports,
adjudications, or prior state required by retention policy.
A node discovering its effective revocation MUST cease operations
that depend on the revoked admission scope.
11.3. Re-Admission
A revoked node requires a new admission decision. Re-admission MUST
reference the new request and decision and MUST NOT silently
reactivate the revoked record. Policy MAY require reference to the
prior revocation and remediation evidence.
12. Node Succession
A replacement deployment does not automatically become the same node.
If continuity through a new node identity is intended, an explicit
succession record MUST be created.
A succession record MUST identify:
* predecessor and successor node identifiers;
* the responsible authority, reason, and effective time;
* which identity bindings move or terminate;
* which admission scopes require new decisions;
* which evidence, obligations, and records remain with the
predecessor;
* whether conformance reports remain applicable; and
* an integrity mechanism or reference.
Authority, admission, evidence custody, and conformance MUST NOT
transfer silently. A result tied to an implementation version or
declared state MUST be re-evaluated when succession changes material
test conditions.
Jacobs Expires 17 February 2027 [Page 11]
Internet-Draft Web4 Node State and Admission August 2026
13. Freshness, Versioning, and Extensibility
A declaration MUST provide a timestamp, sequence, version, or
equivalent freshness indicator. A declaration consumer MUST be able
to distinguish current state from stale, replayed, or superseded
state within applicable policy.
Where replay can affect participation, implementations SHOULD use
timestamps, nonces, sequence values, short-lived proofs, or
equivalent controls.
Future bindings MUST distinguish binding version, information-model
version, and node-implementation version. Version negotiation MUST
fail cleanly when mandatory behavior is incompatible. An unknown
major version MUST NOT be treated as compatible.
Future bindings SHOULD define mandatory-to-understand semantics.
Unknown optional fields MAY be ignored only when doing so does not
alter security, authority, admission, policy, or constraint
semantics. Extension mechanisms SHOULD follow [RFC6709] and
[RFC9413].
14. Dependencies and Conformance References
A node-state declaration MUST identify dependencies material to its
claimed operation. A dependency reference SHOULD identify the
provider or service class, purpose, availability state, and whether
it is required for connected operation, disconnected operation,
evidence access, identity, policy, or intelligence capability.
A node claiming conformance MUST reference a report identifying the
framework, tested implementation version, evidence set, policy
profile, evaluator, interval, result, limitations, and integrity
reference.
Admission MUST NOT be represented as conformance. Conformance MUST
NOT be represented as admission. A coordinating node's result does
not transfer to members, and a member's result does not transfer
automatically to a successor or materially changed implementation.
15. Failure Semantics
A future protocol binding MUST provide explicit failure results and
MUST NOT silently convert failed admission or state validation into a
successful generic response.
UNSUPPORTED-VERSION: The binding or model version is not supported.
Jacobs Expires 17 February 2027 [Page 12]
Internet-Draft Web4 Node State and Admission August 2026
INVALID-NODE-IDENTITY: The node identifier or binding cannot be
validated.
INVALID-INTEGRITY: An integrity check or signature failed.
UNKNOWN-FEDERATION: The requested federation or participation domain
is unknown.
NOT-ADMITTED: No effective admission exists for the requested scope.
ADMISSION-SUSPENDED: Participation is suspended.
ADMISSION-REVOKED: Admission has been revoked.
STALE-DECLARATION: The declaration fails freshness policy.
REPLAY-DETECTED: The request or declaration appears replayed.
POLICY-CONFLICT: Applicable policies cannot authorize the operation.
CONSTRAINT-UNSUPPORTED: A material condition cannot be enforced.
INSUFFICIENT-EVIDENCE: Required evidence is absent or unavailable.
AUTHORITY-UNAVAILABLE: A required authority cannot be resolved or
reached.
CONFORMANCE-NOT-DECLARED: Required conformance information is
absent.
RATE-LIMITED: Resource policy prevents current processing.
INDETERMINATE: No authorized final result can be established.
A binding SHOULD identify whether an error is temporary or permanent,
whether retry is allowed, whether human review is required, and which
details can be disclosed safely.
16. Abstract Information Model
The examples in this section are non-normative. They do not define a
JSON binding, media type, canonicalization rule, or signature format.
A future binding can use CDDL [RFC8610], JSON canonicalization
[RFC8785], or another mechanism after its requirements are evaluated.
16.1. Node-State Declaration Example
Jacobs Expires 17 February 2027 [Page 13]
Internet-Draft Web4 Node State and Admission August 2026
{
"schema_version": "0.1",
"declaration_id": "DECLARATION-001",
"node_id": "NODE-EXAMPLE-1",
"node_id_scope": "FEDERATION-EXAMPLE",
"operator": "OPERATOR-EXAMPLE-1",
"roles": ["member"],
"admission_state": "ACTIVE",
"identity_bindings": [
{
"type": "uri",
"value": "https://node-a.example.com/",
"status": "current"
}
],
"policy_profiles": ["POLICY-EXAMPLE-1.0"],
"implementation": {
"version": "1.0",
"integrity_reference": "urn:example:integrity:build-1"
},
"dependencies": ["DEPENDENCY-DECLARATION-001"],
"conformance_reports": ["CONFORMANCE-REPORT-001"],
"sequence": 42,
"declared_at": "2026-08-16T00:00:00Z",
"last_material_update": "GOVERNANCE-EVENT-100",
"integrity_reference": "urn:example:integrity:declaration-001"
}
16.2. Admission Request Example
{
"schema_version": "0.1",
"request_id": "ADMISSION-REQUEST-001",
"node_id": "NODE-EXAMPLE-1",
"requested_federation": "FEDERATION-EXAMPLE",
"operator": "OPERATOR-EXAMPLE-1",
"requested_roles": ["member"],
"requested_scope": ["evidence-exchange"],
"identity_binding_references": ["BINDING-SET-001"],
"policy_profile": "POLICY-EXAMPLE-1.0",
"dependency_declaration": "DEPENDENCY-DECLARATION-001",
"node_state_declaration": "DECLARATION-001",
"evidence_references": ["NODE-IDENTITY-EVIDENCE-001"],
"conformance_references": ["CONFORMANCE-REPORT-001"],
"requested_at": "2026-08-16T00:00:00Z",
"integrity_reference": "urn:example:integrity:request-001"
}
Jacobs Expires 17 February 2027 [Page 14]
Internet-Draft Web4 Node State and Admission August 2026
16.3. Admission Decision Example
{
"schema_version": "0.1",
"admission_record_id": "ADMISSION-001",
"request_id": "ADMISSION-REQUEST-001",
"node_id": "NODE-EXAMPLE-1",
"decision": "ADMITTED",
"admission_authority": "AUTHORITY-EXAMPLE-1",
"policy_profile": "POLICY-EXAMPLE-1.0",
"roles": ["member"],
"scope": ["evidence-exchange"],
"conditions": ["status-declaration-required"],
"evidence_references": ["NODE-IDENTITY-EVIDENCE-001"],
"effective_at": "2026-08-16T00:00:00Z",
"review_at": "2027-02-16T00:00:00Z",
"governance_event": "GOVERNANCE-EVENT-101",
"integrity_reference": "urn:example:integrity:admission-001"
}
17. Operational Considerations
Operators need to detect and investigate identity-binding failure,
stale state, suspended or revoked participation, policy mismatch,
authority conflict, integrity failure, unavailable dependencies, and
declaration-distribution failure.
Deployments SHOULD provide bounded visibility into current schema and
implementation versions, admission and lifecycle state, declaration
freshness, last material update, dependency availability, policy
versions, conformance references, validation failures, replay events,
and audit or governance sequence.
Detailed operational information can expose topology, dependencies,
versions, and security posture. Deployments SHOULD provide
authenticated detail while limiting public disclosure according to
risk. Future bindings should apply the operational guidance in
[RFC5706].
18. Implementation Status
This section records known implementation experience using the
approach described in [RFC7942]. It may be updated during
development or removed before RFC publication.
KTS Global reports an operational reference deployment implementing
persistent node identifiers, explicit admission state, gateway-
mediated participation, per-node state or health surfaces, and
Jacobs Expires 17 February 2027 [Page 15]
Internet-Draft Web4 Node State and Admission August 2026
auditable federation changes. The deployment is proprietary. Public
architecture and observable requirements are documented without
disclosing protected internal coordination, computation, or security-
sensitive configuration.
The operator reports production operation since 26 January 2026 and
twenty-one participating nodes as of 5 August 2026. These statements
are implementation evidence supplied by the operator. Formal
conformance to this revision and independent cross-implementation
interoperability have not yet been reported.
Implementation experience informed identity and endpoint separation,
explicit lifecycle, state freshness, failure semantics, and the
requirement not to equate node count with independent
interoperability.
19. Security Considerations
This document defines security-relevant requirements for identity and
admission. Implementers and reviewers should also apply [RFC3552].
19.1. Node Impersonation and Binding Substitution
An attacker can present a valid-looking endpoint or credential under
a false node identity. Protected declarations and updates MUST
authenticate the source and bind the node identifier to current
credentials or equivalent evidence. Binding rotation MUST be
attributable.
19.2. Authority Compromise
An attacker controlling an admission authority can admit malicious
nodes, expand scope, or suppress revocation. Implementations SHOULD
minimize authority, separate duties where appropriate, protect
authority credentials, and preserve attributable governance events.
19.3. Replay and Stale State
Historical declarations or decisions can be replayed to simulate
valid participation. Deployments SHOULD enforce freshness, sequence,
nonce, expiry, or equivalent policy and MUST reject stale state where
freshness is security material.
19.4. Version and Policy Downgrade
An attacker can force an older schema, policy, or credential method.
Implementations SHOULD declare supported versions and MUST reject
unauthorized downgrade.
Jacobs Expires 17 February 2027 [Page 16]
Internet-Draft Web4 Node State and Admission August 2026
19.5. Confused Deputy
A gateway, coordinating node, or member can exercise authority on
behalf of a source lacking permission. Authorization MUST be
operation specific and evaluated against source identity,
destination, requested scope, and policy.
19.6. Denial of Service and Resource Exhaustion
Admission and evidence verification can consume significant
resources. Implementations SHOULD bound input size, request
frequency, verification work, concurrency, and retained state
according to risk.
19.7. Operational Disclosure
Declarations can reveal topology, operators, versions, dependencies,
conformance status, or incident state. Access controls and redaction
SHOULD preserve the minimum information needed for an authorized
decision.
20. Privacy and Governance Considerations
Node declarations and admission records can contain personal,
organizational, jurisdictional, behavioral, and relationship
information. Deployments MUST apply applicable privacy and
governance requirements.
Collection and disclosure SHOULD be limited to information needed for
identity, admission, policy, security, conformance, or audit. Public
declarations SHOULD avoid unnecessary operator details, precise
topology, personal contact information, confidential dependencies,
and sensitive relationship data.
Persistent identifiers increase correlation risk across federations.
A deployment SHOULD document whether identifiers are global,
federation local, rotating, pseudonymous, or linkable and SHOULD
avoid cross-context linkage not required by policy.
Retention periods SHOULD be declared. Revocation does not require
public retention of all underlying evidence, but sufficient history
may be required for audit, dispute, legal obligation, or incident
investigation.
Where a decision materially affects a person or organization,
governance SHOULD provide a method to identify the applicable record,
submit correction or challenge evidence, preserve prior state, and
record the resulting decision.
Jacobs Expires 17 February 2027 [Page 17]
Internet-Draft Web4 Node State and Admission August 2026
21. Future Protocol Bindings
A future binding can define request and response messages,
deterministic encoding, signatures, media types, discovery,
transport, caching, and IANA registries. Such a binding SHOULD:
* remain independent of internal computational architecture;
* preserve opaque stable identifiers;
* define canonical integrity coverage;
* define version negotiation and mandatory-to-understand behavior;
* define explicit errors and retry behavior;
* provide positive and negative test vectors;
* support authenticated and access-controlled declarations;
* document privacy and correlation consequences; and
* demonstrate an interoperable implementation path.
Use of JSON could require a canonicalization mechanism such as
[RFC8785] when signatures cover serialized content. Use of JSON or
CBOR could use CDDL [RFC8610]. These references are informative;
this document does not select a binding.
Where hardware or platform evidence is used, future work should
analyze alignment with the Remote ATtestation procedureS architecture
in [RFC9334] rather than redefining attestation roles.
22. IANA Considerations
This document has no IANA actions.
23. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
Jacobs Expires 17 February 2027 [Page 18]
Internet-Draft Web4 Node State and Admission August 2026
[JACOBS-TERM]
Jacobs, T., "Web4 Terminology and Definitions", Work in
Progress, Internet-Draft, draft-jacobs-web4-terminology-
00, August 2026, <https://datatracker.ietf.org/doc/draft-
jacobs-web4-terminology/>.
[JACOBS-ARCH]
Jacobs, T., "Web4 Federation Architecture Model", Work in
Progress, Internet-Draft, draft-jacobs-web4-federation-
architecture-00, August 2026,
<https://datatracker.ietf.org/doc/draft-jacobs-web4-
federation-architecture/>.
24. Informative References
[JACOBS-MEC]
Jacobs, T., "Web4 Sovereign Entity Comprehension:
Requirements and External Conformance Framework", Work in
Progress, Internet-Draft, draft-jacobs-web4-sovereign-
entity-comprehension-00, August 2026,
<https://datatracker.ietf.org/doc/draft-jacobs-web4-
sovereign-entity-comprehension/>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
RFC 5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>.
[RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
September 2012, <https://www.rfc-editor.org/info/rfc6709>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, June 2019,
<https://www.rfc-editor.org/info/rfc8610>.
Jacobs Expires 17 February 2027 [Page 19]
Internet-Draft Web4 Node State and Admission August 2026
[RFC8785] Rundgren, A., Jordan, B., and S. Erlandsson, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, January 2023,
<https://www.rfc-editor.org/info/rfc9334>.
[RFC9413] Thomson, M. and D. Schinazi, "Maintaining Robust
Protocols", RFC 9413, June 2023,
<https://www.rfc-editor.org/info/rfc9413>.
Acknowledgements
This document was informed by implementation experience with an
operating multi-node federation and by the architectural and
protocol-design guidance cited here. Review and implementation
feedback are invited.
Author's Address
Tim Jacobs
KTS Global
United Arab Emirates
Email: tim@ktsglobal.live
Jacobs Expires 17 February 2027 [Page 20]