Mixed Trust Registry Usage

Overview

VCVerifier supports using multiple trust registries of different types simultaneously. This enables flexible trust models where issuers can be verified through any of several configured registries, providing redundancy and supporting diverse ecosystems.

Trust Logic

When multiple trust registries are configured, an issuer is considered trusted if found in at least one of the configured registries. This implements an OR logic across registries.

This approach provides:

Redundancy: If one registry is unavailable, others can still verify issuers
Flexibility: Support issuers from different ecosystems (EBSI, Gaia-X, etc.)
Gradual Migration: Transition between registry systems without disruption
Multi-Ecosystem Support: Participate in multiple trust frameworks simultaneously

Configuration

Basic Mixed Configuration

Combine EBSI TIR and Gaia-X Registry for the same credential type:

configRepo:
  services:
    testService:
      scope:
        - VerifiableCredential
      trustedParticipants:
        VerifiableCredential:
          - type: ebsi
            url: https://tir-pdc.ebsi.fiware.dev
          - type: gaia-x
            url: https://registry.lab.gaia-x.eu

Multiple Registries per Type

You can configure multiple registries of the same type:

configRepo:
  services:
    testService:
      scope:
        - VerifiableCredential
      trustedParticipants:
        VerifiableCredential:
          # Multiple EBSI TIR instances
          - type: ebsi
            url: https://tir-pdc.ebsi.fiware.dev
          - type: ebsi
            url: https://tir-backup.ebsi.fiware.dev
          # Gaia-X Registry
          - type: gaia-x
            url: https://registry.lab.gaia-x.eu

Different Registries for Different Credentials

Apply different trust registry combinations to different credential types:

configRepo:
  services:
    testService:
      scope:
        - IdentityCredential
        - ParticipantCredential
        - EmployeeCredential
      trustedParticipants:
        # Identity uses only EBSI
        IdentityCredential:
          - type: ebsi
            url: https://tir-pdc.ebsi.fiware.dev
        
        # Participant uses both EBSI and Gaia-X
        ParticipantCredential:
          - type: ebsi
            url: https://tir-pdc.ebsi.fiware.dev
          - type: gaia-x
            url: https://registry.lab.gaia-x.eu
        
        # Employee uses only Gaia-X
        EmployeeCredential:
          - type: gaia-x
            url: https://registry.lab.gaia-x.eu

Verification Flow

When multiple registries are configured, VCVerifier checks them in order:

Receive Credential

VCVerifier receives a credential and extracts the issuer DID

Check First Registry

Query the first configured registry (e.g., EBSI TIR):

If issuer is found → Verification succeeds ✓
If issuer is not found → Continue to next registry

Check Additional Registries

If first registry didn’t find the issuer, query subsequent registries:

Try Gaia-X Registry
If issuer is found → Verification succeeds ✓
If not found → Continue to next registry

Final Result

If issuer found in any registry → Trusted ✓
If issuer not found in any registry → Not trusted ✗

// Pseudocode representation
func VerifyIssuer(did string, registries []Registry) bool {
    for _, registry := range registries {
        if registry.IsTrustedParticipant(did) {
            return true  // Found in at least one registry
        }
    }
    return false  // Not found in any registry
}

Use Cases

Use Case 1: High Availability

Provide redundancy by configuring multiple registries of the same type:

trustedParticipants:
  VerifiableCredential:
    - type: ebsi
      url: https://tir-primary.ebsi.eu
    - type: ebsi
      url: https://tir-backup.ebsi.eu
    - type: ebsi
      url: https://tir-fallback.ebsi.eu

Benefits:

Service continues if primary registry is down
Automatic failover to backup registries
Improved uptime and reliability

Use Case 2: Multi-Ecosystem Participation

Support issuers from both EBSI and Gaia-X ecosystems:

trustedParticipants:
  BusinessCredential:
    - type: ebsi
      url: https://tir-pdc.ebsi.fiware.dev
    - type: gaia-x
      url: https://registry.gaia-x.eu

Benefits:

Accept credentials from multiple trust frameworks
Broader ecosystem participation
Flexibility in issuer onboarding

Use Case 3: Migration Strategy

Gradually migrate from one registry to another:

trustedParticipants:
  VerifiableCredential:
    # Old registry (being phased out)
    - type: ebsi
      url: https://tir-legacy.example.com
    # New registry (being adopted)
    - type: ebsi
      url: https://tir-new.example.com

Benefits:

Zero-downtime migration
Issuers can move at their own pace
Backward compatibility during transition

Use Case 4: Regional Registries

Support different regional trust frameworks:

trustedParticipants:
  VerifiableCredential:
    # European registry
    - type: ebsi
      url: https://tir.ebsi.eu
    # North American registry
    - type: ebsi
      url: https://tir.example.com
    # Asia-Pacific registry
    - type: ebsi
      url: https://tir.apac.example.com

Benefits:

Global issuer support
Regional compliance
Reduced latency with regional endpoints

Performance Considerations

Sequential Checking

Registries are checked sequentially, not in parallel:

If the first registry is slow to respond, it will delay the entire verification process even if subsequent registries could verify the issuer faster.

Optimization strategies:

Order registries by likelihood: Place the most likely registry first
Use caching: VCVerifier’s cache prevents repeated registry queries
Monitor performance: Track which registries are slow and reorder accordingly

Caching Behavior

Each registry lookup is cached independently:

verifier:
  tirCacheExpiry: 3600  # Cache EBSI TIR results for 1 hour
  tilCacheExpiry: 3600  # Cache trusted issuer lists for 1 hour

First verification: Queries all necessary registries
Subsequent verifications: Served from cache
Cache miss: Only queries registries not in cache

Network Resilience

trustedParticipants:
  VerifiableCredential:
    # Primary - fast, reliable
    - type: ebsi
      url: https://tir-primary.ebsi.eu
    # Fallback - alternative provider
    - type: ebsi
      url: https://tir-backup.provider.com
    # Last resort - Gaia-X
    - type: gaia-x
      url: https://registry.gaia-x.eu

Error Handling

How VCVerifier handles errors with multiple registries:

Error Type	Behavior
Connection timeout	Skip to next registry
HTTP 404 (Not Found)	Skip to next registry
HTTP 500 (Server Error)	Skip to next registry
Invalid response	Skip to next registry
All registries fail	Verification fails

Errors from individual registries are logged but don’t cause immediate verification failure. Only if all registries fail or return “not found” does the overall verification fail.

Testing Mixed Configurations

Test Registry Fallback

Verify that fallback works correctly:

# Test with issuer only in second registry
# 1. Confirm issuer NOT in first registry
curl https://tir-pdc.ebsi.fiware.dev/v4/issuers/did:web:example.com
# Expected: 404

# 2. Confirm issuer IS in second registry
curl -X POST https://registry.lab.gaia-x.eu/v2/api/trustAnchor/chain/file \
  -H "Content-Type: application/json" \
  -d '{"uri": "https://example.com/certs/chain.pem"}'
# Expected: 200

# 3. Verify credential - should succeed via Gaia-X

Monitor Registry Performance

Track which registries are actually being used:

# Enable debug logging
logging:
  level: "DEBUG"

# Watch logs for registry queries
tail -f verifier.log | grep "Verify participant"

Look for log entries like:

DEBUG: Verify participant did:web:example.com at gaia-x registry https://registry.lab.gaia-x.eu
INFO: Issuer did:web:example.com is a trusted participant via https://registry.lab.gaia-x.eu

Advanced Patterns

Credential-Type-Specific Strategies

configRepo:
  services:
    testService:
      trustedParticipants:
        # High-security credentials: strict EBSI only
        IdentityCredential:
          - type: ebsi
            url: https://tir-secure.ebsi.eu
        
        # Business credentials: flexible multi-registry
        BusinessCredential:
          - type: ebsi
            url: https://tir-pdc.ebsi.fiware.dev
          - type: gaia-x
            url: https://registry.gaia-x.eu
        
        # Development credentials: permissive local + remote
        TestCredential:
          - type: ebsi
            url: http://localhost:8081
          - type: ebsi
            url: https://tir-pdc.ebsi.fiware.dev

Environment-Based Configuration

configRepo:
  services:
    testService:
      trustedParticipants:
        VerifiableCredential:
          - type: ebsi
            url: https://tir.ebsi.eu
          - type: gaia-x
            url: https://registry.gaia-x.eu

Troubleshooting

Verification Fails Despite Valid Issuer

Symptoms: Issuer exists in one registry but verification still failsDiagnosis:

# Enable debug logging
logging:
  level: DEBUG

Common causes:

Registry order: Issuer is in registry #2 but registry #1 has connection issues and times out
Cache issues: Stale cache entry indicating issuer is not found
Configuration error: Registry URL typo or wrong credential type mapping

Solutions:

Check logs for which registries are being queried
Verify registry URLs are correct and accessible
Clear cache and retry
Reorder registries to put most reliable first

Slow Verification Performance

Symptoms: Verification takes too longDiagnosis:

Check if first registry has high latency
Monitor cache hit rates

Solutions:

Reorder registries: Put fastest/most-used first
Increase cache expiry times
Add more specific credential type mappings
Consider removing slow or unused registries

Inconsistent Verification Results

Symptoms: Same credential sometimes verifies, sometimes doesn’tLikely causes:

Intermittent registry availability
Registry synchronization delays
Cache expiry during high-traffic periods

Solutions:

Add redundant registries for high availability
Increase cache expiry to reduce registry queries
Monitor registry health and availability
Implement retry logic in your application

Best Practices

Order Matters

Place most likely / fastest registries first to optimize performance

Redundancy for Critical Credentials

Configure multiple registries for high-value credential types

Monitor and Adjust

Track which registries are actually used and adjust order accordingly

Test Failover

Regularly test that failover to backup registries works correctly

Document Your Strategy

Clearly document which registries are used for which credential types

Environment Consistency

Use similar registry strategies across dev, staging, and production

Next Steps

EBSI TIR

Learn more about EBSI TIR configuration

Gaia-X

Dive deeper into Gaia-X Registry setup

Overview

Back to trust anchors overview

Get Started

Installation

Configuration

Integration

Trust Anchors

Advanced

​Overview

​Trust Logic

​Configuration

​Basic Mixed Configuration

​Multiple Registries per Type

​Different Registries for Different Credentials

​Verification Flow

​Use Cases

​Use Case 1: High Availability

​Use Case 2: Multi-Ecosystem Participation

​Use Case 3: Migration Strategy

​Use Case 4: Regional Registries

​Performance Considerations

​Sequential Checking

​Caching Behavior

​Network Resilience

​Error Handling

​Testing Mixed Configurations

​Test Registry Fallback

​Monitor Registry Performance

​Advanced Patterns

​Credential-Type-Specific Strategies

​Environment-Based Configuration

​Troubleshooting

​Best Practices

Order Matters

Redundancy for Critical Credentials

Monitor and Adjust

Test Failover

Document Your Strategy

Environment Consistency

​Next Steps

EBSI TIR

Gaia-X

Overview

Build docs developers (and LLMs) love

Overview

Trust Logic

Configuration

Basic Mixed Configuration

Multiple Registries per Type

Different Registries for Different Credentials

Verification Flow

Use Cases

Use Case 1: High Availability

Use Case 2: Multi-Ecosystem Participation

Use Case 3: Migration Strategy

Use Case 4: Regional Registries

Performance Considerations

Sequential Checking

Caching Behavior

Network Resilience

Error Handling

Testing Mixed Configurations

Test Registry Fallback

Monitor Registry Performance

Advanced Patterns

Credential-Type-Specific Strategies

Environment-Based Configuration

Troubleshooting

Best Practices

Next Steps