EAA provider identity verification based on chaining and TLOL

[wfolkendt]

Draft

[Saramandus]

Thank you for this ADR suggestions, @wfolkendt - I will add it to the agenda on this week's AG meeting, if you will be there?

[moulmahdi]

Why does the the seal of EBWOID provider needs to be included in the EBWOID attestation? This doesn't bring any value since the seal is a certificate that contains the public key. Any PKI should be enough. The value is only added when the certificate of the holder is included alongside of its identity information so the that both the digital and legal identities are linked.
The EBWOID provider must be included in a trusted list (LoTE if smae as PID provider). We need that the last entity in the chain to be included in a trusted list to establish the chain of trust.
In this scenario,

• the RP will get both the EAA issued by the company and the EBWOID of this company.
• checks that the company that appears in the EBWOID is the expected one to issue this EAA
• checks that the EAA has been signed by the same key that appears in the EBVOID (the underlying private key)
• checks that the EBVOID has also been signed by the same certificate that appears in a trusted list for the claimed provider
  Then the loop can be closed and a chain of trust can be established

[Saramandus]

@wfolkendt will not be able to join the meeting today, ADR postponed two weeks for further discussion. I have added reviewers for visibility.

[sander]

Thank you @wfolkendt for proposing the ADR. I almost understand the two options and the reasoning behind it, but would first like to better understand the problem definition. My impression is still that the mandatory QESeal is sufficient.

[sander]

Why not? QESeal is a mandatory EBW feature. It does not need to be remote: the EBW owner can purchase a QSCD for on-premise operation.

[wfolkendt]

The QESEAL should not be mandatory for every type of EAA due to the following reasons:

1. Business wallets implemented in objects (e.g. tucks, cars,...) owned by a legal entity need to be able to (self-) issue e.g. during fueling/loading transactions even without internet access. For example Electronic Control Units in a car already have a secure cryptographic device as part of their hardware and it will be to difficult to include or provide access to the QSCD for each object.
2. During the verification of an EAA the EBW relying party needs access to the QTSP infrastructure to verify that the public key is really owned by the EAA issuing legal entity and to verify the revocation state. This creates the following problems: a) the QTSPS interfaces are QTSP provider specific and not harmonized within the EU b) the QTSPs gains an information advantage and market overview, he knows to which business partner an EAA provider has issued EAA's. For some type o EAA's this is also a confidential information.
3. Scalability problems due to the required contracts between millions of legal entities and only a few hundreds of QTSPs
   The QSEAL service requires a bilateral contract between the QTSP and the legal entity. That requires the involvement of lawyers, negotiations and a lot of additional effort. We have learned during the IDunion and EWC project that exactly this effort has created a lot of acceptance problems especially for small suppliers in KyS Use Cases. We need a trust infrastructure where no individual contracts are required, where terms and conditions accepted via a click are enough. This is especially important for BU1 use cases like KyS/KyC
4. The involvement of a QTSP creates administrative burden and therefore additional costs that probably reduces acceptance of the EBW and hinders EBW penetration and scalability of use cases.

[sander]

Thank you for elaborating.

Business wallets implemented in objects (e.g. tucks, cars,...) owned by a legal entity need to be able to (self-) issue e.g. during fueling/loading transactions even without internet access. For example Electronic Control Units in a car already have a secure cryptographic device as part of their hardware and it will be to difficult to include or provide access to the QSCD for each object.

The QSCD may be portable.

During the verification of an EAA the EBW relying party needs access to the QTSP infrastructure to verify that the public key is really owned by the EAA issuing legal entity and to verify the revocation state. This creates the following problems: a) the QTSPS interfaces are QTSP provider specific and not harmonized within the EU

This is thoroughly standardised in ETSI certificate policies:

• for public key ownership, there are standard subject identification attributes;
• for validity status, there is either short-lived or OCSP or CRL, and the open source Digital Signature Service abstracts over it for verification.

b) the QTSPs gains an information advantage and market overview, he knows to which business partner an EAA provider has issued EAA's. For some type o EAA's this is also a confidential information.

Both OCSP and CRL can be channeled through the wallet, so that the QTSP cannot learn which relying parties use them.

Scalability problems due to the required contracts between millions of legal entities and only a few hundreds of QTSPs
The QSEAL service requires a bilateral contract between the QTSP and the legal entity.
[…]
The involvement of a QTSP creates administrative burden and therefore additional costs that probably reduces acceptance of the EBW and hinders EBW penetration and scalability of use cases.

QESeal is a mandatory feature of the European Business Wallet, so I expect it to be included in the contract for the wallet solution.

[wfolkendt]

@sander ;
Thank you for the answers.
Our assumptions related confidentiality and related additional contracts for QESeal seem to be false.
I have to check with our Electronic Control Unit Hardware expert the QSCD topic and with wallet providers the software interface to different qTSP provider topic.
I want to state clearly that EAA provider need both the sealing functionality integrated in the EBW and the EAA chaining functionality based on wallet generated key and the EBWOID attestation that confirms the public key ownership.
During the EWC we have discussed the fact that an EAA provider needs multiple EBWOID attestations within one EBW instance depending which trust infrastructure he is forced to use.
If he needs to use EBSI for his customers he needs an EBWOID that confirms the binding of his did:ebsi to his legal entity EUID.
If he is forced to use did:web for his customers he needs EBWOID that confirms the binding of his did:web.
I have the corresponding slides and I can explain advantages/disadvantages of this infrastructures.
Malin has confirmed (in a separate issue) that a legal entity can operate mutliple EBWs and that a wallet instance can also get multliple EBWOID instances.
What do you think about the need to have different EBWOIDs (or "issuing attestations") issued with the same trustable issuing process by the EBWOID QTSP provider?
@Saramandus
However this is a separate topic/issue/ADR. I will formulate the topic as an issue or ADR after we have decided related this ADR.

[sander]

I expect that the EBWOID provides device binding to the WSCA/WSCD of the EBW, represented using a public key. See COM(2025) 838 Annex Section 16 clause (2):

Competent national authorities shall ensure that Business Wallets owner identification data that they issue is cryptographically bound to the Wallets unit to which it is issued.

However, this WSCA/WSCD key pair should only be used for interactive authentication, and not to protect the origin and integrity of EBW-issued EAA.

[alejandro-nieto-git]

I think this is key. With no Qualified Sealing for each issued (Q)EAA you can't achieve the highest level of legal certainty (physical equivalent) even if you authenticate using EBWOID.

[wfolkendt]

@sander
I know that and I agree in principle. Therefore we are asking for an additional attribute in the EBWOID that includes a public key whose private key can be used to protect origin and integrity.

"However, this WSCA/WSCD key pair should only be used for interactive authentication, and not to protect the origin and integrity of EBW-issued EAA." Is that sentence part of an implementing act or standard?

@alejandro-nieto-git
In BU1 especially in interactions with our suppliers we have a lot of data that are exchanged today via e-mail. For these data we do not need "the highest level of legal certainty (physical equivalent)". I know several legal entites with billions of turnover who today do not use a QSEAL and are able to operate. I see the advantage of QSEALs for some EAAs, but it will be very difficult to convince companies to use an EBW and in addition a QSEAL.

[sander]

@wfolkendt:

"However, this WSCA/WSCD key pair should only be used for interactive authentication, and not to protect the origin and integrity of EBW-issued EAA." Is that sentence part of an implementing act or standard?

This is my interpretation from the ECCG Agreed Cryptographic Mechanisms - version 2 Note 79-KeyUsage.

@alejandro-nieto-git In BU1 especially in interactions with our suppliers we have a lot of data that are exchanged today via e-mail. For these data we do not need "the highest level of legal certainty (physical equivalent)". I know several legal entites with billions of turnover who today do not use a QSEAL and are able to operate. I see the advantage of QSEALs for some EAAs, but it will be very difficult to convince companies to use an EBW and in addition a QSEAL.

Are these operators looking for mandatory European Business Wallet functionality to replace those emails? Instead of EAA, they could also rely on structured data with advanced electronic signatures, or less.

[wfolkendt]

@alejandro-nieto-git
These operators are exchanging company master data via e-mail due to missing standardized schemas for data.
In some use case steps for example contract signing and exchange QERDS an structured data is a an important solution.

However we prefer EAAs due to the fact that EAAs (for example an IBAN) at the beginning will be self issued and later will be replaced by EAAs issued by a more trustful issuer (in the IBAN case by a bank or account information service provider (AISP)). The difference in trust in the received data will be handled by relying party internal data quality processes.

[sander]

Providing the X.509 certificate chain is already supported in the standards:

• an mdoc DeviceResponse contains an x5chain;
• an SD-JWT supports providing the x5c in the header.

[wfolkendt]

We need to evaluate the advantages and disadvantages of an "issuing attestation" in x.509 format and an EBWOID with an additional public key.
According to one of the authors of the SD-JWT standards it is not forbidden to include an EBWOID in the header of an SD-JWT attestation.

[sander]

QTSPs confirm key binding to natural or legal persons using qualified certificates for qualified electronic signatures or seals. So do you mean that option 1 is actually about using this?

[wfolkendt]

No. I have described option 1 as: "The EBWOID attestates also the public key of the EBW owner and is included in the header of each EAA"
So in option 1 the EBWOID confirms key binding to legal person.
I am making the following assumption: The EBWOID replaces the Person Identification Data for legal entities mentioned in eIDAS2.0 and has therefore the highest legal value and therfore I would prefer to use the EBWOID and not an additional x.509 attestation. The business wallet already needs to use the "Access Attestation", the EBWOID with more or less the same attributes. Do we really need to introduce another x.509 "issuing attestation" ?

[moulmahdi]

As a QEAA, the EBWOID aloready contains the required elements to ensure the chaining. The only remaining part is to embeed this EBWOID in the attestations when issued by the business wallet.

[moulmahdi]

EBWOID, as an equivalent of a PID, needs to be issued by a QTSP. The issuer will then appear in a trusted list, including its certificate is therefore not required.
Furthermore, including this certificate by the issuer itself has no value. This would be similar to self-signed certificates

[moulmahdi]

As a QEAA, the EBWOID needs to be bound to the destination wallet. This means that the certificate of this wallet will anyway be included in the EBWOID to ensure the binding (as defined by OpenID4VC)

[miriamweber-procivis]

Looking at trust, it seems important to consider the existing EUDI trust infrastructure also for EBWs, which is already mature and could be reused. In my opinion, especially fort he Mutual Authentication part, the WRPR comes into play and could solve this:

The WRPR is part of the broader eIDAS framework, which defines who is allowed to interact with wallets as issuer or verifier and under which conditions. Any service that wants to use the EUDI Wallet must go through a formal registration process in its Member State. During this process, organizations must prove their legal identity, describe their services, specify which attributes they request or issue, explain their purposes, and provide transparency (e.g. contact details and website). Once approved, they are listed in a national register that wallets and intermediaries can query automatically before trusting a request.
This mechanism directly answers a key trust question from the user perspective: who is requesting data and whether they are authorised to do so. Although WRPR was not originally envisioned for EBW, as trust requirements were assumed to be lower, it seems highly relevant in a business context. Businesses also need strong guarantees that their counterparties are legitimate and secure. For further info, you can also look at: https://www.procivis.ch/insights/wallet-relying-party-registration

In regards to the rulebook: agreed that there will be also X.509 certificates that are used as identifiers/seals for credential issuance (also as envisioned in the EUDI context btw), but these differ from WRPR certificates, which contain additional information for trust. The current rulebook design suggests embedding EBWOID information into credentials to build a trust chain, when relying on the WRPR instead and taking over the EUDI approach, I think this EBWOID-chaining is not needed as already I have a strong basis of trust.

[wfolkendt]

@miriamweber-procivis

The WRPR is part of the broader eIDAS framework, which defines who is allowed to interact with wallets as issuer or verifier and under which conditions. Any service that wants to use the EUDI Wallet must go through a formal registration process in its Member State. During this process, organizations must prove their legal identity, describe their services, specify which attributes they request or issue, explain their purposes, and provide transparency (e.g. contact details and website). Once approved, they are listed in a national register that wallets and intermediaries can query automatically before trusting a request.

The above mentioned approach can not be transferred to EBW-to-EBW interactions. The role EBW Relying Party was introduced to avoid the registration requirement for EBW owners. If such a registration is required millions of EBW owners need to be registered if they simply want to request an IBAN or EUCC from their supplier. KyC and KyS use cases will not scale. These use cases need an open easy scalable identity ecosystem where no additional registration or B2B individual contracts are required. Such an ecosystem can be build if we use attestation chaining.
All EBW owner have performed a very similar process (legal entity identification, authorized representative identification,...) when the EBWOID was issued, therefore, they do not need to register again. We also do not need additional EAA Provider trust list because this solution will not scale for millions of EAA Providers. The national TLoL operating organisation are not prepared to handle this huge number of wallet relying parties. Exactly this is one of the main reasons why attestation chaining is mandatory required.

This mechanism directly answers a key trust question from the user perspective: who is requesting data and whether they are authorised to do so. Although WRPR was not originally envisioned for EBW, as trust requirements were assumed to be lower, it seems highly relevant in a business context. Businesses also need strong guarantees that their counterparties are legitimate and secure. For further info, you can also look at:

I agree: "WRPR are not envisioned for EBW". But the trust requirements are much higher (not "trust requirements were assumed to be lower") than the requirements for accessing an EUDI wallet. The impact when highly confidential data (like UBO, Control Structure, Ownership Structur) are accessed by a WRPR that has impersonated another Business Partner is much higher. Due to confidentiality reasons EBW owners are not allowed to share confidential data, if the data are transferred to an "EUDI wallet relying party component". This component is not certified nor has WRPR bound identity attestations nor a Wallet Unit Attestation that can be revoked.
In addition the wallets which receive a verifierInfo object including an Access and Registration Certificate according to the standard may ignore the corresponding attestations.

My conclusion is that the EUDI WRPR base of trust is insufficient and we need the attestation chaining approach.
I propose a separate meeting to discuss this topic in detail and to understand the different perspectives and to align our assumptions.

[miriamweber-procivis]

@peppelinux is there a take on this from the Trust Group? How shall trust be handled for EAA cases (e.g chaining as proposed?), do you see a relevancy for WRPR for EBWs?

[michelleludovici-ai]

Is the authorization of the BW owner to bind an EAA to an EBWOID pre-configured to always be allowed for each EAA? If not, how can the BW owner know who has allowed the binding otherwise? Is this purely a BW owner internal issue or does it need to be traceable for each EAA that an authorization to bind to the EBWOID has been given (for legal purposes)?

[michelleludovici-ai]

A few more different questions that I wonder about:

1. Is linkability not an issue for BW? Relying parties can easily trace and collude where an economic operator does business by checking the headers of transactions.
2. This procedure is not standardized and I agree with Sander, that this means a rather complicated individual implementation of fetching revocation lists, extracting the EBWOID and certificate chains, and so on, while it is done as a standard for QESeals. I am not saying it is not possible, but it is a more difficult implementation.
3. Would this not result in a lot of data that for example a DPP (digital product passport) would have to contain if it contains the whole trust history as well? Would that maybe be an issue for performance?
4. When a key-rotation is necessary, does the BW owner ask for a new EBWOID and a bound EAA?

[miriamweber-procivis]

@miriamweber-procivis

The WRPR is part of the broader eIDAS framework, which defines who is allowed to interact with wallets as issuer or verifier and under which conditions. Any service that wants to use the EUDI Wallet must go through a formal registration process in its Member State. During this process, organizations must prove their legal identity, describe their services, specify which attributes they request or issue, explain their purposes, and provide transparency (e.g. contact details and website). Once approved, they are listed in a national register that wallets and intermediaries can query automatically before trusting a request.

The above mentioned approach can not be transferred to EBW-to-EBW interactions. The role EBW Relying Party was introduced to avoid the registration requirement for EBW owners. If such a registration is required millions of EBW owners need to be registered if they simply want to request an IBAN or EUCC from their supplier. KyC and KyS use cases will not scale. These use cases need an open easy scalable identity ecosystem where no additional registration or B2B individual contracts are required. Such an ecosystem can be build if we use attestation chaining. All EBW owner have performed a very similar process (legal entity identification, authorized representative identification,...) when the EBWOID was issued, therefore, they do not need to register again. We also do not need additional EAA Provider trust list because this solution will not scale for millions of EAA Providers. The national TLoL operating organisation are not prepared to handle this huge number of wallet relying parties. Exactly this is one of the main reasons why attestation chaining is mandatory required.

This mechanism directly answers a key trust question from the user perspective: who is requesting data and whether they are authorised to do so. Although WRPR was not originally envisioned for EBW, as trust requirements were assumed to be lower, it seems highly relevant in a business context. Businesses also need strong guarantees that their counterparties are legitimate and secure. For further info, you can also look at:

I agree: "WRPR are not envisioned for EBW". But the trust requirements are much higher (not "trust requirements were assumed to be lower") than the requirements for accessing an EUDI wallet. The impact when highly confidential data (like UBO, Control Structure, Ownership Structur) are accessed by a WRPR that has impersonated another Business Partner is much higher. Due to confidentiality reasons EBW owners are not allowed to share confidential data, if the data are transferred to an "EUDI wallet relying party component". This component is not certified nor has WRPR bound identity attestations nor a Wallet Unit Attestation that can be revoked. In addition the wallets which receive a verifierInfo object including an Access and Registration Certificate according to the standard may ignore the corresponding attestations.

My conclusion is that the EUDI WRPR base of trust is insufficient and we need the attestation chaining approach. I propose a separate meeting to discuss this topic in detail and to understand the different perspectives and to align our assumptions.

The EBW usage will not be mandatory for companies / institutions. Some users - e.g banks - will already have a verifier capability in place, out of the role they play within eidas2 and the mandate they have there. We should aim that these front-runners can reuse the components they will introduce also for interactions in the EBW context I believe. Mostly, they will have also already onboarded to the WRPR in their countries and it is a trust infrastructure that exists and must be designed in the implementation to scale. This is also relevant for interactions of citizens wallets / Verifier / Issuer.

[wfolkendt]

Is the authorization of the BW owner to bind an EAA to an EBWOID pre-configured to always be allowed for each EAA? If not, how can the BW owner know who has allowed the binding otherwise? Is this purely a BW owner internal issue or does it need to be traceable for each EAA that an authorization to bind to the EBWOID has been given (for legal purposes)?

@michelleludovici-ai
Each EAA created by a EBW needs to include the EBWOID in the header. This should be part of the EBW functionality and - according to one of the SD/JWT-VC standard authors - is also compliant to the standard. Therefore the "authorization of the BW owner to bind an EAA to an EBWOID is pre-configured" and there is no need for an authorization to bind the EBWOID to an EAA for individual BW owner.
Without that binding/chaining a RP who receives an EAA can not verify that the signing key really was controlled by the EAA Provider. He gets the confirmation from the EBWOID content attested by the EBWOID issuer.

[wfolkendt]

A few more different questions that I wonder about:

1. Is linkability not an issue for BW? Relying parties can easily trace and collude where an economic operator does business by checking the headers of transactions.
   @michelleludovici-ai
   Linkability is generally considered less privacy-sensitive for legal entity wallets than for natural person wallets, because legal entities commonly operate using publicly registered identifiers such as the EUID. In many business scenarios, consistent identification is actually required for trust, compliance, and legal accountability.
   A business identity is often intended to be:

• publicly identifiable,
• legally attributable,
• and consistently recognizable across transactions.
  For example, companies already expose public identifiers such as: EUID (European Unique Identifier), VAT number,
  LEI.
  Nevertheless, some business interactions may still require confidentiality regarding transaction patterns, counterparties, or commercially sensitive activities. For example the information advantage for QERDS providers is a concern. They know with which business partners a legal entity interacts, they also know to whom they issue, ... That is a concern but also a separat topic and an important threat for the acceptance (if not solved).

2. This procedure is not standardized and I agree with Sander, that this means a rather complicated individual implementation of fetching revocation lists, extracting the EBWOID and certificate chains, and so on, while it is done as a standard for QESeals. I am not saying it is not possible, but it is a more difficult implementation.

I agree that it requires implementation effort from wallet provider side.
As mentioned above it does not contradict the standard, but it requires an HAIP document extension.
Most of the verification steps for QESeal verification can be reused (Header of the EBWOID contains the same x.509 certificates). The only additional step is the EBWOID extraction and verification. This functionality is already available in each EBW.

3. Would this not result in a lot of data that for example a DPP (digital product passport) would have to contain if it contains the whole trust history as well? Would that maybe be an issue for performance?

Yes, this will result in additional data. For large DPP systems that may be a problem it depends on how verifiable attestation will be used by DPPs (only for identification or also for DPP data) . The DPP regulation forces DPP providers to maintain the data of an insolvent DPP owner. The long term verifiability is solved.
One of our expert told me that there are several well-established cryptographic and architectural techniques that can reduce the overhead dramatically while preserving long-term verifiability (e g. Diploma and the university no longer exists) provided by attestation chaining.

4. When a key-rotation is necessary, does the BW owner ask for a new EBWOID and a bound EAA?

As described in the ADR this is a tradeoff that needs the mentioned improvement. When rotation is necessary, the BW owner ask for a new (issuer) EBWOID. He uses the new key to issue the new EAAs and embeds the new EBWOID in the header. He does not asks "for a bound EAA".