diff --git a/ideas/145-identity.md b/ideas/145-identity.md index 0f6bc57..d7a81c0 100644 --- a/ideas/145-identity.md +++ b/ideas/145-identity.md @@ -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 - - 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 - - - -- 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 + +Goal Date: 2018-05-15 Description: - Working contracts system - Basic UI for direct interaction with blockchain - ### Minimal Viable Product -Goal Date: 2018-06-01 + +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: - ### Seamless Status Integration -Goal Date: 2018-06-15 - +Goal Date: 2018-06-15 - Identity Sign-in: - Create new; @@ -133,23 +132,23 @@ Goal Date: 2018-06-15 +Goal Date: 2018-07-01 - Recovery: Setup/Update/Cancel Update - Request recovery to selected "friends". - Confirm/reject other's recovery request ## Success Metrics - -Users opt-in using an Identity to enhance interaction with decetranlize systems (such as Status itself) - - +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 - -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