WE BUILD — Architecture & Integration Blueprint (D4.1)

The user initiates signing from the wallet, while the SCA is external. The document is sent to the external SCA for review and consent, after which the signing request is forwarded to a remote SCD that creates the signature and returns the result.

The user initiates signing from the wallet, which also acts as the SCA. The document is presented to the user within the wallet for review and consent. After approval, the wallet forwards the signing request to a remote SCD that produces the signature and returns the result.

The user initiates signing from the wallet, which also acts as the SCA. The document is presented to the user within the wallet for review and consent. After approval, the signature is created locally using a SCD integrated in the user’s device.

The business wallet enrols its owner via the electronic identification of an authorised representative and facilitates enrolment in connected trust services and directory services. The wallet provider is responsible for attesting to its validity to relying parties and enabling authorised representatives to revoke the business wallet and perform other lifecycle changes. In several cases, the wallet provider is also responsible for notifying authorised representatives and government authorities about lifecycle changes.

WE BUILD implementation note: This will be the responsibility of the WP4 Wallet Providers group. At least several providers will be ready to manage their wallet solution and issue wallet units under new and changing business wallet requirements.

The business wallet enables the wallet owner to create, store, use and validate various types of digital documents:

For this purpose, the business wallet implements several applications, including signature creation and secure cryptographic applications.

WE BUILD implementation note: The WP4 Wallet Providers provide, as part of their business wallet solutions, a subset of the functionalities required by the use cases. For the functionalities that require qualified trust services, such as the issuance of qualified certificates or the sealing of documents with qualified electronic seals, the WP4 QTSP group provides these services within WE BUILD. For reference, see the QTSP documentation.

To enable public and private sector information exchange, such as in B2G eGovernment notifications, B2B/B2G eProcurement business documents and other business use cases, a business wallet implements a secure communication channel with other business wallets, with users of digital identity wallets, or with alternative solutions provided through a gateway. This channel enables cross-border delivery and receipt of submissions and notifications with legal effect, and provides a trusted channel with public authorities and other regulated parties across the EU. The channel is implemented using a qualified electronic registered delivery service (QERDS). The digital address for the channel is registered in a standard digital directory.

WE BUILD implementation note: the WP4 QTSP group will explore delivering an interoperable pre-production QERDS, along with CIR (EU) 2025/1944 requirements, as a service to the WP4 Wallet Providers group, working with the WP4 Architecture group on cross-cutting concerns, such as interoperability specifications. This enables wallet providers to provide a business wallet to the use cases with a digital address and access to the designated QERDS. For reference, see the QERDS documentation.

To enable wallet owners, authorised representatives and other authorised users to access the business wallet while preventing unauthorised access, each business wallet implements role-based access control for the assets it protects, including digital documents and the secure communication channel. To identify, authenticate, and authorise wallet users, the access control mechanism relies on electronic identification means, such as digital identity wallets, and, potentially, on trust services for the electronic attestation of attributes.

WE BUILD implementation note: The WP4 Architecture group, in collaboration with the WP4 Wallet Providers group, will explore the access-control mechanism for business-wallet solutions. This may rely on the EUDI wallets within WE BUILD or on other electronic identification means.

Business wallets keep logs and provide dashboard user interfaces to enable control over transactions, including operations on the wallet lifecycle and on digital documents and messages sent and received over the secure communication channel. In addition, these logs enable dispute resolution regarding potentially unauthorised transactions, failures to meet reporting obligations, or administrative or procedural activities.

The most common architecture combines:

This reflects the broader EUDI ecosystem, where personal identity use cases are mobile-centric while organisational use cases often require backend infrastructure.

Several providers indicate the use of remote HSM infrastructure for enterprise wallet deployments. This approach supports large-scale operations and key recovery but requires continuous network connectivity.

The questionnaire responses mainly describe the application layer (mobile app, server, or web wallet), rather than the underlying cryptographic architecture.

Only a small number of providers explicitly describe the type of secure cryptographic device used (for example secure hardware on the device or remote HSM infrastructure).

Architectures supporting legal person wallets are still evolving.
Many providers indicate that their legal person wallet solutions will be further developed during the WE BUILD project in alignment with emerging European Business Wallet proposals.

As a result, the architectures described in the stocktaking responses should be understood as initial implementation approaches rather than final designs.

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.

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.

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.

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.

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.

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.

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.

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

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:

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.

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.

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.

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.

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:

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.

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.

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.

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:

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

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

The European Business Wallet SHALL introduce:

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.

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.

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

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.

WE BUILD will use the EBWOID rulebook as the basis for identification of business wallet owners and deprecate LPID within WE BUILD:

Positive:

Negative/Risks:

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:

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:

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

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

Testing and piloting with a designated QERDS makes it easier:

Open issues:

The WP4 Architecture group can provide the necessary design competence.

The following risks need to be addressed:

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.

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.

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

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 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:

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.

WE BUILD separates the specification of:

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:

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.

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.

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.

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.

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:

The EDD SHALL NOT:

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:

Structuring the EDD as three separated steps makes it easier to:

It makes it more difficult to:

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.

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.

Authors:

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.

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.

Adopting this separation makes it easier to:

It makes it more difficult to:

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.

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.)

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.

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.

Individuals may hold multiple powers, mandates, or authorizations on behalf of an organization.

The consortium needed to determine whether mandate-related attestations should contain multiple faculties or be limited to a single authorization scope.

The core trade-off is between expressiveness and implementation simplicity.

Mandate-related attestations shall be atomic.

Each attestation shall contain exactly one faculty or one service authorization.

Multiple powers shall be represented by multiple attestations rather than by composite authorization structures.

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)

Every wallet MUST provide a Credential offer endpoint and a Credential Issuance endpoint to be published in the EDD.

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

EBWs MUST support a minimum layer of automation for M2M credential exchanges.

There is a structural mismatch between:

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).

The consortium will support both of the following authorization models:

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.

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.

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.

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.

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:

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

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:

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.

Positive

Negative / trade-offs

Open points

Authors:

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.

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

Lookup Service

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.

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.

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

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.

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:

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:

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

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.

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

For scenarios requiring a human actor to present document-related information at a physical checkpoint (port gate, roadside inspection):

Layer 1 — Minimal reference attestation (wallet-held, offline-capable)

Carried in the wallet in mDL or equivalent format. Contains:

Does not embed document payload. Designed for proximity presentation (NFC, QR) and offline verification of the hash and reference.

Layer 2 — Authenticated document retrieval (on demand, online)

Triggered by the relying party (inspector, port authority) using the reference from Layer 1. The full eCMR is retrieved from the certified eFTI platform via (Q)ERDS or the eFTI unique-link mechanism, with non-repudiation and audit trail. Network connectivity is required for this step but may be deferred from the initial presentation interaction.

This two-layer model satisfies:

Reference attestation format and flow specification

The EBW proposal describes the Recital 27 pattern in general terms, but no implementing act or WE BUILD conformance specification yet defines the concrete format: what attributes are required, how the eFTI unique link or Peppol document reference is encoded, how the hash is computed and bound to the attestation. WP4 Architecture and WP4 QTSP should develop this specification as a priority — it is a prerequisite for SC1.3 and SC5 Scenario 4.

Offline-capable reference attestation for roadside scenarios

The Layer 1 reference attestation must function without network connectivity at the point of presentation (e.g. driver presenting to roadside inspector). The hash and document reference must be verifiable offline. The threshold between offline-verifiable reference and online document retrieval needs to be specified for SC1.3bis, including what the inspector’s workflow is when connectivity is unavailable.

SC5 Scenario 4 — wallet-triggered QERDS delivery flow

Wallet-to-wallet direct invoice exchange is a legitimate EBW use case, but the invoice must transit via QERDS as a document, with the wallet acting as the QERDS endpoint. The UX flow for how a supplier triggers QERDS delivery from the wallet — and how the buyer’s wallet receives notification and initiates retrieval — is not yet specified. This is also relevant to the PA4 dependency (business payments follow invoice delivery).

Specification vacuum drives full-payload defaults

The reference attestation pattern is described in EBW Recital 27 but has no associated flow specification, credential schema, or conformance test. In the absence of guidance, use case leads will default to full-payload attestations because the tooling and templates already exist. WP4 Architecture must publish a reference flow and minimal schema before use cases enter specification finalisation. WP3 Use Case Sync Leads should treat absence of a reference attestation specification as a blocker, not a reason to use full-payload alternatives.

Conflation of "wallet-native" with "attestation-native"

Wallet providers and implementers may assume that because something is exchanged via the wallet, it must be modelled as an attestation. EBW Recital 24 ("secure digital platform for storing and exchanging business documents") explicitly contradicts this. WP4 Architecture members engaging with SC1 and SC5 should use the EBW proposal’s own content-type model to explain the distinction directly, not only reference this ADR.

eFTI platform readiness

SC1.3 depends on certified eFTI platforms being operational and accessible for authenticated retrieval. The eFTI Regulation applies in full from 9 July 2027, but platform certification is still in progress. For the WE BUILD pilot phase, use cases may need to operate against pre-production eFTI environments or mock platforms. This must be captured as a dependency in the SC1 specification phase, not resolved by falling back to full-payload attestations.

Peppol gateway for SC5 Scenarios 4 and 5

QERDS-based delivery of Peppol-format invoices requires a gateway between the wallet’s QERDS channel and the Peppol four-corner infrastructure. This gateway is not yet specified in WE BUILD. SC5 and WP4 QTSP should jointly define gateway requirements as part of Scenario 5 specification.

| Action | Owner | |--|--| | Define minimal reference attestation schema and retrieval flow (Recital 27) | WP4 Architecture + WP4 QTSP | | Review SC1 eCMR attestation specification against this ADR; identify required changes | WP3 SC1 Use Case Sync Lead | | Review SC5 Scenario 4 against this ADR; confirm QERDS delivery model | WP3 SC5 Use Case Sync Lead | | Ensure QERDS gateway and conformance specs include eFTI and Peppol retrieval flows | WP4 QTSP | | Define eFTI pre-production environment dependencies for SC1 pilot | WP3 SC1 Use Case Sync Lead + WP4 | | Define SC5 Scenario 4 wallet UX flow for QERDS-triggered invoice delivery | WP3 SC5 + WP4 Architecture |

Commission Implementing Regulation (EU) 2021/1042 (the BRIS implementing regulation) specifies in its Annex that "the structure of the EUID shall be compliant with ISO 6523". EUID is therefore not a parallel identifier layer alongside ISO 6523 — it is an ISO 6523-compliant identifier within that framework. EN 16931, the European standard for electronic invoicing, requires that all organisation identifiers used for invoicing be registered in the ISO 6523 ICD list. Together, these create a unified regulatory basis for ISO 6523 as the cross-network identifier encoding layer across BRIS, Peppol, and the EDD.

The EUID is, however, limited to limited liability companies and commercial partnerships under EU company law (Directive (EU) 2017/1132). The EBW proposal’s own explanatory memorandum acknowledges that sole traders, self-employed persons, and public institutions are not covered by EUID or BRIS. These are frequent parties in SC1 transport scenarios (self-employed drivers, small carriers) and SC5 SME invoicing. Registration paths for these actor types are an open issue (see below).

Step 2 — BDXL 2.0 WE BUILD profile. BDXL 2.0 uses DNS-based U-NAPTR records to resolve a participant identifier to the URL of a capability metadata publisher. The WE BUILD profile maps:

Document type granularity is intentionally excluded from Step 2. Process-level registration is sufficient to route a sender to the correct ecosystem capability registry; document type detail adds governance overhead without delivering interoperability value, and belongs in the ecosystem SMP (Step 3).

Step 3 — ecosystem SMP. Capability detail (endpoint address, protocol version, certificate references) is registered and maintained by each ecosystem’s own SMP. For Peppol-connected participants this is the Peppol Discovery building block (SMP 2.0). For QERDS this is the QERDS provider registry. This delegation means the EDD does not need to know which document types a participant supports, and capability updates require no change to the EDD.

A. Deterministic routing (machine-to-machine)

B. Human search (non-normative — not for machine routing)

BDXL 2.0 WE BUILD profile

The mapping of BDXL 2.0 Service to ecosystem and Process to process is not yet specified. This is a prerequisite for the discovery locator layer to function and for any end-to-end testing involving cross-network routing. WP4 Architecture and WP4 Trust Registry Infrastructure should develop the profile as a first deliverable.

Sole trader and self-employed identifier scheme

Sole traders accessing QERDS via their EUDIW will have a wallet-derived identifier that may not map to an existing ICD. WP4 Trust Registry Infrastructure must define the registration path for this category before use cases involving sole trader counterparties can proceed to full end-to-end testing. Norway’s enkeltpersonforetak (ENK) scheme is an example of a national identifier type not currently in BRIS.

Public sector body registration

Public sector bodies must accept EBW submissions but are not covered by EUID/BRIS. Their identifier schemes vary by Member State. The WE BUILD Digital Directory must define how they are registered and discoverable, at minimum for government-facing scenarios in SC1.3bis, SC5 Scenario 3, and PA4.

Multi-network process resolution

When a participant is reachable via both Peppol and QERDS for the same process, the BDXL response may return multiple discovery references. Selection logic between network options when multiple matches are returned is not yet specified. A preference-ordering mechanism in the BDXL profile may be needed, particularly for SC5 Scenario 5.

Long-term network segmentation

An alternative architectural direction worth further investigation is whether QERDS and eFTI should eventually be modelled as segments within the Peppol network rather than as separate networks at the discovery layer. This would unify the discovery locator layer under a single Peppol SML, reducing the proliferation of separate ecosystem registries, but would require governance changes within OpenPeppol. This ADR does not foreclose this direction but defers it pending further discussion with OpenPeppol governance.

EDD implementing act timeline

No draft implementing act for the EDD API is yet available. The WE BUILD Digital Directory operates as a pilot ahead of the formal specification. Design decisions should be documented explicitly to support the Commission’s implementing act process.

OpenID4VC/VP wallet endpoint discovery

This ADR covers infrastructure-mediated document exchange (QERDS, AS4/Peppol, eFTI). It does not specify how wallet metadata endpoints are registered and located for direct wallet-to-wallet flows using OpenID4VCI (credential issuance) or OpenID4VP (credential presentation). These flows have different discovery requirements: a wallet needs to locate a counterparty’s /.well-known/openid-credential-issuer or equivalent metadata endpoint, which is not naturally modelled by BDXL 2.0 / SMP 2.0. Whether the EDD should store or point to such endpoints, or whether direct wallet-to-wallet discovery should bypass the EDD entirely, needs to be specified separately. Privacy-by-design must be a first-order requirement for this specification: centralised discovery intermediaries for OpenID4VP flows can observe which wallets communicate, what credentials are requested, and over time reconstruct relationship graphs — a concern that is more acute for natural persons than for legal entities, but which applies to both (see risk below). This is a prerequisite for any WE BUILD use case relying on direct wallet-native flows rather than QERDS or Peppol delivery.

Pilot directory diverges from eventual EDD standard

If the Commission’s EDD implementing act specifies a different protocol than BDXL 2.0 / SMP 2.0, WE BUILD implementations will require migration. WP4 Trust Registry Infrastructure should engage proactively with the Commission’s specification process and document design decisions so that divergences are traceable.

Identification gap blocks use case testing

If sole traders and public sector bodies cannot be registered in the WE BUILD Digital Directory, use cases involving these actor types cannot proceed to full end-to-end testing. Interim registration paths — including national ICD scheme mappings — should be defined in the specification phase.

Scope expansion risk for existing Peppol infrastructure

Routing non-Peppol ecosystems (QERDS, eFTI) through the existing Peppol SML/SMP would expand the operational scope and cost of Peppol infrastructure without a corresponding governance mandate. The recommended architecture avoids this by placing ecosystem-specific capability registration in each ecosystem’s own SMP. This boundary must be maintained explicitly in the WE BUILD profile.

Privacy proportionality in discovery — B2B vs natural person flows

The privacy concern raised in connection with centralised discovery intermediaries for OpenID4VP is technically sound in general but needs proportionality analysis when applied to B2B contexts. For natural persons presenting credentials (health data, identity documents, licences), centralised intermediaries observing who presents what to whom is a serious privacy risk that the SSI community has extensively documented. For legal entities engaged in commercial exchange, the metadata exposed by capability registration — "this company can receive invoices via this network" — is commercial capability information that the entity has already chosen to register. GDPR and the broader EU proportionality principle both apply: the appropriate safeguard depends on the sensitivity of the actors and data involved. WE BUILD should distinguish these contexts explicitly in its privacy analysis rather than applying a uniform maximum-privacy posture. That said, for use cases where natural persons are participants (e.g. sole traders presenting mDL credentials at a checkpoint), the more stringent OpenID4VP privacy-by-design requirements apply, and discovery should be designed accordingly.

DNS dependency for BDXL

BDXL 2.0 uses DNS-based U-NAPTR records. The abstraction layer between the wallet and the QERDS (per the QERDS ADR) should shield wallet users from DNS-level operations; only QERDS providers and SMP operators interact with the DNS layer directly.

| Action | Owner | |--|--| | Develop BDXL 2.0 WE BUILD profile (Service → network, Process → process) | WP4 Architecture + WP4 Trust Registry Infrastructure | | Define registration procedure for sole traders and public sector bodies | WP4 Trust Registry Infrastructure | | Register QERDS provider capabilities in SMP 2.0 | WP4 QTSP | | Engage Commission EDD implementing act process; document pilot design decisions | WP4 Architecture | | Define multi-network selection logic when participant reachable via multiple ecosystems | WP4 Architecture | | Specify OpenID4VC/VP wallet endpoint discovery model and privacy-by-design requirements | WP4 Architecture (with input from WP4 QTSP and use case leads for wallet-native flows) |

Describe:

Example:

<ROLE OR COMPONENT> MUST:

<ROLE OR COMPONENT> SHOULD:

<ROLE OR COMPONENT> MUST NOT:

Direction: <SENDER> → <RECEIVER>
Method: <HTTP METHOD>

Request

Response

Example (illustrative only):

Actors: Holder, WU, Issuer (AS and Credential Issuer).

Actors: Holder, WU, Issuer.

Deferred issuance applies to both wallet-initiated and issuer-initiated flows.

When the Credential Issuer cannot immediately produce one or more credentials:

Both WU and Issuer MUST:

Issuers MUST:

WUs MUST:

Issuers MUST:

WUs MUST:

WUs MUST:

Issuers MUST:

Issuers SHOULD:

Issuers MUST:

Wallets MUST:

Issuers MUST:

Issuers SHOULD:

Wallets MUST:

Wallets SHOULD:

Issuers MUST publish metadata that includes:

Wallets MUST:

Issuers MAY:

Example (illustrative)

The concrete parameters and encoding follow HAIP and OpenID4VCI guidance on Credential Offers.

The Credential Offer object MUST contain at least:

The exact JSON structure MUST comply with OpenID4VCI Credential Offer definitions.

Request (logical fields)

Response

All PAR requests MUST be client-authenticated according to Section 7.4.

Request (logical fields)

Response

Response

Direction: WU → Issuer
Method: POST Request (logical fields)

Response

A Deferred Credential Response MAY either provide the issued credentials or indicate that issuance is still pending.

If credential issuance is complete:

If credential issuance is still pending

Error Response If the Deferred Credential Request is invalid, the Issuer returns an error response.

Issuers MUST publish:

The latter MUST include:

WU uses these documents for dynamic configuration.

Wallets MUST:

Wallets MUST NOT:

Verifier obligations are listed below in two groups: per-transaction protocol behaviours, and deployment-time obligations. All items are normative MUSTs. The wallet’s reciprocal duty for the same protocol step is referenced in parentheses.

Verifiers MUST ensure, on every transaction, that:

Verifiers MUST, at deployment:

Verifiers MUST NOT:

Direction: Verifier → Wallet
Transport: openid4vp:// scheme
Usage: Same-device or cross-device scanning

Example:

Wallet MUST retrieve or validate the Presentation Request Object.

The Presentation Request Object MUST include:

Wallet Units reject incomplete or invalid request objects.

Direction: Wallet → Verifier
Method: POST
Authentication: MAY use sender-constrained tokens

Request Body Example

Success Response Example

Error Example

Verifiers MUST publish metadata containing:

Wallet Units retrieves this metadata where available.

This specification distinguishes two certificate lifecycles, applicable independently of the signing model (Wallet-Centric §4.1, QTSP-Centric §4.2):

The applicable lifecycle MUST be signalled by the certificateLifecycle member in the qesRequest (Wallet-Centric) or qesApprovalRequest (QTSP-Centric). Permissible values for a given QES profile are governed by the rulebook bound to signatureQualifier. If the member is absent, long_term MUST be assumed.

Additions on top of CS-02:

High-level steps:

The above flow is illustrated below:

Additions on top of CS-02:

High-level steps:

The flow is illustrated below:

The subsections below apply to both the same-device and cross-device variants of the Wallet-Centric Signing Flow. The cross-device variant follows CS-02 [5] Section 6.2 (rather than Section 6.1) at each corresponding step. Where the two variants differ, the difference is noted inline.

The subsections below apply to both the same-device and cross-device variants of the QTSP-Centric Signing Flow. The cross-device variant follows CS-02 [5] Section 6.2 (rather than Section 6.1) at each corresponding step. Where the two variants differ, the difference is noted inline.

In addition to all requirements in CS-02 [5] Section 7.1, Wallet Units MUST support at least one of the following models:

Wallet Units MAY support both models. A Wallet Unit that supports a given model MUST comply with all requirements specified for that model.

Wallet Units MUST support certificateLifecycle = "long_term" for any signing model they conform to. Support for certificateLifecycle = "short_lived" is OPTIONAL; Wallet Units that claim short-lived support MUST additionally comply with Section 7.1.3.

These requirements apply to Relying Parties operating in the Wallet-Centric Model. In the QTSP-Centric Model, the Relying Party’s obligations are limited to the Relying Party ↔ QTSP interface, which is out of scope of this specification (see NOTE_CSRS_01).

In addition to all requirements in CS-02 [5] Section 7.2, Relying Parties MUST:

Relying Parties MUST NOT: