Maintenance Iteration 18 Holistic Feedback about standards-maintenance HOT 14 CLOSED

There is a typo in the following text in the Security Endpoints section -

Data Recipient Software Products MUST NOT reject requests including the cdr_arragement_id as a form parameter.

cdr_arragement_id should be cdr_arrangement_id

from standards-maintenance.

The following Register APIs incorrectly specify a message body for 401 error responses:

• Get Data Holder Brands
• Get Software Statement Assertion (SSA)

The change is to remove ResponseErrorListV2 as the listed schema. These APIs conform to RFC6750 returning an oAuth error in the WWW-Authenticate response header.

from standards-maintenance.

Two sentences at the start of the Participant Statuses section refer to 'Software Package'. These appear to be mistakes, and should be updated to 'Software Product' for consistency.

from standards-maintenance.

The ClientRegistration schema is not referenced by any endpoints, but represents the decoded string(JWT) specified in the ClientRegistrationRequest.

To provide clarity, the ClientRegistration schema could be referenced in the description of the ClientRegistrationRequest field as follows (bold text to highlight the addition only) –

The registration request JWT to be used to register with a Data Holder. The schema of the payload section of the decoded string(JWT) is defined in ClientRegistration.

from standards-maintenance.

A point under Data Holders in the Request Object section states -

• Data Holders MUST require PAR for authorisation request data in accordance with [RFC9126] where "require_pushed_authorization_requests" parameter is set to "true".

while it should be clear from other statements in the Standards and the upstream spec., the last word ("true") could be changed to true to better convey that the value is expected to be a Boolean.

from standards-maintenance.

The following line in the Non-normative Examples alongside HTTP Headers should be removed; it is not an Accept header like others in that block and the value appears to be mismatched with the name -

Accept-Encoding: charset=UTF-8

from standards-maintenance.

Update Register API descriptions

The ACCC suggests that two Register endpoint descriptions should be updated to clarify when data holders are expected to begin appearing in responses, and what information is currently available. This is intended to address questions raised by stakeholders.

We suggest that the relevant endpoint descriptions should be updated to specify that:

• Get Data Holder Brands Summary includes all data holder brands for which product reference data is available. For data holders that are active for consumer data sharing, the value disclosed is the public base uri. For brands that are not active for consumer data sharing, the value disclosed is the uri that discloses product data relevant to that brand, as provided by the relevant data holder.
• Get Data Holder Brands includes all data holders that have become active for consumer data sharing and have not been archived.

We suggest that the API description in the specification be updated to ensure that users of these endpoints understand their behaviour and the differences between them.

These clarifications reflect current Register behaviour. Accordingly, we consider that this change is non-breaking change.

Area Affected

• Get Data Holder Brands Endpoint Version
• Get Data Holder Brands Summary Endpoint Version

Change Proposed
Register APIs: To include the following information in the endpoint descriptions:

• Get Data Holder Brands Summary includes all data holder brands for which product reference data is available. For data holders who are active for consumer data sharing, the value disclosed is their public base uri. For data holders who are not active for consumer data sharing, the value disclosed is the uri that discloses product data relevant to that brand.
• Get Data Holder Brands includes all data holders who have become active for consumer data sharing and have not been archived.

from standards-maintenance.

The following change has been staged for review:

There is a typo in the following text in the Security Endpoints section -

Data Recipient Software Products MUST NOT reject requests including the cdr_arragement_id as a form parameter.

cdr_arragement_id should be cdr_arrangement_id

ConsumerDataStandardsAustralia/standards-staging@release/1.30.0...maintenance/629#issuecomment-1920466440

from standards-maintenance.

The following change has been staged for review:

The following Register APIs incorrectly specify a message body for 401 error responses:

• Get Data Holder Brands
• Get Software Statement Assertion (SSA)

The change is to remove ResponseErrorListV2 as the listed schema. These APIs conform to RFC6750 returning an oAuth error in the WWW-Authenticate response header.

ConsumerDataStandardsAustralia/standards-staging@release/1.30.0...maintenance/629#issuecomment-1930936447

from standards-maintenance.

The following change has been staged for review:

Two sentences at the start of the Participant Statuses section refer to 'Software Package'. These appear to be mistakes, and should be updated to 'Software Product' for consistency.

ConsumerDataStandardsAustralia/standards-staging@release/1.30.0...maintenance/629#issuecomment-1938107616

from standards-maintenance.

The following change has been staged for review:

The ClientRegistration schema is not referenced by any endpoints, but represents the decoded string(JWT) specified in the ClientRegistrationRequest.

To provide clarity, the ClientRegistration schema could be referenced in the description of the ClientRegistrationRequest field as follows (bold text to highlight the addition only) –

The registration request JWT to be used to register with a Data Holder. The schema of the payload section of the decoded string(JWT) is defined in ClientRegistration.

ConsumerDataStandardsAustralia/standards-staging@release/1.30.0...maintenance/629#issuecomment-1940397162

from standards-maintenance.

The following change has been staged for review:

A point under Data Holders in the Request Object section states -

• Data Holders MUST require PAR for authorisation request data in accordance with [RFC9126] where "require_pushed_authorization_requests" parameter is set to "true".

while it should be clear from other statements in the Standards and the upstream spec., the last word ("true") could be changed to true to better convey that the value is expected to be a Boolean.

ConsumerDataStandardsAustralia/standards-staging@release/1.30.0...maintenance/629#issuecomment-1956098319

from standards-maintenance.

The following change has been staged for review:

The following line in the Non-normative Examples alongside HTTP Headers should be removed; it is not an Accept header like others in that block and the value appears to be mismatched with the name -

Accept-Encoding: charset=UTF-8

ConsumerDataStandardsAustralia/standards-staging@release/1.30.0...maintenance/629#issuecomment-1968023646

from standards-maintenance.

Standards version 1.30.0 was published on 24/04/2024 incorporating changes from MI18.
This comment was not resolved and has been transferred to issue #637.

from standards-maintenance.