# Identity, encryption and trust

Document: SPEC-003. Revision: 0.6 Date: 2026-10-25. Lifecycle: Partially approved under delegated decision D-024; V1 resolution sections are active, later scope remains Draft. Supersedes: none.

## Logical ownership and control traffic (D-227/D-228)

[SPEC-028](028-developer-api.md) reuses instance account/device/session authority across logical servers while checking server-specific ownership and membership for every operation. Logical ownership grants no instance-account administration, and instance ownership grants no implicit logical membership. Global account/device revocation still applies. A signed non-visible flag is presentation metadata; it neither hides content from authorized channel members nor authorizes a bot action. Encrypted inner visibility context must agree with the signed outer envelope.

## Approved video-delivery successor — D-167

D-167/SPEC-024 introduces a separate managed-presentation enforcement profile: authenticated operations, provider track closure/reconciliation and a 30-second conforming-client validity window refreshed every five seconds; it does not promise a provider cutoff during control partition. The existing native relay/microphone three-second lease and four-second hard bound remain active for that adapter. E2EE, approved identity, cryptographic sender authenticity, replay rejection and no plaintext downgrade remain mandatory. Per-fragment signatures are a legacy mechanism; the managed successor uses a separately validated frame-protection profile. See [SPEC-024](024-presentation-delivery.md).


R-015, R-016, R-030, R-036 and R-037 are confirmed. Security mechanisms and defaults below are PROPOSED pending review.

## Direct voice and relay fan-out (D-086)

D-086 and [SPEC-017](017-voice-routing.md) select temporary per-speaker encrypted media with approved-device signatures and ephemeral pairwise key distribution. The relay receives no media secret. Private E2EE direct paths disclose peer network addresses and use conforming-receiver moderation; two modified endpoints cannot be independently disconnected by the host. This explicitly supersedes the relay-only hard-mute guarantee for those paths. All relayed paths retain relay enforcement; SPEC-016 key deadlines, device trust, text and recovery remain.

## Identity and authentication

CONFIRMED D-056/R-074: use `username@domain` as the user-facing account address, independent of display names. Omission of `@domain` means the selected local account service's identity domain. D-057 retains `@sloppyvoice.com` for existing accounts, despite the service hostname `chat.sloppyvoice.com`. The D-058 parsing profile below resolves the previous syntax gap; renaming handles, identity-domain transfers, deleted-name reuse and Unicode usernames remain outside this increment.

### Qualified address parsing (D-058/P-028)

Preserve the V1 local-name grammar `[a-z0-9][a-z0-9_-]{2,31}` after trimming surrounding ASCII whitespace and folding ASCII A–Z to lowercase. Accept a bare local name or exactly one `@` followed by a DNS identity domain. Domains use lowercase ASCII DNS labels, 1–63 characters per label and at most 253 characters total, with letters/digits and internal hyphens; require at least two labels for public discovery, no empty labels, leading/trailing hyphens, trailing dot, port, IP literal or URL path. International domains are entered/displayed as ASCII A-labels; Unicode local names and automatic Unicode domain conversion are deferred. Reject internal whitespace, controls, multiple `@`, empty parts and values beyond these limits. Local loopback `localhost` remains an explicit development exception, not a public identity-discovery target.

An omitted domain comes from the chosen, verified home account service before login, or the active account after login. Do not derive it from the page's hostname or the room host. Show the full canonical address in account, member and administration views so equal local names on different domains remain distinguishable. Optional display names never establish identity. `Saxon@SLOPPYVOICE.COM` and `saxon` on this installation resolve to `saxon@sloppyvoice.com`; `saxon@chat.sloppyvoice.com` is a different, presently unsupported identity, not an alias.

Normalize before lookup and before producing an authentication proof. Keep canonical local username and domain as separate wire/storage fields under SPEC-009; the displayed address is their composition, not a new account UUID or password key. A same-domain suffix may be removed only after verifying equality with the chosen service's domain. A foreign suffix returns a clear unsupported-home-domain error in the closed alpha, before login submission or invitation consumption; do not silently strip it, auto-register a local namesake or send credentials elsewhere. Future remote account selection uses SPEC-010's authenticated discovery and explicit selection, without enabling foreign-room federation.

Invitation username input follows the same parser, requires the connected identity domain, and binds the canonical local name and existing purpose/domain context. The raw-key/full-URL workflow in D-052 remains. Displaying a qualified name never changes roles, keys, device approval or history eligibility. Persist references by stable account UUID within their canonical domain; passwords do not identify an account.

Separate account login, server federation credentials, device authentication, and content-encryption keys. An operator changing a password must not silently gain access to the user's encrypted history. A server's statement that an account exists is not proof that a new device is a trusted encryption endpoint.

Proposed account functions: device list, session revocation, device approval, login recovery, optional recovery key, and local OS-protected key storage. CONFIRMED D-021: V1 uses administrator-issued account invitations and passwords chosen by testers. Passkeys, corporate SSO and any MFA requirement remain later/open choices. D-020 limits V1 to one active device per account; multi-device use follows later. This is a stage restriction, not a single-device assumption in protocol identifiers or cryptography. Proposed admission behaviour rejects a second active device without silently evicting the first; an explicit revocation/replacement flow must be specified before device replacement is implemented. An expired transport session is not proof that its encryption identity has been revoked.

Proposed V1 invitation flow: an authorised administrator issues an expiring, revocable, single-use account invitation; the tester establishes their password over authenticated transport and claims the intended account under the selected binding rules. Account invitations and room invitations are different purposes and must not be interchangeable. Never send a chosen password to the inviting administrator or log it; store only the selected password-verifier representation. Password hashing parameters, rate limits, reset flow, invitation recipient binding and device approval are OPEN implementation prerequisites, not unspecified choices to make while coding. The protocol must preserve a future scoped noninteractive authentication path without requiring a human password challenge for every account action.

CONFIRMED D-022: V1 provides no content-history recovery mechanism after loss of the only device or its keys. Account/login recovery is separate and must explicitly explain that old encrypted history remains unreadable. A replacement device needs a new trusted encryption identity and admission to future epochs; an administrator password reset cannot grant past keys. A later recovery specification must define user-held secrets, backups, trust and membership-period eligibility before enabling history recovery. D-023 permits retrieval of earlier eligible ciphertext on re-admission only; it does not manufacture missing decryption keys.

Foreign authentication claims must be verifiable, audience-bound, short-lived, replay-resistant, and scoped to the target operation. A home domain may attest only identities it controls. The chosen protocol must define clock skew, rotation, expiry, and session revocation. Never send a user's reusable home-domain credential to a foreign host.

## Threat model

D-081/D-082 and [SPEC-016](016-key-lifetimes.md) select temporary authenticated E2EE voice keys, replacing this document's static-device encryption only for that successor voice profile. Stable device signing identity, text encryption, recovery and existing retained history remain unchanged. Voice key retirement does not establish forward secrecy for archived text or recovery copies. The static-key statements below remain applicable to legacy calls and current text.

Protect against network observers, unauthorised accounts, malicious foreign domains, replay, stolen credentials, unauthorised media subscribers, and disclosure from ciphertext stores. E2EE direct communication must also protect content from honest-but-curious transport and hosting operators.

Active server attacks require authenticated device keys, visible key changes, and a verification policy. A compromised directory can otherwise substitute keys or add devices. Out-of-band device verification and possibly key transparency are candidates; the first-contact trust model remains Q-11. Do not promise protection from malicious key substitution without specifying how it is detected or prevented.

Endpoint compromise, an authorised participant recording or forwarding content, traffic analysis, and denial of service are not solved by E2EE. Domain services still learn necessary routing metadata, which may include account identifiers, memberships, timing, IP addresses, and traffic volume. Minimise and document this metadata.

## Direct communication

Direct messages and direct voice calls MUST use E2EE, including communication within one domain. No administrator option may disable it. If attachments, thumbnails, reactions, edits, or direct screen sharing are supported, treat their private content as part of the same confidentiality boundary.

Proposed security requirements:

- Encrypt content on an authorised sender device and decrypt only on authorised recipient devices.
- Authenticate senders, recipients, devices, conversation context, and call membership.
- Use an established, reviewed protocol and implementation. Do not design new cryptographic primitives.
- Define forward secrecy, post-compromise recovery, replay protection, key rotation, membership changes, offline delivery, and encrypted history backup explicitly.
- Never silently downgrade because a peer, media provider, or client lacks E2EE support. Fail with an actionable explanation.
- Make encryption status and unverified/key-changed devices visible before sending sensitive content.
- Avoid plaintext content in server logs, push payloads, analytics, crash reports, and link-preview fetches.

MLS is a candidate for asynchronous group/device key establishment, including groups with two members. It is not a complete application identity, storage, or recovery design. [RFC 9420](https://www.rfc-editor.org/info/rfc9420/), [RFC 9750](https://www.rfc-editor.org/info/rfc9750/).

WebRTC transport encryption alone does not establish E2EE through a media service that terminates transport security. Evaluate authenticated frame encryption such as SFrame together with a defined key-management profile. SFrame is designed to let an SFU route without reading media content. [RFC 9605](https://www.rfc-editor.org/rfc/rfc9605.html).

## Configurable room encryption

D-002 accepts configurable room encryption. Proposed modes:

| Mode | Content access | Available service behaviour |
| --- | --- | --- |
| End-to-end encrypted | Authorised participant devices and explicitly admitted bot devices | Server routing and access enforcement; content search/recording requires a participating endpoint |
| Server-readable | Authorised participants plus the hosting/processing services | Server search, content moderation and optional recording can be implemented under disclosed policy |

Both modes require authenticated encrypted network transport. Encryption at rest is an additional storage control, not a substitute for E2EE. The exact propagation of server-readable text through foreign home domains depends on Q-09 and must be disclosed.

CONFIRMED D-008/D-018: private rooms default to E2EE and public rooms to server-readable content; the creator may explicitly choose either mode at creation. The selected mode stays fixed for the lifetime of that room. Public/private access bundles are defined in SPEC-001 and do not override this explicit choice. Record the effective mode once; never recompute it from later defaults or access policy. Proposed for the first release: bind room content modalities to one declared security mode to avoid text and media silently having different protections. The same mode does not imply identical text and live-media key recipients.

Under D-018, an in-place security-mode change is rejected. A different mode requires a different room; P-003 proposes an explicit replacement-room invitation workflow. It does not authorise automatic membership or history migration. Never decrypt old history into a server-readable destination automatically. Changing this fixed-mode requirement would require an explicit superseding human decision.

### Membership and encryption transitions

The following state contract is PROPOSED, incorporating review RV-02. The host owns persistent membership, policy and live-session admission; trusted participant devices own content-key operations. A device must satisfy both server admission and the selected device-trust contract. Ciphertext delivery permission alone does not establish cryptographic membership.

| Transition | Persistent membership and history | Live media and key effect |
| --- | --- | --- |
| Admit a new room member | Commit an admission position; V1 text eligibility starts there under D-016 | Admit only trusted devices to a new text epoch; do not distribute pre-admission history keys |
| Re-admit a former room member | Open another interval; allow retained history from earlier membership periods plus the new period, excluding absences under D-023 | Establish current group membership without absence-period keys; earlier eligible ciphertext still requires previously retained keys or a future approved recovery mechanism |
| Join a live session | Preserve existing room membership/history boundary | Authorise attendance, establish the device's live-media key membership and current forwarding lease before media exchange |
| Leave or expire live attendance | Preserve persistent room membership | Stop that attendance's forwarding; exclude the departing device from future live-media keys; do not rekey text solely for leaving voice |
| Lose transport connectivity | Preserve persistent room membership; resume eligible text later | Never infer indefinite attendance from a stale socket. Reconcile before the finite attendance/forwarding leases expire; after expiry require fresh live admission and valid keys |
| Remove/ban a member or leave the persistent room | Commit removal; deny new host history delivery according to SPEC-006 | Revoke affected grants and remove the member's devices from future text and live-media epochs |
| Revoke a device | Preserve the account's membership for other authorised devices, where supported | Remove that device from every affected key group and media lease; do not equate account login recovery with device approval |
| Replace or add a trusted device | Apply the stage's device-count limit and explicit trust flow | Define history transfer separately; no old keys arrive merely because the home domain accepted a login |

Only devices admitted to a live session receive its media keys; persistent room membership alone is insufficient. Text and live media have separately scoped recipient membership even if the selected suite shares machinery. A reconnect within a still-valid attendance lease may resume only after current authorisation is checked; it never resumes a held PTT press automatically.

The selected protocol must specify epoch coordinator selection, authenticated membership commits, concurrent joins/removals, ordering against host admission/removal positions, acknowledgements, retransmission, and crash recovery. Once a conforming publisher learns of removal, it closes affected publication under the old epoch. Publication resumes only when authorised remaining endpoints have established a valid replacement epoch under that contract; failure to rekey pauses the affected encrypted communication. Deny stale-epoch new publications after the defined cutoff; handle already accepted older content separately. Re-authorise offline queued content and re-encrypt or reject it under the current epoch rules before admission as a new event.

For live media, authoritative removal acceptance and effective exclusion are distinct events under SPEC-008. An endpoint may not yet have received the removal, so do not promise an instantaneous privacy cutoff at the database commit. The approved protocol/adapter contract must bound the transition, stop old forwarding by the enforcement cutoff, and exclude removed devices from every replacement epoch. The hard continuation limit and tests cover this interval; already delivered media cannot be recalled. Persistent text acceptance uses host ordering to reject new events under an obsolete authorisation/epoch state.

Revocation cannot erase earlier plaintext or keys from a recipient. The future-key exclusion promise assumes conforming remaining endpoints and does not prevent an authorised participant deliberately forwarding content or keys. Rekeying requires neither server-held content keys nor silent downgrade.

## Bots and administration

CONFIRMED D-017: preserve automated participants through ordinary domain accounts and authorised protocol actions. Authentication/action execution does not require a bot classification. Whether optional classification is profile metadata or a distinct account type remains OPEN; neither representation is selected. No privilege or decryption entitlement follows merely from a label. Do not make interactive challenges a prerequisite for every authorised account action; scoped noninteractive authentication needs a supported path when implemented.

An administrative bot receives explicit scoped authority, not implicit trust because it runs on the reference server. Audit the acting identity, authority, target, and outcome. Credentials must be revocable and bounded; detailed provisioning remains deferred under R-017.

A bot that processes E2EE content is an admitted endpoint with access to that content. A server-hosted bot does not create an invisible server decryption entitlement. Private communication with a bot cannot conceal its plaintext from the party operating that bot endpoint; the UI should disclose the participant, not claim otherwise.

## Federation and abuse boundaries

Authenticate server requests, bind signatures/tokens to their intended destination and payload, reject replays, rotate keys, and validate discovery endpoints. Prevent discovery/fetch functions from becoming arbitrary access to private network addresses; deployments requiring private federation need an explicit allow policy.

Blocking, invitations, request limits, domain allow/deny policy, and resource quotas remain enforceable without plaintext access. Reports about encrypted content require a participant to choose what to disclose; automated server scanning cannot inspect content the server cannot decrypt.

## Linked-device successor (D-044/D-045/D-059/D-060)

D-044 confirms one account across KDE, Windows and web; D-045 selects a separate recovery key after loss of every approved device. SPEC-011 selects the P-024 implementation profile under D-059/D-060. It supersedes the single-device/no-recovery restrictions in SPEC-009 and the older V1 sections, while preserving their primitives and already-lost-key limitations.

Keep the stable account ID, password and server-owned permissions. Give each installation or browser profile its own encryption/signing keys, revocable device identity and device-bound sessions. A fresh browser profile or cleared key store is a new device. Never clone an existing device's private signing key, full vault or session token to make another client appear to be the same device.

Linking under SPEC-011: legacy manual linking uses password authentication to open only a restricted, expiring link request. D-171 adds QR linking without password entry: possession of the QR exchange secret binds the new keys, and explicit signed approval by an existing device remains mandatory. The new device proves possession of fresh keys. Any currently approved device may explicitly approve that exact account/domain, request, new-key fingerprint and current device-roster revision after verification of the copied code and explicit approval. The protocol needs authenticated approval evidence that other devices verify; a server directory entry or readable device name alone is insufficient. Recheck both devices and the request at commit, consume it once, and reject stale/replayed/substituted approvals. An offline approved device retains its place in future text recipient sets; it need not remain online to permit another already-approved device to log in.

Recovery under SPEC-011: create a high-entropy user-held recovery secret, separate from the account password and routine device keys. Cloud services store only encrypted recovery material and public verification/encryption information. The raw secret and content keys stay on endpoints. Password-only login or an administrator reset cannot decrypt history or approve a replacement encryption device. D-060 requires the normal account password plus the recovery key. Forgotten-password reset is outside this flow. The owner is recoverable through the same cryptographic proof without an operator bypass.

A successful all-devices-lost recovery creates a fresh device, revokes previous devices/sessions and active voice, and uses current account permissions. It does not replay roles or membership from the backup. SPEC-011 consumes the recovery authority on successful restoration, retains its decryption key only in the restored protected vault, and requires saving a fresh key before recovery is ready again. Its signed roster chain and durable pending completion define ordering and interruption handling. Replacing a still-active recovery authority for suspected compromise remains future work. Ordinary linked devices should be able to add encrypted backup data without holding the private secret that authorises disaster recovery.

Revocation removes the device from future ciphertext recipients and cancels its sessions, pending links and media grants. Password changes are not encryption-key rotation. Existing copies cannot be erased remotely. History transfer and recovery eligibility are owned by SPEC-006; the protocol must not weaken those boundaries. Existing V1 static-key/TOFU and browser-origin limitations remain disclosed until a reviewed successor proves a stronger property. See the [review and migration gates](reviews/2026-10-18-linked-devices.md).

## Configuration

### Signed account login sessions (D-102/D-103)

R-108 selects an owner-controlled home-server policy, captured on successful sign-in or explicit password reauthentication. Activity does not extend it. D-103 selects the signed-token and bounded handover design reviewed in [the login-session review](reviews/2026-10-21-login-sessions.md). This section supersedes the earlier V1 opaque-token/12-hour rule for **new local account sessions**; legacy opaque sessions keep their original deadlines. Foreign visitor sessions and media, delegation, command, challenge and recovery lifetimes keep their independent contracts.

| Property | Classification, scope and type | Default | Validation and precedence |
| --- | --- | --- | --- |
| `loginSessionDays` | Administrative policy; home server; positive whole days or null | 30 | Null means Unlimited. Reject zero, negatives, fractions, strings, booleans and values above 100,000,000 or producing an absolute expiry beyond the supported Date range (8,640,000,000,000,000 ms). Owner-only revision-checked policy patch; omission preserves the value. No channel, account or device override. |

Finite expiry is issuance time plus the captured duration. Unlimited has no scheduled expiry. Existing finite/unlimited deadlines survive policy edits and migration unchanged. A client receives effective expiry and server time; server enforcement is independent of local clocks. Logout, account disablement, device revocation and current permissions apply equally to unlimited sessions.

Fixed protocol profile: compact JWS/JWT, dedicated asymmetric Ed25519 login key, `alg: Ed25519`, `typ: sloppy-login+jwt`, UUID `kid`, at most 4096 ASCII bytes and exactly three unpadded base64url segments. Reject duplicate JSON members, unknown header/claim fields, unsupported algorithms/types and token-supplied keys/URLs. Trusted public keys come only from the selected service's HTTPS `/api/login-keys` resource (loopback development excepted); never derive issuer trust from a token. Pinned `jose` 6.2.13 implements signing/verification using WebCrypto. Content/device keys and media/command HMAC secrets are independent.

The signed claims are exactly `iss` (canonical home service URL), `aud` (exact server UUID), `sub` (account UUID), `device_id` (approved device UUID), `jti` (fresh token UUID), `sid` (session-family UUID retained across early renewals), `iat` (nonnegative integer UTC epoch seconds), and either finite `exp` or `unlimited: true`. A finite `exp` must be an integer later than `iat` and within the supported Date range. Unlimited omits `exp`; missing/ambiguous expiry fails. Future `iat` and `now >= exp` fail, with no server grace. Names, roles, passwords and encryption secrets are excluded. Tokens are signed, readable bearer credentials; signatures do not provide confidentiality or replace current authorization.

Every authenticated request verifies signature, fixed profile, issuer, audience and time, then an active registry entry indexed by the token's hash whose immutable claims/account/device match exactly. Require an enabled account and currently approved device. A mathematically valid signature with a missing, revoked, expired or inconsistent registry entry grants nothing. Legacy opaque 32-byte tokens still require their existing finite registry deadline; no unsigned unlimited fallback exists.

The durable server-only key ring is separate from content keys and survives restart. It holds at most 16 trusted public keys and one active private key. Rotation creates a fresh key for new issuance, retains older verification keys, and erases retired private material. Owner-only revision-checked rotation/revocation is defined by SPEC-009. Revoking a non-active key removes its registry entries and all currently associated handover families. Rotate first to revoke the active key. Public endpoints, logs and source never include private signing material.

Early renewal requires the current valid home session, password, and fresh one-use device-signed `session-renew` challenge. Revalidate session, password verifier, account and approved device after asynchronous work. Prepare a fresh signed credential with the current policy, one candidate per original session, restricted to activation for five minutes. The original keeps its deadline until device-signed activation. Activation rechecks the original is still valid; then retires it at the earlier of its original expiry or 30 seconds after activation. A retiring token cannot renew again. Activation is idempotent while the new session is valid. Logout revokes all credentials for that approved device, including candidates/retiring entries, without signing other devices out. Renewal does not recreate voice attendance, change content keys or reset room state. These bounds are protocol rules, not configurable extra lifetime.

For D-055/D-058 room creation, `encryption` is `e2ee` or `server_readable`; omission resolves once from D-008/D-018's private/public default. Null or unknown modes fail. The owner supplies the explicit choice at creation, the server stores it immutably, and all enabled room modalities use that mode. Switching the access control in an unsaved form supplies its default only until the creator makes an explicit encryption choice. No in-place room mode change is allowed.

The D-058/P-028 parser above consists of fixed compatibility rules, with no username-format switch or configurable case sensitivity. `SERVICE_DOMAIN` remains owned by SPEC-002. The active-account/selected-service domain is context, not a user-editable default suffix. Existing V1 storage names remain unchanged; no new password, key or recovery setting is introduced. Discovery URL configuration belongs to SPEC-010.

Logical names are PROPOSED. A confirmed default below approves its behaviour, not a wire/configuration spelling. Values marked OPEN must be decided for the relevant authentication/encryption profile before implementation.

| Property | Scope and type | Default and status | Behaviour |
| --- | --- | --- | --- |
| `security.private_room_default` | Domain; encryption mode | `e2ee` — CONFIRMED, D-008 | Applied when creating a private room without an explicit permitted override. |
| `security.public_room_default` | Domain; encryption mode | `server_readable` — CONFIRMED, D-008 | Applied when creating a public room without an explicit permitted override; transport remains encrypted. |
| `room.security_mode` | Room creator; enum `e2ee`, `server_readable`; immutable after creation | Explicit creation choice, otherwise the access-type default — CONFIRMED D-018 | Record the effective mode once and display it; reject in-place updates. Exact creation authorisation follows SPEC-008. |
| `accounts.registration_policy` | Domain; registration/admission policy | `admin_invitation` for V1 — CONFIRMED D-021; other modes OPEN | Only an authorised administrator issues account invitations; account creation does not itself admit the account to a room. |
| `auth.methods` | Domain; set of supported login methods | `{password}` for V1 — CONFIRMED D-021 | Tester chooses the password. Other methods need an approved profile; none may alter content-key ownership. |
| `auth.mfa_policy` | Domain; approved MFA requirement policy | OPEN — not selected | MFA scope and bootstrap/recovery integration must be resolved before authentication implementation. |
| `auth.login_session_lifetime_seconds` | Home domain; positive integer seconds | OPEN — not selected | Maximum local login-session lifetime; renewal/revocation are separate from foreign claims. Replaces overloaded draft `auth.session_lifetime_seconds`. |
| `auth.foreign_session_lifetime_seconds` | Room-host domain; positive integer seconds | OPEN — not selected | Maximum host session based on foreign authentication; define renewal and home-domain outage behaviour independently of local login. |
| `auth.federation_token_lifetime_seconds` | Domain/profile; positive duration in seconds | OPEN — not selected | Bounds identity assertion validity at a foreign host. |
| `auth.clock_skew_seconds`, `auth.replay_window_seconds` | Domain/profile; bounded durations in seconds | OPEN — not selected | Accepted timestamp skew and replay-detection retention; values must be compatible with token validity. |
| `media.grant_lifetime_seconds` | Room-host domain; positive integer seconds | OPEN — not selected | Admission credential validity; expiry at setup alone does not terminate an established stream. |
| `media.forwarding_lease_seconds` | Room-host/media contract; positive integer seconds | OPEN — hard maximum not selected | Maximum active forwarding authority before renewal from current host policy; enforced on already established paths even during control loss. |
| `security.device_approval_policy`, `security.first_contact_trust_policy` | Account/domain policy; trust rules | OPEN — not selected, Q-11 | Determines new-device admission and first-contact verification. |
| `security.history_recovery_mode` | Account/profile; recovery strategy | `none` for V1 — CONFIRMED D-022; later mode OPEN | No V1 recovery of old encrypted history after content-key loss; login reset is not a content recovery path. |
| `security.key_rotation_policy` | Protocol/account; rotation triggers and intervals | OPEN — not selected | Includes periodic and membership/device-change rotation; no interval may disable required removal rekeying. |
| `security.federation_private_network_allowlist` | Operator; approved network destinations | Empty — PROPOSED | Makes exceptions to private-network discovery restrictions explicit. |
| `security.server_signing_key_ref` | Deployment; protected key reference | Required — no default, PROPOSED | References the server identity key; generation and bootstrap are not yet selected. |

Mandatory direct-message/direct-call E2EE, absence of silent downgrade, and absence of administrator plaintext-key access are fixed requirements, not disable switches. Credentials, encryption keys, and recovery secrets have no example/default secret values. Federation admission mode is owned by [SPEC-002](002-architecture.md#configuration); ciphertext/backup retention by [SPEC-006](006-operations-data.md#configuration).

The selected cryptographic profile, group/epoch identifiers, trusted-device records and negotiated results are protocol declarations or security state, not arbitrary algorithm settings. Their schemas and initialisation remain OPEN under the versioned profile; the former draft `security.crypto_profile` configuration row is replaced by this requirement. The original one-device stage restriction is superseded by SPEC-011, not an operator switch.

### Selected linked-device configuration

SPEC-011 is the canonical fixed profile inventory for device counts, proof-history limits, link/recovery lifetimes, rates, codes and roster formats under D-059/D-060. These are not operator-selectable algorithms or new runtime environment variables. It replaces the draft `devices.*` and `recovery.challenge_*` setting proposals for this alpha. SPEC-006 owns content eligibility/retention and refers to SPEC-011 for transfer bounds. SPEC-005 owns local storage and input settings.

### Selected V1 security profile (D-024/D-026)

SPEC-009 and this section supersede OPEN/proposed V1 authentication, device, encryption and lifetime entries above. Use libsodium `crypto_box_easy` (X25519/XSalsa20-Poly1305) independently for each recipient, with a fresh random 24-byte nonce per envelope. Sign text envelopes and login/device proofs with Ed25519. The client binds identity, room, message/session, recipient and revision inside authenticated ciphertext. Servers receive only public keys, ciphertext and routing metadata. No custom primitive or server-held content key is introduced.

V1 uses static device keys and does not claim forward secrecy or post-compromise security. Compromise of a device private key can expose retained ciphertext addressed to it. First contact uses visible trust-on-first-use with fingerprints; a changed key blocks sending/playback until explicitly accepted after comparison. Initial directory substitution is not prevented without out-of-band fingerprint verification. The browser trusts its executable origin. These are explicit selected threat-model boundaries, not claims of malicious-origin resistance. A future ratcheting/MLS profile needs migration and its own approval.

Per-recipient encryption replaces the proposed group-epoch coordinator for V1: accepted text recipient sets equal persistent admitted devices; live audio recipient sets contain only admitted active voice devices. Every membership/device change advances the host revision. Text with stale recipients fails; media closes on revision changes and requires a fresh press. A removed device has no ciphertext addressed to it after the cutoff. Rejoining supplies neither absence-period ciphertext nor lost old keys. Retained device keys decrypt only earlier eligible per-device envelopes.

Password verification uses Argon2id v19, memory 19456 KiB, two passes, parallelism one, 16-byte random salt and 32-byte output. Passwords are 15–128 Unicode code points and at most 512 UTF-8 bytes, without composition rules or silent truncation. V1 has no MFA; login additionally requires registered-device signing-key possession. No password is logged or returned to an administrator. Five login attempts per account and twenty per peer per minute are allowed; excess attempts fail before hashing. These are fixed V1 security-profile values, not permissive operator switches.

Superseded for new local sign-ins by D-103 above: legacy/visitor sessions last 43200 seconds and store hashed 32-byte opaque tokens at the host. Existing legacy deadlines remain valid until expiry or revocation. Challenges last 60 seconds and are single-use. One registered active device is permitted; an ordinary login never evicts or adds another device. Owner-authorised reset/replacement revokes sessions and live attendance and requires a purpose-bound invitation. It does not recover old keys. V1 has no owner recovery or backup restore endpoint.

Media admission and continued forwarding share a maximum 3000 ms lease, renewed each 1000 ms while authorised. The relay validates issuance with at most 250 ms future skew and checks expiry on every packet for both endpoints. A 4000 ms hard revocation bound includes skew and processing margin; deployment clocks must be synchronised within 250 ms. Client-side shutdown is additional protection, not proof of relay enforcement. SPEC-008 owns operation outcomes. The lease/signature profile is fixed, not a disableable setting.

Browser device material is encrypted at rest using a generated nonextractable AES-GCM key persisted in IndexedDB; this does not defend against malicious code on the same origin. Desktop material uses Electron's OS-backed safeStorage and fails closed if a secure backend is unavailable. No plaintext preferences fallback is permitted. Tokens and private keys are never included in exported diagnostics. Credentials are scoped to the configured service origin.

### Selected Cloudflare alpha behavior (D-043)

D-043 adds a UUID media generation to Cloudflare-mode grants. Both gateway and native relay reject a grant for a different generation; direct mode omits the field. Revocation retains its separate purpose and monotonically advances room revision across the active generation. TURN credentials establish reachability only; per-packet sender and recipient leases remain required. The internal process-identity contract in SPEC-002 additionally rejects requests addressed to a previous native process, even if Container state and environment survive a fast restart. A prepared attempt is bound to the current authenticated account/device and expires or cancels without live voice admission. Authorisation is checked again after provider waits and before returning credentials or joining.

## Testing

D-171 QR trust coverage follows SPEC-011: wrong optical secret/service/key, forged offer, revoked approver, replay/expiry/cancellation and unsigned roster/bootstrap evidence cannot admit a device. Password-free QR submission remains restricted until explicit signed approval; password-plus-key recovery is a separate unchanged contract.

For the managed presentation trial, SPEC-025 owns the exact `sfu-frame/1` authenticated encoded-frame format. Validate ephemeral-key confidentiality, approved-device Ed25519 sender verification, authenticated context/prefix/counter/ciphertext, replay rejection, original key expiry and fail-closed worker output in Chromium and Firefox through the actual SFU. Transport DTLS and a shared media secret alone do not replace sender authentication.

D-103 login units cover finite/unlimited defaults and bounds, exact warning timing, signature and claim/header validation (including duplicate fields), independent Ed25519 interoperability, immutable registry matching, key rotation/revocation, schema migration, expiry/restart/pruning and handover failure/replay boundaries. Service tests cover current password/device authority, owner-only revisions, voice/ticket continuity and family-wide logout. Browser and real workerd checks are integration evidence, separately from these units.

For P-028, unit-test bare/qualified/case-folded addresses, whitespace and length boundaries, invalid DNS labels and Unicode/control characters, foreign suffix rejection before credential dispatch, and canonical invitation-name comparison. Equal local names on different domains must remain distinct. Regression fixtures preserve existing UUIDs, sessions, password verifiers, keys, role records and encrypted history byte-for-byte; parsing changes must not re-register or reset an account. Discovery transport checks are owned by SPEC-010.

For SPEC-011, unit-test restricted pending-device access; fresh-key possession; approval signer revocation; cross-account/domain request substitution; duplicate, expired and concurrent approvals; roster rollback; device-specific session revocation; and future-recipient exclusion. Recovery units must reject wrong/replayed secrets or proofs, corrupted/old-generation bundles and stale authority; exercise interrupted rotation and loss of all devices. Verify password-only and administrator paths cannot unwrap content. The alpha.6 release report distinguishes automated evidence from remaining physical acceptance.

Unit tests for identity, authorisation claims, device state, and encryption integration should cover:

- Identifier canonicalisation and domain separation, including confusable/display names that must not change the authenticated account identity.
- Token/signature verification with valid and invalid signatures, wrong audience/domain, tampered payload, replay, expiry, and time boundaries using a fake clock.
- Room-security default resolution for public/private creation, explicit authorised overrides, rejected unauthorised overrides, and rejection of every attempt to disable direct E2EE.
- Chosen cryptographic profile integration against published test vectors; wrong keys, modified ciphertext/associated data, repeated messages, unsupported suites, and incorrect membership epochs fail without exposing plaintext.
- New-device approval, key-change warnings, device removal and future-key exclusion; account password recovery alone does not grant old content keys.
- Only authorised participant/device identities are added to an encrypted conversation; ordinary automated accounts gain no implicit content access. If optional bot classification is later implemented, marked and unmarked accounts use the same permission checks.
- Serialization, logging, push notifications, attachment metadata and error paths exclude plaintext content and secret material using fixed test-only sensitive markers.
- Recovery and key-rotation transitions once selected, including failure during backup, stale devices, duplicate removal, and attempts to restore a revoked device.
- Distinct persistent/live/device state transitions; room members outside a live session receive no live-media keys; leaving voice preserves text membership; concurrent removals and failed rekeys pause affected publication rather than continuing an obsolete epoch.
- Admission-token expiry versus active-lease expiry, independent local/foreign session lifetimes, one-active-device enforcement and explicit replacement; stale transport or home login state cannot authorise a new encryption device.
- Account-invitation issuance, purpose/recipient binding, single-use claims, expiry/revocation and concurrent redemption; chosen passwords never appear in admin responses/logs and verifier parameters match the selected authentication profile.
- V1 key loss and login reset leave prior encrypted history unreadable; re-admission excludes absence-period keys while permitting already-keyed earlier eligible history.

Mock transport/storage and use test keys. Unit tests do not establish endpoint safety, malicious-server resistance, or a complete cryptographic audit; those need the separate threat-model and end-to-end checks.

## Acceptance criteria

- D-171: a scanned QR without explicit approval cannot create account, history or media authority; both directions validate exact new keys/service and signed roster/bootstrap evidence, while legacy manual linking and password-plus-key recovery remain usable.

- D-103/A-42 passes: signed issuance and strict verification, unchanged existing deadlines, finite/unlimited enforcement, bounded safe early renewal and immediate revocation hold in isolated fixtures.

- Under P-028/A-40, bare and same-domain qualified names select the same existing account; foreign and malformed names cannot consume invitations or submit local login credentials. Fully qualified displays do not alter stored account/device identity, permissions or history.

- For the linked-device successor, pass A-33/A-34/A-35: independent approved keys, common account authority, encrypted history/recovery and current revocation must hold across KDE, Windows and web; password possession alone cannot admit a new encryption device. These are pending feature gates, not claims about V1.

- Create private and public rooms without explicit security overrides and observe E2EE and server-readable mode respectively, with each mode shown to participants. See A-16.
- Explicitly choose the opposite room mode at creation, observe that choice, then attempt an in-place mode change and receive rejection; later default changes cannot alter existing rooms. See A-16.
- With an encrypted-room member outside the live session, exchange media between admitted devices and verify the non-attendee receives no media keys. Leave voice without losing text membership; remove a member during publication and verify the approved epoch cutoff and fail-closed rekey behaviour. See A-28.
- Exchange direct messages and make direct calls both locally and across domains; relay/storage inspection with only server-held secrets cannot decrypt content. Record the selected suite and key-exchange validation, not only packet opacity. See A-05.
- Attempt a direct-communication downgrade from both a modified client and an incompatible server; communication is refused with an explicit error rather than sent in plaintext.
- Remove an account device or room participant and demonstrate rejection of new access plus exclusion from future content keys under the approved membership-change contract.
- Substitute a device key or add an unauthorised device through a malicious-directory test and observe the warning/rejection defined by the approved trust model; do not claim a stronger property than the selected model provides.
- Recover an account login without its user-held recovery material and verify that encrypted history is not silently exposed to the administrator or newly logged-in device.
- In V1, redeem an administrator-issued invitation, choose a password and sign in; reject reused, expired and wrong-purpose invitations. Attempt a second active device, then the approved explicit replacement flow; lost historical keys remain unavailable after login reset. See A-32.
- Admit a content-processing bot only as an authorised, visible participant endpoint; its operator cannot obtain unrelated conversation plaintext through server privilege alone.
- Scan the defined server logging, notification, and storage outputs from these tests and find no private-content/secret markers outside the explicitly authorised endpoint or disclosed server-readable mode.