Enabling Decentralized/Self-Sovereign Identity with Oracle Blockchain Platform

February 4, 2024 | 18 minute read
Mark Rakhmilevich
Vice President, Blockchain Product Management
Text Size 100%:

Created in collaboration with Lehigh University capstone project team: Ari Carp '24, William Han '24, Adrian Ross '24, and Shun Ueda '25

Self-Sovereign Identity

A student team at Lehigh University in a 2023 capstone project has implemented an idea called Self-Sovereign Identity, supported by a trustless network using the Oracle Blockchain Platform. This solution leverages the W3C Verifiable Credential Model, which meshes a ledger-based verifiable data registry (VDR) and a peer-to-peer system to achieve a trustless network. Self-Sovereign Identity (SSI) gives individuals full control and ownership of their digital identities and credentials without relying on multiple identity systems maintained by different companies and government agencies. This project came about from Oracle's sponsorship of a capstone project at Lehigh University in 2023. We begin with an introduction to Self-Sovereign or Decentralized Identity (both terms are used interchangeably) and then delve into our implementation using the Oracle Blockchain Platform for the core VDR ledger.

Currently, paper documents such as passports and driver's licenses are used to prove claims about individuals (i.e., citizenship, address, age, etc.) In a world of digital interactions, this model presents fraud and privacy risks, such as possible forgery and human error, sharing of unnecessary personal information, which can then be sold to third parties, as well as risks of insecure handling and verifier repository breaches leading to data theft. In addition, our existing digital identities that provide access to various company and government services, such as bank accounts, insurance portals, library cards, and other login accounts, are siloed among numerous systems. Sometimes, these involve Federation when a single set of login credentials are used to support Single Sign-On (SSO) for multiple services. This concept is also based on centralized identity provider (IdP) systems, which are not infrequently subject to security breaches or privacy concerns.

Three types of Identity mechanisms exist in the digital identity management space: Centralized Identity, Federated Identity & and Self-Sovereign Identity (SSI). The first two should be familiar as we have widely used them over the last few decades. The first two involve an identity provider (IdP) and a relying party (RP). Any RP has to contact the IdP directly or indirectly and the IdP shares identity attributes after deciding whether to respond to a specific RP.  An IdP is thus involved in each credential validation process and can track to whom the user has been presenting their credentials, e.g., what online services they have been visiting. By contrast, Self-Sovereign Identity (SSI) gives users complete control of their identity and actions rather than relying on centralized or federated identity providers. Compared to centralized or federated identity systems, SSI or Decentralized Identity cannot be censored or shut down without consent (i.e., users cannot be blocked from using their identity), which makes it the optimum way to give users security and control of their identity. It also doesn't force RPs to connect to specific IdPs, thus enabling privacy-preservation.  And with additional techniques it can also allow users to selectively present specific claims from a credential in a manner that enables cryptographic validation, but doesn't link them to user's unique identity, thus enabling greater degree of anonymity. 

In SSI, identities (called Decentralized Identifiers or DIDs) are linked to credentials consisting of one or more claims (called Verifiable Credentials or VCs) that are validated cryptographically using a trusted registry called a verifiable data registry (VDR). Decentralized Identifiers (DID) and Verifiable Credentials (VC) are the two pillars of decentralized identity that create the foundation of verifiable digital identity, entirely governed by its owner. Multiple standards bodies are involved in creating specifications and defining rules in this space, including the Decentralized Identity Foundation (DIF), focusing on foundational elements of decentralized identity, Trust over IP (ToIP) Foundation, defining architecture for Internet Digital Trust, W3C, focusing on Verifiable Credentials Data Model, and others.

VDRs are frequently implemented using distributed ledger technology (DLT) directly on a special-purpose DLT (e.g., Hyperledger Indy) or as application smart contracts on a general–purpose DLT (e.g., Ethereum, Hyperledger Fabric) because they provide immutability, verifiable change history and shared access for multiple ecosystem participants. While Non-DLT based VDRs exist, they can not provide the tamper-resistence, decentralization of authority, and change history traceability comparable to DLTs, putting them more at risk of external breaches or insider tampering. 

