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 that should be used and are based on the recommendation of the BSI and SOG-IS.

• Issuer Signatures, DeviceSigned:
  • ECDSA using brainpoolP512r1 and SHA-512
  • ECDSA using brainpoolP384r1 and SHA-384
  • ECDSA using brainpoolP256r1 and SHA-256
  • ECDSA using secp256r1 and SHA-256
• Key binding/presentation and Verifier Signatures:
  • ECDSA using brainpoolP384r1 and SHA-384
  • ECDSA using secp256r1 and SHA-256
• MAC:
  • ECDH with secp256r1 + hmac-sha2
• Encryption:
  • AES-256-GCM
• Hashing, PKCE (code challenge method):
  • SHA-256
• DPoP:
  • ECDSA using secp256r1 and SHA-256

Note: The Brainpool curves currently do not have identifiers in the IANA registry for JOSE. Since there are multiple algorithms for the issuer to sign a credential, the relying party and the wallet provider needs to implement all of them. The same applies for the key binding/presentation.

In a later version of this document, we will evaluate if we can reduce the number of algorithms to reduce complexity.