Nonrepudiation assures that, once a request’s origin is verified, the originating actor cannot credibly deny sending it. It extends request authentication beyond origin and integrity: a third party must also be able to distinguish a genuine request from one forged by the API server. section 30.1 section 30.1.3
The requirement rules out shared credentials. With a symmetric secret, both the user and API server can produce evidence that appears to authenticate the user, so an outside verifier cannot tell whether the server forged the request. Asymmetric credentials separate signing from verification: the user alone holds the signing credential, while others verify with a different credential. section 30.1.3
A request reviewed by a third party
Imagine a request claiming to come from user 1234. A digital signature lets a third party verify that user 1234 originated the request without relying on a shared secret that the API server could misuse. If the request also includes the HTTP method, path, host, and selected body content in its fingerprint, changes to the signed request become detectable. section 30.1.3 section 30.6
Choose nonrepudiation deliberately rather than treating it as a default requirement:
- Prefer digitally signed requests when third parties may execute them later or when sensitive records, such as health or financial data, may be audited. section 30.4
- Consider HMAC with a shared secret or short-lived access tokens such as OAuth 2.0 when nonrepudiation is only a nice-to-have and transport security is trusted. section 30.4
- Account for the greater computational cost of asymmetric cryptography when evaluating performance-sensitive designs. section 30.4
