mirror of https://github.com/status-im/EIPs.git
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
This commit is contained in:
Muhammad Altabba
EIP Automerge Bot
parent
9991f4689b
commit
6965fff12c
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue