| fapi-2-message-signing | March 2023 | |
| Fett & Tonge | Standards Track | [Page] |
The OpenID Foundation (OIDF) promotes, protects and nurtures the OpenID community and technologies. As a non-profit international standardizing body, it is comprised by over 160 participating entities (workgroup participant). The work of preparing implementer drafts and final international standards is carried out through OIDF workgroups in accordance with the OpenID Process. Participants interested in a subject for which a workgroup has been established have the right to be represented in that workgroup. International organizations, governmental and non-governmental, in liaison with OIDF, also take part in the work. OIDF collaborates closely with other standardizing bodies in the related fields.¶
Final drafts adopted by the Workgroup through consensus are circulated publicly for the public review for 60 days and for the OIDF members for voting. Publication as an OIDF Standard requires approval by at least 50% of the members casting a vote. There is a possibility that some of the elements of this document may be the subject to patent rights. OIDF shall not be held responsible for identifying any or all such patent rights.¶
OIDF FAPI 2.0 is an API security profile based on the OAuth 2.0 Authorization Framework [RFC6749]. This Message Signing Profile is part of the FAPI 2.0 family of specifications with a focus on providing interoperable support for non-repudiation across OAuth 2.0 based requests and responses.¶
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 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.¶
This document specifies the methods for Clients, Authorization Servers and Resource Servers to sign and verify messages.¶
See section 8 for normative references.¶
For the purpose of this document, the terms defined in [RFC6749], [RFC6750], [RFC7636], [OIDC] and ISO29100 apply.¶
API - Application Programming Interface¶
HTTP - Hyper Text Transfer Protocol¶
REST - Representational State Transfer¶
TLS - Transport Layer Security¶
URI - Uniform Resource Identifier¶
OIDF FAPI 2.0 is an API security profile based on the OAuth 2.0 Authorization Framework [RFC6749]. This Message Signing Profile aims to reach the security goals laid out in the Attacker Model [attackermodel] plus the non-repudiation goals listed below.¶
All provisions of the [FAPI2_Security_Profile_ID2] apply to the Message Signing Profile as well, with the extensions described in the following.¶
In addition to the technologies used in the [FAPI2_Security_Profile_ID2], the following standards are used in this profile:¶
OAuth 2.0 JWT Secured Authorization Request (JAR) [RFC9101] for signing authorization requests¶
JWT Secured Authorization Response Mode for OAuth 2.0 [JARM] for signing authorization responses¶
OAuth 2.0 Token Introspection [RFC7662] with [I-D.ietf-oauth-jwt-introspection-response] for signing introspection responses¶
HTTP Message Signatures [I-D.ietf-httpbis-message-signatures] and Digest Fields [I-D.ietf-httpbis-digest-headers] for signing HTTP requests to and responses from Resource Servers.¶
We understand that some ecosystems may only desire to implement 1 or 2 of the above 3, it is therefore anticipated that a piece of software will be able to conform to each of the methods separately, i.e. there will be separate test options for each of the following:¶
Beyond what is captured by the security goals and the attacker model in [attackermodel], parties could try to deny having sent a particular message, for example, a payment request. For this purpose, non-repudiation is needed.¶
In the context of this specification, non-repudiation refers to the assurance that the owner of a signature key pair that was capable of generating an existing signature corresponding to certain data cannot convincingly deny having signed the data ([NIST.SP.800-133]).¶
This is usually achieved by providing application-level signatures that can be stored together with the payload and meaningful metadata of a request or response.¶
The following messages are affected by this specification:¶
To support non-repudiation for NR4, Introspection Responses can be signed.¶
Clients implementing FAPI2 introspection response signing¶
shall request signed token introspection responses according to [I-D.ietf-oauth-jwt-introspection-response]; and¶
shall verify the signed token introspection responses.¶
To support non-repudiation for NR5 and NR6, HTTP requests and responses can be signed.¶
A future version of this profile expects to support HTTP Message Signing using the HTTP Message Signatures specification being developed by the IETF HTTP Working Group.¶
Some ecosystems are choosing to require clients accessing their endpoints to supply a TLS client certificate at
endpoints that would not otherwise require a TLS client certificate (for example, the PAR endpoint when using
private_key_jwt authentication).¶
This is outside of the scope of both [RFC8705] and the FAPI standards, however in the interests of interoperability we
state that when using TLS as a transport level protection in this manner, authorization servers should expect clients to
call the endpoints located in the root of the server metadata, and not those found in mtls_endpoint_aliases.¶
In addition to the privacy considerations detailed in [FAPI2_Security_Profile_ID2] implementers should consider the privacy implications of storing messages for the purpose of non-repudiation.¶
Such messages may well contain personally identifiable information and implementers should evaluate whether such messages need to be stored. If they are stored then adequate access controls must be put in place to protect that data. Such controls should follow data minimisation principles and ensure that there are tamper-proof audit logs.¶
This specification was developed by the OpenID FAPI Working Group.¶
We would like to thank Takahiko Kawasaki, Filip Skokan, Nat Sakimura, Dima Postnikov, Joseph Heenan, Brian Campbell, Ralph Bragg, Justin Richer and Lukasz Jaromin for their valuable feedback and contributions that helped to evolve this specification.¶
Copyright (c) 2023 The OpenID Foundation.¶
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.¶