The Universal Zero-Port Interconnect Framework (UZPIF): An Identity-Centric Architecture for Post-Port Networking

3.1. Motivation and Deployment Context

• 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. Relationship to VPN-Based Approaches

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 generally retain listener-based service reachability.¶

• No listeners at endpoints.¶

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

• Companion transport profiles define session and transport behaviour rather than inheriting a VPN tunnel abstraction.¶

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

5.1. Canonical Serialisation and Signature Coverage

Producers and verifiers MUST use the JSON Canonicalization Scheme (JCS) defined in [RFC8785] over UTF-8 JSON text.¶

Object production and verification use two exact canonical preimages. First, the producer derives "object_id" from the JCS serialisation of {"body": body, "envelope": envelope_without_object_id}, where envelope_without_object_id is the final envelope with only the "object_id" member omitted. Second, after inserting the derived "object_id", the canonical signature input is exactly the UTF-8 octet string of the JCS serialisation of {"body": body, "envelope": envelope}. The top-level "signatures" member, any detached-signature container, and any transport wrapper are outside both canonical preimages.¶

The "object_id" value MUST be formatted as "urn:uzpif:obj:v1:sha256:<lowercase-hex>", where the digest is the SHA-256 hash of the object-id preimage described above. Verifiers MUST recompute and compare "object_id" before evaluating signatures. Adding, removing, or reordering signatures does not change "object_id". Any change to envelope or body content, including extensions, validity bounds, policy references, or sequence metadata, MUST produce a different "object_id".¶

Each accepted signature MUST cover the exact canonical signature input bytes and nothing else. Suite-interoperable signatures MUST NOT be computed over pretty-printed JSON, partially selected members, alternate canonicalisation schemes, XML renderings, CBOR transcodings, log wrappers, transport records, or presentation-layer containers.¶

If an object-specific schema admits optional defaults, producers MUST materialise the exact values to be signed before canonicalisation. Verifiers MUST recompute "object_id" and the signature input from the received values, not from locally inferred defaults or omitted aliases.¶

Non-finite numbers, duplicate member names, semantically equivalent but non-canonical encodings, or values that cannot be represented under [RFC8785] MUST cause rejection.¶

5.2. Envelope Members and Extensions

Every common signed artefact MUST include "version", "object_type", "object_id", "issuer_authority_id", "subject_id", "scope", "issued_at", "not_before", "not_after", "key_id", and at least one entry in "signatures". The "body" member MUST be a JSON object whose direct member set is closed by the declared "object_type": direct body members not defined for that object type, "extensions", or "critical_extensions" MUST cause rejection. "audience_id", "policy_id", "policy_version", "epoch", "sequence", "nonce", "prev_hash", and "log_ref" MUST be present when relevant to the object's semantics, replay model, or transparency linkage.¶

Authenticity alone is insufficient for reliance on a common signed artefact. A valid signature proves origin and integrity, but a relying party MUST also evaluate freshness, scope, supersession, audience binding where relevant, and policy eligibility before treating the artefact as current authority.¶

version

Identifies the envelope version so that parsers and relying parties can apply the correct validation rules. Suite-interoperable objects defined by this revision MUST set "version" to 1.¶

object_type

Classifies the artefact using the exact case-sensitive token registered in Section 5.3. For suite-interoperable exchange, aliases or profile-specific synonyms are invalid.¶

object_id

Provides the stable identifier for the logical signed object. Producers MUST derive it according to Section 5.1. The same envelope and body content MUST always produce the same object_id, regardless of signature count. Producers MUST NOT reuse an object_id for different envelope or body content.¶

issuer_authority_id

Identifies the authority context under which the object is issued. It MUST map to signed authority metadata or other locally trusted issuer metadata.¶

subject_id

Identifies the principal, resource set, or relationship primarily affected by the artefact.¶

audience_id

Identifies the intended relying party or recipient when the artefact is not intended for universal consumption.¶

scope

Defines the operational scope of the artefact, such as authorised actions, resource sets, tenant boundaries, RN context, or revocation domain.¶

policy_id / policy_version

Name the policy basis and version under which the artefact was issued when policy tracking matters.¶

issued_at / not_before / not_after

Define issuance time and validity bounds. Artefacts outside their validity window MUST be rejected.¶

epoch / sequence

Provide ordering and conflict-detection context. If both are present, "epoch" takes precedence for semantic supersession and "sequence" orders objects within the same epoch or append-only stream. A higher "epoch" supersedes any lower "epoch" regardless of "sequence". If "epoch" is equal, a higher "sequence" is newer. A lower-epoch object MUST NOT supersede a higher-epoch object merely because its "sequence" is larger.¶

nonce

Carries replay-unique entropy for replay-sensitive artefacts such as Grants, PoR evidence, or session-bound authorisations. Re-usable objects that are not replay-sensitive MAY omit it.¶

key_id

Identifies the primary issuer key used for key discovery. It MUST match the first embedded signature entry after signature-array sorting and MUST match at least one embedded signature entry.¶

prev_hash / log_ref

Link the artefact into an append-only sequence or an external transparency record when auditability or append-only verification is required.¶

body members

