Open Banking
The foundations for the remarkable global success of Open Banking over the past 5 years were laid by the creation and implementation of a set of internationally-agreed standards, interoperable protocols and financial-grade APIs. Open Banking enables Business-to-Customer relationships that allow authorised third party applications and services to securely access and process personal financial information maintained by the customer’s bank or other financial institution.
Development of these foundational building blocks has not stopped and the OpenID Foundation, with others, are forging ahead with a number of initiatives to enhance interoperability between global financial institutions. As a major player in GAIN, OIDF will be closely involved in the 2022 Proof of Concept, which is intended to demonstrate that these interoperability enhancements provide an effective, secure and global identity layer for the Internet.
Below is an illustration of how the OpenID Connect suite is underpinned by a range of protocols that together provide a stable and resilient security foundation.
The following tables provide more detailed information about the specifications, standards, protocols and APIs that enable OpenID Connect and will provide enhanced interoperability within the GAIN ecosystem.
- Those standards and protocols that provide a secure and resilient underpinning for OIDC;
- Those specifications that deliver the complete OIDC capability; and
- Those specifications, protocols and APIs than improve interoperability.
Protocol | Developed by | Purpose |
OAuth allows a User to grant access to their private resources on one site (which is called the Service Provider), to another site (called Consumer). While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access to your resources without sharing your identity at all (or its secret parts). | ||
JSON (JavaScript Object Notation) is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects. Derived from JavaScript, it is a common language-independent data format with diverse uses in electronic data interchange, including that of web applications with servers. JSON Web Tokens (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON object that is used as the payload of a JWS structure or as the plaintext of a JWE structure, enabling claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. | ||
JSON Web Signature (JWS) represents content secured with digital signatures or MACs using JSON based data structures that are encoded using base64url encoding. | ||
JSON Web Encryption (JWE) represents encrypted content using JSON based data structures and provides cryptographic mechanisms that encrypt and provide integrity protection for an arbitrary sequence of octets. | ||
A JSON Web Key (JWK) is a JSON data structure that represents a cryptographic key. This specification also defines a JSON Web Key Set (JWK Set), a JSON data structure that represents a set of JWKs. | ||
JSON Web Algorithms (JWA) registers a range of cryptographic algorithms and identifiers to be used with the JWS, JWE, and JWK specifications, including SHA-256/512, ECDSA & HMAC, as defined in NIST & FIPS documentation. | ||
The WebFinger protocol is used to discover information about people or other entities on the Internet that are identified by a Uniform Resource Identifier using standard HTTP methods over a secure transport. A WebFinger resource returns a JSON object describing the entity that is queried, which is referred to as the JSON Resource Descriptor (JRD). |
Table 1: Protocols that underpin OpenID Connect
Specification | Developed by | Purpose |
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. Core OIDC functionality is authentication built on top of OAuth's authorisation and the use of Claims to communicate information about the End-User and the security and privacy considerations for using OIDC. OIDC Core is the minimal implementation for certification; there are optional add-ons (below), depending on the use case. | ||
OIDC Discovery (Optional) | This specification defines a mechanism for an OIDC Relying Party to discover the End-User's OID Provider (OP) and obtain information needed to interact with it, including its OAuth 2.0 endpoint locations. In order for an OIDC Relying Party to utilize OIDC services for an End-User, the RP needs to know where the OID Provider is. OIDC uses WebFinger to locate the OID Provider for an End-User. Once the OpenID Provider has been identified, the configuration information for that OP is retrieved as a JSON document, including its OAuth 2.0 endpoint locations. | |
OIDC Dynamic Client Registration (Optional) | In order for an OID Relying Party to utilize OIDC services for an End-User, the RP needs to register with the OID Provider (OP) to provide the OP information about itself and to obtain information needed to use it, including an OAuth 2.0 Client ID. This specification describes how an RP can register with an OP, and how registration information for the RP can be retrieved. | |
OIDC Session Management (Optional) | This specification complements the OIDC Core by defining how to monitor the End-User's login status at the OID Provider (OP) on an ongoing basis so that the Relying Party (RP) can log out an End-User who has logged out of the OP. Both this specification and the OIDC Front-Channel Logout use front-channel communication, which communicate logout requests from the OP to RPs via the User Agent. In contrast, the OIDC Back-Channel Logout uses direct back-channel communication between the OP and RPs being logged out. The OIDC RP-Initiated Logout complements these specifications by defining a mechanism for a RP to request that an OP log out the End-User. | |
OIDC Form Post Response Mode (Optional) | This specification defines the Form Post Response Mode. In this mode, Authorization Response parameters are encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format. |
Table 2: Listing of relevant OIDC specifications
Specification | Status | Developed by | Purpose |
Financial-grade API 1.0 | Published |  | Based on OAuth 2.0 and OpenID Connect suite of standards, but with less optionality and the requirement to use modern security best practices. Exhaustive conformance tests to allow implementers to ensure their software is secure and interoperable |
Financial-grade API 2.0 | Implementer's draft | With a broader scope than v1.0 FAPI 2.0 aims for complete interoperability at the interface between client and authorization server as well as interoperable security mechanisms at the interface between client and resource server. It also has a more clearly defined attacker model to aid formal analysis, includes Baseline Security Profile & Attacker Model. Additional work by this WG includes FAPI2.0: Advanced Security Profile, Grant Management for OAuth 2.0 & Simple HTTP Message Integrity Protocol. | |
Implementer's draft | The iGov Working Group is developing a security and privacy profile of the OpenID Connect specifications that allow users to authenticate and share consented attribute information with public sector services across the globe. The resulting profile will enable standardized integration with public sector relying parties in multiple jurisdictions. The profile will be applicable to, but not exclusively targeted at, identity broker-based implementations. | ||
Implementers draft | The eKYC and Identity Assurance (eKYC & IDA) WG is developing extensions to OIDC that will standardise the communication of assured identity information, i.e. verified claims and information about how the verification was done and how the respective claims are maintained. The specification also defines flexible data schemas for request and response as well as communicating information relating to the assured identity data including: - Which data are required | ||
Implementer's draft | MODRNA Authentication Profile 1.0 allows RPs to use high quality authentication methods, which can be provided by Mobile Network Operators (MNO). However a RP must be able to describe its demands for an authentication request and it must be able to do this in an interoperable way. The Profile will specify how RP's request a certain level of assurance for the authentication. Additionally, it will specify an encrypted login hint token to allow for the transport of user identifiers to the OP in a privacy preserving fashion. MODRNA will support GSMA technical development of Mobile Connect and enable Mobile Network Operators (MNOs) to become Identity Providers. | ||
Implementer's draft | This specification extends OIDC with the concept of a Self-Issued OpenID Provider (Self-Issued OP), an OP which is within the End-User's local control. End-Users can leverage Self-Issued OPs to authenticate themselves and present claims directly to the RPs. This allows users to interact with RPs directly, without relying on third-party providers or requiring the End-User to operate their own hosted OP infrastructure. | ||
Implementer's draft | This specification extends OIDC with support for presentation of claims via W3C Verifiable Credentials. This allows existing OpenID Connect RPs to extend their reach towards claims sources asserting claims in this format. It also allows new applications built using Verifiable Credentials to utilize OpenID Connect as integration and interoperability layer towards credential holders. Verifiable Presentations are used to present claims along with cryptographic proofs of the link between presenter and subject of the verifiable credentials it contains. |
Table 3: OIDC specifications in development
With its huge ‘install base’, OIDC is already used by millions of websites for user authorisation & authentication at the “front door”. Indeed, while a vanishingly small portion of internet users have ever heard of OIDC, it is the nuts and bolts of the most universal and familiar user flow of the contemporary commercial web, including online banking and government services.
The latest development of OIDC– Self Issued OIDC Provider, enables greater integration between OIDC and the W3C DID standard and seeks to address the problem of achieving critical mass in 3 areas – users/holders, IDPs/Issuers and RPs/Verifiers.
The vision of DID-SIOP is a way of bringing decentralised identity concepts into alignment with the ideas of “self-issued” portable identity that the original OpenID innovators had.