How to identify & match an issuer - EUID in the certificate data?

[rfbonte]

A relying party wants to check wether an issuer is a trusted party.
For example, is the issuer a QTSP-QEAA.

For this I think we need the EUID of the issuer in the certificate/seal, so a relying party can match the issuer in the relying party register.

Is this the way it will work?

Note, this has impact on the seals that can be used in the wallet economy and should be standardized.

[Romain-Santini]

Dear Rene,

Please find some answers below.

There are essentially two cases:

1. The issuer is either a qualified trust service provider (issuing a QEAA) or a public body responsible for an authentic source (issuing a Pub-EAA), or
2. The issuer is a non-qualified trust service provider.

In the first case, the LOTL and the relevant certificates already provide all the information we need. The content of the attestation itself, as well as that of the underlying qualified electronic signature or seal, is defined in the Regulation (see the Annexes to Regulation 910/2014, as amended by Regulation 2024/1183) and further specified in the relevant ETSI standards.

The trust model is also designed in such a way that all the necessary information is available in the attestation and in the certificate of the signature/seal, allowing the correct trust anchor to be identified in the LOTL. This is usually the certification authority for which the subjectDN matches the issuerDN of the signature/seal certificate.

The identifier used for this matching may vary from one Member State to another. In France, for example, we use the name of the legal entity together with its “SIREN” identifier. However, since the matching is performed between the data contained in the seal/signature certificate and the data published in the LOTL, both of which are subject to the oversight and review of the QTSP and the supervisory body, there is, in practice, very little room for inconsistency.

Therefore, I do not think we need to introduce the RP registry or the EUID into this process. The existing model already works in practice and has done so without issue for several years for qualified trust services under the original eIDAS Regulation.

In the second case, things become somewhat more complicated. To my knowledge, there is no widely agreed rule defining the content of such attestations or certificates, nor do we have a reference list or registry of non-qualified issuers. Some of these issuers may be included in the LOTLs, but this is at the discretion of each Member State, and there is no requirement for ex ante supervision of non qualified TSPs.

Therefore I am of the opinion that non-qualified attestations should preferably be used in ecosystems where the parties already know and trust each other and have established the corresponding trust anchors. Where trust needs to be established among a large number of parties that do not know each other and have not agreed on common trust anchors, QEAAs and Pub-EAAs should be used instead.

In any event, I do not think that using the registry of relying parties is the best way to address this issue, as this is not the purpose of the registry. The registry is intended to allow EUDI Wallets to establish that relying parties (including issuers) have undergone a basic GDPR compliance process, by declaring the intended use of the Wallet and the data they intend to collect, and that they are therefore authorised to communicate with EUDI Wallets.

Being included in the registry does not, in my understanding, provide any assurance regarding the specific processes followed by an attestation issuer, nor does it provide any additional assurance as to the trustworthiness of the attestations it issues. I therefore do not think that inclusion in the registry should be used as a trust anchor for relying parties.