Skip to main content
Version: 0.x

Trust Services in the VDC Ecosystem

Trust Services play a critical role in the Verifiable Digital Credential (VDC) ecosystem by providing the infrastructure necessary to establish and maintain trust between participants. These services primarily focus on two essential aspects: managing cryptographic trust through public key verification and handling credential revocation.

Public Key Trust Models

Trust in VDCs fundamentally relies on cryptographic verification of the issuer's digital signature. For this verification to be meaningful, verifiers must have confidence that the public key they're using genuinely belongs to the claimed issuer. Two primary approaches have emerged for managing this trust:

Certificate-Based Trust

The certificate-based approach extends traditional Public Key Infrastructure (PKI) concepts to the VDC ecosystem. In this model:

  1. Certificate Authorities (CAs): Trusted third parties issue digital certificates that bind an issuer's identity to their public key.
  2. Certificate Chains: Hierarchical trust relationships are established, with root CAs at the top of the trust chain.
  3. Certificate Validation: Verifiers check that certificates are valid, properly signed, and not expired or revoked.

Certificate-based trust models have several characteristics:

  • Leverage well-established PKI practices and technology
  • Clearly defined hierarchical trust relationships
  • Standardized certificate formats (X.509)
  • Centralized governance and control
  • Built-in expiration and revocation mechanisms

This approach is particularly common in government-issued credentials and regulated industries where centralized oversight is expected or required.

DID-Based Trust (Decentralized Identifiers)

The DID-based approach represents a more decentralized model for managing cryptographic trust, leveraging emerging W3C standards for Decentralized Identifiers (DIDs):

  1. DID Documents: Contain public keys, authentication methods, and service endpoints for a given identifier
  2. Verifiable Data Registries: Maintain DID Documents, often using distributed ledger technology (blockchain)
  3. Method-Specific Operations: Standardized mechanisms for creating, reading, updating, and deactivating DIDs

DID-based trust models offer distinct advantages:

  • No central authority required for identifier registration
  • Greater control by the identifier owner
  • Flexible cryptographic methods and key management
  • Enhanced privacy through pairwise DIDs or zero-knowledge proofs
  • Potentially improved resilience through decentralized infrastructure

This approach aligns with self-sovereign identity principles and is gaining traction in more open, user-centric identity ecosystems.

Hybrid Approaches

Many real-world implementations adopt hybrid approaches that combine elements of both models:

  • Certificate-Backed DIDs: Using traditional PKI to provide an initial trust anchor for DIDs
  • Federated Trust Registries: Centrally governed lists of trusted DIDs or DID methods
  • Trust Frameworks: Formalized governance structures that define rules for both certificate and DID usage

These hybrid models seek to balance the established security practices of PKI with the flexibility and user control of DID-based systems.

Credential Revocation Mechanisms

Trust Services also provide critical infrastructure for credential revocation—the ability to invalidate previously issued credentials when necessary. Several mechanisms exist for managing revocation:

Certificate Revocation Lists (CRLs)

CRLs are periodically published lists of all revoked credentials, signed by the issuer:

  • Distribution: CRLs are published at specified locations (URLs) listed in the credential
  • Verification: Verifiers check if a credential's identifier appears in the relevant CRL
  • Freshness: CRLs include issuance dates and next update timestamps
  • Size Concerns: CRLs can grow large over time, creating bandwidth and processing challenges

Online Certificate Status Protocol (OCSP)

OCSP provides real-time credential status checking:

  • Real-time Queries: Verifiers send requests for specific credential status
  • Compact Responses: Only the status of the requested credential is returned
  • Privacy Concerns: OCSP queries may reveal which credentials are being verified and by whom
  • Availability Requirements: Requires the OCSP responder to be constantly available

Status Lists

Status Lists represent a more compact approach to revocation:

  • Bitstring Encoding: Each credential is assigned a bit position in a list
  • Compact Representation: Only the position and value (revoked/valid) are needed
  • Verifiable Credentials Status List 2021: A W3C specification for this approach
  • Update Frequency: Lists can be updated and published at regular intervals

Cryptographic Accumulators

Accumulators provide a highly privacy-preserving approach to revocation:

  • One-way Membership Function: Mathematically proves membership without revealing the entire set
  • Zero-knowledge Proofs: Credential holders can prove their credential is not revoked without revealing identifiers
  • Compact Representation: Accumulators maintain constant size regardless of the number of revoked credentials
  • Computational Complexity: Higher computational requirements than simpler methods

Blockchain-Based Revocation

Distributed ledger technology offers another approach to revocation:

  • Immutable Records: Revocation status is recorded on a blockchain
  • Decentralized Verification: Any party can verify status without relying on a central service
  • Transparency: Public visibility of revocation actions (though not necessarily the identities involved)
  • Smart Contract Integration: Automated handling of revocation conditions and consequences

Implementation Considerations

When designing or selecting Trust Services for a VDC ecosystem, several factors should be considered:

  1. Privacy Requirements: How sensitive is the act of verification itself? Does the verification reveal user behavior patterns?

  2. Scalability Needs: How many credentials will be issued and verified? What are the performance requirements?

  3. Connectivity Assumptions: Will verifications occur in environments with limited or no internet connectivity?

  4. Freshness Requirements: How quickly must revocation information propagate through the ecosystem?

  5. Governance Structure: Who controls the trust roots? How is this control exercised and audited?

  6. Interoperability Goals: Will credentials need to be verified across organizational or national boundaries?

  7. Regulatory Constraints: Are there legal requirements governing trust models in the relevant jurisdiction?

The choice of trust model and revocation mechanism significantly impacts the security, privacy, and usability characteristics of a VDC ecosystem. Most successful implementations carefully balance these considerations based on their specific use cases and constraints.