IETF Internet-Draft · Chio Docs

When to use this page

Use this page when: you need the standards-track document itself, its intended status, its section map, and its normative and informative references. Don't use this if: you want the byte-level framing rules and endpoint contracts an implementer works from (see Wire Protocol) or the capability and receipt field semantics (see Protocol Reference).

Source

This page reflects spec/ietf/draft-chio-protocol-00.md in the Chio repository. The draft is submitted in full conformance with BCP 78 and BCP 79. It is published for review and discussion and is not itself an Internet Standard.

Document Metadata

Field	Value
Title	The Chio Protocol
Stream	Network Working Group
Author	Chio Editors
Intended status	Standards Track
Date	April 2026
Expires	October 2026

Abstract

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

Conventions and Terminology

The keywords 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 pins four 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 and, where it exists, a companion reference page on this site.

Section	Defines	Anchored in
1. Introduction	Three cooperating layers; one caller invokes one tool under delegated authority producing signed receipts	—
2. Conventions and Terminology	BCP 14 keywords; capability, receipt, sender constraint, native transport	—
3. Protocol Interfaces	Native framed transport, hosted MCP transport, trust-control lifecycle	`spec/WIRE_PROTOCOL.md`
4. Error and Version Model	Two 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	—
8. References	Normative and informative references	—

Protocol Interfaces

Section 3 splits the protocol into three cooperating layers. The native transport is narrow; the hosted and trust-control interfaces provide the remaining deployment functions.

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 three methods on one path:

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 references two machine-readable registries rather than restating their contents inline:

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/permanent classification, and retry guidance

The negotiation record defines rejection behavior for each interface. On the native interface, 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 full threat model to spec/SECURITY.md and the machine-readable register spec/security/chio-threat-model.v1.json. At minimum, implementations address six 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 interface-specific:

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

Attestation is not authorization

Attestation does not authorize by itself. It is valid only when paired with sender continuity over the same request. A verified runtime claim without a bound sender constraint does not admit a call.

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 and covers six categories:

Category	Scenario file
Capability validation	`capability-validation.json`
Delegation attenuation	`delegation-attenuation.json`
Receipt integrity	`receipt-integrity.json`
Revocation propagation	`revocation-propagation.json`
DPoP verification	`dpop-verification.json`
Governed transaction enforcement	`governed-transaction-enforcement.json`

The runner supports three language-neutral driver 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/stdout; the runner writes one length-prefixed `AgentMessage` 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 non-Rust implementations can use the endpoint without framed bytes

The checked-in suite runs against the reference fixture. Build the runner and fixture, then point the runner at either an --stdio-command or an --http-base-url target:

bash

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

$ target/debug/chio-native-conformance-runner \
    --scenarios-dir tests/conformance/native/scenarios \
    --results-output tests/conformance/native/results/generated/chio-self.json \
    --report-output tests/conformance/native/reports/generated/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: normative framing, hosted MCP session lifecycle, and trust-control endpoints.
Schemas and Errors: the negotiation artifact and error registry in full.
Protocol: capability, receipt, and manifest field semantics.
Security: the threat model and transport security matrix.
Bindings API: vector corpus and binding-conformance suite.