Nominated representative end user for non-individual consumers

[CDR-API-Stream]

Description

The issue of the subject identifier for the logged in user and the relationship to the consumer was raised in the Maintenance Iteration call on 20th October 2021.

Whilst implied, the data standards are not clear on the relationship between the logged in user and the associated customer data. This may create some ambiguity for non-individual consumers and nominated representative scenarios.

A nominated representative is a named individual (person) who is authorised to establish data sharing consents for the non-individual consumer (e.g. a business or trust). The OIDC sub pairwise identifier and details returned in the ID Token and UserInfo endpoint represent the logged in user (for a non-individual consumer this is the nominated representative e.g., the business agent acting on behalf of the business). If the ADR requests the user consent to sharing data related to the OIDC profile scope, this would relate to the logged in user not the non-individual consumer.

However, the customer data collected via the Customer APIs is the customer data of the non-individual consumer.

If more than one nominated representative is assigned by the non-individual consumer, then the all consents are established on behalf of the consumer and the ID Permanence requirements pertain to the consumer not the logged in user.

For individual consumers where the account holder is the person authenticating and authorising the data sharing, this is not an issue. The data associated to the logged in user is the data of the consumer because the individual is the authenticating party and the customer of the data holder.

Non-Individual use case

Take for example, Bob, Jane and Sally who all work for Paddington Wholesale Florists. Paddington Wholesale Florists have business accounts established with Happy Bank. Paddington Wholesale Florists use First Accounting, an online accounting and ecommerce platform to sell flowers and manage their accounting. First Accounting is accredited as a data recipient within the CDR. To connect their bank accounts using the CDR, Paddington Wholesale Florists nominate Bob and Jane as their nominated representatives with Happy Bank. Happy Bank offers its customers the ability to manage nominated users who are permitted to set up CDR consents via the Happy Bank internet banking app.

Bob looks after all the accounting and needs full access to all banking and customer data. Jane looks after online sales and only needs access to the transaction account history.

Scenario A Non-individual consumer = Paddington Wholesale Florists Nominated Representative 1: Bob Nominated Representative 2: Jane Data Holder = Happy Bank ADR = First Accounting Consent 1: Account ABC, Account DEF Consent 2: Account DEF

In Scenario A,

• For Consent 1, the UserInfo details represent Bob's first name, last name and associated profile information
• For Consent 2, the UserInfo details represent Jane's first name, last name and associated profile information
• For both consents, the accountIds are the same (they do not change because the consumer has not changed, only the nominated representative)

Scenario B Bob leaves the Paddington Wholesale Florists business and Sally takes over the accounting. Paddington Wholesale Florists nominates Sally as a nominated representative. Paddington Wholesale Florists also removed Bob as a nominated representative and updates the user details with First Accounting. The consents established by Bob remain active because they are consents to share data authorised by Paddington Wholesale Florists.

Non-individual consumer = Paddington Wholesale Florists Nominated Representative 1: Nominated Representative 2: Jane Nominated Representative 3: Sally Data Holder = Happy Bank ADR = First Accounting Consent 1: Account ABC, Account DEF Consent 2: Account DEF Consent 3: Account ABC, Account DEF

In Scenario B,

• For Consent 1, the UserInfo details represent Bob's first name, last name and associated profile information
• For Consent 2, the UserInfo details represent Jane's first name, last name and associated profile information
• For Consent 3, the UserInfo details represent Sally's first name, last name and associated profile information
• For all three consents, the accountIds are the same (they do not change because the consumer has not changed, only the nominated representative)

Area Affected

• CDR Federation
• Scopes and Claims
• ID Permanence
• Customer API

Change Proposed

The change proposed is to clarify the language and data standards definitions such that:

• Add definitions in the CDR Federation section for Logged In User, Nominated Representative and Non-Individual Consumer.

• The personally identifiable information provided in the ID Token and UserInfo endpoint represents the authenticating end user (the nominated representative)

• The resource identifiers that adhere to the ID Permanence requirements are anchored to the consumer not the authenticated end user (in other words, the business who is the non-individual consumer)

  • Clarify in the Scopes and Claims that the sub identifier and personally identifiable information represents the logged in user.
  • Clarify in the ID Token section that this represents the logged in user.

• Determine whether agent role should be defined as a claim returned in the UserInfo response

• Deteremine whether agent details should remain in the Customer API or allow these to be provided solely through the mechanisms that represent the authenticated end user (i.e. request the claims to be returned via the UserInfo endpoint)

