Decision Proposal 036 - OIDC userinfo Support

[JamesMBligh]

Due to previous feedback on the Customer payload this proposal has been drafted to clarify the use of the userinfo end point and id_token in the OpenID Connect standard as it pertains to the CDR standards.

It is anticipated that feedback will be closed for this proposal on the 1st of November. While this is a short period for feedback there is a need to accommodate the draft standard release on the 2nd. There will be more time for feedback after this date as the entire standard will be open for feedback at that point.
Decision Proposal 036 - OIDC userinfo Support.pdf

[JamesMBligh]

Please Note
Leading up to the definition of the first draft of the standards, the security working group decision proposals will be high level only. Due to the sensitivities around sharing security concerns and discussing current implementations in the financial sector the Advisory Committee has requested detailed security design decisions to be formulated via a series of in person meetings. These in person meetings will be co-ordinated using the security working group mailing list. You can sign up to this list at http://eepurl.com/dCNaTn.

The end result of this process will be a working draft proposal that will then be published and opened for transparent public comment, as has been the practice to date for the Data Standards Body.

For this reason this proposal, and others in this series, will focus on high level decisions that shape the overall approach to security under the regime rather than low level technical specifics.

-JB-

[RalphBragg]

There is a distinction between a banks customer and the authenticated user which I don't believe is explicitely made in either the customer data endpoint nor in this paper.

• Customer API Standard: Information about the customer which isn't necessarily the authenticated user.
• CDR Userinfo / OIDC Standard: Information about the authenticated user / session which isn't the same necessarily as the customer.

A customer is a business term that could mean different things to banks, energy companies and telcos so we really need to be careful about language. However, the OIDC ID Token and UserInfo Endpoint relate to the authenticated end user (individual) and the standards support their usage in this regard.
There is a relationship between the ID Token and User Info response. Both include the subject claim which ties them together, a Relying Party should verify that the subject of the ID Token matches the subject claim returned by the User Info endpoint.

Option 3 is a good place to start as it technically facilitates mechanisms for explicitly delivering information about the authenticated user, adoption of the other options presented would be disapointing as they either reinvent a standard that is core to the base specifications and authorisation framework already adopted by the CDR (OpenID Connect FAPI RW) or remove functionality which would limit interoperability and usability from the off for the ecosystem.

In option 3, and generally throughout the paper, it implies that there is a way to tie the id_token / userinfo response to the customer payload. There is currently no Identifier on the Customer Resource but as this is currently a single value not an array of customer objects the binding could be implicit.

From experience, the likelihood of this changing to an array of customer objects is quite high, and the fact that the Customer Resource is a singular resource implies that an "Authenticated User / Credential set" can not be associated with more customer / organisations. Is this really the case?

Assuming no, doesn't this again lend suport for need to adopt a resource that provides information about the Authenticated User distinctly seperate from the Customer concept? Additionally, should the Customer Resource change to an array then there will need to be an identifier added too each customer object which will then also need to be added to the user info and the id_token to bind all three of the objects together. Perhaps adding that unique customer Id now would be a good measure to future proof this?

Perhaps a new decision proposal should be added to the mix to create an "Authenticated User" CDR Standard instead of "minimally supporting it.

e.g
Option 3.5: Create a standard userinfo claimset for Authenticated Cdr Common Claims.
The mechanisms (OIDC) have already been agreed to be implemented by the ecosystem.

The challenges of building an API standard that does not allow Data Consumers to accurately and reliable identify the "Authenticated User" are well known, the OBIE in the UK didn't tackle this problem and now there are a significant problems for Data Consumers in this area. These challenges are called out in an article by John Heaton-Armstrong (A TPP / Data Consumer Champion) here https://www.linkedin.com/pulse/challenge-psu-identity-psd2-john-heaton-armstrong/

Finally, there was some concerns around extensibility of the UserInfo or id_token made in this paper and there's a mention of KYC and Onboarding. For information, I've attached a presentation by Torsten Lodderstedt that describes how OIDC can support both use cases today - fully supported by the FAPI RW Framework.
Identity Proofing with OpenID Connect.pdf

[darkedges]

Agree with @RalphBragg as It is a different endpoint.
How would it be protected? I.e is it something that requires Consumer consent?
This is important to differentiate as a consumer would need to be informed of every request to this endpoint, just like the other data requests. They would also need to know what data it would give an ADR, as they may not consent to giving those details out.

Would a payments access token give the same details as an accounts access token?

I think this need some better justifications before it can be considered properly.

Regards
Nicholas Irving

[da-banking]

We think compounding users and organisations as customers is causing confusion. As noted by @RalphBragg the term "customer" is open to interpretation. We would prefer to not use that term, and instead talk about "users" and "organisations":

• an organisation may be the owner of accounts
• the user is the authorised user that has shared accounts that they can transact on, and may be part of an organisation

DA supports the use of OpenID userinfo. We think this should be mandatory. However we do not think that organisation info should be returned by the userinfo endpoint.

We think there is a broad alignment in the standard OpenID Claims for the data currently assigned to the customer endpoint under person.

Notable gaps include:

• more than one email address for a user
• more than one phone number for a user
• mailing address for a user
• occupation for a user

We propose that the /common/customer and /common/customer/detail endpoints be re-purposed to be /common/organisation and /common/organisation/detail; and that new scopes be defined to access these being "Basic Organisation Data" and "Detail Organisation Data" respectively. The payload should return the content of the "organisation" element currently proposed for the customer endpoints as a top-level inclusion.

For the userinfo endpoint, we propose that the standard sub claim be a unique ID of the authorising user adhering to the standards for ID permanence. This would allow a user to authorise and re-authorise with a third-party and remain identifiable as the same user.

We propose that an "is_agent" claim be included to determine if the user is an agent of an organisation. When true, the /common/organisation and /common/organisation/detail endpoints could be called.

If the "Basic Customer Data" scope is approved by the authorising user, then an example response might be:

HTTP/1.1 200 OK
Content-Type: application/json

{
 "sub": "5c98f37d-229f-4d4f-812d-9fd360ca899b",
 "name": "Mrs Jane Doe OBE",
 "given_name": "Jane",
 "middle_name": "",
 "family_name": "Doe",
 "cdr" {
  "occupation_code": ""
 }
}

If the "Basic Customer Data" scope and either the "Basic Organisation Data" or the "Detail Organisation Data" is approved by the authorising user, then an example respone might be:

HTTP/1.1 200 OK
Content-Type: application/json

{
 "sub": "5c98f37d-229f-4d4f-812d-9fd360ca899b",
 "name": "Mrs Jane Doe OBE",
 "given_name": "Jane",
 "middle_name": "",
 "family_name": "Doe",
 "cdr" {
  "is_agent": true, // Calling /common/organisation won't 404.
  "occupation_code": ""
 }
}

If the "Detail Customer Data" scope is approved by the authorising user, then an example response might be:

HTTP/1.1 200 OK
Content-Type: application/json

{
 "sub": "5c98f37d-229f-4d4f-812d-9fd360ca899b",
 "name": "Mrs Jane Doe OBE",
 "given_name": "Jane",
 "middle_name": "",
 "family_name": "Doe",
 "email": "[email protected]", // Preferred
 "phone_number": "+61499999999", // Preferred
 "birthdate": "1970-03-01",
 "address": {
  "formatted": "55 Currie Street\nAdelaide\nSouth Australia\n5000\nAustralia",
  "street_address": "55 Currie Street",
  "locality": "Adelaide",
  "region": "South Australia",
  "postal_code": "5000",
  "country": "Australia"
 },
 "cdr" {
  "occupation_code": "",
  "emails": ["[email protected]","[email protected]","[email protected]"],
  "phone_numbers": ["+61499999999","+61488888888","+61477777777;ext=5577"],
  "mailing_address": {
   "formatted": "55 Currie Street\nAdelaide\nSouth Australia\n5000\nAustralia",
   "street_address": "55 Currie Street",
   "locality": "Adelaide",
   "region": "South Australia",
   "postal_code": "5000",
   "country": "Australia"
  }
 }
}

If the "Detail Customer Data" scope and either the "Basic Organisation Data" or the "Detail Organisation Data" is approved by the authorising user, then an example response might be:

HTTP/1.1 200 OK
Content-Type: application/json

{
 "sub": "5c98f37d-229f-4d4f-812d-9fd360ca899b",
 "name": "Mrs Jane Doe OBE",
 "given_name": "Jane",
 "middle_name": "",
 "family_name": "Doe",
 "email": "[email protected]", // Preferred
 "phone_number": "+61499999999", // Preferred
 "birthdate": "1970-03-01",
 "address": {
  "formatted": "55 Currie Street\nAdelaide\nSouth Australia\n5000\nAustralia",
  "street_address": "55 Currie Street",
  "locality": "Adelaide",
  "region": "South Australia",
  "postal_code": "5000",
  "country": "Australia"
 },
 "cdr" {
  "is_agent": true, // Calling /common/organisation won't 404.
  "occupation_code": "",
  "emails": ["[email protected]","[email protected]","[email protected]"],
  "phone_numbers": ["+61499999999","+61488888888","+61477777777;ext=5577"],
  "mailing_address": {
   "formatted": "55 Currie Street\nAdelaide\nSouth Australia\n5000\nAustralia",
   "street_address": "55 Currie Street",
   "locality": "Adelaide",
   "region": "South Australia",
   "postal_code": "5000",
   "country": "Australia"
  }
 }
}

Versioning
We think the standard OpenID claims have been tried and tested for so long and across so many industries that we are unlikely to be inhibited by aligning with them, and the benefits of using this standard mechanism are clear.

For the CDR-specific userinfo claims, the payload is likely to expand over time, which does not need to be versioned. Adding properties is not a breaking change.

There is no inbuilt way to perform version negotiation, so we do not see a way to avoid breaking clients if properties are removed, or their meaning changed. This is a limitation of the approach.

[LenNatBEN]

Agree with @RalphBragg regarding the distinction between user and customer. Option 3 provides support for that difference however so is feasible.

[NationalAustraliaBank]

NAB questions the need for a new way of accessing user data that requires further security controls when this same data is already provided as part of the data payload. However, if there is proven value for it, we would support Option 3 (Minimally Support "userinfo") and keep the OIDC standard consistent.

In this scenario, alignment with previous decisions must be taken into consideration: PII and confidential / restricted data must follow the same principles as per previous data payload discussions (i.e. KYC and identity verification data must not be shared; PAN must be masked).

Furthermore, we agree with #RalphBragg that further consideration is required to differentiate customers from authenticated users. We believe this is a fundamental topic that needs to be clarified and discussed prior to closure of this decision.

[WestpacOpenBanking]

Westpac supports option 4 only. We believe that userinfo should only be used to the minimum extent needed to support the security flow and that it should not include any personally identifiable information. Our reasoning follows from the pros mentioned and the cons identified in relation to the other options and a belief that the consumer data right framework should cover all aspects of the standard.

[JamesMBligh]

Thanks for the feedback everyone. We will synthesising this for an initial hypothesis for the draft standards and will then work with the security working group in working sessions to work through the issues and clarify the position for implementation.

-JB-

[JamesMBligh]

The finalised decision for this topic has been endorsed. Please refer to the attached document.
Decision 036 - OIDC userinfo Support.pdf

-JB-