NFT Author Information and Consent
Video
Original
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
ormsg.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.
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, the JSON document pointed by
tokenURI(uint256 _tokenId)
MUST include the top-level fieldauthorInfo
- If a contract supports the metadata extension for EIP-1155, the JSON document pointed by
uri(uint256 _id)
MUST include a top-level fieldauthorInfo
The JSON schema of authorInfo
(named ERC5375AuthorInfoSchema
) is defined as follows:
{ "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:
{ "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:
{ "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 compatible message. Specifically, the structure is defined as follows:
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:
{ "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:
{ "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
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 matchesERC5375AuthorInfoSchema
consent
exists and matchesERC5375AuthorConsentSchema
;- If calling
tokenURI
(for EIP-721) oruri
(for EIP-1155) returns the URI of a JSON document D2, all the top-level fields listed inmetadataFields
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.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all