mirror of https://github.com/status-im/swarms.git
lint and more details
This commit is contained in:
Ricardo Guilherme Schmidt
Oskar Thorén
parent
62aab29990
commit
483849858c
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Preamble
|
||||
|
||||
Idea: #145
|
||||
Idea: #145-identity
|
||||
Title: Identity
|
||||
Status: In Progress
|
||||
Created: 2018-05-04
|
||||
|
|
@ -27,6 +27,7 @@ Creates a common user-owned credentials for authentication on smart contracts an
|
|||
Self sovereign identity can disrupt single sign on services by using blockchain ledger, smart contracts and encryption techniques.
|
||||
|
||||
#### Traditional sign-in:
|
||||
|
||||
1. Verification of personal information is required for each single sign on service.
|
||||
2. Services usually require trusting your personal information to multiple companies, which may collect it.
|
||||
3. Some services require payment credentials to be stored in their database, which might be abused.
|
||||
|
|
@ -36,6 +37,7 @@ Self sovereign identity can disrupt single sign on services by using blockchain
|
|||
In traditional services you can get conforted by having an authority taking care of your data, which not only control your access to it, but also can read it (and sell it).
|
||||
|
||||
#### Self-sovereign identity sign-in:
|
||||
|
||||
1. Verified claims over Identity could be required by services.
|
||||
2. Personal data is held by Identity owner
|
||||
3. Payment system is done by payment authorizations made by Identity owner.
|
||||
|
|
@ -45,13 +47,15 @@ In traditional services you can get conforted by having an authority taking care
|
|||
In self-sovering identity its owner have full resposability over its safety, but also have full control of their Identity.
|
||||
|
||||
#### Fundamental terms:
|
||||
|
||||
- ID Manager (owner) can define MultiSig public keys required for its management/actions;
|
||||
- ID Manager (owner) can define a Recovery contract;
|
||||
- ID Manager (owner) can define public keys for other; users knowing how to encrypt data for identity owner;
|
||||
- ID Manager (owner) can accept claims;
|
||||
- ID Manager (owner) can make claims.
|
||||
|
||||
#### Status Use Case
|
||||
#### Status Use Case:
|
||||
|
||||
From user perspective, instead of talking to obscure address/contracts, users would able to confirm that a person is whom they expect to be interacting.
|
||||
Mainly because they usually know by community network who is the Identity holder and can safely assume is the right person.
|
||||
|
||||
|
|
@ -60,6 +64,7 @@ This is important for chat system, where Identities provide the right key for ot
|
|||
Recovery contract, if safely defined, will garantee that Identity owner is able to get back their Identity from loss or theft, therefore no need to create a new one and ask friends to update their contact list with your new Identity.
|
||||
|
||||
#### External references:
|
||||
|
||||
- [EIP#725](https://github.com/ethereum/EIPs/issues/725)
|
||||
- [EIP#735](https://github.com/ethereum/EIPs/issues/735)
|
||||
- [Fabian Vogelsteller - ERC: Identity - Ethereum London](https://www.youtube.com/watch?v=jv3BmGGFP7c)
|
||||
|
|
@ -72,11 +77,7 @@ Recovery contract, if safely defined, will garantee that Identity owner is able
|
|||
- [Self-sovereign BigchainDB data injection in smart contracts through the Jolocom Identity Gateway](https://www.youtube.com/watch?v=8K-BDlsx8KQ)
|
||||
- [IDbox – Cost efficient device for self-sovereign identity](https://www.youtube.com/watch?v=h1Oz3oEtZxE)
|
||||
|
||||
|
||||
|
||||
|
||||
### Product Description
|
||||
<!-- What functionality are you adding? What will this look like from a user perspective? Why is this important? -->
|
||||
|
||||
- Smart contracts: See [GDocs Identity Terms Intent](https://docs.google.com/document/d/1K8tFjGneScuKiudpD3HfSpAd4eOe8012jn0Q3iDxEV0/edit#) and [Identity Readme](https://github.com/status-im/contracts/blob/develop/Identity.md)
|
||||
- Basic contracts demo: Helps engaging developers and bug hunting.
|
||||
|
|
@ -86,10 +87,8 @@ Recovery contract, if safely defined, will garantee that Identity owner is able
|
|||
- Identity Management: User may setup keys & recovery options for its identity, confirm claims and even update the contract code.
|
||||
|
||||
### Requirements & Dependencies
|
||||
<!-- Are there bugs or feature requests in other repositories that are part of this Idea? -->
|
||||
<!-- There is no approval unless the idea requires to be reviewed by supporting organelles (Financial, Hiring, or Design). -->
|
||||
<!-- The Swarm must develop a fully fleshed out Requirements document for the idea to proceed, to the satisfaction of participants. -->
|
||||
- For finalizing this idea ERC725 and ERC735 should be approved as standard, this swarm might influence how this standards end up defined, this is important for the solution working better with unknown future applications.
|
||||
|
||||
- ERC#725 and ERC#735 should be approved as standard, this swarm might influence how this standards end up defined, this is important for the solution working better with unknown future applications.
|
||||
|
||||
- #27 ENS subdomain registry is important as a shortcut for user's identity address, otherwise QR-Codes or big hexadecimal strings would be needed.
|
||||
|
||||
|
|
@ -97,29 +96,29 @@ Recovery contract, if safely defined, will garantee that Identity owner is able
|
|||
|
||||
|
||||
## Dates
|
||||
|
||||
### Proof-of-concept
|
||||
Goal Date: 2018-05-15<!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format -->
|
||||
|
||||
Goal Date: 2018-05-15
|
||||
|
||||
Description:
|
||||
- Working contracts system
|
||||
- Basic UI for direct interaction with blockchain
|
||||
|
||||
|
||||
### Minimal Viable Product
|
||||
Goal Date: 2018-06-01<!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format -->
|
||||
|
||||
Goal Date: 2018-06-01
|
||||
|
||||
Description:
|
||||
- Status Wallet enables creation, association or recovery of Identity
|
||||
- Status Wallet enables transactions to be executed by Identity
|
||||
- Identity management (basic)
|
||||
|
||||
|
||||
Testing Days required: <!-- Days required at the end of development for testing -->
|
||||
|
||||
|
||||
### Seamless Status Integration
|
||||
|
||||
Goal Date: 2018-06-15<!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format -->
|
||||
|
||||
Goal Date: 2018-06-15
|
||||
|
||||
- Identity Sign-in:
|
||||
- Create new;
|
||||
|
|
@ -133,23 +132,23 @@ Goal Date: 2018-06-15<!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format --
|
|||
- Update of Kernel
|
||||
|
||||
### Recovery Support
|
||||
Goal Date: 2018-07-01<!-- Date for evaluation in ISO 8601 (yyyy-mm-dd) format -->
|
||||
|
||||
Goal Date: 2018-07-01
|
||||
|
||||
- Recovery: Setup/Update/Cancel Update
|
||||
- Request recovery to selected "friends".
|
||||
- Confirm/reject other's recovery request
|
||||
|
||||
## Success Metrics
|
||||
<!-- Assuming the idea ships, what would success look like? What are the most important metrics that you would move? -->
|
||||
|
||||
Users opt-in using an Identity to enhance interaction with decetranlize systems (such as Status itself)
|
||||
|
||||
<!-- Example: Onboarding conversion rate. Target >30% full funnel -->
|
||||
Status Users opt-in using an Identity to enhance interaction with decetralize systems (such as Status itself).
|
||||
Developers start using Status Identity implementation as base.
|
||||
New users adopt Status because Identity support, which will be required for many dapps in future.
|
||||
|
||||
## Exit criteria
|
||||
<!-- Launch new onboarding UI flow -->
|
||||
Community consensus in ERC725 and ERC735 interfaces, launched on Status.
|
||||
|
||||
Ethereum Foundation approval of ERC#725 and ERC#735 standard interfaces.
|
||||
Fully integrated on Status App.
|
||||
|
||||
## Supporting Role Communication
|
||||
<!-- Once Requirements and Goals are fleshed out, then it should be communicated to supporting organelles if required -->
|
||||
|
|
|
|||
Loading…
Reference in New Issue