Standards & Guidelines regarding Sponsored Accreditation

[biza-io]

Description

We have opened this item as a changelog item because the only guidance regarding the areas of issue is that contained in Noting Paper 207 which is closed. The issues raised are a result of CDR Rules V3 amendments made 30 September 2021 and for which Sponsored Accreditation is available from 1 February 2022. Our reading of the amendments seems to indicate that a current Unrestricted Data Recipient can enter into an agreement at any time after 1 February provided they notify the "Data Recipient Accreditor as soon as practicable, but no later than 5 business days" and the Registrar has recorded on the "Register of Accredited Persons that the person is an affiliate of the sponsor" which could feasibly be done in the construct of the current Register API meeting the legal requirement but with likely unintended technical consequences.

In the interest of avoiding ambiguity:

• Data Holder: The existing definition of a Data Holder
• Sponsor: An accredited person carrying an unrestricted accreditation level entering into a sponsorship agreement
• Affiliate: An accredited person carrying a sponsored accreditation
• Register of Accredited Persons: The ACCC Register API. We are aware this isn't a "perfect" alignment however we note that for the purposes of Standards the "the Accreditation Registrar must, in the manner the Registrar thinks fit, make the following information publicly available" so we assume this is done so via the Register API
• Consumer: The CDR Consumer

We acknowledge the areas outlined here are likely to not be complete with regards to the likely changes to the Standards.

Display of Affiliates Name within Data Holder Dashboard

Under 1.10D (2) a Sponsor may collect data on behalf of the Affiliate:

As a consequence of this, such data collection may occur using the sponsors information security registration and, subsequently, the Data Holder will only have visibility of the Sponsor. This item was highlighted by the DSB in NP207 but we are not aware of any Decision Proposal to resolve it:

The Holder Dashboard therefore is likely to have information which is not aligned with the Recipient Dashboard especially as the accredited person now appears to incorporate sponsored affiliates.

Display of Sponsors Name & Accreditation Number within Affiliates Dashboard

The dashboard operated by an affiliate must display the sponsor's name and sponsor's accreditation number:

These requirements are not currently incorporated in the CX Guidelines. Noting Paper 207 stated that "No additional CX Data Standards are anticipated for this item" however the rules incorporate this information as part of "details of each consent" so we are left to ask whether such a statement is incorrect.

Authentication to a Sponsors Dashboard

It is unclear how (or if) there is an expectation that a Consumer will be required to authenticate to the Sponsors dashboard for the purposes of managing arrangements. In certain situations (like where the Sponsor is collecting on behalf of the Affiliate) this may be the only method of managing arrangements yet there does not appear to be any such Standards relating to this and it is very unclear how this would be smoothly managed for the Consumer.

Identification of Accreditation Type in the Register API

There is currently no prescribed method of identifying the accreditation type within the Register API. This appears to be stated as a mandatory requirement within the amendments to Division 5.3, 5.24:

Area Affected

• CX Guidelines
• CX Standards
• Register API

Change Proposed

Biza.io continues to question the viability of authorisation chaining that is not cryptographically bound and, while highlighting this via various industry body submissions since 2019, again looked to highlight this without entering a technical deep dive in our response regarding Rules V3 ("Data Disclosure Traceability"). We continue to believe that the most effective means of communicating multi-level consent is likely an encapsulated cryptographically signed consent descriptor.

Nonetheless, as time is now of the essence and not wishing to delay the activation of Affiliates by February 2022 we propose the following tactical changes:

1. Display of Affiliate Name in Data Holder Dashboard

   a. Introduce a dataRecipientBrandType into dataRecipientBrands attribute of RegisterDataRecipient allowing for the disclosure of SPONSORED vs. UNRESTRICTED and within which the software product of the Affiliate could be contained (allowing for Holders to render such implications). (Possibly) introduce a dataRecipientBrandSponsorId attribute to allow for explicit linking of an Affiliate to a specific Data Recipient Brand.

   b. Specify CX Guidelines related to the disclosure of the Affiliate Name in the Data Holder Dashboard.

2. Display of Sponsors Name/Accreditation Number

   CX Guidelines should incorporate Sponsorship details within the Data Recipient dashboard

3. Authentication to Sponsors Dashboard
   Specify a CX Standard that an Affiliate must provide a Dashboard, accessible via its existing authorisation channels (or potential within its software product directly) that directly manipulates the arrangements collected on its behalf by the Sponsor.

4. Identification of Accreditation Type in the Register API

   This is likely resolved by proposed change 1(a).

[CDR-API-Stream]

Hi @biza-io thanks for raising this. There is a fair bit to address in this issue. Just touching on the consultation earmarked in NP207, this was anticipated as a future consultation once v3 rules related standards were finalised. This issue was deprioritised due to the extent of v2 and v3 rules obligations on DHs and other issues identified in NP207.

Given the community request to address this topic (including this issue), we will bring forward the DP consultation on this subject and consider the feedback presented in this change request.

[RobHale-Truelayer]

TrueLayer supports the indication of @CDR-API-Stream to bring forward consultation on this subject and suggest there would be merit in extending the scope of that work to include all access arrangements discussed in NP207.

Thank you @biza-io for describing a range of identified issues and proposing potential solutions associated with the rapidly approach Sponsor/Affiliate model 👏.

There are also potential issues with the (already active) Principal/Representative model that would benefit from adjustments to metadata in order to adequately represent relationship attributes where a single software product is used by multiple representatives. This would support better consumer experiences where intermediaries are used to collect data.

We are concerned that one potential 'easy' solution might be to advise intermediaries to allocate a unique software product to each representative. This would be highly problematic for those planning to offer a platform product at scale. Aside from negating the commercial viability of this approach, it would also create very real practical issues for things such as client certificates, IDs, deployment of changes across products and CTS retesting.

We would appreciate CX Guidance and a Register Attribute Review being deemed as prioritised activities to enable design and engineering teams currently working on solutions to have confidence that they will be compliant and that the CX for consent, authorisation and dashboard functionality can clearly communicate the role of all parties involved.

This work will benefit any ADR considering an alternate access arrangement.

[biza-io]

We note the following notice from the ACCC related to the issues highlighted by this ticket:

To whom it may concern,

We are writing to inform you of the upcoming implementation of Sponsored Accreditation to the CDR Register as per Version 3 of the Rules announced on 5 October 2021.

From 1 February 2022, when Data Recipients are accredited at the Sponsored level, they will be included on the CDR Register of Accredited Persons.

Accredited Data Recipients (ADRs) at the Sponsored level will not have a Software Product, and instead rely on a Sponsorship Arrangement with an Unrestricted ADR to collect CDR data on their behalf.

Data Holders – what this means for you:
· Data Recipients accredited at the Sponsored level will commence appearing in the Get Data Recipients API, and can appear as ACTIVE, without a Software Product. Please ensure that your solutions can cater for this scenario.
· Please ensure that your solution aligns with the existing Consumer Data Standards, where a Data Holder must be able to consume an empty array on the Software Product.
If you require any assistance in relation to this matter, please do not hesitate to contact the CDR team via [email protected] or via the CDR Service Management Portal.

Consumer Data Right Team
Incident and Problem Management | Consumer Data Right
Australian Competition & Consumer Commission
Level 2, 23 Marcus Clarke St, ACT 2060 | www.accc.gov.au.

We wish to highlight, once again, and not withstanding the technical issues outlined, that with this communication the following behaviours will be experienced by all data holders:

1. Consent flows will reference the sponsoring entity. For instance if Joes Finance enters into a sponsorship arrangement with Frollo, all consent flows presented by the Holder will be in the name of Frollo. Additionally the legal entity details will be those of Frollo. It is therefore unclear as to whether this constitutes a legally binding consent between the Consumer and Joes Finance as Joes Finance will never be exposed during the prescribed consent flow
2. Dashboards will be grouped by sponsoring entity. Once again, taking the Joes Finance sponsored by Frollo situation only Frollo will be displayed and there will be no way of differentiating sharing arrangements between Frollo or Frollo sponsored entities

Further we note the following:

