The specification does not use OHTTP as-is with the intended setup. It uses the HPKE encryption portion of the OHTTP specification. In the typical OHTTP setup, the payload is opaque to the relay resource. In the TEE KV server case, the payload is opaque to the cloud infrastructure outside TEE.

The V2 specification could have used HPKE directly but practically OHTTP is used in other areas by Chrome, such as the K-anonymity service, so we decided to try to reuse.

So to answer the question, there is only one URL needed since the setup is simpler (the cloud infrastructure, equivalent to the relay resource, knows how to forward the request to the server inside TEE without URL).

The specification very clearly states that the payload is binary HTTP (RFC 9292), which requires a URL for requests. I don't know how to square that with what you are saying here. What am I missing?

In Server responsibilities and Separate gateway and target and some other places it was mentioned that the gateway resource and the target resource can be operated by the same server.

That is the case here. The KV server acts as both the gateway resource and the target resource. It decapsulates requests from the client, processes it and returns an encapsulated response.

Please correct me if I'm wrong - my understanding is that the binary HTTP URL is primarily for the gateway resource to forward the requests to the target resource if they are operated as separate entities, which is not the case here.

Yes, the same server can (and probably should) operate both resources. But these are separate resources, with separate identities. That these are operated by the same entity doesn't change that.

Pardon my ignorance - we are pretty much decapsulating the request and processing the request in the same piece of code. They don't practically have separate identities. As a result, the client only needs to know the URL to the KV server. The encapsulated request would get to the load balancer which forwards it to the KV server running inside TEE. And the KV server running inside TEE would decapsulate it, process the request and return an encapsulated response back to the client.

Perhaps we missed something or should have a better flow in which case I'm very happy to hear suggestions. Could you elaborate a bit on what the consideration behind your comment is?

You have established that you don't need the value, yes. That doesn't change the fact that the format requires it.

Do you know if there's some convention for what value to use in this case? Can it be something fixed so the IG does not need to be aware of?

You're on your own, I'm afraid. This particular application was never anticipated in the Oblivious HTTP design.