Information on 'sc' for dcc partner systems outdated or wrong. Implementation ok?

[vaubaehn]

Describe the bug

Information 'Anbindung Partnersysteme mit DCC'

The wiki states: The provision of a timestamp 'sc' (sample collected) is optional: https://github.com/corona-warn-app/cwa-quicktest-onboarding/wiki/Anbindung-an-CWA-mit-Verwendung-von-DCCs#upload-des-testergebnisses

Expected behaviour

The wiki must state: The provision of a timestamp 'sc' is REQUIRED.

Steps to reproduce the issue

Read wiki.

Possible Fix

Check if only the documentation is outdated/wrong, or if there is a problem with the implementation in quick-test-frontend, quick-test-backend, test-result-server and connection of 3rd-party-software.

Additional context

To issue a valid test DCC, a timestamp for the collected sample is required: https://github.com/ehn-dcc-development/ehn-dcc-schema/blob/a603410d760fefc9073931c8c807759d9714c136/DCC.combined-schema.json#L212-#L220

Additionally, CWA (test result with or without DCC), other wallet apps and verifier apps (DCC) heavily rely on a correct sc timestamp. If the 'sc' timestamp is not correct, it leads to problems, see https://github.com/corona-warn-app/cwa-app-android/issues/3559 https://github.com/corona-warn-app/cwa-documentation/issues/630

Also it looks like, that partner systems that create QR codes (or deeplinks) for CWA at the time of test registration with an included timestamp of the time of test registration (and not the time of sample collected, or at least time of testing appointment) deliver a wrong timestamp by default to CWA, what potentially may be used for fraud (see links above). Is there a way to prevent this?

Dear @mschulte-tsi and @ascheibal , could you kindly address these points (adapt documentation for partners, check implementations) and contact CWA team on how to handle 'sc' issues that pop up on CWA client side but seem to be caused server/3rd-party-side? Thank you in advance.

/cc @mlenkeit @thomasaugsten

[dsarkar]

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

[mlenkeit]

@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.

[vaubaehn]

@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.

[vaubaehn]

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 ❤️

[vaubaehn]

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!

[Ein-Tim]

Will someone andres this issue soon?