Clarification Sought on Regular Polling of Data Holder Information from Register

[spikejump]

There is currently a requirement for ADRs to poll the Register's GetDataHolderBrands endpoint every 6 hours. Can we please get clarification on the expected ADR actions based on the response received?

What kind of changes are ADRs expected to detect and act on in the metadata returned from GetDataHolderBrands?

As documented, the following scenarios may warrant a push notification.

A new Data Holder becomes active A new Accredited Data Recipient software product becomes active A Data Holder has been surrendered from the CDR An Accredited Data Recipient Software Product has been deactivated or removed from the CDR Register

First and third scenarios are relevant to ADRs. For the first, our assumption is ADRs will make a conscious decision to connect to the new DH and would not systematically establish connections simply because a new DH is on the scene.

How frequently will the third scenario happen? When and if it does happen and ADR is not aware but still makes calls to the DH the calls will fail right? In the worst case, the calls go through and customer data was fetched. In such a case, it seems privacy of data is not a concern as the data belonged to the customer in the first place and consent was obtained. The only issue seemed to be data was obtained from a holder that's no longer in the CDR regime, in which case such act is no longer under the CDR rules any more.

Please help to clarify the importance of ADRs fetching Data Holders information every 6-hours and DRs action as a result of the response.

[perlboy]

@spikejump, there are endpoint rotation/change actions to be considered as well right?

On 30 Jan 2020, at 1:37 pm, spikejump notifications@github.com wrote:

 There is currently a requirement for ADRs to poll the Register's GetDataHolderBrands endpoint every 6 hours. Can we please get clarification on the expected ADR actions based on the response received?

What kind of changes are ADRs expected to detect and act on in the metadata returned from GetDataHolderBrands?

As documented, the following scenarios may warrant a push notification.

A new Data Holder becomes active A new Accredited Data Recipient software product becomes active A Data Holder has been surrendered from the CDR An Accredited Data Recipient Software Product has been deactivated or removed from the CDR Register

First and third scenarios are relevant to ADRs. For the first, our assumption is ADRs will make a conscious decision to connect to the new DH and would not systematically establish connections simply because a new DH is on the scene.

How frequently will the third scenario happen? When and if it does happen and ADR is not aware but still makes calls to the DH the calls will fail right? In the worst case, the calls go through and customer data was fetched. In such a case, it seems privacy of data is not a concern as the data belonged to the customer in the first place and consent was obtained. The only issue seemed to be data was obtained from a holder that's no longer in the CDR regime, in which case such act is no longer under the CDR rules any more.

Please help to clarify the importance of ADRs fetching Data Holders information every 6-hours and DRs action as a result of the response.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[spikejump]

@perlboy That is a valid use-case scenario to consider. This is why there is a need for clarification on what changes need to be considered for action.

Specifically, for this use-case, it's difficult to imagine a systematic change on the endpoint in production environment without first validating/regression testing the new endpoints. When to switch will be determined based on many factors. As such it's hard to imagine such change requires a regular 6-hour poll of the Register.

[perlboy]

@perlboy That is a valid use-case scenario to consider. This is why there is a need for clarification on what changes need to be considered for action. Specifically, for this use-case, it's difficult to imagine a systematic change on the endpoint in production environment without first validating/regression testing the new endpoints. When to switch will be determined based on many factors. As such it's hard to imagine such change requires a regular 6-hour poll of the Register.

To be honest I was more focused on change detection versus a specific timeline but, yes, scenario mapping for all of these seems like it would be useful. I guess there's a broader question here around what the "post go-live" management plan for the CDR Ecosystem is. Perhaps those prospective ADR's and Big 4 Data Holders can seek to clarify this at their weekly testing meetings?

Nonetheless for regression of new endpoints, I'm not aware of any published guidance from the ACCC on the provision of a test environment in which to sandbox these, likely regular, operational changes.