Consumer Data Standards Version 1.3: Approaching Common Ground

Image credits: Marcus Ireland from Pexels

What’s new in CDS 1.3?

With the latest release of the Consumer Data Standards (CDS) specification - version 1.3 - several changes have been introduced to the technical framework applicable to open banking in Australia. This has laid the foundation for integrating the latest changes to global standards such as FAPI 2.0 and Oauth 2.0. With version 1.3, attention is given to facilitate the management of multiple consents per Data Recipient and end-user combination. Also, a more systematic approach for informing that consent is revoked has been introduced. The rules have further required the adoption of a more secure approach to the authorization process by including a concept known as Pushed Authorization Requests (PAR) described in the Oauth 2.0 standards.

Reasons Behind These Amendments

Primarily, the additional functionality introduced is focused on enabling Data Recipients to efficiently provide more service types to consumers and ensure consumers retain adequate control over consent in these situations. This helps maintain consumer trust in the system, a vital element of ensuring wide adoption by consumers of open banking in Australia.

With the changes introduced, a Data Recipient can benefit from the introduction of concurrent consents since it will allow an end-user to create a new consent if they need to use a new service provided by the Data Recipient or if some new functionality has been introduced in the application. This allows the end-user to use that service without making amendments to already established consents.

When a user revokes the consent granted via the Data Recipient’s application or else via the Data Holder’s consent management application, there should be a mechanism to inform either party that the particular consent is not valid anymore. This is made possible with the introduction of a new endpoint known as the CDR arrangement management API. If this communication does not take place, the Data Holder will continue to expose the consumer’s data and the Data Recipient will continue to have the consumer’s data within their system. It is important to communicate the revocation both ways for protecting the consumer and to prevent the consumer’s data from being misused.

The use of the Pushed Authorization Request helps to prevent the communication of sensitive information in the front channel. Instead of communicating sensitive information directly in the redirect request to the authorization endpoint of the bank, only a reference for the data related to the communication will be sent while the actual details of the authorization request will be communicated via a dedicated endpoint.

Concurrent Consents Approach of the CDS

In order to support multiple consents from the same Data Holder, some form of identification should be attached with the consent. This approach is followed in the Open Banking Standard specification in the UK, where a “consent-id” is provided to the Data Recipient after they inform the Data Holder of their intention of creating a consent (consent initiation). Similarly, in the CDS regime, this identification will be known as “cdr_arrangement_id”. In a previous version of the CDS, the name “sharing_identifier” was used but it was changed to reflect a more general intention anticipating the introduction of “write APIs” as well in the future.

The Data Holder will need to send a unique identifier for the “cdr_arrangement_id” claim in the ID token after the consumer completes the consent authorization process. This will be used by the Data Recipient to uniquely identify the consent established per end-user-Data Holder combination. Furthermore, this identifier should not reveal any information about the end-user.

When a Data Recipient wishes to revoke a previously established sharing arrangement, the “cdr_arrangement_id” related to that consent should be sent as a claim in the request object. When a Data Holder receives this, the consent as well as all tokens attached to that consent should be revoked after successfully establishing the new consent. If no “cdr_arrangement_id” claim is present in the request object of the authorization request, new consent will be established and no amendments should be done to the existing consents and the tokens attached.

Figure 1: Concurrent consent approach. Source: Concurrent Consent decision proposal.

Consent Revocation

The CDR Arrangement Management endpoint has been introduced with version 1.3 and it includes an endpoint for the revocation of the consent. This endpoint must be implemented by both Data Holders and Data Recipients. This will help both parties to notify each other in the event consent is revoked. The “cdr-arrangement-id” should be used to uniquely identify which consent should be revoked. This makes the communication of revocation much more cleaner and straightforward. The “cdr_arrangement_id” is used to identify which consent is to be revoked. For Data Holders to determine the base URI to invoke when informing the revocation, a new claim will be introduced with the software statement assertion known as “RecipientBaseURI”.

This new API lays the foundation for a way to notify participants in more complex use cases related to the data sharing arrangements in the CDR ecosystem. This is similar to the event notification API which is present in the UK Open Banking specification.

Figure 2: Consent revocation by data holder. Source: Concurrent Consent decision proposal.

Figure 3: Consent revocation by data recipient. Source : Concurrent Consent decision proposal.

Pushed Authorization Requests

PAR is a concept introduced in the Oauth2 specification to further the security and authenticity of the authorization request. This allows details related to the authorization such as the scope details and the client id to be communicated in a secure manner to the authorization server. JWT secured authorization request (JAR) was introduced to ensure cryptographic integrity and authenticity protection by including a request object which is a signed JWT that contains the authorization data. To cope with the size limitations of the authorization request, a request_uri was introduced which clients can use to refer to a request object.

The PAR specification complements this further by adding capabilities to send the request object to the authorization server before redirecting the end user for the authorization process. This endpoint ensures the integrity of protected authorization requests while giving the authorization server higher confidence in the client’s authenticity. Client authentication can also be completed before any user interactions take place and the error message can be directly sent to the client without any end user interference.

The Data Recipient needs to use the PAR endpoint if the request is too large to be communicated via a front channel or if the request contains a “cdr_arrangement_id”.

Figure 4: PAR endpoint. Source : Concurrent Consent decision proposal.

The request_uri should expire within a period of between 10 and 90 seconds. After receiving a request_uri, the Data Recipient can proceed with the actual authorization process and prompt the consumer to authenticate and authorize the consent. A sample authorization request will be presented in the following form where no sensitive information is sent via the front channel:

GET /authorize?request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1

Data Holders should also publish the PAR endpoint details in the OPENID discovery endpoint in order for Data Recipients to direct the request to the PAR endpoint.

Into the Future

There is strong recommendation from the community in the CDR ecosystem to adopt common standards which will strengthen security and enhance interoperability between standards. The recommendations in particular are to adopt the FAPI 2.0 profile and agree upon a general consent management API to maintain the consent status and for revocation purposes. The new additions to the specification such as the CDR arrangement endpoint and Pushed Authorization Endpoint shows the intent and interest of the CDS regime to adopt the latest recomemnded standards.

In order to support complex consent scenarios where fine grained consent models are to be used, Rich Authorisation Request (RAR) is the recommended way in Oauth2.0. This introduces a standard manner in which more details regarding consent can be communicated without limiting the consent to a scope. This will be useful in particular when moving the CDR to dealing with write operations.

Several recommendations related to the consumer experience are currently being researched by the consumer data standards body which include consultation for joint accounts, re-authorisation, fine-grained control, de-identification and deletion,amending consent and simplification of consent. This research is focused on how to align the user journeys with the scenarios mentioned for a smoother user experience (UX). After formalizing the UX changes, the technical specification will also be modified to reflect the changes in the consumer experience. With the new changes introduced to the specification, it can be seen that as the specification matures, it will be moving towards adopting already established approaches in the areas of consent management and identity and access management.

I hope this blog helped in providing an understanding about the latest version of the Consumer Data Standards specification. In order to explore more about Open Banking in Australia, learn more about how WSO2 Open Banking caters to the CDR requirements.