Decision required
Design the authenticated remote Flect runtime used when a normal browser or mobile host cannot embed local Pi and privileged capabilities.
The reviewed design must resolve:
- runtime identity and user authorization;
- device discovery and explicit pairing;
- transport authentication and confidentiality;
- capability projection and remote confirmation;
- session resumption, replay protection, ordering, and interruption;
- credential locality and secret redaction;
- revocation, lost-device, and compromised-runtime behavior;
- offline cached-interface semantics;
- multi-user and product-authorization boundaries; and
- deployment, observability, retention, and abuse controls.
Exclusions
- Exposing the current loopback development runtime to a network.
- Treating TLS alone as application authentication.
- Copying Pi or product credentials into browser or mobile storage.
- Implementing a remote service before the threat model and protocol are approved.
Acceptance criteria
- A design document defines authorities, assets, adversaries, protocol states, key lifecycle, failure behavior, and recovery.
- An explicit decision records whether the first implementation is peer-hosted, user-hosted, product-hosted, or supports more than one provider through the same contract.
- Protocol fixtures cover pairing, reconnect, replay rejection, revocation, interruption, and lost-device recovery.
- Security review approves the design before any non-loopback listener or remote capability adapter is implemented.
Decision required
Design the authenticated remote Flect runtime used when a normal browser or mobile host cannot embed local Pi and privileged capabilities.
The reviewed design must resolve:
Exclusions
Acceptance criteria