Skip to content
Series 9 · Orchestration architecture · 9.1

Keys to interoperability.

Formats, protocols and interface contracts that let a signature travel between systems.

October 20264 min read

A signature that can only be verified inside the system that produced it is not interoperable, and a signature that is not interoperable is worth less than it seems. Interoperability is not a feature added at the end: it is a design decision made at every layer. Unlike the previous series, this one sets out the principles behind how we think about Signing Flows; here the product appears as an example, not as an argument.

Four layers of interoperability

LayerWhat must be able to travelHow it is achieved
The documentThe signature, its timestamps and its validation data.Standard advanced signature formats, such as the ETSI PAdES profiles, up to the long term level.
TrustWhich providers and roots are valid.Machine readable official trusted lists from multiple countries.
ServicesSignature requests, timestamps, revocation checks.Open protocols: the Cloud Signature Consortium interface, RFC 3161, OCSP.
IntegrationCommands and events between the platform and other systems.An interface described in a public contract, with signed events and operations that can be repeated without duplicate effects.

Principles that do not change

To interoperate is to accept that another system, one we do not control, must be able to understand and verify what we did.
In practice

At Signing Flows we apply these principles as follows: PDFs are signed with PAdES profiles, and the long term level has been checked against the European Commission's validation tool; remote signing uses the Cloud Signature Consortium interface; and our own interface is published as an OpenAPI specification, with idempotency keys and signed events. These are foundational decisions, designed so that the platform can grow without breaking what already exists.

Key points

Interoperability is built in four layers: document, trust, services and integration. At every layer the rule is the same: open standards, independent verification, explicit contracts and an exit that is always possible.

Sources

  1. ETSI EN 319 142, PDF Advanced Electronic Signatures (PAdES)
  2. Cloud Signature Consortium, API specification
  3. IETF, RFC 3161, Time Stamp Protocol, 2001
  4. European Commission, EU Trusted Lists
  5. OpenAPI Initiative, OpenAPI Specification 3.1
  6. European Commission, DSS signature validation tool

← All notes

Trust Notes

Articles for those who decide how an organization signs: principles, practices and criteria that hold up as rules and technologies change.

A publication of Signing Flows, by Interfase.

Series