Update Quarto build script

Author: gfour

.github/workflows/build-blueprint.yml

@@ -26,7 +26,7 @@ jobs:
 
       - name: Build static files
         id: build
-        run: cd blueprint && ./build.sh --github-action
+        run: cd blueprint && ./build-quarto.sh --github-action
 
       - name: Upload static files
         id: deployment

blueprint/01-executive-summary.md

@@ -1,3 +1,7 @@
+---
+title: WE BUILD — Architecture & Integration Blueprint (D4.1)
+---
+
 # Executive Summary and Project Context
 ## Background
 [WE BUILD](https://webuildconsortium.eu/) is a [Large Scale Pilot (LSP)](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/694487808/What+are+the+Large+Scale+Pilot+Projects) funded by the European Commission. The project tests how the European Digital Identity (EUDI) Wallet and the European Business Wallet (EBW) can support cross-border business processes across the EU.

blueprint/_quarto.yml

@@ -1,30 +1,60 @@
 project:
   title: "WE BUILD — Architecture & Integration Blueprint (D4.1)"
-  type: manuscript
+  type: website
+  output-dir: _site
 
-manuscript:
-  article: blueprint.qmd
+highlight-style: a11y
+
+website:
+  site-url: https://webuild-consortium.github.io/wp4-architecture/blueprint/blueprint.html
+  repo-url: https://github.com/webuild-consortium/wp4-architecture
+  page-navigation: true
+  bread-crumbs: true
+  llms-txt: true
+  search:
+    show-item-context: true
+    type: overlay
+  page-footer:
+    left: |
+      ![EU](eu.png){width=200px} ![WE BUILD](/we_build.png){width=200px}
+  navbar:
+    background: light
+    collapse-below: lg
+    left:
+      - text: "Architecture & Integration Blueprint"
+        href: blueprint.qmd
+      - text: "Architecture Decision Records"
+        href: appendix-adr.qmd
+      - text: "Conformance Specifications"
+        href: appendix-cs.qmd
+      - text: "Business Wallet Definition"
+        href: appendix-ebw-definition.qmd
+      - text: "Trust Infrastructure"
+        href: appendix-trust-ecosystem.qmd
+      - text: "QTSP Documentation"
+        href: appendix-qtsp.qmd
 
 toc: true
 
 format:
   html:
-    page-layout: full
+    number-depth: 4
     number-sections: true
-    notebook-links: false
-    theme: cerulean
-    self-contained: true
-    collapse-level: 4
-    toc-location: left
+    toc: true
     toc-depth: 4
     toc-expand: 4
-    toc-collapse: false
-    search: false
+    include-in-header:
+      - text: |
+          <img src="eu.png" width="200px"> <img src="we_build.png" width="200px">
+    theme:
+      - cosmo
+      - brand
     mermaid:
       theme: default
   # docx:
-    # reference-doc: p20_template_we_build_deliverabl.docx
+  #   reference-doc: template.docx
 
 filters:
   - shift_headings.lua
 
+# freeze: true

blueprint/appendix-adr.md

@@ -1,10 +1,12 @@
-# Appendix G. Architecture decision records
+---
+title: Architecture decision records
+---
 
 [WE BUILD](https://www.webuildconsortium.eu/) maintains a lightweight architecture decision record (ADR) for each software-related decision affecting interoperability.
 
 Propose new ADRs using the [template](_template.md). Announce them to the [Architecture group](https://portal.webuildconsortium.eu/group/architecture) in the Portal to get feedback to understand the consortium’s opinion. 
 
-## ADR process for WE BUILD
+# ADR process for WE BUILD
 
 ```mermaid
 stateDiagram-v2
@@ -23,5 +25,5 @@ stateDiagram-v2
     rejected --> [*]
 ```
 
-## ADR overview
+# ADR overview
 

blueprint/appendix-cs.md

@@ -1,34 +1,36 @@
-# Appendix H. Conformance Specifications (CS)
+---
+title: Conformance Specifications (CS)
+---
 
-## About
+# About
 
 The Conformance Specifications define how WE BUILD participants implement wallet interfaces and communication protocols between issuers, wallets, and relying parties (RPs). 
 They ensure interoperability and conformance by translating ADR decisions into precise implementation requirements.
 
 The ITB will be based on the CS as a starting point. The test suites in the ITB are relying predominantly on the CS. 
 
-## Contributing
+# Contributing
 
 The Architecture group define the CS, with help from all implementing participants (wallets, issuers and verifiers). For members of the consortium, find more information on the CS processes are held on [open social - Architecture Group](https://portal.webuildconsortium.eu/group/architecture). 
 
-## CS Process Summary for WE BUILD Large Scale Pilots (LSPs)
+# CS Process Summary for WE BUILD Large Scale Pilots (LSPs)
 
 Conformance Specifications (CS) progress through the following process towards the Large Scale Pilots (LSPs):
 
 ![CS Process and Roles](https://github.com/webuild-consortium/wp4-architecture/blob/main/images/WPRoles.png)
 
-### Approved CSs
+## Approved CSs
 
 | **CS #** | **CS Title**                        |
 | -------- | ------------------------------------|
 | CS-001   | Credential Issuance - v1.0          |
 | CS-002   | Credential Presentation - v1.0      |
 |          |                                     |
 
-### CSs Under Development
+## CSs Under Development
 
 | **CS #** | **CS Title** |
 | -------- | ------------ |
 |          |              |
 
-## Conformance Specifications
+# Conformance Specifications

blueprint/appendix-ebw-definition.md

@@ -1,16 +1,18 @@
-# Appendix D. Business Wallet Definition
+---
+title: Business Wallet Definition
+---
 
 Revision 1.0
 
-## Scope and context 
+# Scope and context
 
 This document sets out a non-technical working definition of “business wallet” as introduced in the European Business Wallet regulatory proposal, to support a common interpretation within WE BUILD and in dialogue with the European Commission. It is intended as reference material for the WE BUILD use case and capability work. It does not cover detailed architecture, protocol choices, implementation design, or use case roadmaps.
 
 This document draws on the EUDI Wallet regulations, EWC deliverables<sup><sup>[\[1\]](#footnote-0)</sup></sup>, and relevant industry and consortium publications, and incorporates the draft Implementing Act on Business Wallet.
 
-## Core concepts
+# Core concepts
 
-### Description
+## Description
 
 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.
 
@@ -24,7 +26,7 @@ The wallet owner is defined by **European Business Wallet Owner Identification D
 
 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.
 
-### Conceptual model
+## Conceptual model
 ```mermaid
 graph LR
     A(Other Business Wallets) --> B(Business Wallets)
@@ -40,9 +42,9 @@ graph LR
     class B businessWallet
 ```
 
-## Business Wallet definition
+# Business Wallet definition
 
-### Roles supported
+## Roles supported
 
 A business wallet enables its owner, amongst other operations, to act as:
 
@@ -62,15 +64,15 @@ Other relevant roles are:
 - Wallet provider: the entity that provides the business wallet solution to its owner (potentially the owner themselves)
 - Owner identification data provider: the entity that verifies the identity of an authorised representative enrolling the wallet owner and attests, using an electronic attestation of attributes, the wallet owner's identification data in accordance with authentic source registrations
 
-### Key functions
+## Key functions
 
-#### Wallet lifecycle management
+### Wallet lifecycle management
 
 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._
 
-#### Digital document management
+### Digital document management
 
 The business wallet enables the wallet owner to create, store, use and validate various types of digital documents:
 
@@ -84,18 +86,18 @@ For this purpose, the business wallet implements several applications, including
 
 **_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](#appendix-f-qtsp-documentation)._
 
-#### Secure communication channel
+### Secure communication channel
 
 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](#qerds-documentation)._
 
-#### Access control mechanism
+### Access control mechanism
 
 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._
 
-#### Digital transaction management
+### Digital transaction management
 
 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.

blueprint/appendix-qtsp.md

@@ -0,0 +1,6 @@
+---
+title: QTSP documentation
+---
+
+The WP4 QTSP group collaborates on [internal reference code and documentation](https://github.com/webuild-consortium/wp4-qtsp-group) to increase interoperability. This appendix lists the entry points for this reference documentation by each provided service.
+