Skip to main content

​
Overview

The configRepo section defines how VCVerifier manages service configurations, credential types, and trust relationships. This can be configured statically in YAML or dynamically via a Credentials Config Service.

​
ConfigRepo Settings

​
configRepo.configEndpoint
string
URL of the Credentials Config Service for dynamic configuration updates.When configured, VCVerifier periodically fetches service configurations from this endpoint.
configRepo:
  configEndpoint: http://config-service:8080
​
configRepo.updateInterval
integer
default:"30"
Interval in seconds for fetching configuration updates from the config service.
configRepo:
  configEndpoint: http://config-service:8080
  updateInterval: 60
If configEndpoint is not configured, only static configuration from the YAML file will be used.

​
Service Configuration

​
configRepo.services
array
Array of statically configured services with their trust anchors and scopes.
Each service has the following structure:

​
Service Properties

​
services[].id
string
required
Unique identifier for the service.
configRepo:
  services:
    - id: myService
​
services[].defaultOidcScope
string
Default OIDC scope to use when none is specified in the authentication request.
configRepo:
  services:
    - id: myService
      defaultOidcScope: "default"
​
services[].authorizationType
string
Type of authorization to be provided in the redirect response.
​
services[].authorizationPath
string
Path for the authorization endpoint to be provided in redirects.

​
OIDC Scopes

​
services[].oidcScopes
object
required
Map of scope names to scope configurations. Each scope defines which credentials to request and how to trust them.

​
Scope Configuration

​
oidcScopes.<scopeName>.credentials
array
required
Array of credential configurations for this scope.
​
oidcScopes.<scopeName>.presentationDefinition
object
Presentation Definition following the DIF Presentation Exchange specification.Defines the format and constraints for requested credentials.
​
oidcScopes.<scopeName>.dcql
object
DC Query Language (DCQL) query for requesting specific credentials and claims.
​
oidcScopes.<scopeName>.flatClaims
boolean
default:"false"
When true, flattens credential claims to plain JWT claims instead of keeping the credential/presentation structure.
oidcScopes:
  myScope:
    flatClaims: true

​
Credential Configuration

Each credential in a scope has the following properties:
​
credentials[].type
string
required
Type of the credential (e.g., VerifiableCredential, CustomerCredential).
credentials:
  - type: CustomerCredential

​
Trust Configuration

​
credentials[].trustedParticipantsLists
array
List of trusted participants registries to check if the credential issuer is a trusted participant.Each entry has:
  • type - Registry type (ebsi or gaia-x)
  • url - URL of the registry
credentials:
  - type: CustomerCredential
    trustedParticipantsLists:
      - type: ebsi
        url: https://tir-pdc.ebsi.fiware.dev
      - type: gaia-x
        url: https://registry.lab.gaia-x.eu
​
credentials[].trustedIssuersLists
string[]
List of EBSI Trusted Issuers Registry compatible endpoints to verify that issuers are trusted and have permission to issue credentials with specific claims.
credentials:
  - type: CustomerCredential
    trustedIssuersLists:
      - https://tir-pdc.ebsi.fiware.dev
EBSI Trusted Issuers Registry:
  • Standard EBSI-compliant registry
  • Default type for backwards compatibility
  • Supports any DID method
Gaia-X Registry:
  • Gaia-X Digital Clearing House registry
  • Requires did:web identifiers
  • Issuers must provide valid x5u location in their publicKeyJwk
You can configure multiple registries of different types. An issuer is trusted if found in at least one registry.

​
Holder Verification

​
credentials[].holderVerification.enabled
boolean
default:"false"
When true, verifies that the credential holder matches the presenter.
credentials:
  - type: CustomerCredential
    holderVerification:
      enabled: true
      claim: subject
​
credentials[].holderVerification.claim
string
Claim path to retrieve the holder identifier from the credential.

​
Compliance Verification

​
credentials[].requireCompliance
boolean
default:"false"
When true, requires a compliance credential accompanying this credential.
credentials:
  - type: ParticipantCredential
    requireCompliance: true

​
JWT Inclusion

​
credentials[].jwtInclusion.enabled
boolean
default:"true"
Whether to include this credential in the generated JWT.
​
credentials[].jwtInclusion.fullInclusion
boolean
default:"false"
When true, embeds the complete credential. When false, only configured claims are included.
​
credentials[].jwtInclusion.claimsToInclude
array
Array of claims to include from the credential. Each entry has:
  • originalKey - Key path in the credential
  • newKey - Key to use in the JWT (optional, defaults to originalKey)
credentials:
  - type: CustomerCredential
    jwtInclusion:
      enabled: true
      fullInclusion: false
      claimsToInclude:
        - originalKey: credentialSubject.email
          newKey: email
        - originalKey: credentialSubject.name

​
Presentation Definition

The presentation definition follows the DIF Presentation Exchange specification: 
oidcScopes:
  default:
    presentationDefinition:
      id: my-presentation
      input_descriptors:
        - id: my-descriptor
          constraints:
            fields:
              - id: credential-type
                path:
                  - $.type
                filter:
                  type: array
                  contains:
                    const: CustomerCredential
          format:
            jwt_vc:
              alg:
                - ES256

​
Input Descriptor

​
input_descriptors[].id
string
required
Unique identifier for the input descriptor.
​
input_descriptors[].constraints.fields
array
Array of field constraints:
  • id - Field identifier
  • path - JSONPath array to the field
  • optional - Whether the field is optional (default: true)
  • filter - Custom filter to apply (e.g., value constraints)
​
input_descriptors[].format
object
Credential format requirements. Common formats:
  • jwt_vc - JWT Verifiable Credential
  • ldp_vc - JSON-LD Verifiable Credential
  • sd+jwt-vc - Selective Disclosure JWT VC
Each format can specify alg (algorithms) requirements.

​
DCQL Query

DC Query Language provides fine-grained control over requested credentials: 
oidcScopes:
  default:
    dcql:
      credentials:
        - id: customer-credential
          format: jwt_vc
          claims:
            - path:
                - $.vc.credentialSubject.email
          meta:
            vct_values:
              - CustomerCredential
          trusted_authorities:
            - type: trust_registry
              values:
                - https://tir-pdc.ebsi.fiware.dev
​
dcql.credentials
array
required
Array of credential queries.
​
dcql.credential_sets
array
Array of credential set queries for complex requirements.

​
Complete Example

configRepo:
  # Optional: Use external config service
  configEndpoint: http://config-service:8080
  updateInterval: 60
  
  # Static service configuration
  services:
    - id: marketplace
      defaultOidcScope: "customer"
      
      oidcScopes:
        customer:
          # Credentials and trust configuration
          credentials:
            - type: CustomerCredential
              trustedParticipantsLists:
                - type: ebsi
                  url: https://tir-pdc.ebsi.fiware.dev
              trustedIssuersLists:
                - https://tir-pdc.ebsi.fiware.dev
              holderVerification:
                enabled: true
                claim: subject
              requireCompliance: false
              jwtInclusion:
                enabled: true
                fullInclusion: false
                claimsToInclude:
                  - originalKey: credentialSubject.email
                    newKey: email
                  - originalKey: credentialSubject.customerId
          
          # Presentation definition
          presentationDefinition:
            id: customer-presentation
            input_descriptors:
              - id: customer-credential-descriptor
                constraints:
                  fields:
                    - id: credential-type
                      path:
                        - $.type
                      filter:
                        type: array
                        contains:
                          const: CustomerCredential
                format:
                  jwt_vc:
                    alg:
                      - ES256
          
          # Flatten claims in JWT
          flatClaims: true
        
        premium:
          credentials:
            - type: PremiumCustomerCredential
              trustedParticipantsLists:
                - type: ebsi
                  url: https://tir-pdc.ebsi.fiware.dev
              jwtInclusion:
                enabled: true
                fullInclusion: true

​
Best Practices

Trust Configuration:
  • Always configure at least one trusted participants or issuers list
  • Use multiple registries for redundancy
  • Regularly review and update trust anchors
Scope Design:
  • Create separate scopes for different credential requirements
  • Use descriptive scope names that reflect the credential type
  • Configure defaultOidcScope for seamless user experience
When to use static configuration:
  • Simple deployments with few services
  • Fixed trust relationships
  • Development and testing
When to use dynamic configuration:
  • Multiple services with changing requirements
  • Need for runtime configuration updates
  • Production environments with evolving trust frameworks
  • Multi-tenant scenarios

​
Next Steps

Verifier Configuration

Configure DID, keys, and validation modes

Templating

Customize the login page

Build docs developers (and LLMs) love

Get started for freeTalk to us