EIP 2619 - Geotimeline Contact Tracing Data Standard #2619
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
axic
reviewed
May 6, 2020
EIPS/eip-2611.md
Outdated
| @@ -0,0 +1,152 @@ | |||
| --- | |||
| eip: 2611 | |||
There was a problem hiding this comment.
Where is 2611 coming from? That seems to be something different: #2611
Have to use 2619, which is the number of this PR.
marleymarl
changed the title
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
MicahZoltu
suggested changes
Sep 9, 2020
There was a problem hiding this comment.
It looks like for some reason this change touches some files in the root of this repository. Can you remove those changes so this can potentially be merged?
It is unclear to me why this needs to be a standard? Keep in mind that not all good ideas should be standards, and while this may be a good idea, I think it would make more sense to just build an application/contract rather than trying to define a standard.
| ## Implementation | ||
| <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.--> | ||
|
|
||
| ## Copyright |
There was a problem hiding this comment.
Suggested change
| ## Copyright | |
| ## Security Considerations | |
| TBD | |
| ## Copyright |
|
|
||
|
|
||
| ## Implementation | ||
| <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.--> |
There was a problem hiding this comment.
Suggested change
| <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.--> | |
| TBD |
| By creating an EIP, we hope to increase the use of Ethereum as an open immutable data store for contact tracing data and encourage contact tracing organizations to thus make this data open and available while preserving privacy and anonymity. | ||
|
|
||
| ## Test Cases | ||
| <!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.--> |
There was a problem hiding this comment.
Suggested change
| <!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.--> |
| ``` | ||
|
|
||
| ## Rationale | ||
| <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> |
There was a problem hiding this comment.
Suggested change
| <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> |
Comment on lines
+41
to
+44
| <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).--> | ||
|
|
||
|
|
||
|
|
There was a problem hiding this comment.
Suggested change
| <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).--> |
| This standard outlines a smart contract interface for recording and retrieving geotimelines for the purpose of contact tracing. The key issue is that it is important to share this data and at the same time maintain privacy and anonymity of both confirmed cases of COVID and of those people wanting to check their geotimelines against that data. At the same time it is important to provide a way to ensure that the data is entered through trusted parties. The Geotimeline standard enables contact tracing organizaitons to be whitelisted before securely, anonymously and privately storing this information and making it available for retrieval. | ||
|
|
||
| ## Motivation | ||
| <!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.--> |
There was a problem hiding this comment.
Suggested change
| <!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.--> |
| A standard interface for storing to and retrieving from the blockchain historical points of location and time, collectively those points forming a geotimeline for individuals, for the purpose of contact tracing for COVID-19 and any other pandemic, in an anonymous and private way, while at the same time ensuring data integrity. | ||
|
|
||
| ## Abstract | ||
| <!--A short (~200 word) description of the technical issue being addressed.--> |
There was a problem hiding this comment.
Suggested change
| <!--A short (~200 word) description of the technical issue being addressed.--> |
Comment on lines
+12
to
+13
| <!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.--> | ||
|
|
There was a problem hiding this comment.
Suggested change
| <!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.--> |
| <!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.--> | ||
|
|
||
| ## Simple Summary | ||
| <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.--> |
There was a problem hiding this comment.
Suggested change
| <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.--> |
|
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
eip: 2619
title: Geotimeline Contact Tracing Data Standard
author: Greg Marlin (@marleymarl)
discussions-to: marleymarl/geotimeline#95
status: Draft
type: Standards Track
category: ERC
created: 2020-04-23
Simple Summary
A standard interface for storing to and retrieving from the blockchain historical points of location and time, collectively those points forming a geotimeline for individuals, for the purpose of contact tracing for COVID-19 and any other pandemic, in an anonymous and private way, while at the same time ensuring data integrity.
Abstract
This standard outlines a smart contract interface for recording and retrieving geotimelines for the purpose of contact tracing. The key issue is that it is important to share this data and at the same time maintain privacy and anonymity of both confirmed cases of COVID and of those people wanting to check their geotimelines against that data. At the same time it is important to provide a way to ensure that the data is entered through trusted parties. The Geotimeline standard enables contact tracing organizaitons to be whitelisted before securely, anonymously and privately storing this information and making it available for retrieval.
Motivation
Contact tracing is a critical activity for reducing the spread of COVID-19 and other pandemic viruses, and in helping to mitigate risks after the end of quarantine periods. Key issues related to contact tracing include data integrity and availability, as well as individual privacy and anonymity.
The GeoTimeline international team of volunteers have been working on an open source map data input front-end component library that makes it easy to capture geotimelines, points of location and time that each represent a set of historical footprints that identify to one person but protect privacy and anonymity through the assignment of random uuids.
Contact tracing workers capture this information by clicking on a map and adding a date and time to associate with that latitude and longitude point using a pop-up modal form. After a set of these points with date and time are collected, they are saved as one geotimeline.
The GeoTimeline Application can be used by contact tracing organization that are typically made up of many human team members interviewing people and recording the information.
This standard addresses the issues of privacy and anonymity as well as data integrity and availability in the following ways:
By applying this standard, GeoTimeline will integrate secure signing and authentication of a trusted party through the integration of an Ethereum wallet on the frontend (using MetaMask / web3.js) to be used to prove the organization entering the data is a verified organization. The geotimelines will be represented on the blockchain as an address with associated geotimeline bounding box coordinates and status (confirmed case, suspect, not suspect, recovered). Nothing will be able to be tied back to an individual's personal identity by looking at the blockchain. At the same time they key information that is needed to be open and available will be there and queriable, namely the geotimeline information.
Specification
Methods
geotimeline
Returns the hash of set of footprints associated with a timeline address, along with it geotimeline bounding box values (2 geohashes representing top-left and bottom-right lat/lon values and 2 timestamps representing earliest time and latest time) and case status
getAllGeoTimelines
Returns all timeine addresses that fall within geotimeline bounding box values (timestamps falling in between earliestTime and lastestTime and geohashes falling in between upperLeftGeoHash and bottomRightGeoHash)
addGeoTimeline
Saves a timeline using an IPFS hash representing all footprints in a geotimeline, along with its bounding box values of start date/time, end date/time, upper-left geohash and bottom-right geohash as well as status (confired case, not suspect, suspect, recovered) and gets back an Id for the geotimeline that was saved to the array
addVerifiedOrganization
Adds the wallet address of a contact tracing organization to a list of approved addresses that can add geotimeline data
isVerifiedOrganization
Adds the wallet address of a contact tracing organization to a list of approved addresses that can add geotimeline data
updateTimelineStatus
Updates the status of a given timeline to reflect a new value (non suspect, suspect, confirmed, recovered)
Events
GeoTimelineAdded
MUST trigger when a new geotimeline is added.
VerifiedOrganizationAdded
MUST trigger when a new verifiedOrganization is added.
VerifiedOrganizationRemoved
MUST trigger when a verifiedOrganization is removed.
ConfirmedCaseUpdate
MUST trigger when the status of a geotimeine is updated to confirmed.
Rationale
The proposed solution was designed to provide a way to address key issues of data integrity and availability, while at the same time ensuring anonymity and privacy of the individuals whose geotimelines are being stored on and retrieved from the blockchain.
By creating an EIP, we hope to increase the use of Ethereum as an open immutable data store for contact tracing data and encourage contact tracing organizations to thus make this data open and available while preserving privacy and anonymity.
Test Cases
GeoTimeline will be implementing this within its project and will be approaching contact tracing organizations to use it within the framework of the overall contact tracing solution. This section will be updated when GeoTimeline has deployed a smart contract based on this standard to the Ropsten test network.
Implementation
Copyright
Copyright and related rights waived via CC0.