The Participant Relationship Protocol (PRP): A Relationship-Centric Network Architecture GJ LABS
gjalves@gjalves.com.br
General relationship identity network architecture continuity This document describes the architecture of the Participant Relationship Protocol (PRP). PRP treats a relationship, rather than an address, route, transport connection, or identity alone, as the primary persistent context in which communication is authorized and continuity is evaluated. It separates relationships from the replaceable identities, sessions, trajectories, routes, paths, adjacencies, transports, and carriers that realize communication. PRP is independent of IP and of any other particular network-layer protocol. IP-based and non-IP carriers are optional realizations of the same relationship-centric architecture. The document defines terminology, architectural invariants, layering boundaries, security and privacy requirements, and criteria for evaluating relationship-centric protocol designs. It intentionally does not define a wire format, cryptographic suite, routing algorithm, carrier technology, deployment architecture, or IANA registry.
Introduction Internet communication is commonly described through addresses, routes, transport state, and application endpoints. Those objects are necessary realization mechanisms, but none of them alone expresses the durable authorization and continuity context between communicating participants. Addresses can change, paths can fail, transport sessions can be rekeyed, and carrier attachments can disappear while the reason and authorization for communication remain. PRP introduces the relationship as an explicit architectural object. A relationship records the rules under which participants recognize continuity, constrain identity, authorize communication, and replace realization mechanisms. Reachability can make communication technically possible, but it does not create or expand relationship authority. The foundational statement of PRP is:
Communication becomes possible because a relationship already exists.
This is an architectural ordering rather than a claim that packets can be exchanged before reachability exists. Paths, transports, and carriers move information, while routes select scoped forwarding outcomes. The relationship determines why an exchange belongs to a continuing authorized context and which realization mechanisms are acceptable for that context. This document is intended for protocol designers, implementers, researchers, and reviewers evaluating relationship-centric networking. It is published for informational purposes through the Independent Submission Stream and does not represent IETF consensus or specify an Internet Standard.
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 BCP 14 when, and only when, they appear in all capitals, as shown here.
Scope This document defines:
  • the relationship-centric communication model;
  • the distinction among relationships, identities, sessions, trajectories, routes, paths, adjacencies, transports, and carriers;
  • architectural layers and dependency boundaries;
  • continuity, authorization, and trust invariants;
  • security and privacy properties that every realization must address; and
  • requirements for claiming architectural conformance.
This document does not define packet or record layouts, cryptographic algorithms, numeric registries, session-establishment messages, routing or discovery algorithms, carrier bindings, application object models, deployment mechanisms, or administrative interfaces. Separate specifications may define those subjects provided they preserve the invariants in this document.
Foundational Model An address-centric communication sequence is often summarized as: route -> transport -> communication ]]> PRP instead places the relationship and its continuity rules before the realization mechanisms: continuity and authorization ^ | trajectory / route decisions / transport / carrier ]]> The relationship does not replace the lower-layer mechanisms. It supplies the persistent context against which their use, replacement, and failure are evaluated. A realization can therefore move between addresses, paths, sessions, or carriers without silently creating a new relationship, provided continuity is authenticated under relationship policy.
Terminology
Participant:
An entity capable of taking part in a relationship. A participant can represent a person, process, service, device, organization, or another entity type.
Relationship:
A persistent communication and authorization context among participants. Persistence is semantic and does not require a particular storage mechanism or uninterrupted availability.
Continuity:
The ability to determine, under relationship policy, whether an interaction belongs to the same relationship across time or a change of realization mechanism.
Identity:
A representation by which a participant or service can be distinguished within a defined scope. An identity constraint is relationship policy specifying which identity properties are required, permitted, or prohibited.
Trust material:
Information used to evaluate continuity, authorization, or identity constraints. Transport reachability alone is not trust material unless relationship policy explicitly makes it so.
Authorization boundary:
The set of actions permitted within a relationship. Authentication evaluates a principal or continuity claim; authorization determines what that claim is allowed to do.
Session:
Bounded cryptographic and operational state used to exchange information within a defined scope and generation. A relationship can use multiple sessions over its lifetime.
Route:
A scoped directional forwarding decision used in the realization of a trajectory. A route selects an eligible next path, adjacency, or local-delivery outcome. It is one decision leg of a trajectory and is not the trajectory itself.
Trajectory:
A validated directional realization of reachability for a relationship. A trajectory can span multiple route decisions and contains one or more paths.
Path:
An authenticated directional opportunity to carry traffic within a trajectory.
Routing identifier:
An operational selector for local route state, interpreted within an explicit routing scope and lifetime.
Adjacency:
A context in which participants can directly exchange units through a carrier under a defined local scope. Physical proximity or carrier enumeration can create an adjacency candidate but does not establish an authenticated relationship.
Transport:
The exchange semantics used to realize a relationship, including the applicable authentication, confidentiality, integrity, replay, ordering, and reliability properties.
Carrier:
A mechanism capable of moving protocol units between adjacent participants. Carrier technology and locators are realization details.
Service:
A capability exposed within an authorization context above core relationship semantics. Discovery, governance, evaluation, storage, and application protocols can be services without becoming prerequisites of every deployment.
Aggregation:
An optional relationship-realization arrangement in which an authorized participant coordinates or intermediates multiple independently authorized relationship contexts or trajectories. Aggregation does not merge relationships, identities, continuity state, or authorization boundaries. It is distinct from packet batching, data summarization, and group identity.
Aggregator:
A participant performing aggregation under explicitly delegated relationship authority. Acting as an aggregator grants no implicit authority over endpoint identity, relationship continuity, or application authorization.
Reference Classes A protocol realization can distinguish several non-substitutable reference classes:
  • A strong identifier is a self-certifying reference to one concrete entity.
  • A strong alias is an authenticated logical reference whose selected concrete members still prove their own strong identifiers.
  • A weak alias is a classification reference and is not a cryptographic identity.
  • A content identifier is an immutable commitment to finite content bytes and is not an entity identity.
A content identifier has no private key, cannot prove possession, and does not assert an owner, author, provider, or semantic meaning. Availability of matching bytes is a separate and revocable claim. Specific encodings and algorithms for these classes are outside this architecture.
Architectural Invariants
Relationship Primacy A conforming design MUST identify the relationship context whose communication it realizes. It MUST NOT define relationship continuity solely as continued possession of a locator, route, carrier attachment, or ephemeral session handle.
Independent Lifetimes Relationships, identities, sessions, trajectories, routes, paths, adjacencies, and carriers have distinct lifetimes. A conforming design MUST define transitions among them without silently equating one object with another.
  • A relationship can outlive a session, trajectory, route, path, or carrier.
  • A trajectory can be replaced and its route decisions can change without replacing the relationship.
  • A session can be rekeyed without changing participant identity.
  • An adjacency can exist without authorization to form a relationship.
  • Loss of a carrier does not by itself revoke a relationship.
Local Scope Operational selectors are local unless another authenticated scope is explicitly defined. Local selectors MUST NOT be interpreted as global addresses or identities. An intermediary can rewrite local forwarding selectors while preserving end-to-end relationship semantics.
Explicit Authority Every protocol decision affecting access to a relationship or service MUST derive from relationship policy or explicitly delegated authority. Reachability, routing, discovery results, or a successful cryptographic handshake MUST NOT silently expand authorization.
Replaceable Realization A conforming design SHOULD support replacement of a failed or obsolete realization mechanism without replacing the relationship when continuity can be authenticated. When continuity cannot be authenticated, the design MUST fail or establish a new relationship according to explicit policy. It MUST NOT silently reset replay, ordering, identity, or authorization state while claiming continuity.
No Mandatory Global Infrastructure A conforming protocol suite MUST permit two participants possessing sufficient local relationship information and a compatible carrier to communicate without consulting a mandatory global naming, routing, identity, governance, or ledger service. A profile can depend on external services, but that dependency is a property of the profile and not a universal architectural requirement.
Network-Layer Independence The PRP architecture MUST NOT require IPv4, IPv6, or any other particular network-layer protocol as a universal prerequisite. A conforming realization can operate over any compatible carrier capable of moving protocol units between adjacent participants. A profile MAY require IP or another network technology. That dependency is a property of the profile, not of PRP itself. When an IP-based profile is used, IP addresses and routing are scoped realization mechanisms and MUST NOT become participant identity, relationship continuity, or authorization.
Architectural Layers
  1. The relationship layer defines continuity, trust, authorization, and communication permissions.
  2. The routing layer selects and maintains trajectories and the scoped route decisions that realize a relationship.
  3. The transport layer supplies exchange semantics over those trajectories.
  4. The carrier layer moves units between adjacent participants.
Services operate above these concerns. A protocol can combine layers in one component, message, or cryptographic transcript, but it MUST retain their semantic boundaries. A function belongs to the architectural core only when every valid deployment requires it, it cannot be supplied as an optional service, and omitting it would invalidate the relationship-centric model.
Conceptual Operation This section is non-normative. It illustrates the distinction between a relationship and its realizations without prescribing messages or implementation components.
  1. Participants possess local policy and trust material sufficient to recognize or propose a relationship.
  2. A carrier supplies an adjacency candidate, eligible paths are authenticated, and scoped route decisions participate in a selected trajectory.
  3. A protocol profile authenticates the required principals and binds a session to the relationship context.
  4. Authorized services exchange information through that session.
  5. If a path, trajectory, carrier, or session fails, another realization can be established. The relationship continues only if its continuity rules are satisfied.
  6. Revocation of the relationship authorization terminates its authority independently of whether old trajectories, route decisions, or sessions remain technically usable.
This sequence does not require a globally resolvable participant name. A selected profile can require a self-certifying identity, a provisioned trust anchor, a pseudonymous continuity key, or another explicitly specified mechanism.
Illustrative Use Cases This section is non-normative. The examples illustrate consequences of the architecture and do not prescribe protocol mechanisms or deployment models.
Mobility across Realizations Two participants communicate while one moves between carrier attachments and receives different locators. Paths and transport state can be replaced, but the relationship need not be recreated. The replacement is accepted only when the selected profile authenticates continuity and preserves the relationship's authorization constraints.
Intermittent Communication Participants can retain a relationship while no valid trajectory, path, or compatible carrier is available. Later reachability supplies a new opportunity to communicate; it does not by itself restore authority. Communication resumes only after continuity is established under the relationship policy.
Scoped or Pseudonymous Participation A relationship can constrain a participant to a scoped or pseudonymous identity without requiring a globally resolvable name or civil identity. The scope, acceptable identity evidence, and authorized actions remain explicit properties of that relationship. The absence of a global name does not imply anonymity or prevent correlation.
Discovery, Routing, and Aggregation Discovery produces candidates or information used to realize a relationship. It does not establish identity, trust, continuity, or authorization unless a separate authenticated procedure explicitly says so. Routing constructs and maintains trajectories through scoped directional route decisions. A relationship can be direct or transit one or more forwarding participants. Transit does not grant an intermediary authority over endpoint identity or application authorization. Aggregation is an optional scaling and privacy mechanism. Direct relationships remain architecturally valid. An aggregation profile MUST specify what an aggregator learns, which statements it authenticates, and which decisions remain reserved to endpoints. It MUST preserve the independent relationship, identity, continuity, and authorization boundaries defined by this architecture.
Relationship to Existing Network Architectures PRP is independent of the Internet Protocol. It does not require IPv4, IPv6, or any other particular network-layer protocol. A PRP realization can operate over any compatible carrier capable of moving protocol units between adjacent participants. An IP-based profile can use IP addresses, routing, and transport protocols as optional realization mechanisms. IPv6 continues to provide packet delivery as described in when such a profile uses it. This does not make IP an architectural prerequisite, and possession of an IP address does not establish participant identity, relationship continuity, or authorization. Transport protocols already separate some connection state from a particular path. For example, QUIC supports connection migration . That continuity is transport-specific; PRP defines a relationship context that can outlive and authorize replacement of the complete transport session. Other architectures separate endpoint identity from routing location. The Host Identity Protocol introduces a host identity namespace, while the LISP architecture separates endpoint identifiers from routing locators. PRP does not replace those mechanisms. It distinguishes both identity and locator from the relationship that determines continuity and authorization, and a PRP profile can use such mechanisms as realizations. The architecture therefore does not claim that identity-locator separation, path migration, or authenticated sessions are new individually. Its contribution is the explicit relationship object and the invariants that prevent those replaceable mechanisms from becoming implicit sources of persistent authority.
Security Considerations Relationship primacy does not itself provide cryptographic security. Every protocol profile MUST specify authenticated principals and transcript scope, confidentiality and integrity properties, replay domains, authorization inputs, selector and generation scopes, key and state lifetimes, exhaustion and amplification bounds, downgrade protection, and failure behavior. A carrier-security claim does not imply end-to-end security. Adjacent authentication does not imply service authorization. A self-certifying identifier demonstrates control of key material but does not establish an external civil identity or authorize arbitrary services. Continuity creates valuable long-lived state and is therefore a target for fixation, rollback, replay, and confused-deputy attacks. A replacement realization MUST be bound to the exact relationship, participants, direction, generation, and authorization policy required by its profile. State from one scope MUST NOT be admitted into another merely because identifiers or byte lengths coincide. Unknown or malformed security-critical values MUST fail closed unless a specification defines a safe extension rule. Loss of continuity evidence MUST NOT be repaired by silently accepting reachability, a local handle, or unauthenticated forwarding state as equivalent authority. Persistent relationships can increase the impact of compromised trust material. Profiles must define revocation, recovery, key replacement, and the point at which continuity can no longer be safely claimed. Denial-of-service protections must bound retained state, verification work, retries, referrals, and fanout per authenticated authority.
Privacy Considerations Relationship-centric operation does not inherently provide anonymity, unlinkability, traffic-flow confidentiality, resistance to correlation, or availability. A stable relationship context can itself become a correlation surface even when routes, addresses, and session keys change. Profiles MUST state which relationship identifiers, participant references, timing signals, path changes, and service metadata are visible to carriers, intermediaries, discovery services, and peers. Operational selectors should have the narrowest practical scope and lifetime. Implementations should avoid exposing durable relationship state where an ephemeral correlation is sufficient. Padding, batching, multipath, private discovery, aliases, and cover traffic can reduce particular observations, but each requires separate analysis. No deployment should infer privacy properties merely from the absence of globally meaningful addresses or civil identities.
Operational Considerations Relationship, trajectory, route-decision, path, session, and carrier state should be observable as distinct objects so that operators do not mistake path availability for relationship authorization. Diagnostics should identify scope and generation while avoiding disclosure of long-lived trust material or globally correlatable identifiers. Implementations need explicit bounds for relationship state, candidate trajectories and paths, route decisions, concurrent sessions, retained replay information, and recovery attempts. Replacement should normally be make-before-break when the selected profiles can authenticate continuity, but an implementation must prefer loss of availability over an unauthorized continuity claim. Interoperability depends on protocol profiles that instantiate this architecture. Architectural conformance alone does not imply wire compatibility.
Extensibility and Evolution Extensions MUST preserve the invariants in this document. An extension that requires globally stable locators, equates routes with identity, or makes optional governance a universal prerequisite is not architecturally conforming. Protocol versions and profiles MUST define explicit selection and failure behavior. Negotiation MUST NOT silently weaken authenticated properties or reinterpret assigned values. Migration SHOULD preserve relationship continuity through an authenticated make-before-break procedure when both profiles permit it.
Architectural Conformance A design conforms to this architecture only if it:
  1. treats a relationship as the primary persistent communication and authorization context;
  2. defines continuity independently of any single trajectory, route, path, session, or carrier;
  3. keeps operational routing and carrier selectors distinct from identity;
  4. makes authorization an explicit relationship decision;
  5. permits direct communication without mandatory global governance;
  6. does not make IP or another particular network-layer protocol a universal prerequisite;
  7. states the scope and lifetime of identities, sessions, trajectories, routes, paths, and selectors; and
  8. does not claim security or privacy properties beyond those supplied by specified profiles.
Conformance to this architecture does not imply conformance to a particular wire protocol, discovery mechanism, routing protocol, carrier binding, or service profile.
IANA Considerations This document has no IANA actions.
Normative References Key words for use in RFCs to Indicate Requirement Levels Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words Informative References Host Identity Protocol Version 2 (HIPv2) Internet Protocol, Version 6 (IPv6) Specification QUIC: A UDP-Based Multiplexed and Secure Transport An Architectural Introduction to the Locator/ID Separation Protocol (LISP)
Acknowledgments The author thanks the contributors and implementers whose independent protocol work exposed the architectural distinctions documented here. Specific reviewers will be acknowledged in subsequent revisions.