QUIC Identity Protocol

Introduction QUIP defines a federation-native protocol that ensures:

Portable identity independent of domain providers
Verifiable server authenticity without reliance solely on certification authorities
Deterministic global state convergence
Cryptographic accountability for misbehavior

QUIP operates directly over QUIC and eliminates reliance on HTTP-based federation layers.

Minimal Working Example The following example demonstrates a complete QUIP flow:

Non-Goals QUIP does NOT guarantee:

Anonymity (use Tor or similar) — a design choice
Metadata confidentiality — connection patterns are observable
Resistance to global passive adversaries — traffic analysis remains possible
Byzantine consensus — deterministic merge is not Byzantine fault tolerant
Economic Sybil resistance — independent witness definition provides operational heuristic only
Witness collusion resistance — a federation with >=3 colluding witnesses can falsely attest violations; deployments must rely on legal/commercial incentives

Note on categorization: The items above mix design choices (anonymity, metadata confidentiality) with explicit security limitations (collusion resistance, Byzantine consensus). All are intentional non-goals of the protocol.

Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

NodeId: 32-byte Ed25519 public key (raw bytes)
Genesis NodeId: Root identity in a rotation chain; the oldest known NodeId
Attestation: Signed CBOR object binding identity claims
Primary attestation: Attestation binding a specific user@domain address to a NodeId
Vector clock: Map of issuer → counter, used for causality tracking
Gossip: Propagation mechanism for state updates
Violation receipt: Signed proof of protocol violation
Profile: Conformance level (Basic, Documents, Media)

Protocol States

State Definitions QUIP connections SHALL be in one of the following states:

INIT: Initial state before discovery. No messages sent.
DISCOVERING: Performing DNS discovery. MAY send DNS queries.
CONNECTING: Establishing QUIC connection. MAY send QUIC handshake.
HANDSHAKING: Exchanging QUIP handshake. Control stream active; no application streams.
SYNCING: Synchronizing gossip state. Accept gossip; MAY defer message delivery.
ACTIVE: Normal operation. All streams fully functional.
DEGRADED: Operating with reduced capabilities. Rate limits increased; new streams discouraged.
REVOKED: Identity or peer revoked. No messages accepted or sent.
CLOSED: Connection terminated. No further state transitions.

State Transitions The following transitions are normative:

From	To	Trigger	Required Action
INIT	DISCOVERING	Application requests connection	Perform DNS SRV/TXT lookup
DISCOVERING	CONNECTING	DNS resolution succeeds	Initiate QUIC handshake
CONNECTING	HANDSHAKING	QUIC connection established	Send QUIP handshake on stream 0
HANDSHAKING	SYNCING	Handshake complete, profiles compatible	Begin gossip sync on stream 1
HANDSHAKING	CLOSED	Profile mismatch or handshake error	Send error, close connection
SYNCING	ACTIVE	Initial sync complete	Normal operation begins
SYNCING	CLOSED	Sync timeout or unrecoverable error	Send error, close connection
ACTIVE	DEGRADED	Resource exhaustion or policy violation	Reduce functionality
ACTIVE	REVOKED	Receipt of valid revocation attesting this peer	Terminate all active streams
ACTIVE	CLOSED	Connection loss or explicit close	Clean up state
REVOKED	CLOSED	Any	Final cleanup
DEGRADED	ACTIVE	Resource recovery	Resume normal operation

State transitions not listed above are not permitted and MUST cause a connection error ( code 17: PROTOCOL_VIOLATION).

Protocol Invariants Implementations MUST enforce:

Determinism: All state transitions () MUST produce identical results across peers
Signature Coverage: All externally visible objects MUST be signed with domain separation ()
Identity Continuity: Identity MUST be traceable to a genesis NodeId through a verifiable rotation chain
Canonical Encoding: All serialized data MUST use QUIP-CBOR ()
No Duplicate Keys: CBOR maps MUST NOT contain duplicate keys
No Indefinite Lengths: Indefinite-length byte strings and text strings are PROHIBITED

Architecture Overview Layered model (bottom to top):

QUIC transport (TLS 1.3) — encryption, multiplexing, congestion control
Identity and attestation layer — NodeIds, bindings, trust models
Deterministic state machine — canonical CBOR, vector clocks, gossip
Profile layer — Basic / Documents / Media feature activation
Application layer — messaging, media, B2B, documents

Identity Model

NodeId Every user has a NodeId — an Ed25519 public key (32 bytes). The corresponding private key is never disclosed to any domain or third party. NodeIds are encoded as raw byte strings in CBOR.

Attestations All attestations are signed CBOR objects.

Subject Signature Computation The subject signs the following QUIP-CBOR array:

Issuer Signature Computation The issuer signs the following QUIP-CBOR array: The complete attestation on the wire is:

Key Rotation Signature computation: Rotation validation rules: Receivers MUST reject:

Cyclic chains (NodeId appears twice)
Duplicate NodeIds in the same chain
Chains with non-monotonic timestamps (timestamps must increase)
Multiple successors from the same NodeId unless the previous successor is revoked
Rotations where the old key is already revoked
Chains exceeding maximum depth of 32 (configurable)

Genesis Discovery The Genesis NodeId is the oldest known NodeId in a rotation chain. First message rule: If a receiver encounters a NodeId with no prior state, and the message is signed by a key that is not clearly the genesis, the sender MUST include the full rotation chain. Failure results in error KEY_ROTATION_CHAIN_MISSING ( code 15).

Identity Trust Modes The identity_trust_mode bitmask is defined as:

Bit	Name	Description
0	SIMPLE	Accept primary attestations from any domain
1	VERIFIED	Require attestations from certified providers ()
2-15	Reserved	Reserved for future use

Negotiation: The effective trust mode is the bitwise AND of local and remote modes. If the result has no bits set, the connection proceeds with the lowest common mode (SIMPLE) and MUST log a warning. Downgrade behavior: VERIFIED mode MUST NOT downgrade to SIMPLE without explicit operator configuration. Any downgrade MUST be logged.

Trust Model

Server Authentication Modes

Mode	Requirement	Use Case
COMPAT (default)	Web PKI + SHOULD use DANE if available	General deployment
STRICT (optional)	DNSSEC + DANE REQUIRED	High-security environments
LEGACY (deprecated)	Web PKI only	Legacy transition

Independent Witness Definition A witness domain qualifies as independent for violation receipt validation if ALL conditions hold:

Distinct DNSSEC-signed domain (, , )
Distinct TLSA record
Distinct /24 IPv4 or /48 IPv6 prefix

Additional weighting (SHOULD): Implementations SHOULD also consider distinct ASN (Autonomous System Number), distinct DNSSEC KSK (Key Signing Key), historical trust scoring based on past witness accuracy, and observed federation longevity (minimum 30 days active).

DNS Downgrade Protection After TLS handshake completion, the client MUST verify that the server's presented certificate and DANE TLSA record (if applicable) are consistent with the TXT capabilities advertisement from DNS. Inconsistencies MUST be logged and, in STRICT mode, cause connection termination.

Handshake Transcript Binding The QUIP handshake MUST be cryptographically bound to the QUIC TLS session using the TLS exporter interface , Section 7.5. Transcript canonicalization: The client and server handshake payloads are embedded as CBOR byte strings containing the exact transmitted bytes: ', h'' ] ]]> Sequence of operations:

TLS handshake completes (both peers have established session keys)
QUIP handshake bytes are transmitted on stream 0 (client first, then server)
Both peers buffer the exact bytes they send and receive (no re-encoding)
After both handshake messages have been exchanged, each peer computes:

Because both peers use the same TLS session and the same canonicalized handshake array, they derive identical binding values locally
The binding is used as a local consistency check: each peer can verify that the handshake parameters it is using are consistent with the binding it computed
No binding value is ever transmitted

Verified Mode Governance Governance and policy requirements for VERIFIED mode (trust anchor authorization, provider certification criteria, dispute resolution, and antitrust/competition safeguards) are deployment-specific and outside the scope of this document. Implementations in VERIFIED mode MUST rely on local policy to define acceptable trust anchors and certification authorities.

Verified Mode PKI

Trust Anchor Format Trust anchors are distributed as signed CBOR objects:

Trust Anchor Distribution Trust anchors are distributed via:

Hardcoded — Implementations MAY ship with a set of trusted roots
DNS-based — _quip._trust.root.domain TXT records containing anchor hashes
Transparency log — Optional certificate transparency-style log

Attestation Provider Certificate

Certificate Path Validation When receiving a provider certificate chain, peers MUST perform the following validation: Path building order:

Start from the end-entity (provider) certificate
Chain to issuer using issuer field (NodeId or anchor_id)
Continue until reaching a known trust anchor
Maximum chain depth: 8

Trust anchor matching: Trust anchors are identified by anchor_id string. Implementations MUST support exact string matching. Wildcard matching is NOT permitted. Signature validation: All signatures MUST use Ed25519 . Future versions may negotiate additional algorithms. Expiry precedence: Certificates with expires_at in the past MUST be rejected. Trust anchors with valid_until in the past SHOULD be rejected (grace window of 24 hours permitted for rollover). Rollover handling: Trust anchors SHOULD have overlapping validity windows during rollover. During overlap, either anchor is considered valid. After old anchor expires, it MUST NOT be accepted. Cross-signing: Cross-signed certificates are permitted if they chain to a trust anchor. Maximum chain depth applies to the merged path. Revocation check: Before accepting a certificate, check revocation status per . Revoked certificates MUST be rejected regardless of validity period.

Provider Revocation Freshness Peers MUST enforce freshness limits on provider revocation lists:

Condition	Behavior
Revocation list age < 24 hours	Normal operation
Revocation list age 24-72 hours	DEGRADED mode, log warning
Revocation list age > 72 hours	VERIFIED mode MUST fail closed; reject all VERIFIED-mode attestations

DNS Trust Anchor Bootstrapping DNS-distributed trust anchors are advisory until chained to an existing trusted anchor or implementation trust store. Implementations MUST validate the DNSSEC chain for any DNS-discovered anchor. The first anchor in a deployment MAY be installed out-of-band (e.g., via package management, configuration file, or hardcoding). Once an anchor is trusted, it may be used to validate subsequent anchor updates.

Transport

Connection Establishment QUIC connection with ALPN "quip". The first client-initiated bidirectional stream opened after QUIC connection establishment (stream ID 0) is designated the QUIP Control Stream. The second client-initiated bidirectional stream (stream ID 4) is designated the QUIP Gossip Stream.

Logical Role	Stream Type	Stream ID (Client)	Stream ID (Server)
Control stream	Client bidirectional	0	1
Gossip stream	Client bidirectional	4	5
Application streams	Client bidirectional	8, 12, ...	9, 13, ...

All control messages (errors, rate advisories) are sent as CBOR arrays on the Control Stream. Handshake sequencing: No application streams (streams other than the Control and Gossip streams) SHALL be processed until the QUIP handshake completes and transcript binding verification succeeds. The Control Stream and Gossip Stream MAY be used during handshake. Phase 0: DNS Discovery Query _quip._udp.domain.example SRV and TXT: Phase 1: QUIP Handshake (Control Stream) Client sends: Server responds with identical structure. Both peers compute active_profiles = local.profiles & remote.profiles. If zero, send error () and close.

Wire Format The CBOR object MUST be a single complete top-level item with no trailing bytes.

Stream Semantics

Logical Role	Direction	Reliability	Ordering
Control	Bidirectional	Reliable	Strict
Gossip	Bidirectional	Reliable	Strict
Application	Profile-dependent	Mixed	Mixed

Bootstrap Discovery Priority order:

DNS SRV + TXT (MUST)
QUIC Well-Known: ["WELL_KNOWN", "/peer"] on Control Stream (MUST)
Cached endpoints (SHOULD)
HTTPS fallback (OPTIONAL, DEPRECATED)

The full bootstrap handshake (GOSSIP_BOOTSTRAP exchange) is defined in .

Message Envelope

Envelope Structure The signed payload is a CBOR array, not a map: The wire representation is:

Signature Computation (Domain Separation) All signatures in QUIP use standard Ed25519 without pre-hashing, with explicit domain separation strings prepended to the message.

Object Type	Domain Separator (UTF-8)
Message envelope	`"QUIP-MESSAGE-V1"`
Gossip message	`"QUIP-GOSSIP-V1"`
Key rotation	`"QUIP-ROTATION-V1"`
Attestation (subject)	`"QUIP-ATTESTATION-SUBJECT-V1"`
Attestation (issuer)	`"QUIP-ATTESTATION-ISSUER-V1"`
Violation receipt	`"QUIP-VIOLATION-V1"`

