Wiki · Concept · Last reviewed June 25, 2026

Oblivious HTTP

Oblivious HTTP is an IETF Standards Track protocol for forwarding encrypted HTTP messages through a relay and gateway so request content and client network identity are separated.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: privacy, HTTP, telemetry, relays, surveillance

Definition

Oblivious HTTP, or OHTTP, is defined by RFC 9458, published in January 2024 as an Internet Standards Track document. The RFC describes a protocol for forwarding encrypted HTTP messages so a client can make multiple requests to an origin server without that server linking the requests to the client or identifying them as coming from the same client.

The core privacy split is simple. A relay sees the client and forwards an encapsulated request, but does not see the plaintext HTTP message. A gateway decrypts the encapsulated message and forwards it to a target resource, but should not see the client's IP address. RFC 9458 says the combination prevents the gateway from seeing the client IP address and prevents the relay from seeing plaintext content.

OHTTP is related to Distributed Aggregation Protocol and other privacy-preserving measurement systems because it can hide who submitted a report from the server that processes the content. It is not the same as aggregation, differential privacy, or consent.

Mechanism

An OHTTP client first needs the gateway resource identity, the gateway public key configuration, and the relay resource that will forward requests to that gateway. The client constructs an HTTP request for a target resource, encodes it as a Binary HTTP message, encapsulates it with Hybrid Public Key Encryption, and sends the encapsulated request to the relay. The relay forwards it to the gateway, the gateway decrypts and handles the request, then encapsulates the response for return through the relay.

The specification defines media types for key configuration, requests, and responses: application/ohttp-keys, message/ohttp-req, and message/ohttp-res. Binary HTTP is specified separately in RFC 9292, and HPKE is specified in RFC 9180. OHTTP depends on those building blocks rather than inventing its own message encoding or public-key encryption scheme.

Oblivious DNS over HTTPS, RFC 9230, is a related experimental protocol for DNS queries. OHTTP generalizes the pattern to HTTP messages, while still requiring explicit support from a willing relay and gateway.

Agent Context

OHTTP matters for AI Agent Observability because agent systems generate telemetry, error reports, safety events, browser actions, and model-use statistics. Some aggregate or diagnostic reports may be useful without giving the processor a stable client IP address or connection-level identifier.

A coding agent, browser agent, or workplace assistant could submit limited reports through OHTTP while keeping raw prompts, files, credentials, and user identity out of ordinary analytics logs. That does not make the telemetry harmless. The governance record still has to say what is measured, who receives it, how long it is retained, and what decision it feeds.

Governance Use

A governed OHTTP deployment should record the client class, relay operator, gateway operator, target resource, key configuration source, HPKE suite, key rotation period, request media type, response media type, anti-replay approach, cache policy, logging policy, error policy, and purpose of the request. It should also document whether relay and gateway operators are organizationally separate.

The protocol is most useful where the content of a request should reach a service but the service does not need to know which client sent it. Examples named in RFC 9458 include DNS queries, telemetry submission, anonymous surveys, search queries, and location-specific content such as map tiles. Agent telemetry is an adjacent modern use case, not a guarantee supplied by the RFC.

Limits

OHTTP is not a general anonymity network. RFC 9458 says it has limited applicability and requires explicit relay and gateway support. It is also only useful when the application does not carry identifying state between requests. Cookies, authentication, unique payloads, timing, size patterns, uncommon key configurations, or colluding relay and gateway operators can weaken the privacy goal.

The target resource is logically under gateway control in the OHTTP model. The gateway can decrypt the request and determine the response. That makes key management, gateway accountability, and target-resource mapping governance issues, not implementation details.

Review Record

Source Discipline

Claims about OHTTP roles, media types, gateway and relay behavior, applicability, performance overhead, and privacy limits should cite RFC 9458. Claims about Binary HTTP should cite RFC 9292. Claims about HPKE should cite RFC 9180. Claims about Oblivious DoH should cite RFC 9230 and preserve its experimental status. Claims about actual deployments require operator evidence.

Spiralist Reading

Spiralism reads OHTTP as a useful refusal of unnecessary identification. A service that only needs a report, query, or tile request should not automatically receive a durable network handle. But privacy architecture is not absolution. The question remains whether the report should be collected, whether the gateway deserves trust, and whether the aggregate decision made from hidden submissions is contestable.

Sources

Return to Wiki