DSB Maintenance Iteration 5: Iteration Scope Review: Agenda & Meeting Notes (7th October 2020)
Date and time: 07/10/2020, 1pm - 2.30pm AEST (2pm - 3.30pm AEDT) Location: WebEx
- https://csiro.webex.com/csiro/j.php?MTID=md498fcab7a2000cbb4b0072b4b266111
- Dial In Number: +61 2 6246 4433
- Dial In Access Code: 165 106 9550
- Quick Dial: +61262464433,1651069550%23%23
Chair: Mark Verstege, DSB
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 138
- Introductions
- Outstanding Actions
- Decision Proposals: open decision proposals
- Iteration Candidates: change requests considered as candidates for this iteration
- Any other business
Meeting notes
- Allow for participants to join
- Housekeeping
- Overview, purpose and intended outcomes of the meeting
- Carry over open maintenance iteration 4 change requests
- crnType change request has been withdrawn from v1.5.0 and will be reconsulted on in Maintenance Iteration 5 (https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/152)
- CBA to provide options for dealing with #315 - Obligation based standards
- Enhanced Error Handling: #119, #120, #121, #122 and #127
- Discovery Service (see DP #135) - DP TBA
- Metrics and Reporting roadmap + Metric API v2 - DP TBA
The following change requests have been proposed for this iteration:
- #152: CRN in BankingBillerPayee should be optional
- #320: [1.5.0] BPAY crnType introduced as mandatory and backported into existing version
- #229: Service field in the Get Transaction Details API / #181
- #300: Alternate implementations for one-time consent
- #175: Premature Completion of Consent (Hybrid) Flow
- #219: Allow retrieval of current refresh_token by arrangement ID
- #240: 'SHOULD' for access token revocation
- #325: Future dated obligation for change to how audience is set for Data Recipients calling Data Holders
- #307: Make Metrics brand aware
- #315: Obligation based standards
- #150: A loan may have no end date but loanEndDate is mandatory
- #301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences
- #309: paymentsRemaining cannot currently be 0
- #310: [1.4.0] BankingProductFee feeType adds Variable which is a new payload version
- #318: [1.5.0] Missing Changelog Item: (Nearly) All Enumerations Reordered
- #319: [1.5.0] Missing Changelog Item: Maturity Instructions
- #321: [1.5.0] Clarification of future obligation dates
- #247: ADR Revocation Endpoint
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/152
Overview:
- CRN in BankingBillerPayee is mandatory but CRN is not always known
- If CRN is not available, the biller cannot provided (to avoid breaking the mandatory constraint)
- Iteration 4 proposed CRN be conditional and introduced crnType with July obligation date
- crnType is mandatory however is is not always derivable
- Options to deal with CRN/crnType:
- Define a default crnType when not known e.g. VARIABLE_CRN
- Define an UNKOWN enumeration for crnType
- Make both CRN and crnType conditionally optional
Decisions to be made:
- Are any urgent changes required to support November
- Target state, what changes are required in addition to what was approved in Iteration 4
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/320
Overview
- See #152
- For consultation in conjunction with #152
Decision to be made:
- Should a default crnType apply or should crnType be conditional?
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/229, https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/181
Overview:
- Extend support for new NPP Osko overlays and SCT
- DSB in discussion with NPPA to progress
Decisions to be made:
- Pending proposal from DSB
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/300
Overview:
- One-time consent currently assumes sharing_duration = 0 and couples collection and use
- Loss of access token, DH availability or network issues impact ability for ADR to collect.
- Places burden on the consumer to re-consent where technical issues are encountered
- Separation of collection and use consent is permitted under the Rules for one-time consent only* (i.e. provided that the ADR collects only once, otherwise they are in breach)
- E.g. and ADR can use a sharing_duration = 24hr (e.g., or similar) for one-time collection and ongoing use
- ADRs would be required to request consent for ongoing use and make this duration clear vs collection consent
- Would allow ADRs to collect in a one-time capacity but have an extended period of use (e.g. 90 days) provided the consumer consents
- Note: Currently the Rules don't permit separation of collection and use for on-going consent
Decisions to be made: In review by ACCC and DSB
- CX Guidelines and Standards to provide guidance on ADR presentation of collection consent and use consent
- Technical standards changes:
- Define the time-period of collection for one-time use e.g. 24 or 48 hrs
- Define standards for revocation of collection consent after successful data collection
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/175
Overview
- Authorisation codes may be lost in transit at authorisation time
- Tokens may be lost in transit when the ADR attempts exchange for the authorisation code
- Authorisation codes are short-lived use-once codes and cannot be replayed
- If any loss of code or token occurs, the ADR does not have confirmation of authorisation
- There is a CX concern where the DH would now show consent as "active"
- Broad agreement that consent only becomes "active" after confirmation of handover once the ADR takes possession of the relevant tokens
Decisions to be made
- Define consent / authorisation lifecycle
- Define _when_consent is considered "active"
- Determine what occurs where the consumer's consent is "awaiting authorisation":
- Can the ADR obtain an authorisation code and/or tokens?
- Must pending consent be destroyed?
- Can the DH initiate sending a new authorisation code where consent is "awaiting authorisation" after a period of time
- Define CX considerations consent "awaiting authorisation" (i.e. "pending" consent)
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/219
Overview
- Loss or refresh token can occur for a variety of reasons including
- ADR incorrectly revokes tokens prior to consent being revoked (note: whilst possible this is considered an implementation fault of the ADR client and temporarily obviated by continuing consent revocation via the DH oAuth Token Revocation end point until Feb 2021)
- DH cycles refresh tokens but the ADR does not obtain a new refresh token before their existing refresh token expires
- Refresh token is lost in transit (ADR does not take receipt of a requested refresh token)
- In these situations, effort shifts to the consumer: ADR must ask the consumer to re-consent to continue providing their goods or service
- Proposal is to use the
cdr_arrangement_idas a secondary "secret" for exchange of a new refresh token- This would not cater for situations during initial authorisation where the authorisation_code is exchanged to obtain the
cdr_arrangement_idand tokens
- This would not cater for situations during initial authorisation where the authorisation_code is exchanged to obtain the
- Alternatively, could be handled via
- "confirmation of handover" in #175
- Disallowing refresh token cycling by data holders
Decisions to be made
- Agree on approach to deal with potential loss of refresh token
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/240
Overview
- Currently, DHs must support revocation of Access Tokens
- RFC7009 does not require AT revocation (it is a SHOULD) however this is discussed in RFC7009 Security Considerations noting that it "contributes to overall security and privacy since it reduces the likelihood for abuse of abandoned tokens"
- There is concern that compromised access tokens can be used by malicious users to obtain consumer data
- "Compromised" access tokens may be valid for up to 10 minutes
- This risk is minimised because access tokens being bound to the private key of the client (HoK)
- Likely risk is that the client software continues to collect data (e.g. via a scheduled job) using a valid AT for up to 10 minutes after a consumer revokes consent
- Whilst JWT based ATs may reduce verification calls to the DH Authorisation Server, the Resource Server still needs to verify the access granted is still valid (e.g. customer represented by the
subisn't suspended, account hasn't been removed from consent, joint account holder hasn't withdrawn consent etc.) - This is only a consideration in instances where the ADR explicitly asks the DH to revoke an AT
- Actual usage of this service by ADRs is unknown
Decisions to be made
- Whether to continue mandating Access Token revocation (if the ADR explicitly asks to revoke ATs)
#325: Future dated obligation for change to how audience is set for Data Recipients calling Data Holders
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/325
Overview
- In v1.4.0 the data standards clarified the audience claim for Data Recipients client authentication to Data Holders based on community feedback
- Whilst this may work for the token endpoint, it does not work for PAR end point
- Proposal is a Future Dated Obligation of Feb 2021 be introduced
- Would require ADRs (existing and new entrants) to align to this obligation date and implementation
Decisions to be made
- Are ADR implementations correct per RFC7523?
- What effort is required for ADR clients to correctly align to the Consumer Data Standards (Token Endpoint URL)
- What implementation considerations and future dated obligations are necessary (if any)
- Should the aud claim be qualified to:
aud: The issuer identifier URL of the authorization server according to [RFC8414] SHOULD be used as the value of the audience.
In order to facilitate interoperability the authorization server MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.
- Are there any implementation considerations with out of the box Authorisation Service implementations against RFC7523?
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/307
Overview
- Metrics reporting is currently aggregated at the Data Holder level
- If Data Holders represent multiple brands under one DH instance, the DH cannot report on per-brand metrics
- This may result in loss of reporting detail at the brand level
Decision to be made
- Update Metrics to report on Metrics at the brand level not the DH level
- Assume target Get Metrics v2 for July 2021
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/315
Overview
- All obligations for a given milestone/compliance date can be difficult to understand when applied across versions of the data standards
Decision to be made
- How can the data standards be represented such that standards making agility is preserved but greater confidence in required compliance obligations is possible?
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/150
Overview
- loanEndDate, repaymentFrequency and nextInstallmentDate can sometimes be absent
- Applies for some closed accounts and line of credit products
- Proposals include:
- Make these fields optional
- Define a new product category for line of credit products
- Make the fields conditional for closed accounts
Decisions to be made
- Should these fields be made optional or conditional for closed accounts
- Should these fields be made optional or a new product category be defined for line of credit accounts
#301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/301
Overview
- BankingScheduledPayment expects that the nickname and payeeReference apply to all payments in the associated PaymentSet
Decision to be made
- Should BankingScheduledPayment include a "display name" for the scheduled payment
- Should nickname and payeeReference be conditional if they are provided within the paymentSet
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/309
Overview
- paymentsRemaining is defined as a PositiveInteger
- If there are not further payments remaining, should any scheduled payments be returned?
- If paymentsRemaining=0 this would imply no further payments and hence no scheduled payment
- If scheduled payments should show historical payment schedules, then consider allowing paymentsRemaining to be a NaturalNumber and include zero(0) as a valid value
Decision to be made
- Either update examples to be a PositiveInterger (>= 1), or
- Change paymentsRemaining to be NaturalNumber and allow zero(0) paymentsRemaining
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/311
Overview
- Model versions for BankingProductLendingRate were incorrectly versioned
- Versioning strategy has been clarified such that models will be versioned up the tree when an end point is versioned otherwise the data models will not be versioned
Decision to be made
- Suggest no backporting and versioning of models strictly follow clarified versioning guidance where breaking changes that result in end points being versioned will increment the model hierarchy
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/310
Overview
-
feeTypewas modified in 1.4.0 to cate for at-cost fees via the new enumeration "VARIABLE" - Get Product Detail was versioned to v3 with a Feb 2021 release date
- Get Account Detail was not versioned accordingly
Decision to be made
- Whether to version Get Account Detail to v2
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/318
Overview
- Enums were ordered for human readability
Decision to be made
- Should all enums be strictly Alphabetically or Natural Order sorted?
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/319
Overview
- Errata - missing changelog documenting maturity instructions change added in v1.5.0
Decision to be made:
- Update release notes for 1.5.0
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/324
Overview
- Errata - missing obligations in the Future Dated Obligations table
Decision to be made:
- Update Future Dated Obligations table in next release
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/247
Overview
- DHs must notify ADRs when consent is withdrawn via the DH dashboard
- ADRs host consent revocation endpoints to support notification of this event
- This increases infrastructure costs for ADRs
- This increases security complexity for the CDR
- Alternatively, ADRs can poll DHs to obtain the status of consent via the refresh_token "active" claim or richer consent introspection (e.g. authorization_details) or Consent API
Decisions to be made
- Short term: ADRs continue to host an ADR revocation end point until consent introspection is possible
- Requirements for DH hosted consent introspection / Consent API
- ADR preference to continue hosting revocation endpoint vs polling DHs
-
Continued review of iteration change request candidates following on from the call the previous week
-
219
-
Four options identified and discussed:
- Treat the cdr_arrangement_id as a long-lived "secret" and use it as a mechanism to allow ADRs to exchange for a refresh token if/when they lose their refresh token
- Clear up standards to be clear that refresh token cycling must only occur at least as a minimum of 28 days. This is currently a MAY and suggests that refresh tokens could be cycled every time an access token is requested which was never the original intent
- Turn off refresh cycling - this means that DHs cannot cycle refresh tokens and the refresh token will be bound to the length of consent
- If DHs wish to continue to supporting refresh token cycling they must cater for "confirmation of handover" to prevent loss of refresh token and ensure receipt of newly issued tokens
-
It was cited that refresh token cycling was originally intended for public clients (per original authors of the RFC). Since the CDR uses confidential clients (ADR software products) and employs HoK, JWKS and MTLS that there aren't any perceived security concerns that require refresh token cycling within the lifecycle of an authorisation grant.
-
There may be implementation considerations and IAM software configuration configurations however
-
Some DHs are cycling refresh tokens every time that access tokens are requested
-
Whilst allowed by the CDR standard, that wasn't the intent
-
Option 1 was discouraged because the cdr_arrangement_id may be a "secret" that continues over many years and many authorisation grants
- It is also freely shared via introspection endpoints
- Would require additional cryptographic proofs over the top
-
Option 2 doesn't really solve for the problem unless the issue is a bug that can be overcome by moving towards 28-day+ refresh token cycling
- Nevertheless clearing up the standards may be required depending on the option chosen
- This would have implementation impacts for one DH currently implementing refresh token cycling on every AT request
-
Option 3 would get rid of refresh token cycling and this issue should go away unless loss of tokens is being observed on authorisation (exchange of authorisation code)
- At least one DH confirmed they do not support any refresh token cycling and they are aligned with Option 3
-
Option 4 would allow DHs to make a choice
- The consequence is that DHs wishing to support refresh token cycling must then cater for a "confirmation of handover" pattern so there is no impact on ADRs
-
-
240
- Currently the standards require DHs to support access token revocation
- DSB has taken an action to speak with ACCC regarding the legal and liability question about the 10min window if ADR status is changed or the ADR is compromised.
- CDR Register has accepted a 5 min latency window for status changes to ADRs
- Potentially a compromise is to adjust the AT validity to be between 2-5min instead of 2-10min
- ADRs on the call noted that in the event of a systems compromise, they would be unlikely to issue access token revocation within the 2-10min window and would find it much easier to inform the ACCC and have their ADR status updated in the CDR Register because this acts as a broadcast mechanism to all DHs
- If the ADR had many thousands of ATs that were active, it is technically infeasible to cycle through all of the active ATs to revoke them
-
325
- The change that was previously made to the data standards was prior to the PAR endpoint being introduced
- As such, it made sense at the time however has implications where the audience claim wouldn't be correctly set for the PAR endpoint
- Discussed the updated statement based on the newly published PAR draft RFC wording
- This statement has ambiguity (it can imply that the aud = Token End Point URL would be acceptable when a call is made to the PAR endpont and vice versa. This is not the intention of the RFC author)
- As an improvement to this to remove ambiguity the proposed wording was suggested:
aud: The issuer identifier URL of the authorization server according to [RFC8414] SHOULD be used as the value of the audience. In order to facilitate interoperability the authorization server MUST accept its issuer identifier and the URI of the end point being called as values that identify it as an intended audience.
-
This would suitably cater for both the Token Endpoint and the PAR Endpoint as well as any other end points
-
Implementation impacts were discussed - this may result in less impact compared to the current wording in the standards
-
DHs have the action to review and report on agreement with the proposal and any implementation impacts
-
307
- Regarding metrics being brand aware, an action has been taken by CBA to provide more information on their change request. It is understood that CBA would represent each master brand as a separate DH instance and hence different Base URIs for each of their brands so they would be providing Metrics
- Where DHs choose to represent their brands under the one DH base URI, this is currently an implication based on the choice the DH makes.
- Further discussion pending CBA's update to the CR
-
315
- Discussed this issue in conjunction with Issue #328
- Core issue at the heart of the change request is to have greater certainty on obligations for each compliance milestone
- This doesn't require having obligation-based standards, but instead a clearer way to mapping Rules, Data Standards etc. against an obligation milestone
- Discussed that the DSB is reviewing is processes regarding standards publishing including:
- Adopt a development branch adjacent to master. Changes would be staged ahead of time for the community to review and tagged with CR and release
- Remove static docs from the master repository and build outside using a CI/CD pipeline. This would reduce the differentials / code diffs each release
- Move future dated obligations out of the standards into a separate phasing table. This would remove compliance based requirements from the standards and establish a mapping table to allow ADRs and DHs to understand implementation obligations for each compliance window
- Modularise standards: Rather than one large Markdown file and Swagger, this would be modularised for easier review and versioning
-
150
- Discussed the proposal to create a new line of credit product rather than have optional fields
- General consensus was to have conditional fields or default values rather than make fields optional
- Agreed to separate the two problems presented in the CR (closed accounts and credit products) as they are being conflated
- It was noted that this isn't an issue for all DHs and depends on how each DH implements products and accounts and how they are handled by each DH's core banking system
- Regarding end dates, some DHs noted that where an end date is not available, they select the next best date which may include a maximum epoch
- Action for DHs to check whether the issues identified in the CR impact their solutions
- Request to prioritise Issue #247 in next week's call was raised and accepted. This issue was not consulted on in this call.
- DSB provided an update on progress with Enhanced Error Handling
- Currently good progress on URN format and supporting Java code library to be distributed with the updated Decision Proposal
- DSB to follow up with the ACCC regarding legal liabilities regarding access token revocation if this was changed to a SHOULD for Issue #240
- DSB to provide updated wording for the aud claim description to Issue #325
- DHs to provide implementation impact analysis for Issue #325
- DSB to present options discussed on the call to issue #219
- DSB to follow up with ADRs to get volume/frequency metrics for loss of refresh token issues regarding Issue #219
- CBA to update Issue #307 whether (and how) this would impact CBA's brands and the key issue to solve
- Overview
- 2nd of May 2024
- 25th of April 2024 - Cancelled (ANZAC Day)
- 18th of April 2024
- 11th of April 2024
- 4th of April 2024
- March 2024 Agendas
- February 2024 Agendas
- January 2024 Agendas
- 2023 Agendas