# QNE Password Record Login Recipe Doctrine V1

Date: 2026-06-14

## Status

Current planning doctrine and TODO marker.

## Purpose

QNE password records should be able to include a structured login recipe for
the site or service associated with the password. The recipe records the known
process for reaching and completing login while keeping the password secret
itself in the QNE vault.

The aim is to make QNE more useful than a conventional password manager without
turning it into an uncontrolled autonomous credential agent.

## Core Rule

The login recipe is not authority. It is only a procedure.

Authority comes from the password record policy, the user's current approval,
and QNE safety doctrine. Sensitive actions must remain visible and auditable.

## Password Record Shape

A future password record should distinguish:

- identity data
- secret reference
- login recipe
- policy
- provenance and maintenance metadata

Example conceptual shape:

```text
PasswordRecord
  account_id
  site_name
  canonical_url
  login_url
  username_or_account_identifier
  secret_ref
  login_recipe
  policy
  provenance
```

The raw password should not be stored directly in ordinary record text. It
should be held by the QNE device vault or Home Node vault and referenced by
`secret_ref`.

## Login Recipe

A login recipe may include:

- open login URL
- wait for username field
- fill username or account identifier
- wait for password field
- fill password or ask user to type manually
- click submit or wait for user confirmation
- detect multi-factor authentication
- detect success page, success URL, or success page element
- detect failure messages
- detect provider flow changes

Recipes should be structured data, not opaque prose, so a QNENodeSkill or
browser engine can inspect and execute them safely.

## Policy

Each password record must be able to define site-specific policy, including:

- manual password entry only
- allow password autofill
- allow submit
- require confirmation before submit
- never store session cookies
- allow session restore
- read-only after login
- forbid financial actions
- require user presence for MFA

Financial and high-risk accounts default to manual password entry, user-present
MFA, and read-only operation.

## Browser Automation Role

Obscura or another browser automation engine may help discover, verify, and
execute login recipes. It should not own the password store.

The vault stores secrets. The PA requests consent. The login recipe describes
the procedure. The browser engine performs only the steps allowed by current
policy and user approval.

## Maintenance Metadata

The password record should track login recipe health:

- last verified timestamp
- engine used for verification
- selector or step confidence
- failure count
- last failure reason
- whether the site changed its login flow

This lets QNE warn the user when a recipe is stale rather than silently failing
or taking uncertain actions.

## TODO Marker

Future work item:

Design and implement QNE password records with attached login recipes, vault
secret references, per-site policy, and provenance metadata. Investigate
Obscura-assisted login-flow discovery only after the mobile PA, Home Node
semantic action path, and initial vault structures are stable.
