Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add remote signing provider architecture

Aperta
  • Qualcosa non va?
#8,942 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
php
Ambito
backend-api-design, security

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
PHP
Stelle
835
Fork
167
Merge medio
1g 4h
PR unite (30g)
388

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di LibreSign/libresign

Tutte le issue di LibreSign/libresign

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.