Decentralized Identity on the Hedera Consensus Service | Hedera Hedera Network Services Token Service Mint and configure tokens and accounts. Consensus Service Verifiable timestamps and ordering of events. Smart Contracts Run Solidity smart contracts. HBAR The Hedera network's native cryptocurrency. Insights How It Works Learn about Hedera from end to end. Explorers View live and historical data on Hedera. Dashboards Analyze network activity and metrics. Network Nodes Understand networks and node types. Devs Start Building Get Started Learn core concepts and build the future. Documentation Review the API and build using your favorite language. Developer Resources Integrations Plugins and microservices for Hedera. Fee Estimator Understand and estimate transaction costs. Open Source Hedera is committed to open, transparent code. Learning Center Learn about web3 and blockchain technologies. Grants Grants & accelerators for your project. Bounties Find bugs. Submit a report. Earn rewards. Ecosystem ECOSYSTEM Hedera Ecosystem Applications, developer tools, network explorers, and more. NFT Ecosystem Metrics Analyze on-chain and market NFT ecosystem metrics. CATEGORIES Web3 Applications Connect into the innovative startups decentralizing the web on Hedera. Enterprise Applications Learn about the Fortune 500 companies decentralizing the web on Hedera. Wallets & Custodians Create a Hedera account to manage HBAR, fungible tokens, and NFTs. Network Explorers Hedera mainnet and testnet graphical network explorers. Developer Tooling Third-party APIs, integrations, and plugins to build apps on Hedera. Grants & Accelerators Boost your project with support from the Hedera ecosystem. Partner Program Explore our partners to bring your vision into reality. Hedera Council Over 30 highly diversified organizations govern Hedera. Use Cases Hedera Solutions Asset Tokenization Studio Open source toolkit for tokenizing assets securely. Stablecoin Studio All-in-one toolkit for stablecoin solutions. Hedera Guardian Auditable carbon markets and traceability. Functional Use Cases Data Integrity & AI Reliable, secure, and ethically governed insights. Sustainability Enabling fair carbon markets with trust. Real-World Asset Tokenization Seamless tokenization of real-world assets and digital at scale. Consumer Engagement & Loyalty Mint, distribute, and redeem loyalty rewards. Decentralized Identity Maintain the lifecycle of credentials. Decentralized Logs Scalable, real-time timestamped events. DeFi Dapps built for the next-generation of finance. NFTs Low, fixed fees. Immutable royalties. Payments Scalable, real-time, and affordable crypto-payments. HBAR Overview Learn about Hedera's token, HBAR. Treasury Management Hedera’s report of the HBAR supply. Governance Decentralized Governance Hedera Council See the world's leading organizations that own Hedera. About Meet Hedera's Board of Directors and team. Journey Watch Hedera's journey to build an empowered digital future for all. Transparent Governance Public Policy Hedera's mission is to inform policy and regulation that impact the industry. Meeting Minutes Immutably recorded on Hedera. Roadmap Follow Hedera's roadmap in its journey to build the future. Resources Company What's New Partners Papers Careers Media Blog Technical Press Podcast Community Events Meetups Store Brand Navigation QUICKSTART Decentralized Identity on the Hedera Consensus Service technical May 01, 2020 by Paul Madsen Head of Identity, The HBAR Foundation Hedera is pleased to announce the early availability of beta tools that Hedera developers can use to manage the lifecycle of Decentralized Identifiers (DIDs) and Verifiable Credentials via the Hedera Consensus Service. We welcome feedback from the community on these tools. Decentralized Identity Decentralized Identity (DI) is an architecture and set of emerging standards for identity management that may use a blockchain or Distributed Ledger (DLT) within the architecture. The fundamental criteria for the applicability of a DLT to a use case (including identity) is the opportunity to disintermediate some actor and thereby gain in efficiency, security, or cost. However, most identity applications require 3rd parties as attribute authorities – the government of Canada must assert that I am Canadian, Hedera that I am an employee, etc - no other party is authorized to say so. So there is arguably a fundamental incompatibility between DLTs and identity in that 3rd parties play a justifiable role. But, even if we can’t disintermediate the business/trust relationship that are fundamental to identity use cases, there may be value in disintermediating the network or messaging architecture – and so gain advantages in privacy, or resilience, or integration efficiencies. The fundamental value of DLTs to identity applications is in enabling a loose coupling between Issuer and RP with respect to the flow of identity attributes and associated metadata. Loose coupling means that Issuer and RP do not directly interact/message, but rather do so indirectly via transactions submitted to and queries of the DLT. Two particular aspects of the above flow can be facilitated by a DLT – metadata discovery and revocation: Validation of credentials presumes verification of digital signatures. DLTs can play a role in facilitating retrieval of the associated public keys. Additionally, DLTs can enable discovery of associated service endpoints. A critical aspect of credential validation is for the RP to assess whether the credential has been revoked. The credential may be long-lived, or short-lived. If short-lived, the RP can be confident that the claims within the credential are fresh and timely. If long-lived, the RP will likely need to gain some other indicator that the claims are still valid. Scaling Decentralized Identity In the Decentralized Identity model, the identifiers by which actors are known may be resolvable against a DLT. When two actors engage in an online interaction that requires their identities be verified, they can both perform a lookup of the other’s identifier against a DLT on which the identity is anchored and retrieve identity metadata that will assist in subsequent validation. Such lookups of identity metadata can be satisfied by whatever DLT node the query is sent to and so place no significant burden on the network. Consequently, the network can collectively provide a high throughput, i.e. many transactions per second or ‘tps’. But a read presumes that the necessary metadata has previously been added to the DLT with a write which, because such a transaction requires that all nodes must process it into consensus state, is generally constrained in throughput. Many identity use cases will require that an identity be written to a DLT only once, thus enabling many subsequent reads. For instance, if a university issues a credential to a graduating student, then that issuance can be recorded once on a DLT. Whenever that student subsequently applies for a job, the HR department would query the DLT for the credential artifacts. It's likely that even low throughput DLTs could handle the associated volume. On the other hand, consider an application like the Internet of Things (IoT) in which each device may receive a distinct and unique identity at manufacture time – this initial identity a key aspect of subsequent assessment of the provenance and validity of the device by later applications and other devices. Each issued identity, and perhaps other moments in the thing's lifecycle, could require a corresponding write to a DLT, which implies that the DLT be able to support that volume of transactions. Most public DLTs are not able to natively support the sort of transaction volumes that such a use case might imply. For example, Bitcoin’s maximum throughout is less than 7 transactions per second (tps), and in its current state, the Ethereum network can process a maximum of 15 tps – these are the speed limits for all transaction types, not just those anchoring identities to the ledger. Hedera Consensus Service The Hedera Consensus Service offers one model for scaling Decentralized Identity. HCS enables a model where identities can be anchored to Hedera at very high throughput. Critically, rather than storing identity metadata (such as public keys, DID Documents, credential hashes, etc) on the Hedera mainnet nodes – these identity artifacts flow through, instead of into, Hedera and out to other computers. Consequently, HCS can avoid the bottleneck of having the nodes of the Hedera network writing to disk. If we apply the HCS model to decentralized identity, the Hedera nodes focus exclusively on assigning a consensus timestamp and order to the transactions storing and updating identity artifacts, but the identity artifacts themselves are not persisted on the Hedera nodes, but rather on the computers of some other business network. With this storage burden removed from the Hedera nodes, they can process transactions at the native speed of the hashgraph consensus algorithm, the very fast 10-100k tps. Similarly, the business network nodes, without bearing the burden of contributing to consensus, can be optimized for fast storage and lookups of these identity artifacts. Standardization Key pieces of the DI architecture are under standardization at the W3C. Hedera recently joined the W3C so that we can ensure that DI applications built on Hedera will be compliant with those emerging standards and where appropriate, contribute Hedera specifications into those standardization efforts. An early preview of the Hedera HCS DID Method specification defines how Decentralized Identifiers and their corresponding DID Documents are managed via HCS messages. Participants create, update, and delete the DID Documents via HCS messages submitted to a specific topic. Those messages (and the DID data they carry) are timestamped and ordered by the Hedera network before flowing out via the mirror network to members of a business network. It is against the business network that Relying Parties (RP) resolve DIDs into the corresponding DID Documents. Similarly, HCS messages can be used to enable a revocation registry of Verifiable Credentials. When a Verifiable Credential (for instance, a Driver’s License issued by the DMV or a particular safety certification issued by a Technical Training School) is issued to a Subject, the hash of that credential is sent via an HCS message to be stored on a business network. When that credential is subsequently presented (for instance, in order to rent a car or to establish a technician’s qualifications for a particular maintenance job) the current status of that credential can be queried against the nodes of the business network. If the credential had been revoked, the hash would have been deleted and the query would fail. Share This Back to blog What is gRPC, gRPC-Web, and Proxies? Ed Marquez Pragmatic Blockchain Design Patterns – Integrating Blockchain into Business Processes Michiel Mulders Zero Cost EthereumTransaction on Success: Hedera's New Fee Model for Relay Operators Oliver Thorn Hedera Adopts Chainlink Standard for Cross-Chain Interoperability To Accelerate Ecosystem Adoption Hedera Team Hedera Developer Highlights March 2025 Michiel Mulders Hedera Release Cycle Overview Ed Marquez View All Posts Sign up for the newsletter CONNECT WITH US Transparency Open Source Audits & Standards Sustainability Commitment Carbon Offsets Governance Hedera Council Public Policy Treasury Management Meeting Minutes LLC Agreement Node Requirements Community Events Meetups HBAR Telegram Developer Discord Twitter Community Support FAQ Network Status Developer Discord StackOverflow Brand Brand Guidelines Built on Hedera Logo Hedera Store About Team Partners Journey Roadmap Careers Contact General Inquiry Public Relations © 2018-2025 Hedera Hashgraph, LLC. All trademarks and company names are the property of their respective owners. All rights in the Deutsche Telekom mark are protected by Deutsche Telekom AG. All rights reserved. Hedera uses the third party marks with permission. Terms of Use  |  Privacy Policy