Architecture decision records

WE BUILD maintains a lightweight architecture decision record (ADR) for each software-related decision affecting interoperability.

Propose new ADRs using the template. Announce them to the Architecture group in the Portal to get feedback to understand the consortium’s opinion.

1 ADR process for WE BUILD

stateDiagram-v2
    state "Pull request (PR) with new ADR" as pr
    state "PR ready to merge" as ready
    state "Consortium decision" as merged
    state "Proposal rejected" as rejected

    [*] --> pr: Any consortium participant proposes
    pr --> ready: Consortium participants review and share advice, authors improve the ADR including summarised advice

    ready --> merged: WP4 Architecture group merges the PR
    merged --> [*]

    ready --> rejected: WP4 Architecture group closes the PR
    rejected --> [*]

2 ADR overview

2.1 Publish consortium trusted lists

Authors:

  • Sander Dijkhuis, Cleverbase, the Netherlands

2.1.1 Context

For the first usage of the interoperability testbed, and for the first increment, it is required to enable trust between issuers, wallets, and verifiers. EWC proposed a trust evaluation mechanism (see EWC RFC 012) including an Trusted List.

According to the evaluation made so far by the Mapping Task Force, at least the QTSP group needs a similar approach for the first QEAAs to test. We need to specify who provides this.

At ETSI, the TS 119 612 (V2.3.1 at time of this release) series is being updated to support the European Digital Identity. This may require further alignment with the current EWC implementations.

2.1.2 Decision

The WP4 Trust Registry Infrastructure group provides trusted lists.

The issuers in the WP4 PID/LPID/QTSP/Wallet provider groups request registration on the trusted lists before testing.

The wallets in the WP4 Wallet provider group include validation with the trusted lists in their verification processes.

The relying parties in WP2/3/4 include validation with the trusted lists in their verification processes.

The starting point is TS 119 612 V2.3.1. Since a profile and implementation guidance are likely needed, and EWC RFC 012 has not yet been effective in practice, these should be specified in separate WE BUILD architecture documents.

2.1.3 Consequences

This decision makes interop between consortium members easier.

This decision makes it harder to test with ad-hoc pairwise trust relationships.

To address the risk of bottlenecks in implementing this decision, the Mapping Task Force pays extra attention to potential blockers for each involved WP4 group.

2.1.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision. In the decision making process, we have heard the following advice.

  • 2025-10-27, Leif Johansson, Sunet, Sweden: OK
  • 2025-10-27, Giuseppe De Marco, Dipartimento per la trasformazione digitale, Italy: OK

2.2 Baseline protocols

Authors:

  • Leif Johansson, Sunet, Sweden
  • Sander Dijkhuis, Cleverbase, the Netherlands
  • Sarah Amandusson, Digg, Sweden
  • George J Padayatti, iGrant.io, Sweden
  • Lal Chandran, iGrant.io, Sweden

2.2.1 Context

The EUDI Wallet ecosystem is mandated by eIDAS to ensure secure, interoperable cross-border digital identity. This implementation is guided by the Architecture and Reference Framework (ARF), which translates legal mandates into technical specifications. To achieve mandatory interoperability for Issuance and Presentation of Person Identification Data (PID) and Electronic Attestations of Attributes (EAA), implementing regulations require compliance with foundational standards. OID4VCI (Issuance) and OID4VP (Presentation) are adopted as the ARF-recommended baseline protocols for technically implementing the required data models and web-based transport mechanisms in the pilot.

Proximity flows are out of scope for the current architecture decision.

While the architecture decision to Publish consortium trusted lists based on TS 119 612 has already been recorded, the consortium also needs a selection of PID/EAA issuance and presentation protocols.

2.2.2 Decision

Each recognized role in the WE BUILD project - PID/LPID Providers, EAA Providers (including QEAA, Pub-EAA), Relying Parties, Wallet Providers, and Trust Service Providers — is REQUIRED to implement the corresponding technical profiles described here. Actors performing multiple roles MUST meet all requirements relevant to those roles.

2.2.3 Consequences

Implementations following this profile ensure interoperability between actors within the WE BUILD ecosystem. Actors can verify conformance through testing against other implementations.

The selected protocols may not suffice for async or proximity use cases. Once the requirements for such use cases appear, the decision may need to be nuanced to enable for example Relying Parties to implement different protocols.

2.2.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision.

2.3 Specify PID and eAA formats

Authors:

  • Sander Dijkhuis, Cleverbase, the Netherlands

2.3.1 Context

To issue PID (including LPID) and eAA (including QeAA and PuB-EAA), it is necessary to specify a digital document format such as mdoc or a JWT-based one. While the EUDI implementing acts specify baseline standards, these specifications may not suffice for WE BUILD. For example, some specified standards need further profiling for interoperability. For some WE BUILD use cases, other standards may be necessary, for example to enable asynchronous interactions with EU Business Wallets, or to enable legal, technical and semantic interoperability with existing systems.

Several WP4 groups are stakeholders in this, for example:

  • WP4 Architecture, for conformance to and efficient implementation of the EUDI framework
  • WP4 PID and LPID Providers, for technical details of the provision of PID and LPID
  • WP4 QTSPs, for technical details of the issuance and validation of QeAA
  • WP4 Semantics, where the specification affects semantic interoperability

To ensure a streamlined process, the Mapping Task Force has evaluated the possible dependencies within WP4.

Out of scope of this evaluation were the dependencies with WP2 and WP3. After the use case stock taking, these should guide the decisions about formats made within WP4. If needed, the WP4 Architecture support teams can help gain input and feedback.

2.3.2 Decision

The WP4 Architecture group specifies digital document formats for PID and eAA.

The WP4 PID and LPID Providers and the WP4 QTSPs are expected to conform to these decisions.

The vocabularies that WP4 Semantics group delivers, may be in a format that is unrelated to the specified digital document formats.

The WP4 Semantics group is expected to ensure semantic interoperability of digital documents using the specified digital document type, if the specified digital document type supports semantic mapping, such as in Verifiable Credentials Data Model v2.0. If not, such as in ISO/IEC 18013-5 mdoc, extra translation may be needed to match vocabularies specified by the WP4 Semantics group. In such cases, the translation is the responsibility of the scheme owners.

2.3.3 Consequences

This decision clarifies the decision process regarding digital document formats for PID and eAA. Other decisions should be recorded soon after to specify the concrete formats for PID and eAA for European Digital Identity Wallets and for European Business Wallets.

This decision creates an indirection between the vocabularies and the digital document formats for PID and eAA, so that the extra translation may be needed if the format does not support semantic annotations. In this case, the translation is the responsibility of the scheme owners.

As an alternative, it has been considered to decide on WP4 Semantics specifying digital document formats for PID and eAA, which would facilitate semantic interoperability, potentially at the cost of technical and legal interoperability. However, since these are cross-cutting decisions, the Mapping Task Force suggests that instead the WP4 Semantics group advices the WP4 Architecture group so that the latter sufficiently takes semantic interoperability into account, for example the ability to support links to globally defined semantic models.

2.3.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision. In the decision making process, we have heared the following advice.

  • 2025-11-11, Ronald Koenig, Spherity, Germany: OK

2.4 Provide EBWOID as a stable minimal basis

Authors:

  • Sander Dijkhuis, Cleverbase, the Netherlands

2.4.1 Context

In BU3 on foreign tax declaration, an issue on Identifiers in LPID was raised to WP4 Architecture, which extends to EBWOID. In this context, EBWOID is European Business Wallet owner identification data. Should the EBWOID just be a “bootstrap identity” with a stable minimum attribute set, or should EBWOID be a “dynamic reference framework” containing many relevant attributes registered by competent bodies?

In the Annex of (EU) 2024/2977, Table 3 specifies mandatory legal person identification data in line with the “bootstrap identity”, and Table 4 specifies optional legal person identification data that leans more towards the “dynamic reference framework”.

In COM(2025) 838 final, Article 8(5) the EBWOID is specified to contain just the name and unique identifier in accordance with Article 9. Furthermore, in Article 20, legal person identification data may become irrelevant under EU Digital Identity.

The implementation choice affects what other electronic attestations of attributes may be needed for use cases such as BU3.

Under EU Digital Identity, EU Member States may take different decisions with regard to this. The upcoming EU Business Wallet legislation may affect these decisions.

To achieve cross-border interoperability within WE BUILD, several options are possible:

  • basic EBWOID everywhere (minimum attributes from a single source)
  • extended EBWOID everywhere (attributes such as the VAT registration number)
  • basic EBWOID in some EU Member States, extended EBWOID in others

2.4.2 Decision

Rely on basic EBWOID everywhere as a minimum identity attestation which must be supported by everyone. Develop use cases under the assumption that other attributes require additional electronic attestations. These other attributes can be used both for identifying the economic operator and for verifying additional claims.

2.4.3 Consequences

The EBWOID rulebook should be kept in line with this decision.

With this decision, it becomes easier to reason about the minimum set of additional electronic attestations.

With this decision, it becomes more difficult to test the extended EBWOID case, which may be relevant to some EU Member States. But note that the decision does not preclude testing with extended EBWOID as well.

To manage the risk that this approach differs from EU Business Wallet legislation, WE BUILD should take the definition of EBWOID in account in its upcoming definition of an EU Business Wallet.

To get started with the minimum identification data, the WP4 PID/LPID group should specify which unique identifier(s) to use.

2.4.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision. In the decision making process, we have heard the following advice.

2.5 Wallet Unit Attestation and Lifecycle Management (For European Business Wallet)

Status: Proposed
Date: 11 February 2026
Authors: WP4 Architecture

  • Lal Chandran, iGrant.io, Sweden
  • Sander Dijkhuis, Cleverbase, the Netherlands
  • George J Padayatti, iGrant.io, Sweden

2.5.1 Context

The European Business Wallet represents an economic operator or public sector body and operates within a cloud or on-premise environment under regulatory oversight derived from revised eIDAS and related Implementing Regulations.

Trust in a Business Wallet must be established at two distinct levels:

  1. Cybersecurity assurance in the wallet’s secure execution and key management environment.
  2. Organisational entity authentication assurance (cf. ISO/IEC 29115) represented by the European Business Wallet Owner ID (EBWOID).

At present, the WE BUILD architecture does not formally define:

  • A Wallet Unit Attestation (WUA) model for European Business Wallet.
  • A Wallet Instance Attestation (WIA) model and its relationship to the WUA.
  • A clear lifecycle model governing Wallet Unit states.
  • The downgrade and revocation semantics between structural and identity trust.

Without an explicit lifecycle and attestation model, revocation handling, issuance eligibility and cross-border interoperability remain ambiguous.

2.5.2 Decision

The European Business Wallet SHALL introduce:

  1. A mandatory Wallet Unit Attestation (WUA).
  2. A defined lifecycle model governing Wallet Unit state transitions.
  3. For this ADR, WIA is not considered for the first iteration of WE BUILD at least.

2.5.2.1 Wallet Unit Attestation (WUA)

A Wallet Unit Attestation is a signed object issued by the Wallet Provider that:

  • Binds the Wallet Unit to a secure cryptographic environment.
  • Contains public keys used for credential binding.
  • Includes validity and revocation information.
  • Is presented to Issuers and Attestation Providers.
  • Is presented to Relying Parties when required to determine Wallet Unit validity, for example via selective disclosure mechanisms.

A valid WUA is required for a Wallet Unit to operate within the EBW ecosystem.

2.5.2.2 Wallet Unit Lifecycle Model

The Wallet Unit SHALL follow the lifecycle states defined below:

UNINSTALLED

No wallet instantiated. No cryptographic material. No WUA. No EBWOID.

INSTALLED

Wallet software deployed and environment prepared, but no WUA issued.

OPERATIONAL

Valid WUA present. Structural trust established. EBWOID not yet acquired or pending.

VALID

Valid WUA and valid EBWOID present. Fully functional for regulated and cross-border use.

2.5.2.3 State Transitions

  • UNINSTALLED → INSTALLED
    Organisation instantiates the software.

  • INSTALLED → OPERATIONAL
    Wallet Unit acquires the WUA.

  • OPERATIONAL → VALID
    A natural person requests and obtains the EBWOID on behalf of the Economic Operator, which is then bound to the Wallet Unit.

  • VALID → OPERATIONAL
    EBWOID revoked or expired.

  • OPERATIONAL or VALID → INSTALLED
    WUA revoked or expired.

  • INSTALLED → UNINSTALLED Uninstallation or decommissioning of a WU, for e.g. during porting from one service provider to other.

Structural trust (WUA) is foundational. Identity trust (EBWOID) depends upon it. A Wallet Unit cannot be VALID without a valid WUA.

2.5.3 Consequences

  • Cybersecurity assurance and Organisational entity authentication assurance are explicitly separated.
  • Revocation of WUA immediately suspends infrastructural legitimacy.
  • Revocation of EBWOID suspends identity validity while preserving structural trust. Where EBWOID is short-lived, the dependency between WUA revocation and EBWOID validity must be further specified in the implementing acts to ensure Relying Parties are not exposed to invalid Wallet Units.
  • Issuers gain a clear rule for issuance eligibility.
  • Lifecycle handling becomes testable within ITB and conformance specifications.
  • Cross-border interoperability is strengthened through explicit state semantics.
  • Wallet Providers are expected to implement this which will be elaborated on further, for.g. via a conformance specification.

This ADR establishes WUA and lifecycle management as mandatory architectural functions of the European Business Wallet. It does not yet establish lifecycle management for entry in the WE BUILD Digital Directory, to simulate the European Digital Directory. This is another layer, which governs the availability of the wallet owner for notifications and submission of documents.

2.5.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision. In the decision making process, we have heard the following advice.

2.5.5 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision. In the decision making process, we have heard the following advice.

2026-02-11, Sander Dijkhuis, Cleverbase, Netherlands 2026-02-11, George Padayatti, iGrant.io, Sweden 2026-02-12, George Fourtounis, GRNET, Greece 2026-02-12, Malin Norlander, Bolagsverket, Sweden

2.6 Replace LPID with EBWOID

Authors: - Erwin Nieuwlaar, KVK, Netherlands

2.6.1 Context:

In webuild-consortium/eudi-wallet-rulebooks-and-schemas#24, the LPID (Legal Person Identification Data) rulebook was removed in favour of the EBWOID (European Business Wallet Owner Identification Data) rulebook. It was unclear whether this represented a consortium decision. Hence, an ADR to discuss support/objections and document this decision is clearly. The PID/EBWOID working group agreed to proceed with this change during a weekly discussion session.

2.6.2 Decision

WE BUILD will use the EBWOID rulebook as the basis for identification of business wallet owners and deprecate LPID within WE BUILD: - No new WE BUILD specifications should reference LPID - Existing WE BUILD references to LPID should be migrated to EBWOID

2.6.3 Consequences

Positive: - One clear rulebook for implementers - Reduced duplication

Negative/Risks: - Migration effort from LPID to EBWOID - EBWOID originates from the Business Wallet proposal, which is not yet in force. There will be an interim period in which eIDAS 2.0 is applicable while the Business Wallet framework is not, creating a risk of misalignment in identifying legal persons

2.6.4 Advice

2.7 Deliver business wallet data using QERDS

Authors:

  • Sander Dijkhuis, Cleverbase, the Netherlands
  • Leif Johansson, SIROS, Sweden

2.7.1 Context

The WP4 Architecture group discussed at the IRL Workshop the draft on eDelivery for wallet-to-wallet messaging. Afterwards, the European Commission published the European Business Wallet (EBW) proposal COM(2025) 838 final that includes a secure communication channel: a designated qualified electronic registered delivery service (QERDS). See the definition in Business Wallet Definition (version 2026-01-14). This definition and the WE BUILD approach was discussed during the Business Wallet Workshop.

While the QERDS was already part of the WE BUILD Grant Agreement, this record makes it explicit part of the WE BUILD architecture and specifies high-level starting points. Use cases are encouraged to specify scenarios with the QERDS in wallet-to-wallet interactions as well as using gateways to connect to existing infrastructures.

The QERDS should comply to the eIDAS requirements for QERDS as well as the proposed EBW requirements for the designated QERDS. The Commission Implementing Regulation (EU) 2025/1944 applies regarding “reference standards for processes for sending and receiving data in [QERDS]s and as regards interoperability of those services”. For the designated QERDS, no draft implementing act is available yet, but high-level requirements are included in the EBW proposal Annex chapter 11, as well as Article 5(3) for availability to European Digital Identity Wallets. It is expected that WE BUILD implementation experience can contribute to the specification of the EBW implementing act.

Key assumptions are:

  • the use of the European Digital Directory (EBW Article 10) for identification (looking up EUIDs), discovery (finding networks and capabilities), and connections (retrieving protocol and endpoint information including public keys);
  • the ability for multiple qualified trust service providers to federatively provide the QERDS;
  • the application of architecture models from the reference standard EN 319 522-1:
    • 4-corner model (§ 4.3) for EBW-to-EBW exchange;
    • extended model (§ 4.4) for exchange through a gateway (EBW Article 16(6)(b)).

For EBW-to-QERDS communication, there does not yet seem to exist a common protocol and the WP4 Architecture group has discussed various ideas.

For communication between QERDS providers, the reference standard EN 319 522-4-1 specifies bindings based on AS4 (HTTP-based protocol in ISO 15000-2:2021, OASIS Standard) or email. The AS4 standard is referenced in EU legislation and implementations such as Peppol using the eDelivery AS4 building block. Other protocols that follow the same architectural model exist, and are outlined in the considered alternatives later in this section.

The AS4 protocol is based on XML signature and encryption which does do not yet provide post-quantum safety. There is no current effort in any standards development organisation to propose post-quantum algorithms for XML signatures or key agreement/encryption. This means that the effective lifetime of a solution based on AS4 as-is is limited to a maximum of 6 or 7 years from the required go-live date for the European Business Wallet. Therefore, in a production ecosystem, protocol migration should be possible.

The 4-corner model of the AS4 architecture provides a way to introduce an abstraction layer towards the QERDS, which means that in principle it is possible to replace the underlying QERDS protocol in the future, although such a task would present significant challenges in practice.

The following alternatives were considered:

  • OpenID4VC and ISO/IEC 18013-7 are standards for receiving credentials into and generating and presenting proofs from the EUDI Wallet. These protocols are well suited for flows that involve user interaction, but are more difficult to adapt to flows that involve automated systems or agents.
  • DIDComm is conceptually quite similar to AS4 and has many benefits including a better path towards quantum safe signatures and encryption than an XML-based protocol has at this point. The downside of this alternative is that the standards need to be profiled for use in the EU, for example to reference existing trust infrastructure.
  • Alternatively, a new suite of protocols could be developed that fulfill the expected requirements of the EUBW such as suitability for automation and agents, compatibility with the EUDI natural person wallet etc. There are several options that could serve as a modern starting point for such work including the Matrix protocol and ActivityPub.

2.7.2 Decision

WE BUILD tests and pilots a designated QERDS, with the following responsibilities:

  • WP4 Trust Registry Infrastructure group establishes a WE BUILD Digital Directory aligned with the EU Digital Directory standards.
  • WP4 QTSP group, in consultation with WP4 Architecture and WP4 Wallet Providers groups, specifies an optional API access protocol as an abstraction layer between the wallet and the QERDS.
  • WP4 QTSP group facilitates pilots using (EU) 2025/1944 and eDelivery AS4.
  • WP4 Architecture and WP4 QTSP groups jointly evaluate the requirements for a potential “AS5” alternative QERDS protocol, based on the needs of WP2/WP3 use cases.

If use cases require gateways to the designated QERDS, in principle the use cases are responsible for providing those gateways.

2.7.3 Consequences

Testing and piloting with a designated QERDS makes it easier:

  • To implement use cases for the EUBW that requires automation and/or agent-based access.
  • To connect with organisations responsible for authentic sources for the retrieval and/or verification of attributes, which is necessary for the issuance of qualified electronic attestations of attributes (see Feature: Verification of attributes).
  • To develop the QERDS aspect of the envisioned EBW ecosystem, building upon existing ecosystems like the Once-Only Technical System and Peppol, using the WE BUILD ecosystem and its Interoperability Test Bed to provide a meaningful and collaborative context.

Open issues:

  • Adapting end-to-end encryption in the four-corner model to the European Business Wallet.
  • Support hardware bound credentials and differentiated level of assurance.

The WP4 Architecture group can provide the necessary design competence.

The following risks need to be addressed:

  • QERDS and eDelivery are new subject matter to several wallet providers and implementers. They may be tempted to instead mold the well-known OpenID4VC protocols to use cases that are better suited for QERDS. To address this risk, WP4 Architecture group members and in particular Use Case Sync Leads are expected to learn about QERDS and engage with the WP2/WP3 groups to learn which practical use cases will drive adoption of automation and agent-based flows that are the main motivators for using QERDS in the EBW.
  • The QERDS requires several cross-group implementations. To reduce interoperability risks, the WP4 QTSP group should:
    • specify at least two Conformance Specifications in consultation with stakeholder groups:
      • EBW-to-QERDS;
      • QTSP-to-QTSP for QERDS;
      • (if use cases need it) EUDIW-to-QERDS;
    • work with the WP4 Testing group to perform testing using these Conformance Specifications on the Interoperability Test Bed.

2.7.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision. In the decision making process, we have heard the following advice.

2.8 Attestation Revocation Mechanism

Authors:

  • Artur Reaboi, e-Governance Agency, Republic of Moldova
  • Alexandru Cozlovschi, e-Governance Agency, Republic of Moldova
  • Fabrizio Notarnicola, InfoCamere, Italy
  • Alessandro Bazzolo, InfoCamere, Italy

2.8.1 Context

Revocation is the process by which an attestation (including PID/EBWOID) is invalidated before its natural expiry so that it can no longer be trusted or used. While short-lived attestations (expiring in 24 hours or less) do not require revocation, long-term attestations need a standardized mechanism to handle invalidation due to reasons such as lost devices, data inaccuracy, or regulatory changes.

The architecture must ensure that the revocation status check preserves the privacy of the Wallet Holder (herd privacy) and allows for scalable implementation. Additionally, the solution must align with the OpenID4VC HAIP 1.0 specifications.

2.8.2 Decision

The WE BUILD project adopts the IETF Token Status List as the mechanism for semantics, formats, and protocols regarding revocation of attestations.

2.8.3 Consequences

2.8.3.1 Easier:

  • Alignment with OpenID4VC HAIP 1.0 for SD-JWT format is ensured, facilitating interoperability.
  • Relying Parties have a standardized format to check for validity across different issuers.

2.8.3.2 More Difficult:

  • To ensure performance and privacy, Issuers must implement complex state management. One way to do it is to pre-allocate random indices in batches, rather than simple sequential generation.
  • As Issuers have the sole right to revoke PIDs/EBWOIDs, Authentic Sources and Issuers must establish protocols to notify the Issuer of events requiring revocation (e.g., data changes or lost devices), as they cannot directly revoke an attestation.

2.8.3.3 Risks:

  • Offline verification scenarios require Relying Parties to cache revocation lists. To address this, Issuers should include expiration dates and time-to-live (TTL) in revocation info to drive caching decisions.

2.8.3.4 Impact (resulting from ADR High-Level Requirements):

  • Issuers (PID/EBWOID Providers, EAA Providers, including QEAA, Pub-EAA) MUST implement attestation revocation for applicable attestations and that are valid for more than 24h. Revocable attestations MUST be assigned a random status list and random index within it before being signed, all in batches.
  • Issuers MUST ensure the invalid status for not yet expired and revoked attestations is published within a reasonable amount of time (for instance, under 1h).
  • Wallet Providers SHOULD ensure their Wallet Units regularly check the revocation status of its PIDs/EBWOIDs and other attestations, and notify the User if any is revoked.
  • Relying Parties SHOULD check the revocation status via a Revocation Status Service. If reliable information is unavailable, they SHOULD perform a risk analysis rather than a mandatory failure.

2.8.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision.

In the decision making process, we have heard the following advice: - 2026-02-04, Jonas Toeniss, Brønnøysundregistrene (BRC), Norway: Move Impact items to Consequences section - 2026-02-13, Feedback in WP4 Architecture meeting: Clarify that regular check of WUA revocation is a MUST only for PID/EBWOID Providers - 2026-02-17, Eelco Klaver, Credenco B.V., Netherlands: WUA implementation and impact to be decided in a separate ADR

2.9 Separate the QERDS agent, log and relay

Authors:

  • Sander Dijkhuis, Cleverbase, the Netherlands

2.9.1 Context

To Deliver business wallet data using QERDS, the WP4 QTSP group is specifying an interoperability framework for testing and piloting this Qualified Electronic Registered Delivery Service using WE BUILD Business Wallets. The current architecture decision is about how to structure this framework.

To reason about this structure, we adopt the concept of a package: an immutable sealed artifact comprising user content, delivery evidence, and relay metadata, as proposed in ETSI TR 119 520-1. The package is potentially partly or fully end-to-end encrypted.

Three major functional components of the WE BUILD reference architecture are:

  • delivery agent: register evidence of submission or notification upon identity verification of the sender or recipient;
  • delivery log: ensure retention of this evidence for stakeholders, for example to resolve disputes;
  • delivery relay: between QERDS providers, relay documents, notifications, or evidence.

To simplify the framework, TR 119 520-1 proposes to treat the above as orthogonal concerns. In this treatment, the delivery agent (“smart wrap service”) results in dispatch or receipt packages. This means that most security requirements regarding confidentiality and integrity are implemented by QERDS providers in their delivery agent role. Delivery relay (“XXTP(S) service”) is about transport protocols for interoperable message exchange between QERDS providers, and is only necessary if the sender uses another provider than the recipient. The delivery log can optionally be supported by tracking technology such as electronic ledgers.

An alternative approach would be to implement QERDS security requirements using the security features of the delivery relay interoperability protocol. For example, eDelivery AS4 applies XML Signature and XML Encryption features for delivery relay. Implementations of QERDS could apply these features to protect not only the relay metadata exchanged between QERDS providers, but also the submission or notification and the QERDS evidence. However, this would increase the complexity of changes to either the security or interoperability specifications.

The ETSI EN 319 522 series have not yet been updated to apply the findings from TR 119 520-1, and there do not seem to be concrete plans to. The ETSI STF 705 project WP4 ongoing until June 2027 or another project may apply this eventually. In the meantime, WE BUILD needs to have some interoperability profile that works today and is sufficiently future-proof with the current knowledge.

2.9.2 Decision

WE BUILD separates the specification of:

  • delivery agent to produce, consume, and delivery packages enforcing access control;
  • delivery log to make available registered evidence of events the agent records;
  • delivery relay to transport packages across QERDS providers.

In the context of delivery registry, the semantics of the packages are defined in ETSI EN 319 522-2. Following TR 119 520-1, WE BUILD applies at minimum:

  • dispatch package (“ERD dispatch”): document submission or procedural notification, along with delivery evidence;
  • receipt package (“ERDS receipt”): notification of a delivery event related to an earlier dispatch package.

For delivery relay, the transport protects against QERDS provider impersonation and eavesdropping relay metadata. It is applied only under the condition the sender and recipient have different QERDS providers.

2.9.3 Consequences

The decision makes it easier to learn about the consequences of the technical direction in TR 119 520-1. It also decomposes the problem into two sub-problems, making it easier to specify technical solutions. The decomposition also enables separate interoperability testing of the specifications.

The decision precludes solutions where the transport protocol may already provide the end-to-end security required from QERDS in European Business Wallets. For example, while mTLS between business wallet instances could technically be used for the mandatory identification of sender and recipient or for the mandatory end-to-end encryption, WE BUILD deliberately decouples these functions from the transport.

Especially if package apply end-to-end security, the decision reduces the ability for delivery relay operators to add value beyond transport, as for example Peppol Service Providers do: format transformation, compliance validation, routing, and access management. A delivery relay operator cannot transform the payload without breaking the seal, and cannot even read it if the content is encrypted. The architecture does not answer the question where such value may be added instead: at the delivery agent, at the business wallet, or as its client application? These are consequential questions for the ecosystem of service providers that currently operate network infrastructure.

The main interoperability risk to manage is divergence with the ongoing ETSI standardisation and European Business Wallet legislation by the European Commission, rendering the test and pilot results less relevant for the production ecosystem. We address this risk by requesting early feedback on WE BUILD deliverables from both the Commission and ETSI STF 705 WP4.

2.9.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision. In the decision making process, we have heard the following advice.

2.10 Structure the European Digital Directory as identification, discovery, and connection

Authors:

  • Rune Kjørlaug, OpenPeppol, Belgium

2.10.1 Context

The EBW proposal COM(2025) 838 final establishes the European Digital Directory (EDD) in Article 10 as the trusted source for locating and contacting EBW owners. The regulation implicitly combines three logically distinct operations into a single “directory” concept: identification (resolving an actor to a stable legal identifier), discovery (finding which networks and processes they are reachable through), and connection (retrieving the technical endpoint for message delivery). Without explicit separation, the EDD risks becoming a duplicated capability registry re-implementing what existing EU eDelivery infrastructure already provides.

A further complication is that the EUID, the primary legal identifier for registered companies under Directive (EU) 2017/1132, is itself ISO 6523-compliant by regulatory mandate: Commission Implementing Regulation (EU) 2021/1042 specifies in its Annex that “the structure of the EUID shall be compliant with ISO 6523.” This means the EDD, Peppol, and EN 16931 already share a coherent identifier framework, and the EDD should build on that rather than introduce a parallel layer. However, EUID and BRIS do not cover sole traders, self-employed persons, or public institutions, leaving a registration gap for actor types that appear frequently in SC1 and SC5 use cases.

Three approaches to the discovery and connection layers were considered. A proprietary EDD API specified by Commission implementing act alone would create parallel, incompatible discovery infrastructure alongside existing eDelivery networks. Decentralised identifier resolution (W3C DIDs, distributed ledger approaches) is conceptually interesting but incompatible with AS4/ISO 6523 networks within the WE BUILD timeframe. eDelivery BDXL 2.0 combined with ecosystem SMP 2.0 reuses proven, EU-mandated infrastructure: BDXL 2.0 resolves an ISO 6523 identifier to a capability registry URL using a Service-to-network and Process-to-process mapping; the ecosystem’s own SMP (e.g. Peppol Discovery building block) handles endpoint detail. This keeps the EDD lean and supports federated operation.

For Step 2 capability discovery, OpenID4VCI Issuer Metadata, OpenID Federation, and the WE BUILD Trust List already provide cross-organisational capability signals within the wallet ecosystem. The EDD must not duplicate these: any capability discovery beyond what SMP process registration covers should be handled as metadata extensions to existing mechanisms. This constraint does not affect Step 1, where all three technologies presuppose a known technical endpoint and do not bridge from legal business identity to a wallet address — which remains the EDD’s primary role under Article 10.

This ADR covers infrastructure-mediated document exchange (QERDS, AS4/Peppol, eFTI). Discovery for direct wallet-to-wallet flows using OpenID4VC/VP raises different architectural and privacy considerations and is recorded as an open issue in the supporting analysis.

For detailed analysis including sequence diagrams, the BDXL 2.0 profile design, identification gaps, and risks, see the supporting analysis.

2.10.2 Decision

The EDD SHALL be defined as a federated legal identity resolver and discovery entry point only. Capability registration, endpoint storage, and routing are delegated to ecosystem-specific registries.

The EDD SHALL: - resolve economic actors to ISO 6523-compliant identifiers (EUID for registered companies; national ICD scheme values for actors not covered by EUID) - return references to ecosystem discovery locators at network and process level (BDXL 2.0, WE BUILD profile) - support registration of sole traders and public sector bodies using ISO 6523 ICD catalog entries

The EDD SHALL NOT: - store AS4/SMP-style capability registry data (document type capabilities, AS4 endpoint addresses, transport certificates) — these belong in ecosystem-specific registries - perform routing or protocol negotiation - replace ecosystem capability registries (Peppol SMP, QERDS provider registries, eFTI gateway registries) - replace authoritative legal business registries

The EDD machine API SHALL be deterministic and identifier-based. Human search capabilities (by name or attributes) SHALL NOT be normative for machine routing.

The recommended three-step stack for WE BUILD:

flowchart LR
    A[Sending System] --> B
    B["Step 1 · EDD\nIdentification\nEUID / ISO 6523"] --> C
    C["Step 2 · BDXL 2.0\nDiscovery\nNetwork + Process"] --> D
    D["Step 3 · Ecosystem SMP\nConnection\nEndpoint + Certificate"] --> E
    E[Access Point / QERDS / eFTI]

2.10.3 Consequences

Structuring the EDD as three separated steps makes it easier to: - reuse proven, EU-mandated eDelivery infrastructure (BDXL 2.0, SMP 2.0) rather than specifying a new directory protocol - support federated operation. Each ecosystem manages its own capability registry without a central point of failure - maintain a single coherent identifier model. EUID is ISO 6523-compliant (Reg. (EU) 2021/1042), aligning with Peppol and EN 16931 - keep the EDD lean and future-proof. Ccapability updates require no change to the EDD identity and discovery layers

It makes it more difficult to: - proceed to end-to-end testing without a BDXL 2.0 WE BUILD profile (Service → network, Process → process mapping) - onboard sole traders and public sector bodies, who are not covered by EUID/BRIS. Interim registration paths must be defined before affected use cases can proceed

The main risks introduced by this decision are: the pilot directory diverging from the eventual EDD implementing act standard; the identification gap blocking use case testing; and scope creep into existing Peppol infrastructure if the BDXL/SMP boundary is not maintained. These are addressed by WP4 Trust Registry Infrastructure developing the BDXL 2.0 WE BUILD profile as a first deliverable, defining interim registration paths for sole traders and public sector bodies, and engaging the Commission’s EDD implementing act process proactively with documented design decisions.

2.10.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision. In the decision making process, we have heard the following advice.

  • 2026-02-11, Rune Kjørlaug, OpenPeppol, Belgium: Contributed the original three-step model (identification, discovery, connection) and the BDXL 2.0 proposal, noting EUID coverage gaps for sole traders and public sector bodies. This ADR is the result of that comment.
  • [2026-03-13, Erlend Klakegg Bergheim, OpenPeppol, Belgium]: Corrections on ebCore Party Id (not used in Peppol; Peppol uses its own variant), DIDComm viability, SMP 2.0 profiling approach (Service → network, Process → process), recommendation to limit step 2 to process level only, EN 16931 regulatory basis for ISO 6523 coverage, and caution against routing non-Peppol ecosystems through existing Peppol SML/SMP infrastructure.
  • 2026-03-27, Florin Cora, Bosch, Germany: Raised that the SHALL NOT on endpoints was too broad, as the EDD may need to locate wallet metadata endpoints for OpenID4VC/VP flows. Also raised that centralised discovery intermediaries for peer-to-peer wallet flows create a metadata observation risk. These comments correctly identified a scope gap: this ADR covers infrastructure-mediated document exchange only; OpenID4VC/VP wallet discovery is recorded as an open issue requiring separate specification with privacy-by-design as a first-order requirement. Florin’s broader suggestion that business documents should be transported as wallet attestations to address this privacy concern was not accepted: B2B capability metadata is categorically different from personal credential presentation and does not warrant the same architectural response.

2.11 Separate attestations, documents, and data in EBW

Authors:

  • Rune Kjørlaug, OpenPeppol, Belgium

2.11.1 Context

The EBW proposal COM(2025) 838 final establishes a framework covering electronic attestations of attributes, submissions, and the exchange of documents and notifications (Articles 3 and 5). Recital 27 explicitly introduces a reference attestation (a pointer and cryptographic hash to a sealed document) as a first-class wallet capability, distinct from embedding a full document payload in a credential.

In practice, WE BUILD use cases (notably SC1 eCMR and SC5 Scenario 4) have modelled near complete complex business documents as full-payload wallet attestations. This conflicts with the eFTI Regulation (EU) 2020/1056, which requires freight transport information to remain authoritative on certified platforms, and with the non-repudiation and audit-trail requirements that Peppol and QERDS are designed to provide.

Three options were considered. Full-payload attestation — embedding the complete document as a wallet credential. This was rejected: it bypasses eFTI certification requirements, is incompatible with document mutability and commercial sensitivity, and does not provide non-repudiation. Selective disclosure over document subsets using SD-JWT or mdoc was also rejected: it does not resolve mutability, versioning, or platform certification requirements, and adds disproportionate complexity. The reference attestation with on-demand retrieval model where the wallet holds a minimal attestation (document reference + hash + issuer) per Recital 27, while the full document remains authoritative on the certified platform and is retrieved on demand. This aligns with the EBW proposal, the eFTI Regulation, and established Peppol and (Q)ERDS trust models.

The root cause of the observed conflation is a specification gap: Recital 27 describes the reference attestation pattern but no conformance specification or credential schema yet exists for it, causing use case designers to default to full-payload alternatives.

For detailed use-case analysis (SC1 eCMR, SC5 eInvoicing) and the layered model for roadside inspection scenarios, see the supporting analysis.

2.11.2 Decision

WE BUILD adopts the following rule on the use of attestations in relation to business document exchange:

Attestations SHALL NOT be used as a substitute for business document exchange. Attestations SHALL convey identity attributes, status claims, and authorisation claims. They MAY also serve as reference attestations per EBW Recital 27, carrying a document reference in the form of a cryptographic hash without embedding the document payload. The full payload of complex business documents (e.g. eCMR, EN 16931 invoice) SHALL be exchanged as EBW submissions via (Q)ERDS or equivalent certified channels, and remain authoritative at their source platform. Where a wallet interaction is required at a point of control, the reference attestation pattern SHALL be applied: the wallet presents the reference; the relying party retrieves the document via an authenticated channel. This restriction applies to attestation issuance and presentation flows. It does not limit what data or documents the wallet holder may store or access for their own purposes.

2.11.3 Consequences

Adopting this separation makes it easier to: - comply with the EBW content-type model, the eFTI Regulation, and GDPR data minimisation - handle document versioning and lifecycle correctly — the authoritative source remains current; the wallet holds only a reference - provide non-repudiation and audit trail via (Q)ERDS - reuse existing qualified infrastructure (Peppol, eFTI platforms) rather than reimplementing document exchange inside wallet credential flows

It makes it more difficult to: - finalise use case specifications before the reference attestation format and retrieval flow are defined — this is a blocker and must not be resolved by falling back to full-payload alternatives - integrate with use cases that have already invested in full-payload attestation designs (SC1 eCMR in particular requires rework)

The main risk introduced by this decision is the specification gap itself: in the absence of a reference attestation schema and flow, use case leads face pressure to use full-payload attestations because the tooling and templates for those already exist. This is addressed by treating the reference attestation specification as a priority deliverable for WP4 Architecture, and by WP3 Use Case Sync Leads reviewing all proposed attestation designs against this ADR before finalising rulebooks.

2.11.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision. In the decision making process, we have heard the following advice.

(To be completed during review.)

2.12 Acceptance of Self-Issued / User-Asserted Attributes

