BLOG

December 17, 2019
3 min read

WSO2 Open Banking 1.4 Consumer Data Standards - Dynamic Client Registration v0.1

Dynamic Client Registration

Dynamic client registration (DCR) is a protocol that provides a mechanism for OAuth 2.0 clients to get registered with an authorization server. Here, a client obtains a set of metadata (known as a ‘software statement’), which describes itself from an authorized issuer. The software statement will be digitally signed and the issuer vouches for the validity of the data about the client. The client can then present this software statement to the authorization server to get itself registered and obtain a valid client identifier to communicate with the server.

Consumer Data Standards DCR Specification v0.1

In the context of Consumer Data Standards (CDS), the Consumer Data Right (CDR) Register is the authorized issuer, the Accredited Data Recipient (ADR) is the client and the Data Holder (Bank) is the authorization server. When the Data Recipient is accredited and the associated Software Product is configured within the CDR Register, the CDR issues a Software Statement Assertion (SSA) for the Software product of the Accredited Data Recipient. The SSA is signed by the CDR Register using the PS256 algorithm conforming to the FAPI-RW specification. Thereby, the ADR composes a registration request including the obtained SSA and sends it to the registration endpoint of the Data Holder to register their Software Product.

In order to evaluate the validity of the SSA, the Data Holder will verify its signature using the JWKS endpoint that the CDR register is yet to provide. Upon successful registration, the Data Holder will respond with a 201 CREATED response, including the required registration data. The registration data will contain the client_id and client_id_issued_at (optional) parameters in addition to the data which were present in the registration request. The client_id is dynamically generated by the Data Holder during the registration process and directly maps to the software_id issued by the CDR register. The ADR can use this data to obtain an access token to communicate with the banking APIs.

The CDS defines the following endpoints in the DCR specification v0.1.

POST /register - Register a Software Product at the Data Holder

GET /register/{clientID} - Retrieve registration data of a Software Product

PUT /register/{clientID} - Update registration data of a Software Product

DELETE /register/{clientID} - Delete a software product (optional)

The POST /register endpoint allows the ADR to register a software product and create an application at the Data Holder as described above. The other three endpoints can be used to manage the registered software product. WSO2 Open Banking supports all the specified endpoints including the optional DELETE /register/{clientID} endpoint. In addition to that, all Software Products created using DCR can be managed by signing in to the Developer Portal using Data Holder’s administrator account.

In terms of endpoint security, all the endpoints are protected using TLS Mutual Authentication, and the latter three are also protected by the specified Holder of Key (HoK) mechanisms. Any change to a created application requires an access token obtained for the particular application.

AU DCR - Sequence diagram for creating an application

AU DCR - Sequence diagram for application data retrieval

AU DCR - Sequence diagram for application update

AU DCR - Sequence diagram for application deletion

Try Out WSO2 DCR API

The following documentation provides a walkthrough to try out the WSO2 Open Banking CDS DCR API. https://docs.wso2.com/display/OB140/Dynamic+Client+Registration+API+v0.1

References

[1] - https://tools.ietf.org/html/rfc7591

[2] - https://cdr-register.github.io/register/