Feedback 05 - Client Registration

[CDR-Register-Stream]

This thread has been created to allow for feedback on the Register Client Registration process.
Client Registration requirements, registration process and associated sequence diagrams can be viewed at: https://cdr-register.github.io/register/#client-registration

• The ACCC seeks input from the financial community on what rules and timings organisations currently use when caching security data.

• The ACCC seeks input from the financial community on what their current processes are regarding dealing with compromised third parties.

• A number of stakeholders commented on this aspect of the draft rules. The ACCC is currently considering these comments and the appropriate amendments to make to the rules in light of that feedback. To assist that process the ACCC is interested in views, via this forum, about:

(a) the types of security incidents where it would be appropriate to ensure that data requests are not sent or responded to;

(b) obligations on Data Holders and Accredited Data Recipients to notify the ACCC of security incidents that may affect the security of the CDR ecosystem – including the way that those incidents should be reported and a practical timeframe for that occurring.

All feedback is welcome.

[NationalAustraliaBank]

NAB would like to provide the following initial feedback on Client Registration.

Static Client Registration

• When a participant receives a request via the Admin API to refresh their cache, within what time period must this occur?

• Regarding the metrics that are being captured, are they being captured by the CDR Register? If so, we assume that participants do not need to inform the CDR Register that they have successfully refreshed their cache, in response to a refresh request, periodic refresh, or cache expiry.

• Where will the recommendations that the metrics will be measured against be published? Will the recommendations cover:

  • Maximum cache age;
  • Periodic refresh cycle;
  • Refresh request turnaround time; and
  • Retry / polling strategy, including exponential back off algorithm considerations?

  What are the implications to non-conformance to these recommendations? Will the CDR Rules incorporate the measurement of participants against the recommendations?

Cache Refresh Metadata Request

• If a refresh request is issued, but the version of the Register data is incorrect or has issues and requires remediation, is the expectation that this will be resolved in a 'roll forward' approach? I.e. There is no expectation for participants to support a 'rollback' capability for their Register cache.

• What NFRs apply to the Admin APIs? This question was previously raised with the Data61 under Decision Proposal 018 - Administration End Points standards#18 (comment) but was not specifically responded to. Will NFRs for the Admin APIs be defined by the DSB / Data61 or the ACCC?

• What is the CDR Register's strategy for notifying all participants to refresh their metadata? Will it be a simultaneous broadcast, which might result in all participants requesting the Discovery APIs around the same time? Or will the CDR Register stagger / throttle the notification to participants, with an understanding that there will be a period where participants will be at different versions of the CDR Register.

Incident Management

What is the mechanism for notification? Will there be an ACCC API to receive these notifications? Is there any consideration to overlay of business hours to this 24 hour notification window?

[perlboy]

Biza.io wishes to ask what the ACCC's future intentions are regarding support within the CDR of Dynamic Registration endpoints and whether they will be supported for publishing? In the latest standards there is an expectation that .well-known endpoints will be published (so it's "dummy dynamic") but dynamic registration is never mentioned. From what I can find in the Standards issues historically this decision was informed by ACCC to facilitate admission control.

With this in mind Biza.io supports, for the case of expediency of Proof of Ecosystem, testing start using static registration information but suggests it is done so in context of eventually migrating to the adoption of OpenID Connect Dynamic Registration combined with OpenID Connect Federation.

Biza.io wishes to note that static registration is not the only method to provide ACCC with the ability to provide a trust line from themselves to participants. Firstly, the shared CA which is separate discussion. Secondly, the 8th draft of the implementors draft for version 1.0 of the OpenID Connect Federation was released 4 weeks ago.

OIDC Reg + Federation provides the following key advantages:

• The Federation provider (ie. in this case the "ACCC Register") is able to provide cryptographic assertion that the published endpoints have been endorsed. This would be applicable to both holder and recipients (collectively "participants")
• Metadata, Key Rollover, and Revocation components which appear to be quite helpful in the context of cache metadata refresh times
• .well-known endpoints can either be published in the register or diminished to referrals to URI endpoints (ie. jwks-uri) with cryptographic assertions used (ie. Register does not need jwks content but can sign a verification of it)
• Participants are able to setup mutually private (ie. never disclosed publicly) OIDC Registrations on potentially custom endpoints. This enhances threat assessment capabilities, enables sandboxing etc and also potentially facilitates multiple agreement setup between recipients business lines providing a variety of benefits (not just in security).

Consequently, in the context of the Static registration publication Biza suggests that the static registration data mirrors format's already established within these internationally adopted standards. This will allow future support in line with the international standards without requiring significant metadata rework in the published Static directory. In an effort to "put up or shut up", find openid-provider.txt an initial metamodel for an OpenID Provider schema object based on OpenID Connect Dynamic OP standards.

[commbankoss]

Commonwealth Bank supports Dynamic Client Registration (as Open Banking UK has implemented). We strongly prefer this approach to static client registration. We also believe that Dynamic Client Registration would be compatible with the ACCC requirements for the Registry. The Open Banking Dynamic Client Registration profile is built on existing standards, which have been tested by industry. However, static client registration is a new concept that introduces new implementation risk through customisation.

The proposed mechanism will rely on Data Holders updating their cached data to reflect changes made to the status of an Accredited Data Recipient (ADR).

The proposed design does not include a central highly available Registry. This design will drive a number of complexities and subsequent design choices:
• Each Data Holder and Data Recipient must implement an invalidation / notification interface for the ACCC to call;
• The ACCC must implement an orchestration mechanism to call all participants in the regime, the cost and complexity of which grows with the number of participating parties (particularly as more industries join the CDR);
• The ACCC mechanism must account for parties being unavailable due to planned or unplanned outages;

These complexities mean that the Register may not communicate changes to a participant’s accreditation or data sharing status to Data Holders as expected or in a timely way. This will increase the number of scenarios in which a Data Holder may not update their cache, and the risk that the Data Holder will continue to share consumer data with the suspended (or terminated) Data Receiver. The risk is particularly acute, as more Data Holders become participants in the CDR.

Commonwealth Bank recommends that the Registry is closely aligned to already existing and tested Standards (e.g. SCIM for exchanging identity details and the OIDC dynamic client registration Open Banking profile) to take advantage of a number of benefits including:
• Rigorous industry testing to which standards have been subjected and therefore the avoidance of unforeseen complexities, bugs and security vulnerabilities
• The ability to take advantage of future evolution of standards to ensure we continue to align with global developments and best practice
• Uniformity across different regions, which will lower the implementation costs for new entrants to the Australian markets.

Commonwealth Bank also recommends adoption of a highly available and scalable Registry (and Certificate Revocation List, or ‘CRL’) and Certificate Authority (CA) endpoints. Full description of the lifecycle of CDR participants is required in the documentation, including the on-boarding, suspension and revocation of participation.

Data Holder/ Registry Authentication
The proposed mechanism for updating Data Holders and the Registry of changes to the status of participants requires the consumption of dedicated APIs. These APIs cannot be public due to the nature of the information they transmit.

Details are required on how Data Holders should authenticate with the Registry endpoint, and how the Registry will authenticate with Data Holders in order to facilitate access to these APIs.

Further clarity is also required regarding whether a Data Recipient’s accreditation status applies to the corporate entity and therefore all the CDR applications they develop, or whether accreditation applies to each separate Data Receiver application.

We recommend adoption of the UK’s Registry model, which enables dynamic client registration.

Certificate Revocation
The Standards do not currently deal with the scenarios that will result in the revocation or suspension of an ADR’s accreditation status, or result in the revocation of its security certificate. We welcome further discussion with ACCC on these possible scenarios.

The Standards also omit technical details regarding:
• How Data Holders can cancel establish sharing requests, as permitted by the Rules
• Whether certification revocation will utilise Online Certificate Status Protocol (OCSP) or an online call to a Certificate Revocation List (CRL)
• The availability Service Level Agreement (SLA) of the CRL
• How many security certificates will issued and to whom
• If all security certificates (TLS, MTLS and private key jwt certificates) will be issue by Certificate Authority or just some of them e.g. TLS and MTLS only

Incident Management
Further details regarding cancelling established sharing requests is required.