Exposure Notifications Verification Server

This is a reference implementation for an Exposure Notifications verification server, part of the broader Google Exposure Notifications system.

About the Server

This server follows the high level flow for a verification system:

1. Authenticates and authorizes humans using Identity Platform.

2. Provides a web interface for epidemiologists (epi) to enter test parameters (e.g. status + test date) to issue a verification code.

   • Short verification codes are typically 6-10 numeric digits and can be read over the phone to a patient. They expire quickly, usually in less than one hour.

   • Longer verification codes can be sent directly to the patient via SMS. These codes generally last longer, like 24 hours.

3. Provides a JSON-over-HTTP API for exchanging the verification code for a verification token. This API is called by the patient's device.

   • Verification tokens are signed JWTs with a configurable validity period.

4. Provides a JSON-over-HTTP API for exchanging the verification token for a verification certificate. This API call also requires an HMAC of the Temporary Exposure Key (TEK) data+metatata. This HMAC value is signed by the verification server to be later accepted by an exposure notifications server. This same TEK data used to generate the HMAC here, must be passed to the exposure notifications server, otherwise the request will be rejected.

   • Please see the documentation for the HMAC Calculation

   • The Verification Certificate is also a JWT

Architecture diagram

Architecture details

• This application is comprised of the following services which are designed to be serverless and scale independently:

  • cmd/server - Web UI for creating verification codes

  • cmd/apiserver - Server for mobile device applications to do verification

  • cmd/adminapi - (optional) Server for connecting existing PHA applications to the verification system.

  • cmd/cleanup - Server for cleaning up old data. Required in order to recycle and reuse verification codes over a longer period of time.

• PostgreSQL database for shared state. Other databases may work, but we only aim to support Postgres at this time.

• Redis for caching and distributed rate limiting.

• Identity Platform for login.

More resources

• API guide
• Realm admin guide
• User guide
• Development
• Using the Cloud SQL Proxy
• Production
• Testing