What happened
On a signed-in phone, changing the car's ready time (today: 10:00 → 12:00) asked for a passkey again. That is the wrong cost for a household setting.
Passkey should prove who is signing in. After that, changing when the car should be ready should just save.
Today
PUT /api/loadpoints/{id}/schedule is a configure write. The box answers E_NEEDS_STEP_UP. The app runs the passkey ceremony and retries with stepUp (EvPanel, src/lib/identity/stepup.ts). Protocol: docs/protocol.md — configure needs owner and a step-up flag.
The flag is this app's word, not a WebAuthn check on the box. It is meant to stop an unlocked phone on a table from reconfiguring the house. For ready time, that extra Face ID is more friction than the risk is worth.
Wanted
- Sign in: passkey, as now.
- Change charging schedule / ready time: no second passkey if the session is already owner.
- Keep a step-up for things that mint access, replace the whole config, or move energy as a command.
The box is the authority. Core must accept the schedule write without a fresh step-up, or the app cannot honestly skip the prompt. Pair the change in srcfl/ftw if the route table stays as it is.
Done when
A signed-in owner can save a new ready time without Face ID or fingerprint. Login still uses a passkey. Tests today that require stepUp on the schedule PUT need to match the new rule.
What happened
On a signed-in phone, changing the car's ready time (today: 10:00 → 12:00) asked for a passkey again. That is the wrong cost for a household setting.
Passkey should prove who is signing in. After that, changing when the car should be ready should just save.
Today
PUT /api/loadpoints/{id}/scheduleis a configure write. The box answersE_NEEDS_STEP_UP. The app runs the passkey ceremony and retries withstepUp(EvPanel,src/lib/identity/stepup.ts). Protocol:docs/protocol.md— configure needs owner and a step-up flag.The flag is this app's word, not a WebAuthn check on the box. It is meant to stop an unlocked phone on a table from reconfiguring the house. For ready time, that extra Face ID is more friction than the risk is worth.
Wanted
The box is the authority. Core must accept the schedule write without a fresh step-up, or the app cannot honestly skip the prompt. Pair the change in
srcfl/ftwif the route table stays as it is.Done when
A signed-in owner can save a new ready time without Face ID or fingerprint. Login still uses a passkey. Tests today that require
stepUpon the schedule PUT need to match the new rule.