Skip to content

Anatomy of a Credential

Overview

All credentials in the EUDI ecosystem—regardless of their legal classification (PID, EAA, QEAA, PubEAA)—share common technical mechanisms. Understanding these mechanisms is essential for designing interoperable and secure credentials.

This page describes the building blocks that every well-designed credential should incorporate.

Credential Structure

A credential consists of several layers:

CredentialMetadata• Credential type identifier• Issuer identifier• Issuance date• Validity period• Revocation/status informationClaims (Attributes)• Mandatory attributes• Optional attributes• Selective disclosure markersHolder Binding• Key reference / biometric / claim-basedIssuer Signature• Cryptographic proof of authenticity

Metadata

Metadata provides context about the credential itself:

Field Purpose
Credential type Identifies what kind of credential this is (e.g., diploma, membership card)
Issuer identifier Uniquely identifies the issuing organization
Issuance date When the credential was created
Validity period How long the credential remains valid
Schema reference Points to the attribute schema definition
Rulebook URI References the governing rulebook (for EAAs)

Claims (Attributes)

Claims are the actual data the credential attests to. They should be:

  • Precisely typed: Use appropriate data types (string, number, date, image)
  • Standards-aligned: Follow existing standards where available
  • Regulation-aligned: Use terminology from applicable regulations
  • Minimized: Include only necessary data (data minimization principle)
  • Harmonized: Use consistent structure across issuers of the same credential type

Signature Mechanisms

Every credential must be cryptographically signed by its issuer. The signature provides:

  • Authenticity: Proof that the credential was issued by the claimed issuer
  • Integrity: Assurance that the credential has not been tampered with

Signature Formats by Credential Type

Credential Format Recommended Signature Format
SD-JWT VC JAdES (JSON Advanced Electronic Signature)
ISO mDoc CBAdES (CBOR Advanced Electronic Signature)

Signature Requirements

For all EAAs:

  • Use certificates linked to the referenced trust anchor
  • Follow BSI/ENISA cryptographic recommendations
  • Consider post-quantum algorithm readiness

For high-trust EAAs (where document-equivalent evidentiary value is desired):

  • Use Qualified Electronic Signatures (QES) or Qualified Electronic Seals (QSeal)
  • Ensure long-term validation capability if long-term storage is required

Certificate vs. Credential Revocation

Never revoke signing certificates to invalidate individual credentials—this is too coarse-grained and affects all credentials signed with that certificate. Use credential-level revocation mechanisms instead.

Holder Binding

Holder binding ensures that a credential can only be used by its legitimate holder. Three binding mechanisms exist:

The credential is cryptographically bound to a key held in the user's wallet.

  • Mechanism: Credential contains a reference to a public key; the wallet proves possession of the corresponding private key during presentation
  • Verification: Relying party verifies the key proof
  • Advantages: Strong binding, privacy-preserving, works across all verification contexts
  • Best for: Native EUDI ecosystem usage

Claim Binding

The credential contains identifying claims (e.g., name, date of birth) that the relying party matches against another identity source.

  • Mechanism: Verifier identifies the user separately (e.g., via PID presentation) and matches claims
  • Verification: Relying party compares credential claims with verified identity
  • Advantages: Works across different media/systems, useful for migration scenarios
  • Best for: Cross-media usage, interoperability with non-wallet systems

Biometric Binding

The credential contains biometric data (face image, fingerprint template) that the verifier matches against the presenting person.

  • Mechanism: Credential includes biometric template; verifier captures live biometric and compares
  • Verification: On-site biometric matching
  • Advantages: Strong physical binding, does not require device interaction
  • Best for: High-security on-site verification, border control scenarios

Revocation Mechanisms

Revocation allows an issuer to invalidate a credential before its natural expiry. This is necessary when:

  • Underlying attributes have changed
  • The credential was issued in error
  • Misuse has been detected or is suspected
  • The holder requests invalidation

When Revocation Is Required

Scenario Revocation Needed?
Very short-lived credentials (hours/days) Usually not
Attributes that may change during validity period Yes
Credentials where misuse poses significant risk Yes
High-trust credentials (QEAA, PubEAA) Yes, within 24 hours

Revocation Mechanisms

The preferred approach for the EUDI ecosystem is status lists:

  • Issuer publishes a cryptographically signed list of revoked credential identifiers
  • Relying party downloads the list periodically and checks locally
  • No per-verification call to the issuer (privacy-preserving)

Anti-pattern: OCSP-style lookups

Do not use Online Certificate Status Protocol (OCSP) style mechanisms where the relying party queries the issuer for each verification. This allows the issuer to track where and when credentials are used.

Status List Updates

  • Status lists should be updated at regular intervals
  • For high-trust credentials: at least every 24 hours
  • Lists should be cached by relying parties to ensure availability

Anti-Tracking Measures

To prevent correlation of credential usage across different verifiers, implement these measures:

Validity Period Variation

Issue credentials with slightly varied validity periods rather than uniform timestamps:

  • Round timestamps to hours or days rather than exact seconds
  • Add small random offsets to expiry dates
  • This prevents using the exact validity period as a tracking identifier

Batch Issuance

Issue multiple interchangeable credentials to the same holder:

  • Each credential has a different identifier but contains the same attributes
  • Wallet can rotate which credential is presented
  • Prevents correlation via credential identifier

Selective Disclosure

Reveal only the minimum necessary attributes for each presentation:

  • Both SD-JWT VC and ISO mDoc support selective disclosure natively
  • Configure credentials to allow fine-grained disclosure
  • Relying parties should request only what they need

For more details on privacy requirements, see Privacy Requirements.

Supported Credential Formats

EAAs in the German EUDI Wallet ecosystem may be issued in two formats:

SD-JWT VC (Selective Disclosure JWT Verifiable Credential)

  • Based on: IETF SD-JWT VC specification
  • Encoding: JSON
  • Optimized for: Online/remote presentation
  • Selective disclosure: Native support via salted hash claims
  • Developer experience: Familiar JSON/JWT tooling

ISO mDoc (ISO/IEC 18013-5)

  • Based on: ISO/IEC 18013-5 (mobile driving license standard)
  • Encoding: CBOR
  • Optimized for: Proximity presentation (NFC, BLE)
  • Selective disclosure: Built-in via namespace structure
  • Ecosystem alignment: Anchor format for PID

Choosing a Format

Use Case Recommended Format
Primarily online/remote verification SD-JWT VC
Primarily in-person/proximity verification ISO mDoc
Cross-border interoperability required ISO mDoc (if PID-aligned)
Integration with existing web infrastructure SD-JWT VC
Both online and proximity use cases Consider issuing in both formats