Skip to content

Commit

Permalink
Add ERC: Decentralized Identity Verification (DID)
Browse files Browse the repository at this point in the history
Merged by EIP-Bot.
  • Loading branch information
64anushka authored Dec 16, 2024
1 parent 2f2b46a commit acf2554
Showing 1 changed file with 194 additions and 0 deletions.
194 changes: 194 additions & 0 deletions ERCS/erc-7734.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,194 @@
---

Check failure on line 1 in ERCS/erc-7734.md

View workflow job for this annotation

GitHub Actions / Run

Rule statuschange requires 1 more reviewers: @SamWilsn, @xinbenlv, @g11tech

Check failure on line 1 in ERCS/erc-7734.md

View workflow job for this annotation

GitHub Actions / Run

Rule statuschange requires 1 more reviewers: @SamWilsn, @xinbenlv, @g11tech
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).

0 comments on commit acf2554

Please sign in to comment.