Merge pull request #121 from webuild-consortium/docs/03-architecture-overview-wallet--types-deployment

Added wallet info to chapter 3 and 4 as well as an appendix.

Author: Saramandus

blueprint/03-architecture-overview.md

@@ -68,3 +68,21 @@ flowchart TB
     class qtsp component;
     class directory governance;
 ```
+
+## Wallet Types in WE BUILD 
+
+WE BUILD supports wallet solutions for both natural persons and economic operators.
+
+Natural persons interact through EUDI Wallets, which enable individuals to authenticate and present personal identity attributes. Economic operators interact through EBW, which enable organisations to manage and present business-related attestations such as representation rights or organisational attributes.
+
+From a deployment perspective, wallet solutions can be implemented in several ways depending on the target users, operational requirements, and cryptographic architecture. In practice, three main implementation approaches are relevant within the WE BUILD ecosystem.
+
+| Wallet type | Typical context | Characteristics |
+|---|---|---|
+| **Mobile wallets (on-device)** | Natural persons | Wallet application running on a user’s smartphone, with credentials stored and used locally on the device. |
+| **Server or Web-based wallets** | Economic operators | Wallet services operated in backend infrastructure and accessed through Web interfaces or enterprise systems. |
+| **Hybrid wallets** | Both contexts | Combine device-based interaction with backend cryptographic infrastructure. |
+
+The underlying cryptographic architecture of wallets is defined in the ARF and related standards. This Blueprint therefore focuses on the interactions and interoperability patterns relevant for WE BUILD rather than repeating the detailed wallet architecture definitions.
+
+In practice, most deployments follow a mobile-first approach for natural persons and a server-based or enterprise-integrated approach for economic operators. Hybrid architectures may also be used to combine device-based user interaction with backend cryptographic services.

blueprint/04-integration-model.md

@@ -161,3 +161,10 @@ WE BUILD will follow the QERDS architecture decomposition and the 4-corner deliv
 5) Recipient notification will be issued, followed by recipient authentication being performed at QTSP B.
 6) Consignment and handover of the message and its metadata will be performed to the recipient’s wallet or connected backend system.
 7) Evidence will be made accessible to sender and recipient wallets (submission/dispatch and receipt/consignment or non-delivery). Evidence will be protected by qualified sealing and, where required, qualified timestamping. Where applicable, the evidence can be pushed to the sender’s and the recipient’s backend systems as well.
+
+## Enterprise and System-to-System Wallet Interactions
+Some WE BUILD scenarios involve interactions between backend systems rather than direct end-user actions. In these cases, wallet functionality may be integrated into enterprise platforms, APIs, or automated services.
+
+This is particularly relevant for EBW scenarios such as supply chain credentials, Digital Product Passports, and automated B2B or B2G data exchange. In such cases, credential issuance and presentation may be initiated by backend systems while still following the interoperability patterns defined in this blueprint.
+
+Although the interaction is system-driven, the same trust framework, credential formats, and verification mechanisms apply as in user-driven wallet interactions.

blueprint/appendix-adr.md

@@ -1,4 +1,4 @@
-# Appendix E: Architecture decision records
+# Appendix F. Architecture decision records
 
 [WE BUILD](https://www.webuildconsortium.eu/) maintains a lightweight architecture decision record (ADR) for each software-related decision affecting interoperability.
 

blueprint/appendix-cs.md

@@ -1,4 +1,4 @@
-# Appendix F: Conformance Specifications (CS)
+# Appendix G. Conformance Specifications (CS)
 
 ## About
 

blueprint/appendix-ebw-definition.md

@@ -1,4 +1,4 @@
-# Appendix D - Business Wallet Definition
+# Appendix D. Business Wallet Definition
 
 Revision 1.0
 

blueprint/appendix-glossary.md

@@ -1,4 +1,4 @@
-# Appendix A – Glossary
+# Appendix A. Glossary
 
 ## Terms and Definitions
 

blueprint/appendix-history.md

@@ -1,4 +1,4 @@
-# Appendix B – Document History
+# Appendix B. Document History
 
 ## Changes
 

blueprint/appendix-trust-ecosystem.md

@@ -1,4 +1,4 @@
-# Appendix C – Trust Ecosystem
+# Appendix C. Trust Ecosystem
 
 The trust infrastructure for the EU Digital Identity and European Business Wallet ecosystem rests on three distinct but complementary processes: **registration/onboarding** of participants, **notification** of certain entities to the European Commission, and **publication of Trusted Lists** (or Lists of Trusted Entities) that provide cryptographic trust anchors for validation. WE BUILD aligns with the [EUDI Wallet Architecture and Reference Framework (ARF)](https://eudi.dev/) and the trust-infrastructure model described in the WP4 Trust Group deliverables.
 

blueprint/appendix-wallet-implementation-models.md

@@ -0,0 +1,64 @@
+## Appendix E. Wallet Implementation and Deployment Considerations in WE BUILD
+
+This appendix provides a short overview of wallet implementation and deployment approaches observed among WE BUILD wallet providers. It does not repeat the architectural classifications defined in the ARF, but highlights aspects that are relevant for the WE BUILD pilots.
+
+Different wallet implementations exist in the ecosystem, reflecting different user groups, device capabilities, and deployment environments. In practice, implementations often combine different approaches depending on the supported use cases.
+
+### Wallet Types Relevant for WE BUILD
+
+From a deployment perspective, wallet implementations in the WE BUILD ecosystem can broadly be grouped into four practical categories.
+
+| Wallet Type | Typical Deployment | Primary Use Cases |
+|---|---|---|
+| Mobile (on-device) | Smartphone application using device hardware security | Natural person wallets and offline use cases |
+| Web / browser-based | Browser interface with backend cryptographic services | Desktop services and enterprise workflows |
+| Cloud / HSM-based | Server-hosted wallet infrastructure backed by HSMs | Legal person wallets and managed services |
+| Hybrid | Combination of local device security and remote HSM | Mixed use cases requiring both scalability and offline capability |
+
+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.
+
+### Deployment Patterns Observed Among WE BUILD Wallet Providers
+
+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.
+
+| Deployment Option | Share of Providers |
+|---|---|
+| Mobile wallet (iOS/Android app) | 77% |
+| Server wallet on cloud | 55% |
+| Server wallet on-premise | 42% |
+| Multi-device or white-label wallet | 6% |
+| Wallet functionality via API or SDK | 6% |
+
+Many providers support multiple modes, typically combining a mobile wallet for natural persons, and a cloud or server-based wallet for legal persons.
+
+### Architectural Trends in the WE BUILD Ecosystem
+
+The stocktaking exercise highlights several trends relevant for the WE BUILD pilots.
+
+#### Mobile and cloud duality
+
+The most common architecture combines:
+
+- a **mobile wallet for natural persons**, and  
+- a **server-based wallet for enterprise or legal person scenarios**.
+
+This reflects the broader EUDI ecosystem, where personal identity use cases are mobile-centric while organisational use cases often require backend infrastructure.
+
+#### Increasing use of HSM-backed 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.
+
+#### Limited visibility of WSCD implementation choices
+
+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).
+
+#### Emerging architectures for legal person wallets
+
+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.

blueprint/build.sh

@@ -90,6 +90,9 @@ cat appendix-trust-ecosystem.md >> main.md
 echo >> main.md
 cat appendix-ebw-definition.md >> main.md
 
+echo >> main.md
+cat appendix-wallet-implementation-models.md >> main.md
+
 # ADR appendix, gathers all ADRs
 echo >> main.md
 cat appendix-adr.md >> main.md