1
0
mirror of https://github.com/corona-warn-app/cwa-documentation synced 2024-11-29 12:44:27 +01:00

Update solution architecture document

* Include new test result server in process
* Update figures to represent new component
* Update endpoints in figures 3 and 4
This commit is contained in:
Thomas Klingbeil 2020-05-31 11:23:32 +02:00
parent 19bc22eef7
commit 44abb9cbdf
No known key found for this signature in database
GPG Key ID: C72D93E3E9C2B70D
7 changed files with 8 additions and 8 deletions

File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 33 KiB

After

Width:  |  Height:  |  Size: 33 KiB

File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 45 KiB

After

Width:  |  Height:  |  Size: 46 KiB

File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 33 KiB

After

Width:  |  Height:  |  Size: 38 KiB

File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 34 KiB

After

Width:  |  Height:  |  Size: 35 KiB

File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 51 KiB

After

Width:  |  Height:  |  Size: 52 KiB

File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 40 KiB

View File

@ -65,7 +65,7 @@ The flow for using the app is as follows, referencing the steps from *Figure 2*:
- (2) Optionally, they can scan the QR code with the Corona-Warn-App (*Figure 3*, step 1) if users decide against using the test retrieval functionality of the Corona-Warn-App, they still receive their test results through the regular channels explained before. - (2) Optionally, they can scan the QR code with the Corona-Warn-App (*Figure 3*, step 1) if users decide against using the test retrieval functionality of the Corona-Warn-App, they still receive their test results through the regular channels explained before.
- (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). - (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 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 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 users 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). - **Step 4a:** After signing up for notifications in step 1, the users 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). - 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 Corona-Warn-App Server uses the TAN to verify the authenticity (*Figure 3*, steps 13-15) of the submission with the Verification Server.
@ -161,7 +161,7 @@ Further details of the API are explained in the documentation of the Corona-Warn
### Data retention ### Data retention
The data on the all involved servers will only be retained as long as required. Diagnosis Keys will be removed from Corona-Warn-App Server once they refer to a period more than 14 days ago. TANs on the Verification Server will be removed as soon as they have been used. The hashed GUID on the Verification Server needs to be retained as long as the GUID can be used to retrieve test results from the Laboratory Information System, as otherwise a second upload privilege (i.e. a registration token) could be fetched with the same GUID. The data on the all involved servers will only be retained as long as required. Diagnosis Keys will be removed from Corona-Warn-App Server once they refer to a period more than 14 days ago. TANs on the Verification Server will be removed as soon as they have been used. The hashed GUID on the Verification Server needs to be retained as long as the GUID can be used to retrieve test results from the test result server, as otherwise a second upload privilege (i.e. a registration token) could be fetched with the same GUID.
## MOBILE APPLICATIONS ## MOBILE APPLICATIONS