Defining HTTP signature validation (RFC 9421) as a precondition extension to allow 412 as the response code

Hello All,

I am working with a team that is looking to implement HTTP Message signatures and validation within our products. I have not read the entire history of how this specification evolved over time and therefore do not know if this topic was previously discussed. If it was and not acted upon, I apologize up front.

After reviewing the RFC I find the error reporting recommendations for using a status code of 401 is not in-line with [HTTP] RFC 9110 Section 15.5.2 401 Unauthorized. Additionally, the status code 403 does not make sense when requests have been made with credentials being exchanged. The 403 response can be interpreted by intermediary network components, as in ZTNA or identity-aware proxies, as an indicator by the origin/target server to cease all access to this session. If not the network components then the application itself may take action when a 403 is the status response and perform an absolute session termination (SLO).

My interpretation of RFC 9421 has me regarding signature validation as a higher class of preconditions to the HTTP message, much the same as If-Modified-Since, If-Match, etc. But these preconditions are applied before further processing the HTTP message and after any TLS preconditions have been met (SERVER HELLO Certificate Validation, SNI, mTLS, ALPN, etc).  In the Tomcat world this could be implemented at a valve level, to be executed before a single nibble of application code is run.

Prereq:  the server or client has been configured with a valve/filter/servlet/JavaScript function to recognize and operate on all signature components.

If the signature validation is indeed a super class of preconditions that must be validated. And when the signature components are found within the header section of the HTTP message then doesn’t it make sense to use the 412 Precondition Failed as the primary status response from signature validation failure or exception? The 412 response per [HTTP] allows for as much or as little details as necessary in the response body to provide information to the end user.

Best Regards,

Kevin J. Dyer
AMERICAS User Success Engineering Director, Infrastructure and Security
kevin.dyer@3ds.com

Next OOO –
------------------------------------------------------------------------------------------------------------------------------------
Office:      +1 781 810 3582
Mobile:    +1 978 549 0971

Dassault Systèmes | www.3ds.com | The 3DEXPERIENCE
Dassault Systèmes | 175 Wyman St |Waltham, MA  02451-1223 | United States


This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer https://www.3ds.com/privacy-policy/contact/