A server returns an InputRequiredResult whose requestState records that the user approved a refund. When the client retries, the server reads that flag from requestState and issues the refund. What must the server do?
Select an answer to reveal the explanation.
Short Explanation
requestState is a sealed envelope you hand to a courier you don't fully trust. If the approval inside decides whether money moves, you'd better seal it so tampering shows. The trap is thinking "clients mustn't modify it" means they can't.
Full Explanation
In multi round-trip requests a server may include requestState in an InputRequiredResult, an opaque string the client must echo back exactly on the retried request. Because it passes through the client, the specification says servers must treat requestState as attacker-controlled input, and if it influences authorization, resource access or business logic, servers must protect its integrity, for example with HMAC or AEAD. A refund approval is business logic with financial impact, so an unprotected flag would let a malicious or compromised client grant itself approval. Trusting it because clients must not modify it fails by concept: that rule describes correct clients, while the security requirement exists precisely for clients that misbehave. Base64 encoding fails because encoding is reversible formatting, not integrity protection; anyone can decode, change and re-encode the value. Asking the client to verify the signature fails because clients must not inspect, parse or make assumptions about requestState, and in any case a check performed by the party being guarded against protects nothing. Exam caveat: integrity protection alone does not stop replay of a valid state; servers should also bind the principal, a short expiry and the originating request. Operational check: flip one character in a captured requestState, retry the call, and confirm the server rejects the request instead of issuing the refund.