Information on 'sc' for dcc partner systems outdated or wrong. Implementation ok? about cwa-quicktest-onboarding HOT 6 OPEN

Internal Tracking ID: EXPOSUREAPP-8122
RAT countdown uses registration time instead of time of test result as starting point

Internal Tracking ID: EXPOSUREAPP-8156
RAT are not shown as invalid when older than 48h

from cwa-quicktest-onboarding.

@mlenkeit
I was not only talking about DCCs, also about conventional RATs. We have now confirmed that users can manipulate validity of RATs when displayed in CWA: https://github.com/corona-warn-app/cwa-app-android/issues/3559#issuecomment-877199316
This will affect also DCCs, when the flow won't be corrected.

from cwa-quicktest-onboarding.

Hi @dmr , in case you could find a fix from your side, could be nice to get a feedback here, so that TSI can reach out more fast to other partners and enhance TSI's backend and documentation accodingly. Thanks in advance - and I like your works ❤️

from cwa-quicktest-onboarding.

@vaubaehn I think that's a misunderstanding. The sc parameter that the document refers to is not the one that is used for the DCC. There's a separate sample collection date on the test result in the Test Result Server that can be set by rapid test providers when they upload the results to the system. Of course, now with the DCC, it should ideally be the same.

from cwa-quicktest-onboarding.

Good morning,
one of the partners fixed their 'sc timestamp' problem already: https://github.com/corona-warn-app/cwa-app-android/issues/3559#issuecomment-877582764. In their case, no 'sc timestamp' was set on their side but was set by test-result-server, when results were transmitted via API-call. This was not a big problem before July 1st, when test results were transmitted in time: the moment when the test result was transmitted was often a good estimation of the time, when sample was collected (approx. 20 minutes difference in average, when there was no delay between reading test result from test by testcenter staff and initiating test result transmission).
But after July 1st, test centers need their users to confirm that the test was taken, which will often be done by clicking on a confirmation link provided by email. When the test result is transmitted to test-result-server via API call after the user clicks on the confirmation link, and the 3rd-party provider does not transmit a 'sc timestamp', it means:

• the average delay between sample collected in reality and 'sc timestamp' increases
• the user can influence the time when he clicks on the confirmation and thus manipulate the time of validity of the test shown in CWA or the validity of the DCC

To solve the problem in a whole (with all partners), more effort and action seems to be necessary. Please find below some suggestions for your internal discussion:

• the test-result-server must not set the 'sc timestamp'
• all test results transmitted by 3rd-parties via API call must be rejected with error when transmitted without 'sc timestamp'
• the quick-test-frontend should enable entry of time when sample was collected
• the quick-test-backend could be enabled to set an 'sc timestamp' when a test result is submitted from quicktest-front-end without 'sc timestamp': timestamp of submission minus 15 minutes as best guess/estimation (15 minutes: time that test usually needs to provide a valid result) - but only, if it's clear the test result comes from quicktest-front-end and sample was just collected (means, it does not apply for 3rd-party-transmission or when lists of results are uploaded).
• TSI would need to adapt and communicate documentation accordingly:
  • 3rd-party providers must provide 'sc timestamp', adaptation on 3rd-party applications may be necessary.
  • 'sc timestamp' should be time when sample is actually collected. If this is not possible for some reason, following estimations could be allowed:
    • timestamp of time when user checks into testcenter (reading QR code or entering personal data into system. NOT: timestamp when taking appointment or time of appointment)
    • timestamp of time when test result is entered into the system minus 15 minutes (time tests needs to provide valid result)
• there may be a transition period of 2 weeks after publishing new documentation/informing 3rd parties until the submission of 'sc timestamp' gets mandatory
• TSI would need to verifiy during "Abnahmetest", that 3rd-party-provider is actually transmitting an accurate 'sc' timestamp.

I hope I could help a bit. Now it's on you, thanks in advance and have a nice day!

from cwa-quicktest-onboarding.

Will someone andres this issue soon?

from cwa-quicktest-onboarding.