Catalogue of Attestations¶

Overview¶

The EUDI Wallet ecosystem requires mechanisms for relying parties to discover available credential types, understand their structure, and verify issuers. The catalogue of attestations addresses these requirements by providing a registry of attestation types with their schema definitions and trust anchors.

Each attestation type entry in the catalogue consists of two parts:

SchemaMeta (machine-readable): Defines schema URIs, supported formats, trust anchors, and binding requirements
Attestation Rulebook (human-readable): Documents governance rules, compliance requirements, and issuance policies

These mechanisms are specified in TS 11 of the Architecture Reference Framework (ARF) and enable interoperability across the ecosystem.

Purpose and Key Challenges¶

When a relying party wants to request a presentation, two fundamental questions must be answered:

What is the structure of the attestation? — The relying party must know the exact schema and attribute identifiers to construct valid requests. Different credential formats (e.g., mdoc vs. SD-JWT VC) may encode the same logical data differently.
Who is authorized to issue this credential? — Anyone can create a digital signature, but the relying party must verify that the issuer was authorized to issue this specific attestation type.

Attestation rulebooks and catalogues solve these challenges:

Challenge	Solution
Discovery: How do relying parties find relevant credential types?	Catalogue provides searchable registry
Interoperability: How do different systems understand the same credential?	SchemaMeta defines canonical schemas per format
Trust: How do relying parties know which issuers to accept?	SchemaMeta references authoritative trust lists
Verification: How should credentials be validated?	Rulebooks specify verification rules

SchemaMeta Structure¶

Each attestation type entry combines human-readable governance documentation with machine-readable schema definitions. The human-readable Attestation Rulebook document defines governance, rules, and compliance requirements. The machine-readable SchemaMeta object contains the schema references and trust anchors.

TS 11 version 1.0.1 defines the SchemaMeta main class with the following components:

Core Identification¶

Field	Description
id	Unique identifier (UUID) assigned by the catalogue provider
version	Version of the schema following SemVer
rulebookURI	URI to the human-readable Attestation Rulebook document. May include `#integrity` suffix with W3C SRI metadata for integrity verification

Schema References¶

The schemaURIs array contains Schema objects linking schema definitions for each supported credential format. Since different formats (e.g., mdoc, SD-JWT VC) encode attributes differently, each schema reference includes:

Field	Description
formatIdentifier	Credential format: `dc+sd-jwt`, `mso_mdoc`, `jwt_vc_json`, `jwt_vc_json-ld`, or `ldp_vc`
uri	Persistent schema URI assigned by the catalogue. May include `#integrity` suffix

Trust Anchors¶

The trustedAuthorities array contains TrustAuthority objects specifying which entities are authorized to issue this credential type. Each entry resolves to the applicable trust framework:

Field	Description
frameworkType	Type of trust framework: `aki` (X.509 Authority Key Identifier), `etsi_tl` (ETSI Trusted List), or `openid_federation`
value	base64url for `aki`, or URI for `etsi_tl` / `openid_federation`
isLoTE	Boolean indicating if the trusted list is a List of Trusted Entities (ETSI TS 119 602) rather than ETSI TS 119 612. Only used with `etsi_tl` type

For QEAAs and PubEAAs, trust is resolved via the EU List of Trusted Lists (ETSI TS 119 612). For EAAs, the List of Trusted Entities (LoTE) approach per ETSI TS 119 602 is recommended. OpenID Federation may only be used for EAAs.

The trustedAuthorities attribute is optional only for attestations without any trust model (i.e., self-signed attestations).

Additional Metadata¶

Field	Description
attestationLoS	Level of security for issuance: `iso_18045_high`, `iso_18045_moderate`, `iso_18045_enhanced-basic`, or `iso_18045_basic`
bindingType	Cryptographic binding: `claim` (to presented claim), `key` (to user's key), `biometric` (to biometrics), or `none`
supportedFormats	Array of supported formats: `dc+sd-jwt`, `mso_mdoc`

Schema References¶

Each EU member state maintains a national catalogue of schemes for attestation of attributes.

Schema references enable relying parties to construct valid credential requests and issuers to validate credentials before issuance. Without knowing the exact attribute identifiers, a relying party cannot request specific data.

For example, the PID encodes the date of birth differently depending on format:

mdoc: birth_date
SD-JWT VC: birthdate

Similarly, country of residence is encoded as:

mdoc: resident_country
SD-JWT VC: address.country

The wallet performs exact matching when processing presentation requests. If a relying party requests an attribute using an incorrect identifier, the wallet will indicate that no matching credential is available. It does not attempt to guess the intended attribute.

Schema Structure¶

Schemas are defined using JSON Schema and include:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://catalogue.example.de/schemas/membership-card-sd-jwt.json",
  "title": "Membership Card (SD-JWT VC)",
  "type": "object",
  "properties": {
    "vct": {
      "type": "string",
      "const": "https://example.de/attestations/membership-card"
    },
    "memberName": {
      "type": "string",
      "maxLength": 256
    },
    "membershipTier": {
      "type": "string",
      "enum": ["Basic", "Standard", "Premium"]
    },
    "nbf": {
      "type": "number",
      "description": "Valid from (Unix timestamp)"
    },
    "exp": {
      "type": "number",
      "description": "Valid until (Unix timestamp)"
    }
  },
  "required": ["vct", "memberName", "membershipTier", "nbf", "exp"]
}

Benefits¶

Schema references provide value to multiple actors:

Relying parties: Can construct valid DCQL queries with correct attribute identifiers
Issuers: Can validate credentials against the schema during issuance, catching errors before credentials are issued
Tooling: Machine-readable schemas enable automated configuration and validation tools

Issuer Authorization¶

The Challenge¶

Digital signatures alone do not establish trust. Any entity can create a signed credential, but relying parties must verify that the issuer was authorized to issue that specific attestation type.

The trust anchor for verification must be obtained out-of-band via a trusted channel, not from the wallet interaction itself. The wallet is controlled by the holder, and relying parties are responsible for verifying issuer authorization independently.

Verification Approach¶

For different attestation types, issuer authorization is verified differently:

Attestation Type	Authorization Source
PubEAA	EU Trusted List links issuer identity to attestation type
QEAA	EU Trusted List
EAA	Attestation rulebook with trust list of authorized issuers

For EAAs and QEAAs, the verification flow involves:

Wallet fetches issuer metadata during issuance
Issuer metadata includes a registration certificate (per ETSI TS 119 472-3)
Registration certificate references the applicable rulebook (per ETSI TS 119 475)
Rulebook contains the trust list with authorized issuers

It is not clear at this point if a QEAA provider needs to be authorized to issue a specific QEAA (i.e., if there needs to be an entry present for authorized issuers in the rulebook).

Trust List Management¶

Trust lists following ETSI TS 119 602 can be hosted and managed by the rulebook publisher. The trust list is a signed JWT, allowing issuers to be added or removed without modifying the rulebook itself. This enables scenarios such as:

A ministry of education publishing a rulebook for diplomas while maintaining a trust list of authorized educational institutions
Multiple member states sharing a common schema while maintaining separate national trust lists

Catalogue of Attestations¶

Concept¶

The catalogue of attestations is a registry where attestation rulebooks are published and can be discovered. While a central EU catalogue is envisioned, member states can also operate their own catalogues—similar to how multiple DNS services enable internet browsing. This federated approach allows national governance while maintaining interoperability through consistent rulebook structures.

Publication Requirements¶

The publication of attestation rulebooks in the catalogue is required for certain attestation types by eIDAS regulation:

Attestation Type	Publication Requirement
QEAA	SHALL register
PubEAA	SHALL register
EAA	MAY register

The European Commission's Attestation Rulebooks Catalogue is the designated repository for publishing Attestation Rulebooks and their schemas. All QEAA and PubEAA providers should publish their rulebooks in this catalogue.

Publishing EAAs

Publication is necessary only when parties outside a closed ecosystem should be able to consume or issue the attestation. For EAAs within a closed ecosystem where all participants are known, catalogue publication may not be required.

Publisher Authentication¶

Rulebook publication requires authentication but not authorization by the catalogue provider. This approach enables ecosystem growth while maintaining accountability:

Authentication: Publishers sign rulebooks using their Access Certificate (the x.509 certificate required for interaction with EUDI Wallets per eIDAS)
Trust anchor: The Access Certificate Authority of the member state
Accountability: Publishers can be identified through the Know Your Customer process required for Access Certificate issuance

Any authenticated publisher can submit rulebooks. The catalogue operator does not perform authorization checks or content review—this enables permissionless innovation while maintaining identity accountability. However, the catalog provider retains the ability to remove entries in cases of malicious behavior, policy violations, or other legitimate concerns, ensuring ecosystem integrity while maintaining the permissionless publication model.

Catalog presence does not imply trust

The catalog is a discovery mechanism, not a trust endorsement. Any authenticated entity can publish a rulebook, which means the catalog may contain entries of varying quality and legitimacy. Relying parties must independently evaluate whether to accept a given attestation type by examining the referenced trust anchors and governance rules—not by assuming that catalog inclusion signals trustworthiness.

For example, a fictional entity could publish a rulebook for a "Professional Engineer License" attestation. The entry would appear in the catalog alongside legitimate entries. A relying party accepting this attestation must verify that the issuer appears on a trust list they recognize (e.g., an ETSI Trusted List maintained by a national engineering authority). Without this verification step, accepting the credential based on catalog presence alone would be insecure.

In practice, relying parties should:

Only accept attestation types whose trust anchors chain to authorities they recognize
Verify that the trust list referenced in the rulebook is operated by a known and reputable entity
Treat the catalog as a source of schema and format information, not as a guarantee of issuer legitimacy

Security Considerations¶

Even if a catalogue provider is compromised, attackers can only delete rulebooks—not modify them. Only the holder of the Access Certificate that published a rulebook can provide updates, as the signature verification would fail otherwise.

Using Attestation Rulebooks¶

For Issuers¶

Publish an attestation rulebook defining your credential type
Provide (or reference existing) schema definitions for each supported credential format
Manage your trust list of authorized issuers (can be updated independently)
Validate credentials against the schema during issuance to catch errors
Version your rulebook when schemas change

For Relying Parties¶

Discover credential types via catalogue search
Retrieve schemas to construct valid presentation requests with correct attribute identifiers
Configure trust anchors from the rulebook to verify issuer authorization
Validate credentials using the verification rules specified in the rulebook

For Wallet Providers¶

Verify issuer authorization by checking the rulebook-defined trust list during issuance
Display credential information using schema metadata
Enable credential discovery (see below)

Discovery Mechanisms¶

The catalogue enables discovery functionality that benefits both relying parties and wallet holders.

Relying Party Discovery¶

Relying parties can query the catalogue to understand:

Which credential types exist in the ecosystem
What attributes each credential type contains
Which issuers are authorized for each credential type
How to construct valid presentation requests

Wallet-Based Discovery¶

With access to the catalogue, wallets can provide enhanced user experiences:

Issuance during presentation: When a relying party requests a credential the user does not possess, the wallet can use the catalogue to determine how and where to obtain it. This enables on-demand credential acquisition without requiring the relying party to provide issuance instructions.

Proactive suggestions: The wallet can scan the catalogue for relevant credential types based on the user's existing attestations and preferences, suggesting credentials that may be useful. This processing can occur entirely on-device to preserve privacy.

Ecosystem Visibility¶

The catalogue of attestations combined with registrar data (where relying parties declare their intended credential requests) provides visibility into ecosystem supply and demand. These metrics can be monitored in a privacy-preserving way without revealing actual credential usage patterns:

Supply: Which attestation types are available and who can issue them
Demand: Which attestation types relying parties intend to request

This visibility helps ecosystem participants understand adoption and identify gaps without requiring centralized transaction monitoring.

Reference Implementation¶

A proof-of-concept implementation demonstrating these data models is available at github.com/cre8/catalog-of-attestations.

The repository provides:

catalog.schema.json — JSON Schema for the SchemaMeta data model
Example attestation — Gym Membership Card as SD-JWT VC
Format-specific schemas — Claimset schemas for credential validation
ETSI LoTE trust list — Working example of issuer authorization
Human-readable rulebook — Governance documentation template

The implementation also includes practical extensions addressing integrity verification (SRI hashes for schemas and rulebooks) and trust list signing for private ecosystems that don't chain to the EU List of Trusted Lists.

Ongoing Standardization¶

The technical specifications for attestation rulebooks and catalogues are actively being developed within ETSI. Key specifications include:

ETSI TS 119 602: List of Trusted Entities (LoTE) for trust list management
ETSI TS 119 472-3: Embedding registration certificates in issuance requests
ETSI TS 119 475: Structure of registration certificates with rulebook references

References¶

ARF TS 11: Specification of interfaces and formats for the catalogue of attributes and the catalogue of attestations (v1.0.1)
ETSI TS 119 478: Specification of interfaces related to Authentic Sources
ETSI TS 119 612: Trusted Lists
ETSI TS 119 602: List of Trusted Entities (LoTE) data model
Attestation Rulebooks Catalogue: GitHub Repository
Reference Implementation: Catalogue of Attestations POC
CIR for EAAs: Commission Implementing Regulation (EU) 2025/1569