Ecosystem Architecture

This document gives an architectural overview of the ecosystem. It is relevant for all parties who are interested in and like to understand the basic concepts, the involved parties and their interplay. Readers may be solution architects or software developers who are in charge of implementing services that are supposed to participate in the ecosystem. Such a service may act in one of the following roles: Identity Provider (IDP), Service Provider (SP) or Relying Party (RP) such as online shops, telecom or insurance companies.

The document focuses on base concepts of and the operational and technical interfaces which have to be invoked or provided by partners who like to become part of . The document describes the concept of the ecosystem. Additional documents provide more information on specific aspects of .

introduces a scheme that enables bank customers to use their online banking accounts for conducting various digital transactions, such as login, registration, identification, payment and signing, with web sites or apps (in general named Relying Parties or RPs) and service providers (SP) that provide enhanced services to RPs via APIs.

The user’s bank ideally acts as her core Service Provider (designated as IDP). These ‚Active banks‘ continue to hold the user’s personal and bank data. Active banks keep the interface to the customer, the RP, and other SPs and provide an IDP implementation according to the free IDP Specification. These banks can generate revenue by exposing APIs and sharing user and account data with RPs and SPs if requested and approved by the respective user.

Passive banks don’t have a contractual relationship with and do not provide an IDP for their customer. However will be available to customers of these banks through TPPs that provide IDPs for passive bank in the scheme. These IDPs use the respective bank’s public interfaces (such as their PSD2 Access to Account API). Passive banks thus form a part of the scheme without their cooperation. Any passive bank may take over the IDP role for their customers if it becomes an active bank.

In both scenarios RPs and SPs can obtain all PSD2 services (account holder, IBAN, 90 days of transaction history, SEPA transfer and mandates) as well as user email and postal address free of charge. Active banks, passive bank IDPs, and other Service Providers can provide additional data for free or at a premium.

Users of both active and passive banks don’t have a user account. instead leverages the existing online banking account by orchestrating a network of IDPs, which provide a federated ID to RPs^[1]. Data is never transferred to an RP without a prior user consent and never transferred to the scheme itself.

Third party party Service Providers will enrich the ecosystem by providing additional services, like enhanced scores or electronic signatures based on the bank-provided authentication capabilities and verified data.

USER PERSPECTIVE: allows me to use my online banking credentials to login to third party websites and apps and to use my bank data for services that require a high level of trust and authenticity. It enables me to initiate SEPA transfers directly at my bank and prove my verified identity to access services that would otherwise require a separate, more cumbersome verification method, e.g., video ID or a physical processes.

RP PERSPECTIVE: enables me to easily authenticate and identify users with their banking account without the need to integrate all banks separately with my service. I get all PSD2 services for free, through a single API Specification and without needing to be certified as Account Information Service Provider (AISP) or Payment Initiation Service Provider (PISP). The same API Specification allows me to access bank-verified identity and account data. Moreover, I can use further -standardized or third party party services, e.g., to enrich the user’s data or to let my users sign contracts with qualified electronic signatures.

ACTIVE BANK PERSPECTIVE: is an ecosystem where I keep the customer interface and the ability to authenticate my users directly^[2], transfer data directly to RPs without the need for third party aggregators, and become the digital master key for my customers.

I can monetize my verified customer and account data by making it accessible to all RPs and SPs in the scheme in compliance with GDPR and PSD2 using open standards and a well-defined commercial and legal framework provided by .

SP PERSPECTIVE: is a marketplace where I can offer my services that are based on verified user identities, data and account data. I can reach a wide range of Relying Parties and other Service Providers and use as billing partner for my offering.

PERSPECTIVE: The platform facilitates the scheme by managing the trust relationships among IDPs, SPs and RPs. The Account Chooser connects RPs and IDPs (and SPs) on behalf of the user. The user determines the bank she wants to use with and this decision is retained in order to provide SSO in subsequent transactions even if a strict 3rd party cookie policy is in place. can be used by IDPs and SPs as a billing and clearing platform.

To become a part of the scheme, partners have to sign up with a RP agent. Banks, RPs and SPs get access to all relevant information and technical specification that are relevant to become part of the ecosystem at https://docs.verimi.de/openbanking/docs.

After successfully implementing the required interfaces and testing of the end-to-end system behavior in the sandbox, will activate the partner for the live environment.

This diagram illustrates the overall architecture of the scheme. It shows the involved parties and their relationships.

A Relying Party (RP) represents a site or app wanting to integrate services into its overall proposition, e.g. to identify the user according to anti money laundering law.

The IDP plays the most fundamental role from the user’s perspective. There is an individual IDP for every bank in the scheme, which provides the functionality for the respective user base with the bank’s look and feel. The IDP authenticates the user taking full advantage of existing methods (such as online banking credentials or mobile apps capable of receiving push notifications and using biometric authentication) and gathers the user’s consent for any transaction.

This also means that the RP always first needs to determine the IDP to talk to on behalf of a certain user.

