Maintenance Iteration 21 Holistic Feedback

[CDR-API-Stream]

This change request has been created to simplify the raising of minor changes, such as text corrections or description clarifications, that are not really material to the standards but do have a real impact on readability and clarity.

Please raise any such suggestions that you would like included in Maintenance Iteration 21 on this issue and the DSB will review them. If a suggestion is a material change a dedicated change request will be raised.

[nils-work]

The Energy specs don't have servers[...].url detail specified currently. This is inconsistent with other specs and means the 'Code samples' examples don't display a 'Host' property and a full URL.

The Energy Data Holder spec could be updated with https://data.holder.com.au/cds-au/v1 like other specs, or all specs could be updated to something such as https://dh.example.com/cds-au/v1

The Energy Secondary Data Holder spec could be updated with the actual hosts (including AEMO and MarketNet pre-prod and prod options) or a generic default such as https://sdh.example.com/cds-au/v1.

References to recipient.com.au could also be updated to adr.example.com where applicable.

Differences between TLS and MTLS endpoints could also be indicated, for example:

• https://tls.dh.example.com/cds-au/v1
• https://mtls.dh.example.com/cds-au/v1

[perlboy]

In https://consumerdatastandardsaustralia.github.io/standards/#cdr-dynamic-client-registration-api_schemas_tocSclientregistration it states:

Predefined error code as described in section 3.3 OIDC Dynamic Client Registration

But the overriding specification for DCR is RFC7591 and the CTS is now enforcing these error codes explicitly, which is noteworthy because 3.3 OIDC Dynamic Client Registration explicitly states "Other error codes MAY also be used."

[nils-work]

The Reporting Requirements section contains details that are out of sync with the latest Get Metrics v5 requirements.

The text could be updated from:

The mechanism for reporting will be via the CDR Administration Endpoints.

To:

The mechanism for reporting will be via the Get Metrics endpoint.

and the following text and the list could be removed as it appears to be redundant:

The following information is to be reported:

• Availability for current month
• Availability for each of the previous twelve months
• ...

[perlboy]

The Reporting Requirements section contains details that are out of sync with the latest Get Metrics v5 requirements.

I wonder why it needs to exist at all? The Standards define the Metrics endpoint, the Rules permit ACCC to require it, how is this an NFR?

[nils-work]

In the Holder of Key Mechanism section, the 'section 3' link is broken -

[MTLS] HoK allows issued tokens to be bound to a client certificate as specified in section 3 of [MTLS].

[nils-work]

Hi @perlboy Re:

In https://consumerdatastandardsaustralia.github.io/standards/#cdr-dynamic-client-registration-api_schemas_tocSclientregistration it states:

Predefined error code as described in section 3.3 OIDC Dynamic Client Registration

But the overriding specification for DCR is RFC7591 and the CTS is now enforcing these error codes explicitly, which is noteworthy because 3.3 OIDC Dynamic Client Registration explicitly states "Other error codes MAY also be used."

Are you saying that the CTS only allows the two codes stated in Client Registration Error Response (invalid_redirect_uri, invalid_client_metadata) and not the four stated in RFC7591 and the Standards, or that it doesn't allow "Other error codes" outside those four?

[perlboy]

@nils-work that is correct, CTS will fail if a deliberately broken DCR does not return one of these errors. In the scenario we found our system was returning (right or wrong, we've now aligned to CTS), server_error because it was an unexpected condition that a DCR would be received where it would be a signed payload with a valid ACCC SSA for a kid that is not present at the JWKS endpoint.

To clarify, the "invalid SSA" the CTS references here is actually the signed POST (not the ACCC SSA) and was well formed and parseable but was signed by an absent kid.

[nils-work]

In the Security Endpoints > CDR Arrangement Revocation End Point section, there appears to be a duplicate line referring to the _cdr_arrangementjwt:

The proposal is to remove the duplicate first bullet and update these lines for clarity -

CDR Arrangement JWT method

The request MUST include the following parameters using the application/x-www-form-urlencoded format in the HTTP request entity-body:

• cdr_arrangement_jwt: A signed JWT that includes the cdr_arrangement_id.
• cdr_arrangement_jwt: A newly signed JWT with the following parameters in accordance with [JWT]:
  • cdr_arrangement_id: The ID of the arrangement that the client wants to revoke.

The cdr_arrangement_jwt SHOULD include all parameters in accordance with Data Holders calling Data Recipients using Self-Signed JWT Client Authentication.

To -

CDR Arrangement JWT method

The request MUST include the following parameter using the application/x-www-form-urlencoded format in the HTTP request entity-body:

• _cdr_arrangementjwt: A newly signed JWT with the following parameters in accordance with [JWT]:
  • _cdr_arrangementid: The ID of the arrangement that the client wants to revoke.
  • This JWT SHOULD also include all parameters in accordance with Data Holders calling Data Recipients using Self-Signed JWT Client Authentication.