Trusted Authorities

Trusted Authorities in DCQL enable verifiers to specify which credential issuers they trust, allowing wallets to filter credentials before presenting them to holders. This improves privacy by preventing the disclosure of credentials that would be rejected anyway, and provides a standardized way to integrate with trust frameworks and issuer validation systems.

What are trusted authorities?

A trusted authority specification identifies credential issuers that the verifier accepts. Rather than receiving any credential and then checking its issuer against a trust list, the verifier provides trust requirements upfront in the DCQL query. The wallet evaluates these requirements and only presents credentials from acceptable issuers to the holder.

This upfront trust signaling serves two purposes: it guides the wallet to filter credentials automatically, and it prevents holders from inadvertently sharing credentials from issuers the verifier won’t accept.

Why trusted authorities matter

In decentralized credential ecosystems, anyone can issue credentials. Verifiers need to determine which issuers they trust before accepting credentials. Without this mechanism, wallets would present all matching credentials regardless of issuer, leading to failed verifications and poor user experience.

Trusted authority specifications solve this by:

Filtering credentials at query time rather than verification time
Protecting privacy by preventing disclosure of untrusted credentials
Integrating with established trust frameworks (government trust lists, federation authorities)
Providing a standardized way to express issuer requirements

Structure

The trusted_authorities field is an optional array within a credential query. Each element is an object specifying a trust mechanism:

"trusted_authorities": [
  {
    "type": "etsi_tl",
    "values": ["https://example.gov/trust-list.xml"]
  }
]

The type field identifies which trust mechanism to use. The values array contains identifiers specific to that mechanism type.

Supported trust types

DCQL defines three standardized trust authority types, each corresponding to a different trust framework approach.

Authority key identifier (aki)

The aki type matches against the Authority Key Identifier from X.509 certificates in the credential’s trust chain. This enables trust based on certificate authorities:

"trusted_authorities": [
  {
    "type": "aki",
    "values": ["B1:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67"]
  }
]

The wallet checks whether the credential’s issuing certificate chains back to a certificate authority with the specified Authority Key Identifier. This integrates with PKI-based trust models.

ETSI trusted list (etsi_tl)

The etsi_tl type matches against ETSI Trusted Lists, which are XML documents listing trusted service providers. This is commonly used in European digital identity systems:

"trusted_authorities": [
  {
    "type": "etsi_tl",
    "values": [
      "https://ec.europa.eu/tools/lotl/eu-lotl.xml"
    ]
  }
]

The wallet checks whether the credential issuer is listed in the specified ETSI Trusted List. This is particularly relevant for EUDI Wallet implementations and regulated identity services in Europe.

OpenID federation (openid_federation)

The openid_federation type matches against trust anchors in OpenID Federation configurations. This enables dynamic trust establishment through federation:

"trusted_authorities": [
  {
    "type": "openid_federation",
    "values": [
      "https://federation.example.com"
    ]
  }
]

The wallet verifies that the credential issuer is part of the OpenID Federation rooted at the specified trust anchor. This supports federation-based trust models common in OpenID ecosystems.

How wallet filtering works

When a DCQL query includes trusted authorities, the wallet:

Evaluates each credential against the credential query’s format and metadata requirements
For credentials that match, checks whether the issuer satisfies the trusted authority requirements
Only presents credentials from trusted issuers to the holder for selection
Excludes credentials from untrusted issuers entirely

This prevents the holder from attempting to share credentials that will be rejected, improving the user experience and protecting privacy.

Privacy benefits

Trusted authority filtering protects holder privacy in several ways:

Prevents failed disclosures: Holders don’t share credentials that will be rejected, avoiding unnecessary exposure of issuer information.

Reduces information leakage: By filtering before presentation, the wallet doesn’t reveal to the holder which untrusted issuers the verifier would reject (which itself could be sensitive information).

Enables informed choices: When multiple trusted credentials exist, the holder can make informed decisions about which to share.

Multiple trust types

A credential query can specify multiple trusted authority types, allowing the wallet to satisfy any one of them:

"trusted_authorities": [
  {
    "type": "etsi_tl",
    "values": ["https://example.gov/trust-list.xml"]
  },
  {
    "type": "openid_federation",
    "values": ["https://federation.example.com"]
  }
]

This accepts credentials from issuers in either the ETSI Trusted List or the OpenID Federation, providing flexibility in trust establishment.

Multiple values per type

Within a single trust type, multiple values can be specified:

"trusted_authorities": [
  {
    "type": "etsi_tl",
    "values": [
      "https://example.gov/national-trust-list.xml",
      "https://example.gov/regional-trust-list.xml"
    ]
  }
]

The wallet accepts credentials from issuers in any of the listed trust lists, enabling support for multiple trust frameworks simultaneously.

Example: university degree with trust list

A credential query for university degrees from accredited institutions:

{
    "id": "university_degree",
    "format": "dc+sd-jwt",
    "meta": {
        "vct_values": ["https://credentials.edu/degree"]
    },
    "trusted_authorities": [
        {
            "type": "etsi_tl",
            "values": ["https://education.gov/accredited-universities.xml"]
        }
    ]
}

This accepts degree credentials only from universities listed in the government’s accreditation trust list, ensuring the degree comes from a recognized institution.

Example: government ID with multiple trust options

A credential query accepting government IDs from multiple trust frameworks:

{
    "id": "government_id",
    "format": "mso_mdoc",
    "meta": {
        "doctype_value": "org.iso.18013.5.1.mDL"
    },
    "trusted_authorities": [
        {
            "type": "etsi_tl",
            "values": ["https://eu.europa.ec/trust-list.xml"]
        },
        {
            "type": "openid_federation",
            "values": ["https://eudi-federation.example.eu"]
        }
    ]
}

This accepts mobile driver’s licenses from issuers in either the EU trust list or the EUDI OpenID Federation, supporting both trust establishment methods.

Role in Vidos

In Vidos, trusted authority specifications integrate with the platform’s trust management:

The Authorizer generates trusted authority requirements based on configured trust policies. When an authorization policy restricts credentials to specific issuers or trust frameworks, these are expressed as trusted_authorities in the DCQL query.

The Validator verifies that presented credentials come from acceptable issuers by checking trusted authority requirements. This happens before cryptographic verification, ensuring processing resources are only spent on credentials from trusted sources.

This enables Vidos to enforce trust policies at the query level, improving efficiency and user experience.

Summary

Trusted authorities provide a standardized way to specify acceptable credential issuers in DCQL queries. Through support for X.509 certificate authorities, ETSI Trusted Lists, and OpenID Federation trust anchors, they enable integration with established trust frameworks while improving privacy through upfront credential filtering.