1. Sponsored entity Data Recipient Status changes within the Register will have no effect on Holder installations as there is no way to correlate such changes to impacted arrangements
2. Sponsored entity Data Recipient Status changes will, by definition, be forced to cascade to Sponsoring entities as there is currently no other way to alter the status of arrangements associated with a Sponsored entity. This has the perverse impact of potentially causing all arrangements of all sponsored entities within a single ADR to be revoked. While a Sponsoring entity can be directed to issue revocations there is no technical mechanism defined nor mandated
3. While the ACCC message states otherwise the following statement exists within the Standards "When the CDR Registrar changes the accreditation status for a Data Recipient for any status other than active, the associated Software Product statuses MUST be changed accordingly." . It is unclear how this binding requirement on the Register will be achieved.

[ShaneDoolanFZ]

We support @biza-io's suggested change to introduce additional metadata to allow Data Holders to give clear guidance to consumers about the data disclosure that is occurring. We also agree that data disclosure traceability is crucial. We think it must be maintained regardless of the access model that a Data Recipient participates in CDR under.

Data disclosure traceability and accountability in CDR is strong with the current software products model. A software product belongs to a Data Recipient. A software product is registered with a Data Holder by way of dynamic client registration. A client ID is issued by the Data Holder to a Data Recipient for that particular software product. Authorizations are then made with that client ID. There is no grey area.

Adatree has already built for Principal/Rep at scale with the current standards that are in place in order to maintain strong data disclosure traceability. I agree with @RobHale-Truelayer that it is the 'easy' route for the ecosystem but it's also on the right path for data disclosure traceability. Yes, the complexity on intermediaries is increased but that's why the intermediary model exists, to handle complexity.

To completely abstract a downstream ADR client behind the software of a Sponsor/Principal would be to introduce grey into the data disclosure process and erode traceability. We think as a rule of thumb authorization should become more accurate and not less. Management of multiple IDs and associated certificates at scale is not something that modern multi-tenant software should be too concerned with and absolutely shouldn't drive ecosystem policy. The ecosystem must not fit the technology, the technology must fit the ecosystem, and the ecosystem's intent has always been traceability and accountability. Without individual consumer facing software being represented at a client level at a Data Holder there is no disclosure traceability within the ecosystem aside from within Data Recipient Sponsor/Principal platform solutions themselves. Might this be good enough? Regardless of whether it works or not it is a step backwards for the ecosystem in our opinion. Transparency has been demanded from Data Holders. We feel Data Recipients of any nature should be held to the same standard.

Consumers give consent to disclose data to use a product or service. A data collection platform is not a product or service of any relevance to a consumer. It is an ecosystem implementation detail. A facilitator of disclosure. We don't think a consumer should be giving authorization to a client ID at a Data Holder that is attached to a data collection software product that also encapsulates hundreds of other downstream software products.

We propose:

• Maintain the existing ecosystem design where consumers consent to disclose data to a software product that is directly providing them with value.
• Introduce additional ADR metadata as suggested by @biza-io to allow Data Holders to effectively convey to the consumer what parties are involved in the data disclosure process and who is ultimately the recipient of the data being disclosed.
• Allow Sponsor/Principal ADRs to create and maintain software products on behalf of their customers through the CDR Portal and via API.
• Introduce automated provisioning of certificates through the CDR Portal and via API.
• Allow the Sponsor/Principal ADR's CTS report to be used by when considering a downstream ADR's software product activation at the Register provided the Sponsor/Principal ADR's platform is being used to facilitate all data collection. This should address scaleability concerns around CTS.
• Require CTS testing of Sponsor/Principal ADRs at a defined cadence (or maintenance of FAPI Relying Party consumerdataright_au certification by the Sponsor/Principal).

The benefits of the above are as follows:

1. Data disclosure traceability and accountability is maintained for the consumer and the rest of the ecosystem in general.
2. Minimal changes are required to the Register to begin with. It should be relatively straight forward to add the additional metadata describing the Sponsor/Principal relationship to then be displayed by the Data Holder. Automation of software product and certificate provisioning can be introduced over time when bottlenecks inevitably begin to occur because of demand. This, coupled with the Sponsor/Principal CTS report covering all data collection activities, should address any scaleability concerns. We don't believe picking the right client certificate for a client ID is a real issue.
3. No changes required to the actual authorization mechanism for Data Holders. A software product is a software product.
4. Rotation and revocation of certificates can continue to be done at a software product level and will only affect individual representatives.
5. The Registrar(s) maintain the ability to make individual software products ACTIVE or INACTIVE without affecting other participants.
6. Provided Data Holders are willing to work with ADRs to migrate JWKS endpoints, the opportunity for the portability of consents granted to a downstream ADR's software product from one Sponsor/Principal ADR to another is maintained because the software product ID, client certificate and client IDs all belong to the customer ADR and not the Sponsor/Principal ADR. This promotes competition between Providers whereas forcing your consumers to re-consent in order to change Providers would be a significant contributor to vendor lock-in.

Again, in our view the above is in fact the 'easy' solution for the ecosystem but also (currently) the only one to maintaining authorization integrity within it. We don't think it should be degraded to accomodate the system design choices of individual participants. Adatree will support any proposed changes to increase the accuracy of data disclosure traceability but we feel we must oppose anything that could potentially reduce it.

[ShaneDoolanFZ]

Consent flows will reference the sponsoring entity. For instance if Joes Finance enters into a sponsorship arrangement with Frollo, all consent flows presented by the Holder will be in the name of Frollo. Additionally the legal entity details will be those of Frollo. It is therefore unclear as to whether this constitutes a legally binding consent between the Consumer and Joes Finance as Joes Finance will never be exposed during the prescribed consent flow

@biza-io our understanding is that consent referencing the sponsoring entity would contravene the below from https://www.legislation.gov.au/Details/F2021L01392:

1.10AA Meaning of CDR representative and related terms

Note: From the point of view of a CDR consumer who is the customer of a CDR representative, the consumer deals with the CDR representative, as if it were an accredited person, and may not deal with the principal at all. The consumer requests the goods or services from the CDR representative; the CDR representative identifies the CDR data that it needs in order to provide the goods and services; the consumer gives their consent to the CDR representative for the collection and use of the CDR data. The consumer is informed that the CDR principal will do the actual collecting, but as a background detail.

Edit: As @biza-io has kindly pointed out their point is related to Sponsor/Affiliate and not Principal/Rep model.

[perlboy]

We are concerned that one potential 'easy' solution might be to advise intermediaries to allocate a unique software product to each representative. This would be highly problematic for those planning to offer a platform product at scale. Aside from negating the commercial viability of this approach, it would also create very real practical issues for things such as client certificates, IDs, deployment of changes across products and CTS retesting.

Just going to callout here that allocating a software product to sub-parties in all models will be challenging because Software Products belong to Brands and Brands belong to Recipients which are linked to Legal Entities. There is currently only an inherited legal entity identifier from 2 levels up the tree outlined in the (redacted during merge of Register into CDS Standards) historical Register standards:

Despite it no longer being located in the "Standard" the JSON structure doesn't lie. This therefore flies in the face of CX Guidelines which explicitly promote the use of legal entity details:

CDR Rules require data holders to refer to the accredited person's name using the legal entity name held in the Register during Authorisation. [...]

Data holders should surface the legal entity name of the data recipient associated with the authorisation

Essentially, irrespective of the accreditation status the legal entity will show the Unrestricted ADI providing service (via whatever means). The only other pathway would be to have every downstream entity created at the top level with essentially no link to the sponsoring entity. Speaking of which a UK colleague mentioned that they solved it by introducing OnBehalfOfObOrganisation:

        OnBehalfOfObOrganisation:
          type: string
          description: A reference to fourth party organisation resource on the OB Directory if the registering TPP is acting on behalf of another
          maxLength: 40

[CDR-API-Stream]

Note that interim guidance, that can be used while changes to the standards are agreed and implemented, has been posted at: ConsumerDataStandardsAustralia/standards#228

[RobHale-Truelayer]

Although we acknowledge there is now a related noting paper, it seems appropriate to continue the dialogue in the context of other responses. We'll provide a direct comment within 228 in due course.

It's great to see the range of well-considered ideas and proposed adjustments emerging through this issue, particularly those from @ShaneDoolanAdatree 👏 👏

We would support the following earlier suggestions:

• Introduction of additional metadata to support the Rep model arrangements (per @biza-io suggestions)
• Ability to create and maintain software products via API (per @ShaneDoolanAdatree suggestion)
• Automated provisioning of certificates via API (per @ShaneDoolanAdatree suggestion)
• Allow sponsor/principal CTS report to be used for downstream software product activation (per @ShaneDoolanAdatree suggestion)

These would go a long way towards overcoming real, shared issues that ADRs have identified and flagged, specifically, the:

• Operational burden for intermediaries wishing to add new software products at scale
• Friction associated with onboarding new Representatives
• NFR implications that could result in DH rate limiting against a single software product
• Questionable benefit of CTS for replica ADR software product deployment

This approach would also allow intermediaries flexibility to offer a SaaS platform for Representatives with reduced risk in terms of instant and universal application of patches, fixes, enhancements etc on a single, existing, tested and operationally proven codebase.

It is perhaps also worth re-stating here that, while Affiliate and Representative models both raise similar technical issues, there is a fundamental difference in that the Affiliate relationship involves 2 x ADRs. This allows the Affiliate's accreditation to be suspended or revoked independently of the Sponsor. With the Representative model, there is only 1 ADR, the Principal so another mechanism is needed in order to discriminate, and the multiple software product arrangement enables this.

These proposed adjustments potentially resolve all but one identified issue - that of certificate management under the Representative model. While this can be managed by the ADR platform, there is room for debate here in terms of whether it is appropriate for an entity that is not collecting data to be issued with a client certificate.

We therefore encourage further discussion and debate on the following points:

1. Rather than associating client certificates with a software product, would it be more appropriate if they were issued to the entity collecting the data (meaning the principal or unrestricted ADR)?
2. Would it be appropriate to remove the binding of client ID to software product, and revert the authentication entity on the register to be that of the ADR?

We would also appreciate advice from ACCC/DSB on these two items:

• The potential Legal Entity issue raised by @biza-io here - Standards & Guidelines regarding Sponsored Accreditation #427 (comment)
• CX Guidance for alternate access arrangements

[CDR-API-Stream]

To help manage the scope of issues being discussed through the standards maintenance process, issue #508 has been raised so the impact of improving the scalability of onboarding software products can be prioritised separately.

Issue #508 will discuss the following requests were raised by ShaneDoolanAdatree:

• Allow Sponsor/Principal ADRs to create and maintain software products on behalf of their customers through the CDR Portal and via API.
• Introduce automated provisioning of certificates through the CDR Portal and via API.

[CDR-CX-Stream]

The below responses are provided as an update to 427's progress:

Display of Affiliate Name in Data Holder Dashboard
The representation of CDR participants in DH spaces will be covered in DP229, including Affiliates and CDR Representatives. This consultation plans to cover various access models, including where multiple clients/consents are established under a single software product, and/or where a unique software product is supplied for each client (as outlined in in NP228). Issue 508 will progress a related issue concerning software product onboarding.

Display of Sponsor's Name/Accreditation Number
This requirement is determined by the rules and was reflected in the CX Guidelines released in December 2021. See the 'Sponsorship arrangement' section on this page.

Authentication to Sponsor's Dashboard
While the rules outline legal obligations relating to specific entities and items, in practice dashboards can be provided by the affiliate where the sponsor is collecting data on the affiliate's behalf, and the sponsor only needs to be noted to the consumer as a background detail. Further, as per rule 4.3(2B)(b) in subdivision 4.2.2, 'a consent for the affiliate to collect the CDR data is taken to be consent for the sponsor to so collect it.' The CX 'Sponsorship arrangement' guidelines for dashboards and consent were developed to reflect these points.

Identification of Accreditation type in the Register API
The DP229 consultation will provide the opportunity to discuss this proposal further.

[perlboy]

I believe this thread and the scope of change required will need to be assessed again based on the "other operational enhancements" additions in the latest rules draft: https://treasury.gov.au/consultation/c2022-315575