Addition of an (18 or over) Age Verification Flag

[jimbasiq]

As a service provider operating under the Open Banking framework guided by the Competition and Consumer (Consumer Data Right) Rules 2020, we aim to ensure that we consistently adhere to and enhance the standard protocols to serve the best interests of our consumers.

We would like to raise a change request with respect to the API standards to enhance the clarity and security around consumer data sharing. The specifics of our request are as follows:

Addition of an (18 or over) Age Verification Flag:

We propose the introduction of a flag in the API response to clearly indicate if a consumer is 18 years of age or older. The key intention behind this is to simplify and enhance the verification process for CDR eligibility or for an ADR provided product or service.

Exclusion of Date of Birth: To underline our commitment to consumer data protection, we are not seeking the direct provision of the consumer's date of birth. We acknowledge and appreciate the potential security risks associated with sharing such sensitive information. Integration with Personal Information Entity: This age verification flag can be seamlessly added to the existing 'personal information entity' structure in the API response.

Support by Existing Rules: The current framework, under the Competition and Consumer (Consumer Data Right) Rules 2020, establishes that only individual consumers over the age of 18 are eligible to receive CDR data. This effectively implies the confirmation of this flag, and our request is to formalize this check in a more technically explicit manner.

Support for Future Rules: It could be argued that the CDR rule above could be used to infer the age of a person to be 18 or over. We believe this type of inference is risky. This change would also support the inclusion of sharing CDR data for consumers under 18 if required in the future.

Nature of the Request: Given the implicit presence of this capability within the existing rules, we don't view this as a change in the standards but rather as an enhancement that will bring about clarity and improved operational efficiency.

Technical Details: Add a new flag attribute (e.g., isConsumer18OrOlder) in the personal information entity in the Get Customer API response.

In raising this change request, we seek to bolster the efficacy of the API standards in alignment with the prevailing regulatory framework. We firmly believe that such enhancements will enrich the user experience while preserving the integrity and trust that Open Banking endeavors to maintain.

We eagerly await your feedback on this proposal and remain at your disposal for any further clarifications or discussions.

[markverstege]

Hi @jimbasiq the CDR rules include eligibility requirements whereby an individual consumer must be 18 years of age or older. If you are obtaining consumer data through a valid CDR authorisation, this implies the individual is 18 years or older. An (18 or over) age verification flag seems to be redundant in this situation.

Out of interest, would a verified credential be useful for scenarios like this? We are considering how VCs might be shared through the Data Standards for a variety of use cases and age verification as a verified insight is one of those (e.g. Is the consumer above 67 years of age?).

[perlboy]

FWIW and I'm not so sure any Holder is doing this but the eligibility rule could be read as a "minimum", i.e. voluntary <18y/o access. I don't think that's actually the case anywhere though.

Footnote, for this use case I would have thought IDA was more aligned?

[jimbasiq]

Hi @markverstege

Thanks, we are aware of the CDR rules regarding eligibility requirements whereby an individual consumer must be 18 years of age or older. We have a low confidence all DHs are aware of this or have implemented this restriction so would like to see something explicit rather than inferred.

I will try to make the next Maintenance Iteration meeting to discuss this one. Apologies I was not able to make the last session.

@perlboy IDA will be tightly coupled with the authenticated user. I understand that Get Customer Detail is also coupled currently i.e. "Obtain detailed information on the customer that has authorised the current session" but thinking ahead it makes sense to me that this may not always be the case.

[markverstege]

Thanks @jimbasiq. If you believe that DHs aren't aware of their compliance obligations or they are not complying with them, then the best course of action is to engage with the ACCC. I'm wary of introducing an age verification flag where it is a restatement of the eligibility criteria. Definitely agree this would be good to discuss in the maintenance iteration to explore the issue in more detail with Data Holders.

Regarding Get Customer Detail, the data returned is the data of the consumer, not the authenticated end user. For individual consumers these will be synonymous, however for non-individual consumers it will represent the data of the consumer and not the nominated representative, other than the agent fields which are included to represent the nominated rep's details.

[markverstege]

Hi @perlboy, you're right, OpenID for Identity Assurance could be a more natural fit compared to verifiable credentials for proof of age if the ADR doesn't need to present that claim in a non-repudiable way to other parties. Sharing of verification document metadata and verification evidence might be tricky however, so the verifiable claim could just be the claim value and trust framework information.

[AGL-CDR]

Thanks, we are aware of the CDR rules regarding eligibility requirements whereby an individual consumer must be 18 years of age or older. We have a low confidence all DHs are aware of this or have implemented this restriction so would like to see something explicit rather than inferred.

