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

Hussh is the control plane, not the custodian of your holdings. Your private agent, One, runs in your own pod: a small container in your own cloud (BYOC), with keys on your own device (BYOK). Hussh operates that pod on your behalf but holds none of your information. It keeps only public metadata (an identifier and the pod's public key), relays sealed ciphertext between parties, and authorizes consent. There is no Hussh vault of your records, and no Hussh backup-of-record.

Plaintext exists only inside your pod and on your device. Everything Hussh and the network see is encrypted. The durable backup is your own, in your own cloud, unlockable only with material that never leaves your device. PCHP is the consent authority that makes each exchange legible: every exchange rides a single-use, signed, revocable grant. That is what "Own your AI. Own your data. Own your compute." means. We are the enabler for exchange, not the holder of what is exchanged.

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: currently 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" is wrong and should be corrected to this page.

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 machines do, six phases (the normative spec, §4 Handshake Lifecycle). In the spec overview's own 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, every step is written to a log the owner can read, and on revocation the key dies.

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	Hash-chained; every issued/revoked CRT and every honored DAT lands here. HMAC-signed receipts with chain verification are implemented.
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

When One needs a capability it does not run itself, a keyless pod reaches a shared specialist through the data door: the read boundary of the control plane. The data door is read-only, fail-closed, and owner-revocable. A pod carries no long-lived key of its own; it presents a consent-backed grant, the door authorizes the read against that grant, and it returns only what the scope allows. If a grant is missing, malformed, or revoked, the door refuses (there is no default-open path), and the owner can revoke the grant at any time, after which the door stops honoring it. Reads are one direction only: a specialist behind the door can be asked, never written to through it. This is PCHP's consent lifecycle applied at the boundary between a person's pod and the shared specialists of the network: scope, purpose, receipt, and revocation travel with every read.

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). Scope, purpose, and receipt travel in HTTPS headers so a gateway can enforce without reading the body. 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)

Real, shipped: the consent-protocol package in the Hussh Research repository (agents, ADK bridge, consent services, OpenClaw/ClawHub plugin surface); PCHP client script live sitewide on hushh.ai 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.