AffirmedID Reflex

Executive Summary

AffirmedID Reflex is an installable background service for Windows 10/11, macOS, and Linux that extends the Pulse Continuous Authentication & Identity Assurance framework directly to the user's endpoint. Where the Auth mobile app provides the user-side trust signal and the Pulse PDP provides the cloud analysis engine, Reflex provides device-side presence and local brokering, the component running on the machine the user is actually working on.

Reflex runs as a per-user background process, launched by Windows Task Scheduler at logon, a systemd --user unit, or a macOS LaunchAgent, rather than as a system-wide service running under an elevated service account. This is a deliberate architecture decision: everything Reflex does, resolving the logged-in user, enrolling a federated identity, brokering local AuthZEN requests, runs with exactly the privileges of the person sitting at the machine, never more.

Reflex is an optional component of the Pulse CA framework. Most Pulse CA capabilities operate fully without it. For organizations that need a local, low-latency trust broker for endpoint-side AI agents, or active BLE proximity verification, Reflex is the mechanism that will deliver those capabilities as it matures.

What Reflex Is

Reflex is a multipurpose background service built from nine cooperating components, each mapping to a distinct part of its architecture:

• Per-User Hosting & Device Identity, a background process launched in the user's own session (not a system service account), backed by a local SQLite store and a single device identifier registered once with the Pulse API.
• One-Time Username Enrollment, a native OS dialog racing a headless CLI/loopback fallback to solicit the person's federated email address exactly once per device.
• CA Session Commissioning, a lazy trigger: no Continuous Authentication session exists until the first local AuthZEN request asks for one.
• Headless OIDC & FIDO2 Login Ceremony, Reflex submits the resolved username to a headless OIDC endpoint; the phone-side dual-assertion FIDO2 ceremony and token issuance happen off-device, between the cloud API and the Auth app.
• Cryptographic Session Identifier (SSDI), a per-session, per-agent hash binding local activity to the device identity without registering every short-lived agent connection with the cloud.
• Local AuthZEN Evaluator, a loopback-only HTTP endpoint answering AuthZEN-shaped access-evaluation requests locally, fail-closed until a CA session is authorized.
• Active Proximity Verification (BLE), a Bluetooth Low Energy scanner that detects a session-scoped UUID advertised by the user's Auth mobile app.
• Post-Quantum Channel Security, an ML-KEM (FIPS 203) key exchange establishing the AES-256-GCM session keys that protect Reflex's WSS traffic.

Per-User Hosting and Device Identity

Reflex is launched in the interactive user's own session, Task Scheduler "At log on" on Windows, a systemd --user unit on Linux, a LaunchAgent on macOS, rather than as a SYSTEM/root service account. This means Reflex reads and writes under the user's own profile (%LOCALAPPDATA%\AffirmedID\Reflex on Windows, ~/Library/Application Support/Reflex on macOS, $XDG_DATA_HOME/Reflex or ~/.local/share/Reflex on Linux), holds no elevated privileges, and, correspondingly, resolves whoever is actually logged in rather than a generic service identity.

On first launch, Reflex opens a local, unencrypted SQLite database and, the first time a CA session is commissioned, mints a persistent device identifier, a GUID prefixed s., and registers it with the Pulse API. This is the only identifier Reflex registers with the cloud on an ongoing basis; subsequent launches read the stored identifier rather than re-registering. It is the foundation of session accountability within the Pulse CA framework and the basis for every interaction with other Pulse services.

One-Time Username Enrollment

Reflex operates in a closed loop architecture for security reasons. identity must be actively confirmed by the person physically present. When the system starts whether power ON, restart, or wake after sleep, it was query for active user identity, username: Reflex solicits the person's federated email address through two parallel paths, racing each other, whichever answers first wins:

• Native OS Dialog: a PowerShell InputBox on Windows, an osascript dialog on macOS, zenity falling back to kdialog on Linux, none of which require any additional software install.
• Headless CLI Companion: running Reflex --enroll from any terminal, SSH session, or remote shell prompts for the address with plain console input and posts it to a loopback listener the running Reflex process is already waiting on. This exists specifically for headless deployments, a server reached only over SSH or VPN with no display and no browser ever, where a native dialog has no path forward at all.

The submitted value must be email-formatted; a bare OS account name or a value with no "@" is rejected with specific, immediate feedback. Once accepted, the device identifier and the enrolled username are written to storage together as a single, one-time event; this pairing cannot be repeated or overwritten on that device once set. Every later Reflex startup reads the stored username directly and proceeds to session commissioning without prompting again.

CA Session Commissioning: First Reference, Not Launch

A foundational architecture decision governs Reflex's Continuous Authentication session: no CA session exists before something actually asks Reflex for one. Launching the Reflex process and commissioning a CA session are two different events. The two loopback listeners, the local AuthZEN evaluator, are enabled unconditionally at launch, but they start out as dormant sockets answering "not authorized" to everything. The first local AuthZEN evaluation request, whichever happens first, is what triggers commissioning: username enrollment (or a read of the memorized username) followed by submission to the headless OIDC login ceremony, run in the background so the triggering request is never blocked waiting on a phone-paced ceremony.

This trigger is idempotent and singular. Only the very first reference, across AuthZEN combined, from any caller, starts commissioning; every later reference, from the same agent or a different one, simply attaches to the CA session already underway or already established. Reflex's CA session is one activity that every local consumer shares, not a separate ceremony per agent.

Headless OIDC Login and FIDO2 Ceremony

Reflex participates only at the two ends of the login ceremony it triggers. The chain runs as follows:

1. Reflex submits the resolved username to the headless OIDC endpoint over a dedicated WSS connection.
2. The OIDC provider requests dual assertion of that username's identity from the AffirmedID cloud API.
3. The API dispatches a FIDO2 challenge to the user's enrolled phone via push notification.
4. On the phone, the user verifies a PIN or biometric; the Auth app's FIDO service verifies the relying-party ID.
5. The phone returns the FIDO2 and ID assertions to the API for verification over its own secure channel.
6. The API acknowledges the verified assertions back to the OIDC provider.
7. The OIDC provider issues tokens, or denies the ceremony, back to Reflex.

Steps two through six happen entirely off-device, between the cloud API and the phone; Reflex neither participates in nor waits synchronously on them. Because that round trip is paced by the user tapping their phone rather than a fixed timeout, submitting the username and learning the outcome are two separate calls: RequestSession returns as soon as the request is sent, and the eventual result, tokens issued or denied, arrives later over the same connection and is delivered to whatever consumer registered to receive it.

A dropped or failed connection during this ceremony is itself surfaced as a denial, with the error as the reason, rather than leaving a caller waiting indefinitely.

Cryptographic Session Identifier (SSDI)

Once a session is established, Reflex derives a Reflex Session Device Identifier, an ephemeral, per-session cryptographic identity distinct from the persistent device identifier. It is a SHA-256 hash of the device identifier concatenated with the session identifier. Anchoring the SSDI to the registered device identifier, rather than a bare transient value, ties every session record back to a specific physical device for its full lifecycle.

If audit completeness for very short-lived agents becomes a requirement, the intended extension is a session-end summary flush, a batch report of the agents that were active, rather than registering each one individually as it connects.

Post-Quantum Channel Security (ML-KEM)

Reflex establishes the session keys protecting its WSS traffic using ML-KEM-768, the NIST-recommended parameter set of the FIPS 203 Module-Lattice-Based Key Encapsulation Mechanism, rather than relying on classical key exchange alone. Reflex generates a key pair and sends the public key to the Pulse API; the API encapsulates a shared secret against that public key and returns the encapsulation; Reflex decapsulates it to recover the same 256-bit shared secret the API holds. That shared secret feeds directly into AES-256-GCM as the encryption key for the WSS channel, and is zeroed from memory once the session ends.

Post-quantum key establishment is a forward-looking hardening measure: it protects today's session traffic against a future adversary who records encrypted traffic now with the intention of decrypting it once a sufficiently capable quantum computer exists.

Local AuthZEN Evaluator

Reflex also hosts a local AuthZEN-shaped access evaluator, a second embedded, loopback-only HTTP endpoint (default port 5287) implementing the OpenID AuthZEN Access Evaluation request shape, subject, action, and resource in, an authorization decision out. The intent is to let endpoint applications and local agents ask "is this action currently authorized" without a cloud round trip for every check.

The evaluator's decision logic is currently a deliberate, minimal stub: it caches the outcome of the most recent OIDC login ceremony and answers every evaluation request with that cached Authorized flag, with no distinction yet by subject, action, or resource. It does, however, implement the one rule that matters most at this stage: it fails closed. Before any login ceremony has ever completed on a device, there is no cached result, and every evaluation is denied. There is no default-allow state. Per-subject and per-resource evaluation, BLE proximity conditions, and revocation on mid-session trust loss are the design target this fail-closed foundation is built toward.

Active Proximity Verification (BLE)

Reflex includes a Bluetooth Low Energy scanner intended to confirm that the user's Auth mobile device is physically near the endpoint. The scanning primitive works as follows: a caller mints a session-scoped 128-bit UUID (valid for under 45 seconds), that UUID is delivered to the Auth app over an authenticated channel, the Auth app begins advertising it over BLE, and Reflex's scanner listens for a matching advertisement, returning the matched UUID on detection, a timeout result if nothing is seen within the configured window, or a "no BLE adapter" result if the endpoint lacks BLE hardware.

Suspend, Sleep, and Logoff Detection

Reflex's disappearance, whether from sleep, a crash, a yanked network cable, or an ordinary logoff, looks identical to outside observers, and suspend/resume notification reliability differs fundamentally by platform: macOS and Linux can genuinely hold up sleep briefly for an acknowledgment, Windows cannot. Rather than build a detection model only as strong as its weakest platform, the architecture treats this as a matter for whatever is watching the session, most notably the Pulse PDP, to resolve: a keepalive that goes silent past its expected interval is the actual detection signal, handled identically regardless of cause.

What Reflex does provide is a single, best-effort, fire-and-forget notification, sent over whatever connection happens to be open, when a suspend or logoff event is detected by platform-specific listeners (native power-event APIs on Windows, macOS, and Linux). There is no acknowledgment wait and no retry; if the message doesn't land, the session's own TTL closes it out regardless. This is a named, accepted tradeoff, not an oversight: an ordinary laptop-closed-for-lunch sleep cycle produces the same signal as an actual compromise or forced termination, absorbed by whatever policy sits downstream of the alarm.

Platform Support

Reflex is distributed as a per-user background process for three platforms:

None of these run under an elevated system service account; each resolves and operates as the interactive user who logged in. BLE capability is required on the endpoint for active proximity verification; all other Reflex functions operate without it, with active proximity simply unavailable in that configuration.

Architecture Summary

Reflex's components interact with the broader Pulse CA framework through well-defined integration points:

Scenario Comparison

How Reflex's architecture is designed to address attack and risk scenarios that session-layer and cloud-side controls alone cannot. Rows marked Design Target describe capability the current build's fail-closed foundation is built toward, not behavior available today; see Implementation Status for the line between the two.

Conclusion

AffirmedID Reflex brings the Pulse CA trust framework to the endpoint as a per-user, non-elevated background service, one whose Continuous Authentication session comes into existence only when something local actually asks for it, and fails closed until it does. Its local AuthZEN evaluator give agentic AI frameworks on the same machine a fast, loopback-only path to session and login state, without a cloud round trip for every check, and without registering every short-lived agent connection with the cloud API. Post-quantum key establishment protects its channel traffic today against tomorrow's decryption capability.