Registration Framework
Pick a registration framework to be used within the Framework: OAuth Dynamic Client Registration or OpenID Federation. Control how client applications are registered within the Data Provider's authorisation servers.
During the creation of the Trust Framework, its administrators need to provide Raidiam with information on how client applications are to be registered within the Data Provider's OAuth Authorisation Servers. The choice between two distinct Registration Framework types, OAuth Dynamic Client Registration and OpenID Federation, can significantly impact the security, flexibility, and efficiency of your ecosystem.
OAuth Dynamic Client Registration (RFC7591) enables client applications to dynamically register themselves with the Data Provider's OAuth Authorisation Servers, eliminating the need for manual intervention by administrators.
When requesting registration at the authorization server's DCR endpoint, clients send a list of desired information to the authorization server. In response, they receive a client identifier and the registered metadata values. This information allows clients to communicate with the authorization server using the OAuth 2.0 framework.
This automated process simplifies the onboarding of new client applications, reducing administrative overhead and accelerating the deployment of services.
OAuth Dynamic Client Registration (DCR) offers several advantages:
- Automation: DCR streamlines the process of registering client applications by allowing them to dynamically register themselves with the authorization server. This automation reduces manual intervention and administrative overhead.
- Flexibility: DCR accommodates the onboarding of new client applications and updates to existing ones seamlessly. It adapts to evolving environments, enabling quick and efficient integration of services.
- Scalability: With DCR, organizations can rapidly scale their ecosystem by adding new client applications without compromising security. This scalability supports the growth and expansion of the ecosystem over time.
- Efficiency: By automating the registration process, DCR improves efficiency by reducing the time and effort required for client application onboarding. This allows organizations to focus resources on other critical tasks.
- Compatibility: DCR ensures compatibility between client applications and the authorization server by dynamically registering metadata values. This compatibility enhances interoperability and smooth communication within the ecosystem.
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 the Data Receiver’s requests and secure token issuance via the Data Provider's Authorization Server Endpoints.
To enable this process, Data Providers must proactively acquire relevant metadata based on their client_id from the Trust Framework, ensuring the registered Data Receiver metadata is always up-to-date.
OpenID Federation can be used to mitigate some of the issues that can arise when OAuth DCR is used, but it introduces an additional overhead for the Data Providers, especially when it comes to the requirements for the authorization server.
DCR Issue | Solution |
|---|---|
Varied registration requests for each Client-Server interaction, causing interoperability issues due to misprocess or miscommunication of these requests | 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. | Implementing a server-side cache policy for registration metadata ensures timely updates, keeping client data in line with what’s defined on the Participant Directory. |
Issues on the registration journey might lead to client identifiers 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. | An unique, standardized client_id and the Trust Framework as the source of truth negates the need for client-side maintenance, streamlining the process. |
Additionally, with OpenID Federation as the Registration Framework, the Trust Framework can:
- Ensure responsibility spread for client registration to the fewest number of actors. 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.
Raidiam Connect offers the Simple Registration Endpoint (SRE) as a native Registration Framework, serving as an alternative to the models specified above. SRE, as with the OpenID Federation registration framework, introduces an automated registration mechanism. This enables Data Receivers to initiate Authentication Requests directly, bypassing traditional registration methods with Data Providers such as Dynamic Client Registration (DCR).
Upon integration into the Ecosystem Trust Framework, Data Receivers are allocated a unique client_id, bound to their created signing and transport certificates. These credentials are utilized to authenticate the Data Receiver’s requests and secure token issuance via the Data Provider's OAuth-compliant Authorization Server.
To facilitate this, Data Providers must proactively acquire relevant metadata based on their client_id from the Trust Framework, ensuring the registered Data Receiver metadata is always up-to-date.
However, with SRE, Data Providers benefit with much more streamlined client registration (discovery). The Authorisation Server can query the Raidiam Connect's Get All Registered Clients API in order to fetch an up-to-date list of all client applications registered within the given trust framework - registering participants ahead of time.