SAML has been the backbone of enterprise single sign-on for more than two decades. If you have designed identity architecture for a large organization, you almost certainly know its strengths: a mature federation model, broad IdP and SP support, and deep integration with enterprise directories. You also know its limitations, XML-heavy payloads, tight coupling between IdPs and relying parties, and an architecture built for an era when "cross-domain" meant two systems inside the same corporate network.
Verifiable credentials represent a different approach to the same fundamental problem: how do you prove that a claim about an identity is trustworthy? Rather than routing trust through a central identity provider at authentication time, verifiable credentials embed the proof in the credential itself, cryptographically signed by an issuer, held by the user, and verifiable by any relying party with access to the issuer's public key.
This article is for identity architects and IAM engineers who know SAML well and want a technically honest comparison: what verifiable credentials do differently, where SAML remains the right choice, and how the two can coexist in a modern identity architecture.
How SAML Works: A Quick Refresher
SAML (Security Assertion Markup Language) is a standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). When a user tries to access an SP, the SP redirects them to the IdP, the IdP authenticates the user, and then it sends a signed XML assertion back to the SP asserting that the user is who they claim to be and optionally what attributes they carry.
The trust model SAML was built for
SAML's trust model is federation-based. Before any assertion can be trusted, the SP and IdP must establish a federation agreement, they exchange metadata, register each other's certificates, and configure a bilateral trust relationship. Once that relationship is in place, assertions flow through it automatically.
This model works extremely well inside an organization or a defined partner ecosystem where every federation relationship can be set up in advance. It works less well when the set of relying parties is open, when users need to prove attributes to organizations that have no prior relationship with the issuing IdP, or when the user, rather than the IdP, needs to hold and control their own identity data.
Where SAML's architecture creates friction
Three limitations in SAML become significant in modern application contexts. First, every new relying party requires a new federation agreement, which means scaling to many SPs requires significant operational overhead. Second, the IdP is always in the loop at authentication time, if the IdP is unavailable, authentication fails, regardless of how established the identity is. Third, SAML assertions are designed to be consumed immediately and are not intended to be held by the user as a portable artifact they can present later or to a different party.
How Verifiable Credentials Work
Verifiable credentials are cryptographically signed, machine-readable claims issued by an organization (the issuer) to a person or entity (the holder), who stores them in a digital identity wallet and presents them to relying parties (verifiers) as proof of their attributes.
The key architectural difference from SAML is that the proof is self-contained. The issuer signs the credential when it is issued; the verifier checks that signature against the issuer's public key at verification time. The issuer does not need to be online or involved in the verification. There is no pre-established federation relationship between issuer and verifier.
The three-party model: issuer, holder, verifier
Every verifiable credential interaction involves three parties. The issuer creates and signs the credential, this might be an employer issuing a proof of employment, an IDV provider issuing a verified identity credential, or a government issuing a digital driving license. The holder receives the credential, stores it in a digital identity wallet, and controls when and to whom it is presented. The verifier receives the credential presentation, checks the issuer's signature, confirms the credential has not been revoked, and decides whether to trust it.
This model makes identity portable in a way SAML cannot. A holder can present the same credential to any number of verifiers without the issuer knowing it happened and without any pre-existing relationship between issuer and verifier.
Standards underlying verifiable credentials
Verifiable credentials are defined by the W3C Verifiable Credentials Data Model. They rely on Decentralized Identifiers (DIDs) for issuer and holder identity, cryptographic identifiers anchored to registries (such as a blockchain or a web domain) rather than a central directory. Presentation protocols include OpenID for Verifiable Credentials (OID4VC), which is emerging as the dominant transport layer for VC-based identity flows.
Verifiable Credentials vs SAML: Key Dimensions Compared
Trust model
SAML: trust is federated. The SP trusts assertions from an IdP because they have a bilateral agreement. Trust is pre-established, bilateral, and requires operational setup for each new relationship.
Verifiable credentials: trust is cryptographic. A verifier trusts a credential because the issuer's signature is valid and the issuer's public key is anchored to a verifiable registry. No pre-existing relationship between issuer and verifier is required. Trust scales to new relying parties without additional setup.
Data portability
SAML: assertions are ephemeral. They are generated at authentication time, consumed by the SP immediately, and not retained by the user as a portable artifact. A user's identity lives in the IdP, not with the user.
Verifiable credentials: credentials are portable artifacts held by the user. A credential issued once can be presented repeatedly, to different verifiers, without involving the issuer. Identity travels with the user across systems, channels, and organizations, which is the foundation of reusable identity.
Privacy
SAML: the IdP is aware of every authentication event, it knows when, where, and how often a user authenticates to each SP. Attributes sent in assertions may be broader than what the SP actually requires, because SAML has limited native support for selective disclosure.
Verifiable credentials: the issuer is not notified when a credential is presented. Holders can use selective disclosure and zero-knowledge proofs to share only the specific attributes a verifier needs, without revealing the full credential. This is a fundamental privacy advantage in contexts where data minimization matters.
Revocation
SAML: revocation relies on session expiry and IdP-controlled assertion lifetimes. If an IdP wants to revoke access for a user, it stops issuing assertions for them. This works in real time because the IdP is in the loop at every authentication event.
Verifiable credentials: credentials support explicit revocation registries. An issuer can mark a credential as revoked, and verifiers check the revocation status at verification time. The credential is no longer accepted anywhere as soon as it is revoked, without the issuer needing to be contacted directly.
Implementation complexity
SAML: mature and well-understood. Every major enterprise IdP and most SaaS products support it. The setup complexity is in configuring federation agreements and managing certificate rotation, not in the standard itself.
Verifiable credentials: the standards (W3C VC, DIDs, OID4VC) are mature and production-ready, but the ecosystem of out-of-the-box SP support is still growing. Implementing VC-based flows requires integrating an issuance and verification API, a wallet component, and a DID registry. Platforms like Truvera package these components into APIs and SDKs that significantly reduce the integration surface, but the integration is more involved than connecting to a SAML IdP.
When to Use SAML and When to Use Verifiable Credentials
SAML is not going away, and it should not. There are scenarios where it remains the right tool.
Use SAML when: you need SSO across a defined set of enterprise applications where federation agreements can be set up and maintained, you are operating inside a single organization or a small, stable partner ecosystem, and your primary use case is authentication (proving the user is logged in), not attribute portability.
Use verifiable credentials when: you need to make identity portable across organizational boundaries where pre-established federation is impractical, when users need to carry and control their own identity data (employment credentials, professional licenses, verified personal identity), when you need privacy-preserving attribute disclosure, when you are building identity flows that involve partners, customers, or external verifiers you cannot pre-configure, or when your use cases include reusable KYC, cross-domain authentication, or AI agent identity.
How Verifiable Credentials and SAML Can Coexist
In most enterprise environments, the transition from SAML-based federation to verifiable credentials will be gradual. SAML handles internal SSO efficiently and reliably; there is no compelling reason to rip it out for use cases it handles well. Verifiable credentials can be introduced alongside it to address the use cases SAML cannot: external identity portability, user-held credentials, cross-organizational trust, and identity for non-human principals like AI agents.
A practical hybrid architecture might look like this: SAML (or OIDC) continues to handle employee authentication to internal applications. Truvera's credential issuance API is used to issue verifiable credentials to employees that they can present to external partners, customers, or service providers. The two systems operate in parallel, each handling the identity flows it was designed for.
Truvera is built to work alongside existing IAM infrastructure, it does not require replacing the SAML federation in place. It adds a portable credential layer that extends identity beyond the boundaries that federation-based SSO was designed to serve. Organizations exploring what a unified identity architecture looks like across internal and external systems can find a practical starting point in the Truvera IAM industry page.
Choosing the Right Standard for the Right Problem
The verifiable credentials vs SAML question is not a binary choice. SAML is mature, reliable, and well-suited to federated SSO within bounded organizational contexts. Verifiable credentials are purpose-built for portable, user-held identity that travels across systems, organizations, and channels without requiring pre-established federation agreements.
The most resilient identity architectures will use both: SAML for the internal SSO use cases it handles well, and verifiable credentials for the cross-boundary, user-controlled, privacy-preserving identity flows that SAML was not designed for. If your organization is starting to hit the edges of what federation can deliver, and you want to understand what a verifiable credential layer would look like alongside your existing IAM stack, request a free consultation with Dock Labs.
Frequently Asked Questions About Verifiable Credentials vs SAML
What is the main difference between verifiable credentials and SAML?
SAML routes trust through a central Identity Provider that is always involved at authentication time. Verifiable credentials embed the proof in the credential itself, cryptographically signed at issuance, held by the user, and verifiable by any party with the issuer's public key. The IdP does not need to be online or involved when a credential is presented.
Can verifiable credentials replace SAML for enterprise SSO?
For internal SSO across enterprise applications, SAML (or OIDC) remains the practical choice. Verifiable credentials are better suited for identity flows that cross organizational boundaries, require user-held portable credentials, or need privacy-preserving attribute disclosure. The two standards solve overlapping but distinct problems.
Do verifiable credentials require a blockchain?
Not necessarily. DIDs can be anchored to a blockchain (as Truvera uses the cheqd network for certain DID methods), but they can also be anchored to web domains or other verifiable registries. Personally identifiable information and credentials themselves are not stored on-chain.
What is selective disclosure and does SAML support it?
Selective disclosure lets a credential holder share only a subset of the attributes in their credential, proving they meet a condition without revealing the underlying data. SAML has limited native support for this; verifiable credentials, particularly those using zero-knowledge proofs, support selective disclosure as a core capability.
How does revocation differ between SAML and verifiable credentials?
In SAML, revocation works through the IdP stopping the issuance of assertions. In verifiable credential systems, an issuer publishes a revocation status that verifiers check when a credential is presented. Both approaches work; the VC model is more suited to credentials that are held by users and presented offline or to parties with no connection to the issuer.
Is there a standard transport protocol for verifiable credentials like there is for SAML?
Yes. OpenID for Verifiable Credentials (OID4VC) has emerged as the dominant transport protocol, building on the OAuth/OIDC ecosystem that enterprise developers already know. This makes it relatively straightforward to extend existing OIDC infrastructure to support verifiable credential issuance and presentation.
What does a migration from SAML toward verifiable credentials look like in practice?
Most organizations do not need a migration, they need a parallel layer. SAML continues to handle internal SSO. Verifiable credentials are introduced for the identity flows that cross organizational boundaries or require user-held, portable credentials. Truvera's API and SDK make it possible to add that layer without rebuilding existing identity infrastructure.