Oracle and SSI

The Oracle Blockchain Platform (OBP) is a permissioned blockchain based on the Linux Foundation Hyperledger Fabric open-source project, with enhanced transaction efficiency and streamlined agreements between multiple parties through smart contracts. It's already broadly used in many industries and can be extended to add VDR and related SSI capabilities for new and existing deployments. That is why the team used OBP as the VDR, exploring the implementation of Decentralized Identities (DIDs), which are stored on-chain, and Verifiable Credentials (VCs), which are passed peer-to-peer, to securely identify individuals and verify their credentials in a privacy-preserving manner. 

Oracle has been actively exploring using SSI in healthcare for Electronic Health Records (EHR) sharing and eGov applications around the world, such as issuing government (state or national) certificates, licenses, etc. More recently, there's been work towards enabling the use of SSI for national ID documents complying with eIDAS European Regulations and ESSIF (European Self-Sovereign Identity Framework.)

The Capstone Project

A four-student team from Lehigh University recently completed a year-long capstone project sponsored by Oracle using Oracle Cloud to address the challenge of preserving privacy while verifying identity and credentials. 

A previous team worked on the first iteration of this project, developing the chaincode to perform CRUD (create, read, update, delete) operations on DID structures stored on OBP, which enables registering of DIDs and managing DID Documents on the ledger. In 2023, the current Lehigh team built upon that solution using the Hyperledger Aries toolkit, specifically the recently introduced Aries Framework JavaScript and React. The solution aims to extend and tailor OBP's generic ledger capabilities to support Self-Sovereign Identities (SSIs) by providing an abstraction layer that enables DIDs with VCs. The SSI model typically has three parties: an Issuer, a Holder, and a Verifier. The team created client software called agents for each role to interact with OBP through chaincodes to resolve (read) and register (write) DIDs in the VDR. The chaincodes are generated and tailored with the Oracle Blockchain App Builder and are accessible by agents through a REST API exposed by ther built-in API gateway in OBP. In addition, the agents can communicate peer-to-peer for the secure issuing and presenting of VCs. The team constructed a user-friendly interface and controller using React, wrapping it around these agents.

SSI Interactions in the Trusted Triangle of Issuer-Holder-Verifier underpinned by Oracle Blockchain Platform VDR
Issuer-Holder-Verifier Interactions in the Trusted Triangle Model Underpinned by Oracle Blockchain Platform-based VDR


One of the target use cases for this solution is to enable patients to issue credentials for healthcare providers to access their EHR data stored in various hospital systems. Healthcare data is one of the most sensitive data types that has historically been in the control of large and siloed health information technology platforms. In a fragmented healthcare system, when patients may need to use providers/specialists outside of their primary care system, sharing healthcare records is often an archaic process relying on paper authorizations shared by fax. Patients also sometimes need to share some of their records, e.g., vaccination data, with third parties (schools, airlines, etc.) Therefore, these technologies solve a crucial problem in giving patients better control of their data. In the demo application, healthcare providers can issue VCs of requested healthcare data to their patients, which can then be presented to other providers for verification.

The team also worked on implementing a cryptographic wallet to sign and store VCs with Hyperledger Aries, removing the weak centralization point and giving the solution the security, interoperability, and privacy DIDs and VCs mechanisms enable.

Key project achievements detailed below include:

  • Deploying Oracle Blockchain Platform (OBP) managed service in Oracle Cloud Infrastructure (OCI) to use as a VDR and adding compute VMs and containers for the agent framework
  • Deploying and extending DID chaincodes from last year's project to handle agent framework requirements
  • Deploying Hyperledger Aries library and its ACA-Py and JavaScript Frameworks
  • Separating Indy and on-Indy VDR interfaces in AJF and creating a VDR module for OBP
  • Creating a new JSON-LD proof handler as part of the W3C Verifiable Credential Model
  • Creating a React wrapper integrated with Oracle IDCS and a Postman collection to test end-to-end processes

Before we go any further, let’s go a little bit more in-depth about each of the components.


