-
Notifications
You must be signed in to change notification settings - Fork 56
DSB Maintenance Iteration 3 Decision Proposal Review Agenda & Meeting Notes (14th May 2020)
CDR API Stream edited this page May 15, 2020
·
5 revisions
Date and time: 14/05/2020, 2pm - 3pm AEST Location: WebEx
- https://csiro.webex.com/csiro/j.php?MTID=m04f83fb26610fae4b1db5d007f573fe3
- Dial In Number: +61 2 6246 4433
- Dial In Access Code: 780 996 986
- Quick Dial: +61262464433,782783445%23%23
Chair: Mark Verstege, DSB
Maintenance overview: Further information
Maintenance project board: See here
Please note this meeting covers the scope identified as part of Maintenance Iteration 3 represented by Decision Proposal 3.
- Introductions
- Outstanding Actions
- Release 1.3.1
- Review of Open Change Requests: walkthrough of change requests
- Any other business
Meeting notes
- Allow for participants to join
- Housekeeping
- Overview, purpose and intended outcomes of the meeting
- None
| 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, |
| #196 | Revocation Endpoint Clarification | Clarification is required for the ADR Revocation endpoint | Under consideration |
The list of decision proposals created in iteration 3:
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) 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 |
- 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
TBA