Invariant-Closed System Design (ICSD)
draft-dpa-icsd-01
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 | Benjamin Anthony Fisher | ||
| Last updated | 2026-03-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Additional Web Page
|
||
| 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-dpa-icsd-01
Network Working Group B.A. Fisher
Internet-Draft DPA R&D
Intended status: Informational 16 March 2026
Expires: 17 September 2026
Invariant-Closed System Design (ICSD)
draft-dpa-icsd-01
Abstract
Invariant-Closed System Design (ICSD) defines an architectural
principle for building systems in which all representable states are
valid and compliant by construction. Rather than relying on runtime
detection, validation, or remediation of invalid or abusive
behaviour, ICSD ensures that invalid states are structurally
unrepresentable through constrained state models, invariant-bound
transitions, and authority-anchored truth sources.
This document introduces the ICSD concept, its core properties,
design trade-offs, and applicability to compliance-critical domains
such as payroll, taxation, financial reporting, and regulated
infrastructure. It defines the current architectural and semantic
baseline for the ICSD portion of the suite.
This document is part of an experimental, research-oriented
Independent Stream suite. It defines the current normative baseline
for trust objects, validation rules, and security semantics within
its scope. Hard interoperability is expected for shared object
semantics and validation rules. Full wire-level, clustering, and
proof-family interoperability is not claimed everywhere yet; the
remaining details are intentionally profile-defined or deferred where
companion work has not yet closed them.
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."
Fisher Expires 17 September 2026 [Page 1]
Internet-Draft ICSD March 2026
This Internet-Draft will expire on 17 September 2026.
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.
Table of Contents
1. Scope and Status . . . . . . . . . . . . . . . . . . . . . . 3
2. Executive Summary . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Core Principle . . . . . . . . . . . . . . . . . . . . . . . 6
6. Invariant-Bound State Space . . . . . . . . . . . . . . . . . 6
7. Survivability and Sovereignty Invariants . . . . . . . . . . 7
7.1. Survivability Invariant . . . . . . . . . . . . . . . . . 7
7.2. No Singular Trust Anchor Invariant . . . . . . . . . . . 7
7.3. Bootstrap Trust Boundary . . . . . . . . . . . . . . . . 8
7.4. Fork Survivability . . . . . . . . . . . . . . . . . . . 8
7.5. Closure Is Not Centralisation . . . . . . . . . . . . . . 9
7.6. Transparent Accountability Invariant . . . . . . . . . . 9
7.7. Anti-Kill-Switch Principle . . . . . . . . . . . . . . . 9
8. Authority-Anchored Truth . . . . . . . . . . . . . . . . . . 9
9. Non-Representable Invalid States . . . . . . . . . . . . . . 10
10. Elimination of Reactive Enforcement . . . . . . . . . . . . . 10
11. Auditability and Compliance . . . . . . . . . . . . . . . . . 11
12. Design Trade-offs . . . . . . . . . . . . . . . . . . . . . . 12
13. Comparison with Traditional Designs . . . . . . . . . . . . . 12
14. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
14.1. Applicability to Identity-Bound Security Systems . . . . 13
15. Security Considerations . . . . . . . . . . . . . . . . . . . 13
16. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14
17. One-Sentence Summary . . . . . . . . . . . . . . . . . . . . 14
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
19. Normative References . . . . . . . . . . . . . . . . . . . . 14
20. Informative References . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Fisher Expires 17 September 2026 [Page 2]
Internet-Draft ICSD March 2026
1. Scope and Status
This Internet-Draft is part of an experimental, research-oriented
suite prepared for the Independent Stream. It is published to enable
structured technical review, experimentation, and architectural
discussion around Invariant-Closed System Design (ICSD).
Within that suite, this document defines the current normative
baseline for trust objects, validation rules, and security semantics
relevant to invariant-bound state transitions, evidence handling, and
authority-anchored truth evaluation. Hard interoperability is
expected for shared object semantics and validation rules.
The material is a research artefact. It does not claim technical
completeness, production readiness, or endorsement by the IETF or any
other standards body, and it is not presented as a standards-track
specification.
Full wire-level, clustering, and proof-family interoperability is not
claimed everywhere yet; relevant suite-level details remain
intentionally profile-defined or deferred. ICSD is therefore
presented primarily as an architectural and semantic baseline rather
than a complete protocol, and it does not mandate a particular
programming language, database technology, exchange format, or
deployment model.
A reference Python implementation and tooling baseline for ICSD is
available as dpa-icsd on PyPI. As of March 6, 2026, the latest
listed release is 1.0.10 and includes the icsd-dpa CLI for evidence
verification and linting. This implementation is informative only
and does not define the normative specification.
2. Executive Summary
Many systems attempt to achieve correctness and compliance by
accepting broad inputs, then using validation, monitoring,
moderation, and repair mechanisms to detect and handle invalid
behaviour after it occurs. This reactive approach increases
operational complexity, creates ambiguous intermediate states, and
expands the attack and abuse surface.
Invariant-Closed System Design (ICSD) proposes a different approach:
design the system such that only valid states can exist. In an ICSD
system, invalid and non-compliant states are not "handled" at runtime
because they are not representable in the system's state space.
Fisher Expires 17 September 2026 [Page 3]
Internet-Draft ICSD March 2026
ICSD shifts complexity from runtime policing towards upfront
modelling. It improves auditability by ensuring every persisted
state is valid, and it reduces abuse opportunities that rely on
malformed, partial, or inconsistent internal state.
3. Terminology
*Requirements Language:* 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 [RFC2119] and
[RFC8174] when, and only when, they appear in all capitals.
*System State:* The complete set of values that determines system
behaviour at a given instant, including persisted data and any in-
scope in-memory state.
*Representable State:* A state that the system can encode in its data
model and reach through its defined transitions.
*Invariant:* A condition that MUST hold for all representable states
of the system (e.g., legal constraints, accounting identities,
authorisation constraints, or schema requirements).
*Invariant-Closed:* A property of a system where the set of
representable states is closed under the invariants; i.e., every
representable state satisfies every invariant.
*Authority-Anchored Truth Source:* An external or internal source of
truth that is treated as authoritative for specific facts (e.g.,
statutory registries, regulated rulesets, signed identity assertions,
or versioned policy artefacts).
*Bootstrap Trust Boundary:* The admission boundary between a
principal that is not yet inside the closed trust domain and one that
has completed explicit bootstrap validation under accepted seed
material, policy, and authority constraints.
*No Singular Trust Anchor:* A design property in which no single
issuer, registry, revocation service, controller, or bootstrap source
can unilaterally determine continued legitimacy for the whole system.
*Recovery / Re-Enrolment:* A privileged trust transition by which a
previously known principal returns to an admissible state under
tighter artefact, supersession, and policy checks than ordinary
steady-state operation.
Fisher Expires 17 September 2026 [Page 4]
Internet-Draft ICSD March 2026
*Fork Survivability:* A property of an invariant-closed system in
which independent continuation remains locally verifiable even if
previously aligned authorities, registries, or operators diverge.
*Reactive Enforcement:* Any mechanism that detects, mitigates, or
remediates invalid behaviour after it has been encoded as a system
state (e.g., validation errors on persistence, moderation queues,
anomaly scoring, or repair jobs).
4. Introduction
Contemporary systems often permit a broad range of inputs and states,
depending on reactive mechanisms - validation checks, monitoring,
moderation, or repair - to handle invalid, non-compliant, or abusive
behaviour after it occurs. This reactive approach increases
operational complexity, maintenance burden, and exposure to errors or
attacks that exploit inconsistent or intermediate states.
Invariant-Closed System Design (ICSD) offers an alternative paradigm:
systems are structured so that only valid states can exist. Invalid
or non-compliant states are not detected and corrected - they are
prevented by design, as they have no representation in the system's
state space.
The core axiom of ICSD is: If a system state can exist, it is already
valid. Correctness, regulatory compliance, and legitimacy are
embedded directly into the type system, input constraints, transition
rules, and data sources.
This document outlines the ICSD principle, contrasts it with
traditional reactive designs, and explores its benefits in domains
where trust assumptions are minimal and authoritative sources define
ground truth. Examples draw from production experience in payroll
and taxation systems, where invariants are non-negotiable.
ICSD is particularly relevant to high-assurance environments,
including financial systems, identity management, regulatory
reporting, and secure infrastructure protocols.
Fisher Expires 17 September 2026 [Page 5]
Internet-Draft ICSD March 2026
This draft should therefore be read as part of an experimental,
research-oriented Independent Stream suite and as the current
normative baseline for trust objects, validation rules, and security
semantics within its scope. Hard interoperability is expected for
shared object semantics and validation rules. Full wire-level,
clustering, and proof-family interoperability is not claimed
everywhere yet; relevant details remain intentionally profile-defined
or deferred in companion work. Multiple authorities or truth sources
do not by themselves solve decentralisation, and broader availability
properties still depend on explicit profile and deployment choices.
5. Core Principle
The foundational axiom of ICSD is: *If a system state can exist, it
is already valid.*
Reactive design (detect+repair) | ICSD design (invalid unrep.)
input | input (constrained)
| | |
v | v
[broad parsing] | [invariant-safe encoding]
| | |
v | v
[state may be invalid] | [state always valid]
| | |
v | v
[detect/moderate/repair] | [audit transition history]
Figure 1: Reactive enforcement versus invariant-closed design
In a reactive design, the system must cope with invalid-but-encoded
states and expend effort detecting, triaging, and correcting them.
In an invariant-closed design, invalid states are unreachable: the
system's representational model does not permit them, and transitions
preserve invariants by construction.
ICSD does not imply that a system is small or trivial. Rather, it
implies that as complexity increases, the modelling discipline
increases as well: each additional state and transition is admitted
only if it can be expressed in a way that preserves invariants.
6. Invariant-Bound State Space
An ICSD system defines a closed set of invariants: conditions that
must always hold true. These invariants define the system's state
space. The system MUST ensure that:
Fisher Expires 17 September 2026 [Page 6]
Internet-Draft ICSD March 2026
* all representable states satisfy all invariants;
* all state transitions preserve invariant validity; and
* no mechanism exists to bypass or temporarily suspend invariants.
In practice, this typically requires modelling state as a finite set
of well-defined types (or records) whose construction is only
possible through invariant-preserving transitions.
Examples of non-negotiable invariants in compliance-critical domains
include:
* a payroll run cannot exist without a verified legal entity and an
applicable tax context;
* a regulatory submission artefact cannot exist unless schema and
policy validation have passed; and
* an authorisation grant cannot exist without a verified identity
and an explicit scope of authority.
In ICSD, invariants are not optional checks; they define what the
system can represent.
7. Survivability and Sovereignty Invariants
This section defines constitutional invariants for ICSD systems that
operate in adversarial, decentralised, or jurisdictionally fragmented
environments.
7.1. Survivability Invariant
An invariant-closed system MUST remain operational if any single
administrative, organisational, or jurisdictional entity ceases
operation or becomes adversarial.
Consequently, an invariant-closed system MUST NOT require any single
dependency class as an operational precondition, including any single
identity issuer, certificate authority, revocation service, relay
operator, directory service, or bootstrap source.
7.2. No Singular Trust Anchor Invariant
No invariant-closed system SHALL depend on a singular trust anchor
whose compromise invalidates the system's operational guarantees.
Fisher Expires 17 September 2026 [Page 7]
Internet-Draft ICSD March 2026
This prohibition includes, but is not limited to, central CAs, global
revocation lists, authorising bodies, mandatory bootstrap registries,
mandatory relay controllers, or singular revocation services when
used as unique trust anchors.
7.3. Bootstrap Trust Boundary
An invariant-closed system is not self-originating. A brand-new
device, node, or principal is not yet within the closed trust domain
and must first be admitted through an explicit bootstrap process.
Bootstrap trust is therefore a first-class architectural concern
rather than an implicit property of the steady-state protocol.
Deployments must define which bootstrap sources they accept.
Acceptable bootstrap inputs may include manufacturer attestation,
owner-installed or operator-installed seed trust, pre-provisioned
deployment credentials, local attestation ceremony, physically
mediated enrolment, custodial onboarding authority, verified HIL-
assisted enrolment, or administrative or MDM-style approval under
signed policy. The bootstrap authority MUST be explicit, narrow,
auditable, and non-magical.
Bootstrap trust does not, by itself, confer unlimited steady-state
authority. Once bootstrap is complete, ordinary invariants, scope
limits, revocation rules, and policy validation MUST apply, and the
bootstrap path MUST NOT silently bypass them.
Bootstrap, recovery, and re-enrolment are privileged trust
transitions and are especially suitable for invariant-closed
modelling because admissible artefacts, bounded authority,
supersession rules, and fail-closed outcomes can be made explicit.
An ICSD-aligned system should make unauthorised or ambiguous Day Zero
and recovery states structurally unrepresentable rather than merely
detectable after admission.
7.4. Fork Survivability
An invariant-closed system MUST permit independent continuation
(fork) without invalidating identity or operational semantics for
participating nodes.
Post-fork operation MUST remain locally verifiable and MUST NOT
depend on continued alignment to a canonical registry for legitimacy.
Fisher Expires 17 September 2026 [Page 8]
Internet-Draft ICSD March 2026
For identity-bound systems, this implies that identities remain
usable post-fork, mediator operation remains registry-independent,
trust relationships remain independently maintainable, and
accountability or transparency artefacts remain locally interpretable
even when no single post-fork authority is universally recognised.
7.5. Closure Is Not Centralisation
Closed does not mean centrally controlled.
Closure refers to integrity-bound operational constraints and
cryptographically sealed state-transition semantics, not
administrative centralisation.
7.6. Transparent Accountability Invariant
Invariant-closed systems SHOULD provide cryptographic transparency or
accountability mechanisms sufficient to permit independent
verification of system behaviour and state transitions.
Examples include signed append-only transparency logs, cryptographic
reachability evidence, and verifiable misbehaviour proofs.
7.7. Anti-Kill-Switch Principle
No invariant-closed system SHALL include unilateral global revocation
or termination capabilities absent multi-party cryptographic
consensus.
8. Authority-Anchored Truth
Where possible, ICSD systems anchor truth to authoritative sources
rather than user assertion. This reduces trust assumptions and
limits the risk of fabricated, inconsistent, or self-contradictory
state.
Authority anchoring does not require a singular administrative
authority. Multiple independent authoritative sources MAY coexist if
they preserve the invariants defined by the system.
Authority anchoring commonly appears as:
* company identity derived from statutory registries;
* tax calculations constrained by authoritative rulesets and
versioned guidance;
Fisher Expires 17 September 2026 [Page 9]
Internet-Draft ICSD March 2026
* roles and authority derived from official records or
cryptographically signed policy artefacts; and
* identity claims derived from verified credentials rather than
mutable profile fields.
User input is treated primarily as selection, initiation, or proposal
- not as the authoritative ground truth. Where user input is
necessary (e.g., choosing a tax code), the representational model
SHOULD restrict it to a set of invariant-safe options.
9. Non-Representable Invalid States
A defining property of ICSD is the elimination of representable
invalid states. In an ICSD system, there are no:
* invalid-but-saved records;
* broken intermediate states;
* speculative or partially complete entities; or
* privileged objects created before authority has been verified.
If a configuration or object cannot be valid, it has no
representation in storage or memory. This removes entire classes of
bugs and abuse vectors associated with partial, inconsistent, or
order-dependent state.
10. Elimination of Reactive Enforcement
Because invalid behaviour cannot be encoded, ICSD systems minimise or
eliminate the need for reactive enforcement mechanisms such as:
* heuristic abuse detection and anomaly scoring;
* moderation queues and manual review pipelines;
* background repair jobs for data quality;
* error-driven state reconciliation; and
* ad hoc "fix-forward" scripts to correct invalid persistence.
Reactive enforcement is replaced by structural impossibility. The
system does not monitor for invalid behaviour; it cannot represent
it.
Fisher Expires 17 September 2026 [Page 10]
Internet-Draft ICSD March 2026
This does not remove all monitoring needs. Systems may still monitor
for availability, performance, and suspicious but valid activities.
ICSD specifically targets the class of failures where invalidity
arises from representable internal state.
11. Auditability and Compliance
In ICSD systems, auditability emerges as a side effect of correct
design:
* every persisted state is valid;
* audit logs describe state transitions, not error recovery;
* compliance evidence is implicit in system history; and
* reconciliation becomes verification rather than investigation.
A practical consequence is that auditors and operators can reason
over the system using a smaller set of cases: "what valid state did
we enter, when, and under what authority?" rather than "what went
wrong and how did we patch it?"
ICSD is especially valuable where invariants are externally imposed
(e.g., law and regulation) and where failure modes have significant
cost (e.g., financial penalties, reputational harm, or operational
shutdown).
High-value control-plane elements are especially strong candidates
for invariant-closed modelling. Examples include RN controllers,
patch or release manifests, grant ledgers, route-policy objects, and
similar authority-bearing artefacts in identity-centric systems. For
such objects, the design goal is that unsigned overrides, invalid
signer sets, rollback states, policy-ineligible transitions, and
partial-write artefacts are not merely detected after the fact but
are structurally unrepresentable.
As a small informative example, a UZPIF-compatible deployment could
model RN controller state acceptance as an invariant-closed
transition: a controller update would become admissible only when the
signed controller object, the authority set accepted at the bootstrap
trust boundary or by later recovery / re-enrolment, epoch or sequence
precedence, and applicable policy scope all validate together. This
illustrates a compatible design discipline, not a requirement that
UZPIF implementations adopt ICSD as a mandatory framework,
prerequisite layer, or protocol dependency.
Fisher Expires 17 September 2026 [Page 11]
Internet-Draft ICSD March 2026
12. Design Trade-offs
ICSD deliberately shifts complexity away from runtime policing and
remediation towards upfront modelling and invariant definition. This
increases initial design discipline but can reduce long-term
maintenance cost, operational overhead, abuse surface area, and
regulatory exposure.
Common trade-offs include:
* *Reduced flexibility:* inputs and workflows may be more
constrained than in permissive systems.
* *Upfront modelling cost:* invariants must be identified,
formalised, and tested early.
* *Migration complexity:* legacy datasets containing invalid state
may require transformation.
* *Profile management:* different jurisdictions or policy regimes
may require explicit profiles.
ICSD is not a statement that "validation is bad". It is a statement
about where validation belongs: as part of constructing representable
state, rather than as a recurring operational burden after invalidity
has already been encoded.
13. Comparison with Traditional Designs
+===========================+====================================+
| Traditional design | ICSD design |
+===========================+====================================+
| Accepts broad input | Accepts only invariant-safe input |
+---------------------------+------------------------------------+
| Detects invalid behaviour | Cannot represent invalid behaviour |
+---------------------------+------------------------------------+
| Repairs bad states | Prevents bad states |
+---------------------------+------------------------------------+
| Relies on monitoring | Relies on structure and modelling |
+---------------------------+------------------------------------+
| Compliance as process | Compliance as property |
+---------------------------+------------------------------------+
| Security controls often | Many controls become inherent to |
| layered on top | the state model |
+---------------------------+------------------------------------+
Table 1: Traditional design compared with ICSD
Fisher Expires 17 September 2026 [Page 12]
Internet-Draft ICSD March 2026
ICSD does not remove the need for good engineering practices such as
testing, change control, or operational security. It changes the
baseline: correctness and compliance become properties of what the
system can represent.
14. Applicability
ICSD is particularly well suited to domains where:
* correctness is mandatory and errors have high cost;
* authoritative sources define ground truth;
* trust cannot be assumed; and
* regulatory exposure is high.
Example domains include payroll and taxation, financial systems,
identity and access control, regulatory reporting, and secure
infrastructure and protocol design.
14.1. Applicability to Identity-Bound Security Systems
In identity-first architectures, a common failure mode is the
existence of "privileged but invalid" objects, such as a grant that
exists before identity is verified, or a session that exists before
policy checks are applied. ICSD mitigates this by making such
objects unrepresentable: the only representable grants and sessions
are those that are already bound to verified identity and explicit
authority.
This principle complements identity-bound frameworks and transports
such as [UZPIF], [UZP], and [TLS-DPA], where correctness and
authorisation are expected to be intrinsic properties of the
connection and its negotiated state. ICSD is therefore best read as
a design discipline and implementation approach that fits such
systems well, not as a suite-mandatory governance layer, required
subsystem, or deployment prerequisite.
15. Security Considerations
ICSD can reduce attack surface by eliminating representable invalid
states. Many classes of injection, abuse, and privilege escalation
rely on malformed, partial, or inconsistent internal state; ICSD
systems make such states unreachable by design.
Fisher Expires 17 September 2026 [Page 13]
Internet-Draft ICSD March 2026
However, ICSD is not a complete security model. A representable
state being "valid" with respect to invariants does not guarantee
that it is desirable. Attackers can still:
* perform harmful actions that are valid within policy (e.g.,
authorised but abusive use);
* target the integrity of truth sources (e.g., poisoning authority
data);
* exploit incorrect invariant definitions (i.e., specification
bugs); and
* attack availability (e.g., denial-of-service) regardless of state
validity.
Designers should treat invariants and authority sources as security-
critical artefacts: they SHOULD be versioned, reviewed, tested, and
auditable. Where possible, authority inputs SHOULD be authenticated
(e.g., signatures, provenance records) and changes SHOULD be subject
to explicit change control.
16. Conclusion
Invariant-Closed System Design reframes correctness from a runtime
concern into a structural property. By designing systems where
invalid behaviour is not prevented but structurally impossible, ICSD
can reduce operational complexity, improve auditability, and
strengthen trustworthiness in compliance-critical environments.
ICSD is best viewed as a discipline: it rewards rigorous modelling
and clear definitions of invariants and authority. Where those
conditions hold, it can remove entire classes of failures that
otherwise demand continuous monitoring and remediation. It can
inform architectures such as UZPIF, UZP, and TLS-DPA without being a
prerequisite for deploying or understanding them.
17. One-Sentence Summary
Invariant-Closed System Design is the practice of building systems
where invalid behaviour is not prevented - it is structurally
impossible.
18. IANA Considerations
This document has no IANA actions.
19. Normative References
Fisher Expires 17 September 2026 [Page 14]
Internet-Draft ICSD March 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 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, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
20. Informative References
[TLS-DPA] Fisher, B. A., "TLS-DPA: An Identity-Bound Security
Protocol for Traditional, Overlay, and Zero-Port
Transports", Work in Progress, Internet-Draft, draft-dpa-
tls-dpa,
<https://datatracker.ietf.org/doc/html/draft-dpa-tls-dpa>.
[UZP] Fisher, B. A., "UZP: Universal Zero-Port Transport
Protocol", Work in Progress, Internet-Draft, draft-dpa-
uzp-transport, <https://datatracker.ietf.org/doc/html/
draft-dpa-uzp-transport>.
[UZPIF] Fisher, B. A., "The Universal Zero-Port Interconnect
Framework (UZPIF): An Identity-Centric Architecture for
Post-Port Networking", Work in Progress, Internet-Draft,
draft-dpa-uzpif-framework,
<https://datatracker.ietf.org/doc/html/draft-dpa-uzpif-
framework>.
Author's Address
Benjamin Anthony Fisher
DPA R&D Ltd (https://www.dpa-cloud.co.uk)
Email: b.fisher@dpa-cloud.co.uk
URI: https://orcid.org/0009-0004-4412-2269
Fisher Expires 17 September 2026 [Page 15]