PCHP — Personal Consent Handshake Protocol
Hussh consent protocol implemented today through Consent Protocol, Developer API, hosted MCP consent/export, PCHP RFC-002, client libraries, and audit flows.
TL;DR: PCHP (Personal Consent Handshake Protocol) is Hussh's consent and scoped-export layer: SSH for humans.
Status as of 2026-07-26: see body.
Relations
The four primitives
PCHP composes four small artifacts into one consent handshake:
1. Consent Receipt Token (CRT)
The user's signed statement: "I consent to scope X, for purpose Y, until time Z." Issued at the moment of consent, presentable to the user or an auditor, and revocable.
2. Data Access Token (DAT)
The capability the receiving party gets. Bound to a specific CRT — no CRT, no DAT. Includes scope, expiry, and the audit hooks. The receiver cannot widen scope without re-handshake.
3. Transparency Log
Every issued/revoked CRT and every honored DAT lands here. The user can reconstruct who saw what, when, why in one place. The audit truth belongs to the user's consent record, not to a partner CRM.
4. Ephemeral Envelope
For one-shot reads or partner exports, the data moves as a short-lived or encrypted envelope scoped to the approved request. This is what prevents "Kai composed a financial picture" or "a partner requested a CRM update" from becoming broad vault extraction.
Why SSH for humans
The analogy is more than marketing. SSH solved a specific problem: making remote-access negotiable, auditable, and revocable across an open network of mutually-suspicious machines. PCHP solves the same shape of problem one layer up — making personal-data access negotiable, auditable, and revocable across an open network of mutually-suspicious agents and services. The four primitives map to SSH's session keys / authorized keys / known hosts / connection log, with consent semantics replacing crypto-only semantics.
Founding principle
PCHP exists because consent should be a technical boundary, not a paragraph in a terms page. The principle is simple: if software reads private data, the user should know the scope, purpose, duration, and audit path before access is honored.
Open Specification & Developer Ecosystem (PCHP RFC-002)
- PCHP RFC-002 & Open Libraries: Published as an open specification and hardened JavaScript client library, allowing any website or application to integrate PCHP consent handshakes in minutes.
- Scope Registry: Standardized scope definitions for privacy choices (
privacy.marketing-email), transactional preferences, and user wants/favorites. - Developer Quickstart: Streamlined onboarding flow for site owners and developers to register PCHP agent endpoints and consent connectors.
Adjacent positioning
- PCHP is not OAuth. OAuth grants access; PCHP grants consent, with audit and revocation as first-class primitives.
- PCHP is not OpenID/SSO. PCHP is about data flow, not identity assertion.
- PCHP is not DRM. DRM enforces what the recipient can do; PCHP enforces whether the recipient can read at all, on the user's terms.
A useful framing for partner conversations: SSL/TLS for the AI agent economy — the neutral consent infrastructure all major model ecosystems need.
Repo truth and north-star boundary
- Current implementation truth: PCHP is implemented today through the Consent Protocol, the Hussh Developer API, hosted MCP consent tools, consent tokens, scoped exports, client libraries, and auditable consent-status flows. An air-gapped, local-first offline mode lets consent request and status round-trips run entirely against a local database with a local reviewer session. A first-class Hussh Python SDK exposes the core consent primitives — gated vault reads, consent-gated vault writes, and one-tap user confirmation — so every data interaction passes through PCHP boundaries.
- Evidence boundary: backed by the shipped offline mode, the first-class SDK, and open client libraries, current as of 2026-07-26.