Merge e1e3b2b into 54cf63a

EIPS/eip-6956.md

@@ -4,7 +4,7 @@ title: Asset-bound Non-Fungible Tokens
 description: Asset-bound NFTs anchor a token 1-1 to an asset and operations are authorized through oracle-attestation of control over the asset
 author: Thomas Bergmueller (@tbergmueller), Lukas Meyer (@ibex-technology)
 discussions-to: https://ethereum-magicians.org/t/erc-6956-asset-bound-non-fungible-tokens/14056
-status: Draft
+status: Review
 type: Standards Track
 category: ERC
 created: 2023-04-29
@@ -54,7 +54,7 @@ In this standard we propose to
 As 2. and 3. indicate, the control/ownership/possession of the ASSET should be the single source of truth, *not* the possession of an NFT. Hence, we propose an ASSET-BOUND NFT, where off-chain CONTROL over the ASSET enforces on-chain CONTROL over the anchored NFT.
 Also the proposed ASSET-BOUND NFTs allow to anchor digital metadata inseperably to the ASSET. When the ASSET is a physical asset, this allows to design "phygitals" in their purest form, namely creating a "phygital" asset with a physical and digital component that are inseparable. Note that metadata itself can still change, for instance for "Evolvable NFT".
 
-We propose to complement the existing transfer control mechanisms of a token according to ERC-721, `Approval` according to [ERC-721](eip-721.md) and `Permit` according to [ERC-4494](eip-4494.md), by another mechanism; ATTESTATION. An ATTESTATION is signed off-chain by the ORACLE and must only be issued when the ORACLE verified that whoever specifies the `to` address or beneficiary address has simultaneously been in control over the ASSET. The `to` address of an attestation may be used for Transfers as well as for approvals and other authorizations.
+We propose to complement the existing transfer control mechanisms of a token according to [ERC-721](eip-721.md) by another mechanism; ATTESTATION. An ATTESTATION is signed off-chain by the ORACLE and must only be issued when the ORACLE verified that whoever specifies the `to` address or beneficiary address has simultaneously been in control over the ASSET. The `to` address of an attestation may be used for Transfers as well as for approvals and other authorizations.
 
 Transactions authorized via ATTESTATION shall not require signature or approval from neither the `from` (donor, owner, sender) nor `to` (beneficiary, receiver) account, namely making transfers permissionless. Ideally, transaction are signed independent from the ORACLE as well, allowing different scenarios in terms of gas-fees.
 
@@ -65,7 +65,7 @@ Lastly we want to mention two major side-benefits of using the proposed standard
 
 ### Related work
 
-We primarily aim to onboard physical or digital ASSETS into dApps, which do not signing-capabilities of their own (contrary to [ERC-5791](eip-5791.md) approach using crypto-chip based solutions). Note that we do not see any restrictions preventing to use ERC-5791 in combination with this standard, as the address of the crypto-chip qualifies as an ANCHOR.
+We primarily aim to onboard physical or digital ASSETS into dApps, which do not signing-capabilities of their own (contrary to the proposed `ERC-5791` using crypto-chip based solutions). Note that we do not see any restrictions preventing to use `ERC-5791` in combination with this standard, as the address of the crypto-chip qualifies as an ANCHOR.
 
 <!-- TO BE EXTENDED -->
 
@@ -530,15 +530,15 @@ Possession based use cases are covered by the standard interface `IERC6956`: The
 
 - **Selling a house with a mortgage:** The owner holds NFT as proof of ownership. The DeFi-Bank finances the house and puts a lock on the transfer of NFT. Allow Transfers of the NFT require the mortgage to be paid off. Selling the ASSET (house) off-chain will be impossible, as it's no longer possible to finance the house.
 
