RFC 0005: Sharing system and MISP connector

Sharing is a sibling of deployment, not a platform

MISP MUST NOT be added to the platforms capability matrix. A MISP instance is not a query engine and MUST NOT grow a configurations.misp block on rule::1.0.

Connectors register by connector id (misp), and the connector id is also the integration key in sharing.toml. A workspace MAY declare several blocks of one integration (for example [[misp]] blocks named misp-internal and misp-isac), each with its own URL, credentials, selection, and TLP ceiling. A block is the unit of destination; the word target below means one block.

flowchart LR
  WS["Workspace objects"] --> A["[[misp]] misp-internal<br/>selection + max_tlp"]
  WS --> B["[[misp]] misp-isac<br/>selection + max_tlp"]
  WS --> C["[[opencti]] (future connector)"]
  A --> API1["MISP REST (internal)"]
  B --> API2["MISP REST (ISAC)"]

Deliverables after acceptance

The draft revisions of this RFC shipped no spec text, so reviewers could agree on the model before text was written against it. AGENTS.md permits that sequencing — spec, fixture, SPECS.md, and CHANGELOG.md updates go in the RFC PR or "follow-up after acceptance per maintainer guidance". Acceptance lands every deliverable below in one PR, #19.

No new object schema revision. metadata.schema values stay threat::1.0 / objective::1.0 / rule::1.0.

Configuration

3.1 Merge and discovery

Sharing configuration follows the existing configuration merge order: bundled package → client .opentide/configurations/ → parent instance. Vocabulary files remain non-overridable.

Top-level sharing.toml maps to config key sharing. Its top level holds only arrays of tables, one per integration, keyed by connector id: every MISP instance is one [[misp]] entry, and a later OpenCTI connector adds [[opencti]] entries beside them. Any other top-level key — a leftover [sharing] table, [targets.<id>] tables, or a bare scalar — is a configuration error, so a workspace written against a draft layout fails loudly rather than sharing nothing. A top-level array whose key names no connector the CLI knows is a warning and is skipped, so a workspace MAY declare [[opencti]] before its CLI supports it.

Integration arrays merge across layers by name. The generic deep merge replaces arrays wholesale, which would force a client to restate every bundled block to change one; sharing is the one configuration file where arrays of tables instead merge entry by entry. A later layer's entry with the same integration key and name overrides the earlier entry key by key; an entry with a new name is appended. A duplicate name in one layer, or one name used by two integrations, is a configuration error. Required keys are checked on the merged result, so enabling a bundled block is two lines:

[[misp]]
name = "misp-internal"
enabled = true

Bundled defaults MUST ship with no enabled block, matching platforms.

3.2 sharing.toml

[[misp]]
name = "misp-internal"
enabled = true
url = "https://misp.internal.example.org"
api_key = "${MISP_INTERNAL_API_KEY}"
max_tlp = "amber"
object_types = ["threat", "objective", "rule"]
rule_statuses = ["PRODUCTION"]

[[misp]]
name = "misp-isac"
enabled = true
url = "https://misp.isac.example.net"
api_key = "${MISP_ISAC_API_KEY}"
max_tlp = "green"
object_types = ["rule"]
publish = true
organisation_uuid = "00000000-0000-4000-8aaa-000000000002"

# [[opencti]]
# name = "opencti-sector"
# ...keys defined by a future sharing::opencti::1.0 spec

There are no global keys. Selection and the TLP ceiling are decided at the integration block, because that is where the destination, its audience, and its credentials are declared; a global ceiling that every block could only tighten was a second policy layer that every reader had to resolve by hand.

3.3 Keys every integration block carries

The connector spec defines every other key of its block. Within a known integration an unrecognised key is a configuration error naming the key and the block, raised before any destination is contacted. Keys removed by earlier drafts (§7.1) are therefore rejected by the same rule, with no separate removed-keys list to maintain.

Nothing in one block changes the resolved configuration of another, and each block MAY name a distinct environment variable for its key. There is still one file.

CLI: opentide share

Normative command family. Implementations MUST provide these subcommands; opentide share with no subcommand MUST mean push.

Shared flags (push / preview / retract):

Scope rules MUST match validation: --file / --uuid / --type that match nothing MUST fail with scope_no_match rather than succeeding vacuously. The same applies to block selection: an unmatched --target value and an empty resolved block set are scope_no_match. CLI filters narrow a block's selection; they never widen it.

Exit status (whole command, not per block; object-level outcomes live in the share report). Implementations MUST choose exactly one code using this order:

1. Preflight (validation, configuration errors, organisation_uuid_mismatch on every selected block, scope_no_match) → 1.
2. Else if at least one object action succeeded (created / updated / unchanged / retracted) and at least one object or block failed → 3.
3. Else if no object failed → 0. Policy skips (skipped_tlp, skipped_status, skipped_type) are not failed. An all-skip run is 0.
4. Else (at least one failed, no successful object action): if every failed is authentication or connectivity → 2; otherwise → 1.

This order is a partition: a sole-block run of only ambiguous_remote_event / HTTP 5xx is 1; only auth/connectivity is 2; mixed success and failure is 3; policy skips with no failed remain 0.

Stdout SHOULD be a structured share report (human table by default; --json MAY be offered). The report MUST carry exactly one record per pair of object metadata.uuid and block name, each with exactly one action (created, updated, unchanged, skipped_tlp, skipped_status, skipped_type, retracted, failed), the remote identifier where one exists, and a reason on every skipped_* and failed. Informational notes MAY be attached to a record without changing its action.

Secrets MUST NOT appear in logs, reports, or preview payloads: every API key value, authorization header value, and value substituted from a ${ENV_VAR} placeholder is replaced with a fixed redaction marker. Block url and organisation_uuid values carry no credential and are emitted unredacted.

Workspace layout and share state

Additions to workspace.md:

There is no sharing export directory and no file-export mode. preview prints the share report and writes no file. .opentide/states/ holds generated synchronization ledgers; sharing has exactly one. A later subsystem gets its own file in that directory. A new connector or a new sync state is another line in sharing.jsonl, not another file.

The ledger is UTF-8 JSON Lines, one JSON object per line, with no wrapping array. It records the current synchronization of each object to each block, not a history of pushes. A writer MUST keep at most one line per triple of object_uuid, integration, and target. A reader that finds a duplicate triple keeps the last line. Lines whose state an implementation does not understand MUST be preserved on rewrite.

State is a regenerable cache, not an authority. Push locates the remote Event by the composite key of §7.5, and the remote result wins on any disagreement: differing fields are overwritten with observed values, and a line is discarded when the lookup finds no Event. A skip or a failure does not change a line. unchanged leaves the line as it is. retract --delete removes it. Deleting the file changes no outcome except replacing unchanged with updated. Implementations SHOULD gitignore it.

Connector registry (generic)

A connector implementation MUST declare:

Connectors without pull MUST NOT advertise import. Each connector spec MUST list every key its block accepts; the loader rejects any other key in that integration's blocks before contacting any destination, so a future connector neither inherits MISP's keys nor needs a removed-keys list.

Future connectors (OpenCTI, TAXII 2.1 collections) get their own sharing::<id>::1.0 specs and their own top-level array in sharing.toml ([[opencti]]); this RFC does not specify them.

MISP connector (sharing::misp::1.0)

7.1 The [[misp]] block

[[misp]]
name = "misp-internal"
enabled = true
url = "https://misp.internal.example.org"
api_key = "${MISP_INTERNAL_API_KEY}"
max_tlp = "amber"
object_types = ["threat", "objective", "rule"]
rule_statuses = ["PRODUCTION"]
# organisation_uuid omitted: each object's metadata.organisation.uuid is used
# publish = false
# verify_ssl = true

A second [[misp]] entry is a second MISP instance, with its own credentials, selection, and ceiling (§3.2 shows misp-isac).

The first MISP block is deliberately small: where to connect, what to select, how high TLP may go, and whose name to publish under. Everything else earlier drafts exposed is fixed in 1.0. Adding an optional key in a later revision is additive for every workspace; removing one is not, so the first revision exposes only what an operator cannot do without.

Publishing organisation. The organisation is half the lookup key of §7.5. opentide objects already record an owning organisation as metadata.organisation.uuid (metadata.md), so the connector consumes that value first and lets a block override it:

An object where both are absent is failed / organisation_uuid_missing. The connector MUST NOT fall back to the API key's organisation. |

Before any create or update, the connector MUST read the API key's organisation and compare it case-insensitively to the resolved value. MISP records the key's organisation as the Event creator whatever the payload says, so a mismatched Event would never match the lookup key and would duplicate on every later run. A mismatch therefore writes nothing: when the value came from the block, the block fails with organisation_uuid_mismatch; when it came from an object, only that object fails. A read failure fails the block with organisation_uuid_unverified; other blocks continue. An object whose metadata.organisation names someone else is republished by setting organisation_uuid on the block to the publisher's own organisation.

Earlier drafts made organisation_uuid mandatory on every target. That duplicated, per destination, a value every object already carries, and let the two disagree silently.

Distribution is derived from TLP. 1.0 has no distribution key:

sharing_group_id is always 0. Each row is the narrowest reach the draft's TLP-to-allowed-distribution table permitted for a community instance: clear and green stay inside the receiving community rather than syncing onward, and amber, which the draft could route to a sharing group, stays organisation-only until sharing groups are specified. Wider distribution and sharing groups are a later revision of the connector (N-4).

Not configurable in 1.0. These keys are rejected as unknown keys (§3.3). They name behaviour this revision fixes rather than exposes:

Removed options. Earlier drafts carried these; each is likewise an unknown key:

7.2 HTTP API (normative subset)

Minimum MISP version: a release that ships upstream opentide template version 5.

Auth: every request MUST send the API key as MISP expects (Authorization: <key>). Implementations MUST NOT put the key in query strings.

Request shapes are pinned in specs/sharing/misp-1.0.md. restSearch is not assumed to constrain creator organisation and object attribute in one predicate, so the connector keeps a hit only when both halves of the lookup key match (N-5).

PyMISP is the recommended opentide implementation library; the spec is HTTP/JSON, not Python. Any client that speaks this subset conforms.

On 401/403, the block MUST fail with "authentication failed" without dumping response bodies that might include keys. Galaxy lookups that fail for transport, timeout, or authorization reasons fail the affected object with galaxy_lookup_failed; they MUST NOT silently degrade into a guessed value. Cluster lookups MUST be read-only: the connector never creates, modifies, enables, deletes, or uploads a galaxy or cluster.

7.3 Tags and galaxies

The emitted tag set is closed to three sources: TLP, PAP, and clusters from two galaxies.

Emission order, so a golden fixture is byte-comparable across runs: TLP, PAP, threat-actor clusters, then mitre-attack-pattern clusters; ascending code point order within each group; each distinct tag string at most once.

TLP and PAP tag strings are copied character-for-character from the misp field of the matching [[keys]] entry in tlp.vocab.toml and pap.vocab.toml. A metadata.tlp value that is absent or matches no key fails the object with unmapped_tlp; a metadata.pap value that matches no key fails it with unmapped_pap. An absent metadata.pap emits no PAP tag — PAP is emitted only when the object carries it (D-8), and there is no per-block PAP default.

extra_tags is not configurable in 1.0 (§7.1), so the closed tag set holds for every block. Communities with local taxonomies are the case for adding bounded constant tags in a later revision (D-5).

Removed from the first draft: the tag rows for maturity, RSIT, kill chain, sectors, criticality, and viability, and the whole opentide:* bookkeeping namespace with its tag_namespace option. Those six vocabularies now travel inside the object document only. Family, schema, version, object UUID, and rule status travel as opentide object attributes and inside the document, so duplicating them as tags added maintenance without adding information.

Cluster resolution is a lookup, never a construction. The connector MUST resolve every cluster against the receiving instance and MUST emit the cluster value string exactly as the instance returns it. It MUST NOT derive a cluster value from an opentide vocabulary field: att&ck::1.0 name values use a <Parent>: <Sub-technique> form that does not equal a MISP cluster value, and silently constructing one produces a tag that looks right and matches nothing.

Failure modes are all non-fatal to the Event, because a missing cluster is a property of the receiving instance rather than a defect in the object (D-6):

A sub-technique emits its own cluster tag only. The parent technique is emitted only when the object lists the parent identifier separately, because inferring the parent invents a mapping the author did not write.

7.4 Event envelope

The connector derives exactly seven Event fields:

The field set is closed by choice, not by observation. Document transport needs exactly four things from the envelope: routing (distribution, sharing_group_id), triage (threat_level_id, analysis), human labelling and ordering (info, date), and publication state (published). Everything an object could otherwise contribute is inside the document, where it is lossless. Keeping the set closed is what makes a golden fixture a complete expectation rather than a sample.

uuid, timestamp, orgc_id, org_id, Orgc, Org, event_creator_email, EventReport, and CryptographicKey are server-owned and MUST NOT be set. The Event uuid in particular is assigned by the receiving instance (§7.5) and is echoed by the connector only to address an existing Event on update.

The Event title is the object name alone. The first draft's question 10 asked for a framework or organisation marker in the title; the creator organisation MISP already shows beside every Event carries that, and a prefix would make the title differ per block for the same object. analysis is fixed at completed because a shared Tide object is a finished document, not an investigation in progress.

An object whose top-level name is absent or empty after trimming, or whose metadata.created is absent or not a valid YYYY-MM-DD date, is failed with the offending field named, and no remote Event is created or modified.

threat_level_id (MISP: 1 High, 2 Medium, 3 Low, 4 Undefined) is derived from the object, never configured. The source field is per family: threat → top-level criticality; rule → top-level severity; objective → none. One table covers all three opentide severity scales. The opentide scales and the MISP scale are separate namespaces, and neither severity.vocab.toml nor alert_severity.vocab.toml carries a misp field, so this translation is introduced here rather than read from vocabulary data.

Values are matched against the full vocabulary name (case-sensitive first, then case-insensitive equality), never by substring or token — minor must not match Baseline - Minor. A rule severity value is matched against both the severity::1.0 and alert_severity::1.0 rows; see Observations not acted on for why. Low and Medium appear in more than one scale and resolve identically in each, so cross-scale matching needs no knowledge of which scale a value came from.

This replaces the first draft's threat_level_source option and its four tables, and it rejects a per-block constant: two objects of different severity published to one instance must not arrive indistinguishable.

7.5 The single opentide object, identity, and idempotency

Every Event carries exactly one MISP object, an instance of the upstream opentide template, and zero Event-level attributes. Every attribute the connector emits is a member of that object. No detection, sigma, or yara object is emitted, and no MISP ObjectReference entry is created.

The template is pinned by identity, and this repository commits a copy of the upstream definition at schemas/misp/opentide.definition.json so that the pinned relation set is reviewable data rather than a claim in prose:

Template version 5 values_list is threat, objective, rule. The earlier draft's tvm, dom, and mdr tokens MUST NOT be emitted. misp-event-relation is optional on the template and is not emitted: MISP Event UUIDs are server-assigned.

A missing required relation on the receiving instance's template fails the object with template_relation_missing, naming each absent relation. A missing template altogether fails it with template_missing. A template_version that differs from the pinned 5 while all six required relations are present is an informational note, not a failure — the connector emits the pinned relation set and continues. There is no template_version_unsupported reason.

Updates are confined to the seven envelope fields, the tag set, and the one opentide object. Remote objects or Event-level attributes the connector did not emit are left in place with an informational note, and the remote Event uuid and creator organisation are never rewritten.

Relations point from child to parent. The template documents opentide-relation only as "UUID of other opentide Objects with a relation to this Object", so direction is a choice this RFC makes:

Child-to-parent is chosen because a child always knows its parent while a parent does not enumerate its children. Emitting from the child needs no workspace-wide graph walk, and adding a rule never forces a re-push of the objective or threat above it. Values are 36-character lowercase canonical UUIDs of Tide objects — never MISP Event or object UUIDs — at most one attribute per distinct UUID, ordered ascending lexicographically so a golden fixture is stable. A relation value that is not a canonical UUID fails the object. A relation source that is absent, null, or an empty list emits zero relations and is a normal success. A relation UUID whose object was not shared to that block is still emitted, with an informational note (D-4): the value is opentide identity, and withholding it would make the record depend on share history.

No extends_uuid value is set and no MISP event extension is created. The first draft's parent-presence machinery — a pre-HTTP share plan, a remote presence probe, and rules about MISP published state — existed only to keep extends_uuid from dangling. Carrying the parent UUID as an attribute value removes the whole problem: the record is correct on emission, needs no ordering guarantee, and repairs itself when the parent is shared later.

Event identity. The Event UUID is assigned by the receiving instance and is never forced to equal metadata.uuid. The reason is the multi-publisher case, not an implementation convenience: in a shared community, several organisations may each publish their own version of the same opentide object, each under their own MISP organisation. If the Event UUID were the object UUID, the second publisher's Event would collide with the first's, and every instance would have to choose between rejecting the publication and overwriting another organisation's record. So the connector locates its own Event by a composite key, and both halves are required (D-2):

lookup key = (Event.Orgc.uuid == resolved publishing organisation, §7.1)
           ∧ (opentide object `uuid` attribute == Tide object metadata.uuid)

Orgc.uuid is compared as a canonical UUID, case-insensitively; the uuid attribute is compared as an exact case-sensitive string. An Event satisfying only one half is no match.

Because the organisation is part of the key rather than a check applied after matching, the first draft's verify_event_org option and its org_mismatch reason are removed. A foreign publisher's Event is the expected shape of a healthy community, not an error, and it must neither trigger an ambiguity failure nor stop this block from creating its own Event.

The content hash is computed over the emitted object document, locally, before any request. It is therefore unaffected by anything the receiving instance may normalise on ingest.

7.6 Unredacted payload governed by TLP and distribution

The opentide-object attribute carries one value: the verbatim byte sequence of the source object document, as plain UTF-8 YAML text — comments, key order, indentation, and blank lines preserved, no canonical re-serialisation, no base64 or compression, no truncation, no splitting across attributes, and no envelope, shard wrapper, or transport header around the body (D-11).

Two contracts follow by construction rather than by rule. The emitted document is exactly one YAML document parsing to a mapping at the root, and it passes the uuid-format and schema checks of validation.md against its own metadata.schema whenever the source object does — the workspace-scope id-uniqueness check and the cross-object References and Chaining sub-steps are outside the contract, because a single detached document carries no workspace registry. And every authored value, including the top-level key set, is character-for-character equal to the source. Push always runs those checks before payload construction and records an object raising error-severity issues as failed / validation_error; warning-severity issues continue with a note. Earlier drafts let a target switch validation off with require_validation = false; 1.0 does not, because an unvalidated document is exactly what a consumer cannot trust.

Nothing is removed. No field, key, comment, or value is dropped, emptied, masked, replaced, or truncated for any block, any metadata.tlp value, any configuration key, or any run flag. references.internal, platform tenants, response.procedure.searches[].query, and every query, search, condition, sigma, yara, and hunt details value an object carries reach every recipient the resolved distribution permits. TLP:RED is shared on the same terms as any other TLP value when the block's max_tlp is red, carrying its complete body (D-12).

The exposure controls are exactly two: the block's max_tlp ceiling and the TLP-derived distribution of §7.1. Payload filtering is not among them. Withholding content from a recipient is done by raising the object's metadata.tlp, by lowering the block's max_tlp, or by leaving the object out of the block's selection — there is no per-field mechanism, and the connector spec carries this consequence in its own text so that an operator learns it before configuring a block.

The first draft's §7.6 is removed wholesale: the include_queries, include_internal_references, include_tenant_identifiers, include_platform_blocks, and include_object_yaml options; the skipped_redaction and skipped_yaml report outcomes; and the prohibition on attaching the source document unmodified, which this revision reverses — carrying the verbatim document is now the required behaviour. No replacement option, flag, or default may remove a field.

One prohibition survives, and it is connector-side. No workspace configuration value, no api_key value, no authorization header value, and no value substituted from a ${ENV_VAR} placeholder is ever injected into the document, the object, the envelope, the tag set, the share report, the share state, or CLI output. This constrains what the connector adds; it is not a payload filter. A value an author wrote into the object body is shared as authored, even if it resembles a credential.

preview and push produce a byte-identical opentide-object value and the same outcome class for the same object and block — so a golden fixture is a single expectation for both. The content hash and the TLP gate are evaluated before any create, update, or publish call.

7.7 Retract

Retract is still TLP-scoped: it operates on previously shared records in state or on the remote, not on objects that were never pushed.

7.8 Example — authored object vs emitted Event (preview)

Author YAML (fixture-style; every value below is a placeholder):

name: Suspicious PowerShell Encoded Command
metadata:
  uuid: 00000000-0000-4000-8003-000000000010
  schema: rule::1.0
  version: 3
  created: "2026-01-01"
  modified: "2026-02-04"
  tlp: amber
  pap: amber            # optional, from the metadata 1.1 revision
  author: detection-team
  organisation:         # consumed as the publishing organisation
    uuid: 00000000-0000-4000-8aaa-000000000001
    name: Example CERT
description: Detects encoded PowerShell command lines used for credential access.
status: PRODUCTION
severity: High
techniques:
  - T1059.001
detection_model: 00000000-0000-4000-8002-000000000001
references:
  internal:
    runbook: https://wiki.internal.example.org/runbooks/encoded-powershell
response:
  alert_severity: High
  procedure:
    analysis: Confirm parent/child process chain and account context.
configurations:
  sentinel:
    enabled: true
    # the query travels with the document; TLP and distribution decide who reads it
    query: |
      SecurityEvent
      | where EventID == 4688
      | where CommandLine has "-enc"

Emitted Event, block misp-internal from §7.1 (informative). Every envelope value is derived, not chosen:

• info — the object name.
• date — the calendar date of metadata.created.
• distribution 0 — TLP amber maps to your organisation (§7.1).
• sharing_group_id 0 — always, in 1.0.
• threat_level_id 1 — rule severity: High, matched through the alert_severity::1.0 rows of §7.4.
• analysis 2 — fixed at completed.
• published false — always, in create and update payloads alike.
• No extends_uuid, no ObjectReference; the objective UUID is an opentide-relation attribute value.
• Publishing organisation 00000000-0000-4000-8aaa-000000000001 — misp-internal sets no organisation_uuid, so the object's metadata.organisation.uuid is used. It is checked against the API key's organisation before the create and is not part of the payload, because MISP sets Orgc from the key.

{
  "Event": {
    "info": "Suspicious PowerShell Encoded Command",
    "date": "2026-01-01",
    "distribution": 0,
    "sharing_group_id": 0,
    "threat_level_id": 1,
    "analysis": 2,
    "published": false,
    "Attribute": [],
    "Tag": [
      {"name": "tlp:amber"},
      {"name": "PAP:AMBER"},
      {"name": "misp-galaxy:mitre-attack-pattern=\"<cluster value returned by the instance for T1059.001>\""}
    ],
    "Object": [
      {
        "name": "opentide",
        "meta-category": "misc",
        "template_uuid": "892fd46a-f69e-455c-8c4f-843a4b8f4295",
        "template_version": 5,
        "Attribute": [
          {"object_relation": "name", "type": "text", "value": "Suspicious PowerShell Encoded Command"},
          {"object_relation": "uuid", "type": "text", "value": "00000000-0000-4000-8003-000000000010"},
          {"object_relation": "version", "type": "text", "value": "3"},
          {"object_relation": "opentide-type", "type": "text", "value": "rule"},
          {"object_relation": "schema", "type": "text", "value": "rule::1.0"},
          {"object_relation": "opentide-object", "type": "text", "value": "name: Suspicious PowerShell Encoded Command\nmetadata:\n  uuid: 00000000-0000-4000-8003-000000000010\n  …the document above, byte for byte, comments included…\n"},
          {"object_relation": "opentide-relation", "type": "text", "value": "00000000-0000-4000-8002-000000000001"}
        ]
      }
    ]
  }
}

The Event uuid and Orgc are deliberately absent from the create payload: the instance assigns the UUID, and the connector reads Orgc.uuid back to key later lookups (§7.5).

The JSON above abbreviates each attribute. The connector spec pins the rest (N-1, N-2): every attribute carries category Other, to_ids false, and distribution 5 (inherit the Event), and the object itself carries distribution 5, so it can never be more widely distributed than the Event that carries it. disable_correlation follows the template per relation (§7.5). The golden fixtures under fixtures/sharing/valid/ show every field.

The technique cluster tag value is shown as a placeholder. The connector emits the cluster value the instance returns for T1059.001 and never constructs one, so golden fixtures assert the tag's shape rather than one instance's string (N-6).

Validation of sharing config

opentide validate SHOULD gain an optional check sharing-config (off by default, always on for opentide share push). It checks the merged sharing.toml:

• The top level holds only arrays of tables; any other top-level key is unknown_key
• Every block has name, and every [[misp]] block has url and api_key (missing_field); api_key resolves to a set, non-empty environment variable at run time
• name matches the allowed characters (name_invalid) and is unique in each layer and across integrations (duplicate_name)
• No key outside the connector's list (unknown_key), which also catches every key removed or deferred in §7.1
• max_tlp is a tlp name (max_tlp_unknown), and every object_types entry is a family (object_type_unknown)
• organisation_uuid, when set, is a canonical UUID (organisation_uuid_invalid)
• No sharing/ configuration directory exists (sharing_directory)

This is configuration validation, not object-schema validation.

Conformance fixtures

Sharing fixtures live in their own tree, fixtures/sharing/valid/ and fixtures/sharing/invalid/, because this repository's checker treats fixtures/invalid/*.yaml as opentide object documents (D-9). scripts/sharing_fixtures.py covers the TOML and JSON sharing fixtures.

Every golden Event JSON is paired with a committed object fixture under fixtures/valid/, and the checker derives the expectation from that fixture instead of trusting a hand-typed constant. Fixtures MUST NOT contain live API keys, real hostnames, or real organisation UUIDs: credentials are ${ENV_VAR} placeholders, hosts are documentation-reserved names, and organisation and Event UUIDs are placeholders. Nothing is copied from local reference material.