An open wire-level standard for handing off live AI, IVR and human conversations across vendors — with full identity, consent, AI-governance, and crypto-grade trust.
When a live conversation moves between systems — IVR to AI, AI to human, AI to another vendor's AI, voice to chat — almost every piece of useful context is lost or has to be rebuilt by side-channel APIs that are different at every contact-centre. OHP defines the single, signed envelope that travels with the call.
A receiver that accepts an OHP envelope knows, at the wire level:
- Who is on the call — strong identity assurance, sd-jwt verifiable credentials, AAL/IAL levels.
- What was agreed — the conversation summary, intent stack, slot values, and a redaction-aware transcript.
- What the user consented to — ISO/IEC 27560 consent receipts, lawful basis, jurisdictional scope.
- Which AI system was driving — risk class, model card, GPAI provenance, oversight mode, decision log.
- That the envelope is genuine — Ed25519 + ML-DSA-65 hybrid JWS signatures, transparency-log anchored.
- That sensitive data stays sealed end-to-end — HPKE encryption with per-recipient keys.
No proprietary connectors. No screen-scraping the IVR. No "trust me, the previous vendor authenticated them".
OHP is one envelope with four conformance tiers. Each tier is a strict superset of the one below, so you adopt only what your workload needs.
| Tier | What it adds | Typical use |
|---|---|---|
| Core | Identity, intent, transcript summary, consent receipt, control verbs. Plain JSON. | Internal IVR-to-agent routing, low-stakes warm transfers. |
| Signed | Detached JWS over a CBOR-canonicalised envelope, DID-based issuer identity, RTP fingerprint binding. | Cross-vendor handoffs where receivers need to prove provenance. |
| Sealed | HPKE-encrypted sub-envelope for sensitive fields, federation trust chain, recipient-specific keys. | Healthcare, financial services, regulated cross-border calls. |
| Regulated | EU AI Act + ISO/IEC 42001 metadata: aiSystem, governance, oversight, per-decision provenance, Art 50 / Art 86 disclosures. |
High-risk AI deployments, post-market monitoring, auditable AI handoffs. |
Read the normative spec, the architecture overview, or the field-by-field envelope reference.
OHP separates concerns the way HTTP separates them from TLS so that any layer can evolve independently.
| Layer | Concern | Examples |
|---|---|---|
| L4 — Conversation State Envelope | The mandatory JSON document the spec defines. | id, issuer, audience, intent, transcript, consent, signatures. |
| L3 — Control Plane | The verbs that drive a handoff. | PROPOSE, ACCEPT, REJECT, ASSUME, RETURN. |
| L2 — Transport Bindings | How envelopes ride existing infrastructure. | ohp/sip-info, ohp/ws, ohp/https, ohp/grpc. |
| L1 — Trust, Identity & Crypto | What makes the envelope verifiable. | DIDs, HPKE, hybrid JWS (Ed25519 + ML-DSA-65), SD-JWT VC, OpenID Federation, transparency log. |
| L0 — Media Continuity | Binding the envelope to the live media leg. | SDP re-INVITE hints, RTP fingerprint, codec negotiation. |
| Repository | What it is |
|---|---|
| OHP | The specification, schemas, examples, and conformance suite. Start here. |
More repositories — reference implementations, the conformance test runner, transport-binding libraries — will be added as v0.2 work begins. See the roadmap.
OHP is a public draft at version 0.1. The wire format is stable enough for early implementers to build against; breaking changes between v0.1 and v0.2 will be called out in the changelog with migration notes.
- Reference conformance test runner (Node + Python) that consumes the test vectors.
- A signed-vector pack (real Ed25519 + ML-DSA-65 signatures, HPKE round-trips).
- Reference receiver/sender libraries for one transport binding.
- Capability-discovery polish for
/.well-known/ohp-capabilities.json.
- Read the spec. Start with the overview, then the normative v0.1 document.
- Discuss. Ideas, questions, and proposals belong in Discussions.
- Open an issue. Bug reports, spec ambiguities, and concrete proposals: issue tracker.
- Contribute. Read CONTRIBUTING.md — contributions are accepted under the DCO.
- Governance. Editor / maintainer model and decision process: GOVERNANCE.md.
- Security. Private disclosure process: SECURITY.md (
security@cloud.ax). - Code of conduct. CODE_OF_CONDUCT.md.
The Open Handoff Protocol specification, schemas, examples, and conformance materials are licensed under Apache License 2.0. See LICENSE and NOTICE.
General enquiries: enquiries@cloud.ax · Security: security@cloud.ax · Conduct: conduct@cloud.ax
OHP is being incubated by Cloudax and is contributed to under Apache 2.0 with the explicit goal of becoming a multi-vendor, multi-implementer standard. Implementers, integrators, and regulators are welcome — see the adoption roadmap.
