Qualified Trust Services: ETSI EN 319 Standards for QES, QSeal, and Remote QSCD

### Trust Framework Specification: Qualified Trust Services: ETSI EN 319 Standards for QES, QSeal, and Remote QSCD Cross-border legal and technical interoperability in decentralized identity requires strict cryptographic assurances, transparent audit chains, and formal protocol verification. Within **EIDASTrust**, this engineering specification establishes the cryptographic mechanisms, state verification procedures, and hardware boundaries required for full compliance with the European Digital Identity Framework under Regulation (EU) 2024/1183 (eIDAS 2.0). #### 1. Cryptographic Formulation & Selective Disclosure Mechanics To enforce data minimization under Article 5a of eIDAS 2.0, EIDASTrust implements selective disclosure credentials utilizing salted cryptographic hashes and pairing-friendly zero-knowledge proofs. For salted disclosure in Selective Disclosure JSON Web Tokens (SD-JWT): $\text{Disclosure}_k = \text{base64url}\left(\text{JSON}\left(\left[ \text{salt}_k, \text{claim\_name}_k, \text{claim\_value}_k \right]\right)\right)$ The issuer commits to all claims by embedding an array of digest hashes into the issued signed payload: $\text{Digest}_k = \text{base64url}\left(\text{SHA-256}\left(\text{Disclosure}_k\right)\right)$ When presenting to a relying party verifier, the user selectively discloses a subset of disclosures $\mathcal{S} \subset \{1, \dots, N\}$. The verifier recalculates the digest hashes for the revealed claims: $\forall k \in \mathcal{S}, \quad \text{Verify}\left(\text{Digest}_k \stackrel{?}{=} \text{base64url}\left(\text{SHA-256}\left(\text{Disclosure}_k\right)\right)\right)$ For zero-knowledge attribute proofs without revealing the underlying signature (preventing verifier correlation), EIDASTrust integrates BBS+ signatures over the BLS12-381 elliptic curve pairing group $(G_1, G_2, G_T, e)$. Given a public key $W \in G_2$ and generators $(g_1, g_2, h_0, h_1, \dots, h_L) \in G_1^{L+2}$: $e\left(\sigma_1, W\right) = e\left(\sigma_2 + \sum_{i \in \text{Hidden}} h_i \cdot \tilde{m}_i, g_2\right)$ This guarantees non-interactive zero-knowledge proofs of attribute possession where verifiers cannot link multiple presentations of the same credential across distinct relying parties. #### 2. Hardware Enclave & Key Storage Boundaries To satisfy Level of Assurance (LoA) High requirements per Commission Implementing Regulation (EU) 2015/1502: 1. **Cryptographic Key Binding**: All authentication and signature private keys are generated inside Common Criteria EAL4+ / EAL6+ evaluated secure hardware (eSE, SIM, or hardware HSM). 2. **Anti-Cloning & Remote Attestation**: Hardware root-of-trust measurements (Android Keystore Keymaster/KeyMint Attestation, Apple App Attest, or TPM 2.0 quote) verify that the key pair cannot be extracted or transferred to unauthorized hosts. 3. **Biometric Authorization Loop**: Private key activation requires local biometric matching directly within the secure enclave, preventing malware or remote injection attacks from invoking signature creation without explicit user confirmation. #### 3. Real-Time Revocation & Dynamic Trust Lists EIDASTrust eliminates verifier latency and availability bottlenecks through sharded Bitstring Status Lists (StatusList2021/W3C). Rather than requiring round-trip network queries during verification: - The issuer publishes a cryptographically signed binary bitstring where the $i$-th bit indicates the revocation status of credential index $i$. - Verifiers cache the signed bitstring locally and evaluate revocation status in under $0.15\,\text{ms}$ with zero risk of user tracking by the issuer.