Operator eIDAS attestation / agreement-reference (skeleton template)

Status: SKELETON — pending counsel review under docs/legal/decisions/lawyer-request5.md §3 document 4 + §4 point 10. Counsel asked to identify the minimum required contents. Do not treat this template as legally final until counsel returns. Purpose: local operator-controlled attestation file that the runtime (Loader 1 / Loader 2 in src/Cryptography/StellaOps.Cryptography.Plugin.Eidas/Loading/) consults before emitting any positive eIDAS claim state. Until this file is present and well-formed, the runtime emits not-claimed:eidas-operator-agreement-not-loaded. Authored: 2026-05-04 Owner: Stella Ops Compliance + Cryptography Guild Loaded by: the operator places this file at the path configured by Eidas:TrustedList:OperatorAgreementAttestationPath (or equivalent — final config key TBD when counsel approves).

Why this file exists

The reference-only-no-vendoring canonical model adopted in EXEC-20260504-eidas-reference-only-canonical-model.md puts the burden of qualified-service representations on the operator, not on Stella Ops. The runtime can refuse to emit any positive eIDAS claim until the operator has explicitly attested that:

1. the operator (not Stella Ops) controls the relevant QTSP relationship;
2. the operator has rights to use the trust-material pack and the per-transaction evidence;
3. the operator selected the QTSP and the qualified-service profile;
4. the operator accepts pack-expiry and evidence-revocation handling duties;
5. the operator will not represent Stella Ops as a QTSP;
6. the operator is responsible for downstream qualified-service representations;
7. the operator will preserve pack and evidence audit records.

This template defines the file shape so that the runtime check, operator workflow, and audit trail all converge on the same structured artefact.

Required acknowledgements (counsel-driven minimum content)

The following acknowledgements MUST appear in the attestation file. Each is a discrete operator-authored claim. Lawyer-request5 §4 point 10 asks counsel to confirm or refine this list.

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

Counsel may add, remove, or reword these once response 5 is returned. Until then, the runtime treats absence of any of the seven acknowledgements as operator-agreement-not-loaded.

File shape (proposed, pending counsel)

# eidas-operator-agreement-attestation.yaml
# Stella Ops eIDAS operator attestation — local operator-controlled.
# Loaded by Loader 1 alongside the trust-material pack.

version: 1
operatorId: "<operator's stable identifier; opaque to Stella Ops>"
attestedAt: "<ISO-8601 UTC timestamp; signed by operator>"
attestedBy:
  name: "<authorized operator representative>"
  role: "<role / title>"
  contact: "<email or other operator contact>"

qtspRelationship:
  qtspName: "<QTSP legal name>"
  jurisdiction: "<member-state ISO code>"
  qtspServiceIdentifier: "<service-specific identifier from the relevant TSL>"
  packVersion: "<vendor-supplied pack version pin>"
  packExpiryUtc: "<ISO-8601 UTC; operator commits to refresh before this date>"

acknowledgements:
  controlsQtspRelationship: true
  hasRightsToUsePackAndEvidence: true
  selectedQtspAndService: true
  acceptsExpiryAndRevocationDuties: true
  willNotClaimStellaOpsIsAQtsp: true
  responsibleForDownstreamRepresentations: true
  willPreservePackAndEvidenceAuditRecords: true

# Optional but recommended — operator's own legal counsel sign-off pointer.
# Stella Ops does not validate this; it is operator-side audit trail only.
operatorLegalSignOff:
  reviewedBy: "<operator's counsel name or firm; optional>"
  reviewedAt: "<ISO-8601 UTC; optional>"
  reference: "<operator-side reference / ticket number; optional>"

# Operator-side digital signature over this attestation file.
# Format and signing scheme TBD pending counsel guidance.
signature:
  alg: "<TBD pending counsel>"
  value: "<base64 signature over the canonicalised attestation>"
  certificateChain: "<optional base64 chain>"

Runtime behaviour expected (Loader 1 / Loader 2)

• Missing file → emit not-claimed:eidas-operator-agreement-not-loaded. No positive claim possible.
• File present but any of the seven acknowledgements.* is false or absent → emit not-claimed:eidas-operator-agreement-not-loaded. Treated identically to missing file.
• File present and well-formed but attestedAt is in the future or before the pack’s validFromUtc→ reject the file as malformed. Emit not-claimed:eidas-operator-agreement-not-loaded.
• File present, well-formed, all acknowledgements true, signed → loader returns EidasOperatorAgreementState.Loaded(packVersion, attestedAt). Combined with Loader 1’s pack state and Loader 2’s per-transaction evidence, this enables emission of claimed-against:<qtsp-pack-version> (subject to counsel’s response on whether that string itself is legally safe — see lawyer-request5 §1(d)).
• File packVersion does not match the loaded pack’s packVersion→ fail closed. Operator must update the attestation when rotating packs.

What this file is NOT

• It is not a Stella-Ops-issued certificate. Stella Ops never signs this file. The operator does.
• It is not a contract between operator and QTSP. It is the operator’s attestation to Stella Ops’ runtime that such a contract exists.
• It is not vendored by Stella Ops in the repository or Offline Kit. It is a per-deployment artefact that the operator places at the configured path.
• It is not a substitute for the operator’s own qualified-service representations. It is a fail-closed gate that prevents Stella Ops from being implicated in those representations.

Pending counsel decisions (lawyer-request5)

The following items are explicitly pending counsel response and may change this template:

1. Acknowledgement list — counsel may add, remove, or reword the seven items above (lawyer-request5 §4 point 10).
2. Signature requirement — whether the file MUST be operator-signed and, if so, what algorithm / key class / chain is acceptable.
3. Schema location — whether this template lives at this path or somewhere counsel prefers (e.g. under docs/contracts/schemas/eidas/).
4. Wire-format — YAML vs JSON vs canonical JSON. Runtime currently parses canonical JSON for other eIDAS artefacts.
5. Per-environment vs per-tenant — whether the attestation is one-per-deployment or one-per-tenant when Stella Ops runs multi-tenant.
6. Versioning rule — whether version: 1 here pins forward-compatibility behaviour and how the runtime should treat future versions.

Append-only history