Error Messages Errors are sent as CBOR arrays on the Control Stream: Where error_code is a uint (), message_id is 32 bytes (may be null for handshake errors), and error_text is a human-readable string.

Rate Advisory Messages Rate advisories are sent as CBOR arrays on the Control Stream: The limit_type field is a string matching the resource type being rate-limited (e.g., "message", "gossip", "datagram").

Sequence Validation Rules Sequence numbers are scoped to (genesis_NodeId, discriminator) where discriminator is the string from the signed payload array (e.g., "message", "document", "gossip"). Rules:

Sequence numbers MUST be strictly increasing per scope
Gaps MAY be buffered up to a limit of 256 missing entries
Out-of-order delivery is permitted, but sequence validation applies on receive
Duplicates with the same message_id are rejected
Retransmissions MUST reuse the identical message_id

Message ID Construction

Timestamp Validation Timestamps are advisory only. Sequence numbers dominate ordering.

Soft window (MUST accept): ±300,000 ms (5 minutes)
Hard window (MAY accept): ±3,600,000 ms (1 hour) with warning
Outside hard window: MUST reject

Implementations MUST NOT use timestamps for causality determination.

Gossip and Consistency

Vector Clocks Map from issuer → counter. Issuer canonical forms: Domain: text string (major type 3). NodeId: byte string, 32 bytes (major type 2). Mixed representations for the same issuer are PROHIBITED. Maximum vector clock entries: 1024. Entries beyond this limit SHOULD be pruned (oldest issuers first).

Gossip Message Format The signed payload is a CBOR array: The wire representation is:

Resource Authority Model

Resource Type	Authoritative Issuer	Mutability
`attestations`	Attestation issuer	Immutable after issuance
`revocations`	Revocation issuer	Monotonic (add-only)
`violations`	Witness peer	Immutable

Anti-Entropy Protocol SYNC request: SYNC response:

Conflict Resolution When updates are concurrent (neither vector clock dominates the other), the deterministic merge order is:

Causal check: If one clock has all issuers with counters >= the other clock, that clock wins (causal dominance)
If concurrent: Lexicographic comparison of sorted (issuer, counter) tuples as QUIP-CBOR
If equal: Higher NodeId (bytewise) of the signer of the update payload
If equal: Smaller SHA-256 of the update payload

Gossip TTL

Default: 5
Range: 3-7
Decrement before re-gossip; TTL=0 not re-gossiped

Rate Limiting and Accountability

Sequence Numbers Every reliable message carries a sequence number per (sender, resource_type).

64-bit unsigned integer
Maximum permitted value: 2^62 - 1 (approximately 4.6e18)
Implementations MUST trigger a key rotation warning when the sequence number reaches 2^61 (50% of max)
If a sender approaches 2^62 - 1, they MUST rotate their NodeId () before the next increment
Overflow beyond 2^62 - 1 is a provable violation ( code 16)

Violation Receipts When a peer detects a violation (e.g., sequence gap, rate exceedance), it creates a signed violation receipt and gossips it. Validation requirement: A violation receipt is considered valid only if corroborated by at least 3 independent witnesses as defined in . If fewer than 3 qualified domains exist in the federation, the threshold equals the number of domains. Receipt signature:

Resource Limits Implementations MUST enforce the following limits:

Resource	Limit	Behavior When Exceeded
Maximum CBOR object size	64 KB	Reject with error
Maximum gossip message size	64 KB	Reject with error
Maximum document size	16 MB	Reject with error
Maximum attestation chain depth	8	Reject with error
Maximum rotation chain depth	32	Reject with error
Maximum vector clock entries	1024	Prune oldest
Maximum replay cache entries	100,000	LRU eviction
Maximum pending sequence gaps	256	Discard oldest

Conformance Profiles

Profile	Required Features
Basic	NodeId, attestations, DANE (COMPAT), message envelope, rate limiting, gossip
Documents (Companion Document)	Adds: content addressing, schema registry, collections. Specified in a separate document.
Media (Experimental)	See

The Documents profile features (content addressing by hash, schema registry, document collections) are specified in a companion Internet-Draft titled "QUIP Documents Profile".

Experimental Features The following features are marked experimental in this version and MAY change incompatibly in future versions. Implementations SHOULD log a warning when experimental features are used.

Feature	Status
Media profile	Incomplete; separate document planned
Routing resource type	Not fully specified; use at own risk

