Skip to content

did.md

Latest commit

 

History

History
237 lines (192 loc) · 6.28 KB

did.md

File metadata and controls

237 lines (192 loc) · 6.28 KB

N42 Blockchain DID Interface Technical Documentation

1. Overview

N42 Blockchain provides a robust and flexible Decentralized Identity (DID) infrastructure, enabling secure, self-sovereign digital identity management. The N42 DID module conforms to W3C DID standards, while integrating on-chain verification, privacy-preserving ZKPs, cryptographic proofs, cross-domain identity bridging, and selective disclosure features.

This documentation covers the architecture, API endpoints, data formats, security mechanisms, and integration guidance for developers and enterprises building identity solutions on top of N42.

2. Key Features

  • Self-sovereign identity: Users own and control their identity without centralized authorities.
  • W3C-compliant DID structure: Compatible with global DID specifications.
  • On-chain and off-chain hybrid identity registry: Efficient and scalable storage design.
  • Zero-knowledge proof support: Selective disclosure of attributes without revealing raw data.
  • Cross-domain verification: Support for DID resolution and interoperability between N42 domains.
  • Reputation and credential verification: Built-in verifiable credentials for social and reputation-based applications.

3. Architecture

The N42 DID system is composed of:

  • DID Registry Contract (on-chain): Stores mappings between DIDs and their associated public keys, service endpoints, and credential metadata.
  • Off-chain Storage: Optional storage layer using IPFS/Arweave for large, non-critical DID documents.
  • DID Resolver: Module that resolves DIDs and returns the DID Document with proof.
  • ZK Verifier Engine: Verifies zero-knowledge proofs for attributes.
  • VC/VP Module: Handles issuance, storage, and verification of Verifiable Credentials (VCs) and Verifiable Presentations (VPs).

4. DID Format

N42 uses the following format for its DID identifiers:

did:n42:<domain-id>:<unique-identifier>

Example:

did:n42:social:0xA1B2C3D4E5F67890

Each DID resolves to a DID Document, formatted according to W3C specifications:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:n42:social:0xA1B2C3D4E5F67890",
  "verificationMethod": [
    {
      "id": "did:n42:social:0xA1B2C3D4E5F67890#key-1",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "controller": "did:n42:social:0xA1B2C3D4E5F67890",
      "publicKeyHex": "0392ABCDEF..."
    }
  ],
  "authentication": [
    "did:n42:social:0xA1B2C3D4E5F67890#key-1"
  ],
  "service": [
    {
      "id": "did:n42:social:0xA1B2C3D4E5F67890#profile",
      "type": "SocialProfile",
      "serviceEndpoint": "ipfs://QmZk..."
    }
  ]
}

5. API Endpoints

5.1 Create DID

POST /api/v1/did/create

Payload:

{
  "public_key": "0392ABCDEF...",
  "domain": "social",
  "metadata": {
    "service": {
      "type": "SocialProfile",
      "endpoint": "ipfs://QmZk..."
    }
  },
  "signature": "<ECDSA signature>"
}

Response:

{
  "did": "did:n42:social:0xA1B2C3D4E5F67890",
  "status": "created",
  "timestamp": 1712345678
}

5.2 Resolve DID

GET /api/v1/did/resolve?did=did:n42:social:0xA1B2C3D4E5F67890

Response:

{
  "didDocument": { ... },
  "proof": {
    "type": "EcdsaSecp256k1Signature2019",
    "created": "2025-03-20T12:00:00Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "...",
    "signatureValue": "MEUCIQD..."
  }
}

5.3 Update DID Document

PUT /api/v1/did/update

Payload:

{
  "did": "did:n42:social:0xA1B2C3D4E5F67890",
  "updates": {
    "service": {
      "type": "MessagingService",
      "endpoint": "https://msg.example.com"
    }
  },
  "signature": "<ECDSA signature>"
}

5.4 Revoke DID

DELETE /api/v1/did/revoke

Payload:

{
  "did": "did:n42:social:0xA1B2C3D4E5F67890",
  "signature": "<ECDSA signature>"
}

5.5 Issue Verifiable Credential

POST /api/v1/vc/issue

Payload:

{
  "issuer_did": "did:n42:edu:0xUniversity123",
  "subject_did": "did:n42:social:0xA1B2C3D4...",
  "credential_type": "DegreeCredential",
  "claims": {
    "degree": "MSc Computer Science",
    "university": "XYZ University"
  },
  "expiration": "2027-12-31",
  "signature": "<issuer_signature>"
}

5.6 Verify Verifiable Presentation

POST /api/v1/vp/verify

Payload:

{
  "presentation": { ... },
  "proof": { ... }
}

Response:

{
  "is_valid": true,
  "verified_by": "did:n42:org:0xVerifier001",
  "timestamp": 1712345999
}

6. Security Model

  • DID ownership: Proven via cryptographic signatures (ECDSA, Ed25519, or others).
  • Credential integrity: Protected by issuer signatures and optionally by ZKPs.
  • Data privacy: Selective disclosure enabled via ZK-SNARKs, BBS+ signatures, and FHE (future).
  • Revocation: Verifiable credentials include revocation registries to invalidate compromised or outdated claims.
  • Domain isolation: Each DID is scoped to a domain, ensuring domain-specific governance.

7. Best Practices

  • Use off-chain IPFS/Arweave links to store large DID metadata to minimize gas fees.
  • Rotate verification keys periodically for enhanced security.
  • Encourage use of Verifiable Credentials with ZK-based selective disclosure in privacy-sensitive applications.
  • Maintain timestamped logs of all DID operations for auditability.

8. Future Roadmap

  • Cross-chain DID bridging: Support for DID resolution across Ethereum, Solana, and Cosmos.
  • Biometric DID binding: Optional facial/fingerprint binding to DID for hardware wallets or civil registry integrations.
  • DAO-based identity governance: Voting-based revocation or re-verification of credentials.
  • FHE-based private identity validation.

9. Conclusion

The N42 DID Interface enables secure, private, and interoperable decentralized identity management across multiple domains and applications. By integrating industry standards with cutting-edge cryptography, N42 empowers developers and institutions to build verifiable identity ecosystems for finance, AI, social, education, and more — all while preserving user sovereignty and trustlessness.