Authors:

  • Consortium Architecture Working Group AMS Track 4

  • Boris Lingl, boris.lingl@datev.de

  • Alexander Manecke, a.manecke@telekom.de

  • Ignacio Ripoll, ignacio.ripoll@corpme.es

  • Iris Speiser, iris.speiser@datev.de

  • Marlene Urbschat, marlene.urbschat@datev.de

2.12.1 Context

The consortium needed to determine whether self-issued/user-asserted attributes are acceptable within the ecosystem.

The acceptability and legal fit of self-issued attestations were unclear. While self-issued attestations offer flexibility and ease of issuance, they do not provide the same level of assurance as electronic attestations of attributes (EAA) or qualified electronic attestations of attributes (QEAA) issued by trusted parties.

The core trade-off is between enabling broad adoption and maintaining a consistently high level of trust across jurisdictions.

2.12.2 Decision

The consortium will allow the use of self-issued/user-asserted attributes.

However, self-issued attributes shall not be treated as qualified attestations and shall not imply the same level of legal or regulatory assurance.

Relying parties remain responsible for determining whether self-issued attestations are sufficient for their use case and risk profile.

2.12.3 Consequences

2.12.3.1 What becomes easier?

  • Faster ecosystem adoption.
  • Reduced issuance complexity.
  • Lower barriers to participation.
  • Increased flexibility for use cases where qualified attestations are not required.

2.12.3.2 What becomes more difficult?

  • Trust evaluation becomes the responsibility of relying parties.
  • Acceptance may vary across jurisdictions.
  • Additional policy decisions may be required by service providers.

2.12.3.3 How do we address the risks introduced by this change?

  • Clearly distinguish self-issued and qualified attestations.
  • Define metadata and trust indicators that allow relying parties to assess assurance levels.
  • Allow relying parties to reject self-issued attestations where regulatory requirements demand stronger evidence.

2.12.4 Advice

  • 2026-06-11: Consortium Working Group: Self-issued/user-asserted attributes should be supported to maximize ecosystem adoption.
  • 2026-06-11: Legal and Compliance Representatives: Self-issued attestations must not be confused with qualified attestations.
  • 2026-06-11: Service Providers: Acceptance policies should be based on jurisdictional and risk requirements.

2.14 EBW’s EAA Extension for the EDD

Authors:

  • Toennis Jonas, Puria Dyne, Rune Kjørlaug, Angel, Ssander Dijkhuis, Evmorfili Bbairamidou, Ivan Faltus, Felix Rosenberg-Gruszczynski, Martin Westerkamp, Nklomp@sphereon.com, filippo@dyne.org, lld@netsmart.gr, ANDRIANA PRENTZA, Muhamed Turkanović
  • Track 3 - Workshop (AMS, 9,10th June)

2.14.1 Context

Working on the context defined in adr/build-edd-identification-discovery-connection.md and having as the focus the EBW-EDD connection.

For M2M scenarios, there is a need to be able to identify and address EBWs directly for information exchange. This could be in cases where an EAA gets re-issued, and a relying party can send a request for sharing of the new EAA, instead of initiating direct customer contact. It would also make it possible to address attestation to given wallets, reducing the potential for interception in issuance service. (Might become less relevant with Openid4VCI 1.1)

2.14.2 Decision

Every wallet MUST provide a Credential offer endpoint and a Credential Issuance endpoint to be published in the EDD. * This COULD be the same endpoint, as long as both functionalities are supported. * The endpoint MUST be unique per wallet, and not require an active browser session. * The endpoint COULD be protected behind a secret mechanism. In that case, the secret must be shareable by the Business owner. This secret does not indicate consent to receive/share a credential. Its main purpose is to prevent SPAM attacks against these endpoints from third parties.

2.14.3 Consequences

  • EDD functionality needs to be provided by WP4
  • EBW comformance tests need to be adjusted to include the endpoints for the EDD

2.14.4 Advice

  • Focus should also be made towards classical business documents, i.e., non-EAA (credentials/attributes)
  • Considering differences in protocols based on EAA or non-EAA, these should be covered in the EAA discovery and connection part

2.15 EBW EAA exchange automation

Authors:

  • Toennis Jonas, Puria Dyne, Rune Kjørlaug, Angel, Ssander Dijkhuis, Evmorfili Bbairamidou, Ivan.faltus@bankid.cz, Felix Rosenberg-Gruszczynski, Martin Westerkamp, Nklomp@sphereon.com, filippo@dyne.org, lld@netsmart.gr, Filip Hladky, ANDRIANA PRENTZA, Muhamed Turkanović
  • Track 3 - Workshop (AMS, 9,10th June)

2.15.1 Context

For M2M scenarios, there is a need to be able to automate attestation exchanges. The general discussion indicated that this would ideally be a different protocol than OpenID4vc, but that this would not be feasible within WeBuild timescope. Automation through a automatic approval list or a full policy engine were nominated as the potential solution

2.15.2 Decision

EBWs MUST support a minimum layer of automation for M2M credential exchanges. * A wallet MUST allow a wallet owner to define a combination of recipient and credential types to be shared or received automatically without human approval if requested on the wallet’s credential endpoint. * A wallet COULD ask after a VC flow if the credential and recipient combination should be added to the automatic approval list. * All defined rules in the automatic approval list MUST be visible to the wallet owner, and MUST be under the control of the wallet owner.

2.15.3 Consequences

  • A VP process MUST consult the approval list before answering a VP request or escalating to the user per default OpenID4VCP flow.
  • A VCI process COULD consult the approval list before receiving a credential instead of human approval.
  • European Business Wallet providers MUST implement at least a rudimentary automatic approval list for a given Attesation/revciver or issuer combination

2.15.4 Advice

  • A wallet SHOULD allow rules to be defined in a portable, compatible way, so that e-services who request long lived access (e.g. government services) can define these necessary rules for easy import into the business wallet.

2.16 Support Role-Based and Service-Based Authorization Models

Authors:

  • Consortium Architecture Working Group AMS Track 4

  • Boris Lingl, boris.lingl@datev.de

  • Alexander Manecke, a.manecke@telekom.de

  • Ignacio Ripoll, ignacio.ripoll@corpme.es

  • Iris Speiser, iris.speiser@datev.de

  • Marlene Urbschat, marlene.urbschat@datev.de

2.16.1 Context

There is a structural mismatch between:

  • how businesses grant powers (typically role-based), and
  • how service providers authorize access to their services (typically service-based).

Mandating only one authorization model would exclude important use cases and stakeholders.

The core trade-off is between simplicity (a single model) and flexibility/interoperability (supporting both models).

2.16.2 Decision

The consortium will support both of the following authorization models:

  • Role-Based Authorization
  • Service-Based Authorization

Service providers may choose the model they support based on their risk assessment and authorization requirements.

In addition, BU3 will create and maintain a service register/list to enable the discovery and mapping of service-based authorizations.

2.16.3 Consequences

2.16.3.1 What becomes easier?

  • Better alignment with established business practices.
  • Greater flexibility for service providers.
  • Improved adoption across different sectors.
  • Support for a broader range of authorization scenarios.

2.16.3.2 What becomes more difficult?

  • Mapping between role-based and service-based permissions.
  • Ensuring consistent interpretation of authorization scopes.
  • Discovery and governance of service definitions.

2.16.3.3 How do we address the risks introduced by this change?

  • Create and maintain a consortium-wide service register/list.
  • Define governance rules for service registration and discovery.
  • Allow service providers to perform their own risk assessment regarding acceptance of role-based powers.
  • Continuously refine mappings between roles, faculties, and services.

2.16.4 Advice

  • 2026-06-11: Consortium Working Group: Support both models to maximize interoperability and adoption.
  • 2026-06-11: Service Providers: Acceptance of role-based powers should depend on whether the associated faculties are sufficient and on the provider’s risk assessment.
  • 2026-06-11: BU3: A service register and discovery mechanism are required for operational deployment.

2.17 Support for Sole Trader Representation

Authors:

  • Consortium Architecture Working Group AMS Track 4

  • Boris Lingl, boris.lingl@datev.de

  • Alexander Manecke, a.manecke@telekom.de

  • Ignacio Ripoll, ignacio.ripoll@corpme.es

  • Iris Speiser, iris.speiser@datev.de

  • Marlene Urbschat, marlene.urbschat@datev.de

2.17.1 Context

The current PoA/PoR rulebooks focus primarily on legal persons and do not adequately represent sole traders and similar economic actors.

As a result, certain business structures cannot be represented consistently within the current model.

The core trade-off is between maintaining a legal-person-centric model and expanding the scope to support a broader set of economic actors.

2.17.2 Decision

The consortium will extend the rulebook terminology from “legal person” to the broader concept of an “economic operator.”

The consortium will leverage the EBWOID initiative and use an EUID-like identifier approach to support identity representation for sole traders and similar actors.

Where necessary, existing implementations may continue to process legacy terminology during a transition period, provided that semantic interpretation remains aligned with the new rulebook concept.

2.17.3 Consequences

2.17.3.1 What becomes easier?

  • Inclusion of sole traders within the ecosystem.
  • Broader applicability of PoA/PoR use cases.
  • Improved alignment with real-world business structures.
  • Better consistency across participating jurisdictions.

2.17.3.2 What becomes more difficult?

  • Cross-border identifier interoperability remains challenging.
  • National registration systems may use incompatible identifiers.
  • Additional governance may be required for identifier mapping.

2.17.3.3 How do we address the risks introduced by this change?

  • Reuse existing EBWOID work wherever possible.
  • Define guidance for identifier mapping and interoperability.
  • Continue collaboration with relevant European initiatives addressing economic operator identification.
  • Define a migration approach for legacy terminology to avoid interpretation inconsistencies during rollout.

2.17.4 Advice

  • 2026-06-11: Consortium Working Group: The rulebook should support all relevant economic actors, not only legal persons.
  • 2026-06-11: Identity Domain Experts: Existing EUID-like approaches should be reused where possible.
  • 2026-06-11: Member States: Cross-border identifier harmonization remains an open challenge that requires further work.

2.18 ADR: EAA for verifiable claims (attestations), (Q)ERDS for data transfer (business documents)

Date 2026-06-11
Context WE BUILD WS Amsterdam track 3
Authors: Toennis Jonas, Puria Dyne, Rune Kjørlaug, Angel, Ssander Dijkhuis, Evmorfili Bbairamidou, Ivan faltus@bankid.cz, Felix Rosenberg-Gruszczynski, Martin Westerkamp, Nklomp@sphereon.com, filippo@dyne.org, lld@netsmart.gr, Filip Hladky, ANDRIANA PRENTZA, Muhamed Turkanović

2.18.1 Context

This decision builds upon the earlier decision to Separate attestations, documents, and data in EBW.

The regulatory definitions of attestations are functional rather than structural. eIDAS (as amended by Regulation (EU) 2024/1183) defines an electronic attestation of attributes as an attestation in electronic form that allows attributes to be authenticated, where an attribute is a characteristic, quality, right or permission of a natural or legal person or of an object. Beyond this, an attestation is in practice a structured piece of data that is signed or sealed by its issuer; neither eIDAS nor the proposed EU Business Wallet regulation (COM(2025) 838) constrains what such data may represent. In the EUDI Wallet context this under-specification is workable: the EUDI Wallet ARF assumes the holder is a natural person on a personal device under the User’s sole control, and the wallet is in practice the system of record for the credentials it holds. The ARF (v2.9.0) has explicitly removed legal-person Wallet Units from its scope in view of the development of a separate business wallet, the boundary this ADR operates within.

In the business wallet ecosystem this assumption does not hold. The wallet of an Economic Operator (EO) is connected to a broader suite of business systems — ERP, invoicing, procurement, archiving — that already act as systems of record for business transactions. If “anything signed and structured” can be carried as an attestation, the attestation mechanism becomes a de facto data transfer channel, duplicating and competing with established document exchange infrastructures rather than complementing them.

2.18.2 Decision

Within WE BUILD we adopt the following definitions and assign each concept to a distinct mechanism:

Electronic attestations of attributes (EAA) provide verifiable claims about an entity whose validity is lifecycle-managed at the source. While the claim content itself is integrity-protected and tamper-evident, its validity is mutable: the issuer can suspend or revoke it at any time, and relying parties are expected to check current status, not just signature validity.

Business documents are self-contained, structured or unstructured data artifacts that represent a business fact or transaction at a specific point in time. Once issued by its source, a business document is immutable. Its content is finalized, and any subsequent change is expressed as a new document (e.g., a correction, amendment, or credit note), never as a modification of the original.

From these definitions follows the central rule of this ADR:

Business documents are not to be transferred as attestations. Attestations are conveyed and presented via the EAA mechanisms of the wallet ecosystem; business documents are exchanged via electronic registered delivery services ((Q)ERDS) or other established document exchange infrastructures.

2.18.3 Rationale

The two concepts differ in their fundamental temporal and lifecycle semantics:

Business document Attestation
Asserts What happened (historical fact) What currently holds (status, capability, authorization)
Content Immutable after issuance Integrity-protected, fixed at issuance
Validity Final — corrections via new, linked documents Mutable — managed at source (suspension, revocation, expiry)
Verification Integrity and authenticity of the artifact Integrity plus current status at source
Natural mechanism (Q)ERDS / document exchange networks (Q)EAA

A document asserts a historical fact and is therefore immutable; an attestation asserts an ongoing state and is therefore lifecycle-managed. Conflating the two creates concrete problems:

  1. Revocation semantics break down. An invoice carried as an attestation would inherit revocation semantics that have no business meaning — an issued invoice cannot be “revoked,” only credited or corrected through a new document.
  2. Systems of record are duplicated. Treating documents as wallet-held attestations positions the wallet as a parallel store of transactional data, in conflict with existing ERP and archiving obligations (including statutory bookkeeping requirements).
  3. Established exchange infrastructure is bypassed. Document exchange networks provide delivery evidence, addressing, and validation capabilities that the attestation presentation flow does not replicate. Routing documents through attestation channels discards these capabilities without replacement.
  4. Status-checking load is misdirected. Relying parties would be expected to perform status checks against issuers for artifacts whose validity, by definition, never changes.

Conversely, the combination of the two mechanisms is where the value lies: attestations (e.g., ApprovedSupplier, AuthorizedServiceProvider) establish who the parties are and what they are entitled to do, while the document exchange conveys what was transacted. Attestations may be referenced from or embedded in business documents to bind transaction to entitlement, without changing the transfer mechanism of the document itself.

2.18.4 Consequences

Positive

  • Clear interoperability boundary: the EUBW integrates with, rather than substitutes for, existing document exchange infrastructure.
  • Each artifact type gets verification semantics that match its nature — status checks for attestations, integrity/authenticity verification and delivery evidence for documents.
  • Existing legal and operational frameworks (eInvoicing directives, ViDA, bookkeeping legislation, Peppol agreements) remain applicable to documents without reinterpretation.

Negative / trade-offs

  • Two mechanisms must be operated and governed instead of one; scenarios involving both (e.g., attestation-bound invoicing) require explicit binding patterns.
  • Edge cases exist where classification requires judgment (e.g., a certificate of conformity attached to a delivery). The decisive test is lifecycle semantics: if validity is managed at the source after issuance, it is an attestation; if the content is final at issuance, it is a document.

Open points - Decision tree to be contributed to the Blueprint by the authors - Specification of the binding pattern between attestations and business documents (reference vs. embedding) to be contributed to the Blueprint by the authors.

2.19 Credential offer endpoint registry and lookup

Authors:

  • Lal Chandran, iGrant.io, Sweden
  • Nikolaos Triantafyllou, University of Aegean, Greece

2.19.1 Context

Issuer-initiated credential issuance requires a European Business Wallet (EBW) to expose a credential offer endpoint, that is, a reachable target to which an Issuer can deliver a credential offer. Mandating such an endpoint is necessary for interoperability: without it, an Issuer cannot rely on any given EBW being able to receive a pushed credential offer, and issuer-driven flows such as onboarding, re-issuance and attestation delivery become unreliable.

A naively mandated endpoint, however, makes every EBW a permanently reachable, publicly addressable target. This strips engagement control from the Wallet Owner, creates an unsolicited-inbound surface for credential spam and phishing, and disproportionately affects SMEs and sole traders who lack filtering and security operations.

The Wallet Unit Attestation and lifecycle management decision deferred this concern, noting that the availability of the Wallet Owner for notifications and submission of documents is a separate layer governed by entry in the WE BUILD Digital Directory. This ADR specifies that layer, so that the mandated endpoint delivers interoperability without becoming an open relay.

2.19.2 Decision

The WE BUILD Digital Directory layer SHALL be composed of two distinct components: a Registry as the authoritative source of record, and a Lookup Service as the permissioned resolution interface over it. The write path (registration, governed by the Wallet Provider and Wallet Owner) is kept independent from the read path (resolution, exposed to Issuers).

Registry

  • Registration MUST be performed by the Business Wallet Provider on behalf of the Wallet Unit, and MUST be opt-in by the Wallet Owner.
  • The Wallet Owner MUST control which Issuers, or classes of Issuer, are authorised to resolve and reach its endpoint.
  • A Registry entry binds the endpoint to the Wallet Unit’s identity (EBWOID) and structural trust (WUA).
  • The Registry is the single point at which endpoint records and authorisation policy are created, updated and removed.

Lookup Service

  • A credential offer endpoint MUST NOT be published openly; it MUST be resolved through the Lookup Service rather than discovered, scraped or enumerated directly.
  • Resolution MUST be permissioned. Only authenticated Issuers MAY resolve a Business Wallet endpoint, and the Lookup Service MUST enforce the authorisation policy held in the Registry.
  • The Lookup Service MUST NOT confirm the existence of a registered entity to an unauthenticated or unauthorised querier, to prevent enumeration of SMEs and sole traders.

Resolution of an endpoint MUST NOT by itself entitle an Issuer to deliver. The endpoint MUST enforce a consent or allow-list check at delivery time, so that it rejects credential offers from Issuers the Wallet Owner has not accepted.

2.19.3 Consequences

Authorised Issuers can reliably find and reach Business Wallets for issuer-initiated flows, preserving interoperability. Business Wallets are not open relays: an endpoint is reachable only for Issuers the Wallet Owner has accepted, and invisible to everyone else. Engagement control returns to the Wallet Owner through opt-in registration and per-Issuer authorisation, and the credential spam surface is removed by permissioned resolution and the delivery-time consent gate. SMEs and sole traders receive these protections by default, with no security setup on their end, and enumeration risk is mitigated because the Lookup Service does not disclose entities to unauthorised queriers.

Wallet Providers are expected to implement registration and resolution, to be elaborated further via a conformance specification. Actors can verify conformance through testing against other implementations.

2.19.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision.

2.20 Business Wallet Unit Attestation based on TS3

Authors:

  • Lal Chandran, iGrant.io, Sweden
  • Nikolaos Triantafyllou, University of Aegean, Greece

2.20.1 Context

The EUDI Wallet (CS-04) defines its Wallet Unit Attestation through Technical Specification 3 (TS3), where the Wallet Unit Attestation is composed as WUA = WIA + KA, that is, a Wallet Instance Attestation bound to one or more Key Attestations. TS3 lets Issuers determine a Wallet Unit’s security level, authenticate it, and verify it has not been revoked for the lifetime of an issued attestation.

The Wallet Unit Attestation and lifecycle management decision made a Wallet Unit Attestation mandatory for the European Business Wallet but did not fix its shape. The Business Wallet (CS-05) differs from the EUDI Wallet on several dimensions: it is a server or cloud-hosted service rather than an app on a personal device, its keys live in a Cloud HSM, an organisation-controlled HSM or server-side, and it plays Holder, Issuer and Verifier in one wallet at high, possibly batched or asynchronous, throughput.

A comparison of CS-04 and CS-05 shows that several dimensions can be reused from the EUDI Wallet approach as-is, while a smaller set requires CS-05-specific work. The settled, reused dimensions are roles, form factor, key custody, attestation shape, organisational identity carriage, and roles played. The open dimensions, addressed in separate ADRs, are lifecycle source, discovery, session binding, and throughput.

This ADR records the decision for the attestation shape dimension: how the Business Wallet Unit Attestation is structured.

2.20.2 Decision

For WE BUILD Consortium usecases, the European Business Wallet SHALL adopt the TS3 Wallet Unit Attestation approach as the basis for the Business Wallet Unit Attestation (BWUA).

As a working hypothesis, the BWUA is composed as BWUA = BWIA + SKA, mirroring the TS3 WUA = WIA + KA structure:

  • BWIA (Business Wallet Instance Attestation) attests the Business Wallet Unit and its components against the relevant requirements, in the role of the TS3 WIA.
  • SKA (Server Key Attestation) attests the keys used for credential binding where those keys are held in a Cloud HSM, organisation-controlled HSM or server-side environment, in the role of the TS3 KA adapted to a server form factor and key custody.

The following dimensions are reused from the EUDI Wallet (CS-04) / TS3 approach as-is, adapted only for the Business Wallet form factor where noted:

  • Roles — Business Wallet Provider, Admin(s) and Users.
  • Form factor — server or cloud-hosted service.
  • Key custody — Cloud HSM, organisation-controlled HSM, server-side, or any.
  • Organisational identity — EBWOID carried as a claim, issued by member state business registries or similar.
  • Roles played — Holder, Issuer and Verifier in one wallet.

The lifecycle source, discovery, session binding and throughput dimensions are out of scope for this ADR and are decided separately.

2.20.3 Consequences

Reusing TS3 gives the Business Wallet a known, interoperable attestation model rather than a bespoke one, so Issuers and Relying Parties can reason about Business Wallet security and revocation using the same structure as the EUDI Wallet. The BWIA + SKA decomposition preserves the TS3 separation between attesting the instance and attesting the keys, while accommodating server-side and HSM-based key custody that the EUDI Wallet’s device-bound model does not assume.

Because BWUA = BWIA + SKA is recorded as a working hypothesis, the precise profile, including formats, the SKA’s relationship to HSM key-attestation mechanisms, and conformance criteria, remains to be elaborated via a conformance specification. Where the Business Wallet’s server form factor diverges from TS3 assumptions about a local WSCD, those divergences must be made explicit so that Issuers are not exposed to attestation semantics that do not hold for a cloud-hosted wallet.

2.20.4 Advice

Once merged, this is our consortium’s decision. This does not mean all participants agree it is the best possible decision.

2.21 Pre Flight CS

** Authors:**

2.21.1 Context

The consortium sometimes requires fast and lightweight conformance specifications in order to start testing. For some areas the standardization situation is pretty clear cut and testing can proceed with a minimal “pre-flight” CS that references existing standards.

The expectation is that the result if testing is fed back into the CS process in WP4 so that a better and more informed CS can be produced as the result of the first round of testing.

2.21.2 Decision

The consortium will support the publication of pre-flight CS documents. Such documents are characterized by essentially being references to existing standards and possibly some profile. A pre-flight CS is not meant to be normative and should only be used when the standards situation is clear but there is a lack of testing. The pre-flight CS is meant to resolve a catch-22 where WP4 is waiting on testing to complete a CS but the testing needs a CS to begin.

2.21.3 Consequences

2.21.3.1 What becomes easier?

This decision enables faster progress on emerging standards across the EUDI ecosystem.

2.21.3.2 What becomes more difficult?

Feedback from the testing phase is necessary to complete the work on a proper CS for the ecosystem.

2.21.3.3 How do we address the risks introduced by this change?

A structured report-back process from the testing in other WPs to inform the next version of the CS in question.

2.21.4 Advise