



Network Working Group                                        B.A. Fisher
Internet-Draft                                                   DPA R&D
Intended status: Informational                            6 January 2026
Expires: 10 July 2026


  The Universal Zero-Port Interconnect Framework (UZPIF): An Identity-
             Centric Architecture for Post-Port Networking
                      draft-dpa-uzpif-framework-00

Abstract

   The Universal Zero-Port Interconnect Framework (UZPIF) describes a
   post-port networking model in which communication is established via
   outbound, identity-bound sessions to Rendezvous Nodes (RNs).  By
   removing publicly reachable listening ports at endpoints, UZPIF aims
   to reduce exposure to Internet-wide scanning and unsolicited ingress,
   and to constrain a broad class of lateral-movement vectors.

   This document outlines architectural motivation, a high-level
   security model, operational and economic considerations, a governance
   concept (Pantheon), and an incremental migration approach.  UZPIF is
   intended to be read alongside companion work describing the Universal
   Zero-Port Transport Protocol (UZP; [UZP]) and TLS-UZP ([TLS-DPA]).

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 10 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Fisher                    Expires 10 July 2026                  [Page 1]

Internet-Draft                    UZPIF                     January 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.

Table of Contents

   1.  Scope and Status  . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Executive Summary . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Why Now?  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  What's New Versus Yet Another VPN?  . . . . . . . . . . .   4
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Core Architecture . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  High-Level Flow: EP to RN to EP . . . . . . . . . . . . .   6
     5.2.  Pantheon Grant Verification . . . . . . . . . . . . . . .   6
     5.3.  Flow Stitching by the RN  . . . . . . . . . . . . . . . .   6
     5.4.  Multi-RN Stitching for High-Assurance Tenants . . . . . .   7
   6.  Pantheon: Identity and Governance Model . . . . . . . . . . .   7
     6.1.  Identity Model  . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Certificate Format  . . . . . . . . . . . . . . . . . . .   8
     6.3.  Grant Structure . . . . . . . . . . . . . . . . . . . . .   8
     6.4.  Attestation Model . . . . . . . . . . . . . . . . . . . .   8
     6.5.  Caching Rules . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Benefits and Trade-offs . . . . . . . . . . . . . . . . . . .   9
   8.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Economics . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   10. Migration Plan for Organisations  . . . . . . . . . . . . . .  11
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     13.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Appendix A.  Appendix A: Technical Specification (Excerpt)  . . .  13
     A.1.  Abstract  . . . . . . . . . . . . . . . . . . . . . . . .  14
     A.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .  14
     A.3.  Architectural Overview  . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Scope and Status

   This document is an Internet-Draft and represents work in progress.
   It is published to enable structured technical review,
   interoperability discussion, and disciplined specification
   development around the Universal Zero-Port Interconnect Framework
   (UZPIF).




Fisher                    Expires 10 July 2026                  [Page 2]

Internet-Draft                    UZPIF                     January 2026


   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.

   It is not a universal replacement, is not mandated outside its target
   environment, and is designed for experimentation and profile-driven
   deployments.

   During conversion from internal research documents into IETF XML,
   care has been taken to:

   *  preserve a clear distinction between normative and informative
      content;

   *  use requirement language (e.g., "MUST", "SHOULD", "MAY") only
      where protocol behaviour is intentionally specified;

   *  avoid any implication of registry finalisation, mandatory
      implementation, or standard-track status; and

   *  maintain intellectual-property neutrality, with no implied patent
      grants or licensing commitments beyond the IETF Trust copyright
      licence applicable to Internet-Draft text.

   Ongoing research, implementation, performance validation, and real-
   world pilot work remain outside the scope of this Internet-Draft text
   and may be pursued separately.

