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

The future EUDI ecosystem is defined through the Architecture Reference Framework (ARF). Because the ARF is still evolving, it does not yet cover every implementation detail. In the WE BUILD pilot environment, the full certification and qualification schemes used in production cannot always be applied.

To address these gaps, WE BUILD defines project-specific implementation rules through:

In the final ecosystem, wallets and services must undergo formal certification by national supervisory bodies.

The European Commission, together with the European Digital Identity Cooperation Group, has published:

Furthermore, there are several standardisation organisations that contribute with standards for the EUDIW ecosystem.

In addition to the aforementioned standardisation organisations, the European Cybersecurity Agency (ENISA) is developing the EUDI Wallet Certification Scheme, which will be published as an implementing regulation under the Cybersecurity Act. The purpose of the EUDI Wallet Certification Scheme is to harmonise the national certifications of the EU Member States' EUDI Wallets.

This issuance flow is initiated by the user:

This issuance flow is initiated by the issuer:

In the wallet-centric model, the EUDI Wallet is the central component of the electronic signature process. Three distinct signing processes are considered, depending on where the Signature Creation Application (SCA) runs and where the Signature Creation Device (SCD) is hosted.

In the QTSP-centric model, the trust service provider operates the signing or sealing process. The cryptographic key material used for signature or seal creation is generated, stored, and used within infrastructure controlled by or on behalf of the QTSP, typically in secure hardware environments. From the perspective of the user, signing and sealing are therefore remote operations. External components interact with the trust service through defined interfaces, while the cryptographic operation itself is performed within the QTSP-controlled environment.

Within this architecture, the EUDI Wallet may act as a client-side orchestration component. It can authenticate the user, capture user intent, and trigger a signing operation. However, it does not operate the signature creation environment, does not manage signing credentials, and does not assume the responsibilities of a trust service provider.

In this model, the QTSP remains responsible for identity binding, credential issuance, and compliance with applicable ETSI standards. Signature or seal creation data remains under controlled conditions consistent with the required assurance level, and activation mechanisms enforce the conditions required for advanced or qualified signatures, including sole control where applicable.

The pilot implementation aims to remain technically aligned with qualified signing requirements. Pilot trust validation is described below and relies on consortium trusted lists.

For remote signing and sealing flows, WE BUILD uses the Cloud Signature Consortium (CSC) interoperability framework. CSC APIs expose standardised interfaces that allow wallets and client applications to interact with QTSP-operated signing services. The detailed WE BUILD CSC interoperability profile will be defined in a WBCS. That specification will describe the concrete integration details, including authorisation mechanisms, endpoints, supported formats and algorithms, and interoperability constraints used in the ITB. Until such a profile is published, CSC API v2.2.0.0 serves as the base reference specification for CSC-based interactions.

During the pilot phase, trust validation relies on consortium reference trust mechanisms. Wallet components or external SCAs validate participating QTSPs and trust anchors using WE BUILD trusted lists. The reference trusted list may include participating QTSP entries and their registered issuing certificate authorities for pilot purposes.

When a signing request is processed, the SCA validates the signer’s certificate chain against issuing certificate authorities listed in the WE BUILD trusted list and checks the QTSP status within the pilot trust framework. Revocation status is validated using OCSP responders or CRL distribution points operated by participating QTSPs. Where registration status checks are required, registrar processes are simulated through mock registrar services and endpoints.

WE BUILD supports signing scenarios where an individual signs on behalf of an organisation. This model reuses the wallet-centric and QTSP-operated signing approaches described above. The wallet provides the user interface for document review and approval, while the QTSP performs the signature or seal creation within its controlled environment.

In these scenarios, the transaction must bind both the natural person and the organisation represented. The natural person identity is represented by the PID, while the organisation context is represented through the EBWOID, which acts as the cross-border minimum organisation identifier.

At signing time, identifiers or references to both the PID and the EBWOID are included in the transaction data presented to the user and subsequently authorised or signed. This ensures that the resulting signature or seal can be unambiguously linked to both the individual and the organisation.

The exact representation of these bindings is use-case specific and will be defined in rulebooks and WBCS (see Chapter 5 for the semantic and schema model).

As a baseline, a classic B2G/B2B situation is used: an authority notifies an economic operator, the economic operator responds, and the relying party requires evidence. With QERDS, both sides use their QERDS providers to register sending and receiving, so that delivery is not just transport, but is a process that produces trustworthy evidence.

In this model, WE BUILD takes the next step: wallets become the user-facing endpoints (“wallet-centric delivery”). The sender wallet and recipient wallet remain the places where users read, approve, and manage messages, or where they configure connections to backend systems to perform these actions. QERDS providers form the delivery layer underneath, handling routing, inter-provider exchange, and evidence creation, while wallets provide identity/authentication and user control.

WE BUILD follows the QERDS architecture decomposition and the four-corner delivery pattern:

The WE BUILD terminology is published online and serves as a reference model for the terminology of the European Digital Identity Framework. The terminology is defined using the Simple Knowledge Organisation System (SKOS).

The European Wallet vocabulary is maintained in GitHub. It is defined using the Web Ontology Language (OWL), which specifies classes, properties and individuals of the vocabulary.

To support semantic interoperability, credential subjects used within the EBW framework are modelled in the vocabulary. These vocabulary terms are then mapped to the corresponding elements used in attestations.

If the credential format supports machine-readable semantic contexts, the mapping between credential data and the vocabulary can be embedded in the credential itself. Otherwise, the meaning of the data fields must be defined in attestation rulebooks, and the rulebook owner is responsible for mapping those fields to the vocabulary definitions.

Reuse of existing vocabularies The EBW vocabulary defines the domain-specific vocabulary used in the WE BUILD attestations. Existing vocabularies are reused where possible, including those for credential metadata, proof mechanisms, security, decentralised identifiers, and credential status. Domain vocabularies from other sectors may also be reused (for example, digital product passports, supply chains, education, railway and data spaces).

In the Appendix - Trust Ecosystem there is a diagram that summarises the roles of Member State and European Commission, the split between registration and notification, and how Trusted Lists and the LoTL are produced and consumed. A simplified version used in WE BUILD is shown below.

WE BUILD participants select the registry in which they register.

Revocation of PID, EBWOID and attestations is implemented by issuers. In WE BUILD, attestation revocation follows the agreed mechanism defined in the ADR on Attestation Revocation, based on the IETF Token Status List and aligned with OpenID4VC HAIP.

Short-lived attestations (valid for 24 hours or less) are not subject to revocation.

Revocation or withdrawal of providers and services is reflected in the trust infrastructure through status changes in Trusted Lists and, where applicable, invalidation of certificates.

To maintain a trusted ecosystem, PID and EBWOID providers agree to:

According to the rules, a provider must revoke without delay if:

The Task 2 trust-infrastructure schema defines the following responsibilities matrix for registration and Trusted List compilation:

This blueprint section mirrors the Task 2 responsibilities matrix so that architectural roles are consistent across WP4.

Authentication in the WE BUILD architecture closely follows the standards and flows of the underlying protocols (OpenID for Verifiable Credentials, ISO 18013-5, and other application-specific communication protocols).

For organizational entities that register with the Registrar (PID Providers, Attestation Providers, Relying Parties), authentication is primarily established using access certificates issued by the Access Certificate Authority, validated against up-to-date Trusted Lists or Lists of Trusted Entities (ARF and ETSI TS 119 602 / 119 612 / 119 615). Wallet Providers are notified by Member States to the European Commission (they do not register with the Registrar); their authenticity is established via the Wallet Provider Trusted List and related attestations (e.g. Wallet Unit Attestation). Mutual trust is strictly required in application-specific protocol flow specifications, and consolidated through OpenID HAIP and ARF HLRs, with certificate-bound tokens and protocol-level message signatures along with endpoint authentication and message integrity.

According to the ARF, the Relying Party cannot request the Wallet Unit Attestation (WUA) during the presentation flow. Presentation requests address PID and attestations only (ARF Topic 1, OIA_01); the WUA is presented to the PID Provider or Attestation Provider during issuance of a PID or device-bound attestation, not to the Relying Party (ARF Topic 9, WUA_03, WUA_05, WUA_05a). The ARF explicitly states that there is no separate mechanism for the Relying Party to verify the revocation status of a Wallet Unit directly with the Wallet Provider (ARF Section 6.6.3.12). Trust in the Wallet Unit is therefore mediated by a trusted third party: the PID Provider or Attestation Provider that belongs to a Trust Anchor (Trusted List) and that received the WUA at issuance. That trust is indirect from the Relying Party’s perspective. The PID Provider or EAA Provider periodically checks the revocation status of the Wallet Unit to which it has issued credentials (using the revocation information in the WUA received at issuance; ARF Topic 9 WUA_02, ARF Section 6.6.2.4). If the Wallet Unit is revoked, the PID Provider or Attestation Provider SHALL revoke the credentials it issued to that Wallet Unit (Article 5, 4.(b), European Digital Identity Regulation; ARF Section 6.6.2.4). By verifying the revocation status of the PID or attestation, the Relying Party implicitly relies on the issuer’s verification of the Wallet Unit.

For attestation holders (individual end-users and the corresponding wallets), authentication requirements leverage possession-based proofs and, where applicable, identity schemes notified to the European Commission that attest Level of Assurance High according to the eIDAS Framework. Local user authentication (e.g., via PIN, password, device biometrics) must fulfill the minimum Level of Assurance required by the credential or attestation type and is enforced by policy prior to any issuance or presentation flow.

Wallet Units are expected to combine protocol-specific authentication mechanisms (as per OpenID4VC and ISO 18013-5) with validation of trust anchors and up-to-date Trusted Lists, covering both participant and credential authenticity.

Authorization determines what actions a subject is permitted to perform after authentication. In line with the Task 2 trust framework and the EUDI Wallet ARF, WE BUILD assumes that the default is “allow all” at the ecosystem level, and that policies (expressed via Trusted List extensions, registration/entitlement data, and optional registration certificates) can tighten this to an effective “deny all except explicitly allowed” model for specific contexts and participants. When such policies apply, only the actions and attribute uses listed in the applicable allow‑lists are permitted; all others are denied. Trust marks (for Credential Issuers, Wallet Solutions, and Relying Parties), together with Trusted List extensions and registration certificates, carry authorization semantics (e.g. authorised credential types, attribute groups, purposes, scope restrictions) and are used in policy evaluation and collision prevention as specified in the Task 2 trust framework and the trust‑infrastructure schema.

According to the EUDI Wallet ARF v2.8, when present and applicable, policies and default authorisations may be overridden by user will: the Wallet Unit SHALL ensure the User approved the presentation of any attribute(s) prior to presenting those attributes and SHALL always allow the User to refuse presenting an attribute requested by the Relying Party or Verifier Wallet Unit (ARF Topic 6, RPA_07); if Relying Party authentication fails, the Wallet Unit SHALL either not present the requested attributes or give the User the choice to present or not (RPA_06a).

For reference on relying party access certificates and relying party registration certificates, see the RPAC/RPRC documentation.

Key lifecycle for trust anchors and for services listed in Trusted Lists is reflected in list content and status (e.g. service status, status determination approach, and history where required by the profile). Updates and revocation of listed services follow the applicable ETSI trusted list profiles (TS 119 612 / TS 119 602) and are consumed per ETSI TS 119 615. Certificate policies and Certificate Transparency (SCT) where applicable are specified in the referenced ETSI standards.

Wallet Units and Relying Parties establish trust in a Credential Issuer (PID Provider or Attestation Provider) and in the credentials they issue by combining Trusted List entries (trust anchors and, where applicable, authorised attestation types) with registration data (Registry or registration certificate). The catalogue of attestation schemes defines what credential types exist; Trusted Lists and registration define who is allowed to issue which types. The flow below is aligned with the WP4 Trust Group credential catalogue and issuer constraints: the verifier accepts a credential only if the issuer is present in the applicable Trusted List and the credential’s attestation type is among the issuer’s authorised types (ISSU_24, ISSU_24a, ISSU_34, ISSU_34a for Wallet Units; OIA_12, OIA_13, OIA_14, OIA_15 for Relying Parties).

Trust in a Wallet Solution (Wallet Provider and Wallet Unit) is established by Credential Issuers (PID Providers and Attestation Providers) before issuing a PID or attestation. The flow is mandated by the ARF (Topic 9 Wallet Unit Attestation, Topic 31 notification and Trusted Lists), uses OpenID4VCI 1.0 for the issuance protocol and issuer metadata (ISSU_22, ISSU_22a, ISSU_22b), and is reinforced by OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0 for authenticity, holder authentication, and certificate-bound tokens. The Wallet Unit presents a Wallet Unit Attestation (WUA) to the Issuer during the issuance request; the Issuer verifies the Wallet Provider against the Wallet Provider Trusted List and validates the WUA (ARF ISSU_19, ISSU_21 for PID; ISSU_28, ISSU_30 for Attestation Providers; WUA_02, WUA_03, WUA_05, WUA_05a). The Wallet Provider Trusted List is compiled by the European Commission from Member State notifications (WPNot_01--WPNot_05).

A Business Wallet is a product and service that enables an organisation to identify itself, manage authorisations, exchange verified attributes and documents, and receive legally relevant notifications in support of administrative and regulatory procedures. Unlike European Digital Identity Wallets, an European Business Wallet does not need to be an eID means under an eID scheme, although it may reuse similar components.

WE BUILD implementation note: The topic of online business identity, potentially outside of eID schemes, needs to be further discussed within the WP4 Architecture group. It may also have consequences for the WP4 PID/LPID Providers group.

A technical decomposition (front end, back end, and cryptographic components) is out of scope for this document.

Each Business Wallet has a single wallet owner, which is the entity that the wallet represents through its interactions. Note that this is distinct from, for example, the company owner or the wallet provider.

The wallet owner is defined by European Business Wallet Owner Identification Data (EBW-OID), which includes an official name and an EU-unique identifier. These owner identification data are issued into the business wallet as an electronic attestation of attributes.

A Business Wallet can have multiple wallet users, meaning natural or legal persons that operate the wallet through a user interface or an application programming interface under roles and mandates set by the wallet owner. These wallet users may apply software applications to access these interfaces. Some users may be authorised representatives, while others may be employees or service providers operating within delegated permissions.

A business wallet enables its owner, amongst other operations, to act as:

These operations are under role-based access control, where recognised roles comprise:

In addition, the wallet owner may configure other roles that suit the owner’s policies and/or national or EU law.

Other relevant roles are:

From a deployment perspective, wallet implementations in the WE BUILD ecosystem can broadly be grouped into four practical categories.

These categories reflect common deployment patterns observed across wallet implementations. The concrete architecture used by a wallet provider depends on the supported use cases, operational requirements, and device capabilities.

The WE BUILD Wallet Provider Group conducted a stocktaking questionnaire covering 31 wallet providers participating in the project. Providers described the deployment models they currently support.

The results show a clear split between natural person and enterprise wallet deployments.

Many providers support multiple modes, typically combining a mobile wallet for natural persons, and a cloud or server-based wallet for legal persons.

The stocktaking exercise highlights several trends relevant for the WE BUILD pilots.

Below is a non-exhaustive overview of QEAA features that use cases may choose to pilot. For each feature in scope for the pilots, the QTSP group develops an interop profile and ensures available service compatibility.

Participants of the QTSP group may issue QEAA under any of the schemes referenced below.

Below is a non-exhaustive overview of QERDS features that use cases may choose to pilot. For each feature in scope for the pilots, the QTSP group develops an interop profile and ensures available service compatibility.

None yet.

None yet.

Standards:

Authors:

Authors:

Authors:

Authors:

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

Authors:

Authors:

Version <VERSION>

This document defines the WE BUILD Conformance Specification for <TITLE>.

Its purpose is to describe how relevant actors within the WE BUILD ecosystem are expected to interoperate in a consistent and testable way.

This specification should:

This specification is based on <BASE STANDARD / PROFILE / ADR> and should be read together with other applicable WE BUILD specifications where relevant.

This specification defines the conformance expectations for <DOMAIN / CAPABILITY>.

It should make clear:

Out-of-scope items should be listed where needed, especially if they are handled by other WE BUILD documents or external specifications.

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119.

These keywords indicate the strength of requirements for conforming implementations.

This section identifies the roles and components relevant to this specification.

Only roles that matter for this specification should be included.

Examples may include:

This section gives a short explanation of how the protocol or function works at a high level.

It should help the reader understand:

This section should stay concise. Detailed behaviour belongs in later sections.

This section describes the main interaction flows between actors.

Flows should be written as step-by-step sequences that help implementers understand how the protocol operates.

Example subsections:

This section defines the normative requirements for implementations.

Requirements may be grouped in the way that best fits the specification, for example by:

Example structure:

This section describes the technical interfaces used by the protocol.

Examples may include:

For each interface, describe:

Example subsection:

An implementation conforms to this specification if it implements the requirements defined in this document for its role and supports the relevant interfaces and flows.

Where relevant, conformance may be stated separately for each role.

Example

An implementation conforms as a <ROLE 1 CONFORMANCE CLASS> if it:

Additional WE BUILD profiles may define stricter requirements for specific use cases. Such profiles MUST NOT weaken the mandatory requirements in this specification.

[1] <ORGANISATION> (<YEAR>) <TITLE>. Available at: <URL> (Accessed: <DATE>).

[2] <ORGANISATION> (<YEAR>) <TITLE>. Available at: <URL> (Accessed: <DATE>).

[3] <ORGANISATION> (<YEAR>) <TITLE>. Available at: <URL> (Accessed: <DATE>).

Version 1.0

Table Of Contents

This document defines the WE BUILD Consortium Conformance Specification (CS) for high assurance credential issuance based on the decision recorded in WE BUILD ADR Base Protocols.

It profiles:

The aim is to ensure that Wallet Units and Credential Issuers within the WE BUILD ecosystem interoperate consistently for the issuance of SD-JWT-VC credentials [3] with high security and privacy.

This specification focuses only on issuance. Presentation, verification of requirements, and trust management are out of scope and covered in separate documents. The document is used to build the WE BUILD Interoperability Test Bed Plus (ITB+) [4].

This specification defines:

This document describes:

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL are to be interpreted as commonly used in technical specifications.

This specification uses the following roles:

The WE BUILD issuance profile is based on the OAuth 2.0 Authorisation Code Flow with the following mandatory features:

Issuance can be:

Both modes are required in this profile.

This section presents the flows as text-based sequence descriptions.

This section summarises the mandatory requirements for WE BUILD implementations.

This section defines the logical interfaces for conformance. Exact URL paths are deployment-specific and discovered through metadata.

An implementation conforms to this specification as a Wallet Provider if it:

An implementation conforms to this specification as an Issuer if it:

Profiles may define additional constraints for specific WE BUILD credential types, such as PID, QEAA, or business credentials. Such profiles MUST NOT relax the mandatory requirements in this document. The specific issuance will be taken into a separate CS.

[1] OpenID Foundation (2025) OpenID for Verifiable Presentations 1.0. OpenID Foundation. Available at: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html (Accessed: 24 November 2025).

[2] OpenID Foundation (2025) OpenID4VC High Assurance Interoperability Profile — draft 03. OpenID Foundation. Available at: https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0-ID1.html (Accessed: 24 November 2025)

[3] IETF (2025) SD‑JWT‑based Verifiable Credentials. IETF. Available at: https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-09.html (Accessed: 24 November 2025).

[4] WE BUILD (2025) Interoperability Test Bed - Reference Specification, 12 November, Available at: https://github.com/webuild-consortium/wp4-interop-test-bed/blob/main/docs/reference-implementation-interoperability-test-bed.md (Accessed: 24 November 2025).

Version 1.0

Table Of Contents

This document defines the WE BUILD Conformance Specification for Credential Presentation, describing how Wallet Units (WU) and Verifiers interoperate using OpenID for Verifiable Presentations (OpenID4VP) 1.0 [1] in alignment with the OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0 - Implementer’s Draft 1 [2], based on the decision recorded in WE BUILD ADR Base Protocols.

It specifies a high‑assurance presentation profile for use within the WE BUILD ecosystem, covering:

This document complements the WE BUILD Conformance Specification: Credential Issuance v1.0. The document is used to build the WE BUILD Interoperability Test Bed Plus (ITB+) [4].

This specification defines the conformance profile for high‑assurance credential presentation:

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, REQUIRED, RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in RFC 2119.

This specification uses the following roles:

The WE BUILD presentation profile is based on OpenID4VP with the following mandatory features defined by HAIP ID-1:

High‑level steps:

NOTE_CS02_01: ISO18013-5 and ISO18013-7 will be supported in subsequent versions based on use case requirements.

This chapter defines the presentation flows required by WE BUILD.

Interfaces in this chapter follow the structure from the Issuance Conformance Specification.

An implementation conforms to this specification as a Wallet Provider if it:

An implementation conforms to this specification as an Issuer if it:

[1] OpenID Foundation (2025). OpenID for Verifiable Credential Issuance 1.0. OpenID Foundation, 16 September. Available at: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html (Accessed: 24 November 2025).

[2] OpenID Foundation (2025) OpenID4VC High Assurance Interoperability Profile — draft 03. OpenID Foundation. Available at: https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0-ID1.html (Accessed: 24 November 2025)

[3] IETF (2025) SD‑JWT‑based Verifiable Credentials. IETF. Available at: https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-09.html (Accessed: 24 November 2025).

[4] WE BUILD (2025) Interoperability Test Bed - Reference Specification, 12 November, Available at: https://github.com/webuild-consortium/wp4-interop-test-bed/blob/main/docs/reference-implementation-interoperability-test-bed.md (Accessed: 24 November 2025).

Version 1.0 / Approved Date: 01 April 2026

Authors / Contributors: WP4 Architecture

Table of Contents

This document defines the WE BUILD Conformance Specification: Remote Qualified Signing with Wallet Units, describing how Wallet Units (WU) and Relying Parties interoperate to create qualified electronic signatures using OpenID for Verifiable Presentations (OpenID4VP) 1.0 [1] and the CSC Data Model Bindings [3].

This specification extends the WE BUILD Conformance Specification: Credential Presentation [5] (hereafter CS-02). All requirements defined in CS-02 apply unless explicitly superseded here. This document defines only the signing-specific additions.

It covers:

This specification defines the conformance profile for remote qualified electronic signature creation. It applies in addition to CS-02 [5].

Requirements are defined for:

Mandatory features beyond CS-02:

Out of scope:

As defined in CS-02 [5] Section 3.

This specification uses the roles defined in CS-02 [5] Section 4, with the following substitutions and additions:

This specification applies the protocol baseline defined in CS-02 [5] Section 5 without modification, with the following signing-specific additions:

High-level steps:

The above flow is illustrated below:

Interfaces in this specification follow the structure defined in CS-02 [5] Section 8. The Wallet Invocation Interface defined in CS-02 [5] Section 8.1 applies without modification.

An implementation conforms to this specification as a Wallet Unit if it:

An implementation conforms to this specification as a Relying Party if it:

[1] OpenID Foundation (2025). OpenID for Verifiable Presentations 1.0. Available at: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html (Accessed: 5 March 2026).

[2] OpenID Foundation (2025). OpenID4VC High Assurance Interoperability Profile - Implementer’s Draft 1. Available at: https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0-ID1.html (Accessed: 5 March 2026).

[3] Cloud Signature Consortium (2025). CSC Data Model Bindings, version 1.0.0. Published 14 October 2025. Available at: https://cloudsignatureconsortium.org/wp-content/uploads/2025/10/data-model-bindings.pdf (Accessed: 30 March 2026)

[4] Cloud Signature Consortium (2025). Data Model for Remote Signature Applications, version 1.0.0. Published 16 October 2025. Available at: https://cloudsignatureconsortium.org/wp-content/uploads/2025/10/csc-dm.pdf (Accessed: 30 March 2026)

[5] WE BUILD (2025). Conformance Specification: Credential Presentation, version 1.0. Available at: https://github.com/webuild-consortium/wp4-architecture/blob/main/conformance-specs/cs-02-credential-presentation.md (Accessed: 5 March 2026).

[6] EWC Consortium (2025). RFC-010: Document Signing on a Remote Signing Service Provider using Long-Term Certificates, version 1.1. Available at: https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/ewc-rfc010-long-term-certifice-qes-creation.md (Accessed: 5 March 2026).

[7] ETSI EN 319 102-1. Electronic Signatures and Trust Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation.