address feedback

EIPS/eip-5791.md

@@ -13,29 +13,28 @@ requires: 191, 721
 
 ## Abstract
 
-This standard is an extension of [EIP-721](./eip-721.md). It proposes a minimal interface for an [EIP-721](./eip-721.md) NFT to be "physically backed" and owned by whoever owns the NFT's physical counterpart.
+This standard is an extension of [EIP-721](./eip-721.md). It proposes a minimal interface for a [EIP-721](./eip-721.md) NFT to be "physically backed" and owned by whoever owns the NFT's physical counterpart.
 
 ## Motivation
 
 NFT collectors enjoy collecting digital assets and sharing them with others online. However, there is currently no such standard for showcasing physical assets as NFTs with verified authenticity and ownership. Existing solutions are fragmented and tend to be susceptible to at least one of the following:
 
-- The NFT cannot proxy as ownership of the physical item. In most current implementations, the NFT and physical item are functionally two decoupled distinct assets after the NFT mint, in which the NFT can be freely traded independently from the physical item.
+- The ownership of the physical item and the ownership of the NFT are decoupled.
 
-- Verification of authenticity of the physical item requires action from a trusted entity (e.g. StockX).
-
-This document proposes a solution to mitigate these issues in a decentralized way. Its intent is to be the simplest possible path towards linking physical items to digital NFTs without a centralized authority.
+- Verifying the authenticity of the physical item requires action from a trusted 3rd party (e.g. StockX).
 
 ## Specification
 
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
 
 ### Requirements
 
-This approach assumes that the physical item must have a chip attached to it that fulfills the following requirements:
+This approach requires that the physical item must have a chip attached to it that fulfills the following requirements:
 
-- the ability to securely generate and store an ECDSA secp256k1 asymmetric keypair
-- the ability to sign messages from the private key of the asymmetric keypair
-- the ability for one to retrieve only the public key of the asymmetric keypair (private key non-extractable)
+- The chip can securely generate and store an ECDSA secp256k1 asymmetric keypair;
+- The chip can sign messages using the private key of the previously-generated asymmetric keypair;
+- The chip exposes the public key; and
+- The private key cannot be extracted
 
 The approach also requires that the contract uses an account-bound implementation of [EIP-721](./eip-721.md) (where all [EIP-721](./eip-721.md) functions that transfer must throw, e.g. the "read only NFT registry" implementation referenced in [EIP-721](./eip-721.md)). This ensures that ownership of the physical item is required to initiate transfers and manage ownership of the NFT, through a new function introduced in this interface described below.
 
@@ -99,12 +98,14 @@ interface IERC5791 {
 
 ```
 
-To aid recognition that an [EIP-721](./eip-721.md) token implements physical binding via this EIP: upon calling [EIP-721](./eip-721.md)’s `function supportsInterface(bytes4 interfaceID) external view returns (bool)` with `interfaceID=0xa70d2657`, a contract implementing this EIP must return true.
+To aid recognition that an [EIP-721](./eip-721.md) token implements physical binding via this EIP: upon calling [EIP-165](./eip-165.md)’s `function supportsInterface(bytes4 interfaceID) external view returns (bool)` with `interfaceID=0xa70d2657`, a contract implementing this EIP must return true.
 
 The mint interface is up to the implementation. The minted NFT's owner should be the owner of the physical chip (this authentication could be implemented using the signature scheme defined for `transferTokenWithChip`).
 
 ## Rationale
 
+This solution's intent is to be the simplest possible path towards linking physical items to digital NFTs without a centralized authority.
+
 The interface includes a `transferTokenWithChip` function that's opinionated with respect to the signature scheme, in order to enable a downstream aggregator-like product that supports transfers of any NFTs that implement this EIP in the future.
 
 ### Out of Scope
@@ -116,7 +117,7 @@ The following are some peripheral problems that are intentionally not within the
 - ensuring that the chip stays attached to the physical item
 - etc.
 
-Work is being done on these challenges in parallel. For example, the Ethereum Reality Service (`https://www.ers.to/`) is meant to tackle some of these issues.
+Work is being done on these challenges in parallel.
 
 Mapping token ids to chip addresses is also out of scope. This can be done in multiple ways, e.g. by having the contract owner preset this mapping pre-mint, or by having a `(tokenId, chipAddress)` tuple passed into a mint function that's pre-signed by an address trusted by the contract, or by doing a lookup in a trusted registry, or by assigning token ids at mint time first come first served, etc.
 
@@ -128,8 +129,6 @@ This proposal is backward compatible with [EIP-721](./eip-721.md) on an API leve
 
 ## Reference Implementation
 
-At the time of writing, Kong is a supplier of chips that satisfy the cryptographic properties listed above.
-
 The following is a snippet on how to recover a chip address from a signature.
 
 ```solidity