This standard is an extension of ERC-721 that adds verifiable credential properties at the contract level. A verifiable credential is a secure digital certificate that encapsulates claims issued by a trusted authority and is designed to be tamper-evident and readily verifiable. It allows ERC-721 tokens to natively reference and manage these credentials—as well as other types of off-chain data—by defining mechanisms for storage, encryption, revocation, and verification.
Many ERC-721 contracts require additional properties to represent verifiable credentials. While it's possible to implement these properties in various ways, it creates an extra effort for third-party platforms to build individualized solutions for each NFT collection.
Having a standard for verifiable credential properties will make it easier for third-party platforms to interact with and validate NFTs that represent verifiable credentials onchain.
Just as NFTs represent digital ownership, verifiable credentials (VCs) represent digital attestations about oneself (identity, education, and more). Blockchains provide an ideal solution for storing VCs and associated claims, offering precise access control, issuer legitimacy, and full lifecycle management for credentials, all while maintaining transparency to safeguard user rights.
This standard addresses key gaps in the W3C framework by defining methods for storage, revocation, retrieval, and presentation, facilitating interoperability within a flexible, standardized structure. It supports custom cryptographic methods for signatures and proofs—from basic issuer signatures to advanced zero-knowledge (ZK) proofs and selective disclosure—allowing adaptability for diverse security requirements.
Additionally, the standard natively supports encryption, crucial for managing sensitive data. It also provides flexibility in credential storage, referencing off-chain data via credentialURI() to accommodate any storage solution, from decentralized storage (like IPFS) to centralized systems.
Originally designed with W3C credentials in mind, this standard is broad enough to support any kind of credential, for example content credentials. More generally this framework can be used to link any off-chain, private payload to an NFT.
This extension aims to provide a standardized way to represent verifiable credentials within the ERC-721 framework. The collection-wide properties (issuer and type) allow for efficient management of credentials where these properties are shared across all tokens in the collection.
The credentialURI function is included to provide a way to retrieve additional off-chain information about individual credentials, similar to the tokenURI function in ERC-721.
By emitting CredentialIssued and CredentialRevoked events, third-party applications and services can track the lifecycle of credentials, enabling real-time monitoring.
Each NFT in this standard is linked to a credential that can be stored in any compatible storage location. To retrieve credentials for a specific user, is sufficient to get the desired credential NFT in their wallet, and the credentialURI() function can provide the exact location of each credential. This URI may point to public storage like IPFS or any custom storage solution with flexible access control, potentially subject to user approval.
Upon retrieval, credentials may be stored in clear text or in encrypted form. The encryptionMethod() property indicates the encryption status, allowing the verifier to know in advance if decryption is required. Decryption may involve user consent if the user's wallet signature is required. Additional steps can be added in cases where advanced algorithms enable selective disclosure or zero-knowledge (ZK) proofs to enhance privacy.
Once decrypted, the credential's authenticity and integrity can be verified using the verificationMethod(), ensuring it remains untampered. For ZK proofs, specific queries can also be verified without disclosing the entire credential. The standard also accounts for credential revocation, which can be implemented in various ways: via burning the associated NFT, an additional structure in the contract or even an off-chain revocation list; in the first case, checking that the NFT is unburned confirms the credential's validity.
While originally intended for verifiable credentials, this standard's flexibility allows it to link any private or external data payload to a user's wallet through an NFT, expanding its utility across various data-reference use cases.
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.
The issuer(), credentialType(), encryptionMethod(), verificationMethod() and credentialURI(uint256 tokenId) functions MUST be implemented as view functions.
The encryptionMethod() function MUST return an empty string if and only if the credential is unencrypted. In case of encrypted credentials the method SHOULD return only the encryption method; Any additional encryption details required for decryption MAY be retrieved separately (a separate function or via the contract metadata).
The verificationMethod() function MUST return the method to verify the credential proof, the response is up to the implementer but SHOULD be compatible with the W3C verification method concept.
The credentialURI(uint256 tokenId) function MAY be used to retrieve the credential location. In case a given implementation uses a different method to retrieve the credential, credentialURI(uint256 tokenId) MUST return an empty string.
The supportsInterface ERC-165 method MUST return true when called with 0x7861069.
The isRevoked(uint256 tokenId) MUST return false if the credential has not been revoked, and MUST return true if the credential has been revoked. MAY return true if the credential does not exist.
The CredentialIssued and CredentialRevoked events MAY be emitted, when the corresponding operations are performed, to allow off-chain systems to monitor credential status efficiently. Credential revocation is not mandated, but MAY be implemented via burning the associated NFT.
This standard is compatible with current ERC-721 standards. It adds new functions without modifying the existing ERC-721 functionality.
Implementers of the ERC-7861 standard must enforce strict access control to ensure only authorized parties can issue or revoke credentials. Implementers must also carefully consider access control for setting credential properties, protecting the integrity of the collection's credential information.
Credentials should be non-transferable to maintain authenticity and prevent unauthorized transfers. Override transfer functions to enforce this if needed.
The credentialURI should not contain sensitive information, as it is publicly accessible. Sensitive data should be encrypted and stored off-chain, with the credentialURI pointing to the location of this encrypted data; encryption is essential for any sensitive data stored on public storage solutions like IPFS.
Copyright and related rights waived via CC0.