OBP Chaincode (smart contract) methods are programs deployed on-chain that define the rules and logic to write and validate transactions on the blockchain network. This facilitates the ledger access agents need, as well as any validation rules and other processing. OBP application chaincodes are used for registering, resolving, and querying DIDs and DID Documents. They can also be used in some VC implementations to persist, update, and query VC schemas and credential definitions stored for reference in the VDR as well as to manage VC revocation status as part of the VDR.  


Decentralized Identifiers (DIDs) are like unique URLs associated with asymmetric key pairs to describe a person. They are really a W3C universally unique identifier (UUID) with added power:

  • DIDs are resolvable into a DID Document (DIDDoc) that contains, at a minimum, public keys for the controller to prove control over the DID.
  • A DID is defined by its DID method—a specification that defines how to create, resolve (read), update, and delete the DIDs. Resolving a DID is like resolving a URL, but instead returns the DID’s associated DIDDoc, which enables issuance and verification of credentials.

DIDs are defined in W3C technical report as strings that consist of at least three colon (":") separated components: "did", DID method, and method-specific identifier. 

DID structure and example
Example of DID structure resolvable to DIDDOC


Since this solution uses OBP chaincode to perform the CRUD operations on DIDs, we need to expose this to public DID resolvers, such as DIF Universal Resolver by creating a new DID method that knows how to invoke OBP chaincode. Therefore, we introduced the "orcl" DID method. This method, when read by a DID resolver, automatically calls the correct OBP instance and corresponding chaincode to perform the necessary operations. More on this later.


The verifiable credential is the W3C digital version of the paper credential.  It is a collecttion of claims an Issuer makes about a subject, which can be a person, a legal entity, a product, etc. A driver's license, a student diploma, health insurance card, an ESG certification or some other certification for a company, a certificate of origin or regulatory compliance certification for a manufactured product, or an electronic Bill of Lading (eBL) for a shipment can all be represented using Verifiable Creadentials. In fact, a collection of these for specific use cases and industries has been defined by W3C, for example, a traceability vocabulary for supply chain use cases. 

VC Example Structure
Example of Verifiable Credential Schema

The issuer (government agency, university, manufacturer, etc.) prepares a series of claims and cryptographically signs this credential in a manner that can be cryptographically verified by referring to verification methods defined in the Issuer's DIDDoc in the VDR. The credential also includes the subject's or holder's DID to link the claims to their subject - a holder, a product ID, shipment ID, etc. Then, the issuer sends the signed VCs to the holder. The holder can verify it by resolving the issuer's DID to retrieve their DIDDoc, which then enables them to use the Issuer's public key to validate the signature.   

After this, the holder selects the credential they wish to share and creates a verifiable presentation (VP), which they sign and send to the verifier. The holder's DID could also be registered in the VDR (Verifiable Data Registry), although it doesn't have to be. In the latter case, they can pass it to the verifier in the peer-to-peer message.

