Skip to content

Ecosystem Architecture

Crosscutting Concepts

Security Requirements

For system design and comparison of different solutions options we consider the following core security properties:

Level of Assurance (LoA)

Level of Assurance refers to the degree of confidence in the processes thus providing assurance that the user that uses a particular identity is in fact the user to which that identity was assigned. This property refers to the LoA of the eIDAS Regulation.

Unforgeability of Credentials

Unforgeability of credentials refers to the property that a credential can only be created by the legitimate Issuer and cannot be tampered by someone else. This property ensures the integrity and authenticity of a credential and its verification.

Freshness of Presentations

Freshness of presentations refers to the property that every presentation must be created anew for every verification. This property refers to the mechanisms used for binding a presentation to the presentation request of the Relying Party to prevent replay of presentations.

User Binding of presentations

User Binding refers to the property that credentials are under the sole control of the user. This property refers to the mechanism used for secure authentication of the user in the context of using the credential (e.g., by two-factor authentication linked with a cryptographic binding to the credential) to prevent unauthorized issuance or presentation of a credential. In the literature, this property is also described as holder binding.

Session Integrity

Session Integrity refers to the property that an attacker is not able to insert themselves into an authentication exchange between a Verifier and a Wallet or into an issuance process between a Wallet and an Issuer. This property requires mechanisms for binding communication to an authenticated session to prevent session hijacking.

Cryptographic algorithms

This section defines the cryptographic algorithms required for EU-wide interoperability in the EUDI Wallet ecosystem. The requirements are based on the eIDAS 2.0 Implementing Acts and the ENISA Agreed Cryptographic Mechanisms to ensure compliance with Level of Assurance High (LoA High).

Standards Reference

Most of the requirements on algorithms etc. come from the relevant technical standards like TS 119 472-2, TS 119 472-3, OpenID4VC High Assurance Interoperability Profile 1.0.

Mandatory Algorithm Support

All algorithms specified in this section SHALL be implemented by all ecosystem participants (Wallet Providers, Issuers, Verifiers). Using alternative algorithms (e.g., P-384 or P-521 instead of P-256) in ecosystem-specific agreements is NOT RECOMMENDED, as Wallets are only required to support the mandatory algorithms. Credentials signed with non-mandatory algorithms may not be parseable or verifiable by compliant Wallets, breaking interoperability.

Encryption and Confidentiality

For secure data exchange in both proximity and remote scenarios:

  • Application Layer Encryption: AES-GCM:
  • Transport Encryption: TLS 1.3 or TLS 1.2 with ENISA-compliant cipher suites for HTTPS communication

Note that for Response encryption, verifiers MUST support both, A128GCM, and A256GCM, and wallets can support either or both (see Section 5 of HAIP for more details)

Digital Signatures and Integrity

Signature requirements vary by use case and credential format:

  • Proximity Presentations (ISO/IEC 18013-5):
  • SD-JWT VC (Selective Disclosure JWT):
  • ISO/IEC mdoc:
  • Issuer Signatures (general):
  • Qualified Signatures (QEAA/PuB-EAA):
    • Must be qualified electronic signatures or seals
    • Underlying cryptographic modules require certification to Common Criteria (minimum EAL 4+) or FIPS 140-3 Level 3

Key Management and Exchange

  • Elliptic Curve:
  • Key Exchange (Proximity):
    • ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static) using P-256
  • Key Binding:
    • Wallet must demonstrate Proof of Possession for private keys corresponding to public keys in cryptographic bindings
  • DPoP (Demonstrating Proof of Possession):

Hash Algorithms

  • SHA-256: Required for integrity checks and certificate fingerprints (e.g., x5t header in JWS)
  • All hash functions must comply with ENISA-endorsed mechanisms

Hashing, PKCE (code challenge method)

Special Services

  • Qualified Timestamps (TSA):
    • Algorithms must be explicitly listed in ENISA publications to support presumption of conformity with eIDAS Regulation
  • Remote QSCDs:
    • Providers must implement ENISA-compliant cryptographic controls covering the entire lifecycle of signing techniques

Interoperability Rationale

All EUDI Wallet ecosystem components SHALL support the algorithms specified above. This is mandated by the Implementing Acts for both proximity (ISO/IEC 18013-5) and remote presentation scenarios.

Why no optional algorithms? While ecosystem-specific agreements (e.g., for diploma credentials) might technically allow stronger algorithms like P-384 or P-521, this creates a fragmentation risk: if an Issuer signs a credential with P-521 but the Wallet only implements the mandatory P-256, the credential becomes unusable. To guarantee that any EUDI-compliant Wallet can process any EUDI-compliant credential, all participants SHALL use only the mandatory algorithms specified in this document.

National Requirements and EU Interoperability

Member States may have national regulations that mandate additional cryptographic algorithms beyond those required by the EU Implementing Acts.

Example: Germany - §44 BSI-Gesetz

According to §44 BSI-Gesetz, German federal authorities are legally required to implement the BSI TR-02102 Technical Guidelines. TR-02102 recommends algorithms including Brainpool curves (brainpoolP256r1, brainpoolP384r1, brainpoolP512r1) which are not part of the EU-mandated algorithm set.

Impact on ecosystem participants:

Participant Type EU Algorithms (P-256) National Algorithms (e.g., TR-02102)
Wallet Provider SHALL implement No requirement
Issuer (general) SHALL use for credentials No impact on credential issuance
Issuer (German federal authority) SHALL use for credentials SHALL implement for internal systems per §44 BSI-Gesetz
Verifier (general) SHALL support No requirement
Verifier (German federal authority) SHALL support SHALL implement for internal systems per §44 BSI-Gesetz

Key Principle: Credentials Must Use EU-Mandated Algorithms

Even if national law requires implementation of additional algorithms (like BSI TR-02102), credentials issued for use in the EUDI Wallet ecosystem SHALL be signed with EU-mandated algorithms (P-256) to ensure EU-wide interoperability.

National algorithm requirements apply to internal systems, backend communication, and non-EUDI use cases, but not to the credential signatures that Wallets must verify.

This means German federal authorities acting as Issuers must:

  1. Use P-256 for signing EUDI Wallet credentials (EU interoperability)
  2. Additionally implement TR-02102 algorithms for other federal IT systems and internal communications (national compliance)