PCHP, Personal Consent Handshake Protocol

TL;DR: PCHP is Hussh's open consent and scoped-export protocol (SSH for humans), the consent authority of the control plane, defined by one versioned normative specification (pchp/2026-07-12, v0.1.0) and extended by numbered RFC profiles; the protocol is a name, never a number.

Relations

Nav
One
Kai
Three-layer architecture
BYOA
Connected Systems
Source Library
PCHP Consent Handshake — Sequence — consent handshake diagram

PCHP governs whether an agent or service may receive a scoped export of a person's information, for a stated purpose and duration. It keeps invocation, information access, and action authority separate. A valid grant is necessary for the protected read; it does not by itself establish where the agent runs or who can administer the selected runtime.

One can run in an owner-cloud pod or in a qualified Hussh-hosted pod, while the development pod serves validation. Shared service paths also exist. Key custody, readable processing, and recovery depend on that selected path and its environment. Encrypted vault persistence and sealed exports protect defined boundaries, but they do not prove that Hussh, a provider, or every service can never process readable information.

Consent receipts and revocation must be verified at each relevant hop. Particular routes enforce scoped grants; complete specialist coverage and durable receipt persistence remain requirements. This custody clarification was reviewed against the private agent architecture on 2026-09-23. The implementation inventory below retains its earlier dated status.

Naming rule (canonical): PCHP is the protocol, a name, never a number. The PCHP Specification is the single normative document, versioned by protocol date and semver: pchp/2026-07-12, specification v0.1.0, status Public Request for Comments, licensed CC0 plus Apache-2.0. RFC-00N are numbered profiles and extensions on top of the specification, never the specification itself. Any surface that calls PCHP itself "RFC-001" should be corrected.

The RFC ladder

Number	Name	What it defines	State
—	PCHP Specification	The base protocol: parties (owner, issuer, requester, guardian), handshake lifecycle, tokens, sealed envelope, transparency log, transports, conformance	v0.1.0 · Public RFC · 12 sections written, 13 drafted, 12 planned
RFC-001	The Handoff	How two Ones meet on behalf of their humans, by consent, with a receipt	Published
RFC-002	For agents / the preference subscription fabric	Scope registry, tiers, purpose bundles, the multi round-trip consent pattern, subscriptions	Published; registry generated and versioned
RFC-003	hu_ssh	The binary transport for tensor and state movement between a person's own devices	Design published; reference wire grammar implemented. A pure TypeScript reference parser with golden test vectors is merged and enforces every normative MUST of the frame grammar; a session writer (the sending half, with writer-assigned strictly increasing sequence numbers) is in review. Still honest about the rest: no transport, no server daemon, no cryptography - the attestation chain, enclave signatures, and session encryption remain unimplemented, and the header misalignment is documented as HEP-0001.

RFC-003 is reserved. New protocol work beyond these takes the next number, or, once the PCHP Enhancement Proposal (PEP) process exists, enters as a numbered PEP. Per the spec index's own assessment, the missing lifecycle/deprecation policy and PEP process are the highest-value unwritten sections.

One handshake, two honest descriptions

Two accounts of the handshake exist in public canon, and both are correct at their own altitude:

What the person experiences, four phases (the founding paper, The Hussh One): Identity Resolution, Consent Negotiation, Scoped Exchange, Signed Receipt.
What the specification requires, six phases (the normative spec, §4 Handshake Lifecycle). In the spec overview's narration: the requester states exactly what it wants and why, the owner approves or declines with a real credential, a scoped, time-boxed key is issued, the data moves inside a sealed envelope, steps are recorded for the owner, and revocation ends the grant. Actual per-hop enforcement and receipt durability require path-specific verification.

The reconciliation to use everywhere: four phases a person experiences; six phases on the wire. The paper describes the human arc; the spec describes the machine lifecycle. Cite the spec for anything normative.

Known gap (2026-08-08): the official §4 phase names have not been transcribed into this page; the six-step narration above is from the spec's Overview prose. Pull the exact names from §4 and replace this note.

The four primitives

The wiki's historical vocabulary and the spec's plain-language vocabulary are the same objects:

