Simplifying the Data Access Path for Data Receivers

The OIDC Federation model, particularly as outlined in Section 11.1 of the OIDC Federation specification, introduces an automated registration mechanism. This allows Data Receivers to initiate Authentication Requests directly, bypassing traditional registration with Data Providers. Upon integration into the Ecosystem Trust Framework, Data Receivers are allocated a unique client_id, bound to their created encryption and transport certificates. These credentials are utilized to authenticate requests and secure token issuance via the Data Provider's Authorization Server Endpoint.

To enable this process, Data Providers must proactively acquire relevant metadata based on their client_id from the Trust Anchor, ensuring the Data Receiver metadata is always up-to-date.

Reduce Interoperability problems and improve standardization

The DCR framework, employed in both Brazil and the UK's Open Banking implementations, necessitates that Clients ( Data Receivers ) initiate contact with the Servers ( Data Providers ) registration endpoint to onboard. This process has led to:

• Varied registration requests for each Client-Server interaction, causing interoperability issues due to misprocessing or miscommunication of these requests.

  • How this is solved : By having Servers to automatically register clients based on the Participant Directory's Entity Statements, the system eliminates individual registration requests, enhancing interoperability.

• Registration data can often be outdated as a an active PUT request against the registration endpoint is required for the Client metadata to be updated

  • How this is solved : Implementing a server-side cache policy for registration metadata ensures timely updates, keeping client data in line with what’s defined on the Participant DirectroyDirectory

• Issues on the registration Journey might lead to client_ids being created without the registration_access_token being sent back, forcing manual recovery of tokens or removal of clients, raised using bi-lateral Service Desk tickets.

  • How this is solved : The unique, standardized client_id and the Trust Framework as the source of truth negates the need for client-side maintenance, streamlining the process.

Ensuring Responsibility Spread for Client Registration to the fewest number of actors

On the Proposed Registration Framework, the responsibility for registration entirely rests with the Data Providers. They are required to actively consult and regularly update data from the Trust Anchor (Trust Framework). This ensures they keep an up-to-date registry of all authorized Clients in the Ecosystem.

The Standard also specifies that when Data Providers encounter an Authentication Request from an unrecognized Data Receiver, they must fetch the client's data from the Trust Anchor. This is to accurately ascertain the client's access scopes, regardless of whether the regular updates have been properly conducted.

Support Cross Border Integration

OIDC Federation supports the setup of unified trust network across multiple trust anchors through standardized metadata acquisition mechanisms.

This structure can be used to promote interoperability and trust among clients and servers across different ecosystems, fostering a seamless cross-border integration framework.