305 lines
14 KiB
Markdown
305 lines
14 KiB
Markdown
---
|
|
eip: 5375
|
|
title: NFT Author Information and Consent
|
|
description: An extension of EIP-721 for NFT authorship and author consent.
|
|
author: Samuele Marro (@samuelemarro), Luca Donno (@lucadonnoh)
|
|
discussions-to: https://ethereum-magicians.org/t/eip-5375-nft-authorship/10182
|
|
status: Final
|
|
type: Standards Track
|
|
category: ERC
|
|
created: 2022-07-30
|
|
requires: 55, 155, 712, 721, 1155
|
|
---
|
|
|
|
## Abstract
|
|
|
|
This EIP standardizes a JSON format for storing off-chain information about NFT authors. Specifically, it adds a new field which provides a list of author names, addresses, and proofs of _authorship consent_: proofs that the authors have agreed to be named as authors. Note that a proof of authorship _consent_ is not a proof of authorship: an address can consent without having authored the NFT.
|
|
|
|
## Motivation
|
|
|
|
There is currently no standard to identify authors of an NFT, and existing techniques have issues:
|
|
|
|
- Using the mint `tx.origin` or `msg.sender`
|
|
- Assumes that the minter and the author are the same
|
|
- Does not support multiple authors
|
|
- Using the first Transfer event for a given ID
|
|
- Contract/minter can claim that someone else is the author without their consent
|
|
- Does not support multiple authors
|
|
- Using a custom method/custom JSON field
|
|
- Requires per-contract support by NFT platforms
|
|
- Contract/minter can claim that someone else is the author without their consent
|
|
|
|
The first practice is the most common. However, there are several situations where the minter and the author might not be the same, such as:
|
|
|
|
- NFTs minted by a contract
|
|
- Lazy minting
|
|
- NFTs minted by an intermediary (which can be particularly useful when the author is not tech-savvy and/or the minting process is convoluted)
|
|
|
|
This document thus defines a standard which allows the minter to provide authorship information, while also preventing authorship claims without the author's consent.
|
|
|
|
## 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.
|
|
|
|
All addresses used in this standard MUST follow the casing rules described in [EIP-55](./eip-55.md).
|
|
|
|
### Definitions
|
|
|
|
- **Authors**: creators of an NFT
|
|
- **Minter**: entity responsible for the actual minting transaction; the minter and the authors MAY be the same
|
|
- **Verifier**: entity that wants to verify the authorship of an NFT (e.g. a user or an NFT marketplace)
|
|
- **Author Consent Proof (ACP)**: a signed message that proves that the signer agrees to be considered the author of the NFT
|
|
|
|
### Authorship Support
|
|
|
|
The standard introduces a new JSON field, named `authorInfo`. It provides a REQUIRED interface for authorship claiming, as well as an OPTIONAL interface for author consent proofs.
|
|
|
|
`authorInfo` is a top-level field of the NFT metadata. Specifically:
|
|
|
|
- If a contract supports the metadata extension for [EIP-721](./eip-721.md), the JSON document pointed by `tokenURI(uint256 _tokenId)` MUST include the top-level field `authorInfo`
|
|
- If a contract supports the metadata extension for [EIP-1155](./eip-1155.md), the JSON document pointed by `uri(uint256 _id)` MUST include a top-level field `authorInfo`
|
|
|
|
The JSON schema of `authorInfo` (named `ERC5375AuthorInfoSchema`) is defined as follows:
|
|
|
|
```json
|
|
{
|
|
"type": "object",
|
|
"properties": {
|
|
"consentInfo": {
|
|
"type": "object",
|
|
"description": "Helper fields for consent verification",
|
|
"properties": {
|
|
"chainId": {
|
|
"type": "integer",
|
|
"description": "EIP-155 chain id"
|
|
},
|
|
"id": {
|
|
"type": "string",
|
|
"description": "NFT id"
|
|
},
|
|
"contractAddress": {
|
|
"type": "string",
|
|
"description": "0x-prefixed address of the smart contract"
|
|
}
|
|
}
|
|
},
|
|
"authors": {
|
|
"type": "array",
|
|
"items": "ERC5375AuthorSchema"
|
|
}
|
|
},
|
|
"required": [ "authors" ]
|
|
}
|
|
```
|
|
|
|
Note that `authors` MAY be an empty array.
|
|
|
|
`ERC5375AuthorSchema` is defined as follows:
|
|
|
|
```json
|
|
{
|
|
"type": "object",
|
|
"properties": {
|
|
"address": {
|
|
"type": "string",
|
|
"description": "0x-prefixed address of the author"
|
|
},
|
|
"consent": {
|
|
"type": "ERC5375AuthorConsentSchema",
|
|
"description": "Author consent information"
|
|
}
|
|
},
|
|
"required": [ "address" ]
|
|
}
|
|
```
|
|
|
|
Moreover, if the `consent` field is present, the `consentInfo` field of `authorInfo` MUST be present.
|
|
|
|
`ERC5375AuthorConsentSchema` is defined as follows:
|
|
|
|
```json
|
|
{
|
|
"type": "object",
|
|
"properties": {
|
|
"consentData": {
|
|
"type": "object",
|
|
"properties": {
|
|
"version": {
|
|
"type": "string",
|
|
"description": "NFT authorship consent schema version"
|
|
},
|
|
"issuer": {
|
|
"type": "string",
|
|
"description": "0x-prefixed address of the author"
|
|
},
|
|
"metadataFields": {
|
|
"type": "object"
|
|
}
|
|
},
|
|
"required": ["version", "issuer", "metadataFields"]
|
|
},
|
|
"publicKey": {
|
|
"type": "string",
|
|
"description": "EVM public key of the author"
|
|
},
|
|
"signature": {
|
|
"type": "string",
|
|
"description": "EIP-712 signature of the consent message"
|
|
}
|
|
},
|
|
"required": ["consentData", "publicKey", "signature"]
|
|
}
|
|
```
|
|
|
|
where `metadataFields` is an object containing the JSON top-level fields (excluding `authorInfo`) that the author will certify. Note that the keys of `metadataFields` MAY be a (potentially empty) subset of the set of fields.
|
|
|
|
`consentData` MAY support additional fields as defined by other EIPs. `consentData` MUST contain all the information (which is not already present in other fields) required to verify the validity of an authorship consent proof.
|
|
|
|
### Author Consent
|
|
|
|
Consent is obtained by signing an [EIP-712](./eip-712.md) compatible message. Specifically, the structure is defined as follows:
|
|
|
|
```solidity
|
|
struct Author {
|
|
address subject;
|
|
uint256 tokenId;
|
|
string metadata;
|
|
}
|
|
```
|
|
|
|
where `subject` is the address of the NFT contract, `tokenId` is the id of the NFT and `metadata` is the JSON encoding of the fields listed in `metadataFields`. `metadata`:
|
|
|
|
- MUST contain exactly the same fields as the ones listed in `metadataFields`, in the same order
|
|
- MUST escape all non-ASCII characters. If the escaped character contains hexadecimal letters, they MUST be uppercase
|
|
- MUST not contain any whitespace that is not part of a field name or value
|
|
|
|
For example, if the top-level JSON fields are:
|
|
|
|
```json
|
|
{
|
|
"name": "The Holy Hand Grenade of Antioch",
|
|
"description": "Throw in the general direction of your favorite rabbit, et voilà",
|
|
"damage": 500,
|
|
"authors": [...],
|
|
...
|
|
}
|
|
```
|
|
|
|
and the content of `metadataFields` is `["name", "description"]`, the content of `metadata` is:
|
|
|
|
```json
|
|
{
|
|
"name": "The Holy Hand Grenade of Antioch",
|
|
"description": "Throw in the general direction of your favorite rabbit, et voil\u00E0"
|
|
}
|
|
```
|
|
|
|
Similarly to `consentData`, this structure MAY support additional fields as defined by other EIPs.
|
|
|
|
The domain separator structure is
|
|
|
|
```solidity
|
|
struct EIP712Domain {
|
|
string name;
|
|
string version;
|
|
uint256 chainId;
|
|
}
|
|
```
|
|
|
|
where `name` and `version` are the same fields described in `consentData`
|
|
|
|
This structure MAY support additional fields as defined by other EIPs.
|
|
|
|
### Author Consent Verification
|
|
|
|
Verification is performed using EIP-712 on an author-by-author basis. Specifically, given a JSON document D1, a consent proof is valid if all of the following statements are true:
|
|
|
|
- D1 has a top-level `authorInfo` field that matches `ERC5375AuthorInfoSchema`
|
|
- `consent` exists and matches `ERC5375AuthorConsentSchema`;
|
|
- If calling `tokenURI` (for EIP-721) or `uri` (for EIP-1155) returns the URI of a JSON document D2, all the top-level fields listed in `metadataFields` MUST exist and have the same value;
|
|
- The EIP-712 signature in `signature` (computed using the fields specified in the JSON document) is valid;
|
|
|
|
Verifiers MUST NOT assume that an NFT with a valid consent proof from address X means that X is the actual author. On the other hand, verifiers MAY assume that if an NFT does not provide a valid consent proof for address X, then X is not the actual author.
|
|
|
|
## Rationale
|
|
|
|
### Why provide only an author consent proof?
|
|
|
|
Adding support for full authorship proofs (i.e. Alice is the author and no one else is the author) requires a protocol to prove that someone is the only author of an NFT.
|
|
In other words, we need to answer the question: "Given an NFT Y and a user X claiming to be the author, is X the original author of Y?".
|
|
|
|
For the sake of the argument, assume that there exists a protocol that, given an NFT Y, can determine the original author of Y. Even if such method existed, an attacker could slightly modify Y, thus obtaining a new NFT Y', and rightfully claim to be the author of Y', despite the fact that it is not an original work. Real-world examples include changing some pixels of an image or replacing some words of a text with synonyms.
|
|
Preventing this behavior would require a general formal definition of when two NFTs are semantically equivalent. Even if defining such a concept were possible, it would still be beyond the scope of this EIP.
|
|
|
|
Note that this issue is also present when using the minter's address as a proxy for the author.
|
|
|
|
### Why off-chain?
|
|
|
|
There are three reasons:
|
|
|
|
- Adding off-chain support does not require modifications to existing smart contracts;
|
|
- Off-chain storage is usually much cheaper than on-chain storage, thus reducing the implementation barrier;
|
|
- While there may be some use cases for full on-chain authorship proofs (e.g. a marketplace providing special features for authors), there are limited applications for on-chain author consent, due to the fact that it is mostly used by users to determine the subjective value of an NFT.
|
|
|
|
### Why repeat id, chainId and contractAddress?
|
|
|
|
In many cases, this data can be derived from contextual information. However, requiring their inclusion in the JSON document ensures that author consent can be verified using only the JSON document.
|
|
|
|
### Why not implement a revocation system?
|
|
|
|
Authorship is usually final: either someone created an NFT or they didn't. Moreover, a revocation system would impose additional implementation requirements on smart contracts and increase the complexity of verification. Smart contracts MAY implement a revocation system, such as the one defined in other EIPs.
|
|
|
|
#### Why escape non-ASCII characters in the signature message?
|
|
|
|
EIP-712 is designed with the possibility of on-chain verification in mind; while on-chain verification is not a priority for this EIP, non-ASCII characters are escaped due to the high complexity of dealing with non-ASCII strings in smart contracts.
|
|
|
|
### Usability Improvements for Authors
|
|
|
|
Since the author only needs to sign an EIP-712 message, this protocol allows minters to handle the technical aspects of minting while still preserving the secrecy of the author's wallet. Specifically, the author only needs to:
|
|
|
|
- Obtain an EVM wallet;
|
|
- Learn how to read and sign a EIP-712 message (which can often be simplified by using a Dapp)
|
|
|
|
without needing to:
|
|
|
|
- Obtain the chain's native token (e.g. through trading or bridging);
|
|
- Sign a transaction;
|
|
- Understand the pricing mechanism of transactions;
|
|
- Verify if a transaction has been included in a block
|
|
|
|
This reduces the technical barrier for authors, thus increasing the usability of NFTs, without requiring authors to hand over their keys to a tech-savvy intermediary.
|
|
|
|
### Limitations of Address-Based Consent
|
|
|
|
The standard defines a protocol to verify that a certain _address_ provided consent. However, it does not guarantee that the address corresponds to the expected author (such as the one provided in the `name` field). Proving a link between an address and the entity behind it is beyond the scope of this document.
|
|
|
|
## Backwards Compatibility
|
|
|
|
No backward compatibility issues were found.
|
|
|
|
## Security Considerations
|
|
|
|
### Attacks
|
|
|
|
A potential attack that exploits this EIP involves tricking authors into signing authorship consent messages against their wishes. For this reason, authors MUST verify that all signature fields match the required ones.
|
|
|
|
A more subtle approach involves not adding important fields to `metadataFields`. By doing so, the author signature might be valid even if the minter changes critical information.
|
|
|
|
### Deprecated Features
|
|
|
|
`ERC5375AuthorInfoSchema` also originally included a field to specify a human-readable name for the author (without any kind of verification). This was scrapped due to the high risk of author spoofing, i.e.:
|
|
|
|
- Alice mints an NFT using Bob's name and Alice's address
|
|
- Charlie does not check the address and instead relies on the provided name
|
|
- Charlie buys Alice's NFT while believing that it was created by Bob
|
|
|
|
For this reason, smart contract developers SHOULD NOT add support for unverifiable information to the JSON document. We believe that the most secure way to provide complex authorship information (e.g. the name of the author) is to prove that the information is associated with the _author's address_, instead of with the NFT itself.
|
|
|
|
### Replay Attack Resistance
|
|
|
|
The chain id, the contract address and the token id uniquely identify an NFT; for this reason, there is no need to implement additional replay attack countermeasures (e.g. a nonce system).
|
|
|
|
## Copyright
|
|
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|