Skip to content

DSB Maintenance Iteration 9: Agenda & Meeting Notes (6 October 2021)

Jump to bottom
CDR API Stream edited this page Oct 14, 2021 · 5 revisions

DSB Maintenance Iteration 9 - Agenda & Meeting Notes (2021-10-06)

Date and time: 06/10/2021, 2pm - 3.30pm AEDT (1pm - 2.30pm AEST)
Location: WebEx
Dial-in details:

Chair: Mark Verstege, DSB; Ivan Hosgood ACCC
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 212

Agenda

  • 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

Introductions

This week is the third call of the 9th maintenance iteration. The purpose of the meeting is to discuss options for iteration candidates adopted in the 9th maintenance iteration

  • Allow 5 min for participants to join
  • Housekeeping
  • Overview, purpose and intended outcomes of the meeting

Actions

  • ANZ to create a change request to better support cursors for returning large result sets.
  • StayOrGo to create CDR Register change request for a public API to expose non-sensitive Data Holder metadata to public (unauthenticated) clients

Release plan

  • v1.11.1 was published on October 5th 2021. This release contains minor documentation errata
  • v1.12.0: Energy standards, Non-Functional Requirements
  • v1.13.0: Porting of Register standards from ACCC

Open / Active Decision Proposals

The following decision proposals are open for community feedback

DP # Closing date DP
216 Pending Decision Proposal 216 - Profile Scope Support
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
209 Pending Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile
206 Closed Decision Proposal 206 - Register Standards
203 No closing date Normative Standards Review (2021)
158 Closed Decision Proposal 158 - Participant capability discovery

Future Plan

Review of Q4 and new changes: https://github.com/ConsumerDataStandardsAustralia/future-plan/projects/1

Iteration 9 Change Requests

All open change requests can be found here:

Data Standards CRs:

Issues Consulted

The following issues have been consulted on during this iteration. The current status is summarised.

Source # Change Request Status Recommendation
Standards Maintenance Issue 404 Profile scope not aligned with CX standards Pending DP This issue will be consulted on in Decision Proposal 216 - Profile Scope Support given the breadth of the standards changes
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
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
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
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
CDR Register Issue 174 Update Register APIs to search for and differentiate between archived entities Delayed Carried over to next iteration
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
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.
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

CDR Register CRs:

Issue 169: CDR Register OpenID Configuration does not specify token signing algorithm support

  • Changes proposed: The swagger definition for the CDR Register OpenID Configuration endpoint does not reflect the design. The request_object_signing_alg_values_supported field needs to be removed and replaced with the token_endpoint_auth_signing_alg_values_supported field.

Issue 189: RegisterDataHolderAuth schema in GetDataHolderBrands descriptions to be clarified

Changes proposed:

  • RegisterDataHolderAuth
    Old Description: Provides details of authorisation endpoints for Data Holders
    New Description: Defines the mechanism used and associated endpoints for Data Holder to Data Recipient authentication

  • registerUType: Unchanged

  • jwksEndpoint
    Old Description: JWKS endpoint for private_key_jwt client authentication with Data Recipient
    New Description: JWKS endpoint used for authentication by the Data Holder with the Data Recipient

Issue 188: SSA definition: Deprecation of revocation_uri

  • Proposed that this issue is held over to the next iteration once the Register standards have been incorporated into the Consumer Data Standards
  • There is a risk that defining the deprecation schedule this maintenance iteration will be premature. The ACCC are anticipating future API work impacting SSA definitions. Rather than define the deprecation schedule in this maintenance iteration, the ACCC/DSV will combine this work with these future API changes so all impacts can be considered together.

Issue 186: Documentation improvement: JWT Signature verification requirements during the DCR flows

Registration request JWTs MUST be verified against the associated JWK published by the ADR. Data Holders must extract the jwks_uri from the SSA in the request and verify the request JWT signature accordingly

Data Standards Issues For Consultation

Issue 407: Align data quality NFR with Privacy Safeguard 11

In line with feedback from the OAIC regarding data quality requirements in relation to Privacy Safeguard 11, it is proposed to change the Data Quality section of the standards from:

Data holders are required to take reasonable steps to ensure that CDR data, having regard to the purpose for which it is held, is accurate and up to date.

A data holder is required to be able to demonstrate that reasonable steps to maintain data quality are being undertaken.

To instead be:

Data Holders and Data Recipients are required to comply with Privacy Safeguard 11 — Quality of CDR data in accordance with s 56EN(1) of the CDR legislation. Privacy Safeguard 11 includes, but is not limited to, requirements for Data Holders and Data Recipients to take reasonable steps to ensure that CDR data is accurate, up to date and complete.

Data Holders and Data Recipients are required to be able to demonstrate that reasonable steps to maintain data quality are being undertaken.

