-
Notifications
You must be signed in to change notification settings - Fork 575
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add ERC: Decentralized Identity Verification (DID)
Merged by EIP-Bot.
- Loading branch information
Showing
1 changed file
with
194 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,194 @@ | ||
--- | ||
Check failure on line 1 in ERCS/erc-7734.md GitHub Actions / Run
|
||
eip: 7734 | ||
title: Decentralized Identity Verification (DID) | ||
description: A privacy-preserving method for decentralized identity verification, enabling secure integration of identity management in dApps. | ||
author: Anushka Yadav (@64anushka) <[email protected]> | ||
discussions-to: https://ethereum-magicians.org/t/discussion-on-decentralized-identity-verification-did-standard/20392 | ||
status: Draft | ||
type: Standards Track | ||
category: ERC | ||
created: 2024-06-26 | ||
--- | ||
|
||
## Abstract | ||
|
||
This proposal introduces a standard for decentralized identity verification (DID) on the blockchain. The standard leverages cryptographic hashes to represent identity proofs and events for transparency and traceability. By emphasizing simplicity, privacy, and user control, this proposal aims to reduce overhead for developers and users, ensuring seamless integration into decentralized applications (dApps). It offers a minimalistic solution that keeps identity structure simple and enables off-chain mechanisms for detailed identity management and verification. | ||
|
||
## Motivation | ||
|
||
Centralized identity verification methods are cumbersome, prone to data breaches, and fail to provide users control over their identity data. Existing DID solutions often introduce complexity, making adoption challenging for developers and users. This proposal seeks to address these issues by: | ||
|
||
- Offering a minimalistic, decentralized standard that simplifies identity verification. | ||
- Providing privacy-preserving mechanisms that keep sensitive identity data off-chain. | ||
- Encouraging wider adoption by enabling seamless integration into dApps across various industries. | ||
- | ||
### Stakeholders | ||
|
||
The following stakeholders will benefit from this proposal: | ||
|
||
#### dApp Developers | ||
Developers creating decentralized applications that require identity verification can implement this standard to provide users with secure, decentralized identity management. The minimalistic design makes it easier to integrate into existing workflows without adding unnecessary complexity. | ||
|
||
#### Service Providers | ||
Platforms offering services such as decentralized finance (DeFi), gaming, or social networking can integrate this standard to verify user identities without relying on centralized authorities. This reduces the risk of fraud and enhances user trust. | ||
|
||
#### Enterprises | ||
Companies looking to integrate blockchain-based identity solutions into their existing systems can use this standard to ensure secure and privacy-preserving identity verification. This allows for a seamless transition to decentralized technologies while maintaining user privacy and security. | ||
|
||
#### Developers of Interoperability Solutions | ||
Those working on cross-platform and cross-blockchain interoperability can implement this standard to enable a unified identity verification mechanism across different systems, reducing complexity and increasing user control over their identities. | ||
|
||
### Differentiation | ||
|
||
This proposal stands out from other DID standards by focusing on minimalism, user control, and privacy. Unlike other solutions that encompass a wide range of identity attributes and interactions, this standard keeps the structure simple and relies on off-chain mechanisms for detailed identity management. Its simplicity fosters easier adoption, making it ideal for dApps that prioritize user-centric, secure ecosystems. | ||
|
||
## Specification | ||
The Decentralized Identity Verification (DID) standard introduces a simple, secure, and privacy-preserving mechanism for verifying user identities on the blockchain. The key components of this standard are outlined below: | ||
|
||
#### Identity Contract | ||
A smart contract that acts as the central authority for identity verification. The contract stores the status of identity verifications for users and ensures that verification events are triggered securely and transparently. | ||
|
||
#### Verification Function | ||
The `verifyIdentity` function allows a user to submit two verification hashes that represent off-chain proofs or attestations of identity. These hashes can be derived from external sources such as third-party verifiers, documents, or attestations.The function compares the provided hashes and updates the identity verification status accordingly. | ||
|
||
##### Input Parameters: | ||
**identityHash:** A cryptographic hash representing the user's identity. | ||
**verificationHash:** A cryptographic hash derived from the proof or attestation used to verify the identity. | ||
|
||
#### IdentityVerified Event | ||
The `IdentityVerified` event is emitted when the user's identity verification is successfully updated. This event ensures traceability and transparency, allowing dApp developers and users to track verification statuses. | ||
|
||
#### Identity Structure | ||
The identity is a simple structure represented by a unique address (public key). Additional identity attributes, such as name or age, are optional and left to off-chain management. This minimal approach keeps the implementation lean, avoiding unnecessary complexity and encouraging broader adoption. | ||
|
||
### Interface | ||
|
||
```solidity | ||
pragma solidity ^0.8.0; | ||
interface IDecentralizedIdentity { | ||
// Struct to represent an identity | ||
struct Identity { | ||
address userAddress; // Ethereum address of the user | ||
bytes32 identityHash; // Hash of the identity data | ||
bytes32[2] verificationHashes; // Hashes used for verifying identity | ||
bool isVerified; // Indicates if the identity is verified | ||
uint256 timestamp; // Timestamp of identity creation | ||
} | ||
// Event emitted when a new identity is created | ||
event IdentityCreated(address indexed userAddress, bytes32 identityHash, uint256 timestamp); | ||
// Event emitted when an identity is verified | ||
event IdentityVerified(address indexed userAddress, bytes32[2] verificationHashes, uint256 timestamp); | ||
// Event emitted when an identity is revoked | ||
event IdentityRevoked(address indexed userAddress, uint256 timestamp); | ||
// Function to create a new decentralized identity for the caller. | ||
// Parameters: | ||
// - identityHash: Hash of the identity data. | ||
function createIdentity(bytes32 identityHash) external; | ||
// Function to verify the decentralized identity for the caller. | ||
// Parameters: | ||
// - verificationHashes: Hashes used for verifying the identity. These can be | ||
// derived from off-chain proofs, cryptographic challenges, or other methods | ||
// specific to the implementer's requirements. The exact meaning and derivation | ||
// of the verificationHashes are left to the contract's implementer. | ||
function verifyIdentity(bytes32[2] calldata verificationHashes) external; | ||
// Function to revoke the decentralized identity for the caller. | ||
function revokeIdentity() external; | ||
// Function to retrieve the decentralized identity for a given user address | ||
// Parameters: | ||
// - userAddress Ethereum address of the user. | ||
// Returns: | ||
// identity The decentralized identity struct. | ||
function getIdentity(address userAddress) external view returns (Identity memory); | ||
} | ||
``` | ||
|
||
## Rationale | ||
|
||
The design leverages cryptographic hashes to represent identity information, ensuring that sensitive data is not stored directly on the blockchain. The use of `verificationHashes` allows for flexible identity verification mechanisms. These hashes could be derived from various off-chain proofs, such as cryptographic challenges or attestations, depending on the implementer's needs. By leaving the interpretation of the verification hashes open, the standard enables adaptability while maintaining privacy and security. Additionally, the inclusion of events ensures transparency and traceability. | ||
|
||
## Reference Implementation | ||
|
||
```solidity | ||
pragma solidity ^0.8.0; | ||
import "./IDecentralizedIdentity.sol"; | ||
contract DecentralizedIdentity is IDecentralizedIdentity { | ||
// Mapping to store identities by user address | ||
mapping(address => Identity) private identities; | ||
// Function to create a new decentralized identity for the caller. | ||
// Parameters: | ||
// - identityHash Hash of the identity data. | ||
function createIdentity(bytes32 identityHash) external override { | ||
// Ensure identity does not already exist | ||
require(identities[msg.sender].userAddress == address(0), "Identity already exists"); | ||
// Create the identity for the caller | ||
identities[msg.sender] = Identity({ | ||
userAddress: msg.sender, | ||
identityHash: identityHash, | ||
verificationHashes: [bytes32(0), bytes32(0)], // Initialize with empty hashes | ||
isVerified: false, | ||
timestamp: block.timestamp | ||
}); | ||
// Emit event for the creation of a new identity | ||
emit IdentityCreated(msg.sender, identityHash, block.timestamp); | ||
} | ||
// Function to verify the decentralized identity for the caller. | ||
// Parameters: | ||
// - verificationHashes: Hashes used for verifying the identity. | ||
function verifyIdentity(bytes32[2] calldata verificationHashes) external override { | ||
// Ensure identity exists | ||
require(identities[msg.sender].userAddress != address(0), "Identity does not exist"); | ||
// Update verification hashes and mark identity as verified | ||
identities[msg.sender].verificationHashes = verificationHashes; | ||
identities[msg.sender].isVerified = true; | ||
// Emit event for the verification of identity | ||
emit IdentityVerified(msg.sender, verificationHashes, block.timestamp); | ||
} | ||
// Function to revoke the decentralized identity for the caller. | ||
function revokeIdentity() external override { | ||
// Ensure identity exists | ||
require(identities[msg.sender].userAddress != address(0), "Identity does not exist"); | ||
// Mark identity as not verified | ||
identities[msg.sender].isVerified = false; | ||
// Emit event for the revocation of identity | ||
emit IdentityRevoked(msg.sender, block.timestamp); | ||
} | ||
// Function to retrieve the decentralized identity for a given user address | ||
// Parameters: | ||
// - userAddress Ethereum address of the user. | ||
// Returns: | ||
// identity The decentralized identity struct. | ||
function getIdentity(address userAddress) external view override returns (Identity memory) { | ||
return identities[userAddress]; | ||
} | ||
} | ||
``` | ||
|
||
## Security Considerations | ||
|
||
**Secure Hashing**: Ensure that identity and verification hashes are generated using a secure hashing algorithm to prevent collisions and ensure the integrity of the identity data. | ||
**Replay Attacks**: Verification hashes should incorporate nonces or timestamps to prevent replay attacks. | ||
**Implementation Flexibility**: Developers must ensure that hash generation and validation processes are robust and resistant to manipulation. | ||
|
||
## Copyright | ||
|
||
Copyright and related rights waived via [CC0](../LICENSE.md). |