Self-Sovereign Identity on Oracle Blockchain with Privacy-Enhanced Verifiable Credentials

Important identity documents, such as driver’s licenses and birth certificates, are often stored in physical forms, which are vulnerable to damage and loss. They are also prone to human error during verification and normally take a long time to issue or renew. Even worse, when we need to share credentials online, like photos of our passport, the methods we use are prone to being intercepted, faked, or cause us to share more information than required, raising privacy concerns.

In addition, we frequently rely on email addresses or social logins to access digital services like bank accounts, healthcare records, government services, or even online shopping—all at the cost of handing over control of our personally identifiable information (PII). This not only often gets sold to third parties without our consent, but also frequently becomes subject to mishandling and data breaches. The convenience of centralized identity services comes at the cost of security and privacy, leaving our data at risk. But there’s a better way. Self-Sovereign Identity (SSI) can transform the way we share information and improve privacy in important aspects of everyday life.

Just over a year ago, we published a blog post that describes Self-Sovereign Identity (SSI) and its implementation on the Oracle Blockchain Platform (OBP). If SSI is new to you, then you likely want to start there. This post briefly re-introduces SSI but quickly dives deeper into more recent developments: anonymous credentials in the context of healthcare, performance and security improvements, and integration of more recent advances and protocols.

Verifiable Credentials in Self-Sovereign Identity Ecosystem

The previous blog details a collaboration with a Lehigh University student capstone project, expanding on an even earlier capstone that developed a proof of concept W3C Verifiable Credential Data Model (VC-DATA-MODEL), to provide a verifiable data registry (VDR) on the Oracle Blockchain Platform. This VDR, a key component of Decentralized Identity, serves as a digital ledger for decentralized identifiers (DIDs), credential issuer information, revoked credentials, and credential type details. As shown in the diagram below, a VDR enables the interaction between Issuers, Holders, and Verifiers—the 3 corners of the so-called “Triangle of Trust” in self-sovereign identity.

A strong anchor for decentralized identifiers or DIDs enables them to be linked with a set of claims called Verifiable Credentials or VCs. Users (Holders) retain the actual claims in their wallet and present them to Verifiers (a.k.a. Relying Parties) along with signatures allowing Verifiers to ensure that claims originate from the specified Issuers and are about the Holders who present them to the Verifier. In other words, users decide what information to share and with whom, which is at the heart of self-sovereign identity. 

Oracle’s VDR solution in Oracle Blockchain Platform leverages Hyperledger Fabric’s immutable ledger and smart contracts to securely anchor public cryptographic material for Self-Sovereign Identity (SSI) applications. The cryptographic verifiability enabled by the blockchain enables organizations to meet higher Identity Assurance Levels (IAL) as defined by NIST SP 800-63-3 and to align with the EU eIDAS Regulation for electronic identification, ensuring the authenticity, immutability, and provenance of decentralized identity data across global ecosystems.

On top of the VDR, the solution provides an agent service based on the OpenWallet Foundation’s (OWF) Credo TypeScript framework—an evolution of Hyperledger Aries—with Oracle enhancements for enterprise-grade scalability, resilience, and performance. The agent framework based on Credo uses Decentralized Identity Foundation’s DIDComm protocol, based on secure messages that are encrypted, signed, and transport-agnostic, to issue and verify credentials through configurable workflows. It supports flexible credential formats, including SD-JWT, W3C JSON-LD, and, for stronger privacy protection, Hyperledger AnonCreds, which we describe below. This flexibility enables organizations to select the formats that best meet their privacy, interoperability, and trust requirements.

The OBP Decentralized Identity (DI) framework exposes standards-compliant RESTful and WebSocket APIs for interacting with the agents, enabling straightforward integration for Identity Managers issuing Verifiable Credentials (VCs) and Verifiers acting as Access Managers or Relying Parties. To further simplify adoption, a TypeScript SDK and a controller web portal are provided, reducing integration complexity and accelerating project ramp-up.

Although the standard W3C model (VC-DATA-MODEL) alludes to strong privacy, most Triangle-of-Trust implementations protect privacy only to some extent. Holders can disclose credentials without having to identify themselves or let the Issuer know that a credential they’ve issued is being verified by a 3^rd party.  However, the privacy is not complete. Holders usually must present the entire credential with all its claims to a Verifier and Verifiers can correlate a user’s DID across multiple presentations to deduce even more information. This would be like a nurse asking for your blood type, but you end up having to share your entire medical history instead.

Therefore, a new 2024 capstone project with four new Lehigh University students worked on addressing these privacy concerns (Elizabeth Pursell ‘25, Daniella Stokic ‘25, Michael Kaufman ‘25, Victor Carolino ‘25) by implementing support for Hyperledger AnonCreds—a privacy-enhanced Verifiable Credentials model with important benefits:

• Avoidance of correlatable identifiers: No correlatable identifiers are required in presenting data to a verifier.
• Verifier assurances: Credentials are bound to a holder secret, so verifiers know that credentials presented together were issued to the same holder providing the presentation—allowing claims from multiple VCs to be combined into a single presentation.
• Minimal data sharing: Data shared by holders to verifiers is minimized using selective disclosure and ZKP predicates. This allows sharing only the required claims and/or using predicates to prove set membership or numeric ranges (for claims related to age, income, years of specific experience, etc.) without disclosing actual values.

Zero Knowledge Proofs

Before going into the details, let’s gain some understanding of the zero-knowledge approach. In cryptography, a zero-knowledge proof (ZKP) is a method where one party convinces another that a statement is true, without disclosing any information beyond the fact that it’s true. This may sound impossible but let me illustrate the concept with an example.

Imagine two people, Peggy and Victor. Peggy, who knows a secret code, wants to prove to Victor that she can unlock a keypad-locked door inside a cave. The cave is shaped like a ring with the entrance on one side and the locked door on the other. They label the left and right paths A and B.

Victor waits outside while Peggy enters the cave. She takes one of the paths, but Victor doesn’t know which. After a moment, Victor calls out either “A” or “B,” and Peggy must return and exit via that path. To enter via one way and exit via the other, she must pass through the door, which is only possible if she has the correct code to open it. If she doesn’t know the code, she can only return correctly if she happened to enter on the path Victor calls. The chances of returning correctly without knowing the code are 50%. If they repeat this process 20 times, the chance she responds correctly to all challenges drops to 1 in 2^20 (less than 0.000001%).

If this happens, Victor can be highly confident that Peggy knows the secret code, because the odds of guessing right that many times in a row are so small. Using this iterative process, Peggy has demonstrated to Victor that she knows the code without actually disclosing it. This is a simplified example; you can learn more on the Wikipedia page, where this example came from.

Enhancing Privacy with Hyperledger AnonCreds

Now that we have explained this powerful new approach, let’s revisit Self-Sovereign Identity (SSI) and, more specifically, verifiable credentials (VCs). As mentioned briefly before, not all VCs are created equal. Most implementations of the W3C VC-DATA-MODEL, are easy to understand, but offer limited privacy. The credential with multiple claims has a single signature applied, which means it needs to be presented in its entirety for signature to be verified. Selective Disclosure JSON Web Tokens (SD-JWT) improve on this but require issuing a separate credential for every usage to avoid correlation—creating several other issues. Hyperledger AnonCreds—short for “Anonymous Credentials”, on the other hand, stands out as the only format that truly ticks all the boxes for robust privacy protection, thanks to their use of ZKPs.

AnonCreds use advanced cryptographic methods during both issuance and presentation. For instance, when a credential is issued, only the Holder sees the final copy, while the Issuer sees a version with some attributes “blinded”. This ensures the issuer cannot collude to correlate one verifiable presentation (VP) with another. Additionally, this enables the Holder to prove claims (like signature or attribute validity) without revealing the underlying values when presenting a credential (a.k.a. making a presentation). For example, the Holder can prove they have valid citizenship claim issued by the government without disclosing any PII. They could also prove they are over a certain age, have sufficient insurance coverage, and that they are in a health network—all at once—without disclosing their identity.

AnonCreds—specifically AnonCreds version 1 (ACv1)—are more widely adopted in enterprise production SSI solutions, for example by the Government of British Colombia in Canada, and used by other organizations like IDunion and the IATA Travel Pass.

Now things will get technical—how is this implemented? The diagram and explanation below give an overview of AnonCreds v1 data objects, how they relate, and who owns or receives each one.

