diff --git a/docs/includes/additional/additional20230708-23756-1rgimks b/docs/includes/additional/additional20230721-17819-179l1ax
similarity index 75%
rename from docs/includes/additional/additional20230708-23756-1rgimks
rename to docs/includes/additional/additional20230721-17819-179l1ax
index a63fe38f..93415bd9 100644
--- a/docs/includes/additional/additional20230708-23756-1rgimks
+++ b/docs/includes/additional/additional20230721-17819-179l1ax
@@ -1,10 +1,13 @@
Additional Standards
The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.
-
These standards fall into three categories:
-1. Candidate standards that are non-binding and stable
-2. Draft standards that are non-binding but volatile as they are under development
-3. Experimental standards that are transient and created to test concepts
+
These standards fall into three categories:
+
+
+
Candidate standards that are non-binding and stable
+
Draft standards that are non-binding but volatile as they are under development
+
Experimental standards that are transient and created to test concepts
+
Candidate Standards
The Consumer Data Standards currently include the following candidate standards:
diff --git a/docs/includes/cds_admin b/docs/includes/cds_admin
index c480943e..cd1bbd26 100644
--- a/docs/includes/cds_admin
+++ b/docs/includes/cds_admin
@@ -689,7 +689,7 @@ This operation may only be called by the CDR Register
]},"abandonmentsByStage":{
- "abandonedConsentFlowCount":{
+ "preIdentification":{"currentDay":0,"previousDays":[0
@@ -1263,7 +1263,7 @@ This operation may only be called by the CDR Register
]},"abandonmentsByStage":{
- "abandonedConsentFlowCount":{
+ "preIdentification":{"currentDay":0,"previousDays":[0
@@ -1375,7 +1375,7 @@ This operation may only be called by the CDR Register
Number of calls resulting in error due to server execution over time
» rejections
@@ -2519,7 +2519,7 @@ This operation may only be called by the CDR Register
}
-
Peak transactions per second over time
+
Number of calls resulting in error due to server execution over time
Properties
@@ -2842,7 +2842,7 @@ This operation may only be called by the CDR Register
]},"abandonmentsByStage":{
- "abandonedConsentFlowCount":{
+ "preIdentification":{"currentDay":0,"previousDays":[0
@@ -3151,7 +3151,7 @@ This operation may only be called by the CDR Register
Customer abandonment count per stage of the consent flow. Note that the aggregated abandonment count for all stages for a period should equal the count in abandonedConsentFlowCount for the same period (ie. each abandoned consent should assigned to one, and only one, stage)
-
»»»»»»» abandonedConsentFlowCount
+
»»»»»»» preIdentification
object
mandatory
The number of authorisations that commenced with the data holder but the customer did not successfully identify their profile or user ID
The future dated obligation date has been incorrectly documented in the standards as June 13th 2024. This was a documentation error when v1.25.0 of the standards were published. According to the decision of the Data Standards Chair (Decision 288) the obligation date for the implementation of Get Metrics v5 is May 13th 2024. This will be corrected in the next release of the standards.
+
+
Register APIs use local version of common definitions
The Register APIs use a locally defined version of common schema definitions such as ResponseErrorList for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec.
This page documents the deprecated version 4 of the Get Metrics end point.
-
This version must be implemented by data holders by 1st November 2023.
+
This version must be implemented by November 1st 2023 and may be obsoleted once v5 has been implemented
Get Metrics
@@ -322,15 +322,12 @@
Get Metrics
This end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).
-
NOTE: This version must be implemented by June 13th 2024
Added Data Holder Brands Summary API to endpoint schedule
-
Standards Maintenance #586](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Included the Get Data Holder Brands Summary API into the endpoint version schedule. Addresses this issue comment)
+
Standards Maintenance #586: Included the Get Data Holder Brands Summary API into the endpoint version schedule. Addresses this issue comment
Standards Maintenance #586](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Corrected typos in the endpoint version schedule. Addresses this issue comment)
Standards Maintenance #586](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Renamed InfoSec Profile to Security Profile and CDR Register APIs to Register APIs in the endpoint version schedule. Addresses this issue comment
+
Standards Maintenance #586: Renamed InfoSec Profile to Security Profile and CDR Register APIs to Register APIs in the endpoint version schedule. Addresses this issue comment
{ "errors": [
{
- "code": "urn:au-cds:error:cdr-all:Header/UnsupportedVersion",
+ "code": "urn:au-cds:error:cdr-all:Header/UnsupportedVersion",
"title": "Unsupported Version",
"detail": "'x-v' **MUST** be greater than or equal to '2'"
}
@@ -4892,9 +4892,7 @@
SSA Definition
Get Software Statement Assertion API v1 & v2 has the scope claim explicitly defined.
-
Registration Request using JWT
Removed following requirement from id_token_encrypted_response_alg and id_token_encrypted_response_enc fields:
-- Must be ignored for Authorization Code Flow
-
+
Registration Request using JWT
Example Request
Client registration with OpenID Hybrid Flow
@@ -24964,18 +24962,10 @@
Product Categories
-
Product & Account Components
Updated description of 'PENSION_RECIPIENT' value in
-'Product Eligibility Types' table from:
-- A recipient of a government pension may apply for the product
-to:
-+ Only a recipient of a government pension may apply for the product
-and 'Product Discount Eligibility Types' table from:
-- A recipient of a government pension may receive the discount
-to:
-+ Only a recipient of a government pension may receive the discount
-
+
Product & Account Components
+
-
Product Feature Types
+
Product Feature Types
Description of the usage of the featureType field as it applies to products.
@@ -46183,6 +46173,11 @@
Admin APIs
• Inclusion of aggregate metric for performance metrics
• Addition of abandonmentsByStage object to authorisation metrics
+Note that two typos were identified in the initial version of
+1.25.0 published on 8th July that have now been corrected. These
+are:
+• Incorrect description of the ErrorMetricsV2 model
+• Incorrect name of the preIdentification field
Customer abandonment count per stage of the consent flow. Note that the aggregated abandonment count for all stages for a period should equal the count in abandonedConsentFlowCount for the same period (ie. each abandoned consent should assigned to one, and only one, stage)
-
»»»»»»» abandonedConsentFlowCount
+
»»»»»»» preIdentification
object
mandatory
The number of authorisations that commenced with the data holder but the customer did not successfully identify their profile or user ID
@@ -53939,10 +53934,13 @@
Additional Standards
The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.
-
These standards fall into three categories:
-1. Candidate standards that are non-binding and stable
-2. Draft standards that are non-binding but volatile as they are under development
-3. Experimental standards that are transient and created to test concepts
+
These standards fall into three categories:
+
+
+
Candidate standards that are non-binding and stable
+
Draft standards that are non-binding but volatile as they are under development
+
Experimental standards that are transient and created to test concepts
+
Candidate Standards
The Consumer Data Standards currently include the following candidate standards:
@@ -53964,6 +53962,10 @@
Known Issues
+
Incorrect obligation date for Get Metrics v5
+
The future dated obligation date has been incorrectly documented in the standards as June 13th 2024. This was a documentation error when v1.25.0 of the standards were published. According to the decision of the Data Standards Chair (Decision 288) the obligation date for the implementation of Get Metrics v5 is May 13th 2024. This will be corrected in the next release of the standards.
+
+
Register APIs use local version of common definitions
The Register APIs use a locally defined version of common schema definitions such as ResponseErrorList for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec.
@@ -54031,7 +54033,7 @@
Change Log
-
08/06/2023
+
08/07/2023
1.25.0
Changes arising from Decision 303 (Maintenance iteration 15) and Decision 288 (Metrics and NFRs)
diff --git a/slate/source/includes/_admin.md.erb b/slate/source/includes/_admin.md.erb
index 01509ac6..6f34c9de 100644
--- a/slate/source/includes/_admin.md.erb
+++ b/slate/source/includes/_admin.md.erb
@@ -28,6 +28,11 @@ v5 changes are:
• Inclusion of aggregate metric for performance metrics
• Addition of abandonmentsByStage object to authorisation metrics
+Note that two typos were identified in the initial version of
+1.25.0 published on 8th July that have now been corrected. These
+are:
+• Incorrect description of the ErrorMetricsV2 model
+• Incorrect name of the preIdentification field
```
<%= partial "includes/cds_admin.md" %>
diff --git a/slate/source/includes/_dcr_apis.md.erb b/slate/source/includes/_dcr_apis.md.erb
index 4c296328..6fd40a8d 100644
--- a/slate/source/includes/_dcr_apis.md.erb
+++ b/slate/source/includes/_dcr_apis.md.erb
@@ -9,8 +9,4 @@ This specification defines the APIs for Data Holders exposing Dynamic Client Reg
-
-```diff
-Corrected various spelling and grammatical mistakes
-```
-
-<%= partial "includes/cds_telco.md" %>
diff --git a/slate/source/includes/additional.md b/slate/source/includes/additional.md
index 2f2a1b12..e7004d98 100644
--- a/slate/source/includes/additional.md
+++ b/slate/source/includes/additional.md
@@ -3,6 +3,7 @@
The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.
These standards fall into three categories:
+
1. `Candidate` standards that are non-binding and stable
2. `Draft` standards that are non-binding but volatile as they are under development
3. `Experimental` standards that are transient and created to test concepts
diff --git a/slate/source/includes/banking/_product_components.md b/slate/source/includes/banking/_product_components.md
index c47b9aad..4b1ea37d 100644
--- a/slate/source/includes/banking/_product_components.md
+++ b/slate/source/includes/banking/_product_components.md
@@ -1,15 +1,4 @@
## Product & Account Components
-```diff
-Updated description of 'PENSION_RECIPIENT' value in
-'Product Eligibility Types' table from:
-- A recipient of a government pension may apply for the product
-to:
-+ Only a recipient of a government pension may apply for the product
-and 'Product Discount Eligibility Types' table from:
-- A recipient of a government pension may receive the discount
-to:
-+ Only a recipient of a government pension may receive the discount
-```
Product Feature Types
diff --git a/slate/source/includes/cds_admin.md b/slate/source/includes/cds_admin.md
index 5dada3b8..eea960a2 100644
--- a/slate/source/includes/cds_admin.md
+++ b/slate/source/includes/cds_admin.md
@@ -595,7 +595,7 @@ If the Data Holder supports private_key_jwt client authentication they MUST vali
]
},
"abandonmentsByStage": {
- "abandonedConsentFlowCount": {
+ "preIdentification": {
"currentDay": 0,
"previousDays": [
0
@@ -1119,7 +1119,7 @@ This operation may only be called by the CDR Register
]
},
"abandonmentsByStage": {
- "abandonedConsentFlowCount": {
+ "preIdentification": {
"currentDay": 0,
"previousDays": [
0
@@ -1179,7 +1179,7 @@ This operation may only be called by the CDR Register
|» sessionCount|[SessionCountMetricsV2](#schemacdr-admin-apisessioncountmetricsv2)|mandatory|Session counts over time. Note that a session is defined as the provisioning of an Access Token.|
|» averageTps|[AverageTPSMetricsV2](#schemacdr-admin-apiaveragetpsmetricsv2)|mandatory|Average transactions per second over time|
|» peakTps|[PeakTPSMetricsV2](#schemacdr-admin-apipeaktpsmetricsv2)|mandatory|Peak transactions per second over time|
-|» errors|[ErrorMetricsV2](#schemacdr-admin-apierrormetricsv2)|mandatory|Peak transactions per second over time|
+|» errors|[ErrorMetricsV2](#schemacdr-admin-apierrormetricsv2)|mandatory|Number of calls resulting in error due to server execution over time|
|» rejections|[RejectionMetricsV3](#schemacdr-admin-apirejectionmetricsv3)|mandatory|Number of calls rejected due to traffic thresholds over time|
|» customerCount|[NaturalNumber](#common-field-types)|mandatory|Number of customers with active authorisations at the time of the call|
|» recipientCount|[NaturalNumber](#common-field-types)|mandatory|Number of Data Recipient Software Products with active authorisations at the time of the call|
@@ -1720,7 +1720,7 @@ This operation may only be called by the CDR Register
```
-*Peak transactions per second over time*
+*Number of calls resulting in error due to server execution over time*
### Properties
@@ -1891,7 +1891,7 @@ This operation may only be called by the CDR Register
]
},
"abandonmentsByStage": {
- "abandonedConsentFlowCount": {
+ "preIdentification": {
"currentDay": 0,
"previousDays": [
0
@@ -1981,7 +1981,7 @@ This operation may only be called by the CDR Register
|»»»»»»» currentDay|[NaturalNumber](#common-field-types)|conditional|Number of consents flows that were not successfully authorised for the current day|
|»»»»»»» previousDays|[integer]|conditional|Number of consents flows that were not successfully authorised for previous days. The first element indicates yesterday and so on. A maximum of seven entries is required if available|
|»»»»»» abandonmentsByStage|object|mandatory|Customer abandonment count per stage of the consent flow. Note that the aggregated abandonment count for all stages for a period should equal the count in `abandonedConsentFlowCount` for the same period (ie. each abandoned consent should assigned to one, and only one, stage)|
-|»»»»»»» abandonedConsentFlowCount|object|mandatory|The number of authorisations that commenced with the data holder but the customer did not successfully identify their profile or user ID|
+|»»»»»»» preIdentification|object|mandatory|The number of authorisations that commenced with the data holder but the customer did not successfully identify their profile or user ID|
|»»»»»»»» currentDay|[NaturalNumber](#common-field-types)|conditional|Number of abandoned consent flows for this stage for the current day|
|»»»»»»»» previousDays|[integer]|conditional|Number of abandoned consent flows for this stage for previous days. The first element indicates yesterday and so on. A maximum of seven entries is required if available|
|»»»»»»» preAuthentication|object|mandatory|The number of authorisations where the customer identified themselves (ie. they successfully identify the customer profile to use for the authorisation) but failed to provide a valid OTP or equivalent|
diff --git a/slate/source/includes/changelog.md b/slate/source/includes/changelog.md
index c98b2429..b57070fa 100644
--- a/slate/source/includes/changelog.md
+++ b/slate/source/includes/changelog.md
@@ -4,7 +4,7 @@ The following table lists the changes made to these standards in reverse date or
|Change Date|Version|Description|Detail Of change|
|-----------|-------|-----------|----------------|
-|08/06/2023| 1.25.0 | Changes arising from Decision 303 (Maintenance iteration 15) and Decision 288 (Metrics and NFRs) | See [release notes](includes/releasenotes/releasenotes.1.25.0.html), [Decision 303](https://github.com/ConsumerDataStandardsAustralia/standards/issues/303) and [Decision 288](https://github.com/ConsumerDataStandardsAustralia/standards/issues/288) for details. |
+|08/07/2023| 1.25.0 | Changes arising from Decision 303 (Maintenance iteration 15) and Decision 288 (Metrics and NFRs) | See [release notes](includes/releasenotes/releasenotes.1.25.0.html), [Decision 303](https://github.com/ConsumerDataStandardsAustralia/standards/issues/303) and [Decision 288](https://github.com/ConsumerDataStandardsAustralia/standards/issues/288) for details. |
|07/05/2023| 1.24.0 | Changes arising from Decision 281 (Maintenance iteration 14) | See [release notes](includes/releasenotes/releasenotes.1.24.0.html) and [Decision 281](https://github.com/ConsumerDataStandardsAustralia/standards/issues/281) for details. |
|14/04/2023| 1.23.0 | Changes arising from Decision Proposal 298 | See [release notes](includes/releasenotes/releasenotes.1.23.0.html) and [Decision 298](https://github.com/ConsumerDataStandardsAustralia/standards/issues/298) for details. |
|22/03/2023| 1.22.1 | Patch release including updates to draft Telco standards | See [release notes](includes/releasenotes/releasenotes.1.22.1.html) for details. |
diff --git a/slate/source/includes/endpoint-version-schedule/includes/_banking-dh.md b/slate/source/includes/endpoint-version-schedule/includes/_banking-dh.md
index 5a5c6549..99e00387 100644
--- a/slate/source/includes/endpoint-version-schedule/includes/_banking-dh.md
+++ b/slate/source/includes/endpoint-version-schedule/includes/_banking-dh.md
@@ -22,12 +22,12 @@
| Banking APIs | Get Direct Debits For Account | ``/banking/accounts/{accountId}/direct-debits`` | GET | V1 | 2020-11-01 | N/A | 2019-09-30, V1.0.0 | N/A |
| Banking APIs | Get Bulk Direct Debits | ``/banking/accounts/direct-debits`` | GET | V1 | 2020-11-01 | N/A | 2019-09-30, V1.0.0 | N/A |
| Banking APIs | Get Direct Debits For Specific Accounts | ``/banking/accounts/direct-debits`` | POST | V1 | 2020-11-01 | N/A | 2019-09-30, V1.0.0 | N/A |
-| Banking APIs | Get Scheduled Payments For Account | ``/banking/accounts/{accountId}/`` ``payments/scheduled`` | GET | V1 | 2020-11-01 | 2024-09-09 | 2019-09-30, V1.0.0 | TBC, V1.25.0 |
-| Banking APIs | Get Scheduled Payments For Account | ``/banking/accounts/{accountId}/`` ``payments/scheduled`` | GET | V2 | 2024-03-11 | N/A | TBC, V1.25.0 | N/A |
-| Banking APIs | Get Scheduled Payments Bulk | ``/banking/payments/scheduled`` | GET | V1 | 2020-11-01 | 2024-09-09 | 2019-09-30, V1.0.0 | TBC, V1.25.0 |
-| Banking APIs | Get Scheduled Payments Bulk | ``/banking/payments/scheduled`` | GET | V2 | 2024-03-11 | N/A | TBC, V1.25.0 | N/A |
-| Banking APIs | Get Scheduled Payments For Specific Accounts | ``/banking/payments/scheduled`` | POST | V1 | 2020-11-01 | 2024-09-09 | 2019-09-30, V1.0.0 | TBC, V1.25.0 |
-| Banking APIs | Get Scheduled Payments For Specific Accounts | ``/banking/payments/scheduled`` | POST | V2 | 2024-03-11 | N/A | TBC, V1.25.0 | N/A |
+| Banking APIs | Get Scheduled Payments For Account | ``/banking/accounts/{accountId}/`` ``payments/scheduled`` | GET | V1 | 2020-11-01 | 2024-09-09 | 2019-09-30, V1.0.0 | 2023-07-08, V1.25.0 |
+| Banking APIs | Get Scheduled Payments For Account | ``/banking/accounts/{accountId}/`` ``payments/scheduled`` | GET | V2 | 2024-03-11 | N/A | 2023-07-08, V1.25.0 | N/A |
+| Banking APIs | Get Scheduled Payments Bulk | ``/banking/payments/scheduled`` | GET | V1 | 2020-11-01 | 2024-09-09 | 2019-09-30, V1.0.0 | 2023-07-08, V1.25.0 |
+| Banking APIs | Get Scheduled Payments Bulk | ``/banking/payments/scheduled`` | GET | V2 | 2024-03-11 | N/A | 2023-07-08, V1.25.0 | N/A |
+| Banking APIs | Get Scheduled Payments For Specific Accounts | ``/banking/payments/scheduled`` | POST | V1 | 2020-11-01 | 2024-09-09 | 2019-09-30, V1.0.0 | 2023-07-08, V1.25.0 |
+| Banking APIs | Get Scheduled Payments For Specific Accounts | ``/banking/payments/scheduled`` | POST | V2 | 2024-03-11 | N/A | 2023-07-08, V1.25.0 | N/A |
| Banking APIs | Get Payees | ``/banking/payees`` | GET | V1 | 2020-11-01 | 2022-08-31 | 2019-09-30, V1.0.0 | 2021-12-23, V1.15.0|
| Banking APIs | Get Payees | ``/banking/payees`` | GET | V2 | 2022-07-31 | N/A | 2019-09-30, V1.0.0 | N/A |
| Banking APIs | Get Payee Detail | ``/banking/payees/{payeeId}`` | GET | V1 | 2020-11-01 | 2022-08-31 | 2019-09-30, V1.0.0 | 2021-12-23, V1.15.0|
diff --git a/slate/source/includes/endpoint-version-schedule/includes/_energy-dh.md b/slate/source/includes/endpoint-version-schedule/includes/_energy-dh.md
index d19ea5a3..64fddef8 100644
--- a/slate/source/includes/endpoint-version-schedule/includes/_energy-dh.md
+++ b/slate/source/includes/endpoint-version-schedule/includes/_energy-dh.md
@@ -18,12 +18,12 @@
| Energy APIs | Get Invoices For Account | ``/energy/accounts/{accountId}/invoices`` | GET | V1 | 2022-11-15 | N/A | 2021-10-29, V1.14.0| N/A |
| Energy APIs | Get Bulk Invoices | ``/energy/accounts/invoices`` | GET | V1 | 2022-11-15 | N/A | 2021-10-29, V1.14.0| N/A |
| Energy APIs | Get Invoices For Specific Accounts | ``/energy/accounts/invoices`` | POST | V1 | 2022-11-15 | N/A | 2021-10-29, V1.14.0| N/A |
-| Energy APIs | Get Billing For Account | ``/energy/accounts/{accountId}/billing`` | GET | V1 | 2022-11-15 | 2024-09-09 | 2021-10-29, V1.14.0| TBC, V1.25.0 |
-| Energy APIs | Get Billing For Account | ``/energy/accounts/{accountId}/billing`` | GET | V2 | 2023-11-01 | N/A | TBC, V1.25.0| N/A |
-| Energy APIs | Get Bulk Billing | ``/energy/accounts/billing`` | GET | V1 | 2022-11-15 | 2024-09-09 | 2021-10-29, V1.14.0| TBC, V1.25.0 |
-| Energy APIs | Get Bulk Billing | ``/energy/accounts/billing`` | GET | V2 | 2023-11-01 | N/A | TBC, V1.25.0| N/A |
-| Energy APIs | Get Billing For Specific Accounts | ``/energy/accounts/billing`` | POST | V1 | 2022-11-15 | 2024-09-09 | 2021-10-29, V1.14.0| TBC, V1.25.0 |
-| Energy APIs | Get Billing For Specific Accounts |``/energy/accounts/billing`` | POST | V2 | 2023-11-01 | N/A | TBC, V1.25.0| N/A |
+| Energy APIs | Get Billing For Account | ``/energy/accounts/{accountId}/billing`` | GET | V1 | 2022-11-15 | 2024-09-09 | 2021-10-29, V1.14.0| 2023-07-08, V1.25.0 |
+| Energy APIs | Get Billing For Account | ``/energy/accounts/{accountId}/billing`` | GET | V2 | 2023-11-01 | N/A | 2023-07-08, V1.25.0| N/A |
+| Energy APIs | Get Bulk Billing | ``/energy/accounts/billing`` | GET | V1 | 2022-11-15 | 2024-09-09 | 2021-10-29, V1.14.0| 2023-07-08, V1.25.0 |
+| Energy APIs | Get Bulk Billing | ``/energy/accounts/billing`` | GET | V2 | 2023-11-01 | N/A | 2023-07-08, V1.25.0| N/A |
+| Energy APIs | Get Billing For Specific Accounts | ``/energy/accounts/billing`` | POST | V1 | 2022-11-15 | 2024-09-09 | 2021-10-29, V1.14.0| 2023-07-08, V1.25.0 |
+| Energy APIs | Get Billing For Specific Accounts |``/energy/accounts/billing`` | POST | V2 | 2023-11-01 | N/A | 2023-07-08, V1.25.0| N/A |
## Energy Shared Responsibility APIs
diff --git a/slate/source/includes/introduction/_fdo.md b/slate/source/includes/introduction/_fdo.md
index f333d98b..73062a98 100644
--- a/slate/source/includes/introduction/_fdo.md
+++ b/slate/source/includes/introduction/_fdo.md
@@ -35,4 +35,4 @@ Added FDOs for decision 288 and 303
|[Get Scheduled Payments for Account V2](#get-scheduled-payments-for-account)|
Data Holders **MUST** implement v2 of this endpoint by **March 11th 2024**
Data Holders **MAY** obsolete v1 of this endpoint from **September 9th 2024**
| March 11th 2024 |
|[Get Scheduled Payments Bulk V2](#get-scheduled-payments-bulk)|
Data Holders **MUST** implement v2 of this endpoint by **March 11th 2024**
Data Holders **MAY** obsolete v1 of this endpoint from **September 9th 2024**
| March 11th 2024 |
|[Get Scheduled Payments For Specific Accounts V2](#get-scheduled-payments-for-specific-accounts)|
Data Holders **MUST** implement v2 of this endpoint by **March 11th 2024**
Data Holders **MAY** obsolete v1 of this endpoint from **September 9th 2024**
| March 11th 2024 |
-|[Get Metrics V5](#get-metrics)|
Data Holders **MUST** implement V5 of this endpoint by **June 13th 2023**
Data Holders **MAY** deprecate v4 of this endpoint once V5 is implemented**
| June 13th 2024 |
+|[Get Metrics V5](#get-metrics)|
Data Holders **MUST** implement V5 of this endpoint by **June 13th 2024**
Data Holders **MAY** deprecate v4 of this endpoint once V5 is implemented**
| June 13th 2024 |
diff --git a/slate/source/includes/known-issues.md b/slate/source/includes/known-issues.md
index e330d931..1dd4d68e 100644
--- a/slate/source/includes/known-issues.md
+++ b/slate/source/includes/known-issues.md
@@ -4,6 +4,7 @@ There are certain aspects of the standards that are actively under review. These
Issue | Description
:---- | :----------
+Incorrect obligation date for Get Metrics v5 | The future dated obligation date has been incorrectly documented in the standards as June 13th 2024. This was a documentation error when v1.25.0 of the standards were published. According to the decision of the Data Standards Chair (Decision 288) the obligation date for the implementation of Get Metrics v5 is **May 13th 2024**. This will be corrected in the next release of the standards.
Register APIs use local version of common definitions | The Register APIs use a locally defined version of common schema definitions such as `ResponseErrorList` for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec.
Register APIs use different field type definitions | The Register APIs define their own field types that are not consistent with the [Common Field Types](#common-field-types) defined in the data standards. As part of porting the Register standards across to the primary data standards, the field types need to be re-aligned to use the common field type definitions. For example, `string (data-time)` should be changed to `DataTime` and `integer(int32)` should be changed to `PositiveInteger`.
DCR and Register Swagger naming conventions | The DCR and Register naming conventions are not consistent with the broader data standards. Field names should be standardised to camelCase and snake_case inline with the data standards
@@ -26,5 +27,3 @@ API | Updated Error Codes | New Error Codes
[Get Software Products Statuses](#get-software-products-statuses) | 400: Missing Required Header / Invalid Header / Invalid Version / Invalid Field | 404: Invalid Industry
[Get Data Recipients Statuses](#get-data-recipients-statuses) | 400: Missing Required Header / Invalid Header / Invalid Version / Invalid Field | 404: Invalid Industry
[Get Data Recipients](#get-data-recipients) | 400: Missing Required Header / Invalid Header / Invalid Version / Invalid Field | 404: Invalid Industry
-
-
diff --git a/slate/source/includes/nfrs/_performance-requirements.md b/slate/source/includes/nfrs/_performance-requirements.md
index da5b9b21..be55883a 100644
--- a/slate/source/includes/nfrs/_performance-requirements.md
+++ b/slate/source/includes/nfrs/_performance-requirements.md
@@ -1,22 +1,5 @@
## Performance Requirements
-```diff
-Listed specific APIs in the `Unattended` section
-
-Fixed incorrect Energy API names replacing:
-- Get Accounts
-- Get Account Detail
-- Get Balance For Account
-- Get Bulk Balances
-- Get Balances For Specific Accounts
-with:
-+ Get Energy Accounts
-+ Get Energy Account Detail
-+ Get Balance For Energy Account
-+ Get Bulk Balances for Energy
-+ Get Balances For Specific Energy Accounts
-```
-
API end point performance will be measured in response time of individual API requests from receipt of request to delivery of response.
It is understood that different response times can be measured depending on which technical layer of an API implementation stack is instrumented and that not all of the technical layers between the Data Recipient Software Product and the Data Holder will be in the control of the Data Holder. As this is implementation specific it is expected that the Data Holder will ensure that the measurement of response time occurs as close to the Data Recipient Software Product as practicable.
@@ -27,10 +10,6 @@ In light of these considerations, the performance requirement for Data Holders i
The nominated threshold for each end point will be according to the following table:
-```delta
-Corrected the requirement for the Large Payload tier to remove reference to unattended calls
-```
-
|Tier|Response Time|Applies To…|
|----|-------------|-----------|
|Unauthenticated|**1500ms**|All Unauthenticated end points not otherwise specified in a separate threshold.|
diff --git a/slate/source/includes/obsolete/get-metrics-v4.html.md b/slate/source/includes/obsolete/get-metrics-v4.html.md
index f3f25b00..f7cefb26 100644
--- a/slate/source/includes/obsolete/get-metrics-v4.html.md
+++ b/slate/source/includes/obsolete/get-metrics-v4.html.md
@@ -13,7 +13,8 @@ search: false
# Get Metrics V4
This page documents the deprecated version 4 of the Get Metrics end point.
-This version must be implemented by data holders by 1st November 2023.
+This version must be implemented by **November 1st 2023** and may be obsoleted once v5 has been implemented
+
## Get Metrics
@@ -56,14 +57,11 @@ This end point allows the ACCC to obtain operational statistics from the Data Ho
This end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).
-NOTE: This version must be implemented by **June 13th 2024**
-
-Obsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).
+Obsolete versions: [v1](/includes/obsolete/get-metrics-v1.html) [v2](/includes/obsolete/get-metrics-v2.html).
Deprecated versions:
-- [v3](includes/obsolete/get-metrics-v3.html)
-- [v4](includes/obsolete/get-metrics-v4.html) - This version must be implemented by **November 1st 2023**
+- [v3](/includes/obsolete/get-metrics-v3.html)
If the Data Holder supports private_key_jwt client authentication they MUST validate the scope.
@@ -794,7 +792,7 @@ This operation may only be called by the CDR Register
|» sessionCount|[SessionCountMetricsV2](#schemacdr-admin-apisessioncountmetricsv2)|mandatory|Session counts over time. Note that a session is defined as the provisioning of an Access Token.|
|» averageTps|[AverageTPSMetricsV2](#schemacdr-admin-apiaveragetpsmetricsv2)|mandatory|Average transactions per second over time|
|» peakTps|[PeakTPSMetricsV2](#schemacdr-admin-apipeaktpsmetricsv2)|mandatory|Peak transactions per second over time|
-|» errors|[ErrorMetricsV2](#schemacdr-admin-apierrormetricsv2)|mandatory|Peak transactions per second over time|
+|» errors|[ErrorMetricsV2](#schemacdr-admin-apierrormetricsv2)|mandatory|Number of calls resulting in error due to server execution over time|
|» rejections|[RejectionMetricsV3](#schemacdr-admin-apirejectionmetricsv3)|mandatory|Number of calls rejected due to traffic thresholds over time|
|» customerCount|[NaturalNumber](#common-field-types)|mandatory|Number of customers with active authorisations at the time of the call|
|» recipientCount|[NaturalNumber](#common-field-types)|mandatory|Number of Data Recipient Software Products with active authorisations at the time of the call|
@@ -1209,7 +1207,7 @@ This operation may only be called by the CDR Register
```
-*Peak transactions per second over time*
+*Number of calls resulting in error due to server execution over time*
### Properties
diff --git a/slate/source/includes/releasenotes/releasenotes.1.25.0.html.md b/slate/source/includes/releasenotes/releasenotes.1.25.0.html.md
index b7eb1508..36eb64ec 100644
--- a/slate/source/includes/releasenotes/releasenotes.1.25.0.html.md
+++ b/slate/source/includes/releasenotes/releasenotes.1.25.0.html.md
@@ -42,10 +42,10 @@ This release addresses the following Decision Proposals published on [Standards]
|Change|Description|Link|
|------|-----------|----|
| Removed legacy obligation dates | [**Standards Maintenance #586**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Removed legacy obligation dates more than 6 months in the past. Addresses this issue [comment](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586#issuecomment-1541298747)) | [Future Dated Obligations](../../#future-dated-obligations) |
-| Added Data Holder Brands Summary API to endpoint schedule | **Standards Maintenance #586**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Included the Get Data Holder Brands Summary API into the endpoint version schedule. Addresses this issue [comment](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586#issuecomment-1552304480)) | [Endpoint Version Schedule](../../includes/endpoint-version-schedule/#endpoint-version-schedule) |
-| Typo correction in the endpoint schedule | **Standards Maintenance #586**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Corrected typos in the endpoint version schedule. Addresses this issue [comment](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586#issuecomment-1552317244)) | [Endpoint Version Schedule](../../includes/endpoint-version-schedule/#endpoint-version-schedule) |
-| Heading changes | **Standards Maintenance #586**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Renamed InfoSec Profile to Security Profile and CDR Register APIs to Register APIs in the endpoint version schedule. Addresses this issue [comment](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586#issuecomment-1552523783) | [Endpoint Version Schedule](../../includes/endpoint-version-schedule/#endpoint-version-schedule) |
-| Spelling mistake | **Standards Maintenance #586**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Fixed misspelling of "Register". Addresses this issue [comment](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586#issuecomment-1569508043) | [Future Dated Obligations](../../#future-dated-obligations) |
+| Added Data Holder Brands Summary API to endpoint schedule | [**Standards Maintenance #586**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Included the Get Data Holder Brands Summary API into the endpoint version schedule. Addresses this issue [comment](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586#issuecomment-1552304480) | [Endpoint Version Schedule](../../includes/endpoint-version-schedule/#endpoint-version-schedule) |
+| Typo correction in the endpoint schedule | [**Standards Maintenance #586**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Corrected typos in the endpoint version schedule. Addresses this issue [comment](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586#issuecomment-1552317244) | [Endpoint Version Schedule](../../includes/endpoint-version-schedule/#endpoint-version-schedule) |
+| Heading changes | [**Standards Maintenance #586**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Renamed InfoSec Profile to Security Profile and CDR Register APIs to Register APIs in the endpoint version schedule. Addresses this issue [comment](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586#issuecomment-1552523783) | [Endpoint Version Schedule](../../includes/endpoint-version-schedule/#endpoint-version-schedule) |
+| Spelling mistake | [**Standards Maintenance #586**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586): Fixed misspelling of "Register". Addresses this issue [comment](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/586#issuecomment-1569508043) | [Future Dated Obligations](../../#future-dated-obligations) |
## High Level Standards
diff --git a/slate/source/includes/security/_endpoints.md.erb b/slate/source/includes/security/_endpoints.md.erb
index 37797935..63a019e3 100644
--- a/slate/source/includes/security/_endpoints.md.erb
+++ b/slate/source/includes/security/_endpoints.md.erb
@@ -1,10 +1,4 @@
## Security Endpoints
-```diff
-Added statements noting CORS is not required for the following:
- * OpenID Provider Configuration End Point
- * Authorisation End Point
- * JSON Web Key Set End Point
-```
<%= partial "includes/security/endpoints/oidc_provider_configuration.md" %>
<%= partial "includes/security/endpoints/authorisation.md" %>
@@ -16,4 +10,4 @@ Added statements noting CORS is not required for the following:
<%= partial "includes/security/endpoints/cdr_arrangement_revocation.md" %>
<%= partial "includes/security/endpoints/par.md" %>
<%= partial "includes/security/endpoints/registration.md" %>
-<%= partial "includes/security/endpoints/register.md" %>
\ No newline at end of file
+<%= partial "includes/security/endpoints/register.md" %>
diff --git a/slate/source/includes/standards/_errors.md b/slate/source/includes/standards/_errors.md
index 7b68e364..c71c52ef 100644
--- a/slate/source/includes/standards/_errors.md
+++ b/slate/source/includes/standards/_errors.md
@@ -1,10 +1,4 @@
## Error Codes
-```diff
-Replaced following in description of 'Invalid Page Size':
-- page_size
-with:
-+ page-size
-```
These standards define a standard list of error codes that Data Recipient Software Products and Data Holders **SHOULD** or **MUST** conform to. Further,
diff --git a/slate/source/includes/standards/_types.md b/slate/source/includes/standards/_types.md
index 8e6f1503..bed52f25 100644
--- a/slate/source/includes/standards/_types.md
+++ b/slate/source/includes/standards/_types.md
@@ -1,9 +1,5 @@
## Common Field Types
-```diff
-Added actual % values represented by examples for RateString field type
-```
-
The following table outlines the common data types for fields used in the standard.
Type | Description | Valid Examples
diff --git a/slate/source/includes/swagger/cds_admin.json b/slate/source/includes/swagger/cds_admin.json
index 342b8b10..39dee4f9 100644
--- a/slate/source/includes/swagger/cds_admin.json
+++ b/slate/source/includes/swagger/cds_admin.json
@@ -400,7 +400,7 @@
"type" : "object"
},
"ErrorMetricsV2" : {
- "description" : "Peak transactions per second over time",
+ "description" : "Number of calls resulting in error due to server execution over time",
"properties" : {
"aggregate" : {
"$ref" : "#/components/schemas/ErrorMetricsV2_aggregate"
@@ -1759,7 +1759,7 @@
"type" : "object",
"x-conditional" : [ "currentDay", "previousDays" ]
},
- "AuthorisationMetricsV2_abandonmentsByStage_abandonedConsentFlowCount" : {
+ "AuthorisationMetricsV2_abandonmentsByStage_preIdentification" : {
"description" : "The number of authorisations that commenced with the data holder but the customer did not successfully identify their profile or user ID",
"properties" : {
"currentDay" : {
@@ -1882,8 +1882,8 @@
"AuthorisationMetricsV2_abandonmentsByStage" : {
"description" : "Customer abandonment count per stage of the consent flow. Note that the aggregated abandonment count for all stages for a period should equal the count in `abandonedConsentFlowCount` for the same period (ie. each abandoned consent should assigned to one, and only one, stage)",
"properties" : {
- "abandonedConsentFlowCount" : {
- "$ref" : "#/components/schemas/AuthorisationMetricsV2_abandonmentsByStage_abandonedConsentFlowCount"
+ "preIdentification" : {
+ "$ref" : "#/components/schemas/AuthorisationMetricsV2_abandonmentsByStage_preIdentification"
},
"preAuthentication" : {
"$ref" : "#/components/schemas/AuthorisationMetricsV2_abandonmentsByStage_preAuthentication"
@@ -1901,7 +1901,7 @@
"$ref" : "#/components/schemas/AuthorisationMetricsV2_abandonmentsByStage_failedTokenExchange"
}
},
- "required" : [ "abandonedConsentFlowCount", "failedTokenExchange", "preAccountSelection", "preAuthentication", "preAuthorisation", "rejected" ],
+ "required" : [ "failedTokenExchange", "preAccountSelection", "preAuthentication", "preAuthorisation", "preIdentification", "rejected" ],
"type" : "object"
},
"ResponseErrorListV2_errors" : {
diff --git a/slate/source/includes/swagger/cds_admin.yaml b/slate/source/includes/swagger/cds_admin.yaml
index 8f709dd3..4224a198 100644
--- a/slate/source/includes/swagger/cds_admin.yaml
+++ b/slate/source/includes/swagger/cds_admin.yaml
@@ -517,11 +517,6 @@ components:
nonIndividual: 5
individual: 7
abandonmentsByStage:
- abandonedConsentFlowCount:
- previousDays:
- - 0
- - 0
- currentDay: 8
preAuthorisation:
previousDays:
- 3
@@ -537,6 +532,11 @@ components:
- 7
- 7
currentDay: 8
+ preIdentification:
+ previousDays:
+ - 0
+ - 0
+ currentDay: 8
failedTokenExchange:
previousDays:
- 0
@@ -983,7 +983,8 @@ components:
- unauthenticated
type: object
ErrorMetricsV2:
- description: Peak transactions per second over time
+ description: Number of calls resulting in error due to server execution over
+ time
example:
authenticated:
previousDays:
@@ -1090,11 +1091,6 @@ components:
nonIndividual: 5
individual: 7
abandonmentsByStage:
- abandonedConsentFlowCount:
- previousDays:
- - 0
- - 0
- currentDay: 8
preAuthorisation:
previousDays:
- 3
@@ -1110,6 +1106,11 @@ components:
- 7
- 7
currentDay: 8
+ preIdentification:
+ previousDays:
+ - 0
+ - 0
+ currentDay: 8
failedTokenExchange:
previousDays:
- 0
@@ -1504,11 +1505,6 @@ components:
nonIndividual: 5
individual: 7
abandonmentsByStage:
- abandonedConsentFlowCount:
- previousDays:
- - 0
- - 0
- currentDay: 8
preAuthorisation:
previousDays:
- 3
@@ -1524,6 +1520,11 @@ components:
- 7
- 7
currentDay: 8
+ preIdentification:
+ previousDays:
+ - 0
+ - 0
+ currentDay: 8
failedTokenExchange:
previousDays:
- 0
@@ -3235,7 +3236,7 @@ components:
x-conditional:
- currentDay
- previousDays
- AuthorisationMetricsV2_abandonmentsByStage_abandonedConsentFlowCount:
+ AuthorisationMetricsV2_abandonmentsByStage_preIdentification:
description: The number of authorisations that commenced with the data holder
but the customer did not successfully identify their profile or user ID
example:
@@ -3401,11 +3402,6 @@ components:
the count in `abandonedConsentFlowCount` for the same period (ie. each abandoned
consent should assigned to one, and only one, stage)
example:
- abandonedConsentFlowCount:
- previousDays:
- - 0
- - 0
- currentDay: 8
preAuthorisation:
previousDays:
- 3
@@ -3421,6 +3417,11 @@ components:
- 7
- 7
currentDay: 8
+ preIdentification:
+ previousDays:
+ - 0
+ - 0
+ currentDay: 8
failedTokenExchange:
previousDays:
- 0
@@ -3432,8 +3433,8 @@ components:
- 5
currentDay: 5
properties:
- abandonedConsentFlowCount:
- $ref: '#/components/schemas/AuthorisationMetricsV2_abandonmentsByStage_abandonedConsentFlowCount'
+ preIdentification:
+ $ref: '#/components/schemas/AuthorisationMetricsV2_abandonmentsByStage_preIdentification'
preAuthentication:
$ref: '#/components/schemas/AuthorisationMetricsV2_abandonmentsByStage_preAuthentication'
preAccountSelection:
@@ -3445,11 +3446,11 @@ components:
failedTokenExchange:
$ref: '#/components/schemas/AuthorisationMetricsV2_abandonmentsByStage_failedTokenExchange'
required:
- - abandonedConsentFlowCount
- failedTokenExchange
- preAccountSelection
- preAuthentication
- preAuthorisation
+ - preIdentification
- rejected
type: object
ResponseErrorListV2_errors:
diff --git a/swagger-gen/api/cds_admin.json b/swagger-gen/api/cds_admin.json
index 317ce371..9d1b8e04 100644
--- a/swagger-gen/api/cds_admin.json
+++ b/swagger-gen/api/cds_admin.json
@@ -1317,7 +1317,7 @@
"unauthenticated",
"authenticated"
],
- "description": "Peak transactions per second over time",
+ "description": "Number of calls resulting in error due to server execution over time",
"type": "object",
"properties": {
"aggregate": {
@@ -1876,7 +1876,7 @@
},
"abandonmentsByStage": {
"required": [
- "abandonedConsentFlowCount",
+ "preIdentification",
"preAuthentication",
"preAccountSelection",
"preAuthorisation",
@@ -1885,7 +1885,7 @@
],
"type": "object",
"properties": {
- "abandonedConsentFlowCount": {
+ "preIdentification": {
"type": "object",
"properties": {
"currentDay": {
diff --git a/swagger-gen/cds_admin.md b/swagger-gen/cds_admin.md
index 5dada3b8..eea960a2 100644
--- a/swagger-gen/cds_admin.md
+++ b/swagger-gen/cds_admin.md
@@ -595,7 +595,7 @@ If the Data Holder supports private_key_jwt client authentication they MUST vali
]
},
"abandonmentsByStage": {
- "abandonedConsentFlowCount": {
+ "preIdentification": {
"currentDay": 0,
"previousDays": [
0
@@ -1119,7 +1119,7 @@ This operation may only be called by the CDR Register
]
},
"abandonmentsByStage": {
- "abandonedConsentFlowCount": {
+ "preIdentification": {
"currentDay": 0,
"previousDays": [
0
@@ -1179,7 +1179,7 @@ This operation may only be called by the CDR Register
|» sessionCount|[SessionCountMetricsV2](#schemacdr-admin-apisessioncountmetricsv2)|mandatory|Session counts over time. Note that a session is defined as the provisioning of an Access Token.|
|» averageTps|[AverageTPSMetricsV2](#schemacdr-admin-apiaveragetpsmetricsv2)|mandatory|Average transactions per second over time|
|» peakTps|[PeakTPSMetricsV2](#schemacdr-admin-apipeaktpsmetricsv2)|mandatory|Peak transactions per second over time|
-|» errors|[ErrorMetricsV2](#schemacdr-admin-apierrormetricsv2)|mandatory|Peak transactions per second over time|
+|» errors|[ErrorMetricsV2](#schemacdr-admin-apierrormetricsv2)|mandatory|Number of calls resulting in error due to server execution over time|
|» rejections|[RejectionMetricsV3](#schemacdr-admin-apirejectionmetricsv3)|mandatory|Number of calls rejected due to traffic thresholds over time|
|» customerCount|[NaturalNumber](#common-field-types)|mandatory|Number of customers with active authorisations at the time of the call|
|» recipientCount|[NaturalNumber](#common-field-types)|mandatory|Number of Data Recipient Software Products with active authorisations at the time of the call|
@@ -1720,7 +1720,7 @@ This operation may only be called by the CDR Register
```
-*Peak transactions per second over time*
+*Number of calls resulting in error due to server execution over time*
### Properties
@@ -1891,7 +1891,7 @@ This operation may only be called by the CDR Register
]
},
"abandonmentsByStage": {
- "abandonedConsentFlowCount": {
+ "preIdentification": {
"currentDay": 0,
"previousDays": [
0
@@ -1981,7 +1981,7 @@ This operation may only be called by the CDR Register
|»»»»»»» currentDay|[NaturalNumber](#common-field-types)|conditional|Number of consents flows that were not successfully authorised for the current day|
|»»»»»»» previousDays|[integer]|conditional|Number of consents flows that were not successfully authorised for previous days. The first element indicates yesterday and so on. A maximum of seven entries is required if available|
|»»»»»» abandonmentsByStage|object|mandatory|Customer abandonment count per stage of the consent flow. Note that the aggregated abandonment count for all stages for a period should equal the count in `abandonedConsentFlowCount` for the same period (ie. each abandoned consent should assigned to one, and only one, stage)|
-|»»»»»»» abandonedConsentFlowCount|object|mandatory|The number of authorisations that commenced with the data holder but the customer did not successfully identify their profile or user ID|
+|»»»»»»» preIdentification|object|mandatory|The number of authorisations that commenced with the data holder but the customer did not successfully identify their profile or user ID|
|»»»»»»»» currentDay|[NaturalNumber](#common-field-types)|conditional|Number of abandoned consent flows for this stage for the current day|
|»»»»»»»» previousDays|[integer]|conditional|Number of abandoned consent flows for this stage for previous days. The first element indicates yesterday and so on. A maximum of seven entries is required if available|
|»»»»»»» preAuthentication|object|mandatory|The number of authorisations where the customer identified themselves (ie. they successfully identify the customer profile to use for the authorisation) but failed to provide a valid OTP or equivalent|