Web4 Node State and Admission Requirements

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

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

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

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

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

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

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;¶

• 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.¶

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

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

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

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

{
  "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"
}

{
  "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"
}

{
  "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 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].¶

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

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

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