DSB Maintenance Iteration 3 Decision Proposal Review Agenda & Meeting Notes (14th May 2020) - ConsumerDataStandardsAustralia/standards GitHub Wiki

DSB Maintenance Iteration 3 - Decision Proposal Review - Agenda & Meeting Notes (2020-05-14)

Date and time: 14/05/2020, 2pm - 3pm AEST Location: WebEx

Chair: Mark Verstege, DSB
Maintenance overview: Further information
Maintenance project board: See here

Agenda

Please note this meeting covers the scope identified as part of Maintenance Iteration 3 represented by Decision Proposal 3.

Meeting notes

Introductions

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

Actions

  • None

Release 1.3.1

Issue # Issue Issue Summary Change proposed
#215 Revocation endpoint is no longer specified for the Data Recipient - as per V1.3.0 Data Recipient is removed from the Hosted By obligations although this is only accurate post-Nov Table will be updated to show ADR obligations for revocation endpoint prior to Nov 2020.
#202 Commissioning /decommissioning dates of the product APIs The standards state that v2 of PRD is to decom on August 29th 2020

Remove decommissioning statement for v2.

This version is to be ceased to be called by data recipients by August 29th 2020 and can be decommissioned by data holders as of that date.
#192 1.3.0: No GetProducts is valid between Aug 29 2020 and Feb 2021 See above
#190 V2 model should be labelled V3 PRD model versions incorrectly labelled v2 not v3 Fix to the swagger to correctly refer to v3 will be made
None Update URI Versioning non-normative example Non-normative example for base URI is incorrect Remove /<resource> - the non-normative example is there to represent what precedes the <resource>
#79 New constraint type for product detailed and account detailed endpoints Change introduced in 1.3.0 for Product Constrain Types but is inconsistent across MIN_LIMIT and MAX_LIMIT Documentation fix to use the same wording
#201 Product Reference Data obligations for non-major ADIs Error handling requirement isn't explicit

Change:

If all versions requested are not supported then the data holder should respond with a 406 Not Acceptable.

To:

If all versions requested are not supported then the data holder must respond with a 406 Not Acceptable.
None Clarify use of 422 error on "for specific Account" end points Current the requirement is ambiguous Update the text to clarify a 422 is required
#186 mutual_tls_sender_constrained_access_tokens metadata value has been superseded by tls_client_certificate_bound_access_tokens Update to reflective latest standards for using tls_client_certificate_bound_access_tokens and stop using mutual_tls_sender_constrained_access_tokens

Remove:

"mutual_tls_sender_constrained_access_tokens": "true",

And add:

"tls_client_certificate_bound_access_tokens": "true",
#180 Please fix non-normative example for refresh_token_expires_at and sharing_expires_at Change the values to be integers not strings
"refresh_token_expires_at": 1311281970,
"sharing_expires_at": 1311281970
#196 Revocation Endpoint Clarification Clarification is required for the ADR Revocation endpoint Under consideration

Decision Proposals

The list of decision proposals created in iteration 3:

DP # Issue
#119 Decision Proposal 119 - Enhanced Error Handling Payload Conventions
#120 Decision Proposal 120 - CDR Error Codes for Enhanced Error Handling
#121 Decision Proposal 121 - Application of existing HTTP Error Response Codes to Enhanced Error Handling
#122 Decision Proposal 122 - Extension of Supported HTTP Response Codes for Enhanced Error Handling

Change Requests

Proposed recommendations

The list of change requests considered in iteration 3:

Issue # Issue Proposed decision
#169 Align how audience is set for 'Data Recipients calling Data Holders’

Proposed:

Update:

The URL of the end point being invoked.

To:

The Token Endpoint URL.
#68 Enhanced Error Handling, #118, #164, #174 Four Decision Proposals have been created to track consultation on this topic (see above)
#79 New constraint type for product detailed and account detailed endpoints

Proposed:

MAX_LIMIT: A maximum limit exists (such as a maximum loan balance denoting the borrowable amount or maximum allowable credit limit)
MIN_LIMIT: A minimum limit exists (such as a minimum loan balance denoting the borrowable amount or minimum credit limit)

This will be fixed in 1.3.1
#64 Support URI Encoded images

Proposed:

1. The description of a "link" for card art, this can be changed to:

URI reference to a PNG, JPG or GIF image with proportions defined by ISO 7810 ID-1 and width no greater than 512 pixels. The URI reference may be a link or url-encoded data URI [RFC 2397].

2. As for changing BankingProductV3_cardArt to BankingProductCardArt there are already other precedents of the former. This change won't be adopted.
N/A Consent Model and technical roadmap. In progress. Deferred until Enhanced Error Handling is published
#168 New Product Fee Type - CALCULATED (to address issue #161) Introduction of a ProductFee.feeType = 'VARIABLE' with the amount, balanceRate, transactionRate and accruedRate properties becoming optional. The additionalInfo and additionalInfoUri should be used to describe the at-cost fee
#10 Tiered fees in Product Reference data Pending agreement on outcome for #168
#74 V1.1.0 Reintroduction of request_uri and/or Pushed Request Object Resolved - the use of request_uri is included within the use of Pushed Authorisation Requests support adopted for Concurrent Consent
#172 Validation of client_id parameter in client authentication requests Under review
#78 HTTP Header to be returned in the case where the request is not entirely well formed and a large page size is requested No change required.
#99 Update id_token example to correctly show nested jwt Under review
#175 Premature Completion of Consent (Hybrid) Flow Under review Will be addressed under the Consent Model consultation)
#101 Changes to align to FAPI and OIDF Specifications Round 2 Will be addressed under the Consent Model consultation

Notes

  • v1.3.1 is currently being staged for release next week
  • The recommended positions for each Change Request were reviewed with participants
  • Consensus was agreed based on the positions where a recommendation was given
  • Enhanced Error Handling is in final internal review and will be posted next week with walkthrough of the decision proposals to be organised after proposals have been posted for review and consideration

Other business TBA

Next Steps

TBA

⚠️ **GitHub.com Fallback** ⚠️