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

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);