diff --git a/EIPS/eip-1484.md b/EIPS/eip-1484.md index 48f2034c..0f7361cf 100644 --- a/EIPS/eip-1484.md +++ b/EIPS/eip-1484.md @@ -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. ## 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 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. ### 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. @@ -368,11 +368,7 @@ MUST be triggered when recovery is initiated. ```solidity event RecoveryTriggered( - uint indexed ein, - address recoveryAddress, - address[] oldAssociatedAddresses, - address[] oldProviders, - address newAssociatedAddress + uint indexed ein, address recoveryAddress, address[] oldAssociatedAddresses, address newAssociatedAddress ); ``` @@ -381,15 +377,7 @@ event RecoveryTriggered( MUST be triggered when an `Identity` is poisoned. ```solidity -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); ``` ### Solidity Interface @@ -413,21 +401,9 @@ contract ERC1484 { event ResolverRemoved(uint indexed ein, address resolvers, address provider); event RecoveryAddressChangeInitiated(uint indexed ein, address oldRecoveryAddress, address newRecoveryAddress); event RecoveryTriggered( - uint indexed ein, - 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 + uint indexed ein, address recoveryAddress, address[] oldAssociatedAddresses, address newAssociatedAddress ); + event Poisoned(uint indexed ein, address recoveryAddress, address poisoner, bool resolversCleared); function identityExists(uint ein) public view returns (bool); function hasIdentity(address _address) public view returns (bool);