(most up to date version in https://docs.google.com/document/d/1AydmZjjMxw1XhG5I03pKbM7iI4cmpHgLadGlYBghCkg/edit )

Author: @Ranna Zhou

Status: composing

Required reviewers: Kyle, Sam, Adam Smith (privacy), Dazza (legal / principles), Diarmid (security and test)

Project owners

Authentication Tech = Lina Mårtensson

Places Tech = 

Places UX = Adam Laskowitz

App Tech = 

App UX = Jeff Stolz

Links to tech specs:

[Draft] Authentication of positive status

Overview

Problem Statement

A brief description of the problem we're trying to solve. Why is this valuable to work on? If you are working on an HA engagement, this is the main section that’s required to be filled out.

The health authority needs a way to notify community members of exposure to a COVID-19 carrier.

Proposed Work

A high-level overview of what we're building and why it will solve the problem.

We will build a secure way for the carrier to share identifier beacon(s) with the health authority for the entire duration that the carrier is likely to be contagious. This security will also ensure that the carrier’s positive status is validated.

Background

Any work done in this area to date and the context necessary to understand the user problems below. 

Terminology

Carrier = a community member who has tested positive for COVID-19.

Asymptomatic carrier = a community member who has tested positive but does not display any known symptoms.

Identifier beacon = the information broadcasted by an individual’s device via bluetooth. Also talked about as a phone’s “random ID”

Collision = when 1 or more community members using a GAEN app register being co-located and therefore have stored the identifier beacon(s) locally on their respective devices.

Exposure event = a collision with a carrier, meaning that the device displaying the notification has compared the locally stored beacons with the list of recent ones from carriers downloaded from the HA’s Path Check server.

Path Check server = the server serving the list of recent carrier beacons that community member app instances compare their collision list against.

Expected experience

An easy-to-follow walkthrough of the end-to-end experience of collision to exposure notification.

Google statements:

• If at some point a user is positively diagnosed with COVID-19, he or she can work with the health authority to report that diagnosis within the app, and with their consent their beacons will then be added to the positive diagnosis list. User identity will not be shared with other users, Apple and Google as part of this process. (From page 3 of their V1.1 FAQ)

• Community member-facing documentation of positive status flow:

Open

Technical context/notes

• The identifier beacon of a device changes every 10-20 minutes.

• Information available for a single exposure event

User Problems

The issues that users are having in this problem area today. Usually a statement about what the user needs and what’s making it hard for them to satisfy this need.

• A carrier doesn’t have a way to trigger exposure notifications for other community members that come into contact with them during the entire time they are likely to be contagious.

• A health authority doesn’t have a secure way to verify a carrier’s positive status in the BLE system.

• (I’m sure there are more.)

Scope

Requirements

What requirements should this project fulfill? Explicit functional requirements.

“Generate positive status code” workflow tool in Safe Places

• An HA representative can generate a new verification code that when communicated to a community member, the community member can enter into their Path Check app to begin the positive status user flow.

  • Who this representative is depends upon the health authorities’ operational processes for whose responsibility it is to notify a carrier of positive status. For example, it could be a medical professional at the time of test result readout, a testing center administrator, a contact tracer, etc.

  • What form this code should take depends upon the health authorities’ operational processes for how the notification should happen. See next points on usability and security.

• The representative can configure the time period (in days) that the positive status is for, with the default and maximum being 14 days, as that’s the maximum retention time for identifier beacons on the device anyway.

  • This is to enable accounting for any potential time delay between the test, receipt of test result, and notification of test result).

• (Usability) The code must be easy to disclose to the community member, preferably at the same time and in the same manner that the positive test result is being communicated.

  • If disclosed over the phone, the code should be short and hard to mishear. E.g. N random common words.

  • If disclosed on paper, the code should be a scannable QR code or similar.

  • If disclosed over SMS or email, the code should be a 

• (Security) The code should be valid for only a certain period of time where possible.

  • If receiving over phone, SMS, or email, the code will be valid for 15 mins.

• (Security) Once a verification code is used, it may not be used again and is no longer valid.

• If the community member fails to use a code, the health authority representative should be notified.

  • TBD/needs fleshing out if this is necessary, but this seems like something that most HAs might want.

Community member app: positive status flow

• A carrier scans or enters a positive status verification code provided by their health authority.

  • If the code is not valid, the community member receives a prompt to contact their health authority for a code if they believe this is in error.

• The carrier can consent to sharing their last 14 days of identifier beacons with the HA.

• The carrier can consent to sharing all identifier beacons for the next N days, where N is the number of days the HA representative configured the positive status to be valid for.

• OPEN Q: what happens if the user declines?

• When the time period is up, the carrier is notified that their positive status has expired. 

  • (idea) thank them for contributing to slowing the spread by enabling automated, privacy-conscious contact tracing :)

Non-Requirements

Include anything related to this project that is out of scope. Helps to cite principles (such as our privacy principles or other).

• We are unable to prevent a carrier from behaving irresponsibly or actively working against the common goal of contact tracing. We explicitly cannot prevent the carrier from:

  • Giving their code to someone else who can then enter the code into their own app.

  • Using a different device in their everyday life other than the one with the app that they entered their verification code in.

• It is the responsibility of the health authority and NOT Path Check to ensure that they are communicating the verification code to the correct community member. We have no ability to ID users of the Path Check app, nor will we implement any features that aid in doing so.

  • OPEN Q: Where should this line be drawn in our existing privacy policy or that of the HA?

Future Work

List requirements that we know we want to add, but will do later.

Community member app: onboarding / signing up to an HA

• HA can configure their onboarding flow to ask other questions of interest (e.g. if they have intake questions at the border)

Open questions

(feel free to add)

• What do the privacy policies of the HA have to include in order for us to be comfortable co-branding their implementation with Path Check? While this is outside of the scope of this spec, this spec does rely on certain things (like the correct identification of the community member as the recipient of the auth code).

•