-
Notifications
You must be signed in to change notification settings - Fork 56
DSB Maintenance Iteration 9: Agenda & Meeting Notes (24 November 2021)
Date and time: 24/11/2021, 2pm - 4pm AEDT (1pm - 3pm AEST)
Location: WebEx
Dial-in details:
- https://treasuryau.webex.com/treasuryau/j.php?MTID=m6786d3cadd2da38bd3ae2bf7cca07212
- Dial In Number: +61 2 9338 2221
- Dial In Access Code: 265 1917 2241
- Quick Dial: +61-2-9338-2221,,26519172241##
Chair: Mark Verstege
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 212
- Wait 5 minutes for all participants to join. Kickoff at 2:05pm (AEDT)
- Outstanding Actions
- Release plan: schedule of forwards looking standards releases
- Open Decision Proposals: key consultation dates
- Iteration 9 change request candidates
- Any other business
Meeting notes
This week is the eighth call of the 9th maintenance iteration. The purpose of the meeting is to discuss options for iteration candidates adopted in the 9th maintenance iteration. This meeting has been extended to two hours.
Please note 1: This maintenance iteration has been extended by 4 weeks and will conclude 1st December 2021. This is to incorporate energy change requests and align to end of year shutdown.
- Allow 5 min for participants to join
- Housekeeping
- Overview, purpose and intended outcomes of the meeting
- ANZ to create a change request to better support cursors for returning large result sets.
- (Issue #292) [IN PROGRESS] DSB to propose strawman solution
- (Issue #291) [IN PROGRESS] DSB to propose strawman solution
- Community to raise a CR for energy charges to include a unit of measure (e.g.
$/kWH, $ /day, $/hr). See Issue 439 - (Issue #428) DSB to discuss CTS support for audience claim value for DHs calling the ADR revocation endpoint
- v1.12.0 was published on 14th of October 2021: This release contains binding non-functional requirements for banking and energy
- v1.13.0 was published published on the 22nd of October 2021: porting of Register standards from ACCC
- v1.14.0 was published on the 29th of October 2021: Energy API standards
- v1.15.0+: no current release candidates are scheduled
The following decision proposals are open for community feedback
DP # | Closing date | DP |
---|---|---|
216 | Closed | Decision Proposal 216 - Profile Scope Support |
209 | Closed | Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile |
162 | 30/11/2021 | Decision Proposal 162 - CX Standards | Joint Accounts |
222 | 30/11/2021 | Decision Proposal 222 - CX Standards | Insights and Trusted Adviser Disclosure Consents |
225 | 18/02/2022 | Decision Proposal 225 - Data Recipient Security Standards |
211 | Pending | Decision Proposal 211 - Scope of Risk-based Authentication and Identity Proofing Framework, Threat and Attack Model |
210 | Pending | Decision Proposal 210 - Transition to FAPI 2.0 Profile |
203 | No closing date | Normative Standards Review (2021) |
158 | Closed | Decision Proposal 158 - Participant capability discovery |
Review of Q4 and new changes: https://github.com/ConsumerDataStandardsAustralia/future-plan/projects/1
All open change requests can be found here:
- Maintenance Iteration 9 extended until 1st December 2021
- Proposed that Maintenance Iteration commence 16th Feb 2022
The following issues have been consulted on during this iteration. The current status is summarised.
Standards Maintenance Issues
Source | # | Sector | Change Request | Status | Recommendation | Affected Schema (if applicable) |
Affected Endpoint (if applicable) |
---|---|---|---|---|---|---|---|
Standards Maintenance | Issue 404 | Banking | Profile scope not aligned with CX standards | DP216 is live | This issue will be consulted on in Decision Proposal 216 - Profile Scope Support given the breadth of the standards changes | N/A |
|
Standards Maintenance | Issue 395 | Does DHs' PAR endpoint require enabling private key jwt client authentication in addition to request object validation? | No change | No change | N/A | N/A | |
Standards Maintenance | Issue 397 | Transaction Security Ciphers | Alternative supported | Defer to FAPI 1.0. The change proposed by the DSB to defer to FAPI standards will be included in the DP 209 consultation. Standards will be changed in accordance to the schedule for FAPI 1.0 adoption | N/A | N/A | |
Standards Maintenance | Issue 406 | Change Request to make 'scope' optional in the token end-point response in FAPI | Not supported | Retain current requirement for scope support. Alignment to FAPI 1.0 (Final) requirements for the scope value will be included in the DP 209 consultation. Standards will be changed in accordance to the schedule for FAPI 1.0 adoption | N/A |
|
|
Standards Maintenance | Issue 150 | A loan may have no end date but loanEndDate is mandatory | Supported - Breaking Change | Change repaymentFrequency , loanEndDate and nextInstallmentDate fields to be optional. |
|
|
|
Standards Maintenance | Issue 396 | Define new Digital Wallet Payee Type to relevant schemas | Supported - Breaking Change | Extend payee support for provider-agnostic digital wallets. Get Payees v2 and Get Payee Detail v2 future-dated obligation of 31st of March 2022. Data Holders can support v2 as early as is practical but no later than 31st of March 2022. Retirement of v1 APIs 1 month after v2 FDO (i.e., any time after 31st April 2022). |
|
|
|
Standards Maintenance | Issue 405 | Alternative mechanisms for OTP | Under consultation | No recommendation yet made | N/A | N/A | |
Standards Maintenance | Issue 407 | Align data quality NFR with Privacy Safeguard 11 | Change supported | Changes to Data Quality NFRs working in line with OAIC feedback regarding data quality requirements in relation to Privacy Safeguard 11 | N/A | N/A | |
Standards Maintenance | Issue 402 | Support for multiple additional information documents | Change proposed; Under consultation | Proposes changes to supported multiple additional product documents | BankingProductV3 |
|
|
Standards Maintenance | Issue 401 | Extending the list of supported feature types | Under consultation | Proposes changes to supported feature types |
|
|
|
Standards Maintenance | Issue 291 | Credit card loyalty program data: significant gaps and lack of structure | Under consultation | Proposes changes to better support loyalty schemes |
|
|
|
Standards Maintenance | Issue 292 | Credit card balance plans and payment hierarchy: inadequate information within the CDS | Under consultation | Proposes changes to supported multiple payment plans and balances |
|
|
|
Standards Maintenance | Issue 391 | Remove requirement for at least one address in physicalAddresses array | Under consultation | Proposed change to remove requirement of at least one address to be returned. Feedback from DHs has indicated that this is not always possible when the address held on record is invalid |
|
|
|
Standards Maintenance | Issue 423 | Energy | Review of demand charges in energy billing transactions | Under consultation | - | - | - |
Standards Maintenance | Issue 422 | Energy | Energy C&I tariff extensions | Under consultation | - | - | - |
Standards Maintenance | Issue 421 | Energy | Review of rates in energy account payload | Under consultation | - | - | - |
Standards Maintenance | Issue 420 | Energy | Modification of energy account enumeration values | Under consultation | - | - | - |
Standards Maintenance | Issue 419 | Energy | Modification of energy billing and invoicing enumeration values | Under consultation | - | - | - |
Standards Maintenance | Issue 432 | Energy | EnergyPlanSolarFeedInTariff.tariffUType enum contains incorrect values | - | - | - | |
Standards Maintenance | Issue 428 | InfoSec | CTS incorrectly implements Data Holder Initiated Revocation | For consultation | - | - | - |
Standards Maintenance | Issue 426 | InfoSec | Recipient Arrangement Revocation Endpoint exposed to Mixup Attack | For consultation | - | - | - |
Standards Maintenance | Issue 428 | InfoSec | CTS incorrectly implements Data Holder Initiated Revocation | For consultation | - | - | - |
Standards Maintenance | Issue 435 | InfoSec | Nominated representative end user for non-individual consumers | - | - | - | |
Standards Maintenance | Issue 424 | Register | API Uplift for Data Holder Multi-Sector support | For consultation | - | - | - |
Standards Maintenance | Issue 425 | Register | API Uplift for Data Recipient Multi-Sector support | For consultation | - | - | - |
Standards Maintenance | Issue 431 | Register | Register participant statuses do not detail data holder behaviour when ADR is revoked and SP inactive | For consultation | - | - | - |
Standards Maintenance | Issue 433 | Register | Data Holder behaviour is not defined when a software product id goes "missing" | For consultation | - | - | - |
CDR Register Maintenance Issues
Source | # | Change Request | Status | Recommendation | Affected Schema (if applicable) |
Affected Endpoint (if applicable) |
---|---|---|---|---|---|---|
CDR Register | Issue 169 | CDR Register OpenID Configuration does not specify token signing algorithm support change request | Change supported | Documentation fixes. Staged and published after v1.13.0 release | N/A | N/A |
CDR Register | Issue 189 | RegisterDataHolderAuth schema in GetDataHolderBrands descriptions to be clarified | Change supported | Documentation fixes. Staged and published after v1.13.0 release | N/A | N/A |
CDR Register | Issue 188 | SSA definition: Deprecation of revocation_uri | Change supported | Documentation fixes. Staged and published after v1.13.0 release | N/A | N/A |
CDR Register | Issue 186 | Documentation improvement: JWT Signature verification requirements during the DCR flows | Change supported | Documentation fixes. Staged and published after v1.13.0 release | N/A | N/A |
CDR Register | Issue 174 | Update Register APIs to search for and differentiate between archived entities | Delayed | Carried over to next iteration | N/A | N/A |
CDR Register | Issue 126 | Consider changing statement in Certificate Management about the use of ACCC CA issued certificates for ADR end points | Delayed | To be consulted on under DP 211 threat modelling | N/A | N/A |
CDR Register | Issue 123 | Consider identicons to allow DHs to provide multiple attributes to map to individual accreditations | Under consultation | Requesting feedback. No recommendation has been made. | N/A | N/A |
CDR Register | Issue 175 | Publish an endpoint version schedule to document the introduction and deprecation of Register and DCR endpoints | Documentation enhancement | This will be covered with the merging of the CDR Register standards into the Consumer Data Standards. Deprecation schedules for various endpoint versions can then be discussed in future maintenance iterations | N/A | N/A |
Issue 418: CDR Data Holders outbound connection whitelisting
- Cross-post of Issue 416: Introduce explicit language to prevent unwarranted friction in the dynamic client registration (DCR) process by data holders
- For discussion
Issue 428: CTS incorrectly implements Data Holder Initiated Revocation
- For discussion
Issue 426: Recipient Arrangement Revocation Endpoint exposed to Mixup Attack
- For discussion
Issue 433: Data Holder behaviour is not defined when a software product id goes "missing"
- For discussion
- For discussion
Issue 402: Support for multiple additional information documents
- For discussion
Issue 401: Extending the list of supported feature types
- For discussion
Issue 438: Representing adjustment transactions within the Billing Payload for C&I customers
- For discussion
Issue 439: Review Pricing Model & Time Zone attributes within Account Detail Payload
- For discussion
Issue 423: Review of demand charges in energy billing transactions
- For discussion
Issue 422: Energy C&I tariff extensions
- For discussion
Issue 421: Review of rates in energy account payload
- For discussion
Issue 420: Modification of energy account enumeration values
- For discussion
Issue 419: Modification of energy billing and invoicing enumeration values
- For discussion
Issue 432: EnergyPlanSolarFeedInTariff.tariffUType enum contains incorrect values
- For discussion
- Address any other business arising from the community
Standards Maintenance Issues
-
InfoSec & Common Issues
-
Issue 418:
- Assumption that whitelisting is automatically actioned on DCR POST/PUT operations (create/update)
- Data Holders use whitelisting as an important cybersecurity control
- Not directly an issue with DCR but it impacts DCR
- The issue for whitelisting only relates to server-side backchannel calls to external addresses
- Discussed clarifying in the standards that manual whitelisting is not permitted
- This may require a period of support from the ACCC to provide ADR domains/URLs ahead of time prior to DCR requests
- Options discussed:
- (A) Remove DCR altogether. Provide ADR domain data via the CDR Register APIs
- (B) Delay calls by ADRs after DCR (e.g. delay of 60 min - 24 hours)
- (C) Accept DCR may fail as a port knock and the ADR must retry after a specified period of time
- (D) CDR Register hosts the ADR's JWKS endpoints. This doesn't solve for the other ADR hosted endpoints e.g. sector_identifier_uri and CDR Arrangement Revocation endpoint.
- Recipient logo was raised as an adjacent (but separate) security concern. Currently DHs must trust a file hosted by an external party and display within a secure environment (e.g. the DH's Internet Banking).
- The standards are currently silent on whether whitelisting is allowed. The standards are explicit about the NFRs for dynamic client registration. Therefore, the standards permit whitelisting if it is automated such that it does not breach the NFRs for DCR.
- DSB will consult on a long-term strategic solution to resolve this issue however a short-term solution needs to be embedded to supports ADRs and DHs during the transition
- DSB to verify that the ACCC can or is providing an operational process to distribute ADR domain lists to DHs ahead of activation and DCR requests
-
Issue 428:
- No further feedback provided on GH
- Currently an immediately breaking change and not a future dated obligation for DHs
- Right now, some ADRs are rejecting calls
- Preference that the standards be updated without a future dated obligation with ADRs updating their software solutions ASAP and DHs raising incidents against ADRs to rectify the integration issue
- Options:
- (A) Revert to old statement with a future dated obligation on the new statement
- (B) No future dated obligation but support an immediate allowance for the end state
- DSB to discuss with active ADRs how quickly the change could be enacted to resolve the issue
- DSB to confirm that the ACCC is updating the CTS to the proposed wording, not the current wording
-
Issue 426:
- ADR should accept
jti
once - this needs a statement change for single use tokens - Supporting changes required:
- Define a maximum value for the
exp
value. Consensus agreed on 10 - 90 seconds. Shorter FDO - Cryptographically bind the cdr_arrangement_id with the assertion. Longer FDO
- To support immediate movement to resolve the issue the standards changes should be defined as a SHOULD to allow for early adopters
- Define a maximum value for the
- Discussed alternative solutions to resolve this long term
- (a) Change the CDR Arrangement Revocation Endpoint to be a notification API that informs the ADR to collect (pull) the data
- (b) Require ADRs to support MTLS and act as a FAPI-compliant authorisation server accepting client registration from DHs
- Strategic long-term solution to be consulted on around action initiation
- DSB to discuss with ADRs whether any are currently allowing token reuse
- ADR should accept
-
-
Register Issues
- Issue 433:
- Wording will be improved by the DSB and updated on the GH issue
- DSB to continue discussions with the ACCC on the CTS changes and provide a response back to the community
- Issue 433:
-
Banking
-
No issues discussed
-
Energy Issues
-
No issues discussed
- (Issue 418) DSB will consult on a long-term strategic solution to resolve this issue however a short-term solution needs to be embedded to supports ADRs and DHs during the transition
- (Issue 418) DSB to verify that the ACCC can or is providing an operational process to distribute ADR domain lists to DHs ahead of activation and DCR requests
- (Issue 428) DSB to discuss with active ADRs how quickly the change could be enacted to resolve the issue
- (Issue 428) DSB to confirm that the ACCC is updating the CTS to the proposed wording, not the current wording
- (Issue 426) DSB to discuss with ADRs whether any are currently allowing token reuse
- (Issue 433) DSB to continue discussions with the ACCC on the CTS changes and provide a response back to the community