From 227925416abe431e8dcec94bc4d3ab87ff16f974 Mon Sep 17 00:00:00 2001 From: Thomas Klingbeil Date: Wed, 3 Jun 2020 10:45:55 +0200 Subject: [PATCH] Clarify verification process (fetch of test result) * As the verification server does not store the test result, it needs to be re-fetched from the Test Result Server. This was already represented in Figure 7. --- images/solution_architecture/figure_3.svg | 2 +- solution_architecture.md | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/images/solution_architecture/figure_3.svg b/images/solution_architecture/figure_3.svg index fb786d2..29a038a 100644 --- a/images/solution_architecture/figure_3.svg +++ b/images/solution_architecture/figure_3.svg @@ -1,3 +1,3 @@ - Produced by OmniGraffle 6.6.2 2020-06-01 07:56:59 +0000Figure 3Ebene 1Test Result ServerVerification ServerPhone with Corona-Warn-AppCorona-Warn-AppServerTANTANDiagnosis KeysTANvalid/not validPOST /testresultPOST /verifyPrinted QRCodeGUIDScan QR codevia camerahash(GUID)12568121315POST/tanResult911Registration Token4hash(GUID)Test result7InitialSetupPollingTANRetrieval10Generate TAN3Generate Registration TokenStore diagnosiskeys16Registration TokenRegistration Tokenhash(GUID)Test resulthash(GUID)hash(Registration Token)hash(TAN)Registration TokenDiagnosis KeysValidate TAN14Figure 3: Data flow for the verification processLaboratory Information System (LIS)hash(GUID)Test resultAPOST/registrationTokenPOST /lab/resultsPOST /app/result + Produced by OmniGraffle 6.6.2 2020-06-03 08:39:35 +0000Figure 3Ebene 1Test Result ServerVerification ServerPhone with Corona-Warn-AppCorona-Warn-AppServerTANTANDiagnosis KeysTANvalid/not validPOST /testresultPOST /verifyPrinted QRCodeGUIDScan QR codevia camerahash(GUID)12568141517POST/tanResult913Registration Token4hash(GUID)Test result7InitialSetupPollingTANRetrieval12Generate TAN3Generate Registration TokenStore diagnosiskeys18Registration TokenRegistration Tokenhash(GUID)Test resulthash(GUID)hash(Registration Token)hash(TAN)Registration TokenDiagnosis KeysValidate TAN16Figure 3: Data flow for the verification processLaboratory Information System (LIS)hash(GUID)Test resultAPOST/registrationTokenPOST /lab/resultsPOST /app/result1011 diff --git a/solution_architecture.md b/solution_architecture.md index dbde8e0..e8dfbb9 100644 --- a/solution_architecture.md +++ b/solution_architecture.md @@ -67,10 +67,10 @@ The flow for using the app is as follows, referencing the steps from *Figure 2*: - **Step 2:** The samples are transported to the lab (together with a “Probenbegleitschein”, which has a machine-readable QR code on it, as well as multiple other barcodes (lab ID, sample IDs). - **Step 3:** As soon as the test result is available (i.e. the samples have been processed), the software running locally in the lab (lab client) transmits the test result to the Laboratory Information System, together with the GUID from the QR code. The Laboratory Information System hashes the GUID and posts it together with the test result to the Test Result Server through a REST interface (*Figure 3*, step A), which in turn makes it available to the verification server. - **Step 4a:** After signing up for notifications in step 1, the user’s phone regularly checks the Verification Server for available test results (polling, figure 3, steps 5-8). This way, no external push servers need to be used. If results are available, the user is informed about the availability of information and only after opening the app, the result is displayed, together with recommendations for further actions (see scoping document for more details). -- In case the test returned a positive result, users are asked to upload their keys to allow others to find out that they were exposed. If the users agree, the app retrieves a short-lived token (TAN) from the Verification Server (see also *Figure 3*, steps 9-11). The TAN is uploaded together with the diagnosis keys of up to the last 14 days to the Corona-Warn-App Server (*Figure 3*, step 12). -- The Corona-Warn-App Server uses the TAN to verify the authenticity (*Figure 3*, steps 13-15) of the submission with the Verification Server. - - The TAN is consumed by the Verification Server and becomes invalid (*Figure 3*, step 14) - - If the Corona-Warn-App Server receives a positive confirmation, the uploaded diagnosis keys are stored in the database (*Figure 3*, step 16). +- In case the test returned a positive result, users are asked to upload their keys to allow others to find out that they were exposed. If the users agree, the app retrieves a short-lived token (TAN) from the Verification Server (see also *Figure 3*, steps 9-13). As then Verification Server does not persist the test result, it is fetched from the Test Result Server it is fetched from the Test Result Server once more (*Figure 3*, steps 10-11). The TAN is uploaded together with the diagnosis keys of up to the last 14 days to the Corona-Warn-App Server (*Figure 3*, step 14). +- The Corona-Warn-App Server uses the TAN to verify the authenticity (*Figure 3*, steps 15-17) of the submission with the Verification Server. + - The TAN is consumed by the Verification Server and becomes invalid (*Figure 3*, step 16) + - If the Corona-Warn-App Server receives a positive confirmation, the uploaded diagnosis keys are stored in the database (*Figure 3*, step 18). - The TAN is never persisted on the Corona-Warn-App Server. - In case of a failing request, the device receives corresponding feedback to make the user aware that the data needs to be re-submitted.