Issue 391: Remove requirement for at least one address in physicalAddresses array

To address raised in the CDR Support article where a physical address is held but is invalid and cannot be provided in a schema compliant manner, it is proposed to remove the requirement of at least one physical address.

This proposal would change the current text:

Must contain at least one address. One and only one address may have the purpose of REGISTERED. Zero or one, and no more than one, record may have the purpose of MAIL. If zero then the REGISTERED address is to be used for mail

To be:

One and only one address may have the purpose of REGISTERED. Zero or one, and no more than one, record may have the purpose of MAIL. If zero then the REGISTERED address is to be used for mail

Implementation considerations:

  • Impacts ADRs that currently rely on an address being present
  • Data Holders that cannot share one or more addresses must respond with an empty array "physicalAddresses": []

Issue 402: Support for multiple additional information documents

  • Requirements

    • Allow product references to include one or more (list) Terms & Conditions URIs
    • Based on consultation, other documents may also be required (e.g. travel insurance details for a credit card)
    • Based on consultation, denoting which document is the primary or secondary document for a given document type is important
    • Based on consultation, other document types may also benefit from a list vs single URI (e.g., bundleUri)

  • Options

    • Option 1: Add new AdditionalTermsUri list
      This option would add a new field which supports a list of additional (secondary) terms and conditions URIs.
/***********************
 * Proposal (Option 1):  
 ***********************/

    "BankingProductV4_additionalInformationV2": {
      "type": "object",
      "properties": {
        "overviewUri": {
          "type": "string",
          "description": "General overview of the product",
          "x-cds-type": "URIString"
        },
        "termsUri": {
          "type": "string",
          "description": "The primary terms and conditions for the product",
          "x-cds-type": "URIString"
        },
        "additionalTermsUri": {
          "type": "array",
          "description": "An array of additional terms and conditions for the product, if applicable",
          "items": {
            "type": "string",
            "x-cds-type": "URIString"
          }
        },
        /* ... */
      },
      "description": "Object that contains links to additional information on specific topics"
    }

/***********************
 * Example (Option 1):  
 ***********************/

"additionalInformation": {
    "overviewUri": "string",
    "termsUri": "string",
    "eligibilityUri": "string",
    "feesAndPricingUri": "string",
    "bundleUri": "string",
    "additionalTermsUri": [
      "https://bank.com.au/terms-and-conditions/travel-insurance-terms-and-conditions.pdf",
      "https://bank.com.au/terms-and-conditions/loyalty-rewards-terms-and-conditions.pdf"
    ]
}
  • Option 2: Support an array of additional information URIs.
/***********************
 * Proposal (Option 2):  
 ***********************/

    "BankingProductV4_additionalInformationV2": {
      "type": "array",
      "description": "Object that contains links to additional information on specific topics",
      "items": {
        "$ref": "#/definitions/BankingProductV4_additionalInformationV2_Uri"
      }
    },

    "BankingProductV4_additionalInformationV2_Uri": {
      "type": "object",
      "required": ["type", "uri"],
      "properties": {
        "isPrimaryUri": {
          "type": "boolean",
          "description": "Indicates whether the URI is the primary additional information document for the given type. Defaults to `true`. One one primary document URI for each document `type` is allowed.",
          "x-cds-type": "Boolean"
        },
        "type": {
          "type": "string",
          "description": "The type of additonal information document described",
          "enum": [
            "OVERVIEW", /* General overview of the product */
            "TERMS_AND_CONDITIONS", /* Terms and conditions for the product */
            "FEES_AND_RATES",
            "ELIGIBILITY",
            "BUNDLE"
          ]
        },
        "description": {
          "type": "string",
          "description": "Display text providing more information on the document"
        },
        "uri": {
          "type": "array",
          "description": "The URI describing the additional information",
          "items": {
            "type": "string",
            "x-cds-type": "URIString"
          }
        }
      }
    }

/***********************
 * Example (Option 2):  
 ***********************/

