From 5af91deaea4b755e770eac29a1ef2faa106271f8 Mon Sep 17 00:00:00 2001 From: Marco Pashkov Date: Tue, 19 May 2020 22:16:17 -0700 Subject: [PATCH 1/4] Clarification and contextual link to the diagrams `main approaches` implies that the app will eventually only use either option 1 or option 2. However, I am guessing the author meant that those are both options to be used in the production app. I further highlighted the two options visually and removed clutter. --- solution_architecture.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/solution_architecture.md b/solution_architecture.md index 0055082..58f7288 100644 --- a/solution_architecture.md +++ b/solution_architecture.md @@ -46,7 +46,9 @@ The app pursues two objectives: First, supporting individuals in finding out whe ### Retrieval of lab results and verification process Reporting positive tests to the app is crucial for others to get informed about a relevant exposure and potential infection. On the other hand, a verification before the uploaded of diagnosis keys is required in order to prevent misuse. -There are two main approaches for this verification: The first option is to use the integrated functionality of the Corona-Warn-App to retrieve the results of a SARS-CoV-2 test. Through this integration, the positive test result is already verified and the diagnosis keys can be uploaded right after users have given their consent. The second option is to receive a human-readable token (e.g. a number or a combination of words) and provide this as verification to the app. This token is called teleTAN. +There are two ways for receiving this verification: +1. Use of the integrated functionality of the Corona-Warn-App to retrieve the results of a SARS-CoV-2 test from a verification server (see Figure 4a). Through this integration, the positive test result is already verified and the diagnosis keys can be uploaded right after users have given their consent. +2. Use of a human-readable token (e.g. a number or a combination of words) and provide this as verification to the app. This token is called teleTAN (see Figure 4b). ![Figure 2: Interaction flow for verification process](images/solution_architecture/figure_2.svg "Figure 2: Interaction flow for verification process") From 0b5b99107e49f709713964f7a8ae035bc305cced Mon Sep 17 00:00:00 2001 From: Marco Pashkov Date: Tue, 19 May 2020 22:19:16 -0700 Subject: [PATCH 2/4] correction of the figures --- solution_architecture.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/solution_architecture.md b/solution_architecture.md index 58f7288..a8fa584 100644 --- a/solution_architecture.md +++ b/solution_architecture.md @@ -47,8 +47,8 @@ The app pursues two objectives: First, supporting individuals in finding out whe Reporting positive tests to the app is crucial for others to get informed about a relevant exposure and potential infection. On the other hand, a verification before the uploaded of diagnosis keys is required in order to prevent misuse. There are two ways for receiving this verification: -1. Use of the integrated functionality of the Corona-Warn-App to retrieve the results of a SARS-CoV-2 test from a verification server (see Figure 4a). Through this integration, the positive test result is already verified and the diagnosis keys can be uploaded right after users have given their consent. -2. Use of a human-readable token (e.g. a number or a combination of words) and provide this as verification to the app. This token is called teleTAN (see Figure 4b). +1. Use of the integrated functionality of the Corona-Warn-App to retrieve the results of a SARS-CoV-2 test from a verification server (see Figure 2, Step 4a). Through this integration, the positive test result is already verified and the diagnosis keys can be uploaded right after users have given their consent. +2. Use of a human-readable token (e.g. a number or a combination of words) and provide this as verification to the app. This token is called teleTAN (see Figure 2, Step 4b). ![Figure 2: Interaction flow for verification process](images/solution_architecture/figure_2.svg "Figure 2: Interaction flow for verification process") From b29195053b66aecc9b1b79c4087bc2606070e390 Mon Sep 17 00:00:00 2001 From: Marco Pashkov Date: Tue, 19 May 2020 23:00:27 -0700 Subject: [PATCH 3/4] correction and simplification --- solution_architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/solution_architecture.md b/solution_architecture.md index 0055082..2f08968 100644 --- a/solution_architecture.md +++ b/solution_architecture.md @@ -62,7 +62,7 @@ The flow for using the app is as follows, referencing the steps from *Figure 2*: - (3) When the code is scanned, a web service call (REST) is placed against the Verification Server (*Figure 3*, step 2), linking the phone with the data from the QR code through a registration token, which is generated on the server (*Figure 3*, step 3) and stored on the phone (*Figure 3*, step 4). - **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 the test result. It is made available to the Verification Server through a REST interface. -- **Step 4a:** After signing up for notifications in step 1, the user’s phone regularly check on the Verification Server whether test results are available (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 recommandations for further actions (see scoping document for more details). +- **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 recommandations 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 6-8). 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) From 97840b86bd81549389f78d203829204bb6007d3d Mon Sep 17 00:00:00 2001 From: Thomas Klingbeil Date: Wed, 20 May 2020 09:16:31 +0200 Subject: [PATCH 4/4] clarify that upload only happens with user consent fixes #105 --- solution_architecture.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/solution_architecture.md b/solution_architecture.md index 0055082..6c551e5 100644 --- a/solution_architecture.md +++ b/solution_architecture.md @@ -41,7 +41,9 @@ Once the keys and the exposure detection configuration have been downloaded, the It is important to notice at this point, that the people that have been exposed to a positively tested person are **not informed by a central instance**, but the risk of an exposure is calculated locally on their phones. The information about the exposure remains on the user’s phone and is not shared. -The app pursues two objectives: First, supporting individuals in finding out whether they have been exposed to a person that has later been tested positively, and second receiving results of a SARS-CoV-2 test on their phone through an online system. This helps to reduce the period until necessary precautions (e.g. contact reduction and testing) can be taken. In order to prevent misuse, users need to verify that they have been tested positively before being able to upload their keys. Through this integrated approach, the verification needed for the upload of the diagnosis keys does not require any action from the users. They only have to confirm to the app and the Exposure Notification Framework that they are willing to share their diagnosis keys. Manual verification is also possible, if the lab that performed the testing does not support the direct electronic transmission of test results to the users' phone or if users have decided against the electronic transmission of their test results. +The app pursues two objectives: First, supporting individuals in finding out whether they have been exposed to a person that has later been tested positively, and second receiving results of a SARS-CoV-2 test on their phone through an online system. This helps to reduce the period until necessary precautions (e.g. contact reduction and testing) can be taken. +In order to prevent misuse, users need to provide proof that they have been tested positive before being able to upload their keys. Through this integrated approach, the verification needed for the upload of the diagnosis keys does not require any further action from the users. +They only have to confirm to the app and the Exposure Notification Framework that they are willing to share their diagnosis keys. Manual verification is also possible, if the lab that performed the testing does not support the direct electronic transmission of test results to the users' phone or if users have decided against the electronic transmission of their test results. ### Retrieval of lab results and verification process