USER-ID-1: user identity resolution specification

[JarbasAl]

🤖 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.

What this adds

OVOS-USER-ID-1 — the session fields that carry user identity and
authentication evidence for an utterance, who is allowed to write them,
how authentication strength is expressed and how it expires, and what
skills may assume from it.

Files

• user-id-1.md (new) — the specification.
• session-1.md — §3 roster rows and See-also entry for the eight
  fields claimed here. The claiming mechanic (SESSION-1 §2.2) requires
  the owner to be nameable from the roster, so this PR carries the rows
  rather than deferring them.
• README.md — spec-index row.
• CHANGELOG.md — entries for USER-ID-1 and for the SESSION-1 roster
  addition.

Trust model

The first draft let identity ride in on the wire: fields on the inbound
session were taken at face value, and §5.1 told plugins to preserve
them. That is not a trust model — any participant that can put a Message
on the bus can assert any user_id and any auth_level, and a skill
gating a bank transfer on auth_level >= 5 would honour it. This
revision fixes that.

• §2.1 gate invariant. Identity fields on an inbound Message are
  unauthenticated hints. The recognition plugin — or the bridge, where
  the bridge runs recognition — MUST re-derive and overwrite every
  identity field it can derive, and MUST clear every field it did not
  derive, on every inbound Message from a governed participant. This
  is BRIDGE-1 §4.1's gate invariant applied to identity: a gate, not a
  handshake. The preserve-SHOULD is deleted. Cross-utterance identity
  now comes from the plugin's own state keyed on session_id (§5.3),
  never from what the session asserts.
• §2.2 ownership. The recognition plugin owns the fields and writes
  them at a SESSION-2 §2.6 mutation boundary — normally the
  metadata-transformer hook. The old "stable once written" sentence,
  which contradicted both §5 and SESSION-1, is gone.
• §3.1 decay. auth_level gains authenticated_at. A level of 3 or
  above MUST decay after a deployer-defined TTL to the strongest level
  still derivable. A level was previously immortal for the life of a
  session.
• §3.2 default session. auth_level is capped at 1 on
  session_id: "default". That session is shared by everyone near the
  device and impersonable by any remote participant (SESSION-1 §3.1);
  evidence from one speaker cannot be attributed to the next.
• §5.1 / §5.2 resolution. Conflict resolution used to say "highest
  confidence", but no confidence field exists on the wire. It is now a
  normative order by evidence class: active passphrase > corroborated
  biometrics > single biometric > stated name > configured default. When
  resolved signals name different people, the plugin MUST NOT set
  user_id and MUST set auth_level 0 — the spec does not guess which
  signal is lying.
• §6 bridge limits. A bridge MAY set user_id, default_user_id,
  and an auth_level capped at 1. It MUST NOT set a per-signal field or
  authenticated_at it did not derive from a recognizer it ran — a
  fabricated face_id is indistinguishable downstream from a real one.
  A bridge that does run a recognizer is acting as a recognition plugin
  and is bound by §5 in full.
• §6.1 default_user_id. Deployer configuration, not a wire input.
  The recognition plugin MAY mirror it onto the session; every runtime
  signal outranks it.
• §8 privacy. Per-signal fields SHOULD NOT cross a bridge boundary —
  only user_id and auth_level should be relayed. Ids MUST be opaque
  and per-deployment, and MUST NOT be derived from or usable as
  biometric templates.

Smaller changes

• voice_id → speaker_id throughout. TRANSFORM-1 §3.5 already
  uses voice_id as a context hint naming the synthetic voice for
  TTS; §2 states the distinction in one line.
• Face-recognition liveness drops from SHOULDs to one non-normative
  note. This spec verifies identity, not liveness; a recognizer's
  spoof-resistance is a property of the recognizer, and a deployer who
  cares configures a shorter TTL or requires level 5.
• Per-field deployment defaults in the §2 table, as SESSION-1 §2.2
  item 3 requires of any claiming spec.
• §7.2's threshold table is labelled informative guidance, not
  requirements.
• Re-authentication (§5.4) is restated accurately against CONVERSE-1 §5:
  the handler sets session.response_mode from its own dispatch, the
  prompt carries listen: true, and delivery happens inside the
  pipeline via a front-positioned converse plugin.
• The §8 examples are trimmed to one concise case per scenario, and the
  high-trust example now shows the response_mode mutation and
  listen: true rather than gesturing at them.
• Guest fallback folded into §7.1; See-also entries say what each
  reference is for.

Merge order

Merge after #128 (README restructure) — both touch the spec-index
table, and #128's row edits should land first.

#122 also edits session-1.md. This PR only appends roster rows and
one See-also bullet at the end of the existing lists, so the two should
merge cleanly, but whichever lands second wants a look.

Draft: the trust-model rework changes what implementations must do at
the bridge boundary and wants a read before it leaves draft.

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 37 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: 0b7b00e4-e7e8-4088-831e-0780e0cc14ff

📥 Commits

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

📒 Files selected for processing (4)

• CHANGELOG.md
• README.md
• session-1.md
• user-id-1.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch spec/user-id

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[JarbasAl]

Merge-ready (MERGEABLE, dev merged in). Template conformance: header present, RFC-2119 boilerplate present, sections numbered 1–9, See also section. Fixed: USER-ID-1 was absent from README spec table and CHANGELOG — both added. Cross-references to OVOS-SESSION-1, OVOS-TRANSFORM-1, OVOS-BRIDGE-1 are forward-pointing specs (correct for an in-review spec). Note: after #55 merges, GLOSSARY.md in this branch will need ovos-intent-*.md links updated.