"additionalInformation": [
  {
    "isPrimaryUri": true,
    "type": "OVERVIEW",
    "uri": "https://bank.com.au/products/Travel-Credit-Card/"
  },
  {
    "additionalInfoType": "FEES_AND_RATES",
    "additionalInfoUri": "https://bank.com.au/products/Travel-Credit-Card/Fees.html"
  },
  {
    "type": "ELIGIBILITY",
    "uri": "https://bank.com.au/products/Travel-Credit-Card/Eligibility"
  },
  {
    "type": "TERMS_AND_CONDITIONS",
    "uri": "https://bank.com.au/products/Travel-Credit-Card/primary-terms-and-conditions.pdf"
  },
  {
    "type": "TERMS_AND_CONDITIONS",
    "description": "Terms and conditions for complementary travel insurance when the Platinum Advantage card is used to book flights and accommodation.",
    "isPrimaryUri": false,
    "uri": "https://bank.com.au/terms-and-conditions/travel-insurance-terms-and-conditions.pdf"
  },
  {
    "type": "TERMS_AND_CONDITIONS",
    "description": "Terms and conditions for the Platinum Advantage loyalty rewards scheme.",
    "isPrimaryUri": false,
    "uri": "https://bank.com.au/terms-and-conditions/loyalty-rewards-terms-and-conditions.pdf"
  }
}
  • Implementation Considerations
    • Option 1:
      • No breaking change to ADRs.
      • No change to the endpoint versioning
      • Less future-proof or flexible
      • Only addresses additional terms and conditions. Similar pattern could be adopted for secondary overview/bundle/entitlements/fees & rates document URIs
    • Option 2:
      • Creates breaking changes for ADRs and DHs
      • Creates a v4 for PRD endpoints
      • Future-proof and extensible: if new document types are added, this is easy to extend

Issue 401: Extending the list of supported feature types

  • Key issues:
    • (1) Inconsistency in industry usage of existing enumerated feature types and other types such as feeType (e.g. EARLY_TERMINATION_FEE vs EXIT_FEE)
    • (2) Many product differentiating features may be holder-specific. A structured collision-resistant subType (similar to error code URN naming conventions) may allow Data Holders to implement differentiating features. Over time, they may be standardised across the industry. Discussed whether a subType should be supported that can be specific to each DH. This would maximise competition and flexibility under a set of industry recognised and defined types
    • No ADR feedback has been provided in support of the change

Any other business

  • Address any other business arising from the community



Meeting Minutes

Notes

Actions

  • ANZ in the final stage of drafting a change request for pagination cursor support
    • May present different options for review and an ANZ recommendation

Register Issues

  • Ivan summarised in-flight changes, no comments from the community

Standards Maintenance Issues

  • Issue 407

    • No issues raised with the proposed re-wording

  • Issue 402

    • No further feedback raised. Proposal will be posted to the change request.
    • Noted that this would create a breaking change

  • Issue 391

    • No issues raised in regards to the options
    • Discussed whether a free form address format would be useful where banks can't sufficiently represent structured addresses.
    • Encouraged the community to raise this as a change request if this was considered important

  • Issue 401

    • Design & Distribution Obligations have come into effect. A community member raised the question of how the CDR will address this
    • Overlap with Issue 292
    • Inconsistency in use of featureType and feeType as well as the reliance on OTHER as a fallback category currently imposes high degree of internal mapping work on ADRs to standardise the usage of types across all Data Holder implementations
    • Improved consistency would benefit ADRs
    • Noted that consistency is good but there will always be a need to support flexibility and competition
    • Solutions should focus on balancing both considerations
    • Having holder-specific sub types was supported in principle
    • Proposed enumerated types:
      • Noted that instalment plan as a feature type was not useful - b better off being described within the fees and rates structures
      • WBC to propose descriptions for each featureType
    • Noted that Issue 408 deals with transaction limits.
    • Additional structure in addition to what is proposed may be useful
      • Discussed Introductory Offers as a primary rate or feature where a balance offer, flashback etc are not permanent features but they are offered an incentives for a short period of time to encourage customers to take up a product
    • With Buy Now, Pay Later (BNPL) products, there in an increasing need to solve for instalment plans for lending & credit products.
    • This is a core component of BNPL products and shouldn't be buried deep in the PRD representation
    • Features should be persistent things like payment wallets, insurance etc.

  • Issue 292

    • Credit Cards balance plans have their own interest rate
    • Cash advance rates don't typically have an interest free feature / rate
    • Instalment plans are an array of different rates
    • It's common for credit cards to have three or more balance plans for a loan
      • each has its own minimum repayment amount and payment date
    • hierarchy in the balance plan interest rates will help to calculate payments
      • It was noted that existing legislation already requires banks to pay off balances with the highest interest rates first
      • In this respect, having a hierarchy may not be useful other than as a representation of that or combining similar rates within a single plan
      • May require hierarchy to be ordered by / nested by highest interest rate
    • Noted that lendingRateType includes cash advance and purchase rates already but doesn't include balance transfer and instalment rate types
    • Could represent balances similar to purses in the BankingBalance structure
    • Lending rates need to reference or tie together to the balances so it is obvious what rate applies to which balance
    • This may be done via a unique reference ID
    • Balances should have a display name to represent the individual plans so ADRs can easily render them
    • Similar issue to credit cards with home loans supporting a portfolio loan structure (e.g. overall rate + separate fixed and variable rates)

  • Issue 291

    • Not discussed due to insufficient time. Carried over to next call

Other business

  • No other business raised

Next Steps

  • Not applicable

Actions

  • WBC to create proposed featureType descriptions for each enumerated featureType proposed in issue 401

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally