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 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 participants). 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 has 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.
Financial API consists of the following parts:
These parts are intended to be used with [RFC6749], [RFC6750], [RFC7636], and [OIDC].
Fintech is an area of future economic growth around the world and Fintech organizations need to improve the security of their operations and protect customer data. For example, it is a decades-old common practice of aggregation services to use screen scraping as a method to capture data and translate it to another service, such as usernames and passwords. This practice creates security gaps which require financial institutions to allow what ppears to be an automated attack against their applications and to maintain a whitelist of aggregators. A new draft standard, proposed by this workgroup would instead utilize an API model with structured data and a token model, such as OAuth [RFC6749, RFC6750].
The Financial API aims to provide specific implementation guidelines for financial services to adopt for use cases of online banking by developing a REST/JSON data model protected by specified OAuth profile that is secure.
This document is Part 1 of 5 that specifies the Financial API and it provides a profile of OAuth that is suitable to be used in the access of Read-Only financial data.
A higher level of security profile suitable for Read and Write Access APIs are provided in Part 2 and Part 3/4/5 provides the data schema for specific use cases.
The key words "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2. These key words are not used as dictionary terms such that any occurence of them shall be interpreted as key words and are not to be interpreted with their natural language meanings.
2. Normative References
3. Terms and Definitions
4. Symbols and Abbreviated Terms
5. Read-Only API Security Profile
5.2. Read-Only API Security Provisions
5.2.2. Authorization Server
5.2.3. Public Client
5.2.4. Confidential Client
6. Accessing Protected Resources
6.2. Read-Only Access Provisions
6.2.1. Protected Resources Provisions
6.2.2. Client Provisions
7. Security Considerations
7.1. TLS Considerations
7.2. Message Source Authentication Failure
7.3. Message Integrity Protection Failure
7.4. Message Containment Failure
7.4.1. Authorization Request and Response
7.4.2. Token Request and Response
7.4.3. Resource Request and Response
8. Privacy Considerations
8.1. Privacy By Design
8.2. Adhering to Privacy Principles
§ Authors' Addresses
This document specifies the method for an application to:
The following referenced documents are strongly recommended to be used in conjunction with this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
[RFC7230] - Hypertext Transfer Protocol -- HTTP/1.1 [RFC7230]: https://tools.ietf.org/html/rfc7230
[RFC4122] A Universally Unique IDentifier (UUID) URN Namespace [RFC4122]: https://tools.ietf.org/html/rfc4122
[RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: https://tools.ietf.org/html/rfc6749
[RFC6750] - The OAuth 2.0 Authorization Framework: Bearer Token Usage [RFC6750]: https://tools.ietf.org/html/rfc6750
[RFC7636] - Proof Key for Code Exchange by OAuth Public Clients [RFC7636]: https://tools.ietf.org/html/rfc7636
[RFC5246] - The Transport Layer Security (TLS) Protocol Version 1.2 [RFC5246]: https://tools.ietf.org/html/rfc5246
[RFC7525] - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [RFC7525]: https://tools.ietf.org/html/rfc7525
[RFC6125] - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) [RFC6125]: https://tools.ietf.org/html/rfc6125
[O2fNA] - OAuth 2.0 for Native Apps [O2fNA]: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-05
[RFC6819] - OAuth 2.0 Threat Model and Security Considerations [RFC6819]: https://tools.ietf.org/html/rfc6819
[OIDC] - OpenID Connect Core 1.0 incorporating errata set 1 [OIDC]: https://openid.net/specs/openid-connect-core-1_0.html
[OIDD] - OpenID Connect Discovery 1.0 incorporating errata set 1 [OIDD]: https://openid.net/specs/openid-connect-discovery-1_0.html
[OIDM] - OAuth 2.0 Multiple Response Type Encoding Practices [OIDM]: https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
[X.1254] - Entity Authentication Assurance Framework [X.1254]: https://www.itu.int/rec/T-REC-X.1254
[MTLS] - Mutual TLS Profile for OAuth 2.0 [MTLS]: https://tools.ietf.org/html/draft-ietf-oauth-mtls
For the purpose of this document, the terms defined in [RFC6749], [RFC6750], [RFC7636], [OpenID Connect Core][OIDC] apply.
API – Application Programming Interface
CSRF - Cross Site Request Forgery
FAPI - Financial API
FI – Financial Institution
HTTP – Hyper Text Transfer Protocol
REST – Representational State Transfer
TLS – Transport Layer Security
The OIDF Financial API (FAPI) is a REST API that provides JSON data representing account and transaction related data. These APIs are protected by the OAuth 2.0 Authorization Framework that consists of [RFC6749], [RFC6750], [RFC7636], and other specifications.
Read-only access is generally viewed to pose a lower risk than the Write access and as such, the characteristics required of the tokens and method to obtain tokens are explained separately.
Read-Only access is a lower risk scenario compared to the Write access; therefore the protection level can also be lower. However, since the FAPI can provide potentially sensitive information, it requires more protection level than a basic [RFC6749] requires.
As a profile of the OAuth 2.0 Authorization Framework, this document mandates the following to the Read-Only API of the FAPI.
The Authorization Server
A Public Client
In addition to the provisions for a Public Client, except for [RFC7636] support, a Confidential Client
The FAPI endpoints are OAuth 2.0 protected resource endpoints that return financial information for the resource owner associated with the submitted access token.
The resource server with the FAPI endpoints
The client supporting this document
Since potentially sensitive and confidential information is being exchanged, all interactions shall be encrypted with TLS (HTTPS) in accordance with the recommendations in [RFC7525]. TLS version 1.2 or later shall be used for all communications.
Authorization request and response are not authenticated. For higher risk scenarios, they should be authenticated. See Part 2, which uses request object to achieve the message source authentication.
The authorization request does not have message integrity protection and hence request tampering and parameter injection are possible. Where such protection is desired, Part 2 should be used.
The response is integrity protected when the ID Token is returned from the authorization endpoint.
In this document, the authorization request is not encrypted. Thus, it is possible to leak the information contained if the web browser is compromised.
Authorization response can be encrypted as ID Token can be encrypted.
It is possible to leak the information through the logs if the parameters were recorded in the logs and the access to the logs are compromised. Strict access control to the logs in such cases should be enforced.
It is possible to leak information through the logs if the parameters were recorded in the logs and the access to the logs are compromised. Strict access control to the logs in such cases should be enforced.
Care should be taken so that the sensitive data will not be leaked through the referrer.
If the access token is a bearer token, it is possible to exercise the stolen token. Since the access token can be used against multiple URIs, the risk of leaking is much larger than the refresh token, which is used only against the token endpoint. Thus, the lifetime of the access token should be much shorter than that of the refresh token. Refer to section 16.18 of [OIDC] for more discussion on the lifetimes of access and refresh tokens.
** NOTE ** The following only has a boiler plate text specifying the general principles. More specific text will be added towards the Final specification.
Stakeholders should follow the privacy principles of ISO/IEC 29100. In particular:
Following people contributed to this document:
|Nomura Research Institute, Ltd.|