Targeting key hash in request headers for routing and session affinity

Context

At KubeCon EU 2026, the OFREP discussion (recap) identified a challenge with routing and session affinity for OFREP requests.

Problem

OFREP uses POST requests with the evaluation context in the body. This makes load balancing and session affinity harder because routing decisions require parsing the request body. The etag header exists but isn't well suited for routing.

The targeting key is the natural routing key, but it often contains PII (emails, user IDs, etc.) and shouldn't be sent in plaintext as a header.

Proposal

Add a hash of the targeting key as a new request header in the OFREP spec. This would allow:

• Load balancers to route requests to consistent backends without body parsing
• Session affinity for stateful evaluation scenarios
• No PII exposure since only a hash is transmitted

The hashing should happen in the OFREP provider before the request is sent.

An ADR should be written to document the decision, including:

• Which hashing algorithm to use
• Header name convention
• Whether this is required or optional

Related

• #39: OFREP 1.0 roadmap

Start by reviewing the OFREP 1.0 roadmap in #39 and the KubeCon EU 2026 recap linked in the issue. Define the hash algorithm, header naming convention, and whether the header is required or optional, then document the decision in an ADR.