Add remote signing provider architecture
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
- Tech stack
- php
- Domain
- backend-api-design, security
Research direction
Start by reading the external signing foundation in #8335 and use this epic to identify focused child issues for the provider layer. Define the provider-independent boundaries and keep PDF/PAdES concerns separate from provider API, authorization, session, error, and retry logic. The epic is done only after the child issues implement the architecture and at least one provider uses it without adding PDF/PAdES logic.
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 define the next architecture step after #8335 and to make the work visible for organizations that may want to fund it.
If you are interested in this topic, discussion is welcome. Implementation should happen only through focused child issues after the architecture and scope are defined.
Background
#8335 creates the foundation for signing when the private key is outside LibreSign.
The next step is to add a provider layer around that foundation.
LibreSign should be able to work with remote signing services without putting provider-specific API, authorization or session logic inside the PDF/PAdES signing layer.
Goal
Create a provider-independent architecture for remote signing.
The provider layer should be able to handle concerns such as:
- provider discovery and configuration;
- credential selection;
- authorization flows;
- signing session lifecycle;
- sending prepared signing data to a provider;
- receiving the returned signature value;
- provider-specific errors and retry behavior.
The PDF/PAdES layer must remain independent from these details.
Why this matters
This is the bridge between the generic external-signing foundation and real remote signing services.
A common provider architecture allows LibreSign to support different ecosystems without creating a separate signing implementation for each one.
Possible future integrations include:
- Cloud Signature Consortium (CSC);
- European trust service providers;
- ICP-Brasil PSC;
- cloud KMS and HSM-backed services;
- other remote signing APIs.
This also makes the work easier to fund because each protocol or provider can be implemented as an isolated follow-up project.
Expected direction
The architecture should keep this separation:
LibreSign workflow
|
v
PDF / PAdES signing layer
|
prepare / complete
|
v
Remote signing provider layer
|
v
Provider API / trust service / HSM service
The provider layer must not need to understand PDF structure, ByteRange or incremental PDF updates.
Out of scope
This epic does not implement:
- CSC itself;
- eIDAS/QTSP integration;
- ICP-Brasil PSC;
- local smart cards or tokens;
- PKCS#11;
- a specific commercial provider.
Those should be separate follow-up epics.
Funding opportunity
This work is suitable for organizations that need vendor-independent remote signing in LibreSign.
Funding this epic would create reusable infrastructure instead of a one-off integration for a single provider.
Dependency
This epic depends on the external signing foundation in #8335 being sufficiently stable.
Done when
This epic is ready to be closed when the provider architecture has been implemented through focused child issues and at least one provider can use it without adding PDF/PAdES logic to the provider integration.
- Dominant language
- PHP
- Stars
- 828
- Forks
- 159
- Avg merge
- 7h 53m
- Merged PRs (30d)
- 523
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
-
Difficulty 1/5 Under an hour Newbie friendliness 83/100
LibreSign/libresign#9007 · 1 reaction ·
Maintainers usually reply within 1 day
-
backend enhancement php
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Validation page says "This document is valid" for a document with no signaturePossibly taken @maia-andre claimed this 8 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
LibreSign/libresign#8284 · 5 comments ·
Maintainers usually reply within 1 day
-
backend php
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
All issues in LibreSign/libresign
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
fe: spell out "Auto increment" in the table editor, "AI" reads as artificial intelligence todayOpen
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
landsman/adminer-desktop#120 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
L: java:gradle L: java:maven L: ruby:bundler T: bug 🐞
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
dependabot/dependabot-core#16547 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
glpi-project/glpi#25922 ·
Maintainers usually reply within 1 day