Agent Data Options

Option 1: Retain agent data via the Customer APIs

No change is made. In this option, agent data continue to be returned via the Customer API. The first and last name of the agent is also provided via the UserInfo endpoint if the agent consents to share this data.

Considerations:

• Continues to couple consumer data to end user data
• No change to the Customer APIs

Option 1b: Retain agent data via the Customer API and add agent role as custom OIDC PI claim

No change is made to the Customer APIs but a new agent role claim is added to the list of supported claims the ADR can request. This custom claim is returned via the UserInfo response.

Considerations:

• Creates a CDR specific PI claim
• No change to the Customer APIs

Option 2: Remove agent data via the Customer APIs

This change proposes to remove. The agent role would need to be defined as a custom claim that the ADR can request for return via the UserInfo endpoint.

Considerations:

• Decouples consumer data to end user data
• Small change to the Customer APIs. Issue 391: Remove requirement for at least one address in physicalAddresses array has already identified changes to the Customer API so this can be included in the same versioning of the Customer APIs.

These changes may create breaking changes and the DSB requests input on what considerations should be given to obligation dates and phasing. Noting that non-major banking Data Holders are not yet obligated to return non-individual consumer data.

[anzbankau]

The proposed clarification that ID Permanence for Businesses should be keyed to the business customer and not the individual creating the consent does not align to our understanding of the standards at the time when sharing for business commenced in Nov-2021. Given this, the proposed changes would impact our implementation.

We see two possible approaches to transition, both with their respective issues:

1. Agree a date that the ID Permanence logic will be changed for all Authorisations (including existing Authorisations) for business customers. In this approach ADRs would need to reobtain all the customer’s data in order to have corrected identifiers. A key challenge we see in this case is ADRs identifying which Authorisations would need such treatment. It could be understood based on the type of information coming back in Get Customer – but not all ADRs would necessarily have access to that. Further the performance impacts to the ecosystem would need to be considered.
2. Implement the changes in a way that doesn’t impact Authorisations created before the implementation date. This adds some complexity to Data Holder implementations, but means the ADRs will not have existing Authorisations impacted. The issue here is that the ADR won’t have consistent identifiers and therefore not be able to have aggregated data and treatment including data from before the implementation date.

We propose that any changes be given at least 6 months from the date of finalised standards and given the large volume of work already committed for first half of 2022, any changes are future dated to November 2022.

[benkolera]

I am the Chief Software Officer at Biza.io, responding of behalf of Biza. I'll respond to each of the proposed changes inline:

Add definitions in the CDR Federation section for Logged In User, Nominated Representative and Non-Individual Consumer.

Biza agrees that these definitions would clarify these entities and make the other changes in this proposal easier to describe in the CDS.

The personally identifiable information provided in the ID Token and UserInfo endpoint represents the authenticating end user (the nominated representative)

• Clarify in the Scopes and Claims that the sub identifier and personally identifiable information represents the logged in user.
• Clarify in the ID Token section that this represents the logged in user.

Biza strongly recommends this position as it brings the CDR in line with Open ID Connect (https://openid.net/specs/openid-connect-core-1_0.html#Terminology ).

The resource identifiers that adhere to the ID Permanence requirements are anchored to the consumer not the authenticated end user (in other words, the business who is the non-individual consumer)

Biza feels that this is a good clarification to make when making these changes so that there are no accidental breaking of PPIDs when releasing their Non-Individual Consumer support.

Determine whether agent details should remain in the Customer API or allow these to be provided solely through the mechanisms that represent the authenticated end user (i.e. request the claims to be returned via the UserInfo endpoint)

Biza strongly supports option 2 (Removal of the Agent Info from GetCustomer) as the resource server’s responsibility in the CDR is to provide details about the consumer rather than have knowledge about the user that authenticated.

When attempting to design our resource server implementation for Non-Individual Consumers, getting the agent Name/role was an architectural hassle because the resource server by design really only had knowledge of the consumer. The best solution we had was having our resource server call getUserInfo with the access token, but this seems like an unnecessary architectural coupling when the ADR could just call userinfo instead.

Determine whether agent role should be defined as a claim returned in the UserInfo response

If we are removing the agent details from the GetCustomer call, it seems like we should indeed make a CDS specific userinfo claim. Biza notes that such changes should come with clear guidance and upgrades to the permission language data clusters in the CDS CX Standards to resolve any implementation confusion when upgrading to these new standards.

Additional Considerations

Biza notes that this consideration of the userinfo subject does not only apply to Non-Individual consumers, but also when there are Authority to Operate / Power of Attorney type relationships where the authenticated user may be operating an arrangement for a different Individual Consumer. These usecases are coming increasingly to light as Biza firms up its Multiparty Authorization Designs for the upcoming Joint Account FDO.

Biza would recommend applying the same treatment to these POA/ATO type arrangements where the User Info response returns the information about the authenticated user and not the individual consumer that has been shared in the arrangement.

E.g, if I authenticate as Ben Kolera and I have power of attorney over Joe Blogs, I have the ability to create an sharing arrangement where Joe Bloggs is the individual consumer and is returned at the GetCustomer. But in this case it would be good for the ecosystem to have it standardised that Ben Kolera is returned in the userinfo rather than the Individual Consumer Joe Bloggs.

If keep with including the authenticated user in GetCustomer response (i.e Agent Name/Role), then the ATO/POA relationships may require other GetCustomer fields (individual consumer versions of Agent Name) in the Person object to reflect these. This feel like additional unnecessary complexity when it could be all handled in userinfo.

[CDR-API-Stream]

Thanks @benkolera,

This discussion will be progressed in today's Maintenance Iteration call.

Re: agent data (UserInfo API) If this change is adopted it would remove the agent name and role from the permission language for the customer data scopes.

In version 1.15.0 of the data standards, data language standards were introduced for the "profile" scope to address some aspects you've raised. Particularly that the name and contact data represents the data of the authenticating user. This uses the OIDC Standard Claims for name data (name, given_name, family_name, updated_at). For completeness, the "agentRole" would be a new CDR claim introduced into the UserInfo endpoint.

Three sub-considerations relate to this change:

• Consideration 1: Supported agent data

  • Agent role would be a new CDR claim
  • Should custom CDR claims be namespaced (e.g. URN) or simple naming format?
  • Should agentFirstName and agentLastName be included (redundantly) or should only OIDC Standard Claims be used?
  • Should these claims ONLY be requested as individual claims or would we bundle them into the profile scope as well?
  • Assumption is that they are only requested as individual claims (i.e. not bundled into the profile scope)

• Consideration 2: Required agent data

  • Should ADRs be allowed to request agent data as essential claims, and if so, the DH MUST return the data for non-individual consumers?
  • It is assumed that agent data MUST always be returned for non-individual consumers
  • If the Data Holder does not hold agent data, then the Data Holder would not return the agent data claims in the UserInfo response even if they were requested as essential (e.g. in the situation where the consumer is an individual)
  • As noted by @benkolera, there may be individual consumer scenarios where a nominated representative (e.g. a guardian or PoA) could be assigned for the individual consumer. This extends the usability of this solution but it does raise the question whether there may be alternative data language for agents of individual consumers vs nominated representatives of non-individual consumers
  • ADRs would not know (other than through their software's purpose / use case) that they are dealing with a nominated representative for a non-individual consumer. It is only after authorisation that they will know with certainty that the authenticating user is a nominated representative.
  • Should an agent type be returned to support PoA / guardianship etc. in the future beyond just nominated representatives for non-individual consumer

• Consideration 3: Phase in approach and obligation dates

  • This change would impact Get Customer APIs and the UserInfo APIs.
  • It would also impact the list of individual claims DHs must support and ADRs can request
  • The change would impact data language standards for customer, profile and individual claims data

Further considerations We'd also invite participants implementing non-individual consumer data sharing to respond to what data is commonly held and displayed for nominated representatives in your implementations for non-individual consumers.

[CDR-API-Stream]

Hi all, noting that the maintenance iteration held on 30/03/2022 ran out of time to discuss this item. It has been included in the agenda for an out of cycle maintenance iteration call to be held 2pm AEST Wednesday 6/04/2022.

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration 11 call. It was agreed to carry this change request into maintenance iteration 11.

[CDR-API-Stream]

No feedback has been received to the options for consideration. This issue won't be tabled on the agenda for the Maintenance Iteration call scheduled for 08/06/2022. The DSB encourages community feedback on this issue to progress it within Maintenance Iteration 11.

[CDR-API-Stream]

A Decision Proposal is required to introduce an Agent API, #88 DSB Item - Agent API has been added to DSBs future-plan backlog.

[CDR-API-Stream]

Closing as this issue will be considered as a Decision Proposal, see Future Plan Issue #90: DSB Item - Business Customer and Agent Review.

Note Future Plan Issue #88, mentioned above, is a duplicate of Future Plan Issue #90.