The Media profile uses QUIC datagrams as specified in .

Security Considerations

Threat Model Summary QUIP defends against: domain impersonation (via subject signatures), replay attacks (via message_id cache), BGP hijacking (via DANE binding), DNS poisoning (via DNSSEC), split-brain/fork (via deterministic merge), gossip amplification (via TTL and rate limits), Sybil witnesses (via independent witness definition — raises operational cost of Sybil-style witness fabrication). QUIP does NOT defend against: anonymity attacks, metadata confidentiality, global passive adversaries, Byzantine consensus, economic Sybil resistance, or witness collusion (relies on legal/commercial incentives).

Replay Attacks Domain separation () prevents cross-context replay. The message_id cache provides per-message protection.

Downgrade Attacks DNS downgrade protection () and handshake transcript binding () prevent silent capability stripping. STRICT mode refuses downgrades.

Canonicalization Attacks QUIP-CBOR () eliminates encoding ambiguity. Duplicate keys and indefinite lengths are rejected. QUIP-CBOR is defined as an application profile of .

Privacy Considerations

NodeId reuse enables correlation
Gossip reveals topology
Address bindings are public

Linkability through rotation chains: Key rotation preserves identity continuity for accountability. All keys in a rotation chain are cryptographically linked to the genesis NodeId. Rotating keys does NOT provide unlinkability or anonymity.

IANA Considerations

ALPN Protocol ID Registration IANA is requested to register the following ALPN protocol ID:

Protocol:: QUIP
ID:: "quip"
Reference:: This document

QUIP Error Codes Registry IANA is requested to create a registry titled "QUIP Error Codes" with the following initial contents:

Code	Name	Description
1	INVALID_SIGNATURE	Signature verification failed
2	ATTESTATION_EXPIRED	Attestation validity period exceeded
3	DNSSEC_FAILURE	DNSSEC validation failed
4	RATE_LIMIT_EXCEEDED	Quota exceeded
5	DUPLICATE_MESSAGE	message_id already seen
6	KEY_ROTATED	Sender's NodeId rotated
7	UNSUPPORTED_VERSION	Schema version not supported
8	GOSSIP_RATE_LIMIT	Gossip update rate exceeded
9	PROFILE_MISMATCH	No common profile
10	HASH_MISMATCH	Document hash mismatch
11	DATAGRAM_NOT_SUPPORTED	Peer does not support datagrams
12	GOSSIP_BOOTSTRAP_FAILED	Bootstrap failed
13	KEY_COMPROMISED	Key compromise reported
14	GOSSIP_SYNC_TIMEOUT	Anti-entropy timeout

Registration policy: IETF Review for codes 0-127. Codes 128-255 are reserved for application-specific extensions. Error code 0 is reserved and MUST NOT be used.

CBOR Tag 65536 Registration IANA is requested to register the following CBOR tag in the CBOR Tags registry :

Tag Number:: 65536
Data Item:: CBOR array
Semantic:: Container for QUIP protocol messages. The first element of the array is a string discriminator indicating the message type (e.g., "message", "gossip", "document", "key_rotation", "primary_binding").
Point of Contact:: Junior Joseph Mututi <jjmututicloud@gmail.com>
Fragment Identifier:: N/A
Reference:: This document

QUIP-CBOR Profile QUIP defines a strict deterministic CBOR profile called the QUIP Deterministic CBOR Profile (QDP). This is an application profile, not a replacement for canonical CBOR. QDP is used exclusively within QUIP protocol messages.

Encoding Rules

Class	Type	Ordering Rule
1	Unsigned integers	Numeric ascending, shortest encoding first
2	Negative integers	Numeric ascending (more negative first)
3	Byte strings	Length-ordered, then lexicographic
4	Text strings	Length-ordered, then UTF-8 bytewise lexicographic

Prohibited constructs: duplicate map keys, indefinite-length items, floating point values, non-minimal UTF-8, CBOR simple values other than false/true/null.

Implementation Guidelines

State Persistence Implementations MUST persist vector clocks for all tracked resources, sequence number state per (genesis_NodeId, discriminator), revocation state for known peers, and peer relationship state. Replay cache persistence is OPTIONAL.

Sequence State Loss Recovery If sequence state is lost after restart, the implementation MUST log a critical error, rotate the NodeId () to start a new sequence space, and NOT reuse prior sequence numbers.