Skip to content

spec: bridge-1.md — session-identity trust carve-out; internal-topic routing exclusion; gate ordering - #135

Open
JarbasAl wants to merge 1 commit into
devfrom
spec/bridge-1-audit
Open

spec: bridge-1.md — session-identity trust carve-out; internal-topic routing exclusion; gate ordering#135
JarbasAl wants to merge 1 commit into
devfrom
spec/bridge-1-audit

Conversation

@JarbasAl

@JarbasAl JarbasAl commented Aug 4, 2026

Copy link
Copy Markdown
Member

🤖 Auto-generated by Claude Fable 5 (claude-fable-5) via Claude Code — NOT human-reviewed. Verify before acting. Cross-spec citations were model-verified against dev source; behavior-change sections need owner judgment.

Audit fixes for BRIDGE-1, plus two cross-file spillovers (INTENT-4 M7, USER-ID gate invariant).

Trust boundary

  • §3.4.1 session-identity carve-out. The non-inspection rule of relaying mode covered everything in the session, including session_id. That let an external participant assert "default" — the global registration scope (INTENT-4 §11.2) — or a hub-side session_id belonging to another participant, which defeats the reason INTENT-4 §11.1 reads session_id from context in the first place. The rule now separates session content (client-authoritative, untouched) from the session_id trust anchor: a bridge MUST NAT-stamp the identifier it owns for that participant, or reject the Message.
  • §3.2 internal-coordination exclusion. session_id matching is broad enough to catch poll traffic that was never meant to leave the deployment. The converse, common-query, and fallback ping/pong/request families are now excluded from session_id routing; they remain relayable by destination match, which is the satellite-registered-skill case (§4.4).

Hardening surface

  • §3.2 — hardened minimum topic set promoted from MAY (multi-deployment only) to SHOULD for every deployment, managed mode included.
  • §3.2 — the set is now an allowlist of (topic, allowed-signals) pairs. Admitting a topic for destination matching does not admit it for session_id or site_id matching.
  • §4.1.1 — one line disambiguating the capability denylist from the transport topic allowlist. Different axes.

Gate invariant

  • §4.1 ordering MUST — policy re-application completes before bus injection. Asynchronous or inject-then-mutate gates are not conformant; the orchestrator may already have read the session.
  • §4.1 identity fields — identity fields claimed by other specifications are policy fields for this rule; the proposed OVOS-USER-ID-1 user_id / auth_level are named as the current instance.

Spillover

  • §4.4 (INTENT-4 M7) — hub-side session_id for ovos.skill.deregister goes in the message context, never the payload. The payload carries skill_id only.

Behavior changes

  • External assertion of the default session is now forbidden. A bridge that previously relayed a participant-supplied session_id: "default" verbatim must NAT-stamp or reject it. This closes cross-tenant intent-pool pollution: an external participant could otherwise register into, and match against, the global "default" scope.
  • Hardened topic set moves MAY → SHOULD, and internal-coordination topics move from relayable-by-session_id to destination-only. A bridge relying on broad session_id routing to deliver poll traffic must switch to destination.

Conformance §6 updated for all new MUST/SHOULD clauses. CHANGELOG updated.

…routing exclusion; gate ordering

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Aug 4, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@JarbasAl, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 41 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 14be96fb-8420-4428-870a-a725ee4d3026

📥 Commits

Reviewing files that changed from the base of the PR and between 1d3622b and a03d5ae.

📒 Files selected for processing (2)
  • CHANGELOG.md
  • bridge-1.md

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@JarbasAl
JarbasAl marked this pull request as ready for review August 4, 2026 12:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant