IETF Internet-Draft · Chio Docs

Source

This page normatively reflects spec/ietf/draft-chio-protocol-00.md in the chio repository. Intended status: Standards Track. Dated April 2026, expires October 2026. The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY are interpreted as described in BCP 14 when, and only when, they appear in all capitals.

The conformance section also reflects tests/conformance/native/README.md, the scenario files under tests/conformance/native/scenarios/, and the runner flags in crates/tooling/chio-conformance/src/bin/chio_native_conformance_runner.rs.

Synopsis

The draft opens with the Internet-Draft header block, then runs from the abstract through the references in the numbered sections of the section map.

spec/ietf/draft-chio-protocol-00.mdtext

Network Working Group                                          Chio Editors
Internet-Draft                                                April 2026
Intended status: Standards Track
Expires: October 2026

# The Chio Protocol

Abstract

The draft describes Chio as a protocol and runtime profile for mediated tool execution under signed capabilities, signed receipts, explicit versioning, and bounded transport security requirements. It defines a native framed transport, an MCP-compatible hosted edge, and trust-control lifecycle endpoints for capability issuance, delegated issuance, receipt query, and revocation.

The draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. It is not an Internet Standards Track specification; it is published for review and discussion.

Conventions and terminology

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY are interpreted as described in BCP 14 when, and only when, they appear in all capitals. The draft defines these terms:

Term	Definition
capability	A signed Chio authority token
receipt	A signed Chio audit record for one evaluated action
sender constraint	Proof that binds a caller to an issued capability or session profile
native Chio transport	The framed transport defined in phase `311`

Section map

The draft is organized into the standard Internet-Draft sections. Each one is anchored to normative material elsewhere in the repository.

Section	Defines	Anchored in
1. Introduction	One caller invokes one tool under explicit delegated authority while producing signed audit receipts; the protocol surface is split into cooperating layers	none
2. Conventions and Terminology	BCP 14 key words; capability, receipt, sender constraint, native Chio transport	none
3. Protocol Surface	Native framed transport, hosted MCP transport, trust-control lifecycle	`spec/WIRE_PROTOCOL.md`
4. Error and Version Model	The machine-readable registries for negotiation and error taxonomy	`spec/versions/`, `spec/errors/`
5. Security Considerations	Threat model and surface-specific transport rules	`spec/SECURITY.md`, `spec/security/`
6. Conformance	Native conformance lane and language-neutral driver contracts	`tests/conformance/native/`
7. IANA Considerations	No IANA actions in this revision	none
8. References	Normative and informative references	none

Protocol surface

Section 3 splits the protocol surface into cooperating layers. The native transport alone is narrow; the hosted and trust-control surfaces carry the rest of the deployment.

Native Chio transport

The native transport uses one frame format:

a 4-byte unsigned big-endian length prefix
canonical JSON payload bytes

Versioning is out-of-band exact match. The wire version is chio-wire-v1; there is no in-band downgrade, and incompatible peers close or reset the transport. The native message catalog is:

Family	Messages
`AgentMessage`	`tool_call_request`, `list_capabilities`, `heartbeat`
`KernelMessage`	`tool_call_chunk`, `tool_call_response`, `capability_list`, `capability_revoked`, `heartbeat`

Hosted MCP transport

The hosted edge exposes:

POST /mcp
GET /mcp
DELETE /mcp

Version selection occurs through initialize.params.protocolVersion and the response echoes the selected value in result.protocolVersion. The current shipped implementation supports exactly one MCP protocol version: 2025-11-25.

Trust-control lifecycle

The trust-control service exposes versioned HTTP endpoints under /v1: capability issuance, federated or delegated issuance, receipt query, and revocation. Delegated issuance uses explicit continuation inputs and a signed delegation policy ceiling when a parent capability is continued.

Error and version model

Section 4 names the machine-readable registries the draft relies on and does not restate their contents:

Registry	Schema id	Defines
`spec/versions/chio-protocol-negotiation.v1.json`	`chio.protocol-negotiation.v1`	Exact-match compatibility and rejection behavior for the native, hosted, and trust-control surfaces
`spec/errors/chio-error-registry.v1.json`	`chio.error-registry.v1`	Numeric Chio error codes, categories, transient or permanent classification, and retry guidance

The negotiation record defines rejection behavior for each surface. On the native surface, an incompatible peer triggers close_or_reset_transport and Chio error 1000. On the hosted MCP edge, a version mismatch is rejected with JSON-RPC -32600 carrying the same Chio code. Trust-control selects versions by path prefix and compares an exact /v1 match. The error registry and the negotiation file are documented field by field on the Schemas and Errors page.

Security considerations

Section 5 defers the threat model to spec/SECURITY.md and the machine-readable register spec/security/chio-threat-model.v1.json. At minimum, implementations address these threats:

capability token theft
kernel impersonation
tool-server escape
replay on the native channel
resource-exhaustion denial of service
delegation-chain abuse

Transport rules are surface-specific:

Deployment	Requirement
Remote hosted and trust-control HTTP	Requires TLS
Cross-host tool-server transport over TCP	Requires mTLS
Sender-constrained or grant profile that requires it	Requires DPoP
Plaintext remote deployment	Nonconformant

Attestation does not authorize by itself; it is only valid when paired with sender continuity over the same request.

Conformance

Section 6 points at checked-in conformance evidence for the native Chio lane under tests/conformance/native/. The suite is executed through JSON scenario files; each category the draft lists is one file under tests/conformance/native/scenarios/, and the last column is the title the file carries.

Category	Scenario file	Driver	Title
Capability validation	`capability-validation.json`	`artifact`	Signed capability verifies under the native fixture corpus
Delegation attenuation	`delegation-attenuation.json`	`artifact`	Delegated capability remains structurally valid and narrower than its parent
Receipt integrity	`receipt-integrity.json`	`artifact`	Signed receipt verifies and tampering is detected
Revocation propagation	`revocation-propagation.json`	`stdio`	Revoked capability is surfaced as a terminal capability_revoked response
DPoP verification	`dpop-verification.json`	`artifact`	Chio-native DPoP proof verifies for the expected capability and action binding
Governed transaction enforcement	`governed-transaction-enforcement.json`	`http`	HTTP driver returns a governed receipt for the governed transfer fixture

The runner supports language-neutral driver contracts for these execution modes, so a third-party implementation can satisfy the same scenarios:

Mode	Target contract
`artifact`	No external process; the runner validates deterministic Chio fixtures such as signed capabilities, delegation chains, receipts, and DPoP proofs
`stdio`	An executable that speaks the native framed transport on stdin and stdout; the runner writes one length-prefixed `AgentMessage` frame and reads `KernelMessage` frames until the terminal `tool_call_response` or EOF
`http`	An HTTP service exposing `POST /chio-conformance/v1/invoke`, carrying plain JSON so an implementation in another language can use the endpoint without framed bytes

The checked-in suite runs against the reference fixture. Build the runner and the fixture, start the fixture's HTTP listener, then point the runner at both targets. --results-output and --report-output name the JSON results file and the Markdown report the runner writes; any writable paths serve, and the runner creates their parent directories.

bash

cargo build -p chio-conformance \
  --bin chio-native-conformance-runner \
  --bin chio-native-conformance-fixture

# in a second terminal: the HTTP target the http scenario calls
target/debug/chio-native-conformance-fixture --http-listen 127.0.0.1:9954

target/debug/chio-native-conformance-runner \
  --scenarios-dir tests/conformance/native/scenarios \
  --results-output conformance-out/chio-self.json \
  --report-output conformance-out/chio-self.md \
  --stdio-command target/debug/chio-native-conformance-fixture \
  --http-base-url http://127.0.0.1:9954

IANA considerations

Section 7 declares no IANA actions in the current revision. Future versions may request registrations for Chio media types, Chio protocol parameter names, and Chio error registry identifiers.

References

Normative

Reference	Used for
RFC 8785	JSON Canonicalization Scheme; canonical JSON payload bytes on the native frame
RFC 9449	OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP); sender-constrained proofs

Informative

GNAP core work for delegated authorization continuation
SCITT architecture and transparency evidence work
RATS architecture for verifier-backed runtime claims
W3C Verifiable Credentials Data Model
OpenID for Verifiable Credential Issuance
OpenID for Verifiable Presentations

Wire Protocol: the byte-level framing rules, hosted MCP session lifecycle, and trust-control endpoint contracts an implementer works from.
Protocol: capability, receipt, and manifest field semantics.
Schemas and Errors: the negotiation artifact and error registry in full.
Security: the threat model and transport security matrix.
Bindings API: vector corpus and binding-conformance suite.

PreviousWire Protocol NextHTTP Transport