search

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

Normative References Needs Update #384

Closed spikejump closed 7 months ago

spikejump commented 3 years ago

Description

The latest CDS spec provides links to FAPI-R and FAPI-RW that are Final versions. But the Version marked in CDS is "draft-06".

In addition, the link to PAR in CDS is to draft-01. However, the reference link from FAPI-RW (Part 2) points to https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par which is at draft-08.

Area Affected

When upstream specifications are incorrectly referenced implementation support for the correct version of the spec gets very challenging.

Change Proposed

Please update the standard so that the linked specification are consistent with each other. Specifically,

Thanks

CDR-API-Stream commented 3 years ago

Thanks @spikejump, we have a Future Plan item to address this along with all other normative references. You can see it here: https://github.com/ConsumerDataStandardsAustralia/future-plan/issues/34

The review is being conducted against CDS baseline v1.9.0 references. The analysis is available here (work in progress): https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/tree/master/reviews

spikejump commented 3 years ago

Thanks @CDR-API-Stream Will keep an eye out on this coming update.

CDR-API-Stream commented 2 years ago

Hi @spikejump can you confirm if this issue is still relevant with the release of v1.15.0 of the standards?

perlboy commented 2 years ago

Based on the review doc:

On the basis of the above question to @spikejump, I'd suggest that the original change request is still relevant because the DSB didn't action its recommended changes and the changes recommended appear to be incorrect anyway.

Finally would suggest the DSB review the IETF guidance on the definition of "updates". While newer guides have removed explicit statements there has been memos on it and still sufficient support for the previous definition:

image

spikejump commented 2 years ago

@CDR-API-Stream In the latest version of the CDS spec, it seems PAR is still referencing a draft version. As @perlboy pointed out PAR is now a RFC.

In addition, we note there are still references to FAPI-R-Draft which relates to x-fapi-auth-date. Suggest FAPI-R-Draft can be removed and just use FAPI-1.0-Baseline? Similarly, there are still many references to FAPI-RW-Draft. May be where it make sense they can be updated to reference FAPI-1.0-Advanced?

CDR-API-Stream commented 2 years ago

Hi @spikejump, this is intentional. There is a transition of the data standards across obligation dates. As such, [PAR] continues to reference the original version. As @perlboy noted we now also reference [RFC9126]. This is the same for FAPI references where we have explicitly delineated [FAPI-1.0-Baseline] and [FAPI-1.0-Advanced] for the final versions of these profiles vs [FAPI-R-Draft] and [FAPI-RW-Draft] for the draft version.

Over time as obligation dates retire the legacy specifications these can be removed with the intention that [PAR] then reference [RFC9126] and we only have the final Baseline and Advanced references for FAPI.

CDR-API-Stream commented 2 years ago

Hi @perlboy, @spikejump's change request was in relation to PAR and FAPI references. These have been actioned.

  • RFC8174 was recommended to add as an informative reference but was not nor would it being informative be appropriate as it would not be technically binding. BCP14 is probably a better way of communicating appropriate use of words and capitalisation as RFC8174 does not replace RFC2119 but essentially adds supplemental statements to it and BCP14 wraps both these up in an IETF aligned way.

Regarding the update of Requirements Level RFCs, thanks for the feedback. Changes to the specifications to accomodate these will be planned however the uplift of FAPI 1.0 was deemed the priority. We will raise a separate change request to address this.

  • RFC8996 was documented as the replacement for RFC7662 but this did not take place and would have been wrong if it had been anyway. RFC8996 is a TLS related document which "updates" RFC7662 in relation to the TLS statements in RFC7662. It is not a replacement.

Thanks again for the feedback. This will be reviewed and incorporated into a separate change request.

On the basis of the above question to @spikejump, I'd suggest that the original change request is still relevant because the DSB didn't action its recommended changes and the changes recommended appear to be incorrect anyway.

As noted above, the original request to address PAR and FAPI references has been actioned. Separate change requests will be raised to address the other two changes you identify.

Finally would suggest the DSB review the IETF guidance on the definition of "updates". While newer guides have removed explicit statements there has been memos on it and still sufficient support for the previous definition:

Noted with thanks.

spikejump commented 2 years ago

@CDR-API-Stream Thanks for the update.

CDR-API-Stream commented 2 years ago

It was indicated in the above comment that a change request would be raised separately to address [RFC8996] as an update to [RFC7662] for TLS version support. This change request will not be raised.

The Data Standards specifically state TLS version 1.2 and greater must be supported in conjunction with FAPI 1.0 Baseline section 7.1. TLS and DNSSEC considerations obviates the need because it includes a requirement that TLS version 1.2 or later must be used:

  1. TLS version 1.2 or later shall be used for all communications.

This provides suitable cover for addressing TLS version support.

nils-work commented 8 months ago

Hi @spikejump

As detailed in a previous comment, it appears that the changes proposed in this issue were resolved over time through the FAPI 1.0 Migration phases.

If there are no further comments or changes to the Data Standards expected from this issue, it will be closed on 23 February 2024.

Thanks