# Event Registration - Summary

Presence Tracing - in CWA also referred to as _Event Registration_ - aims at notifying people of a potential SARS-CoV-2 infection if they have been to the same venue at a similar time than a positively tested individual. It addresses the potential of airborne transmission in spaces with poor ventilation despite maintaining physical distance. As such, it complements BLE-based proximity tracing with the Exposure Notification Framework.

CWA proposes a fully-automated decentral solution for Presence Tracing which works independent of local health authorities and host of the event. It integrates into the existing verification processes of CWA to issue warnings. The solution prioritizes the speed of issuing warnings over their accuracy. A higher degree of accuracy would require manual assessment by local health authorities and the respective resources to do so and is currently not on scope.

In summary, the proposed solution allows a _host_ to create a venue through CWA. All necessary signed data about the venue is encoded in a QR code which can be presented on a mobile device or printed out, for example to be posted at the entrance of the venue. An _attendee_ can check in to the venue by scanning the QR code. Check-ins are stored locally on the mobile device and deleted automatically after two weeks. 

When an attendee tests positive for SARS-CoV-2, they can upload their check-ins along with their Diagnosis Keys to the CWA Server. The CWA Server publishes the relevant check-ins on CDN as _warnings_. Clients regularly download these warnings and match them against the local check-ins on the mobile device. If there is a match and the time an attendee spent at a venue overlaps with a warning for a sufficiently long time, the attendee receives a warning in CWA similar to how warnings are issued for BLE-based exposures.

![TAM Diagram for Event Registration](./../../diagrams/png/evreg-tam-block.png)

## QR Code Structure

The QR code of a venue contains all required attributes for Presence Tracing, so that no server communication is necessary when an attendee checks in to a venue

The data structure is described by the following Protocol Buffer message `TraceLocation`:

```protobuf
message TraceLocation {
  // uuid
  string guid = 1;
  uint32 version = 2;
  TraceLocationType type = 3;
  // max. 150 characters
  string description = 4;
  // max. 150 characters
  string address = 5;
  // UNIX timestamp (in seconds)
  uint64 startTimestamp = 6;
  // UNIX timestamp (in seconds)
  uint64 endTimestamp = 7;
  uint32 defaultCheckInLengthInMinutes = 8;
}

enum TraceLocationType {
  LOCATION_TYPE_UNSPECIFIED = 0;
  LOCATION_TYPE_PERMANENT_OTHER = 1;
  LOCATION_TYPE_TEMPORARY_OTHER = 2;

  LOCATION_TYPE_PERMANENT_RETAIL = 3;
  LOCATION_TYPE_PERMANENT_FOOD_SERVICE = 4;
  LOCATION_TYPE_PERMANENT_CRAFT = 5;
  LOCATION_TYPE_PERMANENT_WORKPLACE = 6;
  LOCATION_TYPE_PERMANENT_EDUCATIONAL_INSTITUTION = 7;
  LOCATION_TYPE_PERMANENT_PUBLIC_BUILDING = 8;

  LOCATION_TYPE_TEMPORARY_CULTURAL_EVENT = 9;
  LOCATION_TYPE_TEMPORARY_CLUB_ACTIVITY = 10;
  LOCATION_TYPE_TEMPORARY_PRIVATE_EVENT = 11;
  LOCATION_TYPE_TEMPORARY_WORSHIP_SERVICE = 12;
}
```

The `guid` attribute is generated by the CWA Server to ensure uniqueness across all CWA QR codes. The data structure is signed by the CWA Server with its private key to prevent tampering of the QR code or identity theft of the GUID of a venue.

The combination of signature and TraceLocation is represented in the following Protocol Buffer message `SignedTraceLocation`:

```protobuf
message SignedTraceLocation {
  // byte representation of a TraceLocation
  bytes location = 1;
  // byte representation of the signature of the TraceLocation
  bytes signature = 2;
}
```

A SignedTraceLocation is base32-encoded and included in a URL. The URL is the content of the QR code and structures as follows:

```shell
HTTPS://E.CORONAWARN.APP/C1/<SIGNED_TRACE_LOCATION_BASE32>

# example:
HTTPS://E.CORONAWARN.APP/C1/BIPEY33...
```

The base32 encoding allows to leverage the input mode _alphanumeric_ when generating the QR code and produces a QR code with a lower density compared to base64 encoding.


### Interoperability with Other Contact Tracing Apps

Other contact tracing apps that leverage QR code for Presence Tracing can integrate with CWA by creating QR codes according to the followig pattern:

```
<URL>/<VENDOR_DATA>/CWA1/<ENCODED_SIGNED_TRACE_LOCATION>
```

| Parameter | Description |
|---|---|
| `<URL>` | The URL associated with the respective contact tracing apps, with or without a partial path. |
| `<VENDOR_DATA>` | Any vendor-specific data such as venue ids. This data may be passed to the vendor-specific app upon interaction by the user if a deeper integratio is required. |
| `<ENCODED_SIGNED_TRACE_LOCATION>` | A representation of the Protocol Buffer message SignedTraceLocation encoded in either base32 or base64 (see recommendations below). |

To optimize the readability and reduce density of the QR code, CWA recomends to generate QR codes with input mode [_alphanumeric_](https://en.wikipedia.org/wiki/QR_code#Storage) and to encode byte sequences (such as Protocol Buffer messages) with base32.

**Note:** Any contact tracing apps that integrate with CWA must ensure that they do not process any information from the CWA part of the QR code.

Examples:

```shell
# upper-case for alphanumeric input mode + base32 encoding
HTTPS://PRESENCE-TRACING.APP/386D0384-8AAA-41B6-93C2-D3399894D0EE/CWA1/BIPEY33...

# base64 encoding
https://check-in.pt.app/386d0384-8aaa-41b6-93c2-d3399894d0ee/CWA1/CiRmY2E...
```