Secure browser-to-node enrollment for locally generated validator identities

[halfaipg]

Current Status

Optional existing-account pairing is implemented and deployed dark. Linux ARM64 live qualification passed; Windows pairing, human desktop recovery and client release remain open.

Ordinary validator setup does not depend on this issue. The public preview.13 release supports explicitly confirmed dedicated-account enrollment: generate and protect a local signer, use Core's wallet-signature authentication, and obtain a validator-only API key. No Google/GitHub login, wallet extension, funds or pasted private key is required.

Identity Contract

Keep the node's dedicated account, signer and scoped API key. Pairing adds a private human-account association for node visibility only. It does not transfer credentials, attach the node signer as a human login identity, merge accounts, change payout wallets or balances, grant recovery/control rights, or certify independent operation.

Both sides deliberately approve. Console approval alone must never trigger a signature. The local app requires a fresh review and comparison-code confirmation of the exact expiring, account-bound payload. A lost response is not proof of a failed commit: recover by reading the current association. Either side can remove that exact association without changing the node's identity.

Merged And Deployed

• Core #58 and scoped-pilot #60: production f51875ce, Alembic 0030, global pairing disabled.
• Console #21: production db301013, authenticated inspection/approval, private listing and exact-association removal.
• Node #54: local pairing controls merged and tested, but not included in public preview.13.
• Native qualification harness #63, live evidence #66, and Core record #62 are merged.

The Linux pilot admitted only two disposable accounts through a private expiring allowlist, then removed the override. Global pairing stayed off. No active association remains; the tables retain cancelled/revoked test metadata rather than being empty. No validator economics or media issuance was enabled.

Verified Evidence

• Six cross-repo HTTP integration tests exercise real Core handlers and built Console authentication/consent routes. Their local database boundary is documented separately from the Postgres tests.
• Core has real PostgreSQL transition-race, migration and restore coverage. The native build/install checks pass across Windows x64, macOS ARM64 and both Linux architectures.
• The published preview.13 Windows runtime passed run 33110290699: accepted signed evidence, bad credentials, firewall outage/recovery, restarts, upgrades and credential retirement. This was HTTP-driven Windows Server testing, not human desktop use or account pairing.
• The actual unpublished Linux ARM64 binary from 35b4e045 passed production pairing against Core and Console: real wallet login, cancellation, separate local confirmation, stale-review rejection, lost-response/restart recovery, and both removal paths. It submitted two accepted reports before pairing and one after with unchanged configuration.
• Independent read-only Postgres checks proved three verified signatures, unchanged non-pairing identities/settings, no test money records, no active association, suspension and API-key revocation. The pilot was removed after cleanup.

The Linux Console login and hidden-TTY code entry were driven by automated first-party test tooling. They are not human desktop, independent-operator or Windows pairing proof. The exact redacted report, hashes and limitations are in PRODUCTION_BASELINE.md and LINUX_PAIRING_CANARY_REPORT.json.

Remaining Gates

• Controlled native Windows pairing journey through accepted signed evidence before/after, explicit two-sided consent, cancellation, restart/response-loss recovery, and both removal paths.
• Ordinary-user desktop verification of double-click startup, browser controls, stop/start, recovery and upgrades. A registration or CI build alone is insufficient.
• Publish the reviewed client as a new immutable version after qualification, preserving existing node identities and updating the exact download links.
• Supervised release-qualified activation with rollback and privacy checks. Until then, keep global pairing disabled.

The separate five-independent-operator / 72-hour cohort is not satisfied by these first-party tests. Keep validator routing, rewards, staking, slashing, media issuance and paid/blind audit activation off.

See ACCOUNT_PAIRING.md and NATIVE_PAIRING_CANARY.md for the current contracts. Older comments below document superseded stages, not current deployment status.

[halfaipg]

PR #50 adds a separate dedicated-account path: consented local signer generation, existing Core SIWE authentication, and validator-only key issuance. A production source canary completed registration through stored signature-verified evidence and was suspended afterward. This does NOT close existing-account pairing: no identity merge, primary-wallet change, or payout change is performed. Keep this issue open for the authenticated account-bound browser/node pairing flow and its Windows end-to-end tests.

[halfaipg]

Source review for the next pairing phase (not implemented or deployed): Core currently enforces one registration per account and per signing wallet, and its validator endpoints derive the signer from the account primary wallet. Worker-manager enrollment provides useful device-flow and recent-step-up patterns, but also installs a payout-wallet delegation; do not reuse that behavior for validators. The validator path needs an explicit, expiring account-to-node signer authorization and a signer-bound validator-only credential, without primary-wallet/payout changes. Preserve the existing one-node/account limit in the initial scope. Reject an already enrolled signer belonging to a different account: transferring existing dedicated accounts is a separate migration, never an implicit merge. Require recent account proof, node proof of possession, bounded one-use nonce/account/audience/scopes/credential commitments, and explicit confirmation in both browser and node. Activation and replay/idempotency must have one durable transactional authority; a Redis lock alone cannot guarantee SQL key activation. Tests must cover wrong account, wrong signer, expired/replayed challenge, cancelled and lost responses, concurrent approvals, key revocation, and unchanged account wallet/credits/payouts. Preview.12 addresses the separate local-app usability milestone; it does not close this issue.

[halfaipg]

Core implementation is now in draft PR AIPowerGrid/grid-core#58 (18c6f8dd), default off. After reviewing the current one-registration-per-account contract, the implementation preserves the enrolled node account/signer/scoped key and adds a separate human-account visibility association. It does not attach the node signer as a human login identity or transfer credentials. This intentionally supersedes the earlier key-transfer approach in this issue.

Two-party flow: node starts -> recent Google/SIWE account approves immutable account binding -> local app compares the code and explicitly signs the exact expiring Core payload -> one PostgreSQL transaction records the association. Either party can remove the exact association; stale unlink proofs cannot remove a later one. Rotated signers and retired accounts require deliberate re-pairing, never automatic account merges.

Local proof: full Core suite with real Postgres validator/credit/payout tests passed 735; final pairing suite passed 49 (all Postgres cases, four skips only for SQLite-inapplicable row-lock tests). Alembic 0030 upgrades/drift checks/rollback/re-upgrade passed on Postgres 16 and SQLite. No production migration or enablement.

Still open: Console page, local operator app integration, exact-platform two-party consent/recovery qualification, then supervised dark deployment and canary. Public preview.12 does not yet implement account pairing.

[halfaipg]

The Console counterpart is now in draft AIPowerGrid/grid-frontend#21 (8fca335), paired with Core draft AIPowerGrid/grid-core#58. All Console CI/security checks passed. It has authenticated inspection/explicit approval, comparison-code waiting, private associated-node status, exact-association unlink and fresh Google/SIWE recovery. It removes obsolete manual key-juggling from the Console setup guide in favor of the released local operator app.

This is not deployed or enabled. Preview.12 still has no pairing controls. Next is the local app: independently bounded pairing operations alongside the running node, strict purpose/audience/node/expiry validation before signing, explicit comparison confirmation, cancellation and restart/unlink recovery. No node key transfer, account merge, payout change or new independence/economic authority.