Self-sovereign identity (SSI) for enterprise use cases

Traditional federated identity (SAML, OAuth, OIDC) federates identity assertions through a central identity provider (Google, Microsoft, your enterprise IdP) — the identity provider mediates every authentication event and can see and control all identity interactions. SSI removes this central intermediary: credentials are issued once, stored in the holder's wallet, and presented directly to verifying parties without contacting the original issuer. The holder controls what is shared, with whom, and when — and the issuer has no visibility into where credentials are used after issuance. This is the fundamental shift from "identity as a service" to "identity as property."

DIDs are globally unique identifiers specified by the W3C that can be resolved to a DID Document containing the subject's public keys and service endpoints, without requiring a central registry. A DID looks like: did:web:example.com or did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9. The DID method (web, indy, jwk, etc.) specifies how the DID Document is published and resolved. Unlike traditional identifiers (email, username) that are controlled by a service provider, DIDs are controlled by the entity that holds the corresponding private key. The W3C DID Core specification became a W3C Recommendation in 2022.

The EU Digital Identity Wallet (EUDIW) is a mandatory initiative under eIDAS 2.0 requiring all EU member states to provide citizens and residents with a digital wallet for storing and presenting identity credentials — including national ID, driving licence, professional qualifications, and medical records — across all EU member states and private sector services. Banks, financial institutions, telecoms operators, and other regulated entities in the EU must accept EUDIW credentials for customer identity verification. Enterprises in the EU need to build EUDIW-compatible verifier infrastructure before the 2026 mandatory rollout deadline to remain compliant with KYC and onboarding regulations.

Selective disclosure allows a credential holder to share only specific attributes from a credential rather than the entire credential. For example, an age verification credential might contain name, birthdate, address, and national ID number — but for an age-gated purchase, the holder only needs to prove "age is over 18." With selective disclosure, the holder presents a cryptographic proof that the age attribute satisfies the condition, without revealing the actual birthdate or any other attributes. This is implemented using BBS+ signatures (used in Hyperledger Aries) or SD-JWT (Selective Disclosure JWT, used in EUDIW) which allow attributes to be disclosed individually while the credential's signature remains valid.

Credential revocation in SSI is more complex than traditional systems because the issuer cannot directly communicate revocation to verifiers (no central authority). Common approaches include: revocation registries on a verifiable data registry (blockchain or similar) that verifiers check in real time — the credential contains a reference to the revocation registry and an index; status lists (W3C Bitstring Status List) where the issuer publishes a signed status list URL and the credential's status is a bit in that list; and Short-lived credentials that expire quickly (hours or days) eliminating the need for explicit revocation for many use cases. Each approach trades off privacy (revocation registry checks may reveal usage patterns) against simplicity.

OID4VC (OpenID for Verifiable Credentials) is a protocol suite that extends OpenID Connect to support issuance and presentation of Verifiable Credentials. It has three specifications: OID4VCI (Credential Issuance) for issuing VCs to wallets using OAuth 2.0 flows; OID4VP (Verifiable Presentations) for presenting VCs to verifiers; and SIOP v2 (Self-Issued OpenID Provider) for wallet-based authentication. OID4VC is the protocol specified by the EU for the EUDIW ecosystem and is rapidly becoming the interoperability standard for cross-ecosystem SSI. It bridges traditional OIDC-based identity systems and the decentralised credential world.

No. Blockchain is one option for the Verifiable Data Registry (VDR) that stores DID Documents and revocation registries, but it is not required. The DID:web method stores DID Documents as JSON files served from a web domain — no blockchain involved. Status list revocation uses HTTPS endpoints. Many enterprise SSI deployments use non-blockchain VDRs to avoid the performance, governance, and cost constraints of blockchain. Blockchain-based VDRs (Hyperledger Indy/Besu, Cheqd) offer stronger decentralisation and censorship resistance but add operational complexity. Choose the VDR based on your trust model requirements, not because blockchain is assumed to be necessary.

Centralised verifiable credentials platforms (LinkedIn Skill Badges, Credly, Accredible) issue credentials that live on the platform's servers — revocation and access are controlled by the platform. If the platform shuts down or revokes access, your credentials disappear. SSI verifiable credentials following W3C standards are held in the credential owner's wallet, portable across any standards-compliant verifier, and not dependent on the continued operation of any particular platform. The trade-off is that SSI credentials require a standards-compliant ecosystem to verify — the issuer, holder, and verifier must all support the same standards — while centralised platform credentials can be verified by anyone with access to the platform.