ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41 stars 9 forks source link

Maintenance Iteration 21 Holistic Feedback #663

Open CDR-API-Stream opened 2 months ago

CDR-API-Stream commented 2 months ago

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 commented 2 months ago

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:

perlboy commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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.

image

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 commented 3 weeks ago

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.
nils-work commented 1 week ago

Review impact of #429 - Refer to components in Banking API spec.

nils-work commented 1 week ago

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

This has been staged - https://github.com/ConsumerDataStandardsAustralia/standards-staging/pull/448/files

nils-work commented 1 week ago

Changes have been staged for the two changes above -

https://github.com/ConsumerDataStandardsAustralia/standards-staging/pull/449/files

HemangCDR commented 1 week ago

In FDO table, the retirement statements for Get Generic Plan Detail v2 and Get Energy Account Detail v3 in FDO should have "from" instead of "by" : image

also affects: image image

nils-work commented 1 week ago

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].

This has been staged - https://github.com/ConsumerDataStandardsAustralia/standards-staging/pull/449/commits/10b081da00e628257c0ec710f2f74a0008c4ab98

nils-work commented 1 week ago

In FDO table, the retirement statements for Get Generic Plan Detail v2 and Get Energy Account Detail v3 in FDO should have "from" instead of "by" : image

also affects: image image

This has been staged: https://github.com/ConsumerDataStandardsAustralia/standards-staging/pull/449/commits/6c19efc007ffa8e1e36aae5d3d39f6aefcad30ac

nils-work commented 3 days ago

This documentation fix will also be addressed as part of MI 21 - #675 - PAR/RFC9126 in Normative references appears twice.