| fapi-http-signing-requirements | December 2024 | |
| Heenan | Standards Track | [Page] |
The Financial-grade API Standard provides a profile for OAuth 2.0 suitable for use in financial services and other similar higher risk scenarios. Ecosystems that have Financial-grade APIs often also have a requirement for the signing of HTTP requests or responses, this document covers the likely requirements and potential solutions.¶
This document is not an OIDF International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.¶
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.¶
The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.¶
The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.¶
The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings.¶
The Financial-grade API Standard provides a profile for OAuth 2.0 suitable for use in financial services and other similar higher risk scenarios. Ecosystems that have Financial-grade APIs often also have a requirement for the signing of HTTP requests or responses, this document covers the likely requirements and potential solutions.¶
For the purpose of this standard, the terms defined in [RFC6749], [RFC6750], [RFC7636], [OpenID] and OpenID Connect Client Initiated Backchannel Authentication Core apply.¶
API – Application Programming Interface¶
FAPI - Financial-grade API¶
HTTP – Hyper Text Transfer Protocol¶
OIDF - OpenID Foundation¶
REST – Representational State Transfer¶
TLS – Transport Layer Security¶
The section lists the likely requirements that influence the choice of HTTP signing method for ecosystems using Financial-grade APIs.¶
Generally ecosystems look to signing as a method for non-repudiation, meaning that the request or response can be retained by the parties and later used as prove that the message came from a party that had possession of the relevant private key.¶
Although TLS certificates can be used for instantaneous proof of key possesion, it is essentially impractical to retain all the necessary state such that it is possible to later independently verify key possession.¶
Any signing scheme must support straightforward serialization for later verification.¶
As the primary use-case for Financial-grade APIs is with JSON payloads, it is generally possible to make using of signing methods that are specific to JSON.¶
As Financial-grade APIs always use end-to-end encrypted TLS, it is generally possible to assume that the message body will not be tampered with (deliberately or accidentally) during transport.¶
However many middleware systems come with REST clients that will often parse JSON payloads automatically, making it difficult to reconstruct the original message body to verify the signature. It is often possible to workaround this (for example canonicalisation or base64 encoding of payloads), but the workarounds can reduce simplicity or robustness. It is often possible to access the raw payload by avoiding use of the REST client. In time this would be less of an issue, as the hope is that REST clients would implement support for widely used signature schemes.¶
In REST-like systems, the Request-URI, method and some HTTP headers often include important information that must be within the scope of the signature.¶
HTTP signing methods must be sufficiently well specified and straightforward to implement such that the signing library does not need to be aware of ecosystem specifics.¶
Systems must not have high rates of false negatives between difference implementations.¶
There are no additional security considerations beyond those in [FAPI1-PART1], [FAPI1-PART2], [FAPICIBA].¶
There are no additional privacy considerations beyond those in [FAPI1-PART1], [FAPI1-PART2], [FAPICIBA].¶
The following people contributed heavily towards this document:¶