ERC-7231 Identity Aggregated NFT (Identity-aggregated NFT)

Final · Signatures & auth · created 2023-06-25

An ERC-721 extension standard that binds multiple Web2 and Web3 account identities to an NFT with the owner's approval and makes that binding verifiable onchain.

Why it is needed

Web3 has the advantage that individuals can own their accounts without a central administrator and present only the information they choose to multiple apps. However, existing solutions have limits. Naming services such as ENS are open and decentralized, but they lack data standardization and their inherent anonymity makes identity authentication difficult. Soulbound tokens (SBTs) depend on centralized attesters, cannot prevent data tampering, and cannot record data on the ledger in a privacy-preserving way. As a result, an individual's Web2 accounts and Web3 addresses stay scattered, which makes it hard to use an aggregated identity onchain. This standard solves the problem by binding an aggregation of Web2 and Web3 identities, approved directly by the individual, to an NFT (including SBTs).

In depth

ERC-721 Extension and Metadata Schema

This standard adds a set of extension functions to ERC-721, so it is fully compatible with ERC-721. It requires ERC-165, ERC-721, and ERC-1271. In addition to name, description, and image, the metadata JSON adds a MultiIdentities array. Each entry consists of userID, which holds a Web2 platform account or a decentralized identity (DID) created on a blockchain; verifierUri, the verifier address for that userID; memo, a memo; and properties, an attribute object for the user ID information. With this schema, the NFT ID and the UserIDInfo array are bound together, so multiple identities can be aggregated seamlessly.

setIdentitiesRoot and getIdentitiesRoot

setIdentitiesRoot(id, identitiesRoot) binds the multi-userID root data hash to the NFT ID, stores it, and emits the SetIdentitiesRoot event. It MUST allow external calls. getIdentitiesRoot(id) MUST return the multiUserIDsRoot in bytes32 format for the NFT ID, MUST NOT change state, and MUST allow external calls. After the user sets the metadata, this function creates a secure binding between the hashed bundle of userIDs and the NFT ID. Only the user has the authority to perform this binding, so the data is guaranteed to belong solely to the user.

Four-Step Verification in verifyIdentitiesBinding

verifyIdentitiesBinding takes the NFT ID, the NFT owner address, the list of userIDs to check, identitiesRoot (the message hash to verify), and an ECDSA signature. Using the ERC-1271 protocol-based signature scheme, it verifies the onchain and offchain binding between the userIDs and the NFT owner address, specifically performing 1) NFT ownership verification, 2) userID format verification, 3) identitiesRoot consistency verification, and 4) verification of the NFT owner's signature. It MUST return true if verification passes and false otherwise, MUST NOT change state, and MUST allow external calls.

Differences from Existing Solutions

ENS is open and decentralized, which is convenient for Ethereum-based apps, but it lacks data standardization and its inherent anonymity makes identity authentication difficult. Other solutions such as SBTs depend on centralized attesters, cannot prevent data tampering, and do not record data on the ledger itself in a privacy-preserving way. This standard widens the boundary of identity solutions with the Identity Aggregated NFT, which binds an aggregation of Web2 and Web3 identities authenticated directly by the individual to an NFT (including SBTs).

Verifying Identity Authenticity Is Outside the Standard

This standard does not define how to verify the authenticity of an individual's identity, wallet, or accounts. The original text only states that there are various methods, including onchain methods such as zk-based DID onchain authentication and offchain authentication algorithms such as auth2 and openID2. In other words, this standard provides a framework for binding authenticated identity information to an NFT and verifying that binding, and leaves the authentication itself to implementations.

Things to watch out for

Original ERC · ← ERCs