You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Define the bus-protocol contract for user identity resolution: the session fields that carry recognized identity, per-signal enrollment evidence, and authentication strength. Skills use session.auth_level to gate sensitive operations without coupling to any specific recognition technology.
Motivation
OVOS currently has no identity concept at the bus level — every session is anonymous. The user-id codebase implements biometric recognition but with no normative contract for how results flow into the pipeline or how skills consume them. This spec formalizes that contract.
What USER-ID-1 defines
Session fields (all opaque strings, all optional):
user_id — consolidated resolved identity
voice_id, face_id, name_id, passphrase_id — per-signal enrollment record IDs
Face print (out-of-band camera plugin; site_id selects camera; liveness detection SHOULD be employed)
Name declaration ("I am Alice" — utterance transformer, post-STT)
Secret phrase (utterance transformer, post-STT)
Resolution: a user recognition plugin writes the fields it resolves to the session before the utterance enters the pipeline. Implementation is deployer-defined (metadata transformer, standalone service, or combination). Layer-2 bridges may inject all fields directly.
Identity persistence: recognition plugin SHOULD carry identity forward within a session; auth_level may upgrade but SHOULD NOT downgrade without a positive disconfirming signal.
Re-authentication: skills requiring a higher level SHOULD prompt and use CONVERSE-1 response_mode to capture the credential utterance.
Companion changes
ovos-session-1.md — seven new fields added to the §2.1 field registry (user_id, voice_id, face_id, name_id, passphrase_id, default_user_id, auth_level)
Summary
Define the bus-protocol contract for user identity resolution: the session fields that carry recognized identity, per-signal enrollment evidence, and authentication strength. Skills use
session.auth_levelto gate sensitive operations without coupling to any specific recognition technology.Motivation
OVOS currently has no identity concept at the bus level — every session is anonymous. The user-id codebase implements biometric recognition but with no normative contract for how results flow into the pipeline or how skills consume them. This spec formalizes that contract.
What USER-ID-1 defines
Session fields (all opaque strings, all optional):
user_id— consolidated resolved identityvoice_id,face_id,name_id,passphrase_id— per-signal enrollment record IDsdefault_user_id— bridge/deployer-configured fallback identityauth_level— integer 0–5 summarising evidence strengthAuthentication levels:
Four enrolled signal types:
site_idselects camera; liveness detection SHOULD be employed)Resolution: a user recognition plugin writes the fields it resolves to the session before the utterance enters the pipeline. Implementation is deployer-defined (metadata transformer, standalone service, or combination). Layer-2 bridges may inject all fields directly.
Identity persistence: recognition plugin SHOULD carry identity forward within a session;
auth_levelmay upgrade but SHOULD NOT downgrade without a positive disconfirming signal.Re-authentication: skills requiring a higher level SHOULD prompt and use CONVERSE-1
response_modeto capture the credential utterance.Companion changes
ovos-session-1.md— seven new fields added to the §2.1 field registry (user_id,voice_id,face_id,name_id,passphrase_id,default_user_id,auth_level)ovos-audio-in-1.md(PR OVOS-AUDIO-IN-1: Audio Input Service Specification #51) — §4 cross-references USER-ID-1 §3.1 for voice-print as audio-transformer use caseOut of scope
Recognition algorithms, enrollment procedures, credential storage, audio/video acquisition.