Stella Ops eIDAS / QTSP posture

Audience: Stella Ops PM, operators, compliance officers, auditors, buyers, external counsel, future engineers. Status: posture is binding internally per EXEC-20260504-eidas-reference-only-canonical-model.md; pending external-counsel sign-off via the lawyer-request5.md cycle. Authoritative records: see docs/legal/decisions/README.md for the full file-level audit trail. Runtime details: see docs/modules/cryptography/architecture.md§4.8 (“Runtime Loader And Claim Control”).

This document is the single-page narrative tying the eIDAS topic together. It is evergreen — read it first if you want to understand “what is Stella Ops’ eIDAS stance and how does the runtime back it up.” Underlying records (decisions, counsel correspondence, runtime contracts) are linked throughout.

1. The regulation in 60 seconds

eIDAS (Regulation 910/2014, as amended; “eIDAS 2” is the current implementing-act landscape) defines three categories that matter for Stella Ops:

• Trust services — creation, verification, and validation of electronic signatures, seals, or timestamps where provided as a service.
• Trust service providers (TSPs) — entities providing those services.
• Qualified trust service providers (QTSPs) — TSPs admitted to a Member State trusted list with explicit qualified status. The legal effect of a “qualified” trust service only attaches when the service is listed as qualified in the relevant trusted list at the relevant time.

Articles 33 / 34 / 40 govern qualified validation, qualified preservation, qualified electronic timestamping, and the application of those rules to qualified electronic seals.

ETSI TS 119 612 v2.4.1 (TLv6) is the technical format for trusted lists; it was enforced from 2026-04-28 22:00 UTC. Pre-v6 trusted-list snapshots are admissible only as labelled historical evidence.

2. Stella Ops’ three-role architecture

The legal architecture Stella Ops asks counsel to validate is:

Stella Ops      = on-prem technical software product
Operator        = party selecting QTSP, supplying evidence,
                  and making any workflow-level qualified-service representation
QTSP            = party providing any qualified trust service
Runtime states  = local claim-control vocabulary, NOT a qualified-service certificate

Stella Ops is not a TSP and is not a QTSP. Stella Ops ships software that locally processes operator-supplied trust material and per-transaction evidence. Stella Ops does not issue, validate-as-a-qualified-service, preserve-as-a-qualified-service, timestamp, certify, seal, or provide relying-party validation reports as a QTSP. If Stella Ops ever offers hosted/managed validation, the canonical model below reopens for review (see §6).

3. The canonical model: reference-only-no-vendoring

Per EXEC-20260504-eidas-reference-only-canonical-model.md (PM-binding 2026-05-04):

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 or Offline Kit.

The in-repo sealed eIDAS fixture under src/Cryptography/__Tests/StellaOps.Cryptography.Tests/Eidas/Fixtures/sealed-pack/ is a first-party synthetic test pack. It may be used to exercise loader, CAdES, revocation, and future signer-certificate QES wiring, but it is not a QTSP pack and must not be shipped as production evidence. Real pack ingestion and replacement steps are documented in docs/modules/cryptography/eidas-qualified-provider-pack-ingestion.md.

Operator-signing program closeout (2026-06-10): production operator-QES qualification is abandoned for the operator-signed governance decisions program. That is a product/legal/supply-chain decision, not a missing implementation detail: no real QTSP/provider pack exists, no vendor-specific counsel decision exists, and treating the synthetic fixture as production qualified evidence would create a false qualified-service claim. Future re-entry must open a new sprint and follow the ingestion runbook plus REG-20260502-eidas-qualified-provider-pack.

Operators bring their own eIDAS trust material and evidence through two local loaders:

• Loader 1 — static offline trust-material pack, loaded at deploy/configuration time. Contents (operator-sourced from their QTSP arrangement): EU LOTL snapshot in TLv6 format, Member State TSL snapshots for the relevant jurisdictions, TSP/service metadata, public signing/TSA certificate chains and trust anchors, OCSP responses / CRL snapshots for the chains, service policy identifiers, CP/CPS references, and accepted/rejected test fixtures.
• Loader 2 — per-transaction evidence, loaded at the relevant release / signing / validation / evidence-embedding event, or from a local operator-controlled evidence store before use. RFC 3161 timestamp tokens are per-request artefacts (the token’s message imprint and TSA-unique serial number bind it to one specific signing event); OCSP responses and CAdES archive timestamps follow the same per-transaction model.

The runtime is implemented in src/Cryptography/StellaOps.Cryptography.Plugin.Eidas/Loading/:

• EidasTrustedListLoader.cs — Loader 1.
• EidasTransactionEvidenceLoader.cs — Loader 2.
• EidasRuntimeClaimState.cs — claim-state vocabulary (see §4 below).
• EidasClaimWording.cs — counsel-driven safer wording constants.
• EidasEvidenceNotProductionReadyException.cs — fail-closed exception with a typed reason enum.

Tests in src/Cryptography/__Tests/StellaOps.Cryptography.Tests/Eidas/ assert character-for-character equality with the counsel-supplied wording and verify all fail-closed branches.

4. The runtime claim-state vocabulary (proposed; pending counsel)

The runtime emits one of the following wire strings on every eIDAS-flavoured signing/validation surface:

Counsel question carried (decisions/eidas-counsel-thread-canonical-model.md Round 1, Edit 3): the positive states above use the word claimed-against:. Counsel surfaced this as worth re-asking before Stella Ops ever emits the positive claim state in production — a more neutral local-validation marker such as validated-against:<qtsp-pack-version> or local-validation-against:<qtsp-pack-version> may be preferable. If a future cycle decides to rename, the runtime constants flip and tests update.

5. The operator attestation file

The runtime refuses to emit any positive eIDAS claim until the operator has supplied a local attestation file at the configured path (config key TBD pending counsel). The skeleton is at docs/legal/operator-attestations/eidas-operator-agreement-attestation.template.md.

Required acknowledgements (counsel-driven minimum content; per decisions/eidas-counsel-thread-canonical-model.md Round 1, Edit 4):

1. operator controls the QTSP relationship;
2. operator has rights to use the pack/evidence;
3. operator selected the QTSP/service;
4. operator accepts expiry/revocation duties;
5. operator will not claim Stella Ops is a QTSP;
6. operator is responsible for downstream qualified-service representations;
7. operator will preserve pack/evidence audit records.

Stella Ops never signs this file. The operator does. Stella Ops only consumes it, validates the seven acknowledgements, optionally validates an operator-side signature, and lets the runtime gate proceed.

6. Reversibility / triggers that reopen the canonical model

Per EXEC-20260504-...md “Reversibility” section + decisions/eidas-counsel-thread-canonical-model.md (Edit 5 in Round 2 + the optional hosted/managed-mode trigger), the canonical model must be reopened if any of the following changes:

• The law (eIDAS 2 implementing acts, Member State trusted-list rules, ETSI TS 119 612 versions).
• Stella Ops’ product claims, support model, or hosted/managed-service posture (e.g., Stella Ops later operates the eIDAS validation path on behalf of customers).
• The runtime claim-state vocabulary or loader behaviour.
• The operator attestation model.
• The third-party asset posture (e.g., partnering with a specific QTSP whose terms permit in-repo vendoring).

A reopening is performed by a new EXEC-YYYYMMDD-eidas-...md decision that supersedes EXEC-20260504. Until then, EXEC-20260504 is binding.

7. Counsel cycle status

The eIDAS lane has two counsel review threads — both closed 2026-05-04. Each thread is a single consolidated record covering all rounds of the conversation (request → response → applied edits, repeated until verdict).

1. Canonical-model review — decisions/eidas-counsel-thread-canonical-model.md. Substantive review of the EXEC-20260504 reference-only canonical model. Two rounds; counsel affirmed the legal architecture (the four-role frame in §2 above). All counsel-driven edits applied. EXEC-20260504 header status flipped to APPROVED + COUNSEL-REVIEWED / LEGAL-MODEL-CONFIRMED. REG-20260502 wording block flipped to COUNSEL-APPROVED for the canonical-model wording only.
2. Vendor-questionnaire review — decisions/eidas-counsel-thread-vendor-questionnaire.md. Substantive review of VENDOR-BRIEF-20260502-eidas-qtsp-redistribution.md. Three rounds: vendor-independent Gate 3 → substantive reframe (which produced Loaders 1 + 2 in the runtime) → pre-forward sign-off. Counsel’s final verdict: “send it. No more substantive edits are needed.” The questionnaire is counsel-approved and held in reserve.

Conditional future counsel work (only fires under specific triggers; not currently pending):

• Vendor-specific Gate 3 review — fires only IF Stella Ops later partners with a specific QTSP. The QTSP would return terms (jurisdiction, profile, expiry/renewal, redistribution, confidentiality, no-mark-use, etc.); those terms come back to counsel for vendor-specific review before any vendor relationship lands. A new thread file decisions/eidas-counsel-thread-vendor-terms.md would be created at that time. Under EXEC-20260504 reference-only-no-vendoring, no QTSP is engaged, so this review is not currently pending. A new EXEC decision would be required to engage a QTSP.
• Reopened canonical-model review — fires only IF the law, product claims, support model, hosted/managed-service posture, runtime claim-state vocabulary, loader behaviour, operator attestation model, or third-party asset posture changes (see §6 reversibility triggers).

8. Engaging a candidate QTSP — how it works

Forwarding a vendor questionnaire / RFP / RFI to one or several candidate QTSPs is normal pre-sales activity. No contract, NDA, license, or payment is required for the act of forwarding or for receiving the candidate’s proposal:

• Compliance / Vendor Integration takes the counsel-approved decisions/VENDOR-BRIEF-20260502-eidas-qtsp-redistribution.md and sends it to one or several candidate QTSPs as cold outreach.
• The candidate returns a proposal: pricing, jurisdiction coverage, profile (RFC 3161 / CAdES-LTA / etc.), expiry/renewal cadence, redistribution model (Options A–D from the questionnaire), confidentiality requirements, marketing materials.
• An NDA may fire at this point if the candidate sends proprietary/confidential information that Stella Ops would ingest. NDAs are bilateral confidentiality, not licensing.
• Receiving multiple proposals lets Stella Ops compare candidates without committing to any.
• License / payment fires only when Stella Ops or an operator actually uses the QTSP’s qualified service in production.
• When Stella Ops decides to engage a specific candidate, that decision is itself a new EXEC under docs/legal/regulatory-asset-intake.md. The candidate’s terms then come back to counsel under the conditional vendor-specific Gate 3 review (§7 above).

In short: cold-emailing the questionnaire to three candidate QTSPs tomorrow is fine. Picking one and signing terms is what triggers the next legal cycle.

9. When a QTSP is selected — what engineering work follows

When (and only when) a future EXEC engages a specific QTSP, the engineering work that follows lands inside the existing crypto plugin tree, not as a new top-level plugin. Specifically:

• Trust-material wiring (most of the work) — operators receive the QTSP’s pack and configure it via Eidas:TrustedList:OfflineTrustMaterialPackPath. This is operator-side work; Stella Ops does not vendor the pack. The runtime (EidasTrustedListLoader.cs) consumes it.
• HSM / PKCS#11 wiring (if the QTSP uses an HSM) — the existing HSM plugin (StellaOps.Cryptography.Plugin.Hsm) consumes any compliant PKCS#11 module. PKCS#11 is the industry-standard interface; every credible QTSP HSM (Thales Luna, YubiHSM 2, AWS CloudHSM, SoftHSM2 for test, nCipher, Utimaco, Sansec / Yunsec for SM regions, CryptoPro / Rutoken for GOST regions) exposes it. Stella Ops does not need a per-vendor sub-plugin for the cryptographic operations — the existing HSM plugin works against any PKCS#11 module the operator points it at.
• Vendor-specific quirks (rare) — only if the QTSP has non-standard PKCS#11 extensions or proprietary protocols. These land as targeted code paths inside the eIDAS plugin (StellaOps.Cryptography.Plugin.Eidas), not as a new plugin.
• A truly new plugin is justified only if the QTSP uses a non-PKCS#11 protocol (proprietary REST API, custom appliance, vendor SDK that bypasses PKCS#11). Most serious QTSPs are PKCS#11-compliant; a new plugin is the exception, not the default.

This means: vendor selection does not bottleneck on per-vendor engineering. The expensive engineering — Loaders 1 + 2, the claim-state vocabulary, the fail-closed gates — is already done and is vendor-agnostic. What’s QTSP-specific is trust material, not crypto operations.

A vendor may also distribute their own SDK (typically wrapping their PKCS#11 module). Operators can use the vendor SDK directly if they prefer — Stella Ops will still consume the same PKCS#11 interface underneath, so the SDK choice is invisible to Stella Ops as long as PKCS#11 is exposed.

10. Operator workflow (when an operator deploys Stella Ops with eIDAS)

1. Operator selects a QTSP and signs a vendor agreement covering: jurisdiction, profile, expiry/renewal cadence, redistribution, confidentiality, no-claim-of-QTSP-endorsement, no-use-of-QTSP-marks.
2. Operator obtains the static trust-material pack from their QTSP and places it at the path configured by Eidas:TrustedList:OfflineTrustMaterialPackPath.
3. Operator authors their local attestation file based on docs/legal/operator-attestations/eidas-operator-agreement-attestation.template.md, populating the seven acknowledgements and (if counsel requires) an operator-side signature. Places it at Eidas:TrustedList:OperatorAgreementAttestationPath.
4. Operator wires the per-transaction evidence supply path: either (a) operator obtains timestamp / OCSP / archive evidence directly from the QTSP per release; (b) vendor supplies an operator-local appliance or batch channel; © vendor supplies periodic evidence bundles; or (d) operator validates only and embeds evidence already supplied locally. Path configured by Eidas:TransactionEvidence:RootPath.
5. Operator restarts the service. Runtime emits claimed-against:<qtsp-pack-version> (or :historical-validation for the labelled historical-replay carve-out) once all gates open. If any gate is shut, runtime emits the corresponding not-claimed:<reason> and the operator’s downstream consumers see no qualified-service claim attached to the output.
6. Operator’s own legal counsel reviews the attestation file and the workflow before any qualified-service claim is made to downstream parties. Stella Ops is not a substitute for that operator-side legal review.

11. What this posture does NOT cover

• Hosted, SaaS, managed-service, or Stella-Ops-operated validation / preservation / timestamping workflows. If Stella Ops later operates the eIDAS path on behalf of customers, EXEC-20260504 reopens (see §6 trigger).
• Non-eIDAS regulatory regimes (DORA, EBA, FIPS, GOST, SM) — tracked in their own intake records under docs/legal/decisions/.
• Vendor selection, QTSP commercial suitability, or specific vendor agreement terms — those land under future lawyer-request<N> cycles after a candidate QTSP returns terms.
• Stella Ops becoming or partnering as a QTSP. That would require a new EXEC decision plus a fresh counsel cycle.

12. Cross-references

• Customer-facing deployment flow (sales / customer success / customer’s IT-ops / customer’s compliance officer): dora-eidas-customer-deployment-flow.md— what’s per-customer (configuration), what’s per-product (counsel cycles, code), what’s almost never (per-vendor modules), common misconceptions, sales talking points.
• Binding decision: decisions/EXEC-20260504-eidas-reference-only-canonical-model.md
• Regulatory asset record: decisions/REG-20260502-eidas-qualified-provider-pack.md
• Real-pack ingestion runbook and synthetic-fixture guardrails: docs/modules/cryptography/eidas-qualified-provider-pack-ingestion.md
• Vendor questionnaire: decisions/VENDOR-BRIEF-20260502-eidas-qtsp-redistribution.md
• Operator attestation template: operator-attestations/eidas-operator-agreement-attestation.template.md
• Counsel cycle index: decisions/README.md §D
• Runtime architecture: docs/modules/cryptography/architecture.md§4.8
• Simulator/hardware separation (cross-cutting): docs/operations/simulator-and-hardware-test-separation.md§1.4
• Regulatory asset intake process: docs/legal/regulatory-asset-intake.md

Append-only history