AGL can confirm that we take our obligations with the utmost gravity. I'm unclear on whether the introduction of this flag would alleviate the risk that there are (apparently) DH's out there that do not share this view.

If a DH cannot be trusted to adequately manage fundamental eligibility obligations, can they be trusted to pass ADRs a 'more trust worthy' age flag? Moving away from implicit to explicit assurance of eligibility because of a lack of trust feels to me that product decisions are being made that really ought to be independently verified and this should not be coming from Data Holders.

[jimbasiq]

Updating this proposal after Yesterday's discussion for the field to be added under the Customer to be an age range Enum e.g. { Unknown, Under 18, Over18 }

This would enable the addition of other age range Enum values in the future e.g. { Unknown, Under 16, Under 18, Over18 }

[markverstege]

Thanks @jimbasiq. As discussed in the call this issue will be taken to the Treasury Rules and OAIC teams for discussion and their guidance because of the privacy considerations.

We hadn't discussed under 18 ranges as flags in the call and given the CDR rules make clear an individual is eligible over 18 years of age, including 0 - 16 and 17-18 year old range may raise further privacy questions and compliance considerations.

One thing I'm interested in understanding with this approach is how an enumeration could scale in future if ADRs were interested in different demographic ranges (e.g. 39 - 55, 56 - 65, vs 35-50, 51-67, etc)? For example, the pension age has changed upwards over the years and other age-related milestones may move into different age ranges over time.

[jimbasiq]

I agree @markverstege it is a tricky subject. I reviewed some standards such as : https://www.abs.gov.au/statistics/people/population/regional-population-age-and-sex/latest-release https://www.indexmundi.com/australia/age_structure.html https://www.aihw.gov.au/reports/australias-health/profile-of-australias-population#:~:text=Figure%201%3A-,Demographic%20snapshot%202021%E2%80%9322%C2%A0,-A%20chart%20showing https://www.nih.gov/nih-style-guide/age - this one actually makes most sense to me.

Further investigation into a standard that could be adopted would be my suggestion.

As for under 18 categories, I am just trying to think about the future. Right now we should have no under 18 consumers. When we do we should be aware of their age range.

[commbankoss]

CBA agrees with previous feedback that data holders are responsible for complying with the CDR rules, which includes applying CDR eligibility criteria and enabling data sharing for valid authorisations. Further, CBA notes that given one of the eligibility requirements for consumer participation in the CDR is >18, the flag is superfluous and would not warrant the related ecosystem costs incurred from implementing this scope.

Given separate legislation is being proposed to regulate Digital Identity systems, CBA understands the intent of the Australian Government is to maintain Trusted Digital Identity and the CDR under separate regimes. Under the Digital ID Bill, a framework enabling Australian citizens to share, with consent, their Digital Identity and related attributes is being enabled and regulated. Further, CBA notes that banks are not the primary source of identity, including age, related data.

Decisions regarding future scope of the CDR, including expanding eligibility to Australians under 18, must be prioritised by balancing policy objectives, and maximising consumer outcomes (security, privacy, utility). Given the broader policy and regulatory implications, this issue should undergo formal consultation through Treasury and the ACCC, rather than the Data Standards. Accordingly, CBA does not support the sharing of identity including age related attributes via the CDR.

[markverstege]

Hi all, acknowledging that the issue has been outstanding for some time in the Maintenance Iteration, it is being actively reviewed within the DSB and our counterparts at the Treasury from a rules perspective. We intend to provide a response back to this thread when it is available and discuss further in the Maintenance Iteration.

[CDR-API-Stream]

Hi @jimbasiq upon further discussion with the CDR agencies please see below:

The CDR eligibility rules limit CDR participation to persons over the age of 18 years, and specifically exclude the sharing of data with respect to account holders who are under 18 (e.g. for joint accounts and partnerships accounts). Therefore, it would be inconsistent with the current CDR policy for standards to include a field that could identify individuals as under 18.

The CDR rules also restrict the sharing of an individuals' date of birth. This doesn’t rule out the possibility of standards to support a field with enumerated age ranges (e.g. 18-24, 25-29, etc). However, we consider this approach would require further consideration, including how it could be used in relation to identity services.

[CDR-API-Stream]

As agreed in the MI meeting on 29 May 2024 this issue will be assessed against the Framework (refer Noting Paper #346). The DSB will then take this through a future iteration when it's ready.

With regard to eligibility error handling, raised in relation to this issue, we would recommend this be raised as a separate change request.

This issue will remain on the backlog while the DSB undertakes further analysis.