The SafeTogether Ecosystem

Committee Draft,

This version:
https://safe-together.github.io/specification/
Issue Tracking:
GitHub
Editors:
(Copernicani.it)
(Coronavirus Outbreak Control)
(LinkedData.Center)

CC0 To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 22 July 2020, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

Abstract

This document provides an interoperability framework for software components and support services that provide the operators in charge of some tools to help tackle phase 2 of the epidemic emergency.

Status of This Document

This document is an incomplete draft. The sections that have been incorporated have not yet been reviewed following the editorial [PROCESS]. However, the information in this document is still subject to change.

You are invited to contribute any feedback, comments, or questions you might have.

All personal data contained in this document (e.g. emails, addresseses etc., etc.) are sole properties of the respective owners and can't be used nor imported without their written permission. The reverse enginering and automatic scraping and/or crawling of all project resources is not permitte

1. Introduction

SafeTogether is a non-for-profit efforts of a wide group of international volunteers to develop technologies helping and supporting practitioners in their fight against COVID-19.

Volunteers are private individuals, professionals, students and people connected or belonging to supporting institutions and private companies who joined pro bono the endeavour.

The volunteers are divided into sub-projects teams (i.e. Application Domains) and in coordination with each other.

  1. Self-certification of movements: measure to comply with State or regional requirements. It allows to forecast places at risk of crowding, to report them to the authorities, to discourage the influx of people, informing people so they can decide to move in greater safety. It digitizes the procedure for the citizen and drastically speeds up the control by the authorities.

  2. Cordon sanitaire (Shielding) : for shielding high-risk categories, the system supports the management of a “buffer” with immune persons, according to the proposal of Prof. Udi Shapiro from the Weizmann Institute. Healthcare professionals are the only authority that can register and associate a digital certificate (whose chain of trusts is internationally verifiable) certifying immunity on the smartphone. Designed for support staff for high-risk categories, it enables to verify directly the truthfulness and validity of the certificate, avoiding the risk of fraud.

  3. Self-certification test: allows a person to document the performance of her own serology test and allows her to certify the result to third parties, for circumstances where lower level of certainty than required by the cordon sanitaire, is appropriate.

  4. Tracing: contact/exposure information from de-identified users is collected efficiently and completely anonymously. It allows medical and emergency management authorities to take the correct actions to alert people who have had the closest contact with a person found to be infected. The system does not process personal information, using only anonymous data exchanged via Bluetooth LE. More details about tracing is provided below.

  5. Quarantine: to guarantee physically the presence of the specific person in a set place is addressed in a number of ways including telephone check by a call center and, thanks to an IPR provided pro bono by the rightsholder, through a biometric recognition performed locally on the smartphone, which does not involve the transmission of any identifiable personal data.

  6. Infrastructure management: specialized support from companies specializing in the implementation, testing and roll-out phases of previous systems, addressing issues related to security aspects and related to infrastructure scalability. Management of the evolutionary maintenance of applications.

  7. User interaction and Process Management: operational support in managing the flow of a user’s transaction from start to finish, accompanying the timing and actual flow of activities, as well as supporting users to meet their expectations (or performance standards) associated with each of the contact points provided.

We are aware that authorities are requiring direct control of the platforms they deploy and they want to run them from infrastructure under their control, often inside their borders, therefore our approach is focused on the definition of a set of protocols, the implementation of the supporting backends and the provision of a reference implementation of the user facing clients.

Some components are ready to be used, others are under development.

Those interested in providing their input or support the initiative can send an email to info@safetogether.app or SafeTogether Web Site.

2. SafeTogether Applications

The SafeTogether Specification describes requirements and protocols for SafeTogether applications and is composed by set of related documents:

Some requirements apply to SafeTogether applications:

3. Reference Implementations

Reference Implementations are SafeTogether applications that are compliant with following requirements:

There MAY exists more than one *Reference Implementation" for each application domain. Here is a known list:

Quarantine
Domain Maturity Resources
Tracing ready to deploy the Coronavirus Outbreak Control team is working to the Covid Community Alert system (aka CovidApp). They released the whole system open source in its GitLab repository. A video is available
Quarantine demo ready A reference implementation for Quarantine System by KeyLess. The application uses a biometric multi-factor authentication platform powered by patent pending privacy-enhancing security technology owned by KeyLess
Shielding demo ready A reference implementation and the documentation for Shielding system by the g0v.it team. The source repository was created. The reference implementation uses portion of LinkedData.Center patent pending Mopso KYC technologies together with the Sovrin infrastructure and Infocert DIZME app.

A video storyboard is available.

Please, contact editors to update this list.

4. Contributors

Any individual that has been involved in proposals to improve the SafeTogether Specification has provided a valuable service to SafeTogether Project and is encouraged to continue.

All manner of contributions are important - whether identifying problems, asking questions, or proposing normative changes.

There are many topics, problems, or ideas best tackled by a group of people with a specific set of domain expertise. For these cases, we have § 6 Panels

5. Stakeholders

Stakeholders are those affected by normative changes to the SafeTogether Specification. There are two types of stakeholders:

users

SafeTogether Users are individuals, companies, or organizations who access a SafeTogether Application.

implementers

SafeTogether Implementers are individuals, companies or organizations who are implementing portions of the SafeTogether Specification.

A Stakeholder may be both a user and an implementer. It is important to consider them both when proposing changes.

Anyone may decide to identify themselves publicly as a SafeTogether Stakeholder, but it is not mandatory. Identified stakeholders may be consulted for feedback as part of the editorial process.

Stakeholders who have opted to identify themselves publicly are listed below:

6. Panels

SafeTogether Panels are groups of individuals focused on a specific problem or domain relevant to the SafeTogether project. Anyone can join a panel or suggest a new panel.

Anyone can create a Panel by making a pull request directly to this document.

Domains may be technical, non-technical, or a combination of both.

This listing helps people find panels they may want to participate in, and helps editors find panels to consult as part of the editorial process.

Index of available Panels:

More or less there is a weekly SafeTogether Community Group call to review all panels. See general channel in § 6.1 General discussion Panel to find out the agenda and exact time of the next call and the address to connect to it, or to add put item on the next agenda.

Development teams and community use thier own process and channel to communicate.

6.1. General discussion Panel

General Discussion about the project governances, process and news

Communication channels:

Panelists:

Editorial Assignment:

Relevant news should be inserted in the project web site

6.2. Stories Panel

Definition of personas and user stories inspiring SafeTogether

Communication channels:

Panelists:

Editorial Assignment:

Candidate Proposals to the SafeTogether Specification produced by this panel are likely to be associated with the [STORIES] specifications, and will be principally reviewed by any editors assigned to it.

7. Repositories

Each repository has one or more assigned editors, and only assigned editors are permitted to merge into the master branch of these repositories.

Editors have _Admin Permissions_ on the repositories they are assigned to.

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

References

Normative References

[PROCESS]
E.Fagnoni. The SafeTogether Process. URL: https://safe-together.github.io/specification/process
[PROTOCOLS]
Protocols and Architectures. URL: https://safe-together.github.io/specification/protocols
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[STORIES]
E.Fagnoni; M.D'Aliessi; A.Carmignani. Personas and User Stories. URL: https://safe-together.github.io/specification/stories

Informative References

[FSF]
Free Software Licenses. URL: https://www.gnu.org/licenses/license-list.html