Primitive	Plain name in spec	What it is
Consent Receipt Token (CRT)	the signed receipt	The owner's signed statement: scope X, purpose Y, until Z. Presentable to an auditor; revocable.
Data Access Token (DAT)	the revocable key	The capability the receiver holds. Bound to a CRT (no CRT, no DAT). Scope cannot widen without re-handshake. When the owner revokes, the key dies.
Transparency Log	the log the owner can read	The protocol's owner-readable audit history. Hash-chained receipts and verification exist on defined paths; complete per-hop receipt coverage and durable writes require further proof.
Sealed Envelope	the sealed envelope	Data moves as a short-lived or encrypted envelope scoped to the approved request. (Formerly "Ephemeral Envelope" in this wiki and "zero-knowledge envelope" in some site copy; one primitive, canonical name Sealed Envelope, per the spec.)

The scope registry and tiers (RFC-002)

The vocabulary is generated, versioned (registry v0.6.0), and served at the public scopes registry endpoint: 263 scopes, seven roots (favorites, life, prefs, privacy, profile, story, wants), 15 purpose bundles, and five tiers that govern what may ever happen to a field:

0 Open (3), coarse, free on first handshake
1 Signal (27), consent state, machine-readable, bundleable
2 Commercial (153), priced, bundleable, auctionable
3 Sensitive (62), never bundled; named counterparty, named purpose only
4 Intimate (18), never auctionable at any price; named human or institution, time-boxed, revocable

Two structural rules: an unknown scope fails closed to tier 4, and writes to tier 3+ are refused today because the encrypted store they belong in is not yet wired. 109 scopes carry IAB Audience Taxonomy mappings; privacy scopes map to Google Consent Mode v2 keys. Deprecation is enforced by a build-failing test: a published scope stays servable at least 365 days after retirement notice, tombstone kept permanently.

The data door

The data door is the scoped read boundary between a pod and a shared specialist. On the implemented routes, a pod presents consent-backed authority and the service returns only the permitted read result; missing, malformed, or revoked authority is refused. This is a path-specific contract, not proof that every specialist and internal read has moved behind the door.

The intended lifecycle carries scope, purpose, audit, and revocation with each read. Complete specialist authority threading and durable receipt coverage remain to be demonstrated across deployed paths.

Composition

PCHP does not replace the agent rails; it adds who asked, under what consent, for what purpose, with what receipt on top of MCP (tools), A2A (negotiation), AP2 (payments), UCP (commerce). The protocol defines scope, purpose, and receipt metadata so a gateway can enforce authorized reads without relying on a broad standing grant. The ungranted case follows MCP's multi round-trip pattern: a request missing consent is answered with exactly what is needed and where to grant it, never blocked on a held connection.

SSH for humans

The analogy is structural: SSH made remote access negotiable, auditable, and revocable across mutually-suspicious machines; PCHP does the same for personal-records access across mutually-suspicious agents and services. CRT/DAT/Log/Envelope map to session keys / authorized keys / connection log / the encrypted channel. Hence hu_ssh as the working name for the RFC-003 transport.

PCHP is not OAuth (OAuth authorizes an app against a provider; PCHP obtains a person's consent for a read of their own records, with a receipt), not OpenID (identity is an input to the handshake, not the handshake), not DRM (protects the owner's control, not a vendor's).

Implementation ledger (honest)

This is the earlier source inventory associated with this page's September 4 status. It is not a fresh deployment attestation for every listed capability.

Source-implemented at that snapshot: the consent-protocol package in the Hussh Research repository (agents, ADK bridge, consent services, OpenClaw/ClawHub plugin surface); PCHP client script reported sitewide on hushh.ai at that snapshot, bridged into Google Consent Mode v2 with all four signals defaulting to denied; signed TTL-capped consent tokens; hash-chained receipt ledger; air-gapped offline mode with local reviewer session; first-class Python SDK gating vault reads/writes; the hu_ssh (RFC-003) reference wire parser with golden vectors, enforcing the published frame grammar's normative MUSTs.
In review: the hu_ssh session writer, the sending half whose invariant is that everything it writes, its own reader accepts.
Design only: the hu_ssh transport itself - no QUIC, no daemon, no handshake state machine, no cryptography; the wire grammar is executable, the transport is not.
Planned: issuer discovery (well-known document), requester registration (Client ID Metadata Documents, following MCP's deprecation of dynamic registration), Guardian rules (standing, revocable rules that pre-screen an offer on the owner's behalf), PEP process, feature lifecycle/deprecation policy.
Authoritative record: the implementation status ledger. The spec index publishes real per-section states rather than listing only finished work.

Founding principle

If software reads private records, the owner must know the scope, purpose, duration, and audit path before access is honored. Consent is a technical boundary, not a paragraph in a terms page. Your information, your business.