Linted all MD files, enabled MD linter for each commit

solution_architecture.md

@@ -11,6 +11,7 @@ We assume a close association of a mobile phone and its user and, thus, equate t
 ![Corona-Warn-App Components](images/solution_architecture/CWA_Components.png "Corona-Warn-App Components")
 
 ## TABLE OF CONTENTS
+
 1. [INTRODUCTION](#introduction)
    1. [Retrieval of lab results and verification process](#retrieval-of-lab-results-and-verification-process)
    2. [Upload schedule for Diagnosis Keys](#upload-schedule-for-diagnosis-keys)
@@ -26,7 +27,6 @@ We assume a close association of a mobile phone and its user and, thus, equate t
 5. [CROSS-BORDER INTEROPERABILITY](#cross-border-interoperability)
 6. [LIMITATIONS](#limitations)
 
-
 ## INTRODUCTION
 
 To reduce the spread of [COVID-19](https://www.ecdc.europa.eu/en/covid-19-pandemic), it is necessary to inform people about their close proximity to positively tested individuals. So far, health departments and affected individuals have identified possibly infected individuals in personal conversations based on each individuals' memory. This has led to a high number of unknown connections, e.g. when using public transport.
@@ -42,6 +42,7 @@ Once the keys and the exposure detection configuration have been downloaded, the
 It is important to note that the persons that have been exposed to a positively tested individual 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 mobile phone and is not shared.
 
 The Corona-Warn-App pursues two objectives:
+
 1. It supports individuals in finding out whether they have been exposed to a person that has later been tested positively.
 2. It receives the result of a SARS-CoV-2 test on a user's mobile phone through an online system. This helps reduce the time until necessary precautions, e.g. a contact reduction and testing, can be taken.
 
@@ -52,6 +53,7 @@ They only have to confirm in the app and for the Exposure Notification Framework
 
 Reporting positive tests to the Corona-Warn-App is crucial for informing others about a relevant exposure and potential infection. However, to prevent misuse, a verification is required before diagnosis keys can be uploaded.
 There are two ways for receiving this verification:
+
 1. Using 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). With this integration, the positive test result is already verified and the diagnosis keys can be uploaded right after the users have given their consent.
 2. Providing a human-readable token, e.g. a number or a combination of words, as verification to the app. This token is called teleTAN (see Figure 2, Step 4b).
 
@@ -64,19 +66,19 @@ This preexisting process for the processing of lab results includes that the doc
 The flow for using the app is as follows, referencing the steps from *Figure 2*:
 
 - **Step 1:** Users of the Corona-Warn-App (i.e. broadcasting and collecting RPIs)
-	- (1) When a test is conducted, they receive an information flyer with a custom QR code. The code is either created on-site or is already available as a stack of pre-printed QR codes. The QR code contains a globally unique identifier (GUID).
-	- (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 mobile 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 mobile phone  (*Figure 3*, step 4).
+  - (1) When a test is conducted, they receive an information flyer with a custom QR code. The code is either created on-site or is already available as a stack of pre-printed QR codes. The QR code contains a globally unique identifier (GUID).
+  - (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 mobile 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 mobile 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 other barcodes (lab ID, sample IDs).
 - **Step 3:** As soon as the test result is available meaning 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 mobile 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 that information is available. The result themselves as well as recommendations for further actions are only displayed after the user has opened the app (see the scoping document for more details).
 - If the test returns 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 the Verification Server does not persist the test result, it is fetched from the Test Result Server once more (*Figure 3*, steps 10-11).
 The TAN is used as authorization in the HTTP header of the POST request for upload of the diagnosis keys of 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.
+  - 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.
 
 ![Figure 3: Data flow for the verification process](images/solution_architecture/figure_3.svg "Figure 3: Data flow for the verification process")
 
@@ -107,17 +109,18 @@ As of now, two uploads are required from the same mobile phone (past diagnosis k
 ![Figure 6: Actors in the system, including external parties (blue components to be open-sourced)](images/solution_architecture/figure_6.svg "Figure 6: Actors in the system, including external parties (blue components to be open-sourced)")
 
 The Corona-Warn-App Server needs to fulfill the following tasks:
+
 - Accept upload requests from clients
-	- Verify association with a positive test through the Verification Server and the associated workflow as explained in the “Retrieval of Lab Results and Verification Process” section and shown in the center of the left side of *Figure 6*.
-	- Accept uploaded diagnosis keys and store them (optional) together with the corresponding transmission risk level parameter (integer value of 1-8) into the database. Note that the transport of metadata (e.g. IP) of the incoming connections for the upload of diagnosis keys is removed in a dedicated actor, labeled “Transport Metadata Removal” in *Figure 6*.
+  - Verify association with a positive test through the Verification Server and the associated workflow as explained in the “Retrieval of Lab Results and Verification Process” section and shown in the center of the left side of *Figure 6*.
+  - Accept uploaded diagnosis keys and store them (optional) together with the corresponding transmission risk level parameter (integer value of 1-8) into the database. Note that the transport of metadata (e.g. IP) of the incoming connections for the upload of diagnosis keys is removed in a dedicated actor, labeled “Transport Metadata Removal” in *Figure 6*.
 - Provide [configuration parameters](#data-format) to the mobile applications
-	- Threshold values for [attenuation buckets](#attenuation-buckets)
-	- Risk scores for defined values
-	- Threshold values for risk categories and alerts
+  - Threshold values for [attenuation buckets](#attenuation-buckets)
+  - Risk scores for defined values
+  - Threshold values for risk categories and alerts
 - On a regular schedule (e.g. hourly)
-	- Assemble diagnosis keys into chunks for a given time period
-	- Store chunks as static files (in protocol buffers, compatible with the format specified by Apple and Google)
-	- Transfer files to a storage service as shown at the bottom of *Figure 6* which acts as a source for the Content Delivery Network (CDN)
+  - Assemble diagnosis keys into chunks for a given time period
+  - Store chunks as static files (in protocol buffers, compatible with the format specified by Apple and Google)
+  - Transfer files to a storage service as shown at the bottom of *Figure 6* which acts as a source for the Content Delivery Network (CDN)
 
 Those tasks are visualized in *Figure 7*. Each of swim lanes (vertical sections of the diagram) on the left side (Phone 1, Phone 2, Phone n) represent one device that has the Corona-Warn-App installed. The user of Phone 1 has taken a SARS-CoV-2 test (which comes back positive later). The users of Phone 2 and Phone n only use the functionality to trace potential exposure.
 The Corona-Warn-App Server represents the outside picture of the individual service working in the back end. For a better understanding, the database has been visualized separately.
@@ -141,13 +144,14 @@ Further information can be found in the dedicated architecture documents for the
 The current base unit for data chunks will be one hour. Data will be encoded in the protocol buffer format as specified by Apple and Google (see *Figure 8*). It is planned that in case a data chunk does not hold any or too few diagnosis keys, the chunk generation will be skipped.
 
 The server will make the following information available through a RESTful interface:
+
 - Available items through index endpoints (not all implemented in first iteration)
 - Newly-added Diagnosis Keys (Temporary Exposure Keys) for the time frame
 - Configuration parameters
-	- 32 parameters for configuring the risk score of the Apple/Google Exposure Notification Framework
-	- [Attenuation bucket](#attenuation-buckets) thresholds
-	- Risk score threshold to issue a warning
-	- Risk score ranges for individual risk levels
+  - 32 parameters for configuring the risk score of the Apple/Google Exposure Notification Framework
+  - [Attenuation bucket](#attenuation-buckets) thresholds
+  - Risk score threshold to issue a warning
+  - Risk score ranges for individual risk levels
 
 Return data needs to be signed and will contain a timestamp (please refer to protocol buffer files for further information). Using index endpoints will not increase the number of requests, as they can be handled within a single HTTP session. In case the hourly endpoint does not hold diagnosis keys for the selected hour, the mobile application does not need to download it. If, on the other hand multiple files need to be downloaded (e.g. because the client was switched off overnight), they can be handled in a single session as well.
 
@@ -171,7 +175,7 @@ The data on all involved servers is only retained as long as required. Diagnosis
 
 The functional scope of the mobile applications (apps) is defined in the corresponding [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md). The apps are developed natively for Apple’s iOS and Google’s Android operating systems. They make use of the respective interfaces for the exposure notification, i.e. broadcasting and scanning for Bluetooth advertisement packages, see *Figure 9*.
 
-For Apple devices (starting from _<to be determined>_), an OS version of at least 13.5 will be required for the system to work, as the framework is integrated into the operating system.
+For Apple devices an OS version of at least 13.5 will be required for the system to work, as the framework is integrated into the operating system.
 
 For Android devices, the features will be integrated into the [Google Play Services](https://9to5google.com/2020/04/13/android-contact-tracing-google-play-services/), which means that only this specific application needs to be updated for it to work. Devices starting with Android 6.0 (API version 23) and integrated BLE chips will be [supported](https://developers.google.com/android/exposure-notifications/exposure-notifications-api#architecture).
 
@@ -186,16 +190,18 @@ The encapsulation especially applies to the part where matches are calculated, a
 ![Figure 11: Key flow from the receiving perspective (as described in the specification by Apple/Google)](images/solution_architecture/figure_11.svg "Figure 11: Key flow from the receiving perspective (as described in the specification by Apple/Google)")
 
 [Information provided from the framework API to the app per exposure](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-FrameworkDocumentationv1.2.pdf):
--	**Attenuation value** (Reported Transmit Power - Measured RSSI)
--	**Attenuation “buckets”**, i.e. times spent within certain attenuation ranges (see below)
--	**Date** when the exposure occurred (with reduced precision, i.e. one day)
--	**Duration** of the exposure (<5/5/10/15/20/25/30/>30 minutes)
--	**Transmission risk level** associated with diagnosis key of other person (downloaded from server, together with diagnosis key)
--	**Total Risk Score** calculated exposure risk level (with a range from 0-4096) according to the defined parameters
+
+- **Attenuation value** (Reported Transmit Power - Measured RSSI)
+- **Attenuation “buckets”**, i.e. times spent within certain attenuation ranges (see below)
+- **Date** when the exposure occurred (with reduced precision, i.e. one day)
+- **Duration** of the exposure (<5/5/10/15/20/25/30/>30 minutes)
+- **Transmission risk level** associated with diagnosis key of other person (downloaded from server, together with diagnosis key)
+- **Total Risk Score** calculated exposure risk level (with a range from 0-4096) according to the defined parameters
 
 ### Attenuation Buckets
 
 Both, Apple and Google allow to define a low and a high threshold for the attenuation, forming three individual buckets:
+
 - Attenuation < low threshold
 - Low threshold <= attenuation < high threshold
 - High threshold <= attenuation