Dynamic registration of accredited data recipients

[JamesMBligh]

After discussions with the ACCC Directory development team the current hypothesis for v1 is that all information required for a data holder to authenticate and communicate with an accredited data recipient (and vice versa) will be held within the meta data store in the Directory. This would mean that dynamic registration mechanisms would not be included in the standards.

If anyone has any thoughts or concerns on this position then feedback would be welcome.

[commbankoss]

Hi James
Please Note we have posted #45 (comment) which is related
Regards
Darren

[NationalAustraliaBank]

NAB is currently concerned with the proposed registration solution and the ramifications it could create. Whilst we understand that the ACCC is currently working on the solution design for the Directory, the following aspects of registration need further consideration:

1. Directory and DH security controls: what is the process for key exchange between Directory and DH and what are the security controls that will need to be implemented by both the Directory and DHs to secure client metadata synchronisation (polling) end points?
2. Stale client metadata cache on the DH side: given that the DH will be polling the Directory for client metadata, it is likely that the DH's cache of client metadata to become stale. This may cause DR's requests to be rejected (in case of newly registered DR client) or processed incorrectly. Polling Directory on each DR's request will cause performance and capacity issues. The proposed design also raises the issue of DH compliance in case the Directory is down or unresponsive. An additional security consideration is related to the inability to immediately revoke client registration within the overall scheme, given that there will be a lag in the DH's cache synchronisation with the Directory.
3. Re-Authorisation: given it looks like the "indicated consent" API (intent API) will go away (Issue#47 Consent API and definition) and the proposal to use CIBA for re-authorisation, DHs and DRs will need to directly exchange key pairs for DR's endpoint authentication purposes. How is this key exchange meant to work? Introduction of CIBA into the re-authorisation process will increase overall complexity for compliant implementations as will in effect require all parties to implement CIBA in a non-standard way.
4. Directory's Availability: if real-time metadata sync is required, the directory itself will need to implement highly available end points for DHs to periodically poll for DR metadata. What is the envisaged availability SLAs/NFRs that Directory is going to be built for?

To reduce the level of complexity and increase support for standard protocols, NAB is supportive of the implementation of Dynamic Registration from day 1.

Depending on the ACCC's requirements (e.g. a centralised copy and control over participant's metadata), we believe there are other technical ways to address it, as for example, upon DR registration with the ACCC its metadata is stored in the directory and they are issued with the "software statement" signed by the ACCC that reflects that metadata. The DRs then use the signed software statement to register with the DH of their choice using dynamic registration endpoint. This solution adheres to the OIDC standards and has been adopted in the UK. Implementing dynamic registration endpoint on the DH side will be less complex then implementing the synchronisation polling against the directory. Also, the responsibility for metadata registration relies upon the DR.

If the freshness of the metadata in the directory and on the DH side is an issue, a variant of the above scheme is that directory itself implements the registration with DHs on behalf of the DRs, so in fact it acts as a caching proxy and can ensure that all instances of the metadata across directory and all DHs are in sync with real time status of synchronisation being held centrally within the directory.

[WestpacOpenBanking]

Westpac supports the comments made by NAB on this issue.

Abandonment of an already supported and existing standard is likely to delay implementation and increase expense for both Data Holders and Data Recipients who have opted to purchase, configure and use tools from software vendors in relevant parts of their implementations. If it is not possible to have dynamic registration in the short term, then consideration should be given to the option of manually registering clients for an initial period and adding dynamic client registration at a later date.

A non-standards based model involving implicit trust of an external credential store rather than a trust framework also needs careful consideration of the increased risks from a security perspective. Use of this approach would also require significant deviations from the normative references currently used in the InfoSec standards. Those normative references assume client registration as fundamental part of their design. In particular, [OAUTH2] and [OIDC] make explicit reference to a litany of parameters which must be registered with the provider and validated against this registration in steps of the flow.

At a minimum, the metadata store approach would require:

• Defined standards for the format of the metadata.
• Standards defining URIs, payloads, response codes, error handling, SLAs and so on.
• An approach for identifying clients.
• Agreement as to if the interface is real time or batched based, and the details surrounding the chosen option.
• An authentication and trust framework to support the interface.
• Ongoing management of this information.
• Security testing and assurance processes for directory.
• Further modifications from the [OAUTH2] and [OIDC] normative references and security testing and assurance processes to validate these for security impacts.

[JamesMBligh]

In reference to the comment from NAB:

If the freshness of the metadata in the directory and on the DH side is an issue, a variant of the above scheme is that directory itself implements the registration with DHs on behalf of the DRs, so in fact it acts as a caching proxy and can ensure that all instances of the metadata across directory and all DHs are in sync with real time status of synchronisation being held centrally within the directory.

This is effectively what is proposed. This is to provide the ACCC with control over the software metadata but also the status of the Data Recipient. This is the same driver for the inclusion of a CDR specific CA as it provides the ability to revoke certificates centrally.

With regard to keeping the cache in sync, there will be an accepted lag in the transfer of updates to the cache for most scenarios with a mechanism to do a force refresh if a critical change (like the revocation of accreditation for a recipient) occurs.

More detail on this mechanism must, of course, be provided.

-JB-