The direct members of "body" are defined by the registered object-type profile. Unknown direct body members MUST cause rejection unless they are carried under "body.extensions".¶

body.extensions / body.critical_extensions

Object-specific extension values MUST appear only under "body.extensions", which, if present, MUST be a JSON object. "body.critical_extensions", if present, MUST be an array of unique extension keys sorted in ascending lexicographic order, and each listed key MUST exist in "body.extensions". Extension keys MUST be unique namespaced ASCII strings. Unknown extension values MAY be ignored only if they are not listed in "body.critical_extensions". Unknown critical extensions MUST cause rejection. Unknown members in "envelope", in an embedded signature entry, or as direct body members MUST cause rejection.¶

5.3. Suite-wide object_type Registry

The "object_type" member is a case-sensitive lowercase ASCII token. For suite-interoperable exchange, it MUST use one of the exact values registered in Table 1. Companion drafts define only the body profile and additional validation for their registered object types; they MUST NOT rename, alias, or reinterpret a registered value. New suite-wide object types require an explicit update to this registry.¶

Detached signatures are not permitted for any registered object type in this revision. A future suite revision MAY change that only by updating both this registry and Section 5.5.¶

5.4. Signature Algorithm Identifiers

The "alg" member is a case-sensitive ASCII token that identifies the exact signature verification procedure applied to the signature bytes in "value". Comparison is byte-for-byte. Aliases, case folding, numeric registry codes, OIDs, or implicit translation between naming schemes MUST NOT be used for suite-interoperable verification.¶

Trusted issuer metadata MUST bind each signing key identifier to one or more exact "alg" tokens. A verifier MUST accept a signature only when the signature entry's "alg" exactly matches a token bound to that key and local policy permits that algorithm for the declared object_type and time interval.¶

Composite or hybrid constructions, if used, MUST have their own exact "alg" token and verification procedure. They MUST NOT be represented by multiple "alg" values within one signature entry or by guessing from key type alone.¶

5.5. Signature Entries, Ordering, and Detached Form

The "signatures" array MUST contain at least one embedded signature. Each embedded signature entry MUST contain exactly "key_id", "alg", and "value". The embedded-signature member set is closed.¶

The array order is significant for serialised interchange and MUST be sorted in ascending lexicographic order by "key_id", then "alg", then "value". Duplicate entries with the same "key_id" and "alg", or duplicate complete entries, MUST cause rejection. A received array that is not already in this order MUST cause rejection. The envelope "key_id" MUST identify the first embedded signature entry after sorting.¶

The "alg" value is mandatory and case-sensitive, and it is processed according to Section 5.4. A signature entry whose "alg" is absent, unknown, unsupported, mismatched to the key metadata, or forbidden by local policy MUST be treated as invalid. If the remaining valid signatures do not satisfy the required signature set, the object MUST be rejected.¶

Embedded signatures are the only interoperable signature form for the registered object types in Table 1. For those object types, detached signatures MUST NOT be used and MUST NOT count toward policy satisfaction. If a future suite revision explicitly permits detached signatures for a specific object type, each detached signature MUST cover the same canonical signature input as the embedded form and MUST carry "object_id", "key_id", "alg", and "signed_object_hash", where "signed_object_hash" is "sha256:<lowercase-hex>" over the canonical signature input. If both embedded and detached signatures are present for such a future object type, every signature MUST verify against the same canonical signature input and object_id; any mismatch MUST cause rejection.¶

5.6. Validation Rules

Relying parties validating a common signed artefact MUST verify at least the following:¶

• the top-level member set, envelope member set, embedded-signature member set, and object-type-specific direct body member set are well-formed and contain no unknown members except under "body.extensions";¶

• the envelope version is supported for the declared object_type, and registered suite-wide object types defined by this revision use "version" equal to 1;¶

• the declared object_type is an exact registered suite-wide token when interoperable suite exchange is claimed;¶

• object_id recomputation succeeds;¶

• issuer_authority_id is locally trusted, validly delegated, or otherwise accepted under the applicable federation policy;¶

• the signing key identified by key_id is valid for the object_type and time interval, and the envelope key_id matches the first embedded signature entry after sorting;¶

• signature ordering and duplicate checks succeed, and every accepted signature verifies over the exact canonical signature input;¶

• each "alg" value exactly matches trusted key metadata and a locally permitted signature verification procedure for the declared object_type;¶

• the required signature set satisfies local policy, including any threshold or quorum rule;¶

• the current time falls within the declared validity interval;¶

• audience_id matches the relying party when the object is audience-bound;¶

• nonce uniqueness and epoch or sequence freshness checks succeed when replay resistance or state ordering matter;¶

• the artefact has not been superseded, rendered stale under local policy, or made policy-ineligible for the relevant scope and decision;¶

• prev_hash or log_ref, when present, are consistent with the relevant append-only or transparency evidence; and¶

• body.critical_extensions, when present, is unique, sorted, references only keys present in body.extensions, and contains no unsupported critical extension names.¶

Objects sharing the same issuer_authority_id, object_type, subject_id, scope, and applicable epoch or sequence state, but with incompatible canonical signature inputs, MUST be treated as conflicting artefacts and processed according to Section 10.7.¶

6.1. High-Level Flow: EP to RN to EP (Informative)

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) ====>|

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

The labels in this figure are illustrative only; this document does not define authoritative wire messages or handshake ordering for the transport steps shown.¶

6.2. Pantheon Grant Verification (Informative)

Prior to stitching, an EP is expected to obtain a signed authorisation ("Grant") from Pantheon, as defined in Section 10.3. Grants bind identity to purpose and validity constraints, enabling RNs to make consistent policy decisions. The authoritative Grant format and interoperability requirements are defined in Section 10.3 and Section 5.¶

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

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

The message labels are illustrative only. Authoritative Grant object semantics are defined in Section 10.3, and authoritative transport or handshake sequencing is defined in companion drafts.¶

6.3. Flow Stitching by the RN (Informative)

The RN establishes a stitched tunnel only if both peers present acceptable identities and authorisations. The exact transport, stitching, failover, and protected-traffic semantics are defined in the companion UZP and TLS-DPA drafts.¶

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

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

The message names and sequencing in this figure are illustrative only. Authoritative stitching, failover, and session semantics are defined in the companion UZP and TLS-DPA drafts.¶

6.4. Multi-RN Stitching for High-Assurance Tenants (Informative)

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

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

This subsection is a deployment sketch only and does not define authoritative multi-RN transport semantics.¶

7.1. HIL Requirements

A HIL used to bridge non-UZPIF-capable equipment:¶

• MUST be explicitly identified as a translation boundary;¶

• MUST terminate trust domains cleanly rather than representing legacy traffic as natively identity-bound;¶

• MUST enforce a narrow allow-listed protocol surface for the specific attached device or device class;¶

• MUST expose only the minimum necessary legacy port behaviour toward the attached equipment;¶

• MUST NOT elevate unauthenticated legacy assertions into Pantheon, Grant, or attestation truth without validation;¶

• SHOULD support one-way or brokered operation where possible rather than transparent raw pass-through; and¶

• MUST be auditable as a security-critical adapter.¶

When a HIL mediates an action into UZPIF, it SHOULD bind that action to auditable evidence including:¶

• the HIL identity;¶

• the attached device identity or slot or port identity;¶

• the translated protocol;¶

• the relevant time interval;¶

• the applicable policy or Grant; and¶

• an evidence-log reference or equivalent audit record.¶

7.2. Local Trust Boundary of HIL-Mediated Systems

A HIL secures the boundary between a UZPIF environment and a legacy device interface; it does not guarantee the integrity or confidentiality of the local physical segment behind that boundary. Deployments MUST treat the HIL-attached legacy domain as an independently exposed trust zone unless additional protections are present.¶

The HIL's protection applies to the mediated protocol boundary, not automatically to the local wire, serial line, bus, switch port, backplane, maintenance interface, or other attached legacy segment behind it. Compromise of that local segment may still permit false device input, spoofed local traffic, local firmware replacement, bus replay, serial-line manipulation, switch-port insertion, maintenance-port misuse, false sensor injection, or manipulation of translated events before they cross into the UZPIF-mediated side.¶

HIL containment therefore reduces and evidences legacy exposure, but it does not retroactively make the attached hardware domain cryptographically trustworthy. Where stronger assurance is required, deployments SHOULD consider physical controls, tamper detection, local attestation, secure serial or bus wrappers where available, and device-origin integrity checks where feasible.¶

7.3. HIL Software and Supply-Chain Integrity

A compromised HIL is especially dangerous because it sits at the boundary between legacy protocol behaviour and native identity-bound operation. A malicious or subverted HIL may spoof device status, fabricate translated events, widen the permitted legacy surface, create covert ingress, or launder insecure traffic into a deployment that appears to be operating under stronger trust assumptions.¶

HIL software manifests, configurations, policy bundles, and updates SHOULD be signed and auditable. No HIL software, configuration, or policy change SHALL become authoritative unless its manifest, version, signer set, scope, and policy eligibility validate successfully under the deployment's normal trust model.¶

HIL update, provisioning, and recovery channels MUST NOT become hidden sovereign authority paths. Local administrative overrides, emergency maintenance paths, or vendor tooling MUST NOT silently bypass the same validation model claimed for ordinary operation. This is aligned with the ICSD ([ICSD]) principle that privileged update or override paths must be modelled so that invalid states are rejected rather than normalised.¶

7.4. Legacy Compatibility Classes

This document distinguishes three compatibility classes for legacy integration so that deployments can state clearly whether a device is fully mediated, tightly brokered, or merely forwarded.¶

Class A - Full Mediation

The HIL terminates the legacy protocol and exposes a modelled, policy-bound interface into UZPIF. This is the RECOMMENDED integration model.¶

Class B - Brokered Pass-Through

The HIL permits tightly scoped transport bridging for a specific session under explicit Grant, time, scope, and evidence rules. This MAY be used where full mediation is not feasible, but it provides weaker containment than Class A.¶

Class C - Direct Forwarding Compatibility Mode

The HIL forwards arbitrary port traffic. This mode is outside the recommended security model, SHOULD NOT be used except as a bounded migration exception, and MUST NOT be represented as equivalent to native UZPIF participation or to Class A or Class B mediation.¶

8.1. Bootstrap Model Clarification

Bootstrap MAY use multiple Bootstrap Seed Bundles, mirrored distribution paths, offline media, local ceremony, and DNS or similar mechanisms as transports for seed distribution. The transport used to deliver seed material does not itself create trust; trust begins only after the device validates a Bootstrap Seed Bundle under local bootstrap policy.¶

Bootstrap mechanisms MUST be replaceable across deployments and over time. Bootstrap mechanisms MUST NOT depend on a single distribution source. No single seed source SHALL be mandatory.¶

8.2. Bootstrap, Recovery, and Re-Enrolment

Bootstrap, recovery, factory reset, re-enrolment, and emergency rekeying are privileged trust transitions. A deployment that appears decentralised during steady-state operation but depends on a singular bootstrap or recovery path has introduced a hidden trust anchor and does not satisfy the intended UZPIF sovereignty model.¶

New-node bootstrap, client recovery after state loss, RN rejoin after corruption, initial HIL enrolment, and emergency rekeying after compromise MUST NOT require a singular globally mandatory authority or delivery path. These workflows MUST NOT depend solely on one website, one operator, one Recovery / Re-Enrolment Bundle, one vendor endpoint, or one golden administrative key as the only path to valid trust state.¶

Recovery workflows MUST fail closed on missing, unsigned, expired, conflicting, or policy-ineligible recovery material. Recovered trust state MUST remain independently verifiable through the signed artefacts, authority metadata, and transparency or quorum evidence defined below before it becomes authoritative.¶

This document defines a minimal baseline model for those privileged transitions. Baseline-conformant bootstrap or recovery support consists of validated Bootstrap Seed Bundle input, explicit first-contact admission through a Bootstrap Admission Object, explicit continuity-sensitive return through a Recovery / Re-Enrolment Bundle when prior state existed, and issuance of only bounded initial or recovered identity and Grant state under policy.¶

Factory reset and re-enrolment MUST be treated as privileged trust transitions rather than convenience workflows. A reset or re-enrolled endpoint, RN, or HIL MUST re-establish trust as a new or explicitly recovered principal under local policy, and previous trust state MUST NOT be silently reinstated absent verifiable recovery artefacts.¶

Profiles MAY use multiple Bootstrap Seed Bundles, mirrored distribution paths, offline recovery packages, out-of-band provisioning, or quorum-approved rekey procedures. However, no single bootstrap or recovery source SHALL be mandatory for global protocol validity. This aligns with the invariant-closed design discipline described in ICSD ([ICSD]), where privileged recovery transitions are modelled so that invalid or unauthorised recovery states are rejected rather than normalised.¶

8.3. Key Custody and Signing-Role Separation

Cryptographic separation of keys is not, by itself, sufficient if the same actor, machine, or operational role can exercise all practically decisive signing and administrative powers. A deployment that concentrates issuance, policy, revocation, software-release, routing, and trust-bundle control into one custody domain has recreated a hidden sovereign control point even if each function uses a distinct key.¶

Deployments SHOULD separate, where practical, at least some of the following roles:¶

• identity issuance;¶

• Grant or policy signing;¶

• revocation quorum participation;¶

• software release or patch manifest signing;¶

• RN operational administration; and¶

• transparency witnessing or equivalent append-only verification roles.¶

This document does not mandate one governance structure. It does define the architectural principle that concentrated custody of all such roles SHOULD be avoided when stronger separation is practical, especially for deployments claiming high assurance, multi-party accountability, or resistance to unilateral control.¶

Where small or local deployments combine roles, that concentration SHOULD be explicit, auditable, and bounded by stronger local controls such as threshold approval, independent logging, external witnessing, or stricter operational review. Combined-role operation MUST NOT be treated as evidence that organisational separation is unnecessary at broader deployment scale.¶

8.4. Client Sovereignty Model

In UZPIF, clients are the ultimate trust arbiters at the edge.¶

Clients MUST:¶

• validate RN transparency logs;¶

• verify Proof-of-Reachability (PoR) responses as defined by UZP ([UZP]); and¶

• independently determine trust decisions using local policy and cryptographic evidence.¶

8.5. RN Controller Properties

An RN Controller is the control-plane implementation used to operate one or more RNs. The following requirements apply to RN Controller designs.¶

RN Controllers MUST:¶

• be self-hostable without external approval;¶

• publish signed transparency logs;¶

• support cryptographic verifiability of routing behaviour; and¶

• allow client-side trust evaluation.¶

RN Controllers MUST NOT:¶

• enforce global revocation unilaterally;¶

• depend on a single upstream authority; and¶

• possess unilateral kill-switch capability.¶

8.6. RN Transparency Log Format

Each RN MUST publish a transparency log as an append-only sequence of signed entries. Logs MUST be cryptographically verifiable, timestamped, and publicly retrievable. Transparency entries used for interoperable verification MUST use the common signed artefact envelope defined in Section 5 with "object_type" set to "rn-transparency-entry".¶

Each RN transparency log MUST contain signed records for:¶

• uptime attestations;¶

• session summaries at aggregated granularity; and¶

• error reports.¶

Signed policy decisions are OPTIONAL but RECOMMENDED and SHOULD be published when policy constraints allow.¶

Each log entry MUST include at least a monotonically increasing sequence number, a timestamp, an entry type, a payload digest, and an RN signature. In the common envelope, these properties are expressed via "object_type", "sequence", "issued_at", "prev_hash" or "log_ref", the object-specific body, and the embedded signature set. Log interfaces MUST allow third parties to retrieve entries and independently verify append-only integrity.¶

Evidence published for accountability SHOULD be sufficient for independent verification without unnecessarily exposing protected content, business-sensitive metadata, or broader activity graphs.¶

8.7. Proof of RN Misbehaviour

A Proof of RN Misbehaviour is a cryptographic evidence object that can be validated without a central judge. Misbehaviour proofs used for interoperable exchange MUST use the common signed artefact envelope defined in Section 5 with "object_type" set to "misbehaviour-proof".¶

Proofs MAY be constructed from one or more of the following evidence classes:¶

• signed evidence of misrouting;¶

• evidence that an RN failed to relay a required nonce during reachability procedures defined by UZP ([UZP]);¶

• log inconsistency proofs (for example, two different signed entries for the same sequence number) derived from the transparency material in Section 8.6; and¶

• signature replay detection evidence.¶

Clients MUST be able to validate misbehaviour proofs locally using published keys and log material. When proof validation succeeds, clients MAY blacklist the RN and SHOULD support policy controls for local blacklist retention and expiry.¶

UZPIF MUST NOT require a token-slashing mechanism or any central adjudication entity for RN accountability. Exclusion decisions are evidence-based and locally enforceable.¶

10.1. Identity Model

Pantheon authorities bind identity, policy, and trust metadata to keys or selectors accepted under policy.¶

Deployments MAY use locally generated or externally attested keys if policy allows; Pantheon authorities validate or certify those bindings rather than being required to generate the underlying private keys.¶

In the suite baseline, Pantheon authorities issue credentials, Grants, and delegations over accepted bindings rather than being required to generate or custody the underlying private keys.¶

Pantheon commonly binds or delegates the following identity-bearing material:¶

• long-term public signing keys bound to CIDs;¶

• ephemeral session keys or ephemeral public keys bound to EIDs under policy; and¶

• delegated sub-identities, selectors, or delegated credentials for services or microprocesses.¶

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

10.2. Certificate Format

Pantheon Certificates (PCerts) used for interoperable federation SHOULD include at least the following elements:¶

• an issuer authority identifier;¶

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

A PCert binds identity, scope, and trust metadata to an asserted public key. It does not by itself state how the corresponding private key was generated or who holds custody of it unless explicit attestation claims in the object-specific body say so.¶

Profiles MAY extend PCerts with additional fields, but interoperable federation requires enough issuer, subject, and validity information for cross-authority validation under Section 10.6.¶

For interoperable exchange, a PCert MUST use the common signed artefact envelope with "object_type" set to "pcert". The certificate-specific fields listed above populate the object-specific body and MUST NOT redefine envelope semantics.¶

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

For interoperable exchange across the suite, a Grant MUST be represented as a signed artefact with "object_type" set to "grant", using the envelope defined in Section 5.¶

This section is the canonical suite-level Grant definition for the architecture described in UZPIF. Companion drafts such as UZP, TLS-DPA, and outbound indexing may add object-specific fields or application-specific constraints in the object-specific body, but they MUST preserve this baseline Grant semantics and the shared artefact envelope.¶

10.4. Authority Identifiers and Metadata

Each Pantheon authority participating in a federation MUST be identified by a stable authority_id. An authority_id MUST remain stable across ordinary signing-key rollover and MUST be unique within the relying party's trust context.¶

Each authority MUST publish signed authority metadata sufficient for relying parties and peer authorities to validate issued objects. At a minimum, the metadata MUST identify:¶

• the authority_id;¶

• one or more current signing keys, and optionally future or retiring keys for rollover;¶

• service endpoints used for issuing or retrieving Pantheon objects;¶

• a metadata validity interval;¶

• the supported object types (for example PCerts, Grants, delegations, revocations, or attestation artefacts); and¶

• an optional transparency-log endpoint.¶

Metadata MAY contain additional deployment-specific policy claims, but Pantheon federation MUST NOT depend on a single global metadata registry or a mandatory schema beyond the minimum semantics above.¶

10.5. Issuer Discovery

Issuer discovery is deliberately non-centralised. A relying party MAY discover an authority and its signed metadata through one or more of the following mechanisms:¶

• local trust bundles;¶

• signed referrals;¶

• cached authority metadata; and¶

• out-of-band provisioning.¶

No global registry, mandatory directory, or single discovery service is required for Pantheon federation. Deployments MAY combine discovery mechanisms and MAY continue to rely on cached metadata when fresh discovery is temporarily unavailable, subject to local expiry policy. An authority without discoverable or locally provisioned metadata MUST NOT be treated as an interoperable federation participant.¶

10.6. Cross-Authority Validation

A client, RN, or other relying service evaluating a PCert, Grant, revocation statement, delegation, or other signed Pantheon object MUST accept that object only if its issuer is:¶

• locally trusted;¶

• delegated from a locally trusted authority, with a delegation chain valid for the relevant object type and scope; or¶

• accepted under a profile-defined federation rule.¶

If none of these conditions holds, the object MUST be rejected. Validation MUST include signature verification, issuer metadata validity, object-type authorisation, scope, and time validity.¶

Acceptance of one object type from an authority does not automatically authorise acceptance of other object types unless the applicable delegation or federation profile explicitly permits it.¶

10.7. Conflict and Split-Brain Handling

Pantheon federation MUST distinguish between issuer misbehaviour and federation divergence. These cases are not equivalent and MUST NOT be processed using a single merge rule.¶

If the same authority issues conflicting signed objects for the same epoch and scope, relying parties MUST treat the condition as evidence of authority misbehaviour. The conflicting objects SHOULD be retained as auditable evidence and MAY trigger local distrust, quarantine, or incident-response policy.¶

If different authorities publish conflicting signed views for the same subject, scope, or revocation state, relying parties MUST treat the condition as federation divergence. Such conflicts MUST NOT be auto-merged or silently normalised. Resolution MUST be performed by local policy, an explicit federation profile, or quorum rules agreed by the deployment.¶

Until resolved, implementations SHOULD fail closed for authorisation-expanding decisions and SHOULD surface the divergence to operators or relying services with enough issuer metadata to support audit and review.¶

10.8. Attestation Model

RNs and endpoints may publish attestations such as:¶

• hardware and software measurements;¶

• configuration hashes; and¶

• policy compliance data.¶

Attestation artefacts SHOULD be published in transparency logs retrievable by relying parties. Storage and serving MAY be provided by Pantheon services, RN Controllers, or both, mirroring transparency and verifiability goals in broader zero-trust guidance. [NIST-SP800-207]¶

10.9. Caching Rules

The following caching guidance is illustrative deployment guidance rather than a protocol-level interoperability requirement. Deployment profiles MAY tighten or relax these values according to their revocation, freshness, and transparency policies.¶

Authenticity alone is insufficient for continued reliance on cached authority. Before cached metadata, PCerts, Grants, or attestation material are used for security-relevant decisions, implementations SHOULD evaluate freshness, scope, sequence or epoch where applicable, and current policy eligibility under local stale-state rules. Authorisation-expanding decisions SHOULD require revalidation once a locally permitted stale window has been exceeded or when superseding state may exist.¶

Endpoints may cache:¶

• authority metadata for the shorter of its stated validity interval or a locally configured cache cap;¶

• PCerts for a locally configured interval appropriate to the deployment's revocation and freshness model (for example, up to 24 hours in low-churn environments);¶

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

• attestation proofs for the duration of RN handshake paths.¶

15.1. Transition of Network Security Roles

UZPIF shifts primary access control from network-coordinate filtering toward cryptographic identity, Grants, and invariant-bound policy enforcement. Network address and open-port exposure therefore cease to be the primary admission model in a native UZPIF deployment.¶

Traditional firewalls, DPI systems, and other middleboxes MAY remain useful for containment, telemetry, egress control, QoS enforcement, volumetric denial-of-service handling, forensic monitoring, HIL containment, regulatory inspection domains, and non-UZPIF legacy enclaves. However, they MUST NOT be treated as authoritative truth sources for identity or policy validity.¶

UZPIF does not assume that packet visibility implies authority. Where middleboxes remain deployed, they operate as bounded policy, containment, or observability components rather than as trust anchors that define whether an identity or Grant is valid.¶

15.2. Compliance, Observability, and Intercept Boundaries

Some deployments will require explicit policy enforcement, enterprise inspection, regulated access, or other observability controls. This document does not define a universal lawful-intercept or hidden inspection authority for UZPIF.¶

Where compliance, monitoring, mediation, or inspection components are deployed, they MUST remain explicit, bounded, and cryptographically distinguishable from protocol truth. The existence of such a component MUST NOT silently redefine endpoint identity, Pantheon authority, Grant validity, revocation state, or other authorisation-relevant truth in the UZPIF suite.¶

A compliance or inspection function MAY enforce local policy, provide observability, or participate in a regulated deployment boundary, but it MUST be treated as a deployment-specific control surface rather than as implicit sovereign protocol authority. Operator or institutional pressure to insert monitoring MUST NOT be satisfied by silently converting middleboxes, RNs, HILs, or auxiliary services into hidden trust anchors.¶

15.3. Identity-Aware Observability Shift

Network-address and port-oriented monitoring may lose significant explanatory power in UZPIF environments. Legacy network-centric visibility therefore becomes incomplete rather than useless: defenders may see less value in source or destination address patterns, open-port exposure, unsolicited inbound attempts, protocol signatures, or packet-shape heuristics than in conventional port-based environments.¶

This does not imply that UZPIF blinds defenders. It does mean that security analytics SHOULD rely increasingly on identity-aware telemetry, authority artefacts, Grant usage patterns, rendezvous behaviour, and policy-verification events rather than on legacy assumptions about open-port exposure. Otherwise, Shadow IT activity, stealthy misuse of valid outbound behaviour, unauthorised stitching requests, abuse of legitimate-looking identity objects, or compromised internal workloads acting within apparently allowed tunnel patterns may become harder to explain or detect.¶

Privacy-related properties in UZPIF MUST be separated. Reduced service discoverability means that publicly reachable listeners and routine unsolicited scanning lose some value. Encrypted content protection means that authorised endpoints can protect payloads and application content from intermediaries. Traffic-pattern privacy concerns whether observers can still infer communication existence, counterpart relationships, cadence, timing, or operational significance from metadata. Improvement in one of these properties MUST NOT be represented as automatically delivering the other two.¶

Effective deployment profiles SHOULD expose auditable telemetry such as Grant issuance and usage logs, RN selection patterns, failed stitching attempts, revocation-consistency signals, identity or authority anomalies, HIL mediation events, downgrade or compatibility-mode activation, and unusual policy-bound session graphs. Such telemetry SHOULD remain explicit, policy-bound, and reviewable rather than being inferred indirectly from legacy packet visibility alone.¶

15.4. Time as a Trust Dependency

Time is a security-relevant input in the UZPIF suite. Grant expiry, revocation freshness, log checkpoints, replay defence, policy activation windows, and software or patch manifest validity all depend on time evaluation. Implementations MUST therefore treat local time and time-derived freshness decisions as part of the trusted security boundary rather than as a purely operational convenience.¶

Policy decisions that depend on time SHOULD tolerate bounded clock drift as defined by deployment policy or a stricter profile. However, no single unauthenticated time source SHALL become a mandatory truth anchor for continued protocol validity. Deployments SHOULD use independently checkable, redundant, or otherwise policy-vetted time inputs where time correctness materially affects authorisation or freshness decisions.¶

When time is uncertain, inconsistent, or outside locally permitted drift bounds, implementations SHOULD degrade safely rather than silently accepting stale or not-yet-valid authority. Safe degradation MAY include rejecting time-sensitive artefacts, requiring revalidation, narrowing replay windows, surfacing operator alarms, or falling back to more conservative local policy.¶

This document does not define a suite-wide time synchronisation protocol. It does define the security posture that incorrect or manipulated time MUST NOT silently widen authority, revive expired Grants, delay emergency revocation effect, or normalise ambiguous checkpoint ordering without explicit local policy.¶

15.5. Replay, Caching, and Stale Authority

Authenticity alone is insufficient for security-relevant artefacts in the UZPIF suite. Grants, revocation signals and threshold evidence as profiled by TLS-DPA ([TLS-DPA]), PoR artefacts as defined by UZP ([UZP]), Proofs of RN Misbehaviour (Section 8.7), transparency checkpoints and receipts as profiled by outbound indexing ([OUTBOUND-INDEXING]), and similar signed objects MUST also be evaluated for freshness, scope, sequence or epoch, audience where relevant, and current policy eligibility before they influence authorisation or trust decisions.¶

An old but well-signed artefact MUST NOT be accepted merely because its signature validates. Implementations MUST determine whether the artefact has expired, has been superseded by a newer eligible artefact, falls outside the current policy scope, or remains within any locally permitted stale window for the decision being made.¶

Profiles SHOULD define bounded stale windows for continued operation during outage or partition conditions. Within such a window, implementations MAY continue to rely on cached authority for narrowly scoped, non-expanding behaviour if local policy permits it. Outside that window, or when freshness cannot be established, systems SHOULD require revalidation before continuing security-relevant operation and SHOULD fail closed for authorisation-expanding decisions.¶

15.6. Downgrade and Compatibility-Mode Abuse

UZPIF deployments may support native operation, HIL-mediated operation, brokered compatibility modes, legacy transport fallback, optional transparency behaviour, or advisory revocation thresholds. These modes create downgrade risk if an attacker can force the system onto a weaker posture while preserving the appearance of normal operation.¶

Fallback and degraded modes MUST be explicit, observable, and policy-bound. An implementation MUST NOT silently downgrade from native identity-first operation to mediated, brokered, legacy-compatible, transparency-reduced, or revocation-weakened behaviour without an allowed policy rule and locally observable state indicating that the downgrade occurred.¶

Peers, operators, or relying services SHOULD be able to determine whether a session or decision is operating in native, mediated, brokered, or otherwise degraded mode. Degraded operation MUST NOT silently inherit the same trust posture, authority scope, or audit assumptions as native operation. Profiles SHOULD narrow permissions, reduce session lifetime, strengthen revalidation requirements, or require additional operator visibility when compatibility or degraded modes are active.¶

Suppressed transparency checks, unavailable revocation evidence, weaker identity binding rules, or temporary compatibility exceptions MUST be treated as explicit trust reductions rather than harmless operational details. If the required stronger mode cannot be established, implementations SHOULD fail closed for authorisation-expanding behaviour unless local policy explicitly permits the weaker mode for a bounded scope and duration.¶

15.7. Break-Glass and Emergency Override Discipline