DIDs (Decentralized Identifiers) also play an important role when it comes to the holder presenting verifiable credentials to a verifier. They enable the Verifier to verify the trusted issuer and link the credential's subject to the holder presenting the credential. The verifier retrieves the issuer's public key from the VDR (and possibly the holder's, too) and uses both keys to verify the signatures and authenticate the claims presented. These steps, supplemented with a check against Revocation registry, protect against fraudulent credentials or copied valid credentials presented by an impersonator.

Detailed VC Lifecycle 

Interactions between the Issuer, Holder, and Verifier in this so-called "trust triangle" rely on the "agents" that implement standards used for DID communications (DIDCOMM versions 1 or 2) and VC formats, which are still evolving and can include:

  • JWT/Verified Credential 
  • JSON – LD Verifiable Credential 
  • AnonCreds v1 or v2

The overall lifecycle is shown below.

  1. An authority (Issuer) receives a request for a credential with required information, including a subject DID
    1. It verifies the requester's eligibility (usually via its own systems of record) and their DID and issues a VC consisting of one or more claims about the subject.
    2. Depending on the VC format the Issuer uses, they cryptographically sign the entire VC or its individual claims (in the latter case, each claim could be independently presented later and verified without disclosing everything else in the VC.)
    3. The Issuer sends signed VC to the requester (a.k.a. Holder, a subject of the claims in the credential)
  2. The user (Holder) receives, verifies, and stores these credentials from one or more Issuers in the digital wallet.
  3. At some point, a Relying Party (a.k.a. Verifier) requests a proof of some claims from the Holder.
    1. If the user decides to share the credential, they construct and send a verifiable presentation to the Verifier, signing it with their private keys.
    2. In some cases, the presentation can include a subset of the claims or claims from multiple credentials.
    3. The Holder's wallet will sign the presentation with the user's private key and send it to the Verifier.
  4. The Verifier receives the presentation and can verify the claims and their relationship to the presenter. Unlike paper credentials or digital copies, claims are evaluated not based on the Verifier's judgment but using cryptographic algorithms that are extremely difficult to forge. When a Verifier receives a presentation from a Holder, it uses information from a verifiable data registry (often built on distributed ledgers) to verify authenticity cryptographically. This includes:
    1. Retrieving keys from the VDR to verify the Issuer's and Holder's signatures to ensure that the credential's subject DID matches the DID of the user presenting it. 
    2. Additionally, the Verifier can check VDR for revocation status to ensure the credential is valid and hasn't been revoked.
    3. Further, depending on the VC format, the Verifier can refer to the VC schema and credential definitions of the VC for additional help in interpreting specified claims.


Just like how a lawyer is your representative in the legal system, an agent is the software that is your representative in the decentralized identity network. It consists of components split into the agent framework and the controller. The open-source Hyperledger Aries library project is the most popular collection of frameworks to build these components. It is also part of the greater Hyperledger ecosystem for enterprise-grade blockchain technologies, the same that OBP is built on. Some of its components originated from Hyperledger Indy blockchain framework, e.g., a client indy-sdk, and there's an ongoing worrk in Aries to make this more blockchain agnostic. One of the key efforts in this capstone project has been focused on support of OBP-based VDR within Aries by extending these interfaces to work with Hyperledger Fabric in Oracle Blockchain Platform leveraging the DID chaincode methods.

HL Aries Agent Framework
Hyperledger Aries Agent Framework


SSI Framework

Now that we've introduced all the components needed for SSI, the team needed a framework that translated these ideas and models into actual code. One of the first organizations that undertook this task was the Hyperledger Foundation with the Hyperledger Indy project. It was an all-in-one solution for SSI, providing a new custom blockchain that could be used as a VDR called the Indy ledger (as opposed to Hyperledger Fabric, the ledger used to build OBP). It also provided the DID method (did:indy), a specific type of credential, “AnonCreds”, though not yet W3C compliant, and specialized secure storage.

For most developers looking to upgrade the security of their identity management, the Indy project initially provided everything they needed. However, others thinking longer-term and wanting interoperable solutions started on a modular solution. This initiative became known as Hyperledger Aries, a project derived from Indy, with the goal of creating a blockchain ledger-agnostic framework.

OBP Ledger Connection

To reach the objective of integrating Hyperledger Aries with the Oracle Blockchain Platform (OBP)-based VDR, the team had to overcome several challenges. When Aries was chosen, one of its promises was ledger-agnostic capabilities, which meant it could easily connect to any ledger, including OBP. However, Aries was derived from Indy-SDK, and much of it still depends on using Hyperledger Indy as the verifiable data registry, including demos and documentation. 

The team went through several frameworks in an attempt to achieve this ledger independence. The Aries Cloud Agent Python Framework (ACA-Py), the most widely adopted Aries variation, claimed that it was just a switch in the genesis blocks (the root of the blockchain) to switch the VDR component to something other than Indy. However, getting ACA-Py admin API to work with OBP turned out to be more challenging. Once the team decided that genesis transactions were no longer the method for connecting OBP to an Aries framework, they tried isolating a sub-framework instance, fully decoupling it from Indy dependencies. However, after substantial analysis of the Aries Cloud Agent Python Framework (ACA-PY) and its heavy dependence on low-level libraries, they found that using it created more issues than solved. ACA-Py depended heavily on the Indy-SDK (a software development kit), with each module interconnected. The lack of documentation and the many version inconsistency issues they found made them look at alternatives.

The most promising alternative the team has settled on is the Aries Framework JavaScript (AFJ), which recently has moved to Open Wallet Foundation and rebranded to Credo. This project has recently split the libraries into distinct Indy and non-Indy implementations. Once the open-source community split the verifiable data registry (VDR) module into Indy and non-Indy versions, the team was able to create their own VDR module for Oracle Blockchain.

VC Presentations

Since VCs can come in different formats requiring different proof implementations, not all frameworks have complete support for presenting and verifying VCs in various formats. As AFJ was still being built, the team discovered it needed a more straightforward implementation of a proof mechanism for VCs using JSON-LD format for presentation. After exploring different approaches, they ultimately created a new JSON-LD proof handler from scratch, which now includes all the necessary features, such as v2 messages, Askar wallet compatibility, framework logging, and error handling. 

After resolving additional issues relating to the chaincode and key types used in the proof, the team finally had a working W3C Verifiable Credential Model. The agent architecture (illustrated below) integrated with OBP was complete. With the infrastructure set, the team could finally move on to the React wrapper, integrate with Oracle IDCS, and test with the Postman API.

The complete set of interactions between agents and the VDR is depicted in the sequence diagram below. As shown, there are a lot of steps when peer-to-peer interaction happens. This ensures reliable and secure communication, with no agent left waiting in a deadlock. Another observation is that in the current implementation using JSON-LD credential format the agent interaction with OBP VDR is only needed when the issuer and the verifier write and read DIDs respectfully. To increase validity in message passing, we have the holder double-check the issuer's signature before sending it to the verifier. A final optimization is that in the early stages of this workflow, the holder does not create an “orcl” DID; instead, a did:key. This “key” method is a simple wrapper to a local public key and is the only thing needed since the holder directly communicates with the verifier. 

SSI Seq diagram
Decentralized/Self-Sovereign Identity Flows in a Sequence Diagram


Future Work

Looking toward the future, the team devised several recommendations to take the project further.

  1. To productize the current implementation, we would recommend the following:
    1. Add error handling and invalid credentials or proofs. 
    2. Create a custom document loader in the W3C module to support multiple DID resolvers. 
    3. Modularize the JsonLdProofFormatService and make a pull request to the main open-source framework. 
    4. Adding highly scalable onboarding and identity-proofing solutions for issuers to mass distribute credentials would be a valuable addition. 
    5. Adding a native mobile solution with Aries Bifold and a mobile wallet improves accessibility. 
    6. The project could also benefit from support for custodial wallet backup and integrating Oracle IdM support for Self-Sovereign Identity issuers and roles. 
    7. To ensure the effectiveness of these recommendations, using the Aries Agent Harness for end-to-end testing is advised.
  2. Proposing RFCs to the Aries Working Group for official format identifiers for the JsonLdProofFormatService would also be beneficial. 
  3. Switching to a credential type that supports selective disclosure, such as BBS+ or AnonCreds, could be helpful as it would enable privacy-preserving VC presentation. Integrating zero-knowledge proofs (ZKPs) for predicate claims would further enhance the security of the project. 
  4. Another recommendation is to publish the Oracle-VDR package on npm to allow for broader registry access.
  5. Finally, integrating "orcl" DID resolution via a driver for DIF Unified Resolver could spur greater adoption of Oracle-VDR through an already widely used resolver.


The team learned a lot throughout the entire project, embarking on it with diverse backgrounds and skill sets. Despite the novelty of Decentralized Identity for all members, we quickly immersed ourselves in the subject, gaining a comprehensive understanding of critical concepts such as Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), Verifiable Data Registries (VDRs), and Agents.

As the project unfolded, we delved into the existing programming infrastructure, familiarizing ourselves with essential tools from Hyperledger like Aries, Indy, and Fabric. We also learned the Oracle ecosystem with OBP, chaincodes, and IdM. This allowed us to leverage established frameworks and technologies, providing a solid foundation to build our solution upon.

Throughout the Software Engineering (SWE) lifecycle, the team encountered and surmounted many challenges but navigated the intricacies and adhered to a SCRUM process throughout. Having to embrace agile methodologies and conduct sprints and retrospectives while working in a novel sector was challenging. We ensured continuous improvement and documentation with the help of tools like Trello and community interaction. Additionally, we learned skills to translate our complex technical solution into a relatable business value.


Self-Sovereign Identity (a.k.a. Decentralized Identity) is rapidly gaining momentum worldwide. The European Union will mandate digital identity under eIDAS 2.0, which now embraces SSI, requiring member states to offer a digital identity wallet to 80% of citizens by 2030. The European self-sovereign identity framework (ESSIF) is part of a joint initiative from the European Commission and the European Blockchain Partnership (EBP), which involves 27 EU countries plus some additional non-EU members, to deliver EU-wide cross-border public services using blockchain technology. 

In the Americas, there are accelerating SSI initiatives across the US, Canada, and Latin America. In the US, the states of Utah and Rhode Island have ongoing SSI initiatives. Canada has also outlined a DID ecosystem framework as part of a 2022 resolution on Ensuring the Right to Privacy and Transparency in the Digital Identity Ecosystem in Canada, OPCoC 2022. British Columbia provincial government has led the charge on SSI and, in collaboration with Ontario and other provinces, is working towards a nationwide solution. Latin America and Caribbean Chain (LACChain) is another regional alliance that has developed an ID Framework that addresses identifiers, verifiable credentials and presentations, digital wallets, and much more.  

SSI Adoption Around the World
SSI Adoption Around the World


Ledger-independent and portable DIDs and VC formats will be critical for enabling large-scale adoption. These benefits from VDRs built on general-purpose blockchains, such as Oracle's Hyperledger Fabric-based Blockchain Platform, are broadly used in many industries. Across the permissioned blockchain spectrum, roughly half of live blockchain deployments use Hyperledger Fabric. A VDR using Hyperledger Fabric will make it easier to implement SSI on currently used blockchain ledgers alongside other blockchain use cases. The easy availability of Hyperledger Fabric BaaS (e.g., OCI Blockchain Platform) makes it simpler and quicker for a B2B consortium to implement an SSI for its user base, e.g., patients of healthcare organizations (providers and insurers), consumers in retail or media & entertainment space, residents and users of state or national eGov services, etc. This project shows that it's possible to use a general-purpose blockchain platform delivered as a managed Blockchain-as-a-Service (BaaS) to support SSI use cases. 

Additional information on this and other Lehigh University blockchain projects completed in the capstone program this year, including another Oracle-sponsored project on Central Bank Digital Currency, are described in this Lehigh Blockchain post.


Members of the Lehigh University student team included Ari Carp '24, William Han '24, Adrian Ross '24, and Shun Ueda '25. Throughout this project, our team met weekly to discuss progress and pressing topics with sponsors from Oracle, including Mark Rakhmilevich and Bala Vellanki, who provided guidance on OCI, the blockchain platform, Hyperledger Fabric chaincodes, Hyperledger Aries frameworks, and other aspects of the project. We would also like to thank Professor Andrea Smith, an adjunct professor at Lehigh University, for coordinating the project and Professor Hank Korth of Lehigh University for additional support regarding blockchain technology.

Mark Rakhmilevich

Vice President, Blockchain Product Management

Mark is responsible for Blockchain strategy and products. He focuses on evolving Oracle Blockchain Platform and Oracle Database Blockchain Tables in the cloud and on-premises to meet the needs of customers and partners for scalable, secure, production-ready platform to support blockchain solutions. He helps to guide customers and partners around the world in applying blockchain technology to deliver on key business outcomes – accelerating growth, reducing costs and friction in business ecosystems, reducing risk and fraud, and bringing to market innovative solutions that solve real-world societal challenges. Mark facilitates customers’ journey from rapid experimentation to live production through discovery, sharing industry use cases and best practices, and advising on solution architecture.

Previous Post

Extending CBDC Scalability and Resilience with Oracle Database Blockchain Tables

Mark Rakhmilevich | 17 min read