EIP-2477: Non-Fungible Token Metadata Integrity.md #2477

fulldecent · 2020-01-19T17:35:41Z

No description provided.

coinfork · 2020-01-20T03:13:43Z

EIPS/eip-2477.md

+
+## Abstract
+
+An interface `ERC2477` with two functions `tokenURIIntegrity` and ``tokenURISchemaIntegrity` are specified for smart contracts and a narrative is provided to explain how this improves the integrity of the token metadata documents.


Syntax: ``tokenURISchemaIntegrity->tokenURISchemaIntegrity`

coinfork · 2020-01-20T03:55:37Z

EIPS/eip-2477.md

+* ERC-1155 metadata extension (`ERC1155Metadata_URI`)
+* ERC-1046 (DRAFT) ERC-20 Metadata Extension
+
+Although all these standards allow storing the metadata entirely on-chain (using the "data" URI, RFC 2397), or using a content-addressible system (e.g. IPFS's Content IDentifiers [sic]), every implementation we have found is using Uniform Resource Locators. These URLs provide no guarantees of content correctness or immutability. This standard adds such guarantees.


Spelling: addressible => addressable

coinfork · 2020-01-20T04:00:05Z

EIPS/eip-2477.md

+/// @dev The ERC-165 identifier for this interface is 0x#######. //TODO: FIX THIS
+interface ERC2477 /* is ERC165 */ {
+    /**
+     * @notice Get a cryptographic hash for the specificed token metadata


Spelling: specificed -> specified
Suggest rewriting to:
* @notice Get the cryptographic hash of the specified tokenID's metadata

coinfork · 2020-01-20T04:02:15Z

EIPS/eip-2477.md

+    function tokenURIIntegrity(uint256 tokenId) external view returns(bytes digest, string hashAlgorithm);
+
+    /**
+     * @notice Get a cryptographic hash for the specificed token metadata's schema


Spelling: specificed -> specified
Suggest rewriting to:
* @notice Get the cryptographic hash of the specified tokenID's metadata schema

coinfork · 2020-01-20T04:11:00Z

EIPS/eip-2477.md

+
+**Function return tuple**
+
+The SRI integrity attribute encodes elements of the tuple $$(cryptographic\ hash\ function, digest, options)$$. This ERC-2477 standard returns a digest and hash function name and omits forward-compatability options.


Spelling: forward-compatability -> forward-compatibility

coinfork · 2020-01-20T04:17:56Z

EIPS/eip-2477.md

+
+Clients must support the SHA-256 algorithm may support others. This is a departure from the SRI specification here SHA-256, SHA-384 and SHA-512 are all required. The rationale for this less-secure requirement is because we expect some clients to be on-chain. Currently SHA-256 is simple and cheap to do on Ethereum whereas SHA-384 and SHA-512 are more expensive and cumbersome.
+
+The most popular hash function size below 256 bits in current use is SHA-1 at 160 bits. Multiple collissions (the "Shattered" PDF file, the 320 byte file, the chosen prefix) have been published and a recipe is given to generate infinitely more collisions. SHA-1 is broken. The United States National Institute of Standards and Technology (NIST) has first deprecated SHA-1 for certain use cases in November 2015 and has later further expanded this deprecation.


Spelling: collissions -> collisions

coinfork · 2020-01-20T04:21:38Z

EIPS/eip-2477.md

+
+## Backwards Compatibility
+
+Both ERC-721 and ERC-1155 provide compatible token metadata specifications built on top of URIs and using JSON schemas. This standard is compatible with both and all specifications are addititive. Therefore, there are no backwards compatability regressions.


Suggest rewrite to:
Both ERC-721 and ERC-1155 provide compatible token metadata specifications that use URIs and JSON schemas. The ERC-2477 standard is compatible with both, and all specifications are additive. Therefore, there are no backward compatibility regressions.

coinfork · 2020-01-20T04:28:08Z

EIPS/eip-2477.md

+
+Both ERC-721 and ERC-1155 provide compatible token metadata specifications built on top of URIs and using JSON schemas. This standard is compatible with both and all specifications are addititive. Therefore, there are no backwards compatability regressions.
+
+ERC-1523 Standard for Insurance Policies as ERC-721 Non Fungible Tokens (DRAFT) proposes an extension to ERC-721 which also tightens the requirements on metadata. Because this is wholly an extension of ERC-721 and this standard ERC-2477 already supports ERC-721 then therefore ERC-1523 is automatically supported.


Suggest rewrite to:
ERC-1523 Standard for Insurance Policies as ERC-721 Non Fungible Tokens (DRAFT) proposes an extension to ERC-721 which also tightens the requirements on metadata. Because it is wholly an extension of ERC-721, ERC-1523 is automatically supported by ERC-2477 (since this standard already supports ERC-721).

coinfork · 2020-01-20T04:30:54Z

EIPS/eip-2477.md

+
+```json
+{
+    "$schema": "https://URL_TO_SCHEMA_DOCUMENT",


$schema is not mentioned anywhere else in the standard, could this be expanded on or clarified to avoid confusion?

coinfork · 2020-01-20T04:33:20Z

EIPS/eip-2477.md

+}
+```
+
+Assume that the metadata and schema above apply to a token with identifier 1234. (In ERC-721 this would be a specific token, in ERC-1155 this would be a token type.) Then the these two function calls MAY have the following output:


Suggest rewrite to:
Assume that the metadata and schema above apply to a token with identifier 1234. (In ERC-721 this would be a specific token, in ERC-1155 this would be a token type). Then these two function calls MAY have the following output:

fulldecent · 2020-01-24T00:58:44Z

@coinfork Added all your updates at 2db9d46, thank you!

coinfork · 2020-01-24T00:59:50Z

@coinfork Added all your updates at 2db9d46, thank you!

Thanks a lot! Glad to be part of this.

MoMannn · 2020-01-24T10:48:07Z

EIPS/eip-2477.md

+     * @return digest Bytes returned from the hash algorithm
+     * @return hashAlgorithm The name of the cryptographic hash algorithm
+     */
+    function tokenURIIntegrity(uint256 tokenId) external view returns(bytes digest, string hashAlgorithm);


In returns add memory data location indicator.

Thank you, fixed in 8cdf3c7

MoMannn · 2020-01-27T10:06:15Z

EIPS/eip-2477.md

+/// @title ERC-2477 Non-Fungible Token Standard
+/// @dev See https://eips.ethereum.org/EIPS/eip-2477
+/// @dev The ERC-165 identifier for this interface is 0x#######. //TODO: FIX THIS
+interface ERC2477 /* is ERC165 */ {


Since the methods are per token should the methods throw if the tokenId does not exist or return a specific value. This should probably be defined.

721 says this:

/// @dev NFTs assigned to zero address are considered invalid, and queries /// about them do throw.

but 1155 does not have such a prescription.

I do not see an obvious way to specify this here yet. Please open this as a discussion item in the discussions-to.

…esource Locators

xpepermint · 2020-02-09T17:25:50Z

Are we good to go? Is there anything that's blocking this issue to be accepted as final?

xpepermint · 2020-02-11T22:00:56Z

@coinfork @MoMannn please approve this PR if there's nothing else to change. Thanks.

@coinfork

* Create eip-xxxx-Non-Fungible Token Metadata Integrity.md * Update EIP number * Update eip-2477.md * Add coauthor, with permission * Add wording updates from @coinfork * Fix spelling * Specify parameter storage * Qualify: nearly every implementation we have found is using Uniform Resource Locators * Add rationale for separate data field * Justify need for schema integrity * Remove "non-fungible" limiting word, make more general * Add reference to The Sandbox

@coinfork

* Create eip-xxxx-Non-Fungible Token Metadata Integrity.md * Update EIP number * Update eip-2477.md * Add coauthor, with permission * Add wording updates from @coinfork * Fix spelling * Specify parameter storage * Qualify: nearly every implementation we have found is using Uniform Resource Locators * Add rationale for separate data field * Justify need for schema integrity * Remove "non-fungible" limiting word, make more general * Add reference to The Sandbox

@coinfork

* Create eip-xxxx-Non-Fungible Token Metadata Integrity.md * Update EIP number * Update eip-2477.md * Add coauthor, with permission * Add wording updates from @coinfork * Fix spelling * Specify parameter storage * Qualify: nearly every implementation we have found is using Uniform Resource Locators * Add rationale for separate data field * Justify need for schema integrity * Remove "non-fungible" limiting word, make more general * Add reference to The Sandbox

fulldecent added 2 commits January 19, 2020 12:35

Create eip-xxxx-Non-Fungible Token Metadata Integrity.md

5de2027

Update EIP number

3e482f1

fulldecent changed the title ~~Create eip-xxxx-Non-Fungible Token Metadata Integrity.md~~ EIP-2477: Non-Fungible Token Metadata Integrity.md Jan 19, 2020

coinfork suggested changes Jan 20, 2020

View reviewed changes

Update eip-2477.md

512b602

MoMannn mentioned this pull request Jan 22, 2020

ERC-2477 the discussion #2483

Closed

fulldecent added 2 commits January 23, 2020 19:08

Add coauthor, with permission

6bc3589

Add wording updates from @coinfork

2db9d46

Arachnid approved these changes Jan 24, 2020

View reviewed changes

MoMannn suggested changes Jan 24, 2020

View reviewed changes

MoMannn reviewed Jan 27, 2020

View reviewed changes

fulldecent added 2 commits January 27, 2020 22:18

Fix spelling

6c646f5

Specify parameter storage

8cdf3c7

xpepermint mentioned this pull request Feb 4, 2020

ERC-2477 0xcert/framework#663

Merged

fulldecent added 5 commits February 4, 2020 16:45

Qualify: nearly every implementation we have found is using Uniform R…

a5fb2a4

…esource Locators

Add rationale for separate data field

cdc046b

Justify need for schema integrity

25cdb07

Remove "non-fungible" limiting word, make more general

3518f30

Add reference to The Sandbox

e29147b

Arachnid approved these changes Feb 12, 2020

View reviewed changes

Arachnid merged commit 66e1f04 into ethereum:master Feb 12, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

EIP-2477: Non-Fungible Token Metadata Integrity.md #2477

EIP-2477: Non-Fungible Token Metadata Integrity.md #2477

fulldecent commented Jan 19, 2020

coinfork Jan 20, 2020

coinfork Jan 20, 2020

coinfork Jan 20, 2020

coinfork Jan 20, 2020

coinfork Jan 20, 2020

coinfork Jan 20, 2020

coinfork Jan 20, 2020

coinfork Jan 20, 2020

coinfork Jan 20, 2020

coinfork Jan 20, 2020

fulldecent commented Jan 24, 2020

coinfork commented Jan 24, 2020

MoMannn Jan 24, 2020

fulldecent Jan 28, 2020

MoMannn Jan 27, 2020

fulldecent Jan 28, 2020

xpepermint commented Feb 9, 2020

xpepermint commented Feb 11, 2020


		## Abstract

		An interface `ERC2477` with two functions `tokenURIIntegrity` and ``tokenURISchemaIntegrity` are specified for smart contracts and a narrative is provided to explain how this improves the integrity of the token metadata documents.


		Function return tuple

		The SRI integrity attribute encodes elements of the tuple $$(cryptographic\ hash\ function, digest, options)$$. This ERC-2477 standard returns a digest and hash function name and omits forward-compatability options.


		Clients must support the SHA-256 algorithm may support others. This is a departure from the SRI specification here SHA-256, SHA-384 and SHA-512 are all required. The rationale for this less-secure requirement is because we expect some clients to be on-chain. Currently SHA-256 is simple and cheap to do on Ethereum whereas SHA-384 and SHA-512 are more expensive and cumbersome.

		The most popular hash function size below 256 bits in current use is SHA-1 at 160 bits. Multiple collissions (the "Shattered" PDF file, the 320 byte file, the chosen prefix) have been published and a recipe is given to generate infinitely more collisions. SHA-1 is broken. The United States National Institute of Standards and Technology (NIST) has first deprecated SHA-1 for certain use cases in November 2015 and has later further expanded this deprecation.


		## Backwards Compatibility

		Both ERC-721 and ERC-1155 provide compatible token metadata specifications built on top of URIs and using JSON schemas. This standard is compatible with both and all specifications are addititive. Therefore, there are no backwards compatability regressions.


		Both ERC-721 and ERC-1155 provide compatible token metadata specifications built on top of URIs and using JSON schemas. This standard is compatible with both and all specifications are addititive. Therefore, there are no backwards compatability regressions.

		ERC-1523 Standard for Insurance Policies as ERC-721 Non Fungible Tokens (DRAFT) proposes an extension to ERC-721 which also tightens the requirements on metadata. Because this is wholly an extension of ERC-721 and this standard ERC-2477 already supports ERC-721 then therefore ERC-1523 is automatically supported.

EIP-2477: Non-Fungible Token Metadata Integrity.md #2477

EIP-2477: Non-Fungible Token Metadata Integrity.md #2477

Conversation

fulldecent commented Jan 19, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fulldecent commented Jan 24, 2020

coinfork commented Jan 24, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xpepermint commented Feb 9, 2020

xpepermint commented Feb 11, 2020