Let’s focus on the verifiable data registry (VDR) where the schemas and credential definitions are maintained, as these are the components the students helped to integrate into the Oracle Blockchain Platform (OBP) Decentralized Identity solution. The other data objects are adapted from the open-source AnonCreds v1 implementation (anoncreds-rs) and the OpenWallet Foundation Credo framework, which follows Hyperledger Aries Interop Profile/RFCs (recently moved to the Decentralized Identity Foundation).

AnonCreds relies on a VDR, a public registry (often a blockchain ledger) that stores tamper-evident public data for non-repudiation. As mentioned, a previous capstone project implemented a VDR service on OBP using smart contracts, which the latest project extended to support schemas and credential definitions for AnonCreds.

Schemas are public reusable templates that define the attributes of AnonCreds credentials and can be published to the VDR by an Issuer. The team created this object and built the corresponding RESTful endpoints to manage it.

{
  "issuerId": "did:orcl:74acabe2-0edc-415e-ad3d-c259bac04c15",
  "name": "PrescriptionRecord",
  "version": "1.0.0",
  "attrNames": ["patientName", "dob", "medicationName", "dosage", "prescribingDoctor", "prescriptionDate", "expirationDate"]
}

Example 1. Simplified OBP ACv1 Schema for a Prescription Record

Issuers then create a credential definition (CredDef), linking it to a Schema. This enables Issuers to issue credentials to Holders and allows Verifiers to validate them. A CredDef consists of a private part (which the students didn’t need to handle) and a public part that includes the Issuer’s public keys and is stored on the VDR. The team followed a similar process here in creating the object and testing it throughout the service.

{
  "issuerId": "did:orcl:74acabe2-0edc-415e-ad3d-c259bac04c15",
  "schemaId": "did:orcl:SGrjRL82Y9ZZbzhUDXokvQ/anoncreds/v1/SCHEMA/PrescriptionRecord/1.0.0",
  "type": "CL",
  "tag": "latest",
  "value": {
    "primary": {
      "n": "779...397",
      "r": {
        "patientName": "294...298"",
        "dob": "650...011",
        "medicationName": "521...922",
        "dosage": "410...200",
        "prescribingDoctor": "226...757",
        "prescriptionDate": "774...977",
        "expirationDate": "750..893",
        "master_secret": "432...445"
      },
      ...
    }
  }
}

Example 2. Simplified OBP ACv1 Credential Definition (CredDef) for a Prescription Record

As you can see, the CredDef is similar to the Schema. It includes all attributes, each paired with a dedicated public key fragment. This approach allows Holders to combine claims from multiple credentials in a single presentation, sharing only the information the Verifier needs and nothing more. In the example above, imagine you are picking up your prescription. The date of birth attribute (‘dob’) in the credential might be useful for another doctor to comprehend the dosage and prescription, but it is superfluous for picking up the order if the pharmacy trusts the doctor’s judgment. With AnonCreds, we could create a presentation that omits this attribute but still verifiably shares the rest.

Notice the addition of master_secret (aka. the link secret) which is a special attribute. The link secret also enables being able to mix and match claims by acting as a shared attribute across the Holder’s credentials to prove they were all issued to the same person. Therefore, to avoid mass-surveillance tracking, its value is determined by the Holder and unknown to the Issuer and Verifier. When requesting a credential, the Holder sends the Issuer a blinded link secret to include in the credential. The Issuer never sees the actual value but signs it along with the other attributes. By doing this for every credential, the Holder can later prove to a Verifier that all credentials were issued to the same individual, using a zero-knowledge proof for the link secret.

Once the VDR enhancements were completed, the team integrated the new endpoints into the OBP-VDR module in Credo and passed the data to the relevant APIs in @credo-ts/anoncreds. This established the connection needed to enable Holders and Verifiers to locate trustworthy information about the Issuer.

"credential": {
  "anoncreds": {
    "schema_id": ".../SCHEMA/PrescriptionRecord/1.0.0",
    "cred_def_id": ".../CRED_DEF/PrescriptionRecord",
    "rev_reg_id": "172",
    "values": {
      ..
      "patientName": {
        "encoded": "Alice"
      },
      "dosage": {
        "encoded": "11mg"
      },
      "expirationDate": {
        "encoded": "2025-11-15 19:00:00.000"
      }
      ..
    },
    "signature": { # signature of issuer
      "p_credential": {
        "m": "71973..",
        ..
      },
      "r_credential": "56172..”
    },
    "signature_correctness_proof": "187071..",
    "rev_reg": "rev_reg:4xE68b..",
    "witness": "25934..”
  }
}

Example 3. Simplified OBP ACv1 Verifiable Credential (VC) for Alice’s Prescription Record

From there, we ensured the solution worked end-to-end, while integrating it with other relevant concepts. In some cases, all the Holder’s claims must come from a trusted Issuer, but in other situations, Verifiers may simply require additional user input alongside proof of identity. While one option would be to request this information afterward, this can raise concerns about authenticity and require multiple messages, making the process less efficient.

Instead, we use a process called self-attestation, where a user can add a self-attested attribute to a verifiable presentation. This approach allows the user to directly attest to certain information—such as providing their blood type or allergies—without needing to rely on an Issuer for each piece of data.

"presentation": {
  "proof": {
    "proofs": [
      {
        "primary_proof": {
          "eq_proof": {
            "revealed_attrs": {
              "dosage": "33034..",
              "patientName": "85649..",
              "m": {
         "dob": "28313.."
                "master_secret": "34558..",
              },
            },
            "ge_proofs": [
              {
          "predicate": "not_expired",
          "u": "32476.."
        }
        ]
      }
    },
       "non_revoc_proof": "51888.."
    ],
    "aggregated_proof": "10311..",
  },
  "requested_proof": {
    "revealed_attrs_groups": {
      "reveal_name_and_dosage": {
        "name": { "encoded": "Alice" },
        "dosage": { "encoded": "11mg" }
      }
    },
    "self_attested_attrs": {
      "allergies": "peanuts"
    },
    "unrevealed_attrs": {
      "dob": "84538.."
    },
    "predicates": {
        "not_expired": {
        "name": "expirationDate",
        "p_type": ">=",
        "p_value": "2025-04-02 07:34:59.807",
        "restrictions": [
          {"cred_def_id": "CRED_DEF/PrescriptionRecord"}
        ]
      }
    }
  },
  "identifiers": {
    "schema_id": "SCHEMA/PrescriptionRecord",
    "cred_def_id": "CRED_DEF/PrescriptionRecord"
  }
}

Example 4. Simplified OBP ACv1 Verifiable Presentation (VP) for Alice’s Prescription Record

Performance Advantages

Another one of our goals was to improve performance. While AnonCreds are a significant improvement over the current practices, they are not entirely new. Originally, AnonCreds served as the native credential for Hyperledger Indy, a comprehensive decentralized identity solution with its own custom ledger. However, Indy has since been phased out, and its best features have evolved into more robust, standalone projects, such as AnonCreds v1 and Aries. Despite this progress, no new underlying ledger has emerged to adequately address the scalability and performance issues that many in the ecosystem still face.

The Oracle Blockchain Platform (OBP) aims to address these issues—combining permissioned Hyperledger Fabric blockchain and OCI (Oracle Cloud Infrastructure) security with the strongest privacy capabilities and usability across multiple applications—make it ideal for enterprises, financial and government organizations looking to deliver SSI benefits to the users. Our preliminary benchmarks reveal a substantial performance boost in read operations compared to previous Indy benchmarks (Dunphy, 2022). Similar to that publication, we configured our client to send 1,000 transactions for each operation. The table below shows latency in milliseconds and the lower the number, the better.

As shown, OBP outperformed across all categories, even when validating with a larger number of nodes. Additionally, our test achieved a 0% error rate, (Dunphy’s paper does address this factor). We observed more than a 2x improvement in read performance from the ledger, which is particularly significant in real-world scenarios where reads are the most frequent transactions. It is also worth noting that there is no noticeable degradation due as we raise the load from 15 to 50 transactions per second (TPS). Additionally, we introduced new functionalities that enable querying the entire ledger for analytics. We hypothesize that AnonCreds object writes take longer than DID writes due to the need to check the IssuerId (DID) on the ledger.

Future Innovation

Working with Credo and AnonCreds community we see several developments that will further strengthen these capabilities and simplify implementations.

For example, currently credential issuance and presentation requests are a little cumbersome. Issuers and, especially, verifiers need to follow the AnonCreds specification to take advantage of ZKP capabilities. Below is a sample presentation request, where the verifier wants the name and dosage revealed and expiration checked, thereby confirming that the subject has a valid prescription without all the details.

{
  "requested_attributes": {    
    "reveal_name_and_dosage": {
      "names": ["patientName", "dosage"],
      "restrictions": [
        {"issuer_id": "$ISSUER_DID"}
      ]
    }
  },
  "requested_predicates": {
    "not_expired": {
      "name": "expirationDate",
      "p_type": ">=",
      "p_value": "$NOW",
      "restrictions": [
        {"cred_def_id": "$CRED_DEF_ID"}
      ]
    }
  }
}

Example 5. Simplified OBP ACv1 Presentation Request for a Non-expired Prescription Record

However, work is on-going to streamline this experience. For example, in the fragment above, you can see an in-house technique—$VARIABLES which dynamically get replaced with environment variables just before requests are sent. Along the same lines the Digital Credentials Query Language (DCQL) is an emerging open-source tool that simplifies how verifiable presentations are requested across various formats. While support for AnonCreds is not yet available, our ongoing work is aimed at supporting this feature. Additionally, there are also efforts in Credo and AnonCreds Working Group to translate AnonCreds credentials to W3C VC-DATA-MODEL.

AnonCreds version 2 (ACv2) is under development. Its cryptographic library supports pluggable signature schemes and integrates a host of new Zero Knowledge Proof capabilities for enhancing privacy protection while retaining accountability. A similar library, DockNetwork crypto, also offers comparable features, but their interfaces differ and each are complex to use.

At the last two Internet Identity Workshops (IIW 39 & 40), our colleagues in Oracle Labs presented work on an abstraction they are developing to decouple credential formats (e.g., W3C VCDM, AnonCreds, etc.) from underlying ZKP libraries. The goal is crypto agility – enabling developers to switch between ZKP libraries when different versions or new and improved libraries arise. As a side effect, their contributions are already benefiting the respective libraries.

Future work will target the AnonCreds v1 credential format to leverage this abstraction, aiming to enable modern, efficient signature schemes without altering existing use cases. Additionally, they plan to expand the ACv1 presentation request to incorporate more advanced ZKP features supported by the above-mentioned libraries.

Another feature we are pursuing is to extend support for credential revocation on OBP. This leverages a revocation repository on OBP ledger and involves a two-step process: 1) a request from the Verifier asking the Holder to include a non-revocation proof (NRP) in the presentation, and 2) the Holder creating the NRP and including it in the presentation sent to the Verifier.

We are also working to integrate ACv1 with OpenID Connect protocols for verifiable credential issuance and presentations (OpenID4VC) – leveraging a more familiar and interoperable protocol for sharing credentials. This consists of three components:

• OpenID for Verifiable Credential Issuance – Defines an API and corresponding OAuth-based authorization mechanisms for issuance of Verifiable Credentials
• OpenID for Verifiable Presentations – Defines a mechanism on top of OAuth 2.0 to allow exchange of claims in the form of Verifiable Presentations
• Self-Issued OpenID Provider v2 – Enables end-users to use OpenID Providers (OPs) and therefore identifiers (e.g. DIDs) that they control

Decentralized Identity Powered by Oracle Blockchain 

A Self-Sovereign Identity (SSI) or decentralized identity solution built on the Oracle Blockchain Platform is paving the way for more secure, private, and user-centric identity management. By leveraging Verifiable Credentials based on Zero-Knowledge Proofs (ZKPs) and AnonCreds, this approach is redefining how data is exchanged across industries and in public services at local, state, and national levels.

The solution enhances privacy by avoiding correlatable identifiers, ensuring that credentials are cryptographically bound to their holders, and minimizing data exposure through selective disclosure and ZKP-based predicates. This empowers users with greater control over their personal information and makes Verifiable Credentials a more privacy-conscious method of digital identity.

In addition to improving user privacy, this approach enables more transparent and accountable data-sharing practices. It helps organizations comply with evolving data protection regulations while significantly reducing the risk of identity theft.

Globally, many governments and regions are adopting SSI. From the State of Utah in the U.S. and provinces in Canada, to the European Union’s ESSIF initiative—and ongoing efforts in India, China, Japan, South Korea, and Argentina—momentum is growing.

Oracle supports this evolution with enterprise-grade, permissioned blockchain technology. It underpins key SSI standards and supports a range of Verifiable Credential models, including W3C credential types, Selective Disclosure JSON Web Tokens (SD-JWT), and now AnonCreds. This provides a production-ready foundation with flexible credential formats, including some of the most advanced privacy-preserving options available.