status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-01-16 18:04:31 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 725

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Muhammad Altabba 2018-09-24 14:18:21 +03:00 committed by EIP Automerge Bot
parent 9991f4689b
commit 6965fff12c
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
EIPS/eip-725.md
View File

@ -10,14 +10,14 @@ created: 2017-10-02
--- ---
## Simple Summary ## Simple Summary
Proxy contract for key management and execution, to establish a Blockchain identity. A proxy contract for key management and execution, to establish a Blockchain identity.
## Abstract ## Abstract
The following describes standard functions for a unique identity for humans, groups, objects and machines. The following describes standard functions for a unique identity for humans, groups, objects and machines.
This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third parties (issuers) and self attested ([#ERC735](https://github.com/ethereum/EIPs/issues/735)), as well as a proxy function to act directly on the blockchain. This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third parties (issuers) and self-attested ([#ERC735](https://github.com/ethereum/EIPs/issues/735)), as well as a proxy function, to act directly on the blockchain.
## Motivation ## Motivation
This standardised identity interface will allow Dapps, smart contracts and thirdparties to check the validity of a person, organisation, object or machine through 2 steps as described in the function XXX. Trust is here transfered to the issuers of claims. This standardized identity interface will allow Dapps, smart contracts and third parties to check the validity of a person, organization, object or machine through 2 steps as described in the function XXX. Trust is here transferred to the issuers of claims.
The most important functions to verify an identity are: `XXX` The most important functions to verify an identity are: `XXX`
@ -26,7 +26,7 @@ The most important functions to manage an identity are: `XXX`
## Definitions ## Definitions
- `keys`: Keys are public keys from either external accounts, or contract addresses. - `keys`: Keys are public keys from either external accounts, or contracts' addresses.
- `claim issuer`: is another smart contract or external account, which issues claims about this identity. The claim issuer can be an identity contract itself. - `claim issuer`: is another smart contract or external account, which issues claims about this identity. The claim issuer can be an identity contract itself.
- `claim`: For details about claims see [#ERC735](https://github.com/ethereum/EIPs/issues/735) - `claim`: For details about claims see [#ERC735](https://github.com/ethereum/EIPs/issues/735)
@ -64,7 +64,7 @@ function getKey(bytes32 _key) constant returns(uint256[] purposes, uint256 keyTy
#### keyHasPurpose #### keyHasPurpose
Returns the `TRUE` if a key has is present and has the given purpose. If key is not present it returns `FALSE`. Returns the `TRUE` if a key has is present and has the given purpose. If the key is not present it returns `FALSE`.
``` js ``` js
function keyHasPurpose(bytes32 _key, uint256 purpose) constant returns(bool exists); function keyHasPurpose(bytes32 _key, uint256 purpose) constant returns(bool exists);
@ -82,11 +82,11 @@ function getKeysByPurpose(uint256 _purpose) constant returns(bytes32[] keys);
#### addKey #### addKey
Adds a `_key` to the identity. The `_purpose` specifies the purpose of key. Initially we propose four purposes: Adds a `_key` to the identity. The `_purpose` specifies the purpose of the key. Initially, we propose four purposes:
- `1`: MANAGEMENT keys, which can manage the identity - `1`: MANAGEMENT keys, which can manage the identity
- `2`: ACTION keys, which perform actions in this identities name (signing, logins, transactions, etc.) - `2`: ACTION keys, which perform actions in this identities name (signing, logins, transactions, etc.)
- `3`: CLAIM signer keys, used to sign claims on other identities which need to be revokable. - `3`: CLAIM signer keys, used to sign claims on other identities which need to be revocable.
- `4`: ENCRYPTION keys, used to encrypt data e.g. hold in claims. - `4`: ENCRYPTION keys, used to encrypt data e.g. hold in claims.
MUST only be done by keys of purpose `1`, or the identity itself. If its the identity itself, the approval process will determine its approval. MUST only be done by keys of purpose `1`, or the identity itself. If its the identity itself, the approval process will determine its approval.
@ -121,9 +121,9 @@ function removeKey(bytes32 _key, uint256 _purpose) returns (bool success)
Executes an action on other contracts, or itself, or a transfer of ether. Executes an action on other contracts, or itself, or a transfer of ether.
SHOULD require `approve` to be called with one or more keys of purpose `1` or `2` to approve this execution. SHOULD require `approve` to be called with one or more keys of purpose `1` or `2` to approve this execution.
Execute COULD be used as the only accessors for `addKey`, `removeKey` and `replaceKey` and `removeClaim`. Execute COULD be used as the only accessor for `addKey`, `removeKey` and `replaceKey` and `removeClaim`.
**Returns `executionId`:** SHOULD be send to the `approve` function, to approve or reject this execution. **Returns `executionId`:** SHOULD be sent to the `approve` function, to approve or reject this execution.
**Triggers Event:** [ExecutionRequested](#executionrequested) **Triggers Event:** [ExecutionRequested](#executionrequested)
**Triggers on direct execution Event:** [Executed](#executed) **Triggers on direct execution Event:** [Executed](#executed)
@ -136,8 +136,8 @@ function execute(address _to, uint256 _value, bytes _data) returns (uint256 exec
#### approve #### approve
Approves an execution or claim addition. Approves an execution or claim addition.
This SHOULD require `n` of `m` approvals of keys purpose `1`, if the `_to` of the execution is the identity contract itself, to successfull approve an execution. This SHOULD require `n` of `m` approvals of keys purpose `1`, if the `_to` of the execution is the identity contract itself, to successfully approve an execution.
And COULD require `n` of `m` approvals of keys purpose `2`, if the `_to` of the execution is another contract, to successfull approve an execution. And COULD require `n` of `m` approvals of keys purpose `2`, if the `_to` of the execution is another contract, to successfully approve an execution.
**Triggers Event:** [Approved](#approved) **Triggers Event:** [Approved](#approved)
**Triggers on successfull execution Event:** [Executed](#executed) **Triggers on successfull execution Event:** [Executed](#executed)
@ -159,7 +159,7 @@ Requires: [ERC 735](https://github.com/ethereum/EIPs/issues/735)
#### addClaim #### addClaim
This SHOULD create a pending claim, which SHOULD to be approved or rejected by `n` of `m` `approve` calls from keys of purpose `1`. This SHOULD create a pending claim, which SHOULD be approved or rejected by `n` of `m` `approve` calls from keys of purpose `1`.
Only Events: Only Events:
**Triggers if the claim is new Event and approval process exists:** [ClaimRequested](#claimrequested) **Triggers if the claim is new Event and approval process exists:** [ClaimRequested](#claimrequested)
@ -241,9 +241,9 @@ MUST be triggered when `approve` was called and the claim was successfully added
## Rationale ## Rationale
This specification was chosen to allow most flexibility and experimention around identity. By having each identity in a separate contract it allows for cross identity compatibility, but at the same time extra and altered functionality for new use cases. This specification was chosen to allow most flexibility and experimentation around identity. By having each identity in a separate contract it allows for cross identity compatibility, but at the same time extra and altered functionality for new use cases.
The main critic of this standard is the verification where each identity that issues a claim, also should have a separate CLAIM signing key attached. While [#ERC780](https://github.com/ethereum/EIPs/issues/780) uses a standardised registry to assign claims to addresses. The main critic of this standard is the verification where each identity that issues a claim, also should have a separate CLAIM signing key attached. While [#ERC780](https://github.com/ethereum/EIPs/issues/780) uses a standardized registry to assign claims to addresses.
Both systems could work in conjunction and should be explored. Both systems could work in conjunction and should be explored.
While also off-chain claims using DID verifiable claims and merkle tries can be added as claims and should be explored. While also off-chain claims using DID verifiable claims and merkle tries can be added as claims and should be explored.