Skip to content

DSB Maintenance Iteration 10: Agenda & Meeting Notes (6 April 2022)

Jump to bottom
CDR API Stream edited this page Apr 11, 2022 · 7 revisions

image

Date and time: 06/04/2022, 2:00pm – 4:00pm AEST

Location: WebEx

Dial-in details:

Chair: Ivan Hosgood, DSB

Maintenance overview: Further information

Maintenance project board: See here

Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 237

Recording

The Maintenance Iteration Calls are recorded for note taking purposes only. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material will be provided without the participant's consent. Participants may email [email protected] should they have any further questions or wish to have any material redacted from the record.

Acknowledgement of Country

We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.
We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.

Agenda

  • Housekeeping
  • Introductions
  • Iteration 10 issues not discussed on 30 March 2022
  • Any other business

Meeting notes

Introductions

This week is an additional call, the fifth, for the 10th Maintenance Iteration.

The purpose of the meeting is to discuss 6 issues on the Agenda for Meeting 4 that were not discussed.

  • Overview, purpose and intended outcomes of the meeting

Previous Agenda & Minutes for Meeting 4 (30/03/2022)

The full agenda and minutes for Meeting 4, held last week, is available here https://github.com/ConsumerDataStandardsAustralia/standards/wiki/DSB-Maintenance-Iteration-10:-Agenda-&-Meeting-Notes-(30-March-2022)

Iteration 10 Issues

All open change requests can be found here: Standards Maintenance Issues.

The standards maintenance backlog can be found here: Data Standards Maintenance

Discussion in today's meeting is limited to the following change requests which are currently in the design stage for this iteration:

Issue # Sector Change Request Decision Change Status Future Dated
Obligation (FD)		 Affected Schema
(if applicable)		 Affected Endpoint
(if applicable)		 Recommendation
435 Infosec Nominated representative end user for non-individual consumers
482 Infosec JWT signing non-normative examples use unsupported signing algorithm Change Recommended Non-breaking change Non-normative example update
488 Register Data holder behaviour clarification required when receiving registrations with unsupported authorisation scopes Change Recommended Breaking change 15/11/2022 N/A Register Data Recipient oAuth Client, Update Data Recipient Registration Data Holder Brands should ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations.
486 Register Allow ADRs to specify scopes for a Software Statement Assertion (SSA) to support cross industry software products In Progress
443 Register SSA definition: Deprecation of revocation_uri Change Recommended Get Software Statement Assertion (SSA) This work contributes to the delivery of #444
498 Register New Register Authenticated APIs versions require multiple authorisation scopes #498 In Progress

Any other business

Next Steps

Meeting Minutes

Notes

MI10 Candidates

No Energy items were discussed in this meeting.

CTS related issues

  • Maintenance Iteration meetings are a natural place for impacts on CTS to be highlighted and discussed in the context of standards related issues.
  • While DSB does not have responsibility for addressing impacts or resolving CTS issues, when they're identified in this forum they will be minuted and actions will be captured and assigned to the ACCC. Progress on actions can then be monitored by the community with updates from the ACCC.
  • The DSB and ACCC collaborate to align approach and resolve issues.

Information Security

Apologies, the items for discussion were mistakenly communicated as 435 and 482, however 482 has already been resolved. Items for discussion are 435 and 458.

  • Issue 435 - Nominated representative end user for non-individual consumers

    • In general, removing agent details from the Customer API is supported, although there are tangential implications and challenges in identifying an appropriate location to move it to.
    • Discussion centred on the general handling of claims and contention with interpretation of underlying standards (OpenID Connect). The proposed changes expose a gap in presentation of user info when the profile scope and customer scopes for banking and energy are considered for both individual and non-individual consumers.
    • Consideration of granular data language definition at the claim level (currently defined at scope level) is requested in order to adequately resolve the gap however this does not address introduction of custom claims - if these can be introduced by individual data holders when extensibility has been applied.
    • Concern that some aspects of an arrangement have the potential to be generic if claims change over time, such as those circumstances where new claims are added to a scope, the ADR could in theory ask for additional information if the details of a consent arrangement are not stored as the specific set of claims that were in operation at the time consent was established.
    • Concerns were raised about exposing agent role and additional user metadata about using the User Info endpoint. Instead preferring a seperate API (either User API, Consent API or Grant Management API). Data such as agent role may change often and is not usually stored in the Authorisation Server. Further to this, a user may have many different roles in the organisation and one or more of these agent roles could be applicable.
    • Logically this information could belong in a separate API that provides information about consent, grant management and when querying, provide metadata about the user role at the time of granting consent. Understanding the requirements for obtaining details of a user logged in at any given point in time is a separate consideration but one that is related to this issue.
    • The evolution of this issue is presenting a deeper layer of questions that requires more time to consider. The DSB invites the community to provide further feedback in order to determine the best course of action for this issue and the impact it has on the impending FDO of 1 July for DP216.
      • Considering commercial scopes (specific to a single DH) and a growing use of individual claims outside of a scope should be considered especially in the context of the user's consent and how that changes over time (by using a catch all scope this creates ambiguity)
      • It was suggested that data language should support progressive standards for displaying data language. In other words, a Contact Details data cluster can be defined that provides a progressive profiling of the individual claims being requested. Based on this, if one or more claims is requested then they should be stored by the Authorisation Server as individual claims based on the final authorisation. If the ADR seeks to add new claims to the authorisation request, they can perform a re-authorisation where extra claims can be requested and then individually included into the consent.
      • There was strong support for decoupling user data from consumer data because this also supports multi-party user access and individual consumer nominated users (e.g. guardian, power of attorney etc.)
    • DSB to update the community on progress of this issue in the next maintenance iteration meeting on the 13th of April. InfoSec 435

  • Issue 458 - FAPI 1.0 Non Normative Examples

    • A sequence diagram illustrating flows for OIDD, DCR, PAR, Authorise and Token has been posted on the issue for community review and feedback. This will help highlight where non-normative examples should be provided
    • DSB will discuss the issue of potential documentation changes to accommodate upstream changes to JARM when FAPI moves from optional to mandatory offline and update the community on progress of this issue in the next maintenance iteration meeting on the 13th of April. Considerations will need to be made on whether the Discovery Configuration Endpoint and DCR documentation should be updated to defer to the upstream standards or explicitly document the fields required to enable JARM support. InfoSec 458

Register

Issue 486 and 488 have progressed and are being addressed in parallel.

New Actions

  • DSB to update the community on progress of this issue in the next maintenance iteration meeting on the 13th of April. InfoSec 435
  • DSB will discuss the issue of potential documentation changes to accommodate upstream changes to JARM when FAPI moves from optional to mandatory offline and update the community on progress of this issue in the next maintenance iteration meeting on the 13th of April. Considerations will need to be made on whether the Discovery Configuration Endpoint and DCR documentation should be updated to defer to the upstream standards or explicitly document the fields required to enable JARM support. InfoSec 458
  • ACCC to provide feedback on the proposal and comment on the feasibility of FDO. Register 486
  • DSB to add commentary on the ticket to address the relationship between statuses and DP245. Register 444

Any other business

None

Next Steps

  • On 13 April 2022 DSB will run through the proposals to address each of the candidates in MI10, some will be Recommended to the chair for change, some may be withdrawn and others may require continued consultation.
  • The Documentation for DP237 will be developed to reflect these proposals.

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally