Passkeys, multi-factor authentication, and security settings

A small set of changes could let someone who has stolen a session keep the account after the session ends:

Each of these asks for one fresh check when the person saves it, in place, not a separate sign-in page. The check is a passkey assertion or an authenticator code; an account without MFA enters its password; an account that signs in only through a deployment OpenID Connect provider re-authenticates there with RFD 15's prompt=login and max_age rules. An organization-owned provider alone never authorizes an account-wide credential or identity change. A passing check covers that one change and any other on this list within the next five minutes, and nothing else.

An account with no enrolled MFA and no password uses a fresh email challenge to set its first password or add its first factor. The challenge is bound to that purpose, browser, and session, expires after five minutes, and authorizes no other account change. Renga delivers it to the account’s current email address; an identity provider’s email claim cannot satisfy it. Email never substitutes for an enrolled factor.

RFD 15's references to sudo mode mean this re-check.

These are not settings, because without them a feature is unsafe or access cannot end:

Terminals and VM operations themselves are also organization settings, off by default, as RFDs 13 and 14 define.

An organization owner may require MFA. A member can then open that organization only with a session whose sign-in used a second factor:

A member whose session does not qualify is asked for their passkey or authenticator code in place, without signing out, and a member without either is sent to enroll one first. Their other organizations are unaffected. So a member who signs in through a provider that is not marked adds a passkey to their Renga account once and confirms it after each provider sign-in.

Each identity provider has an enforces MFA mark, off by default. The operator sets it on deployment providers, and an organization owner sets it on the organization’s own providers; an owner cannot mark a deployment provider, because other organizations share it. The mark says the provider asks every person who signs in through it for a second factor, as a company’s own identity provider usually does, and setting or removing it is recorded in Activity. A github provider cannot be marked, because GitHub’s OAuth API says nothing about how the person signed in.

An organization provider’s mark satisfies only its owning organization’s MFA requirement. Only an operator-marked deployment provider can satisfy the requirement across organizations. The session keeps the provider ID, whether it is deployment- or organization-owned, and its owning organization as MFA evidence; Renga evaluates that evidence for the organization being opened rather than flattening it into an account-wide MFA flag.

When a marked provider’s ID token carries an amr claim, the sign-in counts only if amr contains mfa or a combination that the provider’s configuration explicitly approves as independent factors (RFC 8176). Counting methods is not enough: for example, pwd and kba are both knowledge factors. Any other present amr requires Renga’s local second step. Without amr, the mark alone decides. Removing the mark applies at each affected member’s next request, like any setting that adds a requirement.

An assignment that grants an explicit permission may have an expiry or none, like any other assignment. An organization may set a maximum validity, for example 30 days. With a maximum set, every new or renewed grant of an explicit permission must expire within it, and Renga proposes the maximum as the expiry when someone creates one.

Setting or lowering the maximum shortens existing grants that outlive it, so they end at the maximum measured from the moment the setting changed. It never ends a grant immediately, and running sessions continue until their own grant or lease ends.

A deployment’s operator may declare support identities (RFD 22): accounts from one hidden, MFA-enforcing identity provider that exist only to help diagnose problems. Allow support access appears in an organization’s security settings only when the deployment has declared them. It is off by default, and an owner may turn it on indefinitely or until a chosen time, with the description that it is for diagnostic purposes.

While it is on, every support identity holds the built-in read-only support role (RFD 17) in the organization, appears in the members list marked as support, and is recorded in Activity under its own name like any member. Support identities never hold other roles or explicit permissions, so they cannot change inventory, open terminals, operate VMs, export, or change settings.

Turning it off, or the expiry passing, ends the support memberships and their sessions in the organization immediately; this is the one setting whose change does end sessions, because its purpose is to end access. Unlike every other setting in this table, the operator can neither set a default for it nor lock it (RFD 22): the operator decides who its support people are, and only the owners decide whether they may enter.

Recording is on by default, because a recording is the only record of what someone typed on a host. An organization that turns it off still records who opened each session, on which host, when, and for how long, and the session start still says whether the session is recorded. Turning recording off or on applies to sessions that start afterwards. Existing recordings keep their retention.

Changing a security setting requires the organization.manage permission (RFD 17), which only owners hold among the built-in roles. Each change is recorded in Activity with the actor, the before and after values, and a reason. The settings page shows each setting’s current value and who last changed it.

A setting that adds a requirement applies at each member’s next request to the organization; turning it on never signs anyone out or ends a running terminal session.

An operator can set deployment-wide defaults for these settings, and lock any of them to a value for the whole deployment or for one organization (RFD 22), except Allow support access (Support access). A locked setting shows as read-only, marked as set by the deployment, and owners cannot change it.