Guidance on Profile Scope

Introduction

The notes below are gathered from Subject Matter Expert guidance and responses to participant questions. 

CX requirement for Profile Scope

As the profile scope and associated claims are relevant to the authorising consumer, it is expected that these “cluster” elements will only be visible on the dashboard of the authorising consumer for Joint Accounts and Secondary User approvals and not on the dashboard display of non-authorising account owners.

 Where a Business Client has approved multiple Nominated Representatives (NRs) and the arrangement displays for these other NRs, should the Profile Scope and associated claims appear on the dashboard of the authorising NR or on ALL non-authorising NRs, depending on how the non-individual consumer account is set up and the permissions given to the different nominated representatives. 

Profile Scope and Standard Claims 

The profile scope and individual claims represent data of the authenticated user. For individual consumers this represents the consumer's name and contact details. For non-individual consumers, this represents the nominated representative's name and contact details.

The language for the full data cluster and all permissions must be listed even if the request is for a single claim.
For example, even if the Accredited Data Recipient (ADR) only requests the single standard OIDC claim ‘Address’, both ADRs and Data Holders must display the required data language in full. 

The profile-related claims name, given_name, family_name and updated_at must be supported and returned at the UserInfo End Point as well as in the ID_Token returned in response to a token endpoint request. The updated_at claim aligns with the lastUpdateTime field in the payload returned from the customer endpoint. The ADR can exercise discretion on how to use it.

Supporting Claims 

Data holders must support the basic name claims but it is at the data holder's discretion whether to support the additional contact details for phone number, email address and mailing address.

These claims are advertised by the data holder using the "claims_supported" parameter in their OpenID Discovery Document endpoint. If a data holder does not offer that claim it ignores this requested claim during authorisation. If the requested claim is ignored then the data holder does not need to show the Contact Details data cluster in the authorisation flow.

Accredited Data Recipients (ADRs) can discover what each data holder supports and adjust the claims they request and their user experience accordingly. ADRs should identify claims the data holder supports before constructing a consent request. If the data holder does not support the claim(s), the ADR should not include the claim(s) in the request to the data holder or the consumer.

Profile scope in a consent amendment flow

Consider a scenario where the profile scope has been requested by an ADR in the original consent. In a consent amendment flow, the ADR removes the profile scope and includes some claims in the 'name' data cluster.

The DH is required to pre-select this data cluster. From a data representation perspective, the profile scope, and the claims that OIDC defines as included in the scope, should be treated as synonymous.

Profile Scope and Data Latency

The CDS contains non-functional requirements regarding Data Latency. However, the customer data should be as current as possible, comply with the OAIC Australian Privacy Principles, and follow industry regulatory requirements.