Decision Proposal 23 - Static vs Dynamic Registration

[CDR-Register-Stream]

This thread has been created to capture, document and come to a decision on Static vs Dynamic Registration.

Initial analysis based on the workshop conducted on the 23rd August 2019 is attached below. Analysis.23-Static.vs.Dynamic.Registration.pdf

All feedback is welcome.

[perlboy]

Straight off the bat, there appears to be an implied tie in between Dynamic Registration and Software Statement Assertions in this document. This is a false implication.

The method with which data holders and data recipients establish a registration with each other (Dynamic vs. Static) should be separate from the method of admission control (and trust establishment) in both situations. This is an important distinct because Static Registration cannot occur without combining them (where as Dynamic Reg it's abstracted away).

In the current proposal the intent is to publish JWKS and force Static Registration of these JWKS. This combined the participant statuses (https://cdr-register.github.io/register/#participant-statuses) through the filtering of JWKS publishing. This means that code written involves iterating over the JWKS set and directly modifying individual (and statically defined) client-id's within an IdP.

In the Dynamic Registration situation there is actually two approaches depending on the intent of separation but only one has been described: 1) Dynamic Registration with Software Statement Assertions (as described) 2) Dynamic Registration with initial and ongoing issuer validity being tied to the Register API status with an agreed identifier (currently client-id but I'd suggest iss or aud is more suitable).

Trying to lay out the 3 use cases.

Static Registration as proposed: 1) Obtain data dump of all participants including JWKS keys (Register API) on some scheduled basis 2) List each client id within an IDP then: a) Compare individual client id's within IdP and forcibly synchronise JWKS keys to existing profiles b) Identify new client id's and create new entries in IdP loading blobs of JWKS c) Identify missing client id's and remove entries from IdP

Note: This Represents an O(n3) (where n3 = holder product jwks) outcome problem

Dynamic Registration with SSA data: 1) Register provides SSA's to Recipient to supply to Holder's which including JWKS elements 2) Recipient performs registration to Holder and supplies SSA along with other components as per OIDC Dynamic Registration process. a) Recipients can rotated JWKS on demand between each holder (via an OIDC-DR update), ACCC does not need to be involved 3) Ongoing revalidation occurs via SSA's being reissued or a "check" method issued to the Register

Note: This Represents an O(n2) (where n = holder * product) outcome problem

Dynamic Registration with Register API data: 1) Obtain a data dump of all participant products NOT including JWKS keys (Register API) on some scheduled basis and store this status. In particular this would include the existing status (https://cdr-register.github.io/register/#tocSregisterproduct) from Product and an "audience" like reference (iss or aud or other, tbd). Holders would obtain recipient jwks from the jwks_uri either cached or on demand. 2) Recipient attempts a Dynamic Registration via OIDC-DR which links the "audience" identifier (and likely therefore the jwks_uri). The Holder validates this using the cached status from the Register API. a) Recipients can rotated JWKS on demand between each holder (via an OIDC-DR update), ACCC does not need to be involved 3) On an ongoing basis, (1) occurs again but this time the Holder lists each "audience" (iss/aud etc, tbd) then: a) Identifies now invalid "audiences" and terminates the dynamic registration (consequently blocking a new dynamic registration) IF that recipient has registered in the specific holder's IdP.

Note: This Represents an O(n) (where n = product) outcome problem, ie. is an order of magnitude smaller

[JamesMBligh]

For me there are some pretty simple inflection points between these two solution options:

1. Recipient effort vs Holder effort Both options have custom build of varying levels on the holder side. There are aspects of registration and status that are not standardised that are required for this regime that means no holder can use an OOTB solution for either option. The dynamic solution, however, requires the recipient to take on a lot more accountability (both code and operational management) that the static solution. I see the dynamic solution as a transfer of effort from the holder to the recipient.

2. Complexity In the static option participants get all required info from a known source and then connection can occur. In the dynamic option participants get some info from a known source but get some additional information from another source and then refresh that info from the known source again. The dynamic option is clearly more complex, and therefore more prone to error and management cost, that the static option.

3. Polling vs Notification The dynamic option only works with a polling model where participants (particularly holders) have to continually poll the register to ensure that the accreditation status of the recipient hasn't changed. If you change the dynamic option from polling to a notification model then you effectively get exactly the same solution as the static option but the initial load to a holder is done by a recipient. I don't see that as a simpler option.

Another thought - much has been made of vendor and library support. The UK included a range of custom design features in their standards that have since be adopted by vendors and open source library. Are we assuming that the same level of support wouldn't occur in Australia?

[commbankoss]

ADR on-boarding to Data holder (post accreditation)

Authorisation server needs OAuth clients to be created

	Dynamic client registration	Custom registry replication

Participants Data Holder | - Reduced complexity - Reduced delivery risk - Reduced timelines - Configuration instead of custom code (out-of-the box existing tools) - Ability to use open banking infrastructure for other use cases | Increased complexity - Increased delivery risk - Increased timelines - Custom code – each data holder will be inventing its own way to hack their - Authorisation server or emulate dynamic client registration behind the scenes – SIGNIFICANT EFFORT. Inability to use open banking infrastructure for other use cases - Mixing business and security concerns Data Receiver | See developer experience below Registry | Need to generate / update Software Statement (UI and/or API) This should reduce work on Discovery APIs | No need to generate SSA But more work on APIs is required (as per original plan) Agreed design principles Rules compliance | |   Provable secure | - Tested standards and tools used SSA is signed by ACCC – additional trust | - Potential part mitigation (currently not in scope): API payload can be signed too. Additional work for all participants to achieve this. Developer experience (Data receiver) | Additional API call is required to register with each data holder (one-off unless changes to required). Mitigation: open source tools are available.   Additional ‘column’ is required to hold client_id issued by each data holder   Ability for Australian ADRs to quickly on-board to overseas Open Banking regimes (by utilising similar standards based security profile) | No work is required   No client secret / client credentials supported   Inability for Australian ADRs to quickly on-board to overseas Open Banking regimes (by utilising custom security profile) due to divergence   International vendors less likely to participate / invest in Australian market due to customisation costs Open standards | | | Security supportability (tools) | configuration required |   Timelines | Data Holders ACCC ecosystem (less unknown, more standard) | ACCC Data holders ecosystem (more unknown, less standard) Simplicity (overall architecture) | Requires less implementation, especially in the case of the ADR | Note: UK discarded this option based on “minimisation of central infrastructure” principle The need to compensate for not having reliable central services dramatically increases complexity in the regime (beyond client registration) Other considerations Client_id | Standard pattern: Unique client_id is generated by Data Holder Authorisation server | Options: Client_id is global. Uniqueness cannot be guarranteed across other use cases? OB infrastrcuture cannot be re-used External client_id needs to be mapped to internal OAuth client_id, maintained and referenced -> custom code on DH side

Our interpretation of dynamic client registration is slightly different from the one published by ACCC this morning: -          Based on OIDC Dynamic Client Registration (profiled for our use case) -          Includes Software Statement Assertions (SSA) as a mechanism to convey ACCC accreditation for on-boarding purposes only -          ACCC is still required to publish APIs conveying status of all participant  -          Most modern commercial authorisation servers support this type of profile out-of-the-box (configuration is still required, not custom build)

[CDR-Register-Stream]

Fantastic to see the above input. Thanks to those who have contributed.

One of the challenges we have been looking at with the Dynamic Registration model is where re-registration will need to occur. When adding to the redirect_uris fields, does this constitute a re-registration or an update to registration? Is this dependent on IDP support (i.e. some vendors will and some won't support update of registration functionality). The concern is that if re-registration does need to occur, and a new client_id is issued, do all current consent agreements now go out the window?

[perlboy]

1. Recipient effort vs Holder effort Both options have custom build of varying levels on the holder side. There are aspects of registration and status that are not standardised that are required for this regime that means no holder can use an OOTB solution for either option. The dynamic solution, however, requires the recipient to take on a lot more accountability (both code and operational management) that the static solution. I see the dynamic solution as a transfer of effort from the holder to the recipient.

The specification of quantity of effort here assumes that the significant sunk effort already undertaken in other jurisdictions on client support has a zero value which is plainly untrue. Focusing specifically on recipients workload, there are multiple implementations of dynamic reg for RPs and many of them are freely available. Taking node-openid-client, an MIT licensed (as per CDS assets) library the dynamic registration process is conducted in <10 lines (actually <5 if I just focused on the library) and would be roughly this:

const { Issuer } = require('openid-client');
(async () => {
  const issuer = await Issuer.discover('https://holder.discovery.endpoint');
  const Client = issuer.Client;
  if(database contains registration) ({
    const metadata = database.registration.read("myHolder");
  } else {
    const metadata = Client.register()
    database.registration.writeOnce(metadata)
  }
  myClient = new Client(metadata, jwks)
})()

registrationMetadata is a serialisable object which can be stored, is paired per recipient<->holder pairing. As ACCC directory changes occur the visibility is loss of functional credentials triggering an attempt to reregister (then perhaps give up with "Looks like I've been suspended" after X attempts). Essentially this metadata can be treated as a write-once-read-many pair which is important to note with respect to appropriate secret storage.

By comparison static reg involves stuffing an underlying object, which isn't well documented in most libraries because it isn't really intended, with values in order to serialise it (ie. effectively bootstrap the result of dynamic reg). Since it's state can be changed from the ACCC the attributes cannot be treated as WORMs. If the variables required are not supplied by the ACCC, not specified in the Standards or Providers wish to offer optional support for others (that can't be discovered) assumptions will be made during code writing (rather than during discovery in a rigid way). As dynamic discovery is not mandated to Holders and, even if it was, is not implicitly tied to the static reg there are additional sources of deviation. Finally, if recipients are constructing these client's per microservice there is no central location that stores a rigid representation specifically agreed between recipient and holder (ie. many columns in a table vs. a serialised json response obtained through registration):

const { Issuer } = require('openid-client');
(async () => {
  // Preprocessing:
  // Some process is used to retrieve the Holder's metadata 
  // from cache or (poorer) from register everytime, I won't elaborate here
  // other than to say that it is more complex than looking up a WORM 
  // written bank->registration
  const Client = issuer.Client;
  // All of these must be supplied and are merged from multiple sources
  myClient = new Client({ client_id: "string",
id_token_signed_response_alg: "string",
id_token_encrypted_response_alg: "string",
id_token_encrypted_response_enc: "string",
userinfo_signed_response_alg: "string",
userinfo_encrypted_response_alg: "string",
userinfo_encrypted_response_enc: "string",
redirect_uris: ["uri1", "uri2"],
response_types: ["id_token", "code"],
post_logout_redirect_uris: ["uri1", "uri2"],
default_max_age: 86400,
require_auth_time: false,
request_object_signing_alg: "string",
request_object_encryption_alg: "string",
request_object_encryption_enc: "string",
token_endpoint_auth_method: "private_key_jwt",
introspection_endpoint_auth_method: "string, probably private_key_jwt",
revocation_endpoint_auth_method: "string, probably private_key_jwt",
token_endpoint_auth_signing_alg: "string",
introspection_endpoint_auth_signing_alg: "string",
revocation_endpoint_auth_signing_alg: "string",
tls_client_certificate_bound_access_tokens: true
}, jwks)
})()

2. Complexity In the static option participants get all required info from a known source and then connection can occur. In the dynamic option participants get some info from a known source but get some additional information from another source and then refresh that info from the known source again. The dynamic option is clearly more complex, and therefore more prone to error and management cost, that the static option.

More complex when assuming the value of existing implementations is zero which is plainly untrue. Also more complex when written in a Word document or drawn in a diagram over actually writing the code in question. The focus here appears to be on "some info" being "simpler" without the acknowledgement that in the static registration model metadata is retrieved from multiple sources as well. Some of these are static (ie. interpreted from the Standard), some of these are in Register, others are hardwired by Recipients themselves during implementation. As there is no explicit handshake (and therefore known negotiated "good state") between a single recipient to a single holder this opens the door to a variety of implementation variations, a variety of undocumented error states and potential "in flight" issues that won't be known until the Consumer is sitting in front of the FinTech's app. Additionally, it leaves limited options available for cooperating parties (ie. a holder<->recipient having bi-lateral agreement between them) to agree to an alternative method via third party channels while still being able to reuse CDR based infrastructure. Finally, should the ACCC seek to alter the pattern and still retain a "migratory" approach there would now be a situation where participants have to "guess" what the variation in use is. By comparison for dynamic this would be handled by the gracefully and orderly expiration/update of dynamic registrations which could be managed by Recipients as they adopt the new method.

3. Polling vs Notification The dynamic option only works with a polling model where participants (particularly holders) have to continually poll the register to ensure that the accreditation status of the recipient hasn't changed. If you change the dynamic option from polling to a notification model then you effectively get exactly the same solution as the static option but the initial load to a holder is done by a recipient. I don't see that as a simpler option.

Polling vs. Notification is neither here nor there with respect to dynamic or static. Holders will still need to regularly poll to update statuses in both scenarios. The argument for dynamic is that the recipients of focus for suspension are only those with current registrations within an individual Holder versus all participants in the entire ecosystem irrespective of whether a Holder has ever established any sharing agreement from them (ie. the List Client's call to the IdP will return a lot less data to begin with). This is a problem of logarithmic scale which is exacerbated by CDR success. Putting attack surface considerations aside the mere fact that a Holder will only be iterating over existing registrations (rather than all possible registrations) decreases the cycles required and potentially means that notification is unnecessary. That is to say that by the sheer fact Holder's are only dealing with established parties the time it takes to process a suspension is likely lower and therefore it's possible the Register could dictate the Refresh period is even smaller than 5 minutes (ie. <1 minute). Either way, as I stated to begin with, it is neither here nor there with respect to benefits of static vs. dynamic other than dynamic potentially improving the propogation time capability.

Another thought - much has been made of vendor and library support. The UK included a range of custom design features in their standards that have since be adopted by vendors and open source library. Are we assuming that the same level of support wouldn't occur in Australia?

Firstly, the "UK" referenced here is crossing the boundaries between a technical standard (FAPI+OIDC-DR), which have growing support across multiple jurisdictions (multiple European and Americas + others - spearheaded by non-profit organisations such as FData and FDE) and variations within jurisdictions which compel banks to provide data in a specified format. This is the fundamental difference between PSD2 which compels banks to provide the data versus UK's FCA endorsed OBIE which builds on this and requires banks to provide the data in a specific format.

Additionally, already sunken effort is once again being valued at zero. There is some analogous history with respect to the comparison to be drawn here, notably format wars such as VHS vs. BetaMax, PAL vs. NTSC, rail gauges. Fundamentally market adoption decided the outcome in nearly all of these cases. There is also a direct crossover to the security profile and the fact that Linus's Law says "given enough eyeballs, all bugs are shallow". The "devil you know" is another relevant colloquialism. The mere fact I find lil' ol' me being one of the loudest voices in this process only highlights further how little resource Australia has access to when making these decisions.

Putting this aside, and focusing specifically on UK vs. Australia it is a pure numbers game:

1. There are 1.5x more banks registered in the UK versus Australian ADIs (150 vs. 100)
2. There are 3x more foreign banks registered in the UK versus Australian FSBs (24 vs. 7)
3. The population is 3x in the UK versus Australia
4. Conservatively, there are roughly 3x more Fintech's in the UK than in Australia (~500+ vs. ~1500+)
5. The market capitalisation of all Australian banks is ~AUD$500 billion vs. the UK which are at least AUD$750 billion.
6. The amount of FinTech investment in the UK is >5x larger than Australia (in 2018, ~$900mil vs. ~$5 billion)

Fundamentally for vendors this turns into a decision as to whether the market is worth it. In pure customer count their potential opportunities are ~100 (vs. ~200) but in reality they are probably a lot, lot less because small ADIs in Australia typically use one of four managed platform providers (TSW, Temenos Cloud, InfoSys Cloud and another who's name evades me). So essentially these vendors are looking at "the big ones" which is probably measure in the <25 range (I suspect <10 but I'm being generous). That's not a lot of opportunities at the top of the funnel to justify maintaining entirely separated code trains and I suspect if you did the math there'd be more vendors than potential customers (this is very bad thing for competition).

For Fintech's the consideration is the possible conversion rates versus the ease of implementation. Australia represents a completely new build for 1/3 the potential customer base. By comparison the UK has existing rails (node-openid-client, NimbusDS to name a few) to use with a lot more eyeballs and support. There has been significant VC guidance that an Australian FinTech should actually be focused on Global domination not stuck in their own small backyard. If Australia chooses to reinvent solved problems that have already got adoption across at least Europe (750 million population) this actually has the potentially to DECREASE the chances of growing the FinTech ecosystem further.

Finally, this debate deviates away from a specific direction stated by the Government when the CDR was first initiated which was to base the Standards on International Standards (with a specific call out to the UK) where possible. The amount of funding allocated by the Australian government is <10% of what is believed to have been spent on the establishment of the UK's OBIE.

From my interpretation the focus of the CDR was to enhance consumer choice through the development a larger FinTech ecosystem. I question whether the intention was to create new Software Vendors (particularly Security ones) and would openly state that doing so significantly increases the timeline before any reasonable adoption, which means adoption measured in decades given the UK has been going 4 years so far and has larger access to money, resources and skillsets.

The irony is, that I find myself promoting the adoption of international standards which significantly increases the chances that Biza, which is focused on developer tools for the CDR, will be more likely to have a larger number of competitors much sooner. Alas, I find myself prioritising the overall quality and success of the CDR over the potential upsides to me personally....

[jogu]

@commbankoss and @perlboy have done a great job of writing about this, and I agree with what they say.

To call out one particular issue already mentioned in @commbankoss analysis - using the custom registry replication approach the client_id is going to be an issue (as many IDPs don't allow client_id to be selected by third parties), and I would expect that whatever solution is picked there is would mean a massive amount of unnecessary pain for at least one of the parties involved. That by itself is a pretty good argument against the custom registry. I'd also say that achieving reliable replication on that scale is likely to be fraught with issues with updates failing to occur in edge cases.

On @CDR-Register-Stream's questions:

One of the challenges we have been looking at with the Dynamic Registration model is where re-registration will need to occur. When adding to the redirect_uris fields, does this constitute a re-registration or an update to registration? Is this dependent on IDP support (i.e. some vendors will and some won't support update of registration functionality). The concern is that if re-registration does need to occur, and a new client_id is issued, do all current consent agreements now go out the window?

It sounds like this would be an update to an existing registration, using the 'client configuration endpoint' return in the registration response as 'registration_client_uri ' as defined by https://openid.net/specs/openid-connect-registration-1_0.html#ClientConfigurationEndpoint

I quickly checked around the larger vendors, both ForgeRock and Authlete support this out of the box. I believe Ping currently don't but expose a suitable API so that this can be implemented without requiring vendor changes. This way the client_id would be retained, meaning this is the simplest approach to avoid losing consents. It also means any required breaking changes to client configuration can be managed on an OP by OP basis by the RP on their timescale, which avoids outages whilst configuration changes propagate that would be seen in the replication model. (If there are other vendors that don't support it at the current time, it's going to be a substantially simpler business case for them to add support for an established international standard with existing conformance tests, compared to something specific to Australia.)

[CDR-Register-Stream]

Thankyou for the input @jogu.

Its worth noting that the UK Open Banking Standard Dynamic Registration v3.2 describes the PUT operation as a wholly optional endpoint. To consider dynamic registration in the CDR, this endpoint would need to be made mandatory in order to ensure registrations are maintained.

Does anyone have insight into the impact for their organisations on this requirement?

[SlatsFR]

ForgeRock have implemented and heavily road tested dynamic registration in the UK, Europe and a number of other countries who are investing heavily in Open Banking API's. As such, our position is that it is a well understood, adopted, effective and secure method of registering clients, which should be adopted locally to leverage the body of work and cold face experience already available. Furthermore, moving to a bespoke, non-standard approach is seen as inherently risky from an implementation approach and security perspective, and is likely to isolate our local implementation from the global audience mentioned above.

ForgeRock has overlaid our experience and the capability of our Platform (out of the box and configured for Open Banking) onto the principles outlined in the initial analysis, along with tthe comments in the 'notes' section to provide insight into our expectations of Dynamic Registration. It is as follows:

1. ACCC Rules Compliance ensuring that the solution meets the following requirements:

   a. Enable participant discovery - FR - RS and AS discovery endpoints are available to all Data Recipients provided they are using MTLS (configurable)

   b. ~5 min near real-time updates to the Data Holder of Data Recipient Status - FR - Status check is OOTB via API with ForgeRock's OB directory (Details on implementation can be provided upon request. SSA expiry is also an option. Both options are dependent upon the availability of the Registry, which as a critical core component should be available within the realms of 4 to 5 nines.

   c. Data Holders must meet their obligations when Data Recipient Status changes - FR - As per b. Provided the registry is available and updates made available, the FR Platform provides these checks as part of ongoing transactional authorisation.

   d. ACCC must be able to monitor Data Holder compliance. FR - Need more detail on ACCC's requirement to comment

   e. No Single Point of Failure - FR - FR recommends HA across the registry and all Data Holders for all components and provides well proven patterns for implementing HA where our platform is leveraged for Open Banking

2. Provably Secure: Is the solution secure and how has the security of the solution been validated. FR - ForgeRock agrees that the Dynamic Registration has been battle tested, but would also like to contest that use of SSA's are equally well tested in live environment. We have numerous clients using our SSA generation endpoint, which is an out of the box component of our platform, with penetration tests and 'in the wild' implementations proving the patterns hardness.

3. Data Recipient Developer Experience: Effort required for the data recipient should be minimised. FR - ForgeRock contests that Dynamic Registration meets this requirement. Even when leveraging a Registration JWT (for the highest level of security), which requires 3 calls, the process is extremely simple and should represent less than 2 hours work for a competent front end coder. (Our front-end developer implemented this workflow in under half an hour recently)

We have copied the three calls required to dynamically register a client using the OTTB ForgeRock endpoints. Our experience is that calling and endpoint (get SSA), obtaining the SSA token (Response) and injecting it into the

Get SSA

Generate Regisgtration JWT

Register Client

4. Open Standards: Where appropriate open standards should be used. FR - ForgeRock contends that provided the SSA is being created following the RFC's MACed JSON Web Token (JWT) [RFC7519] & JSON Web Signature (JWS) [RFC7515], Dynamic client registration is entirely compliant with the Open Standards.

5. Security Supportability: How easily does the solution integrate with existing security infrastructure - FR - Forgerock asserts that this requirement is fully met using Dynamic Client Registration. ForgeRock, along with other vendors as we understand, provides an SSA generation endpoint and logic OOTB with the platform. This represents industry support for Data Holders and Recipients should they choose to leverage it.

6. Simplicity: Solutions should aim to be simple. FR - As mentioned above, ForgeRock provides SSA endpoints and build logic in the platform OOTB. As such, custom builds are not required.

7. Meet ACCC Timelines: The solution should be implementable in the current time frame. FR - We refer to the above mentioned availability of vendor provided SSA generation endpoints, and the stated relatively low complexity of implementation for ACCC.

8. Participant Timelines: The solution should be implementable in the current time frame. FR - Vendor support of SSA generation means participants have multiple avenues available to meet this requirement in the given timelines.

@CDR-Register-Stream. The PUT operation you mention is available OOTB in the ForgeRock stack, so there is at least one viable, simple option for supporting the operation within the industry.

[perlboy]

Just a quick note here. I have historically promoted the adoption/investigation of using OpenID Federation. While I feel there are some good architectural benefits to this approach particularly from the perspective of multiple regulatory bodies (ie. AEMO for Energy) this standard is in Draft 8, has limited industry implementations, zero financial service adoption and relative to delivery timelines represents an elevated risk to implementers (not "battle tested/unknown unknowns").

With this in mind, Biza wishes to formally provide support for alignment to the MANDATORY adoption of the UK Open Banking Standard Dynamic Registration v3.2 specification with the alteration of the following OPTIONAL APIs to MANDATORY (and potentially attribute model, to be determined but this is typically configuration based anyway):

[perlboy]

Since there doesn't seem to be a thread specifically for the "forced refresh API". I would suggest consideration be given for making this API optional and then adding a light-weight explicit API to the Register (ie. something that gives a List of <Product ID, Status> pairs rather than a large blob of alpha data). To ensure propagation this could be tied to a conditional requirement on frequency of updates. This would allow Holders to make their own risk/architecture based decision to either:

1. Implement Forced Refresh API with a Variable Refresh Period (ie. once per 10 mins + on demand)
2. Perform light-weight API checks for changes within a specified metric for product(s) accreditation status. What the number is would need feedback from Holders but personally I would be targeting <1 minute which seems achievable.

To verify synchronisation has occurred, a global incrementing version (or YYYYMMDDmmss timestamp) could be stored with the metadata containing last update. This would allow the ACCC to require Holder's to publish an API exposing their current synchronisation state (ie. GET /admin/register-sync) facilitating initial propagation reporting. If the ACCC wanted to go deeper it's possible to extend this admin API to be down to a per product level (ie. GET /admin/recipient-product/{productId}).

[davidgtonge]

Just a quick note to express my support for Dynamic Client Registration. I am the CTO of a TPP (Data Receiver) in the EU and our experience has been much better with ASPSPs (Data Holders) who support dynamic client registration. Its a lot more scalable solution, for example the number of ASPSPs that we can connect to is increasing from 9 to 100+ at the moment -being able to give a piece of software some config and allow it to register with multiple Data Holders at the same time is really beneficial and I would argue more secure. Having to find a different way to manually onboard with each data holder is very frustrating and the process is often error-prone.

I'd also like to very much support the “minimisation of central infrastructure" principle. While this may appear to make things more complex it is a far superior architecture. Any increased complexity can be mitigated by the use of open standards (and the accompanying existing software that supports such standards).

Dave Tonge Co-Char FAPI Working Group, OpenID Foundation

[fahadbinrahat]

As discussion above is referring Dynamic Client Registration, just wanted to point out a requirement listed here on incident management which requires maintenance of an additional status of TPP specific to a given data holder. Does UK open banking have similar feature and if there is any coverage for this within security profile? I guess this will require implementation outside profile.

Incident Management Currently under the draft CDR rules, Data Holders within the CDR ecosystem will be able to refuse to disclose CDR data in response to valid requests from Accredited Data Recipients:

(a) where the Data Holder has reasonable grounds to believe that disclosure would create a real risk of harm or abuse to an individual or adversely impact the security, integrity or stability of the Register or the IT systems of the Data Holder used to receive and response to CDR data requests. Reliance on this exemption is to be notified to the ACCC within 24 hours; or

(b) in the circumstances set out in the standards

[jogu]

Its worth noting that the UK Open Banking Standard Dynamic Registration v3.2 describes the PUT operation as a wholly optional endpoint. To consider dynamic registration in the CDR, this endpoint would need to be made mandatory in order to ensure registrations are maintained.

This is all 100% correct.

It's worth noting that the UK specs shouldn't be taken as gospel - they are very good and have resulted in an working ecosystem, but that's not to say no mistakes were made that can be learnt from, and there are many lessons that the people on the ground in the UK can share of what worked well and what didn't.

The original UK specs (from pre-July 2017) made dynamic registration optional due to push back from the banks, which has I believe now been widely recognised as a mistake.

The latest UK specs recommend (or possibly require, I'm not sure) banks implement one of:

1) standards based mechanism for updating client configuration

2) web portal for manually updating client configuration

"1" is obviously much better for TPPs, as there's wide variability in the web portals which causes numerous issues. I believe the only reason '2' was include as an option is because of a legacy of banks who chose not to support DCR and hence made an investment into manual portals instead.

The only thing we can be sure of when building these ecosystems is that unexpected things are going to come about that are going to result in changes being required, and the best thing to do is to build a flexible system that envisages such changes being made in a way that is controlled. In the UK significant unexpected events were the EBA mandating eIDAS certificates and the FCA (effectively) mandating that non-CMA9 banks use the OpenBanking UK APIs, as well as an expected (but unfortunately not well planned for) transition from RS256 to PS256. There's no doubt at all that if all these had been known about up front the decisions made would have been different and dynamic client registration would have been mandatory from day 1 and the API for updating clients would have been made mandatory at some point.

[WestpacOpenBanking]

Westpac endorses the comments made by @commbankoss and those made by @SlatsFR regarding the benefits of dynamic registration.

We remark that assessments of the level of effort required by data recipients to participate in the regime under either model should focus on the level of code and implementation complexity rather than theoretical architectural complexities. Under a dynamic registration model both holders and recipients both able to leverage both commercial and freely available products and libraries in their implementations and minimize the level of custom coding required for bespoke Australian standards. For both recipients and holders the time and cost to design, build, manage and support products that can securely participate in the regime will be significantly reduced.

We agree that the principles identified by the ACCC are appropriate to frame the decision and have the following remarks in relation to them and each registration approach:

Principle	Comments
1. ACCC Rules Compliance ensuring that the solution meets the following requirements:	Both solutions approaches do not preclude rules compliance.
a. Enable participant discovery	Supported
b. ~5 min near real-time updates to the Data Holder of Data Recipient Status	Adopting dynamic client registration does not preclude meeting this requirement – options include SSA status checking, status update notifications, JWKS-based suspension and certificate-based suspension.
c. Data Holders must meet their obligations when Data Recipient Status changes	Adopting dynamic client registration does not preclude meeting this requirement.
d. ACCC must be able to monitor Data Holder compliance	Both solutions can meet this requirement.
e. No Single Point of Failure	Both solutions can continue to allow data sharing if the register becomes unavailable. An temporary outage affecting the ability for a recipient to register a new client has a limited impact on the regime.
2. Provably Secure: Is the solution secure and how has the security of the solution been validated	Dynamic client registration is much more closely aligned with this principle because it is minimizes or the custom modification of security infrastructure to support an untested and unproven approach from a security perspective.
3. Data Recipient Developer Experience: Effort required for the data recipient should be minimised	Dynamic Client Registration reduces effort for data recipients in the case where they take a security first approach by minimizing the amount of custom code and relying on certified client libraries to make requests. Most of these libraries are freely available.   We acknowledge that it adds friction if a handcrafted approach is taken by recipients, but believe that this is desirable to support the security of the regime.
4. Open Standards: Where appropriate open standards should be used	Dynamic client registration is much more closely aligned with this principle and the associated benefits from implementation and security perspectives.
5. Security Supportability: How easily does the solution integrate with existing security infrastructure	Dynamic client registration is supported out-of-the-box by our security infrastructure and we expect this will be the case for most data holders and data recipients using client libraries. Static registration means increased cost to design and build, test and deploy, and then manage and support the deviations from international standards.
6. Simplicity: Solutions should aim to be simple	A standards based approach will minimize the degree to which custom software must be written to interact in the regime, and hence is simplest for all participants.
8. Participant Timelines: The solution should be implementable in the current time frame	Dynamic client registration is considerably less complex for us to implement and is less difficult for us to deliver in the current time frames.

[NationalAustraliaBank]

NAB strongly recommends the adoption of Dynamic Client Registration that is based on widely adopted Open Standards.

NAB also recognises the requirement for the ACCC to play its role as the central accreditation registrar, which can be supported using software statements issued by the ACCC CDR Register upon Data Recipient registration with the ACCC. This software statement must be presented to the Data Holder's authorisation server client registration endpoint as part of the client registration request, and in turn validated by the Data Holder. This extension / hook on the authorisation server is less complex to implement compared to the current static registration proposal.

If Data Recipients want to update their metadata, the CDR Register acting as the central accreditation registrar can issue the updated software statement, and the Data Recipient can perform an update against the client registration endpoint. This aligns with the intent of the Open Standards, as well as other Open Banking implementations. This approach also reduces the complexity involved for participants to expand their offering outside of Australia, and conversely, attract existing service offerings to consider accreditation under the Australian ecosystem given the lower technical barrier to entry.

The ACCC's requirement to centrally control the accreditation status of participants, and propagate status changes in near real time must be isolated from the client registration mechanism. Not only does this allow flexibility and full control of the timings / SLAs whilst the design, rules and policy continues to evolve, it also contains the customised implementation required to meet this specific central control requirement through custom APIs (of similar paradigm to the current APIs), whilst leveraging as much out of the box capability vendor products and libraries support for Open Standards based client registration.

[anzbankau]

ANZ broadly supports the use of Dynamic Client Registration and agrees with the sentiment of other contributors regarding alignment to international standards.

As other contributors have noted the ACCC requirements can be met with either approach. A move to Dynamic Client Registration would in our view simplify the implementation for all participants.

In addition to comments made by other contributors:

• Complexity for data recipients can be reduced due to following a standards based approach as opposed to bespoke implementation.
• DCR balances implementation standards alignment and provides interoperability of the solution beyond CDR for participants.
• ACCC can continue to administer their requirements (e.g. participant status) through Admin API.

[JamesMBligh]

There is a lot of commentary here on how one solution or another is better. As @jogu has articulated, the UK made choices in this area that ended up not meeting the requirements of the regime and that this caused problems that they are still addressing. I note that, in the discussions on this topic, there is a focus on principles (which are subjective) but not on actual requirements (which are far less so). Without specific requirements there is not a real articulation of the problem.

Without a clear statement of the problem the solution chosen is much more likely to be wrong, so this is my attempt to take a stab at the requirements for the Register. I have gone through the various documents published by the ACCC as well as my own understanding of the needs of the regime to come up with this list. That said it may need some addition or correcttion.

If the solution chosen doesn’t meet these requirements then it is either deficient or the requirement is wrong. Hopefully this might help focus the design decisions somewhat and move it out of the realm of subjectivity.

Data Transfer

For the regime to function the following data transfers are required:

Holder requirements

• R01: Holder needs to know information about the recipient to support OIDC
• R02: Holder needs to know information about the recipient to support revocation
• R03: Holder needs to know information about the recipient to support Consent CX
• R04: Holder needs to know information about the recipient to support their dashboard
• R05: Holder needs to know accreditation level and status information about the recipient with ACCC attestation
• R06: Holder needs to know information about the recipient to support operations (contact details, etc)

Recipient requirements

• R07: Recipient needs to know information about the holder to initiate comms
• R08: Recipient needs to know information about the holder to support OIDC
• R09: Recipient needs to know information about the holder to support their dashboard
• R10: Recipient needs to know information about the holder to support Consent CX
• R11: Recipient needs to know accreditation level (eg. industry) and status information about the holder
• R12: Recipient needs to know information about the holder to support operations (contact details, etc)

Register requirements

• R13: Register needs to know information about recipients to support a public directory
• R14: Register needs to know information about holders to support a public directory

Data timeliness

• R15: Recipients want to be able to propagate changes to their information to all participants in a reasonable timeframe
• R16: Holders want to be able to propagate changes to their information to all participants in a reasonable timeframe
• R17: Register wants to be able to be certain that changes to accreditation status are propagated to all relevant participants in less than 5 minutes
• R18: Register wants to be able to be certain that information about security breaches are propagated to all relevant participants in less than 5 minutes

Resilience

• R19: The solution should allow new consents, revocations and data sharing to be uninhibited if the register is unavailable
• R20: The register should not be required to have high availability
• R21: The solution should allow that data consistency can be assured if the register becomes unavailable and is later restored
• R22: The solution should allow that recipient data consistency can be assured if a holder becomes unavailable and is later restored
• R23: The solution should allow that holder data consistency can be assured if a recipient becomes unavailable and is later restored

Enforcement

• R24: The ACCC needs to be able to monitor and enforce the regime
• R25: The solution must allow flexibility in enforcement capability as the specific enforcement requirements are not known and cannot be fully known until the regime is in operation
• R26: Enforcement needs will likely change over time as new industries come into the regime and the solution should accommodate this

Recipient adoption

To make the regime successful, recipients must voluntarily participate. This introduces the following requirements

• R27: Hurdles for recipient participation should be low and priority should be given to reducing their implementation and operation effort

Other

• R28: The solution should be secure
• R29: The solution should accommodate change arising from rule, standard or designation changes
• R30: The solution should be as simple as possible

[JamesMBligh]

In light of the above requirements the differing solutions suggested meet (or do not meet) the requirements as follows:

Current Documented Solution

• Meta data API for recipients
• Meta data API for holders
• Cache refresh API for recipients
• Cache refresh API for holders

Meets:

• R01 - R14, R17 - R30

Partially meets:

• R15 - Depending on the definition of “reasonable time” and the Register SLAs for periodic cache refresh
• R16 - Depending on the definition of “reasonable time” and the Register SLAs for periodic cache refresh

Does not meet:

• None

Summary: No real requirement deficiencies have been identified in the current solution that can’t be addressed with minor tweaks (such as signing or use of self hosted JWKS URIs).

Dynamic Registration

• Use of OIDC Dynamic Registration protocol

Meets:

• R01, R15, R19, R20, R21, R28, R30

Partially meets:

• R03, R04, R06

Does not meet:

• The other 20 requirements

Summary: By itself OIDC DR only deals with a subset of the data to be transferred and does not meet the additional requirements such as enforcement or propagation of holder information

Dynamic Registration + SSAs

• Use of OIDC Dynamic Registration protocol
• Use of Software Statement Assertions for additional recipient data

Meets:

• R01, R03, R04, R06, R15, R19, R20, R21, R28, R30

Partially meets:

• None

Does not meet:

• The other 20 requirements

Summary: Adding SSAs improves the transfer of recipient information but does not otherwise increase requirement coverage

Dynamic Registration + SSAs + Meta Data APIs

• Use of OIDC Dynamic Registration protocol
• Use of Software Statement Assertions for additional recipient data
• Meta data API for recipients
• Meta data API for holders
• Cache refresh API for recipients (optional if frequent polling is used)
• Cache refresh API for holders (optional if frequent polling is used)

Meets:

• R01 - R18, R23, R28

Partially meets:

• R19 - Depends on the participant implementations but register unavailability is potentially a problem
• R21 - Depends on the participant implementations but register unavailability is potentially a problem
• R22 - A holder outage means that the recipients must keep track of registration status and update when the holder is available again
• R24- R26 - Enhancements to enforcement is limited by the use of multiple mechanisms for transferring and synchronising data
• R29 - Change delivery will be impaired by multiple mechanisms for transferring and synchronising data

Does not meet:

• R20 - The register must be built for HA (only if frequent polling is used)
• R27 - Puts more requirement on the recipient increasing adoption hurdles
• R30 - The solution is now complex (multiple mechanisms, different mechanisms for different types of participants)

Summary: This has all of the mechanisms of the current solution but adds in additional complexity. The additional complexity will increase costs for recipients and for the register. It will also make the solution less robust and harder to incrementally change.

I would suggest that the analysis above indicates that the current documented solution, while it can no doubt be improved, is still superior to the significantly different options put forward to date.

Overall, I think the solution discussions have focussed too much on the needs of the holders (ie. the Banks) rather than addressing the requirements of the regime as a whole. The changes being recommended by the Banks may reduce their implementation costs (which is a good thing) but at the detriment costs of the other participants and of the overall solution. This is very much aligned to the history of the UK implementation articulated by @jogu.

[perlboy]

Content deleted. Moderated by @CDR-Register-Stream

Fundamentally, with or without it's faults the OBIE model, which by their own admission should have mandated Dynamic Registration from the beginning, is battle tested with numerous subject matter experts available for utilisation by implementing parties. This alone has significant weight given the timelines proposed and the fact the ACCC is now in an active search for Recipients who are advanced in their development of IT platform and processes for CDR, with the ability to start testing in October 2019.

As a potential Data Recipient who intends to apply to commence early testing and has a significant codebase already developed to do so, Biza.io can categorically state that the work effort to adopt the existing international standards, even with a metadata related addition to meet ACCC's requirements, is significantly lower than attempting to implement an untested, unproven and uniquely complex approach to holder discovery and registration. This is particularly salient given the fact there is currently no reference implementation with which to verify implementations against.

[CDR-Register-Stream]

All, Just a reminder of the code of conduct

All constructive contributions are very much welcome but we have little tolerance for barbed commentary on individuals.

[CDR-Register-Stream]

All, we appreciate all the input we have received. The ACCC has been going through a requirements / design analysis and is taking all input, both online and offline into account. We aim to have a resolution to this decision this week

[jogu]

There is a lot of commentary here on how one solution or another is better. As @jogu has articulated, the UK made choices in this area that ended up not meeting the requirements of the regime and that this caused problems that they are still addressing. I note that, in the discussions on this topic, there is a focus on principles (which are subjective) but not on actual requirements (which are far less so). Without specific requirements there is not a real articulation of the problem.

I'm not sure about much of this analysis (I think there are other requirements that need to be included), but I want to at least respond to and clarify one of the major points my previous comment was trying to make:

I believe we both agree that flexibility to respond to future regulatory and technical change is crucial, and that doing so should be done without adding significant complexity or difficulties for any parties involved (but particularly for data recipients) or requiring tightly coordinated change across the whole ecosystem.

However I strongly believe the system as currently architected (and documented on https://cdr-register.github.io/register/#static-client-registration ) does not meet that requirement.

As far as I understand the proposed system, (and please correct me if I'm wrong) it is based on a central registry being a single source of truth for client registrations, and those registrations are cloned out to data holders in an asynchronous fashion.

I believe the involvement of a large, new, technically challenging and never-before-implemented system that prevents direct technical communication/changes around OAuth/OIDC client registrations between the data holder (iDP in OIDC terms) and the accredited data recipient (Relying Party) is fundamentally flawed.

Making breaking changes to client registrations (for example, changing the request object signing alg or the id token signing alg) is the problem - and doing it without a 'Big Bang' style switchover (that almost certainly involves substantial downtime for the services CDR consumers want to use).

The way to avoid this kind of inevitable breakage is for the data holder and data recipient to coordinate about what change is made and when. I cannot see how adding a third party (the registry) into these interactions helps here, and I believe it actively causes harm.

The OIDC dynamic client registration & update standard is one approach that achieves the required level of coordination and flexibility (and one I strongly believe should be used), but there may be other solutions. I cannot see a way of solving this issue under the proposed centralised architecture without adding significant complexity to both the implementation for data holders and significant extra overheads for using the system (and diagnosing failures) for data recipients.

[RalphBragg]

There is a lot of commentary here on how one solution or another is better. As @jogu has articulated, the UK made choices in this area that ended up not meeting the requirements of the regime and that this caused problems that they are still addressing. I note that, in the discussions on this topic, there is a focus on principles (which are subjective) but not on actual requirements (which are far less so). Without specific requirements there is not a real articulation of the problem.

To be very clear, the primary issue for TPP's and ASPSPs in the UK is that the absence of both a Dynamic Client Registration registration capability and modification capability results in down-time for customers, a need to co-ordinate change and configuration synchronisation between parties and significant economic wastage to the point were ALL Parties are now actively implementing Dynamic Client Registration support. Not supporting Dynamic Client Registration did not result in a "failure to meet the needs of the regime" but has resulted in a tremendous economic wastage for each participant to the point where collectively the ecosystem has decided to address it.

I also think that the registry design and the need to support dynamic client registration to avoid this colossal release management headache that will result needs to be separated into different topics. It is very possible for ASPSPs to agree to support Dynamic Client Registration without needing the register to provide a "software statement generation" service. It makes a lot sense for consumers and participants to have a central "app-store" and for the federation / accreditation service to provide a Software Statement generation capability but it is not strictly necessary.

Decoupling the how registration occurs, which for the avoidance of doubt i regret not fighting harder in the UK to have banks support standards based dynamic client registration from day 1 and what validation steps a Bank must do to validate the onboarding request might make agreeing a way forward easier?

[CDSAustralia]

There is a lot of commentary here on how one solution or another is better. As @jogu has articulated, the UK made choices in this area that ended up not meeting the requirements of the regime and that this caused problems that they are still addressing. I note that, in the discussions on this topic, there is a focus on principles (which are subjective) but not on actual requirements (which are far less so). Without specific requirements there is not a real articulation of the problem.

The Data Standards Body wish to clarify that @JamesMBligh's comments are a personal view. The Data Standards Body continues to work closely with the ACCC as they define rules, requirements, and their approach to the Register.

[SlatsFR]

@JamesMBligh - you have outlined a number of requirements against which you are evaluating Static v Dynamic Registration (per the image below taken from your post). Could you please point us to the relevant documentation where these requirements are listed? I have not been able to find them.

[bazzat]

ABA Response to Dynamic vs Static Registration

Overview The Australian Banking Association (ABA) appreciates the opportunity to submit a response on behalf of those members that have been actively engaged with this issue. All four major banks and several non-majors have contributed to this submission. Collectively we agree that a change in approach to the registry design is required. We propose a solution to client registration which is both simplified and standards-based. This ensures that compliance obligations are met and that the regime is resilient and scalable. The proposed solution will differ from the current design to contain and minimise CDR specific implementation costs for both data holders and data recipients. In this submission we will attempt to highlight how the ACCC’s requirements for control and availability can be met using dynamic client registration in association with other supporting mechanisms and that the current two-way forced refresh mechanisms are not required.

Current Design – Static Register Model Currently, the registry is designed on the assumption that: • The ACCC needs control over the participant’s interactions, and; • The registry not be highly available due to concerns of creating a single point of failure.

In the current solution it is proposed that these outcomes will be achieved by creating a bespoke two-way caching notification or static registration mechanism. The approach combines design requirements which are better treated as discrete issues across content or business metadata, security, controls and the registry (see figure 1).

(Figure 1 – Current Solution)

Specifically, in the current design: • Metadata is propagated across all participants using an asynchronous / eventually consistent approach • To support the implementation of controls in this environment, significant API build bespoke integration and exception handling logic is required by all participants • The number of point-to-point interactions and data exchanged involved expands rapidly with the number of participants in a hub-and-spoke centralised topology.

Key Concerns The current design represents a specific choice to pivot away from established industry standards dynamic client registration. The industry standards in the domain have evolved past such designs, as such implementations have proven to be complex and difficult to manage at scale.

ABA members are concerned that unnecessary bespoke build and on-going running costs will be dispersed onto all participants. This creates unnecessary barriers for data recipients to enter the regime. A flow on effect will impact the regimes ability to transition into global markets in the future. This has been described by both ABA members and vendors – see: https://github.com/cdr-register/register/issues/23#issuecomment-525977835.

Data recipients will be required to build additional infrastructure to support the custom APIs under the current design, and this investment is not reusable or transferrable beyond the Australian CDR regime.

There will be a requirement to customise the build to support this bespoke design which will impact the assurance strategy proposed by the ACCC and require testing at scale to ensure rigour and to understand what impacts the end-to-end solution will have on the eco-system. We recommend that if the ACCC were to adopt a custom design that an independent security review be carried out and additionally suggest including the below design as a comparable solution to see which one would be more secure.

The Proposal Members of the ABA are aware of the time constraints that are currently affecting the ACCC’s ability to assess and provide an alternative solution that addresses industry concerns. We suggest that the problem is compartmentalised into three manageable components:

1. Establishing trust between Accredited Data Recipients (ADRs) and Accredited Data Holders (ADHs)
2. ACCC controls, defined use cases that the registry will require mechanisms to enable and disable sharing at a participant or regime level.
3. Metadata replication, business generic information such as organisation types (e.g. sole trader) that can be propagated to ADHs.

Figure 2 – Proposed Problem Spaces

Problem Space 1 - Establishing trust between Accredited Data Recipients (ADRs) and Accredited Data Holders (ADHs) We suggest that the ACCC focus initially on the first of these issues, client registration, which allows the establishment of trust between accredited data recipients and accredited data holders as this is the key dependency for industry testing plans.

There has been consistent industry agreement from ADRs, ADHs and vendors, all recognising that the most simplistic, cost effective and standards-based method of meeting the requirement to establish trust between ADRs and ADHs is by implementing dynamic client registration (DCR).

There is strong support for DCR as the preferred approach internationally as it cleanly isolates the security requirements from business content and allows a consistent approach across industries and borders. The use of established industry Standards leverages the rigorous security testing, review processes and coalface experience associated with their development. This lowers the risk of systemic design flaws and mitigates risks incumbent with aggressive and shortened testing periods.

The approach simplifies CDR industry testing which may commence without having all registry components completed.

Using signed Software Statement Assertion (SSAs) will provide appropriate integrity and trust across the participant and the payload information. The current design has gaps in these areas and imposes customisation for both data recipients and holders (e.g.: central allocation of client_ids, JWKS URI propagation in business metadata).

Typical authorisation servers do not allow client_ids to be assigned externally. In the current design each data holder would be forced to deal with this issue independently by custom development. Dynamic client registration enables leveraging of existing standard authorisation server functionality to generate client_ids. Data Holders are able to re-use existing tools, libraries and testing frameworks.

In the suggested approach, JWKs endpoints are distributed via the cryptographically verifiable SSA rather than using a custom API that only relies on transport security for trust. Again, another example of simplification gained by following an international standards based approach while at the same time enabling stronger trust within the regime.

Figure 3 – Summary of GitHub commentary positions for and against use of dynamic client registration

Problem Space 2 - ACCC controls, defined use cases that the registry will require mechanisms to enable and disable sharing at a participant or regime level. We recommend that a simplified approach to the ACCC controls problem space is adopted. The ACCC have repeatedly expressed a desire for control over the participants in the regime. There have been misconceptions expressed in relation to the current suggestion that a forced refresh API to manage these requirements is necessary and desirable. We have proposed a list of scenarios that will be required at a minimum to support secure data sharing in February. As expressed in the table below, none of these require a forced refresh. Each of these use cases could have multiple controls to ensure that each requirement is fully met within the regime.

Note: Using the forced refresh design, the control latency assume that the participants are not experiencing planned or unplanned outages at the time of invocation. As the regime expands, the probability of at least one participant being unavailable at the time of a forced refresh is very high. Approaches certainty. Further requirements in the standards to manage the scenario simply add complexity without resolving the underlying design issue.

Problem Space 3 - Metadata replication, business generic information that can be propagated to ADHs. The ABA recommends separating business and security metadata:

• The registry discovery API should only contain business-level data about participants.
• SSA should contain security data required by Authorisation Server.

The mechanism will require caching with an appropriate mandated TTL for accreditation status and optional real-time status check (to be confirmed later). By isolating and containing this business data it reduces the level of bespoke implementation which in turn increases the likelihood of delivery by the intended regime go-live date.

In both solutions participants will be required to maintain a cache and the ACCC will set agreed maximum lifetimes for participant copies. Neither scenario requires high availability, as if ADR or ADH is unavailable the last cached value can be used. In both scenarios you don’t require high availability as if the ADR or ADH is unavailable you will take the last value present. Therefore, both solutions have the same availability behaviour. An example of how this would work: if an ADH polls the status of an ADR every 5 minutes using the registry discovery API. In the event that the registry is down the ADH will continue to use the ADR statuses from the last call.

Conclusion The ABA recommends that the ACCC adopt standards-based dynamic client registration to help ensure the success of the CDR. The ABA members look forward to collaborating with the ACCC to refine and finalise this approach.

Please refer to the attached Appendix for further details, diagrams and references in support of this submission.

ABA_RESPONSE_DYvS_SA_05092019_Appendix.pdf

[CDR-Register-Stream]

All, The ACCC will be able to provide a decision result on this topic early next week.

We thank you all for the input provided so far.

[MacquarieBank]

Macquarie Bank (as both an ADH and potential ADR), endorses the comments made by @commbankoss , @SlatsFR , @bazzat (ABA) and @westpac and have a strong preference to adopt the RFC based Dynamic Registration approach for ADR Client Registration.

In relation to the proposed Static Registration model, Macquarie Bank has specific concerns that the allocation of Client Id JWKS centrally by the ACCC will require custom changes to our commercial IdP that breaks the security architecture of our IdP that already services a range of Open Banking style use cases with 3rd party partners (ie we lose control on the uniqueness of the Client Id issued). Furthermore, the required use of externally provided JWKS for Client Id’s also adds a layer of ambiguity to the accountability and security posture of Macquarie’s IdP compared to the Dynamic Registration model where this is maintained solely as Macquarie’s accountability.

In terms of relative effort, it is Macquarie’s assessment that there would be a high level of custom engineering required of any RFC Standards based IdP platform to accommodate the Static Registration approach, including a high level of ongoing maintenance of the custom engineering for every release by the commercial IdP vendor.

It is also Macquarie’s assessment, when looking at its option to participate as an ADR, that the engineering required to consume the Dynamic Registration approach would be low to trivial and aligned to existing engineering artefacts developed to connect to API based services that are part of a broader API ecosystem we operate in.

[CDR-Register-Stream]

The ACCC has made the decision to use a Dynamic Client Registration Model for the Consumer Data Right Register in Australia.

We would like to thank all contributors to this issue. We recognise a lot of person hours has gone into analysing each approach and how they affect the position of different participants within the CDR ecosystem.

Detailed clinical analysis of the available options, taking new requirements from the ACCC into consideration, has been undertaken. This included weighing up the pros and cons for each option against the ACCCs principles for Client Registration.

The Data Standards Body’s work on the Static model significantly contributed to analysis of the ACCC’s enforcement requirements and helped stimulate debate on this important issue ensuring we’ve reached the best possible outcome.

The ACCC's analysis is attached: Decision - Design Proposal 23 Static vs Dynamic Registration.pdf

Thanks again all. We will have preliminary designs out soon for review

[CDR-Register-Stream]

Further design on Dynamic Client Registration is located at https://github.com/cdr-register/register/issues/25