Clarification of data recipient identifiers

[commbankoss]

Commonwealth bank seeks clarification on data recipient identifiers.

https://cdr-register.github.io/register/#getdatarecipients has the following identifiers:

legalEntityId
list of dataRecipientBrandId
and a list of associated softwareProductIds

https://cdr-register.github.io/register/#getdatarecipientsstatus has the following identifiers:

dataRecipientId

SSA https://cdr-register.github.io/register/#client-registration has the following identifiers:

orgId
softwareProductId

1. Could ACCC please align and map the identifier linking all three payloads?
2. CX guidelines require Data Recipient Identifier to be displayed by Data Holders to the Consumer during authorization (CX Guideline 1 4: Data holders SHOULD show the ACCC provided CDR branding and details of the request including a data recipient identifier, and the date the request was made.) Which identifier out of the above is suitable and should be displayed for this purpose?

[perlboy]

Agree, clarification is required.

I was of the understanding all required data was supplied during the SSA process, notably these fields for "identifier":

However, on review the need for an accreditation number is articulated due to the CDR Rules which specify in 4.11 (3):

Something tells me the lawyers who wrote the rules didn't consider that the accreditation number would be a 128bit UUID and the CX people assumed it would be 5 digits long rather than 32 alpha characters. Additionally the Register API contains no explicit accreditation detail at the moment.

[CDR-Register-Stream]

@commbankoss Thanks for your query.

Question 1 The Ecosystems entity section of the documentation outlines the linkages for these identifiers:

Identifier	Mapping
legalEntityId	Identifier in LegalEntityDetail schema returned as part of GetDataHolderBrands API Identifier in RegisterDataRecipient schema returned as part of GetDataRecipients API
dataHolderBrandId	Identifier in RegisterDataHolderBrands schema returned as part of GetDataHolderBrands API
dataRecipientBrandId	org_id claim as defined in the SSA Definition Identifier in DataRecipientsBrandMetaData schema returned as part of GetDataRecipients API
softwareProductId	software_id claim as defined in the SSA Definitioniss claim as defined in the Registration Request

It is apparent that it is still challenging to interpret which identifiers are equivalent so I have raised issue #93 to add additional clarification throughout this documentation.

Question 2 The GetDataRecipients API call was optimised for the DH Consent Dashboard use case with the intention to extend it as additional fields become required. As @perlboy has pointed out, there really isn't a human readable value being returned via that API. The Accreditation Number is the appropriate field and we are planning on exposing that as part of the GetDataRecipients API.

However, there is an oppounity for DHs to innovate here and display additional information beyond the CX guidelines. To facilitate that innovation, the Register would need to open up additional details. I have raised issue #94 to elicit feedback from the community on what other fields would be of value here.

[perlboy]

Exposing the accreditation number with the GetDataRecipients API is fine but the SSA should include it to ensure that the cryptographic assertion the ACCC provides includes it's accreditation number.