search

eu-digital-identity-wallet / eudi-doc-architecture-and-reference-framework

The European Digital Identity Wallet
https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/
Other
369 stars 55 forks source link

Support in ARF for *authenticated channels* according to German architecture proposal? #165

Open kernoelpanic opened 2 months ago

kernoelpanic commented 2 months ago

The German Architecture Proposal Version 2 (from 2024-03-21) lists several different solution options (B, B',D, C', and C). From these options the first three (B, B' and D) rely mainly on trusted hardware and authenticated channels between this trusted hardware and the Wallet Provider, PID Provider, or Relying Party on the other side.

As I see it, the current ARF v1.3 mainly focuses on forms of signed credentials (according to the nomenclature of the German Architecture Proposal, where they are described as solution option C' or C).

So my question would be: Are approaches utilizing the concept of authenticated channels between trusted hardware and the WP, PP or RP already permissible according to the current version of the ARF, e.g., by the following trust requirements:

The EUDI Wallet is certified as a qualified signature/seal creation device (QSCD), ...

The EUDI Wallet Provider needs to be able to trust the EUDI Wallet Instance.

The Provider SHALL be able to trust the EUDI Wallet Provider.

The Relying Party SHALL be able to trust the attestation Provider.

Or are such solution options using authenticated channels and MACs not permissible according to the current version of the ARF, e.g., indicated maybe by the following paragraphs which talk explicitly about public keys and signatures (not MACs):

The Relying Party verifies that the public key it used for verifying the seal or signature can be trusted, ... ref

To verify this signature, the Relying Party needs to receive the public key of the attestation, which SHALL be signed (directly or indirectly) by the Provider of the attestation. By signing the public key, the Provider certifies that the public key indeed belongs to the attestation. ref

All attestations are assumed to be signed by the attestation Provider, rather than by the EUDI Wallet Instance (the latter are sometimes called self-signed attestations). ref

If authenticated channel based solution options according to the German Architecture Proposal are not already covered (due to such specifics), will such concepts be explicitly added in a future version?

pinamiranda commented 1 month ago

Thank you for your comment, that was accepted (and added to ARF 1.4.0)

We have made two changes prior to publication of ARF 1.4.0:

  1. This section (6.6.3.5) now allows the use of device-signed or self-issued attestations, provided that such solutions are certified for LoA “high”.
  2. We have added another bullet in section 6.6.3.5 explaining that solutions based on an authenticated channels are allowed. However, we emphasize that any solution must be fully conformant with the interface specifications between Wallet Instance and Relying Party (i.e., ISO 18013-5 and OpenID4VP). Otherwise, interoperability issues will occur.