OVOS-INTENT-4 §3.2: no payload/context skill_id check — a foreign ovos.skill.deregister uninstalls another skill's intents (plus §8.2 lang, §8.1 re-arm)

🤖 Auto-generated by Claude Fable 5.1 (claude-fable-5-1) via Claude Code — NOT human-reviewed. Every claim below marked executed was reproduced by running the named probe against the named commit in a fresh venv; nothing was checked by a human. Verify before acting.

OVOS-INTENT-4 §3.2 (intent-4.md @ dev a57fe0e):

For registration and deregistration, the payload skill_id MUST equal context.skill_id. [...] A consumer — plugin or orchestrator — MUST NOT index or act on one of these messages whose payload skill_id differs from context.skill_id, and MUST log the mismatch at WARN with both values and the rejecting topic. Without this check a skill could register or deregister another skill's intents; ovos.skill.deregister (§8.4) in particular would be a remote uninstall.

§8.2:

Deregistration targets the (skill_id, intent_name, lang) triple [...] If lang is omitted, every language registered for that (skill_id, intent_name) pair is removed.

1. No §3.2 identity check on any spec handler (executed)

handle_register_template, handle_register_entity, handle_deregister_intent, handle_deregister_entity and handle_deregister_skill (padacioso/opm.py, dev e063f0c) read skill_id from message.data only and never read context.skill_id.

Probe: register victim:on (context victim); emit ovos.skill.deregister with data.skill_id=victim and context.skill_id=attacker. Result: every victim intent removed, no WARN. Same with ovos.intent.deregister. A mismatched ovos.intent.register.template is indexed under the attacker-chosen payload id, no WARN. This holds with the bus client's legacy twin disabled, so it is padacioso's own gap, unlike the adapt/padatious/m2v twin issue.

Fix shape: resolve the owner from context.skill_id as adapt and padatious do (_skill_id_from_context), reject with WARN when the payload differs, and apply the same check to the legacy detach_intent handler because the bus client re-emits every spec deregister as a legacy twin carrying the original context.

3. lang is ignored on ovos.intent.deregister (executed)

Register the same intent under en-us and pt-pt, deregister with lang=en-us: both are removed. §8.2 scopes the removal to the triple; only an omitted lang means all languages.

handle_deregister_intent computes the lang list one line after calling __detach_intent(name) without it.

4. Re-registration re-arms a disabled intent

§8.1: "Replacement preserves enabled/disabled state (§8.5)". handle_register_template detaches and re-adds the container entry and the _disabled_intents stash is dropped. This is the same mechanism as #98 and will be fixed by whatever session-scoped disable state replaces the container mutation; noted here so the fix covers it.

Evidence and the probe are in the workspace wiki: knowledge/wiki/audits/spec-adoption-2026-09/sweep-intent4-identity-deregistration.md.

§11 session scoping (same sweep, executed)

OVOS-INTENT-4 §11.3: "A deregistration arriving under the default session removes the "default"-scoped entries only" and §11.2: the default pool is only what was registered under "default". This plugin stores no session_id with a registration: ovos.skill.deregister under session-two removes the default registrations, and a registration under session-two is matched for the default session. §11.4 allows a default-pool-only plugin, but then non-default-session registrations and deregistrations must be ignored, not folded into the default pool. Fix shape: key the index by session (or ignore non-default sessions). Evidence in the sweep report linked above.

Withdrawn: "reject on payload/context mismatch" for the spec registration handlers

The context-authoritative behaviour (WARN with both values, act under context.skill_id, ignore the payload value) is a deliberate, tested design in adapt and padatious (test_register_keyword_differing_payload_uses_context and the tests/test_skill_id_from_context.py family), and MSG-1 forward semantics make the context the reliable attribution. A mismatch is a producer bug worth the warning, not grounds to drop a legitimate registration. This item is withdrawn; do not re-dispatch it. The wording gap between that design and §3.2's "MUST NOT index or act" is a specification question, recorded on the spec side, not a plugin defect. The legacy detach_intent twin bypass (item 1) stands and is unaffected.

Ruling

Miro ruled (2026-09-08) that a registration or deregistration acts on the payload skill_id; context.skill_id is message provenance only, logged on mismatch, never substituted in and never grounds for rejection, so an administrator script can act on a skill's behalf. The spec §3.2 text is to be amended and this engine follows it. The identity-check findings above are superseded: the required behaviour is to read data.skill_id, log a mismatch with both values, and act. The rejection PR opened for this issue is not to be merged.

Start with the handlers in padacioso/opm.py and the legacy detach_intent path, then read knowledge/wiki/audits/spec-adoption-2026-09/sweep-intent4-identity-deregistration.md. Reconcile the withdrawn identity-check findings with the ruling, and verify the remaining language, re-arm, and session-scoping behavior against the documented probes before defining completion.