Protocol pchp/2026-07-12, specification v0.1.0. Status: Public Request for Comments. Every section of the protocol, what state it is in, and an honest count of how much is actually written.
This index is modelled closely on the Model Context Protocol’s own specification index, which is the best documentation in this field and the standard we hold ourselves to. The structure below — architecture, a base protocol, authorization, reusable patterns, transports, features split by party, a machine-readable reference, and a published process — is theirs. We adopted it because an implementer who has read one should be able to navigate the other without relearning anything.
Every entry carries its real state. 12 written, 13 drafted, 12 planned. An index that lists only finished sections is a marketing page. One that shows the whole shape and marks what is missing is a specification, and it is the only kind anybody can plan against.
The parties, the trust boundaries, and what each one is permitted to assume about the others.
Architecture
A requester outside the circle is the normal case, not the exception; the protocol is written for it.
Everything every implementation must get right before it implements anything interesting.
Basic
Date-stamped protocol versions carried per request, after MCP's model.
Authorization
Who is asking, and how an issuer knows.
A well-known document. Published spec makes this Phase 1; not yet served.
Client ID Metadata Documents rather than dynamic registration, following MCP's deprecation.
Issuer binding per RFC 9207: a receipt is valid only against the issuer that minted it.
Patterns
Interaction shapes an implementation reuses everywhere.
Mirrors MCP's input_required. An ungranted request is answered, not blocked.
Must reach every access derived from a grant, across instances.
RFC-002, the preference subscription fabric.
Transports
Scope, purpose and receipt in headers so a gateway can enforce without reading the body.
The binary transport for tensor and state movement between a person's own devices.
What the person whose data it is can do. MCP calls the mirror of this client features; for a consent protocol the human is the first-class party, so they come first.
Owner features
The pchp.js embed, live on this site.
Hash-chained ledger exists; the owner-facing view is partial.
Standing, revocable rules that pre-screen an offer on the owner's behalf.
What the party holding the data must implement.
Issuer features
252 published, five tiers.
Bundles that make an ask legible to a person.
HMAC-signed, hash-chained, with chain verification.
A published scope stays servable for at least 365 days after retirement is announced, and its tombstone is kept permanently. Enforced by a test that fails the build if a scope leaves the registry without notice.
Issuer utilities
TTL and cache scope on list results, after MCP's cacheable lists.
The machine-readable artifacts an implementation is written against.
Reference
Generated, versioned v0.5.0. The normative vocabulary.
A single generated document covering every wire shape.
Needs the lifecycle policy below to exist first.
The part most protocols skip and then regret. MCP publishes its enhancement process, its contributor ladder, and its deprecation policy — and that is a large part of why people build on it.
Process
The rules a proposal is judged against.
MCP commits to a twelve-month minimum window. We have made no such commitment yet, and should.
Numbered, public proposals with an index — modelled on MCP's SEP process.
What is enforced today versus published.
Reading MCP’s documentation end to end, the striking thing is not the protocol. It is that they publish a numbered enhancement process, a contributor ladder, working-group charters, and a deprecation policy with a twelve-month minimum window. That is what makes a standard safe for someone else to build a business on.
We publish a scope registry and invite people to build against it, and we have never said what happens when a scope is renamed or withdrawn. Until we do, the honest label on that row is planned, and it is the highest-value thing on this page that does not yet exist.
The specification is open, the registry is generated and public, and the unfinished sections are named rather than hidden.
One is a product of Hushh Technologies Corporation (brand: 🤫 “hussh”), an independent company. One runs on third-party silicon, systems, and cloud; platform names are used solely to describe where One software runs and imply no affiliation, endorsement, or sponsorship by those platforms. Our own go-to-market and bill-of-materials partner programs are real and actively in pursuit; we name a partner only once an agreement is executed.