Automatically merged updates to draft EIP(s) 1484

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:
Noah Zinsmeister 2018-10-25 13:27:34 -04:00 committed by EIP Automerge Bot
parent 75bafd1eb8
commit 3a484db94d
1 changed files with 6 additions and 30 deletions

View File

@ -13,7 +13,7 @@ created: 2018-10-12
A protocol for aggregating digital identity information that's broadly interoperable with existing, proposed, and hypothetical future digital identity standards. A protocol for aggregating digital identity information that's broadly interoperable with existing, proposed, and hypothetical future digital identity standards.
## Abstract ## Abstract
This EIP proposes an identity management and aggregation framework on the Ethereum blockchain. It allows entities to claim an identity via a singular `Identity Registry` smart contract, associate this `Identity` with Ethereum addresses in a variety of meaningful ways, and use it to interface with smart contracts, enabling arbitrarily complex identity-related functionality. This EIP proposes an identity management and aggregation framework on the Ethereum blockchain. It allows entities to claim an identity via a singular `Identity Registry` smart contract, associate this `Identity` with Ethereum addresses in a variety of meaningful ways, and use it to interface with smart contracts. This enables arbitrarily complex identity-related functionality. Notably (among other features) this proposal is [DID compliant](https://github.com/hydrogen-dev/ERC-1484/blob/master/best-practices/DID-Method.md), can natively support [ERC-725](https://github.com/hydrogen-dev/ERC-1484/tree/master/contracts/examples/Resolvers/ERC725) and [ERC-1056](https://github.com/hydrogen-dev/ERC-1484/tree/master/contracts/examples/Resolvers/ERC1056) identities, and lays a robust foundation for [meta-transactions](https://github.com/hydrogen-dev/ERC-1484/tree/master/contracts/examples/Providers/MetaTransactions).
## Motivation ## Motivation
Emerging identity standards and related frameworks proposed by the Ethereum community (including ERCs/EIPs [725](https://github.com/ethereum/EIPs/issues/725), [735](https://github.com/ethereum/EIPs/issues/735), [780](https://github.com/ethereum/EIPs/issues/780), [1056](https://github.com/ethereum/EIPs/issues/1056), etc.) define and instrumentalize digital identity in a variety of ways. As existing approaches mature, new standards emerge, and isolated, non-standard approaches to identity develop, managing multiple identities will become increasingly burdensome and involve the unnecessary duplication of work. Emerging identity standards and related frameworks proposed by the Ethereum community (including ERCs/EIPs [725](https://github.com/ethereum/EIPs/issues/725), [735](https://github.com/ethereum/EIPs/issues/735), [780](https://github.com/ethereum/EIPs/issues/780), [1056](https://github.com/ethereum/EIPs/issues/1056), etc.) define and instrumentalize digital identity in a variety of ways. As existing approaches mature, new standards emerge, and isolated, non-standard approaches to identity develop, managing multiple identities will become increasingly burdensome and involve the unnecessary duplication of work.
@ -41,7 +41,7 @@ A digital identity in this proposal can be viewed as an omnibus account, contain
The protocol revolves around claiming an `Identity` and managing `Associated Addresses` and `Resolvers`. Identities delegate much of this responsibility to one or more `Providers`. `Provider` smart contracts or addresses may add and remove `Resolvers` indiscriminately, but may only add and remove `Associated Addresses` or other `Providers` with the appropriate permissions. The protocol revolves around claiming an `Identity` and managing `Associated Addresses` and `Resolvers`. Identities delegate much of this responsibility to one or more `Providers`. `Provider` smart contracts or addresses may add and remove `Resolvers` indiscriminately, but may only add and remove `Associated Addresses` or other `Providers` with the appropriate permissions.
### Identity Registry ### Identity Registry
The `Identity Registry` contains functionality to mint new `Identities` and for existing `Identities` to manage their `Providers`, `Associated Addresses`, and `Resolvers`. It is important to note that this registry fundamentally requires transactions for every aspect of building out an `Identity`. However, recognizing the importance of accessibility to dApps and identity applications, we empower `Providers` to build out `Identities` on the behalf of users, without requiring users to pay gas costs. The `Identity Registry` contains functionality to mint new `Identities` and for existing `Identities` to manage their `Providers`, `Associated Addresses`, and `Resolvers`. It is important to note that this registry fundamentally requires transactions for every aspect of building out an `Identity`. However, recognizing the importance of accessibility to dApps and identity applications, we empower `Providers` to build out `Identities` on the behalf of users, without requiring users to pay gas costs. An example of this pattern, often referred to as a meta transactions, can be [seen in the reference implementation](https://github.com/hydrogen-dev/ERC-1484/tree/master/contracts/examples/Providers/MetaTransactions).
Due to the fact that multiple addresses can be associated with a given identity (though not the reverse), `Identities` are denominated by EINs. This `uint` can be encoded in QR format or transformed into more user-intuitive formats, such as a `string`, in registries at the `Provider` or `Resolver` levels. Due to the fact that multiple addresses can be associated with a given identity (though not the reverse), `Identities` are denominated by EINs. This `uint` can be encoded in QR format or transformed into more user-intuitive formats, such as a `string`, in registries at the `Provider` or `Resolver` levels.
@ -368,11 +368,7 @@ MUST be triggered when recovery is initiated.
```solidity ```solidity
event RecoveryTriggered( event RecoveryTriggered(
uint indexed ein, uint indexed ein, address recoveryAddress, address[] oldAssociatedAddresses, address newAssociatedAddress
address recoveryAddress,
address[] oldAssociatedAddresses,
address[] oldProviders,
address newAssociatedAddress
); );
``` ```
@ -381,15 +377,7 @@ event RecoveryTriggered(
MUST be triggered when an `Identity` is poisoned. MUST be triggered when an `Identity` is poisoned.
```solidity ```solidity
event Poisoned( event Poisoned(uint indexed ein, address recoveryAddress, address poisoner, bool resolversCleared);
uint indexed ein,
address recoveryAddress,
address[] oldAssociatedAddresses,
address[] oldProviders,
address[] oldResolvers,
address poisoner,
bool resolversCleared
);
``` ```
### Solidity Interface ### Solidity Interface
@ -413,21 +401,9 @@ contract ERC1484 {
event ResolverRemoved(uint indexed ein, address resolvers, address provider); event ResolverRemoved(uint indexed ein, address resolvers, address provider);
event RecoveryAddressChangeInitiated(uint indexed ein, address oldRecoveryAddress, address newRecoveryAddress); event RecoveryAddressChangeInitiated(uint indexed ein, address oldRecoveryAddress, address newRecoveryAddress);
event RecoveryTriggered( event RecoveryTriggered(
uint indexed ein, uint indexed ein, address recoveryAddress, address[] oldAssociatedAddresses, address newAssociatedAddress
address recoveryAddress,
address[] oldAssociatedAddresses,
address[] oldProviders,
address newAssociatedAddress
);
event Poisoned(
uint indexed ein,
address recoveryAddress,
address[] oldAssociatedAddresses,
address[] oldProviders,
address[] oldResolvers,
address poisoner,
bool resolversCleared
); );
event Poisoned(uint indexed ein, address recoveryAddress, address poisoner, bool resolversCleared);
function identityExists(uint ein) public view returns (bool); function identityExists(uint ein) public view returns (bool);
function hasIdentity(address _address) public view returns (bool); function hasIdentity(address _address) public view returns (bool);