A server already integrity-protects its requestState, but a reviewer worries that a valid, captured value could be replayed later or by another user. What does the specification recommend including inside the protected payload?
Select an answer to reveal the explanation.
Short Explanation
A signed ticket still works for whoever picks it up off the floor, unless your name, a date and the seat are printed on it. Bind the state to the user, give it a short life, and tie it to the exact request. The trap is trusting the JSON-RPC id to stop replays.
Full Explanation
Integrity protection proves a requestState came from the server unmodified, but a valid state can still be presented again. To prevent replay, the specification says servers should include inside the integrity-protected payload, and verify on receipt, the authenticated principal, rejecting state presented by a different principal; a short expiry, rejecting state presented after it lapses; and an identifier for the originating request, such as the method name and a digest of its salient parameters, rejecting state presented on a request that does not match. These measures bound the replay window and prevent cross-user and cross-request reuse; servers that need strictly single use must also track consumption server-side. Relying on new JSON-RPC ids fails because ids are chosen by the client, and an attacker replaying state simply sends it with a fresh id; ids correlate responses, they do not authenticate. Including client capabilities fails by concept: capabilities are self-declared, easily copied, and say nothing about who is calling or which operation the state belongs to. Using Mcp-Session-Id fails because protocol sessions and that header are legacy; revision 2026-07-28 is stateless. Exam caveat: identify the principal from verified credentials such as the token's subject, not from clientInfo. Operational check: present a captured state under a second user's token and after its expiry, and confirm both attempts are rejected.