The Account Chooser is used for that purpose. The user identifies her bank at the account chooser’s user interface and the account chooser in turn identifies the respective IDP and its so-called service configuration, which contains the configuration data and URLs required for the RP to use the various services provided for the customers of the respective bank.

From the perspective of a RP, Account Chooser, Service Configuration and the set of all IDPs are form a “Virtual IDP”.

The platform provides components and interfaces to orchestrate the OpenID Connect/OAuth based flows and use of further APIs between users, RPs, SPs, and IDPs.

The platform provides directories that enable the partners to know each other and to query all relevant details to setup a secure and trustable authentication for any user, independent of which RP she is supposed to use and which IDP is the one she has an account for. The platform also provides a service to collect billing data to facilitate invoicing and settlement among the involved parties.

For a detailed explanation of the platform please consult the Platform Documentation.

Third party Service Providers may offer their services to RPs in the scheme. These SPs can rely on trusted access tokens issued by the IDPs containing bank approved identity information and user data to fulfill services which require a high level of assurance. Service Providers may utilize other services provided by the IDP or other service providers to implement their service.

Most scheme partners, IDPs, SPs and RPs, are onboarded through so-called Agents. These are business partners acquiring the aforementioned partners through their network, perform the KYC check, close the contract and provide with the information needed to set up the respective technical accounts. We will also serve as agent for partners that want to interact directly with .

uses the open standard OAuth 2.0 to authorize access to any kind of service in the scheme. Every IDP is a OAuth Authorization Server that utilizes online banking credentials to authenticate users, gather their consent for service access and user data transfer, and issues access tokens that RPs and SPs use to authorize service access. On top of OAuth, the open standard OpenID Connect is used to provide identity service to RPs.

The scheme forms a virtual IDP composed of thousands of independent IDPs. This poses the following challenges:

HOW IS THE VIRTUAL IDP EXPOSED TO RPs? From an architectural perspective, one could build a proxy encapsulating all IDPs from the RP. Although this sounds beneficial (esp. from an RPs perspective) on first sight, it poses significant technical, legal, and privacy issues since user data would flow through systems. To assess the impact, one needs to take into account that is designed to become an international ecosystem spanning different jurisdictions. This is why is designed as a scheme of independent IDPs^[3], where every IDP directly interacts with the respective RP. ensures interoperability of all IDPs towards RPs by defining standard APIs every IDP in the scheme must comply with (see IDP Specification).

The scheme approach (which is distributed in nature) creates the next challenge:

IS IT POSSIBLE FOR A RP TO USE ALL IDPs OF THE SCHEME WITH A SINGLE CREDENTIAL? This is enabled by maintaining a universal client id for every RP, which is applicable at any IDP. RPs use public key cryptography to authenticate with IDPs, where manages the RP’s public key certificates or URLs pointing to public key certificates. IDPs obtain all RP data (e.g. name, client_id, certificates, redirect URIs, allowed scopes and claims, tos & policy URLs) from the RP directory and maintain it locally for use during the OAuth (OpenID Connect) Flow. IDPs are supposed to periodically synchronize with the RP directory.

As a result, an RP can interact with any IDP without knowing it beforehand. The RP uses its universal client_id and the service configuration of a particular IDP to establish the connection at runtime and at the user’s request.

HOW DOES AN RP DETERMINE WHETHER AN IDP REALLY BELONGS TO ? The account chooser and the service configuration service are the trusted sources of IDP data. The identity provider ensures authenticity and integrity of this data. RP MUST NOT use any endpoint URL obtained anywhere else.

is designed to manage a large number of partners in a highly scalable, uniform and comprehensive way. To fulfil this comprehensive approach of an ecosystem with multiple 3rd party systems but a uniform system behavior, all parties have to follow the same integration guidelines and provide or invoke consistent interfaces. Even though well known standards are used to become part of the ecosystem, will define profiles, details, extensions and interpretations of all used protocols and standards if needed by way of the IDP Specification. It profiles OAuth and OpenID Connect in order to make it fit the requirements and objectives. It also defines the APIs for accessing account information, initiate payment and remotely create electronic signatures in the scheme.

On an overall architectural level, every IDP provides all services for the customers of the respective bank. However, it is vital for that functions provided by fintechs and large techs are also available in the user ecosystem. Because is a federated System comprised of thousands of banks it is difficult to ensure all banks offer all services from the beginning. This is why it is critical that service providers can fill the gaps by offering services like Qualified Electronic Signatures (QES) or scores on top of the banks’ capabilities.

This section defines the service architecture required to build and grow such an ecosystem. It defines how the services offered to the customers of a certain bank (the IDP) are provided and how those services interdepend.

This section defines a set of core services that every bank shall implement and offer to both RPs and SP. It also discusses further value added services that either the bank or another service provider can implement and offer to the customers of the respective bank.

This chapters describes the interactions of the building blocks in the context of relevant processes.