2.  Executive Summary

   The Internet still commonly exposes services via publicly reachable
   transport ports, a legacy design choice that enables scanning and
   unsolicited connection attempts at global scale.  Operationally, this
   contributes to exposure for denial-of-service attacks, credential
   attacks, and lateral movement within networks.

   UZPIF (the framework) and UZP ([UZP]) (its transport protocol) remove
   the concept of exposed ports at endpoints.  Both endpoints initiate
   outbound, identity-anchored sessions to a Rendezvous Node (RN), which
   only stitches traffic when identity, context, and declared purpose
   align under policy issued by Pantheon, the identity and policy plane.

   The intent is a model where nothing is discoverable unless explicitly
   permitted by policy and exposed through the rendezvous fabric, and
   where application traffic is end-to-end authenticated and encrypted.
   UZP ([UZP]) is designed to support performance properties such as:




Fisher                    Expires 10 July 2026                  [Page 3]

Internet-Draft                    UZPIF                     January 2026


   *  block-level reliability,

   *  selective retransmission, and

   *  deterministic pacing.

   Legacy applications (e.g., HTTP(S), remote desktop, file sharing, and
   real-time media) are intended to continue to operate without
   modification via a Host Identity Layer (HIL) that maps traditional
   application expectations onto identity-centric sessions.

   UZPIF is intended to be evolutionary rather than revolutionary.  It
   deliberately builds on transport, security, and identity work
   embodied in QUIC [RFC9000], TLS 1.3 [RFC8446], and the Host Identity
   Protocol [RFC7401], while aligning with modern zero-trust guidance
   (e.g., NIST SP 800-207 [NIST-SP800-207]) and post-quantum
   cryptography standardisation efforts (e.g., the NIST PQC project
   [NIST-PQC]).

3.  Introduction

   This document provides an architectural overview of UZPIF and
   motivates why an identity-first, rendezvous-based model that avoids
   publicly reachable listeners may be desirable.

3.1.  Why Now?

   *  Investment in perimeter defences (e.g., DDoS mitigation and
      application firewalls) can yield diminishing returns as attackers
      automate scanning and exploit discovery at Internet scale.

   *  Zero Trust Network Access (ZTNA) and SASE deployments indicate
      demand for identity-first networking, yet many approaches still
      expose TCP/UDP ingress and rely on perimeter constructs.
      [NIST-SP800-207]

   *  Post-quantum cryptography efforts provide a path to identity-first
      transport without prohibitive performance regression as key
      encapsulation and signature schemes mature.  [NIST-PQC]

3.2.  What's New Versus Yet Another VPN?

   Conventional VPNs and overlay networks typically retain the
   assumption that services listen on IP:port tuples, even if those
   ports are only reachable within a private address space or through a
   gateway.  QUIC [RFC9000], TLS 1.3 [RFC8446], HIP [RFC7401], and
   systems such as Tor [Tor] demonstrate that identity, encryption, and
   rendezvous can be decoupled from raw addressing semantics, but they



Fisher                    Expires 10 July 2026                  [Page 4]

Internet-Draft                    UZPIF                     January 2026


   stop short of removing listening ports entirely.

   *  *No listeners* at endpoints.

   *  *Identity-as-address* via identities (e.g., canonical and
      ephemeral identities) rather than IP:port.

   *  *Block-level reliability* with selective retransmission
      (transport-level design goal).

   *  *Pantheon policy plane* encoding purpose, context, and validity
      into every session.

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

   This Internet-Draft is primarily architectural; requirement language
   is used sparingly and only where behaviour is intentionally
   specified.

   EP  Endpoint.  A host or service that participates in UZPIF by
      initiating outbound sessions.

   RN  Rendezvous Node.  A mediator that accepts outbound sessions and
      stitches permitted flows.

   Pantheon  An identity, attestation, and policy plane that issues
      credentials and session grants.

   HIL  Host Identity Layer.  A compatibility layer intended to support
      legacy applications over identity-centric sessions.

   CID  Canonical Identity.  A long-term cryptographic identity used to
      identify an EP (or a delegated sub-identity).

   EID  Ephemeral Identity.  A short-lived identity used for sessions,
      derived or issued under policy.

   ZPIT  Zero-Port Interconnect Tunnel.  An end-to-end encrypted tunnel
      stitched via one or more RNs.

5.  Core Architecture




Fisher                    Expires 10 July 2026                  [Page 5]

Internet-Draft                    UZPIF                     January 2026


