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.
There is currently no standard to identify authors of an NFT, and existing techniques have issues:
tx.origin or msg.sender
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:
This document thus defines a standard which allows the minter to provide authorship information, while also preventing authorship claims without the author's consent.
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.
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:
tokenURI(uint256 _tokenId) MUST include the top-level field authorInfouri(uint256 _id) MUST include a top-level field authorInfoThe JSON schema of authorInfo (named ERC5375AuthorInfoSchema) is defined as follows:
Note that authors MAY be an empty array.
ERC5375AuthorSchema is defined as follows:
Moreover, if the consent field is present, the consentInfo field of authorInfo MUST be present.
ERC5375AuthorConsentSchema is defined as follows:
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.
Consent is obtained by signing an EIP-712 compatible message. Specifically, the structure is defined as follows:
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:
metadataFields, in the same orderFor example, if the top-level JSON fields are:
and the content of metadataFields is ["name", "description"], the content of metadata is:
Similarly to consentData, this structure MAY support additional fields as defined by other EIPs.
The domain separator structure is
where name and version are the same fields described in consentData
This structure MAY support additional fields as defined by other EIPs.
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:
authorInfo field that matches ERC5375AuthorInfoSchemaconsent exists and matches ERC5375AuthorConsentSchema;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;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.
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.
There are three reasons:
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.
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.
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.
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:
without needing to:
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.
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.
No backward compatibility issues were found.
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.
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.:
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.
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 and related rights waived via CC0.