ERC-5851: On-Chain Verifiable Credentials
Interface for contracts that manage verifiable claims and identifiers as Soulbound tokens.
Abstract
This proposal introduces a method of certifying that a particular address meets a claim, and a method of verifying those certifications using on-chain metadata. Claims are assertions or statements made about a subject having certain properties that may be met conditions (for example: age >= 18), and are certified by issuers using a Soundbound Token (SBT).
Motivation
On-chain issuance of verifiable attestations are essential for use-case like:
- Avoiding Sybil attacks with one person one vote
- Participation in certain events with credentials
- Compliance to government financial regulations etc.
We are proposing a standard claims structure for Decentralized Identity (DID) issuers and verifier entities to create smart contracts in order to provide on-chain commitment of the off-chain verification process, and once the given address is associated with the given attestation of the identity verification off-chain, the issuers can then onboard other verifiers (i.e. governance, financial institution, non-profit organization, web3 related cooperation) to define the condition of the ownership of the user in order to reduce the technical barriers and overhead of current implementations.
The motivation behind this proposal is to create a standard for verifier and issuer smart contracts to communicate with each other in a more efficient way. This will reduce the cost of KYC processes, and provide the possibility for on-chain KYC checks. By creating a standard for communication between verifiers and issuers, it will create an ecosystem in which users can be sure their data is secure and private. This will ultimately lead to more efficient KYC processes and help create a more trustful environment for users. It will also help to ensure that all verifier and issuer smart contracts are up-to-date with the most recent KYC regulations.
Specification
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Definitions
-
Zero-Knowledge Proof (ZKP): a cryptographic device that can convince a verifier that an assertion is correct without revealing all of the inputs to the assertion.
-
Soulbound Token (SBT): A non-fungible and non-transferrable token that is used for defining the identity of the users.
-
SBT Certificate: An SBT that represents the ownership of ID signatures corresponding to the claims defined in
function standardClaim(). -
Verifiable Credential (VC): A collection of claims made by an issuer. These are temper evident credentials that allow the holders to prove that they posses certain characteristics (for example, passport verification, constraints like value of tokens in your wallet, etc) as demanded by the verifier entity.
-
Claim: An assertion that the DID Holder must fulfill to be verified.
-
Holder: The entity that stores the claim, such as a digital identity provider or a DID registry. The holder is responsible for validating the claim and providing verifiable evidence of the claim.
-
Claimer: The party making a claim, such as in an identity verification process.
-
Issuer: The entity that creates a verifiable credential from claims about one or more subjects to a holder. Example issuers include governments, corporations, non-profit organizations, trade associations, and individuals.
-
Verifier: An entity that validates data provided by an issuer of verifiable credentials, determining its accuracy, origin, currency and trustworthiness.
Metadata Standard
Claims MUST be exposed in the following structures:
1. Metadata information
Each claim requirement MUST be exposed using the following structure:
2. Values Information
This following structure will be used to define the actual claim information, based on the description of the Metadata structure, the structure is the same as Values structure of EIP-3475.
3. Claim structure
Claims (eg. age >= 18, jurisdiction in allowlist, etc.) are represented by one or many instances of the Claim structure below:
description of some logic functions that can be used are as follows:
| Symbol | Description |
|---|---|
| ⊄ | does not belong to the set of values (or range) defined by the corresponding Values |
| ⊂ | condition that the parameter belongs to one of values defined by the Values |
| < | condition that the parameter is greater than value defined by the Values |
| == | condition that the parameter is strictly equal to the value defined by the Values structure |
Claim Example
Defines the condition encoded for the index 1 (i.e the holder must be equal or more than 18 years old).
Interface specification
Verifier
Issuer
Events
Rationale
TBD
Backwards Compatibility
- This EIP is backward compliant for the contracts that keep intact the metadata structure of previous issued SBT's with their ID and claim requirement details.
- For e.g if the DeFI provider (using the modifiers to validate the ownership of required SBT by owner) wants the admin to change the logic of verification or remove certain claim structure, the previous holders of the certificates will be affected by these changes.
Test Cases
Test cases for the minimal reference implementation can be found here for using transaction verification regarding whether the users hold the tokens or not. Use Remix IDE to compile and test the contracts.
Reference Implementation
The interface is divided into two separate implementations:
-
EIP-5851 Verifier is a simple modifier that needs to be imported by functions that are to be only called by holders of the SBT certificates. Then the modifier will call the issuer contract to verifiy if the claimer has the SBT certifcate in question.
-
EIP-5851 Issuer is an example of an identity certificate that can be assigned by a KYC controller contract. This is a full implementation of the standard interface.
Security Considerations
- Implementation of functional interfaces for creating KYC on SBT (i.e
changeStandardClaim(),certify()andrevoke()) are dependent on the admin role. Thus the developer must insure security of admin role and rotation of this role to the entity entrusted by the KYC attestation service provider and DeFI protocols that are using this attestation service.
Copyright
Copyright and related rights waived via CC0.