[EPIC] Add eIDAS trust service interoperability
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Domain
- backend-api-design, security
Research direction
Do not implement this epic directly. Start by reviewing dependencies #8335, #8942, #8943, and #8946, then define the supported eIDAS signature levels, provider integrations, validation requirements, and interoperability tests. Done means those requirements are explicit and focused child issues can guide implementation with external trust services.
Written by the indexing model from the issue text.
Description
This is a roadmap and funding epic.
[!IMPORTANT]
Do not implement this epic directly.
This issue exists to study, define and fund the work required for LibreSign to interoperate with European eIDAS trust services.
It must be implemented later through focused child issues. Discussion, requirements and references from trust service providers and European users are welcome.
Background
LibreSign is building the foundation for external and remote signing.
Supporting a remote certificate is not by itself the same as supporting the requirements and trust model used in the European eIDAS ecosystem.
LibreSign should integrate with qualified trust service providers instead of trying to become a trust service provider itself.
Goal
Make LibreSign able to use and validate signing services from the European eIDAS trust ecosystem through open and interoperable mechanisms.
The exact supported eIDAS signature levels and validation requirements must be defined during this epic before implementation starts.
Expected areas of work
This epic may include:
- interoperability with Qualified Trust Service Providers (QTSPs);
- remote signing through standards-based provider integrations such as CSC;
- use of qualified certificates where applicable;
- support for remote QSCD-based signing flows where provided by the trust service;
- PAdES requirements needed by the selected eIDAS use cases;
- certificate chain and revocation validation;
- trusted service status and European Trusted List integration where required;
- timestamp and long-term validation requirements where required;
- interoperability testing with European services.
Important boundary
LibreSign should orchestrate the document signing process and integrate with trust services.
It should not claim to issue qualified certificates, operate a QSCD or become a QTSP unless that is ever addressed as a completely separate project.
Why this matters
Organizations using Nextcloud and LibreSign should be able to keep their document workflows under their own control while using trusted European signing services when a higher assurance level is required.
This creates a practical open-source bridge between self-hosted collaboration and the European digital trust ecosystem.
Business and funding value
This is directly relevant to European public administrations, companies and other organizations that need open digital signing workflows but rely on qualified external trust services for certificate and key operations.
It is also a strong candidate for public-interest and European digital sovereignty funding because the result remains reusable free software and is not tied to one QTSP.
Potential funders and validation partners include:
- European organizations that already use LibreSign or Nextcloud;
- QTSPs interested in open-source integrations;
- public administrations and SMEs that need self-hosted signing workflows;
- digital sovereignty and open infrastructure funds.
Dependencies
This epic depends on:
- #8335;
- #8942 for the remote signing provider architecture;
- #8943 for CSC support where CSC is selected for a target trust service;
- #8946 for the required PAdES and validation capabilities.
Out of scope
This epic does not promise generic “eIDAS compliance” without defining the supported signature level and validation scope.
Each supported level must have explicit technical requirements, tests and validation criteria.
Done when
LibreSign can complete and validate the agreed eIDAS-oriented signing workflows with independent European trust services, with the private key remaining under the control of the external qualified service when required.
- Dominant language
- PHP
- Stars
- 828
- Forks
- 157
- Avg merge
- 6h 48m
- Merged PRs (30d)
- 622
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from LibreSign/libresign
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
LibreSign/libresign#8284 · 5 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
Maintainers usually reply within 1 day
All issues in LibreSign/libresign
Similar issues
-
sync-en
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
UX
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ProfessionalWiki/NeoWiki#1573 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100