Introduction

Trust frameworks are how governments, enterprises, and communities manage identity — the shared rules that let organisations trust each other’s credentials. But the digital identity landscape is shifting fast. Regulators are tightening privacy rules, boards are asking tougher governance questions, and citizens are demanding more control over their own data. In this environment, frameworks built on centralised trust and federation are starting to show their age.

Verifiable Credentials (VCs) present the opportunity to redesign these frameworks around user agency, cryptographic proof, and technical enforcement of consent. This isn’t just an upgrade to the plumbing of identity. It’s a fundamental rewriting of the rules.

The Limits of Federation

Federated identity systems gave us an important step forward — single sign-on across institutions, trust agreements that allowed users to reuse credentials, and reduced friction for service providers. But their limitations are now clear.

In a federated model, the subject rarely sees what information is shared. Logging in through an identity provider can leak more data than intended, with “permission” resting on convention rather than technical enforcement. Federation also creates structural issues: universities forced to rely on outdated federation for transcript sharing, hospitals dependent on fragile central authorities for access to medical records, or government agencies grappling with data leaks from trust brokers.

These weaknesses are not theoretical. When Okta’s systems were compromised in 2022 and 2023, customers had little visibility into what data was exposed or how trust relationships were affected. Subjects had no say in what information was accessed, and their privacy depended entirely on the federation provider’s opaque controls. They affect real-world outcomes in security, privacy, and citizen trust.

Perception vs Reality in Federation

Most end users assume that federated identity is simple: they click “Sign in with X”, are redirected to their identity provider, and then returned to the service. The expectation is that only the necessary information is shared, and that their explicit consent is required for any data transfer.

Perceived flow:

sequenceDiagram
    participant User
    participant IdentityProvider as Identity Provider
    participant Service
    User->>IdentityProvider: Sign in
    IdentityProvider-->>User: Authenticate and request consent
    User->>IdentityProvider: Grant consent
    IdentityProvider-->>Service: Share only necessary attributes
    Service-->>User: Grant access

However, the reality is more complex. In most federated systems, an additional entity—a federation broker—may be present, and the actual data flows are opaque to the user. Often, far more attributes are shared than strictly necessary, and the user’s “consent” is implied by the act of signing in, not enforced by technical controls.

Actual flow:

sequenceDiagram
    participant User
    participant IdentityProvider as Identity Provider
    participant FederationBroker as Federation Broker
    participant Service
    User->>IdentityProvider: Sign in
    IdentityProvider-->>FederationBroker: Send full attribute set<br/>(e.g., name, email, role, group memberships)
    FederationBroker-->>Service: Forward attributes (often unfiltered)
    Service-->>User: Grant access

In federated identity, the Identity Provider also learns which Service Provider the user is accessing, creating an additional privacy concern, as it enables monitoring of user activity across services. In contrast, with Verifiable Credentials, issuers are not in the loop every time a credential is presented, enhancing user privacy by design.

Verifiable Credentials and Trust by Design

VCs flip this model. Instead of identity being brokered by a federation, claims are issued directly by a trusted authority to the subject, who can then present them anywhere. Each credential carries its own cryptographic proof of authenticity.

Selective disclosure allows subjects to share only what’s necessary. A digital licence can prove you are over 18 without revealing your full date of birth. A qualification credential can prove a certification is current without exposing student ID numbers or personal data. Trust is not assumed; it’s verified by design.

This approach moves beyond black-box permissions. The subject is at the centre, with real control, and relying parties get assurance without dependency on federation hubs.

Verifiable Credentials in Action

Verifiable Credentials operate through two key processes: issuance and presentation. During issuance, a trusted issuer verifies the subject’s eligibility and issues a credential directly to the subject’s digital wallet. The subject stores this credential securely and can present it whenever needed, without the issuer being involved each time.

Issuance flow:

sequenceDiagram
    participant Issuer
    participant User
    participant Wallet
    Issuer->>User: Verify eligibility
    Issuer-->>Wallet: Issue Verifiable Credential (VC)
    User->>Wallet: Store VC securely

