From 6965fff12caaf1cf237ee5c92e9782965e4b1eb7 Mon Sep 17 00:00:00 2001 From: Muhammad Altabba Date: Mon, 24 Sep 2018 14:18:21 +0300 Subject: [PATCH] Automatically merged updates to draft EIP(s) 725 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 --- EIPS/eip-725.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/EIPS/eip-725.md b/EIPS/eip-725.md index 94106089..71371f0a 100644 --- a/EIPS/eip-725.md +++ b/EIPS/eip-725.md @@ -10,14 +10,14 @@ created: 2017-10-02 --- ## 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 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 -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` @@ -26,7 +26,7 @@ The most important functions to manage an identity are: `XXX` ## 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`: 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 -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 function keyHasPurpose(bytes32 _key, uint256 purpose) constant returns(bool exists); @@ -82,11 +82,11 @@ function getKeysByPurpose(uint256 _purpose) constant returns(bytes32[] keys); #### 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 - `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. 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. 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 on direct execution Event:** [Executed](#executed) @@ -136,8 +136,8 @@ function execute(address _to, uint256 _value, bytes _data) returns (uint256 exec #### approve 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. -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. +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 successfully approve an execution. **Triggers Event:** [Approved](#approved) **Triggers on successfull execution Event:** [Executed](#executed) @@ -159,7 +159,7 @@ Requires: [ERC 735](https://github.com/ethereum/EIPs/issues/735) #### 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: **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 -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. While also off-chain claims using DID verifiable claims and merkle tries can be added as claims and should be explored.