Stella Ops eIDAS operator terms

Version: 2.0.0 · Contractual document. These are the operator-facing terms for any deployment that configures the eIDAS functionality. They are incorporated as Schedule 2 of the Stella Ops Customer Agreement, identified there by this version and this document's full SHA-256.

What contractual effect these terms have, stated once. These terms have contractual effect to the extent they are validly incorporated into an agreement accepted by the Customer. Before that acceptance, their publication describes product requirements and the intended responsibility allocation; publication alone does not establish the Customer's agreement to that allocation.

Audience: operators, their compliance officers and advisers, and Stella Ops sales and support. Internal record — review provenance, control evidence and approval history — is kept separately in eidas-operator-terms-internal-record.md and is not part of this contractual document or of any agreement incorporating it.

Version 2.0.0 exists because counsel's round-2 review found this document was being incorporated into a customer contract wholesale, carrying internal review history, draft-status statements and named tests with it. Those now live in the internal record. The operative clauses below are unchanged in substance, and the counsel-quoted sentences are preserved character-for-character.

0. Scope, and two things this document is not

These terms are the instrument counsel's control #7 required, in counsel's own words:

Add explicit product terms and documentation covering the provider boundary, limitations, asset rights, operator responsibility and prohibition on representing Stella Ops as a QTSP.

Sections 1-5 are those five topics, in that order.

It is not a claim that Stella Ops has any qualified status. It is the opposite: a written statement of where the Stella Ops product stops.

It is not a safe harbour. On the record:

It materially reduces Stella Ops’ exposure, but it is not by itself a statutory safe harbour.

And on what actually decides the question:

classification therefore depends primarily on the product’s actual operation and representations—not merely on the licence terms or the label “software vendor.”

Sections 1-5 are therefore operative constraints on how the product behaves and how it is described, not paperwork that discharges an obligation by existing.

1. Provider boundary

Counsel's final disposition, verbatim:

Stella Ops supplies an on-premises technical tool. The operator controls the QTSP relationship and any qualified-service representation. The QTSP provides the qualified trust service. Stella Ops runtime states report local technical processing and do not constitute qualified-service certification.

Concretely:

If Stella Ops ever operates the validation path as SaaS, a managed service, a remote support operation or a central validation endpoint, this boundary changes and EXEC-20260504-eidas-reference-only-canonical-model.md must be reopened before that happens.

2. Limitations of a Stella Ops result

A positive eIDAS runtime state from Stella Ops is a local technical validation result and nothing more. Every external rendering of it must carry counsel's sentence, verbatim:

Local technical validation result. Stella Ops does not assert that it is providing a qualified validation service or that this result constitutes a QTSP-issued validation certificate.

The two limitations counsel singles out:

Neither the API nor the user interface may convert a Stella Ops state into a generic "valid", "verified" or "eIDAS compliant" result, and downstream consumers must be able to tell cryptographic validity apart from qualified-service status. When a claim is withheld, the reason stays in the audit record.

This document also does not resolve national evidentiary, contractual, records-management, regulated-industry or professional-retention requirements. Those remain the operator's.

3. Operator-supplied asset rights

Stella Ops vendors no QTSP trust-material pack, production timestamp token, OCSP/CRL evidence, archive timestamp, vendor credential or QTSP-controlled production evidence - in its repository, in its container images, or in the Offline Kit. Every such artefact is supplied by the operator.

Counsel is explicit that this protects Stella Ops without settling anything for the operator:

Reference-only distribution avoids Stella Ops vendoring the assets, but it does not prove that the operator possesses the contractual, intellectual-property, confidentiality or data-protection rights needed to use them.

The operator warrants that it holds the contractual, intellectual-property, confidentiality and data-protection rights needed for every pack and every piece of evidence it places at a configured path, and that supplying them to its own Stella Ops deployment is within those rights.

4. Operator responsibility

Before the runtime will emit any positive eIDAS state, the operator supplies an attestation file at the pinned configuration key Eidas:TrustedList:OperatorAgreementAttestationPath, confirming all seven acknowledgements. The Operator approves and supplies the operational attestation, which is linked to the applicable contractual acceptance record. Stella Ops checks the attestation against its documented schema and operational prerequisites. Contractual acceptance is established through the agreed acceptance process, not merely by the presence of the local file. Any claim that a cryptographic signature has been verified requires actual verification under the documented signature policy. The seven acknowledgements, as enumerated - the operator:

  1. controls the QTSP relationship;
  2. has the right to use the supplied pack and evidence;
  3. selected the relevant provider and service;
  4. accepts expiry, suspension and revocation responsibilities;
  5. will not represent Stella Ops as a QTSP;
  6. remains responsible for downstream qualified-service representations; and
  7. will retain the pack, evidence and audit records.

Template: operator-attestations/eidas-operator-agreement-attestation.template.md. The operator obtains its own legal review of the attestation and the workflow before any qualified-service claim is made to a downstream party. This is a requirement of these terms, not a suggestion, and Stella Ops is not a substitute for that review.

5. Prohibition on representing Stella Ops as a QTSP

Neither the operator nor Stella Ops may describe Stella Ops as a QTSP, as holding qualified status, or as providing a qualified trust service. Counsel names the failure mode:

Representation drift. Marketing pages, proposals, UI labels, API fields, documentation or support statements could override the careful architecture by describing Stella Ops as “eIDAS certified,” a “qualified validator,” or a provider of qualified preservation or timestamping.

The three descriptions counsel names are therefore prohibited across every surface Stella Ops controls - marketing pages, proposals, UI labels, API fields, documentation and support statements:

These prohibitions bind the operator as a term of these terms, and bind Stella Ops across every surface it controls. How Stella Ops enforces them against its own surfaces is a matter of its internal controls rather than of this contract.

6. Licence position

Under the model these terms describe, Stella Ops distributes no third-party trust material: trust lists, validation policies and evidence packs are supplied by the Operator, or obtained by the Operator from sources it selects. A licence obligation in respect of that material therefore runs between the Operator and that material's own licensor, and not through Stella Ops.

The Business Source Licence governing the Licensed Work is not amended by these terms and carries no eIDAS-specific allocation of responsibility. Responsibility for Operator-supplied packs, trust material and evidence is allocated contractually - by the agreement that incorporates these terms and its Schedule 1 - and not by the licence text. Whether the licence text itself requires any eIDAS-specific amendment is an open question, and no conclusion on it is stated here or implied by these terms.

Nothing in this section determines which licence governed a copy of the Licensed Work delivered before these terms were accepted. Rights in such a copy remain subject to applicable law and to any licence or agreement validly applicable to that copy.

7. Where these terms take effect

These terms are given effect in the product and not only on paper. Emission of a positive eIDAS claim state is conditioned on the Operator attestation described in §4; the mandatory disclaimer in §2 accompanies every emitted state; no third-party trust material is vendored into the Licensed Work; and the representation restrictions in §5 are applied to Stella Ops' own published surfaces.

This section states the conditions the product enforces. It is not a representation that any particular release does or does not expose positive-state functionality, and a properly authorised release that emits a positive state on the conditions in §4 is consistent with these terms. The specific control implementations and the dated evidence of their landing are recorded in eidas-operator-terms-internal-record.md rather than here, so that no one implementation posture is frozen into an incorporated document.