SSA definition: Deprecation of revocation_uri

[CDR-API-Stream]

This issue has been raised to track CDR Register issue 188 through the standards maintenance process.

Please refer to CDR Register issue 188 for details

[perlboy]

Arguably this attribute is already deprecated as the DSB removed all references to it in the Standards in V1.11.0 documented as:

Obligations which were due more than 3 months since publication of this release of the standards have been removed. They remain accessible in the archived versions of the standards. They have been removed from the main (current) version to reduce ambiguity and keep the standards streamlined

The result is that revocation_uri is now ambiguously defined in the current Standards. As the SSA is a cryptographic assertion from the regulator, a custom implementation for all participants and likely mapped explicitly to metadata required to be stored as part of the Record Keeping Requirements, removing the revocation_uri from the SSA will likely require a Future Dated Obligation for Data Holders to accept and a Future Data Obligation for Data Recipients to perform an in-place DCR.

There is also no real method of advertising such compatibility with Data Holders and the error behaviour of such compatibility is undefined.

[CDR-API-Stream]

This issue is being discussed in Maintenance Iteration 10   @perlboy. Thanks for your comments and they do help shape the scope of what this issue should seek to address.   The revocation_uri no longer has a functional purpose as the associated functionality (data recipient hosted token revocation endpoint) has been obsoleted as of February 1st, 2021.   The SSA structure remains ambiguous and removal of this field will address that. However, we have an opportunity to examine the implications of SSA changes (removal or addition of a field) and set expectations of SSA change management.   Therefore, the following questions should be considered.   When fields get added/removed in an SSA:

1. How should data holders treat SSAs with unexpected present/or missing fields if the associated functionality has been retired?
2. How will data recipients be confident that a data holder has aligned to this change?
3. How much notice should be provided before the CDR Register publishes SSAs with the field change?
4. What are the versioning implications of this change?
   • Should multiple versions/types of an SSA be retrievable for the CDR Register at a given point in time? Or;
   • Should SSAs follow conventions such as the OIDC Discovery endpoint?  

The goals for this work should include:

• Ensure data holders build their solutions anticipating that SSA fields may be introduced and obsoleted and they are to gracefully handle the changes.
• Ensure data recipients are confident updates to registrations align to the changes in associated functionality
• Ensure FDO dates for changed fields are chosen with sufficient lead time.  

The community is invited to contribute to this discussion, to help identify what considerations should be made for SSA changes and how to reduce disruption to the ecosystem.

[CDR-API-Stream]

The DSB recommends the revocation_uri field be deprecated.

Through this work, a default position on how SSA change management has been defined as follows:

SSA Change management will conform to the conventions already laid out in the Consumer Data Standards:

1. New fields get added and removed with >= 6 month lead time.
2. FDO's are defined and pinned to the next logical obligation date
3. Changes are grouped where possible and versioned utilising the x-v versioning pattern
4. Field values, such as authorisation scopes changes (which may need to be controlled by an ADR or the registrar) do NOT impact the SSA version
5. Data holders will return fields if supported, ignore and not return if not supported
6. Data recipients can validate the supported fields in the registration by comparing the Client Registration SSA and Registration Request using JWT fields provided against the Registration result

Each change will be assessed through the consultation process and any deviations to the above conventions can be raised if required.

[CDR-API-Stream]

Impacts raised from #484 to be assessed to ensure breaking changes have not been introduced by the statement:

5. Data holders will return fields if supported, ignore and not return if not supported

[CDR-API-Stream]

The decision was made to not address this issue in Maintenance Iteration 10. DP 245 explores how Data Recipient information should propagate between Data Recipient Software Products, Data Holder Brands, and the CDR Register

The revocation_uri no longer has a functional purpose as the associated functionality (data recipient hosted token revocation endpoint) has been obsoleted as of 1 February 2021.

However, it has been identified there is a risk of interoperability issues with data holders if the deprecation of the revocation_uri change was to proceed.

Currently, data holders don’t have a mechanism to explicitly identify the version of an SSA presented to them. Some data holders may be using strict validation on SSAs and therefore expect the revocation_uri to be present, regardless of its lack of functionality.

Whilst versioning of the CDR Register API was consulted on, this dealt with the interoperability of the ADR and CDR Register only. It did not address the version negotiation and interoperability of the ADR communicating updated registration information to data holders.

Deferring this change request addresses the following:

1. Reduces effort for the ACCC's implementation of the CDR Register
2. Reduces operational burden for the ACCC coordinating releases of CDR Register endpoints and data holder support without a formal transition process
3. Reduces operational burden for the ACCC dealing with incidents caused by data holders rejecting new SSA versions due to strict validation
4. Reduces the risk of SSA validation requirements conflicting with any decisions made through DP 245.
5. Removes the risk of breaking interoperability of data recipients communicating with data holders.

Given there is no functional impact to data holders and data recipients, and the reduced development impact to the ACCC, it is logical to defer this issue until conventions on how SSA version management is to occur, via the Decision Proposal process.

[CDR-API-Stream]

Please refer to Decision 237 for further details.