Consider mentioning Oblivious HTTP in the guidance documents related to did:webvh to mitigate "Phone Home" data collection

[swcurran]

Oblivious HTTP (OHTTP) is standardized and minimized TOR-like capability where a Client sends a request to a Server through an OHTTP Relay to a Gateway, and gets the response back along the reverse path. Neither the Gateway nor the Server learn who sent the request, and the Relay doesn't know where the request went. The request/response are encrypted using TLS between the client and server -- hidden from the Relay and Gateway.

In practice, OHTTP is used for sessionless queries, such as for the Google Safe Browsing List and Firefox's Browser Telemetry data collection. A did:webvh server or watchers are good candidates for this capability. Here is a flow of how that might work with did:webvh

sequenceDiagram
    participant Client as Client (Wallet / Resolver / Verifier)
    participant Relay as OHTTP Relay (e.g., Fastly)
    participant Gateway as OHTTP Gateway (Ecosystem-Operated)
    participant Server as did:webvh Server / Watcher

    Client->>Relay: Encapsulated OHTTP Request<br/>(encrypted with Gateway’s key)
    Relay->>Gateway: Forward opaque blob
    Gateway->>Server: Decapsulated HTTP Request<br/>(to did:webvh server or watcher)
    Server-->>Gateway: HTTP Response
    Gateway-->>Relay: Encapsulated OHTTP Response
    Relay-->>Client: Forward opaque blob (encrypted response)

    note over Relay,Gateway: Relay sees client IP but not content.<br/>Gateway sees content but not client IP.

Experiment with Oblivious HTTP and then consider adding a note about using it to either the spec or the information site as a mitigation method for "phone home" usage patterns when using did:webvh.