QTSP documentation
The WP4 QTSP group collaborates on internal reference code and documentation to increase interoperability. This appendix lists the entry points for this reference documentation by each provided service.
1 QES documentation
This is documentation of the WE BUILD: WP4 QTSP group.
Technical Overview of Signing and Sealing in WE BUILD: Signing and Sealing
1.1 Informative references
- Standards
- Stable
- Work items
- eudi-doc-standards-and-technical-specifications#29: CSC standards updates
- eudi-doc-standards-and-technical-specifications#68: TS 119 432 update
- Reference specifications
2 QEAA documentation
This is part of the QTSP documentation.
2.1 Reference model
2.2 Architecture overview
2.3 Feature definitions
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.
2.4 Schemes for QEAA
Participants of the QTSP group may issue QEAA under any of the schemes referenced below.
2.5 Informative references
- Catalogues
- Attestation Rulebooks Catalog: Catalogue of schemes for EAA in EUDI
- Standards
- TS 119 471 v1.1.1: requirements for EAA Providers
- TS 119 472-1: DRAFT Profiles for EAA - General requirements
- TS 119 472-2: DRAFT Profiles for Relying Party Interface to EUDI Wallet
- TS 119 472-3: DRAFT Protocol Profiles for interfacing to services providing Personal Identity Data and Electronic Attestation of Attributes
- TS 119 612: Policy and security requirements for trust service providers issuing electronic attestation of attributes (EAA)
- TS 119 602: Electronic signatures and infrastructures (ESI); Policy and security requirements for trust service providers issuing attribute attestations
- ETSI TS 119 478: DRAFT Protocol Interface for Trust Service Provider use of Authentic Sources
- Technical reports
- TR 119 476 v1.2.1: SD and ZKP for EAA analysis
- TR 119 476-1 v1.3.1: SD and ZKP for EAA feasibility
- TR 119 479-2 v1.1.1: EAA extended validation
3 QERDS documentation
This is documentation of the WE BUILD: WP4 QTSP group.
Scope:
- Provision of electronic registered delivery services
3.1 Reference model
3.2 Architecture overview
3.3 Feature definitions
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.
3.4 Technical reports
3.5 Informative references
None yet.
4 rWSCD documentation
This is documentation of the WE BUILD: WP4 QTSP group. Scope:
- Management of remote wallet secure cryptographic devices
4.1 Informative references
None yet.
5 RPAC/RPRC documentation
This is documentation of the WE BUILD: WP4 QTSP group. Scope:
- Relying party access certificate issuance
- Relying party registration certificate issuance This is documentation of the WE BUILD: WP4 QTSP group. Scope: • Relying party access certificate issuance • Relying party registration certificate issuance
Assumptions: - In complete eIDAS ecosystem, Registrars will act as Registration Authorities for TSP issuing RPAC & RPRC. Without any actual Registrar included in the project, present RAs of involved TSPs shall play the role of Registrar. - Registrars did not publish Registration policies yet. Considering WE BUILD as a close group where trust comes from belonging, registration policy shall rely on checking this belonging together with a public NCP registration policy for RPAC: TSP will check presence in lists of WP’s RP in place of national register of Wallet Relying Parties. WP’s leader shall establish these lists.
Issuance process: Process of issuance will limit to AnnexD1 of TS 119 475 for MVP. It will be made of 11 steps : 1. The user (RP representative) will connect and authenticate to TSP’s RA by using its EBW; 2. RA will request credentials; 3. And receive as an answer a EAA granting the user to act as representative of the RP (POA); 4. RA contacts the user to request all additional attributes needed for producing RPRC; 5. RA checks that the authenticated RP is present in the lists of authorised RP supplied by WP’s leaders; 6. RA orders issuance of both certificates; 7. CA issues RPAC and RPRC; 8. CA transmits certificates to the RA; 9. RA notifies the user (e.g. by e-mail); 10. User authenticates via EBW; 11. User retrieves RPAC & RPRC.
5.1 Informative references
Standards: - EN 319 401 - EN 319 411-1&2 - TS 119 475 - TS 119 411-8 - IETF 7515 Technical Reports: - TR 119 411-9