Register participant statuses do not detail data holder behaviour when ADR is revoked and SP inactive

[dsbivan]

Description

The participant statuses section of the standards, details the data holder's responsibilities when the ADR and associated software product change statuses. The cascade rules imply that the status of ADR revoked and SP inactive is not a valid state, however, it is not clear whether the Registrar will take the software product from active, to inactive and then removed, or directly to removed.
Without this information, data holder responsibilities documentation may be incomplete.

Area Affected

The participant statuses section of the standards. The scenario for an ADR revoked and SP inactive needs to be documented within the cascade and data holder responsibilities tables.

Change Proposed

The standards need to be updated to align with the Registrar's actions. Further analysis is required to clarify these requirements

[perlboy]

According to the state diagram both are applicable? Not sure what's unclear here:

I think the bigger issue is that the CTS doesn't behave in accordance with this state change diagram so participants are making assumptions when a software product goes missing - notably that it must have gone into a final state which can only be "Removed". This has the net effect that should the Register "glitch" and return an empty but successful Software Product Status list certain installations will proceed to delete all recipients.

[dsbivan]

@perlboy Thank you for highlighting the "glitch" scenario.

I have raised issue #433 to track this separately.

[CDR-API-Stream]

To provide further clarification, the conflict in the documentation is as follows:

1. The cascade rules in participant statuses section infer that a Revoked / Inactive state is invalid

2. The ADR Revoked guidance in the original Register Design calls out that
   a software product would transition from active -> inactive -> removed.

This discrepency needs to be addressed.

[CDR-API-Stream]

It has been confirmed the ADR Status: Revoked and SP Status: Inactive is a valid state and the ADR revoked process as documented in the guidance is correct.

Therefore, the cascade rules and the data holder responsibilities table need to be updated to ensure consistency.

Proposed Changes

1. Update the status mapping table to show valid cascaded states;

Data Recipient Status	Cascaded Software Product Status
Suspended	Inactive
Revoked	Inactive or Removed
Surrendered	Removed

2. Update the Data Holder Responsibilities Table with the following status combinations to reflect an Inactive software product:

[CDR-API-Stream]

Further work has been identified to determine the data holder responsibilities during the revocation process.

This analysis will then look at how the Data Holder Responsibilities table will be updated to align.

[ACCC-CDR]

The ACCC requests this item be removed as a candidate from Maintenance Iteration 10. The ACCC Accreditation and Legal teams are currently validating use cases for status flows and cascading rules applied to legal entities, brands and software products during a revocation event. To avoid further changes to the standards describing these participant status changes it is proposed that this item is moved to a future iteration when the analysis by the Legal and Accreditation teams is complete.

[CDR-API-Stream]

As per the request by @ACCC-CDR, this issue will be deferred from Maintenance Iteration 10 and moved to the backlog to be considered in a future maintenance iteration

[ACCC-CDR]

The ACCC requests this item be removed from Maintenance Iteration 11. The ACCC Accreditation and Legal teams are continuing to validate use cases for status flows and cascading rules applied to legal entities, brands, and software products during a revocation event. To avoid further changes to the standards describing these participant status changes it is proposed that this item is moved to a future iteration when the analysis by the Legal and Accreditation teams is complete.

[perlboy]

So if a Holder observes Data Recipient in Revoked status but a Software Product in Inactive status what do they do?

The Standards right now would classify this as an invalid response from the Register ("the associated Software Product statuses MUST be changed accordingly") and, as per #453 the previous status should be used for an infinite period of time which would mean a Data Recipient in Revoked status could remain Active with a Software Product....

[CDR-API-Stream]

@perlboy, thanks for your comment.

The Standards right now would classify this as an invalid response from the Register ("the associated Software Product statuses MUST be changed accordingly") and, as per #453 the previous status should be used for an infinite period of time which would mean a Data Recipient in Revoked status could remain Active with a Software Product....

We do need to clarify the appropriate behaviour. A revoked status with an active software product was never the intended design and is an unfortunate default.

The consequence of deferring this issue to a future maintenance iteration must be understood and acknowledged. @ACCC-CDR will need to provide the operational context so we can have the confidence that there will be no unintended consequences by setting this as a low priority.

[ACCC-CDR]

The current approach outlined in the Standards for the flow of a Software Product's Status and its alignment with Data Recipient Status is correct. As per the diagram below, the scenario where a Software Product moves from ‘Active’ to ‘Inactive’ to ‘Removed’ caters for the scenario where a Data Recipient status moves to Suspended, then Revoked or Surrendered.

[CDR-API-Stream]

Based on the @ACCC-CDR's comments, a Data Recipient revoked, Software Product Inactive, is not a valid state.
Therefore the original proposed change by the @CDR-API-Stream (as outlined below) is no longer valid

Proposed Changes

1. Update the status mapping table to show valid cascaded states;

Data Recipient Status Cascaded Software Product Status
Suspended Inactive
Revoked Inactive or Removed
Surrendered Removed
2. Update the Data Holder Responsibilities Table with the following status combinations to reflect an Inactive software product:

Updated Proposal

Based on the above analysis, the DSB proposes that the above analysis finds this a non-issue, and no changes to the standards are required.

Given the conflicting information between the archived register design and the current status model, there would be an additional benefit to providing an article outlining how suspension, revocation and surrendering will transition entities through their various statuses.