🚀
Energy Web X Ecosystem
  • Documentation Overview
  • Core Concepts
    • Energy Web Chain
    • Energy Web X
    • Energy Web Tokens
      • Token Lifting
      • Token Lowering
    • Worker Nodes and Worker Node Networks
      • Server-based Worker Node
      • Marketplace App (desktop-based)
    • Worker Node Operator
    • Smart Flows and Groups
    • Subscription
    • Reward Period
    • Voting and Consensus
    • Ethereum
      • Transactions and Transaction Costs
    • Decentralized Identifiers (DIDs)
  • EWC ECOSYSTEM
    • Energy Web Chain
      • System Architecture
        • Proof-of-Authority Consensus Mechanism
        • System Contracts
          • Name registry
          • Holding Contract
          • Block Reward Contract
          • Validator-Set Contract
        • Validator Node Architecture
      • Energy Web Block Explorer
      • Energy Web Chain Governance & Validators
    • Energy Web Tokens
  • EWX ECOSYSTEM
    • Energy Web X
    • EWX: Architecture
    • Pallets
      • Worker Node Pallet
      • Balances Pallet
      • Proxy Pallet
      • XCM Pallet
      • Assets Pallet
      • Multisig Pallet
      • Scheduler Pallet
      • Preimages Pallet
      • Offences Pallet
      • Eth-Bridge Pallet
      • Token-Manager Pallet
      • Ethereum-events pallet
      • Avn Pallet
    • Worker Nodes
      • 🖥️The Marketplace App
        • Operator and Worker Accounts
          • Creating an operator account
          • Funding an operator account
          • Connecting to operator account
          • Disconnecting an operator account
          • Creating a worker account
          • Importing worker account
          • Exporting worker account
          • Linking a worker account to an operator account
          • Unlinking a worker account from an operator account
        • How to use Ledger on Marketplace App
        • Token Management
          • Creating an EWC account
          • Managing EWC accounts
          • Lifting tokens
          • Lowering tokens
          • Tracking lifting and lowering transactions
          • Checking EWT balance
        • Subscriptions
          • Subscribing to a solution group
          • Topping-up subscription amount
          • Managing subscriptions
          • Unsubscribing from a solution group
          • Unsubscribing delay
        • Worker Node and Rewards
          • Configuring remote worker node
          • Switching worker node location to remote
          • Participating into worker node network
          • Votes casted per Period
          • Reward Period
          • Checking rewards
          • Claiming rewards
        • FAQ: Marketplace App
        • Location Services
      • 🗄️Server-based Worker Nodes
        • Deployment Guide
        • Bootstrapping Server-based Worker Node Accounts
        • FAQ: Server-based Worker Nodes
      • Worker Node use cases
        • Sample Enterprise Use-Cases
          • Operating Envelopes Partitioning
          • ZEL Request Partitioning
          • Green Proofs
            • SAFc
            • Green Proofs for Bitcoin (GP4BTC)
            • Green Proofs as a Service (GPSaaS)
            • Green Proofs for Electrical Vehicles (GP4EV)
  • ENERGY SOLUTIONS
    • Green Proofs by Energy Web
      • Green Proofs Overview
      • Green Proofs Architecure
      • Green Proofs Software Stack
      • Use Cases and Reference Implementations
        • 24x7 Renewable Electricity
        • Sustainable Aviation Fuel
        • Green Proofs for Bitcoin
          • GP4BTC Miner Guide
        • Decarbonizing Shipping
        • Green Proofs for Electrical Vehicles
        • Green Proofs as a Service (GPSaaS)
    • Digital Spine by Energy Web
      • Design and Architecture
      • Component Guides
        • Energy Web Name Service (ENS)
        • Self-Sovereign Identities
          • SSI-Hub
          • Technical Guide
            • Organizations
            • Applications
            • Roles and IAM
          • Deployment Guide
            • Deploy Identity Cache Server
            • Deploy Switchboard
        • DDHub Message Broker
          • Technical Guide
            • Authentication and Authorization
            • Topics
            • Messaging
          • Deployment Guide
            • Deploy DID Auth Proxy
            • Deploy Message Broker
        • DDHub Client Gateway
          • Technical Guide
            • Authentication and Authorization
              • Key Vault
            • Client Gateway Identity and VCs
            • Address Book
            • Topics
            • Channels
            • Integration Options
            • Messaging
          • Deployment Guide
            • Launchpad SaaS
            • Azure Marketplace
            • Self-Hosted
              • Deploy with Kubernetes
              • Deploy with Docker
            • Key Vault
              • Deploy with HashiCorp Key Vault
              • Deploy with Azure Key Vault
              • Deploy with AWS Secrets Manager
            • Rebranding and Whitelabelling
Powered by GitBook
On this page
  • Overview
  • Core Concepts
  1. ENERGY SOLUTIONS
  2. Digital Spine by Energy Web
  3. Component Guides

Self-Sovereign Identities

Overview

Self-sovereign identity (SSI) is a growing paradigm that promotes an individual’s control over their identity and their data. This is in contrast to the current paradigm where most official identifiers (driver’s license, birth certificate, usernames, etc.) are given to users and maintained by a central authority, and where user data can be shared without their knowledge or consent (especially in the event of a cybersecurity breach) and where roles, access, and permissions can be centrally revoked without user knowledge.

Core Concepts

Decentralized Identifiers (DID)

A DID is an identifier that can be generated and controlled by individuals or organizations without an external authority. It can be used to identify any subject, such as a non-tangible asset, a customer, or an organization. A user can create a DID for themselves or an asset using cryptographic or other means. A DID for a given system resides in a verifiable DID registry, which are typically implemented on a decentralized ledger to ensure no one party can unilaterally change its parameters. They may also be hosted in conventional servers or networks.

Each DID can be resolved to a DID Document, a JSON-LD object containing several attributes:

  • the owner of the DID

  • a list of valid cryptographic keys

  • a list of ways that can be used to authenticate

  • a list of service endpoints associated with the DID

These attributes help a third party to verify control for a given DID.

// Example DID Document
{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    //used to authenticate as did ...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "service": [{
    // used to retrieve Verifiable Credentials associated with the DID
    "id":"did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

Verifiable Credentials (VC)

A Verifiable Credential is a secure and machine-verifiable digital credential which respects a standard data model. The use of digital signatures makes verifiable credentials more tamper-evident and more trustworthy than many conventional role-based digital identifiers.

Much like a physical credential (e.g. a passport, or driver’s license), a VC typically contains:

  1. Information related to identifying the subject of the credential (unique identifier)

  2. Information related to the issuing authority

  3. Information related to the type of credential it is

  4. Information related to specific attributes or properties being asserted by the issuing authority about the subject

  5. Evidence related to how the credential was derived

  6. Information related to constraints on the credential (for example, expiration date, or terms of use).

Together DIDs and VCs can be used to implement Identity and Access Management solutions that provide users and organizations with greater control over their identities and associated data.

PreviousEnergy Web Name Service (ENS)NextSSI-Hub

Last updated 3 months ago