ERC-5375 NFT author information and consent standard (NFT Author Information and Consent)
Final · NFTs & multi-token · created 2022-07-30
Defines a JSON format that carries, in NFT metadata, a list of author addresses and a signed proof that the author 'consents to be listed as an author'. It lets author information be provided in a standard way even when the person who minted differs from the actual author.
Why it is needed
Until now there has been no standard that tells who the author of an NFT is. The address that sent the minting (issuance) transaction is commonly treated as the author, but this assumes the minter and the author are the same, so it fails when a contract mints, in lazy minting, and when an intermediary mints on behalf of an author who is not comfortable with technology, and it cannot represent multiple authors either. Other approaches are to look at the first Transfer event or to use custom fields that differ per contract, but with these a contract or minter can claim that someone else is the author without their consent, and NFT platforms have to support each contract separately. This standard defines a common format in which the minter provides author information but cannot list someone as an author without the author's own signed consent.
What to implement
struct Author { address subject; uint256 tokenId; string metadata; }: The structure of the EIP-712 consent message the author signs. subject is the NFT contract address, tokenId is the NFT id, and metadata is the JSON encoding of the fields listed in metadataFields.struct EIP712Domain { string name; string version; uint256 chainId; }: The EIP-712 domain separator structure. name and version are the same as the values written in consentData, and chainId distinguishes the chain.
In depth
The authorInfo field and schema
A contract that supports the EIP-721 metadata extension must include the top-level field authorInfo in the JSON that tokenURI(uint256 _tokenId) points to, and an EIP-1155 contract must include it in the JSON that uri(uint256 _id) points to. authorInfo consists of an authors array (required, may be empty) and a consentInfo object (chainId, id, contractAddress). In each author entry (ERC5375AuthorSchema), address is required and consent is optional. If consent is present, consentInfo must also be present. consent (ERC5375AuthorConsentSchema) requires consentData (version, issuer and metadataFields are required), publicKey and signature. All addresses must follow the EIP-55 checksum format.
The EIP-712 consent message and metadata encoding rules
Consent is expressed by signing an EIP-712 message of the form struct Author { address subject; uint256 tokenId; string metadata; }. metadata is the JSON encoding of the top-level fields listed in metadataFields. It must contain exactly the listed fields, in the same order. All non-ASCII characters must be escaped, with hexadecimal letters written in uppercase, and no whitespace may be inserted that does not belong to a field name or value. The keys of metadataFields may be a subset of all fields, including the empty set. The domain separator consists of name, version and chainId, and consentData and the message structure may support additional fields defined by other EIPs.
Verification procedure and limits of interpretation
Verification is performed per author using EIP-712. A consent proof is valid if the JSON document has an authorInfo that conforms to ERC5375AuthorInfoSchema, the consent conforms to ERC5375AuthorConsentSchema, every top-level field in metadataFields exists with the same value in the document that tokenURI or uri points to, and the EIP-712 signature in signature is valid. A verifier must not assume that X is the actual author just because a valid consent proof for address X exists. Conversely, if there is no valid consent proof for X, it may assume that X is not an author.
Why consent proof instead of full authorship proof
Even if we assume a protocol existed that determines whether X is the sole original author of Y, an attacker could create a slightly modified Y', for example by changing a few image pixels or replacing words with synonyms, and then legitimately claim to be the author of Y'. Preventing this would require a general formal definition of whether two NFTs are semantically the same, which is outside the scope of this EIP. The same problem exists in the current practice of treating the minter address as the author. For that reason, this standard only proves the fact that "this address consented to being listed as an author."
Why off-chain storage
The off-chain approach does not require modifying existing smart contracts and is much cheaper than on-chain storage, which lowers the barrier to adoption. Author consent information is also mainly used by users to judge the subjective value of an NFT, so its on-chain uses are limited. The chainId, id and contractAddress in consentInfo could be derived from context, but they are required so that consent can be verified from the JSON document alone. No revocation system is included, because authorship is usually final and a revocation system increases implementation burden and verification complexity. A contract can still implement the revocation system of another EIP.
Lowering the technical barrier for authors
An author only needs to know how to create an EVM wallet and how to read and sign an EIP-712 message. They do not need to acquire the chain's native token, sign a transaction, understand how fees are priced, or check whether a transaction was included in a block. This lets an author leave the technical parts of minting to the minter without handing their keys to an intermediary. However, this standard only verifies which addresses consented, and does not guarantee that an address is linked to the expected author (for example, a person known by name).
Replay attacks and removal of the name field
The chain id, contract address and token id uniquely identify an NFT, so no additional replay protection such as a nonce is needed. The initial design had an unverified, human-readable author name field, but it was removed because the risk of spoofing, where someone mints using another person's name, was too high. Linking complex author information to the author's address rather than to the NFT is considered the safest way to prove it. Non-ASCII characters are escaped because handling non-ASCII strings in smart contracts is very complex, and escaping keeps on-chain verification possible.
Things to watch out for
- Signature solicitation attack: An author can be tricked into signing a consent message they did not intend to sign. Before signing, the author must check that every signed field matches the required values.
- metadataFields omission attack: If an important field is not included in metadataFields, the minter can change key information and the author's signature may still remain valid.
- Do not add unverifiable information: Adding information such as an unverified author name to the JSON carries a high risk of name spoofing. Developers must not support information that cannot be verified.