-- **Selling a house with a lease:** A lease contract puts a lien on an ASSET's anchored NFT. The old owner removes the lock, the new owner buys and refinances the house. Transfer of NFT will also transfer the obligations and benefits of the lien to the new owner. As a lien-interface, the proposed EIP can for example be extended with [ERC-5604](eip-5604.md)
+- **Selling a house with a lease:** A lease contract puts a lien on an ASSET's anchored NFT. The old owner removes the lock, the new owner buys and refinances the house. Transfer of NFT will also transfer the obligations and benefits of the lien to the new owner.
 
 - **Buying a brand new car with downpayment:** A buyer configures a car and provides a downpayment, for a car that will have an ANCHOR. As long as the car is not produced, the NFT can float and be traded on NFT market places. The owner of the NFT at time of delivery of the ASSET has the the permission to pick up the car and the obligation to pay full price.
 
 - **Buying a barrel of oil by forward transaction:** A buyer buys an oil option on a forward contract for one barrel of oil (ASSET). On maturity date the buyer has the obligation to pick up the oil.
 
 The use case matrix below shows which extensions and settings must (additionally to `IERC6956`!) be implemented for the example use-cases together with relevant configurations.
 
-Note that for `Lockable` listed in the table below, the proposed EIP can be extended with any Lock- or Lien-Mechanism known to extend for ERC-721. Suitable extensions to achieve `Lockable` are for example [ERC-5058](eip-5058.md) or [ERC-5753](eip-5753.md). We recommend to verify whether a token is locked in the `_beforeTokenTransfer()`-hook, as this is called from `safeTransferFrom()` as well as `transferAnchor()`, hence suitable to block "standard" ERC-721 transfers as well as the proposed attestation-based transfers.
+Note that for `Lockable` listed in the table below, the proposed EIP can be extended with any Lock- or Lien-Mechanism known to extend for ERC-721, for example [ERC-6982](eip-6982.md). We recommend to verify whether a token is locked in the `_beforeTokenTransfer()`-hook, as this is called from `safeTransferFrom()` as well as `transferAnchor()`, hence suitable to block "standard" ERC-721 transfers as well as the proposed attestation-based transfers.
 
 | Use Case | approveAuthorization | burnAuthorization | `IERC6956Floatable` | `IERC6956AttestationLimited` | Lockable |
 |---------------|---|---|---|---|---|
@@ -562,8 +562,6 @@ Legend:
 
 ## Backwards Compatibility
 
-<!-- NEEDS FURTHER DISCUSSION -->
-
 No backward compatibility issues found. 
 
 This EIP is fully compatible with ERC-721 and (when extended with the `IERC6956Floatable`-interface) corresponds to the well-known ERC-721 behavior with an additional authorization-mechanism via attestations. Therefore we recommend - especially for physical assets - to use the present EIP instead of ERC-721 and amend it with extensions designed for ERC-721.
@@ -589,8 +587,6 @@ Test cases are available:
 
 ## Security Considerations
 
-<!-- NEEDS FURTHER DISCUSSION -->
-
 **If the asset is stolen, does this mean the thief has control over the NFT?**
 Yes.The standard aims to anchor an NFT to the asset inseperably and unconditionally. This includes reflecting theft, as the ORACLE will testify that PROOF-OF-CONTROL over the ASSET is established. The ORACLE does not testify whether the controller is the legitimate owner,
 Note that this may even be a benefit. If the thief (or somebody receiving the asset from the thief) should interact with the anchor, an on-chain address of somebody connected to the crime (directly or another victim) becomes known. This can be a valuable starting point for investigation.
@@ -631,22 +627,6 @@ In case the ASSET is a physical object, good or property, the following ADDITION
 - Is RECOMMENDED to employ ANCHOR-TECHNOLOGIES featuring irreproducible security features.
 - In general it is NOT RECOMMENDED to employ ANCHOR-TECHNOLOGIES that can easily be replicated (for example barcodes, "ordinary" NFC chips, .. ). Replication includes physical and digital replication.
 
-
-
-### Security Considerations for DIGITAL ASSETS
-
-<!-- NEEDS DISCUSSION -->
-
-<!--
-- TODO formal definition, shall extend to digital-only AND abstract assets (for example memberships)
-- Maybe use Physical and non-physical assets (to extend to abstract assets)?
-- Requirements on Oracles and Proof-of-Control for Digital ASSETs will not be defined in this EIP
-- Valid anchors
-  - Outline merkle-tree salt leaves
-  - Why using merkle-trees and not simply store all available anchors on-chain (besides memory issues)
-- Maintenance-role over using ownership (Ownable is used by marketplaces to manage the collection)
--->
-
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).