Clarify request_id_ref semantics and ACS-Core HKDF parameters

[shivang-sec]

While testing the AGT reference implementation against the v0.1.0 specification, I found two specification details where clearer normative semantics would improve interoperability.

1. steps/toolCallResult.payload.request_id_ref

The v0.1.0 schema describes this optional field as linking a result to its originating toolCallRequest, but does not currently specify the expected behavior when the reference cannot be resolved.

In testing, I submitted an otherwise valid steps/toolCallResult with a request_id_ref UUID that had never appeared as a toolCallRequest in the session. The reference Guardian accepted it in the same way as the equivalent result without request_id_ref.

The proposed clarification is that when request_id_ref is present, a Guardian SHOULD resolve it against the session's recorded toolCallRequests. If the reference is unresolvable, the condition MUST be recorded through the applicable audit event or reason code. Whether an unresolvable reference results in allow or deny remains vendor policy.

The spoof test described above can serve as a conformance/behavioral test for this requirement.

2. ACS-Core HKDF parameters

Section 10 specifies HMAC-SHA256 with a per-session key derived using HKDF from deployment-provided input keying material and session_id, but does not currently specify the derivation parameters needed for deterministic interoperability.

The reference implementation currently uses HKDF-SHA256 with an empty salt, UTF-8 session_id as info, and a 32-byte output.

The proposed clarification is to make the reference implementation's v0.1.0 derivation parameters normative: HKDF-SHA256, empty salt, UTF-8 session_id as info, and 32-byte output.

Deployment-defined input keying material and key_id resolution would remain deployment-defined.

These are intended as specification/interoperability clarifications rather than changes to the wire fields themselves.

I'd appreciate feedback on the proposed normative wording and whether these two clarifications should be handled together.