5.1.  High-Level Flow: EP to RN to EP

   In UZPIF, both peers initiate outbound sessions towards an RN.  After
   policy evaluation and authorisation, the RN stitches the two sessions
   into a tunnel (ZPIT) that carries end-to-end protected application
   data.

   EP A (Initiator)        RN        EP B (Responder)
       |---- outbound ----->|              |
       |                    |<---- outbound|
       |<==== end-to-end encrypted ZPIT (stitched via RN) ====>|

    Figure 1: High-level communication pattern (outbound-only sessions)

   This figure shows both endpoints initiating outbound sessions to the
   RN, which stitches them into a single ZPIT.

5.2.  Pantheon Grant Verification

   Prior to stitching, an EP is expected to obtain a signed
   authorisation ("Grant") from Pantheon.  Grants bind identity to
   purpose and validity constraints, enabling RNs to make consistent
   policy decisions.

   EP                      Pantheon
    |------ Grant Request ------->|
    |<------ Signed Grant --------|
    |
    |---- Grant + CID/EID ----> RN

                 Figure 2: Grant request and issuance flow

   This figure illustrates the basic grant request and issuance exchange
   between an EP and Pantheon.

5.3.  Flow Stitching by the RN

   The RN establishes a stitched tunnel only if both peers present
   acceptable identities and authorisations.  The RN is assumed to be
   able to drop, delay, or reorder packets, but is not expected to learn
   end-to-end protected application plaintext.










Fisher                    Expires 10 July 2026                  [Page 6]

Internet-Draft                    UZPIF                     January 2026


   EP A                RN                 EP B
    |-- Join Request -->|                  |
    |<-- Stitch OK -----|                  |
    |                   |<-- Join Request--|
    |                   |-- Stitch OK ---->|
    |
    |<====== end-to-end encrypted ZPIT (SessionID-bound) ==========>|

                  Figure 3: Join and stitch establishment

   This figure shows the RN joining two authorised sessions into a
   stitched tunnel without learning plaintext.

5.4.  Multi-RN Stitching for High-Assurance Tenants

   UZPIF can be extended to multi-hop stitching, for example where a
   tenant requires multiple independently operated RNs and attestation
   chains.  End-to-end protection is expected to remain between
   endpoints.

   EP A -> RN1 -> RN2 -> EP B

   EP A <======== end-to-end AEAD protected traffic ========> EP B

        Figure 4: Multi-hop stitching with end-to-end authenticated
                                 encryption

   This figure depicts a multi-hop RN chain while end-to-end AEAD
   protection remains between endpoints.

6.  Pantheon: Identity and Governance Model

   Pantheon is described here as a global identity, attestation, and
   policy plane.  This section sketches the model at a conceptual level;
   future revisions may refine data structures and operational
   assumptions.

6.1.  Identity Model

   Pantheon issues (or authorises issuance of):

   *  long-term signing keys (forming CIDs);

   *  ephemeral session keys (forming EIDs); and

   *  delegated sub-identities for services or microprocesses.





Fisher                    Expires 10 July 2026                  [Page 7]

Internet-Draft                    UZPIF                     January 2026


   This identity approach is conceptually aligned with HIP's separation
   of endpoint identities from locators [RFC7401], but elevated to a
   policy plane.

6.2.  Certificate Format

   Pantheon Certificates (PCerts) may include the following conceptual
   elements:

   *  a CID and public signing key (and optionally a post-quantum key
      encapsulation key);

   *  purpose tags (e.g., service, role, tenant);

   *  validity bounds (time or epoch); and

   *  optional attestation claims (e.g., hardware trust or enclave
      measurement).

6.3.  Grant Structure

   A Grant is described as a signed assertion binding:

   *  the CID/EID of the requester;

   *  the requested peer identity;

   *  purpose and action;

   *  a time window and replay nonce; and

   *  an authorised quality-of-service (QoS) class.

6.4.  Attestation Model

   RNs and endpoints may publish attestations such as:

   *  hardware and software measurements;

   *  configuration hashes; and

   *  policy compliance data.

   Pantheon is expected to store these in transparency logs, mirroring
   transparency and verifiability goals in broader zero-trust guidance.
   [NIST-SP800-207]





Fisher                    Expires 10 July 2026                  [Page 8]

Internet-Draft                    UZPIF                     January 2026


6.5.  Caching Rules

   Endpoints may cache:

   *  PCerts for 24 hours;

   *  Grants for the shorter of their validity window or session
      lifetime; and

   *  attestation proofs for the duration of RN handshake paths.

7.  Benefits and Trade-offs

   UZPIF and UZP ([UZP]) intentionally reuse established transport and
   cryptographic primitives, but change where and how they are bound to
   identity, policy, and reachability.  In particular, QUIC [RFC9000]
   and TLS 1.3 [RFC8446] demonstrate encrypted transports with modern
   handshake properties, while UZPIF shifts the reachability model away
   from listening endpoints.
































Fisher                    Expires 10 July 2026                  [Page 9]

Internet-Draft                    UZPIF                     January 2026


     +==============+=================+===============+==============+
     | Dimension    | UZPIF/UZP       | Traditional   | QUIC/TLS     |
     |              | ([UZP])         | TCP/TLS       |              |
     +==============+=================+===============+==============+
     | Exposure     | No open ports   | Open ports    | Open ports   |
     |              | (endpoints are  | and/or        | at network   |
     |              | not publicly    | proxies       | edge         |
     |              | listening)      |               |              |
     +--------------+-----------------+---------------+--------------+
     | Identity     | Mandatory       | Typically     | TLS-level    |
     |              | cryptographic   | TLS-level     | identity     |
     |              | identity        | identity only |              |
     +--------------+-----------------+---------------+--------------+
     | Reliability  | Block-level     | Segment-level | Stream-level |
     |              | (design goal)   |               |              |
     +--------------+-----------------+---------------+--------------+
     | RN trust     | Drop/delay only | N/A           | N/A          |
     |              | (no end-to-end  |               |              |
     |              | plaintext       |               |              |
     |              | visibility      |               |              |
     |              | expected)       |               |              |
     +--------------+-----------------+---------------+--------------+
     | Latency      | Deterministic   | Congestion    | Congestion   |
     | control      | pacing (design  | control       | control      |
     |              | goal)           | variants      | variants     |
     |              |                 | (e.g., Reno/  | (e.g., BBR/  |
     |              |                 | CUBIC)        | CUBIC)       |
     +--------------+-----------------+---------------+--------------+
     | Legacy       | Supported via   | Native        | Often        |
     | applications | HIL (intended)  |               | requires     |
     |              |                 |               | gateways or  |
     |              |                 |               | adaptation   |
     +--------------+-----------------+---------------+--------------+
     | Post-quantum | Designed for    | Inconsistent  | Emerging     |
     | readiness    | cryptographic   | deployment    |              |
     |              | agility         |               |              |
     +--------------+-----------------+---------------+--------------+

               Table 1: Comparison of transport architectures

8.  Threat Model

   This section sketches attacker classes and example controls.  It is
   not a complete security analysis and will evolve with implementation
   experience.

   *Attacker classes* include:




Fisher                    Expires 10 July 2026                 [Page 10]

Internet-Draft                    UZPIF                     January 2026


   *  Internet-wide scanners;

   *  botnets seeking command-and-control beacons;

   *  malicious RNs (assumed capable of drop/delay/reorder);

   *  insiders with credentials; and

   *  traffic analysts performing correlation.

   Existing rendezvous and overlay systems (e.g., Tor [Tor]) and NAT
   traversal mechanisms based on STUN [RFC5389] and TURN [RFC5766]
   demonstrate the power of indirection, but they still assume exposed
   or discoverable listeners somewhere in the path.  UZPIF's design
   intent is to remove those listeners from the endpoint security model.

   Example controls discussed for UZPIF include:

   *  end-to-end authenticated encryption (AEAD);

   *  RN and endpoint attestation;

   *  puzzles and identity-bound rate limits;

   *  multi-RN stitching for higher assurance; and

   *  post-quantum readiness and cryptographic agility (see [NIST-PQC]).

9.  Economics

   *  Capital expenditure reduction: reduced reliance on perimeter
      appliances and complex DMZ designs.

   *  Operational expenditure reduction: fewer ACL/NAT rule changes and
      less inbound exposure management.

   *  Risk reduction: reduced externally visible attack surface.

   *  Potential service models: governance and RN validation as managed
      components.

10.  Migration Plan for Organisations

   UZPIF is intended for incremental deployment alongside existing TCP/
   TLS and QUIC-based stacks [RFC8446] and [RFC9000].

   1.  *Deploy an RN:* Introduce an outbound-only rendezvous node.




Fisher                    Expires 10 July 2026                 [Page 11]

Internet-Draft                    UZPIF                     January 2026


   2.  *Deploy the HIL:* Install the Host Identity Layer on endpoints.

   3.  *Dual-stack operation:* Run UZP ([UZP]) alongside existing TCP/
       TLS.

   4.  *Cutover:* Migrate services gradually to zero-port operation.

11.  Security Considerations

   UZPIF's central security claim is that avoiding publicly reachable
   listeners at endpoints reduces exposure to scanning and unsolicited
   ingress.  However, the framework introduces reliance on identity,
   authorisation, and policy evaluation components (e.g., Pantheon and
   RNs) whose compromise or misconfiguration could impact availability
   and authorisation correctness.

   The threat model in Section 8 discusses attacker classes and
   candidate controls.  Future revisions of this document (and the
   companion UZP ([UZP]) and TLS-UZP ([TLS-DPA]) documents) are expected
   to provide a more systematic analysis, including key management,
   revocation, attestation trust, and traffic analysis resistance.

12.  IANA Considerations

   This document has no IANA actions.

   UZPIF is an architectural framework and does not define protocol
   parameters requiring registries.

13.  References

13.1.  Normative References

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

13.2.  Informative References

   [NIST-PQC] National Institute of Standards and Technology, "NIST
              Post-Quantum Cryptography Standardization Project", 2022,
              <https://csrc.nist.gov/Projects/post-quantum-
              cryptography>.



Fisher                    Expires 10 July 2026                 [Page 12]

Internet-Draft                    UZPIF                     January 2026


   [NIST-SP800-207]
              Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
              "Zero Trust Architecture", NIST SP 800-207, 2019,
              <https://doi.org/10.6028/NIST.SP.800-207>.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              DOI 10.17487/RFC5389, October 2008,
              <https://www.rfc-editor.org/info/rfc5389>.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766,
              DOI 10.17487/RFC5766, April 2010,
              <https://www.rfc-editor.org/info/rfc5766>.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <https://www.rfc-editor.org/info/rfc7401>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

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

   [Tor]      Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
              Second-Generation Onion Router", 2004, <https://www.usenix
              .org/legacy/publications/library/proceedings/sec04/tech/
              full_papers/dingledine/dingledine.pdf>.

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

Appendix A.  Appendix A: Technical Specification (Excerpt)




Fisher                    Expires 10 July 2026                 [Page 13]

Internet-Draft                    UZPIF                     January 2026


A.1.  Abstract

   UZP ([UZP]) defines an identity-addressed, encrypted-by-default
   transport protocol for zero-port networking.  Endpoints do not listen
   on IP/port tuples; both create outbound sessions to an RN.

A.2.  Terminology

   *  EP - endpoint.

   *  RN - rendezvous node.

   *  Pantheon - identity/policy authority.

   *  HIL - Host Identity Layer.

   *  CID - canonical identity.

   *  EID - ephemeral identity.

   *  ZPIT - stitched tunnel.

   *  Block - reliability unit.

   *  Frame - payload unit.

A.3.  Architectural Overview

   1.  EP opens a control channel to an RN.

   2.  EP authenticates with Pantheon.

   3.  EP requests a Join for a peer CID.

   4.  RN validates authorisation and stitches a ZPIT.

   5.  Data flows with deterministic pacing (transport design goal).

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 10 July 2026                 [Page 14]