When the subject needs to prove a claim, they present a proof derived from the credential via their wallet to a verifier. The verifier checks the cryptographic proof against the issuer’s public keys and revocation registries to confirm authenticity and validity. Importantly, the issuer is not involved in this step and does not track when or where the credential is used.

sequenceDiagram
    participant User
    participant Wallet
    participant Verifier
    participant Issuer
    User->>Wallet: Request proof presentation
    Wallet->>Verifier: Present proof with selective disclosure
    Verifier->>Issuer: Check public keys and revocation status
    Verifier-->>User: Grant access or service

This model contrasts sharply with traditional federation, where identity providers mediate every authentication event and often see all user activity. With Verifiable Credentials, the subject has full control over what information is shared and when, enabling privacy by design. Selective disclosure allows users to reveal only the minimum necessary data, and issuers do not track or monitor credential usage, preserving user autonomy and confidentiality.

Selective disclosure in action

Selective disclosure allows the user to prove specific facts without revealing the full underlying data. For example, a user can prove they are over 18 without sharing their full date of birth. This capability enhances privacy by limiting the information shared to only what is strictly necessary.

sequenceDiagram
    participant User
    participant Wallet
    participant Verifier
    User->>Wallet: Request proof of age
    Wallet->>Verifier: Present proof: "Over 18" (DOB hidden)
    Verifier-->>User: Grant access based on proof

This selective sharing ensures that sensitive personal information remains confidential while still enabling trustworthy verification.

Governance Reimagined

Rewriting trust frameworks around VCs means more than technology. It requires a new governance lens. Instead of static, top-down agreements between a handful of large institutions, governance becomes distributed and adaptive.

International standards such as ISO’s work on decentralized identifiers, or Europe’s eIDAS2 regulation, are already pointing towards frameworks that assume cryptographic verification as the baseline. Regulators can shift from mandating trust in specific authorities to defining the assurance levels, revocation rules, and liability models that apply across ecosystems.

This doesn’t weaken governance — it strengthens it by making policies transparent, enforceable, and adaptable to new sectors or technologies without rebuilding the entire trust fabric.

Practical Impacts

The impacts are wide-ranging. Governments can issue digital driver’s licences or life-event certificates as verifiable credentials that work across jurisdictions. Employers can issue workplace certifications, safety cards, or clearances that can be instantly verified without phone calls or paper checks. Health providers can enable patients to share vaccination or prescription credentials securely across borders.

For organisations, this reduces the operational burden of manual verification and lowers risk by removing reliance on centralised data stores. For users, it means autonomy, privacy, and confidence that their data is only ever shared on their terms.

Questions Raised

While Verifiable Credentials rewrite the rules of trust frameworks, they also raise important questions that organisations and regulators must address:

• How will legacy systems transition to VC-based models without disrupting services?
• What are the risks of decentralization (e.g., wallet loss, issuer revocation)?
• How will assurance levels be standardized across jurisdictions?

These questions don’t undermine the promise of VCs — they highlight the areas where collaboration, standards, and innovation are still required.

Conclusion

Verifiable Credentials are not simply another identity standard. They are a way to embed trust into the very design of digital systems. For trust frameworks, that means moving beyond federation and into an era where trust is provable, distributed, and user-centric.

The rules are being rewritten. Organisations that adapt early will shape the standards that follow, building systems that are more secure, more resilient, and more respectful of the individuals they serve.

At UNIFY, we are already seeing this shift with clients who want pilots to evolve into production ecosystems. From a CTO perspective, my focus is on making sure our architecture, delivery models, and product integrations anticipate these new trust rules rather than retrofit to them. That means making selective disclosure, privacy by design, and interoperability the defaults — not afterthoughts.

We are committed to helping our clients navigate this transition — from pilot projects to production-ready ecosystems — and ensuring they lead as the future of trust takes shape.

Let’s connect!