Real-world deployments may require emergency action during outage, recovery, migration, or incident containment. However, a break-glass path that silently disables normal trust checks is itself a high-risk authority path.¶

Any emergency override MUST be explicit, narrowly scoped, time-bounded, auditable, and incapable of silently becoming normal steady-state policy. A break-glass decision MUST NOT be normalised as an invisible standing exception to identity validation, Grant evaluation, revocation processing, transparency expectations, or other authorisation-relevant checks in the UZPIF suite.¶

Deployment profiles SHOULD record the triggering reason, affected scope, approving authority, activation time, expiry condition, and review outcome for such overrides. Emergency operation SHOULD surface clear local state to operators and relying parties when the stronger normal posture has been reduced.¶

15.8. Metadata Leakage and Traffic Analysis

UZPIF can materially reduce direct service and endpoint discoverability without guaranteeing metadata indistinguishability. Removing publicly reachable listening ports does not, by itself, provide strong privacy or anonymity. Unscannable is not the same as unseen. Rendezvous, transparency, and indexing infrastructure MAY still expose valuable metadata such as which parties communicate, which RN or RN cluster they use, how often they communicate, when sessions occur, how long they persist, retry patterns, topology clusters, discovery behaviour, revocation bursts, patch or rollout waves, and whether bursts correlate with alarms, updates, or emergency operations.¶

Even where payload plaintext remains protected, this metadata can support correlation, surveillance, tenant mapping, operational fingerprinting, or coercive analysis. A Rendezvous Node or indexing service that is not a truth anchor may still become a surveillance anchor if deployments over-retain, over-expose, or casually centralise metadata visibility.¶

Reduced discoverability, encrypted content protection, and traffic-pattern privacy are separate design axes. UZPIF can reduce unsolicited inbound exposure and support protected payload transport while still leaving observable metadata patterns available to infrastructure operators or network observers. Observers such as carriers, backbone operators, ISPs, or state-level monitors may still infer communication existence, cadence, rendezvous relationships, and operational timing from outbound rendezvous patterns unless additional privacy-preserving measures are deployed. Claims about strong observation resistance or traffic-pattern privacy MUST therefore be bounded and profile-dependent.¶

Operators SHOULD minimise metadata retention, restrict unnecessary visibility, and avoid collecting or exposing finer-grained metadata than is needed for security, accountability, or operational continuity. Deployment profiles SHOULD define retention bounds, access controls, aggregation rules, and disclosure controls for security-relevant logs, receipts, checkpoints, and session records.¶

Privacy-sensitive profiles MAY use identifier rotation, cover traffic, padding, batching, aggregation, timing obfuscation, multi-RN distribution, traffic shaping, delayed publication, or metadata-minimising RN policy to reduce correlation risk where those measures are compatible with the deployment's accountability and performance goals. Removal of inbound ports alone MUST NOT be treated as sufficient support for broader privacy claims.¶

15.9. Rendezvous Concentration and Availability Pressure

UZPIF and its companion mechanisms introduce stateful verification paths, including handshake processing, PoR validation, Grant verification, transparency checking, authority discovery or resolution, repeated stitching attempts, and HIL-mediated translation work. These paths may improve exposure relative to openly listening services while still creating denial-of-service or state-exhaustion risk if attackers can force expensive pre-authorisation work at scale.¶

Removing inbound exposure from endpoints does not eliminate denial-of-service risk; it shifts strategic pressure toward rendezvous and control-plane infrastructure. UZPIF therefore redistributes attack surface away from broad endpoint exposure and toward smaller sets of highly defended coordination infrastructure. UZPIF-compliant deployments MUST therefore treat RN availability as a first-class design concern rather than as an operational afterthought.¶

RNs are likely focal points for volumetric, state-exhaustion, and coordination-disruption attacks. Endpoint hardening alone does not solve network-wide availability. Deployments SHOULD assume deliberate RN-targeted overload attempts and SHOULD use plurality, geographic dispersion, bounded-state processing, rate controls, admission pacing, queue isolation, and failure isolation where practical. The availability of RN infrastructure also depends partly on underlying transport and routing ecosystems that are outside the protocol's direct control, so protocol and deployment design SHOULD minimise the consequences of temporary RN overload, routing impairment, or RN loss.¶

Expensive cryptographic verification, policy evaluation, federation lookups, or translation work SHOULD occur as late as safely possible in the processing path. Stateless screening, bounded-prestate admission checks, puzzles, quotas, or other low-cost filters SHOULD be preferred where practical before allocating scarce state or invoking high-cost validation.¶

RNs, HILs, and related control-plane services SHOULD rate-limit, queue-bound, or otherwise constrain untrusted requests before high-cost cryptographic or policy evaluation where feasible. Implementations SHOULD separate basic survivability controls from richer verification paths so that overload of one validation function does not automatically collapse unrelated session handling or local containment.¶

Basic survivability SHOULD NOT depend on a single always-available validation bottleneck such as one authority-resolution path, one transparency endpoint, or one high-cost policy service. Deployment profiles SHOULD define bounded-failure behaviour, degraded but observable operation, and local overload policy so that exhaustion pressure does not silently widen authority or force unsafe fallback.¶