V1.17.0 Release Notes
Release notes for version v1.17.0 of the CDR Standards.
Changes Made
Change Requests
This release addresses the following change requests raised on Standards Maintenance:
- Standards Maintenance Issue 504: Correct Data Language for Contact Details (profile scope and individual claims)
- Standards Maintenance Issue 503: Fix documentation defect for CDR Arrangement JWT method
- Standards Maintenance Issue 501: Register API x-v headers moving to mandatory impacts compatibility with older versions of these APIs
- Standards Maintenance Issue 498: New Register Authenticated APIs versions require multiple authorisation scopes
- Standards Maintenance Issue 488: Data holder behaviour clarification required when receiving registrations with unsupported authorisation scopes
- Standards Maintenance Issue 482: JWT signing non-normative examples use unsupported signing algorithm
- Standards Maintenance Issue 478: Energy Secondary Data Holder & Application Specific Errors
- Standards Maintenance Issue 476: Modify Energy concessions structure to allow non-fixed (e.g. daily, monthly etc.) concessions
- Standards Maintenance Issue 465: Confirm Register API 2022 release dates
- Standards Maintenance Issue 457: Energy - Get Service Point Detail register suffix should be optional
- Standards Maintenance Issue 453: Consider an upper bound on trusting entity statuses when they go missing
- Standards Maintenance Issue 452: Deprecation and retirement dates for CDR Register superseded endpoint versions needs to be defined
- Standards Maintenance Issue 449: EnergyPlanSolarFeedInTariff days field should be mandatory
- Standards Maintenance Issue 448: EnergyPlanDiscounts contains optional fields that should be conditional
- Standards Maintenance Issue 444: Add an unauthenticated GetDataHolderBrands endpoint exposed as a public API
- Standards Maintenance Issue 439: Review Pricing Model & Time Zone attributes within Account Detail Payload
- Standards Maintenance Issue 438: Representing adjustment transactions within the Billing Payload for C&I customers
- Standards Staging Issue 170: Fix documentation defect for meters and registers object in EnergyServicePointDetail model
- Standards Staging Issue 153: Modifiy Energy 'location' to be a CommonPhysicalAddress model
- Standards Staging Issue 133: Delete 'days' from applicable period for energy APIs
- Standards Staging Issue 131: Minor edit - replace 'as a query parameter' with 'a path'
- Standards Staging Issue 167: Fix documentation defect to make x-fapi-interaction-id as mandatory in Energy SDH APIs
Decision Proposals
This release addresses the following Decision Proposals published on Standards:
High Level Standards
Change | Description | Link |
---|---|---|
Obligation date highlighting | Highlighting based on a date pickers has been added for the Endpoint versioning schedule to enhance documentation functionality. This feature allows users to select a target date and determine what obligations apply at that date. | Endpoint versioning schedule |
Obligation Dates Table | A series of fixed obligation milestones were agreed in Maintenance Iteration 10. This set of milestones will be used to pin breaking changes to a deterministic series of possible obligation dates. | Obligation Dates |
Scrollable diffs and examples | Added previous and next buttons to support easy scrolling between all diffs and non-normative examples. This feature is context dependent on the tab being viewed | N/A |
oldest-date description | Standards Staging #133: Corrected description of 'oldest-date' by removing the word 'days'. | Energy Schema |
RateString description | Standards Maintenance #476: Changed RateString type to represent generic percentages. | Common Field Types |
Introduction | Standards Maintenance #465 Moved Register FDOs to the Register dependency schedule to differentiate Register delivery from Participant future dated obligations. Register API versions now have dependency dates of 15th November 2022, aligned to Energy | Register Dependencies Schedule |
Shared Responsibility-Energy | Standards Staging #131: Updated fifth bullet-point in Energy Endpoint Variations section to clarify that servicePointId should be replaced with NMI in path parameter as well | Energy |
API End Points
Change | Description | Link |
---|---|---|
Energy schema | Standards Maintenance #439 Added timezone field to EnergyPlanTariffPeriod. Updated description of EnergyPlanContract.timezone to specify default value of AEST | Energy Schema |
Energy schema | Standards Maintenance #449: Made EnergyPlanSolarFeedInTariff.timeVaryingTariffs.timeVariations.days mandatory | Energy Schema |
Energy schema | Standards Maintenance #448: Changed percentOfBill, percentOfUse, fixedAmount and percentOverThreshold attributes from optional to conditional within EnergyPlanDiscounts schema | Energy Schema |
Energy schema | Standards Maintenance #438: Added 'calculationFactors' and 'adjustments' objects to 'EnergyBillingOtherTransaction' model to allow consistent representation of any calculation factors (i.e. DLF or MLF) used for deriving other charges and any adjustments arising from other types of charges such as environmental charge. | Energy Schema |
Energy schema | Standards Maintenance #457 Made EnergyServicePointDetail.meters.registers.registerSuffix field optional | Energy Schema |
Energy schema | Standards Staging #153: Modified Energy 'location' to be a CommonPhysicalAddress model | Energy Schema |
Energy schema | Standards Maintenance #478 Made EnergyServicePointDetail.meters and EnergyServicePointDetail.meters.registers fields optional | Energy Schema |
Energy schema | Standards Maintenance #476: Updated EnergyConcession model to allow representation of concessions that are calculated based on variable parameters | Energy Schema |
Energy schema | Standards Staging #170: The EnergyServicePointDetail.meters and EnergyServicePointDetail.meters.registers have been made into arrays, correcting a technical documentation issue | Energy Schema |
Energy schema | Standards Staging #167: Made x-fapi-interaction-id header mandatory in Energy secondary data holder APIs, correcting a technical documentation issue | Energy Schema |
CDR Register APIs Endpoint Version Schedule | Standards Maintenance #452 Set retirement dates for outstanding deprecated Register APIs | Endpoint Version Schedule |
Register APIs | Standards Maintenance #501: x-v header requirements for versioned Register APIs moved from mandatory to optional |
Register APIs |
Register APIs | Standards Maintenance #444 Added GetDataHolderBrandsSummary API to expose public details of Data Holder Brands from the CDR Register to public clients | Register APIs |
Register APIs | Standards Maintenance #498 New authenticated endpoints only require cdr-register:read as the authorisation scope |
Register APIs |
Information Security Profile
Change | Description | Link |
---|---|---|
CDR Arrangement Revocation End Point | Standards Maintenance Issue 503: Corrected the documentation to include CDR Arrangement Form Parameter and CDR Arrangement JWT methods. Previous versions did not include this documentation correctly. | CDR Arrangement Revocation End Point |
CDR Arrangement Revocation End Point non-normative example | Standards Maintenance #482: Updated data recipient hosted CDR Arrangement Revocation End Point non-normative example alg field from HS256 to PS256 |
Security Endpoints |
Self-signed JWT Client Authentication non-normative example | Standards Maintenance #482: Updated self-signed JWT client authentication non-normative example alg field from HS256 to PS256 |
Client Authentication |
Data Holder Responsibilities | Standards Maintenance #453: Added clarification that when statuses are not received or recognised from the CDR Register, the ACCC can inform Data Holders of statuses to trust using an alternative mechanism. There is no upper bound for how long previous status values should remain trusted. | Data Holder Responsibilities |
Registration Validation | Standards Maintenance #488: Added requirement for data holders to ignore unsupported authorisation scopes | Registration Validation |
Consumer Experience
Change | Description | Link |
---|---|---|
OIDC Contact Detail claims | Standards Maintenance #504: Data language standards have been corrected to clarify that individual OIDC standard contact detail claims must be requested individually and not using the OIDC profile scope. These claims are optional for the Data Holder support and Data Recipients should check the Data Holder's OIDD discovery document to determine which claims are supported by inspecting the claims_supported parameter. |
Profile scope |