EIP 1523: Standard for storing insurance policies as extension of ERC…

…-721 token (ethereum#1512)

EIPS/eip-1523.md

@@ -0,0 +1,129 @@
+---
+eip: 1523
+title: Standard for Insurance Policies as ERC-721 Non Fungible Tokens
+author: Christoph Mussenbrock (@christoph2806)
+discussions-to: https://github.com/ethereum/EIPs/issues/1523
+status: Draft
+type: Standards Track
+category: ERC
+created: 2018-10-10
+requires: 721
+---
+
+## Simple Summary
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
+A standard interface for insurance policies, based on ERC 721.
+
+## Abstract
+<!--A short (~200 word) description of the technical issue being addressed.-->
+The following standard allows for the implementation of a standard API for insurance policies within smart contracts.
+Insurance policies are financial assets which are unique in some aspects, as they are connected to a customer, a specific risk, or have other unique properties like premium, period, carrier, underwriter etc.
+Nevertheless, there are many potential applications where insurance policies can be traded, transferred or otherwise treated as an asset.
+The ERC 721 standard already provides the standard and technical means to handle policies as a specific class of non fungible tokens.
+insurance In this proposal, we define a minimum metadata structure with properties which are common to the greatest possible class of policies.
+
+## Motivation
+<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
+For a decentralized insurance protocol, a standard for insurance policies is crucial for interoperability of the involved services and application.
+It allows policies to be bundled, securitized, traded in a uniform and flexible way by many independent actors like syndicates, brokers, and insurance companies.
+
+## Specification
+<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
+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.
+
+An ERC-1523 compliant insurance policy is a non-fungible token which **MUST adhere to the ERC-721 token standard** and **MUST implement theERC721Metadata and the ERC721Enumerable interface**:
+
+```solidity
+/// @title ERC-1523 Insurance Policy Standard
+///  Note: the ERC-165 identifier for this interface is 0x5a04be32
+interface ERC1523 /* is ERC721, ERC721Metadata, ERC721Enumerable */ {
+
+}
+```
+
+The implementor MAY choose values for the ```name``` and ```symbol```.
+
+The **policy metadata extension** is **RECOMMENDED** for ERC-1523 smart contracts. 
+This allows your smart contract to be interrogated for policy metadata.
+
+```solidity
+/// @title ERC-1523 Insurance Policy Standard, optional policy metadata extension
+/// @dev See ...
+///  Note: the ERC-165 identifier for this interface is 0x5a04be32
+interface ERC1523PolicyMetadata /* is ERC1523 */ {
+
+    /// @notice Metadata string for a given property.
+    /// Properties are identified via hash of their property path.
+    /// e.g. the property "name" in the ERC721 Metadata JSON Schema has the path /properties/name
+    /// and the property path hash is the keccak256() of this property path. 
+    /// this allows for efficient addressing of arbitrary properties, as the set of properties is potentially unlimited.
+    /// @dev Throws if `_propertyPathHash` is not a valid property path hash. 
+    function policyMetadata(uint256 _tokenId, bytes32 _propertyPathHash) external view returns (string _property);
+
+}
+```
+
+In analogy to the “ERC721 Metadata JSON Schema”, the tokenURI **MUST** point to a JSON file with the following properties:
+```json
+{
+    "title": "Asset Metadata",
+    "type": "object",
+    "properties": {
+        "name": {
+            "type": "string",
+            "description": "Identifies the asset to which this NFT represents",
+        },
+        "description": {
+            "type": "string",
+            "description": "Describes the asset to which this NFT represents",
+        },
+        "carrier": {
+            "type": "string",
+            "description": "Describes the carrier which takes the primary risk",
+        },
+        "risk": {
+            "type": "string",
+            "description": "Describes the risk",
+        },
+        "parameters": {
+            "type": "string",
+            "description": "Describes further parameters characterizing the risk",
+        },
+        "status": {
+            "type": "string",
+            "description": "Defines the status of the policy, e.g. Applied, Underwritten, Claimed, Paid out, etc."
+        }
+    }
+}
+```
+
+## Rationale
+<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+Insurance policies form an important class of financial assets, and it is natural to express those assets as a class of non-fungible tokens which adhere to the established ERC-721 standard.
+We propose a standard for the accompanying metadata structures which are needed to uniquely define an insurance policy.
+While policies can have a multitude of possible properties, it is common that policies are issued by some entity, which is basically the entity responsible for paying out claims.
+Second, an insurance policy is typically related to a specific risk. Some risks are unique, but there are cases where many policies share the same risk
+(e.g. all flight delay policies for the same flight).
+In general, the relation of policies to risks is a many-to-one relation with the special case of a one-to-one relation.
+Third, most policies need more parameters to characterize the risk and other features, like premium, period etc.
+Forth, a policy has a lifecycle of different statuses. 
+We believe that those four properties are necessary to describe a policy. For many applications, those properties may be even sufficient. 
+However, any implementation **MAY** chose to implement more properties.
+
+### On-chain vs. off-chain metadata
+For some applications it will be sufficient to store the metadata in an off-chain repository or database which can be addressed by the tokenURI resource locator.
+For more advanced applications, it can be desirable to have metadata available on-chain. 
+Therefore, we require that the ```tokenURI``` **MUST** point to a JSON with the above structure, while the implementation of the ```policyMetadata``` function is **OPTIONAL**.
+
+
+## Backwards Compatibility
+<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
+
+## Test Cases
+<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
+
+## Implementation
+<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).