The problem
The v0.1.0 specification leaves two interoperability-related behaviors underspecified.
First, steps/toolCallResult.payload.request_id_ref is described as linking a result to its originating toolCallRequest, but the specification does not define the expected behavior when the reference cannot be resolved against the session's recorded toolCallRequests.
During testing of the AGT reference implementation, 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.
Second, Section 10 specifies that ACS-Core uses HMAC-SHA256 with a per-session key derived using HKDF from deployment-provided input keying material and session_id, but does not 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. Without normative parameters, independent implementations can derive different keys from the same input keying material and therefore be unable to verify each other's ACS-Core signatures.
Why the wire has to carry it
No new wire fields are proposed.
For request_id_ref, the existing field carries the correlation between a tool result and its originating toolCallRequest. Defining how that reference should be resolved and how an unresolvable reference must be recorded gives independent implementations consistent semantics for an existing wire field.
For ACS-Core signatures, the existing cryptographic contract requires a per-session HMAC key. Normative HKDF parameters are necessary so independent implementations can derive the same key from the same deployment-provided input keying material and session_id. Without deterministic derivation parameters, the existing HMAC-SHA256 wire contract cannot provide reliable cross-implementation interoperability.
Which constituencies this affects
Alternatives considered
For request_id_ref, one alternative is to leave the field entirely informational. This would avoid defining resolution behavior, but would leave the existing "Links to the originating toolCallRequest" description without consistent semantics when the reference is present but cannot be resolved.
Another alternative is to require every unresolvable request_id_ref to result in denial. This would make the correlation rule unnecessarily prescriptive and couple the ACS wire contract to a particular authorization policy. Keeping the final disposition vendor-defined preserves that separation while still requiring the condition to be recorded.
For HKDF, one alternative is to leave the derivation parameters deployment-defined. This provides flexibility, but independent implementations could derive different per-session keys from the same input keying material and therefore fail to interoperate.
Another alternative is to document the reference implementation's current HKDF behavior without making it normative. This would describe the current implementation but would not establish a deterministic cryptographic interoperability profile for independent ACS-Core implementations.
No new wire fields are proposed by this change.
Discussion link
#117
Current Priority Scope
Feeds conformance evidence
The problem
The v0.1.0 specification leaves two interoperability-related behaviors underspecified.
First, steps/toolCallResult.payload.request_id_ref is described as linking a result to its originating toolCallRequest, but the specification does not define the expected behavior when the reference cannot be resolved against the session's recorded toolCallRequests.
During testing of the AGT reference implementation, 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.
Second, Section 10 specifies that ACS-Core uses HMAC-SHA256 with a per-session key derived using HKDF from deployment-provided input keying material and session_id, but does not 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. Without normative parameters, independent implementations can derive different keys from the same input keying material and therefore be unable to verify each other's ACS-Core signatures.
Why the wire has to carry it
No new wire fields are proposed.
For request_id_ref, the existing field carries the correlation between a tool result and its originating toolCallRequest. Defining how that reference should be resolved and how an unresolvable reference must be recorded gives independent implementations consistent semantics for an existing wire field.
For ACS-Core signatures, the existing cryptographic contract requires a per-session HMAC key. Normative HKDF parameters are necessary so independent implementations can derive the same key from the same deployment-provided input keying material and session_id. Without deterministic derivation parameters, the existing HMAC-SHA256 wire contract cannot provide reliable cross-implementation interoperability.
Which constituencies this affects
Alternatives considered
For request_id_ref, one alternative is to leave the field entirely informational. This would avoid defining resolution behavior, but would leave the existing "Links to the originating toolCallRequest" description without consistent semantics when the reference is present but cannot be resolved.
Another alternative is to require every unresolvable request_id_ref to result in denial. This would make the correlation rule unnecessarily prescriptive and couple the ACS wire contract to a particular authorization policy. Keeping the final disposition vendor-defined preserves that separation while still requiring the condition to be recorded.
For HKDF, one alternative is to leave the derivation parameters deployment-defined. This provides flexibility, but independent implementations could derive different per-session keys from the same input keying material and therefore fail to interoperate.
Another alternative is to document the reference implementation's current HKDF behavior without making it normative. This would describe the current implementation but would not establish a deterministic cryptographic interoperability profile for independent ACS-Core implementations.
No new wire fields are proposed by this change.
Discussion link
#117
Current Priority Scope
Feeds conformance evidence