Skip to content

Add OHTTP config support to TEE registry and endpoints#296

Merged
adambalogh merged 3 commits into
mainfrom
claude/keen-thompson-leqpxk
Jun 10, 2026
Merged

Add OHTTP config support to TEE registry and endpoints#296
adambalogh merged 3 commits into
mainfrom
claude/keen-thompson-leqpxk

Conversation

@adambalogh

Copy link
Copy Markdown
Collaborator

Summary

Extends the TEE registry integration to include OHTTP/HPKE key material, enabling clients to encrypt Oblivious HTTP requests to TEEs. The TEEEndpoint now carries both the direct x402 connection path (endpoint + TLS cert) and the oblivious-HTTP relay path (OHTTP config + signing key).

Key Changes

  • ABI Update: Reformatted TEERegistry.abi with consistent indentation and added OhttpConfig struct to TEEInfo output (keyId, kemId, kdfId, aeadId, publicKey, keyConfig, registeredAt)

  • New OhttpConfig NamedTuple: Mirrors the on-chain struct with HPKE key material (X25519 public key, KEM/KDF/AEAD algorithm IDs, serialized key config blob)

  • Enhanced TEEInfo NamedTuple: Now includes the ohttp_config field to carry the full registry record

  • Enhanced TEEEndpoint Dataclass:

    • Added signing_public_key_der (RSA public key for signature verification)
    • Added optional ohttp_config field
    • Updated docstring to document both trust paths (direct x402 and oblivious-HTTP relay)
  • New Registry Methods:

    • get_llm_tee_ohttp_config(): Returns a random active LLM proxy TEE guaranteed to have OHTTP config (non-empty X25519 public key)
    • _parse_ohttp_config(): Helper to safely coerce decoded on-chain tuples into OhttpConfig objects, returning None for TEEs without OHTTP material
  • Updated get_active_tees_by_type(): Now populates signing_public_key_der and ohttp_config fields on returned TEEEndpoint objects

  • Test Updates: Extended _make_tee_info() helper to include the full ohttpConfig sub-tuple and added assertions verifying the new fields are correctly parsed

Implementation Details

  • OHTTP config parsing is defensive: returns None if the tuple is malformed or the public key is empty (indicating no OHTTP support)
  • The get_llm_tee_ohttp_config() method explicitly checks for 32-byte X25519 keys to ensure usability
  • Maintains backward compatibility: existing code using get_llm_tee() continues to work; new code can opt into OHTTP via the new method

https://claude.ai/code/session_01L2gvK4aHX1bs3EQ61zxdkT

claude added 2 commits June 10, 2026 19:48
The bundled TEERegistry ABI and TEEInfo stopped at endpoint + TLS cert, so the
registry read was partial. Read the whole on-chain record:

- ABI: add the ohttpConfig struct (keyId/kemId/kdfId/aeadId/publicKey/keyConfig)
  to getActiveTEEs and getTEE outputs.
- TEEInfo: add the ohttp_config field; new OhttpConfig NamedTuple mirrors it.
- TEEEndpoint: carry signing_public_key_der + ohttp_config (back-compatible
  defaults), so callers can encrypt OHTTP requests AND verify TEE signatures,
  not just dial the endpoint.
- get_llm_tee_ohttp_config(): pick a random active LLM-proxy TEE that advertises
  a usable HPKE config.
- tests: full-struct fixture + OHTTP-field assertions.

https://claude.ai/code/session_01L2gvK4aHX1bs3EQ61zxdkT
`make check` (mypy) flagged `_parse_ohttp_config(raw: object)` as not
indexable. Type the decoded on-chain tuple as `Sequence[Any]`.

https://claude.ai/code/session_01L2gvK4aHX1bs3EQ61zxdkT
@adambalogh adambalogh marked this pull request as ready for review June 10, 2026 19:52
@adambalogh adambalogh requested a review from Copilot June 10, 2026 19:56

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR extends the Python SDK’s on-chain TEE registry integration to surface Oblivious HTTP (OHTTP)/HPKE configuration material alongside existing endpoint + pinned TLS certificate data, enabling clients to choose between direct connections and an OHTTP relay path.

Changes:

  • Added OhttpConfig and expanded TEEInfo/TEEEndpoint parsing to carry OHTTP config + signing public key material from the registry.
  • Introduced get_llm_tee_ohttp_config() to select only LLM-proxy TEEs with usable HPKE public keys.
  • Updated the registry ABI and extended unit tests to assert the new parsed fields.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File Description
src/opengradient/client/tee_registry.py Adds OHTTP structs/parsing, enriches TEEEndpoint, and introduces OHTTP-specific selection API.
tests/tee_registry_test.py Updates mocked TEEInfo tuples and assertions for new endpoint fields.
src/opengradient/abi/TEERegistry.abi Reformats ABI and adds the OhttpConfig struct to relevant outputs.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/opengradient/client/tee_registry.py Outdated
Comment thread tests/tee_registry_test.py
- TEEInfo.ohttp_config was annotated OhttpConfig but TEEInfo(*raw) assigns
  the raw decoded web3 sub-tuple, so the runtime value is a Sequence, not a
  parsed OhttpConfig. Relax the annotation to Sequence[Any] and document that
  the parsed/typed form lives on TEEEndpoint.ohttp_config.
- Add tests covering the new branches: _parse_ohttp_config returns None on an
  empty HPKE public key (and on a malformed tuple), get_active_tees_by_type
  surfaces ohttp_config=None when no HPKE key is present, and
  get_llm_tee_ohttp_config filters out TEEs without usable HPKE material
  (returning None when none qualify).
@adambalogh adambalogh merged commit d5d302c into main Jun 10, 2026
9 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants