webuild-consortium · peppelinux · Nov 27, 2025 · Nov 27, 2025 · Dec 1, 2025
diff --git a/task2-trust-framework/https-count-timing-analysis.md b/task2-trust-framework/https-count-timing-analysis.md
@@ -0,0 +1,115 @@
+This document aims to bring our attention about pratically approaching the eIDAS infrastructure of trust, in particular about the use case where a Wallet Instance has to evaluate the trust with an entity that is both a RP and a QTSP. We must also consider that entity could be, for instance, also a Credential Issuer at the same time, issuing QEAAs (OpenID4VCI) through credential presentations (OpenID4VP).
+
+This issue aims to find and get reactions, comments and different perspectives from the implementers and stakeholder belonging to specific sectors.
+
+## Acronyms
+
+| Acronym | Definition |
+|---------|------------|
+| EAA | Electronic Attestation of Attributes |
+| LOTL | List of Trusted Lists |
+| MS | Member State |
+| OCSP | Online Certificate Status Protocol |
+| CRL | Certificate Revocation List |
+| PSD2 | Payment Services Directive 2 |
+| QEAA | Qualified Electronic Attestation of Attributes |
+| QTSP | Qualified Trust Service Provider |
+| RP | Relying Party |
+| RPI | Relying Party Intermediary |
+| TSL | Trusted Service List |
+| WRPAC | Wallet Relying Party Access Certificate |
+| WRPRC | Wallet Relying Party Registration Certificate |
+
+## HTTP Requests Analysis for Wallet Instance Trust Evaluation
+
+Based on [wp4-trust-group Policy Discovery Pull Request](https://github.com/webuild-consortium/wp4-trust-group/pull/33), here's the HTTP request count for a wallet evaluating trust for an RP that is also a QTSP.
+
+### Minimum Request Count
+
+This analysis assumes that the wallet instance discovers the related Member State (or sector specific) Trusted List starting from the WRPAC.
+
+| Step | Requests | Description |
+|------|----------|-------------|
+| 1. LOTL fetch | 1 | List of Trusted Lists hosted by European Commission|
+| 2. Member State TSL | 1 | RP's country TSL (access certificate domain lookup) |
+| 3. RP WRPAC OCSP/CRL | 1 | Certificate revocation check |
+| 4. RP WRPRC validation | 2 | Query National Register + fetch WRPRC status list (revocation) |
+| 5. RPI WRPAC (if any) | +2 | RPI access certificate and revocation status checks (two distinct HTTP requests) |
+| **Subtotal** | **5-7** | For single Member State (MS), single register (5 without RPI, 7 with RPI) |
+
+**Latency Estimate**:
+| Scenario | Best (250ms/req) | Worst (4s/req) |
+|----------|------------------|----------------|
+| **Serialized** (5 req, no RPI) | **1.25s** | **20s** |
+| **Serialized** (7 req, with RPI) | **1.75s** | **28s** |
+| **Parallelized** (no RPI, 5 req) | **~0.5s** | **~8s** |
+| **Parallelized** (with RPI, 7 req) | **~0.75s** | **~12s** |
+
+### Worst Case - Full Discovery (27 MS + Sectoral)
+
+This analysis assumes that the wallet instance aims to fetch all the Trusted Lists and Registers for all the Member States and Sectoral Registers, for offline operations and caches.
+
+**Theoretical maximum for full cross-border discovery:**
+
+| Component | Requests | Notes | Best (250ms/req) | Worst (4s/req) |
+|-----------|----------|-------|------------------|----------------|
+| LOTL | 1 | | 0.25s | 4s |
+| MS TSLs | 27 | EU27 Member States | 6.75s | 108s (1.8 min) |
+| National WRP Registers | 27 | One per MS, if RP operates cross-border | 6.75s | 108s (1.8 min) |
+| Sectoral Registers | ~50-100 | PSD2, Healthcare, etc. PSD2 alone has ~4,000 entities across EU | 12.5-25s | 200-400s (3.3-6.7 min) |
+| OCSP/CRL per CA | ~27-50 | Multiple CAs per country, 1+ per TSL | 6.75-12.5s | 108-200s (1.8-3.3 min) |
+| WRPRC Provider validation | 2+ | Per WRPRC (register lookup + status list fetch) | - | - |
+| **Total (Serialized)** | **~130-200+** | HTTP requests | **32.5-50s** | **~8.7-13.3 min** |
+
+**Latency Estimate (Full Discovery)**:
+| Scenario | Best (250ms/req) | Worst (4s/req) |
+|----------|------------------|----------------|
+| **Serialized** (~130 req, min) | **32.5s** | **~8.7 min** |
+| **Serialized** (~200 req, max) | **50s** | **~13.3 min** |
+| **Parallelized** (3 sequential phases) | **~0.75s** | **~12s** |
+
+> **Note**: Parallelized assumes 3 sequential phases: (1) LOTL, (2) all TSLs + registers in parallel, (3) all OCSP/CRL in parallel.
+
+
+### Practical Scenario (RP in 1 MS with PSD2 authorization)
+
+| Request | Count |
+|---------|-------|
+| LOTL | 1 |
+| Home MS TSL | 1 |
+| National WRP Register | 1 |
+| PSD2/EBA Register | 1 |
+| OCSP for WRPAC | 1 |
+| WRPRC Provider validation | 2 |
+| **Total** | **~7 requests** |
+
+### Triple-Role Entity: QTSP + RP + Credential Issuer
+
+When an entity operates simultaneously as a **QTSP**, **Relying Party**, and **Credential Issuer** (issuing QEAAs via OpenID4VCI through credential presentations via OpenID4VP), the trust evaluation complexity increases significantly.
+
+#### Additional Validation Requirements
+
+| Component | Requests | Description |
+|-----------|----------|-------------|
+| **RP Validation** | 5-7 | As per standard RP flow (LOTL, TSL, WRPAC, WRPRC + status list) |
+| **QTSP Validation** | 2-3 | TSL lookup for QTSP status + certificate chain validation |
+| **Credential Issuer Validation** | 2-4 | Issuer metadata, authorization server discovery, signing key validation |
+| **Cross-Role Consistency** | 1-2 | Verify entity identifiers match across all three roles |
+
+#### Combined Request Count
+
+| Scenario | Requests | Notes |
+|----------|----------|-------|
+| **Best Case** (cached, single MS) | 9-13 | Shared TSL/LOTL lookups across roles |
+| **Typical Case** | 13-19 | Some cache misses, additional OCSP checks |
+| **Worst Case** (no cache, cross-border) | 26-41+ | Full discovery for each role |
+
+#### Latency Estimates for Triple-Role Validation
+
+| Scenario | Best (250ms/req) | Worst (4s/req) |
+|----------|------------------|----------------|
+| **Serialized** (13 req, typical) | **3.25s** | **52s** |
+| **Serialized** (26 req, worst) | **6.5s** | **104s (~1.7 min)** |
+| **Parallelized** (4 phases) | **~1s** | **~16s** |
+
+*Parallelized phases: (1) LOTL, (2) TSLs + Issuer metadata in parallel, (3) OCSP/CRL + authorization discovery, (4) cross-role consistency checks.*
diff --git a/task2-trust-framework/registry-qtsp-alignment-analysis.md b/task2-trust-framework/registry-qtsp-alignment-analysis.md
@@ -0,0 +1,123 @@
+# Registry-QTSP Working Group Alignment Analysis
+
+## Overview
+
+This document analyzes the open points and gaps between the Trust Registry working group and the QTSP working group, based on content developed todate in github issues and pull request of the [wp4-trust-group](https://github.com/webuild-consortium/wp4-trust-group).
+
+## What's Missing / Gaps Identified
+
+| Branch | Content | Gap |
+|--------|---------|-----|
+| [**certs**](https://github.com/webuild-consortium/wp4-trust-group/tree/certs) | ETSI TS 119 411-8, 119 475 specs | Missing: QTSP-specific certificate profiles for dual-role entities |
+| [**hrls**](https://github.com/webuild-consortium/wp4-trust-group/tree/hrls) | HLRs matrix | Missing: HLRs for QTSP acting as RP |
+| [**infra-schema**](https://github.com/webuild-consortium/wp4-trust-group/tree/infra-schema) | Trust infrastructure schema | Missing: QTSP service endpoints in schema |
+| [**etsi-ts-implprof**](https://github.com/webuild-consortium/wp4-trust-group/tree/etsi-ts-implprof) | ETSI 119 612 implementation | Missing: Service type for QTSP-as-RP |
+| [**pol-disc**](https://github.com/webuild-consortium/wp4-trust-group/tree/pol-disc) | Policy discovery | Missing: QTSP-specific entitlement discovery |
+
+---
+
+## Open Points for Registry-QTSP WG Coordination
+
+### 1. Service Type URI for QTSP-as-RP
+
+**Issue**: No standardized `ServiceTypeIdentifier` exists for a QTSP that also acts as RP (dual role).
+
+**Current State**: ETSI TS 119 612 defines separate service types:
+- `http://uri.etsi.org/TrstSvc/Svctype/CA/QC` for QTSPs issuing qualified certificates
+- `http://uri.etsi.org/TrstSvc/Svctype/RelyingParty` for RPs
+
+**Question**: Should a combined service type be defined, or should dual-role entities be listed twice in TSLs?
+
+### 2. WRPRC for QTSPs
+
+**Issue**: Should QTSPs presenting as RPs have WRPRCs?
+
+**Current State**: ETSI TS 119 475 focuses on general RPs. QTSPs already have qualified status in TSL.
+
+**Questions**:
+- Does QTSP qualified status in TSL suffice for RP trust?
+- Should QTSPs obtain separate WRPRCs for RP activities?
+- How should entitlements differ between QTSP services and RP services?
+
+### 3. Entitlement Aggregation
+
+**Issue**: When a QTSP has both:
+- QTSP entitlements (from qualified status in TSL)
+- RP entitlements (from WRPRC)
+
+**Questions**:
+- How should wallets aggregate/display these?
+- Which takes precedence in case of conflict?
+- Should the wallet show separate trust indicators for each role?
+
+### 4. Cross-Registry Discovery
+
+**Issue**: No defined protocol for wallet to discover which sectoral registers apply to a given RP.
+
+**Current State**: 
+- National WRP registers defined in CIR 2025/848
+- Sectoral registers (PSD2, healthcare, etc.) exist independently
+- No standardized discovery mechanism
+
+**Needed**:
+- Registry of registries (meta-registry)
+- Sectoral register discovery via TSL extensions
+- API specification for cross-registry queries
+
+### 5. Caching Strategy
+
+**Issue**: No specification for cache invalidation across 27+ TSLs + sectoral registers.
+
+**Considerations**:
+- TSL `NextUpdate` field provides update hints
+- Sectoral registers may have different update frequencies
+- Mobile wallet storage/bandwidth constraints
+- Offline operation requirements
+
+**Needed**:
+- Recommended caching TTLs per resource type
+- Delta update mechanisms
+- Priority/criticality indicators for cache refresh
+
+### 6. PSD2 Integration
+
+**Issue**: Missing bridge between ETSI trust infrastructure and EBA PSD2 registers.
+
+**Current State**:
+- EBA maintains PSD2 register with ~4,000+ entities
+- No linkage to ETSI TSL infrastructure
+- Different identifier schemes
+
+**Needed**:
+- Mapping between PSD2 authorization numbers and ETSI identifiers
+- Integration of PSD2 register into LOTL/TSL hierarchy
+- WRPRC entitlement definitions for PSD2 services (AISP, PISP, ASPSP)
+
+---
+
+## Proposed Actions
+
+| # | Action | Owner | Priority |
+|---|--------|-------|----------|
+| 1 | Define service type URI for dual-role QTSP-RP entities | ETSI ESI | High |
+| 2 | Clarify WRPRC requirements for QTSPs acting as RPs | Registry WG | High |
+| 3 | Specify entitlement aggregation rules | Policy WG | Medium |
+| 4 | Design cross-registry discovery protocol | Infrastructure WG | Medium |
+| 5 | Define caching recommendations | Implementation WG | Medium |
+| 6 | Create PSD2-ETSI integration profile | Joint PSD2/ETSI | High |
+
+---
+
+## References
+
+- ETSI TS 119 612 v2.4.1 - Trusted Lists
+- ETSI TS 119 411-8 - Access Certificate Policy for EUDI Wallet Relying Parties
+- ETSI TS 119 475 - Relying party attributes supporting EUDI Wallet user's authorization decisions
+- CIR (EU) 2025/848 - Registration of wallet-relying parties
+- EBA PSD2 Register
+
+---
+
+**Document Version**: 1.0  
+**Last Updated**: 2025-11-27
+