Move credential ceremonies into the world web UI and ignore proxy environment

This commit is contained in:
2026-11-12 06:57:34 +00:00
parent e0c2d8bc8b
commit a74ebd11ba
22 changed files with 209 additions and 356 deletions
+8 -18
View File
@@ -1,4 +1,4 @@
# Host API and host pages
# Host JSON API
`handle(&Api, Caller, Request<Bytes>)` answers requests without a transport.
The `wasi:http` hook supplies the caller from the process table.
@@ -17,21 +17,11 @@ The host opens no separate network port.
Browser ceremonies derive the passkey RP ID and origin from the request Origin header.
The host retains separate pending ceremony state per origin against the same credential registry.
After the first registration, every decision and further registration requires a passkey assertion.
Host pages use relative assets and routes so they work under `/api/`.
## Pages and assets
- `GET /approve/{request}` renders the host's stored summary and public details.
The page sends only the human's decision and optional limit overrides.
The host builds the binding from the stored request and its payload digest.
- `GET /register` registers the first passkey or adds another passkey.
- `GET /entry/{item}/{field}` displays a blank secret-entry form.
The host embeds its public encryption key and the selected field's public metadata.
- `GET /app.js` serves the shared ceremony code and WebCrypto encryption.
The checked-in pages use plain HTML and JavaScript with no build step or external dependencies.
The host escapes review data before it enters HTML.
No page includes a stored secret value.
The host serves no HTML or UI assets. The world web UI owns credential views in `/srv/www`.
The Passkeys view lists labels and registers passkeys. The bootstrap notice opens that view.
The approval view at `/#approve/ID` reads stored summaries and details through JSON routes.
The secret-entry view at `/#entry/ITEM/FIELD` encrypts the secret before submission.
The host constructs authorization bindings from stored requests and verifies every proof.
## Public JSON routes
@@ -76,8 +66,8 @@ The V8 harness answers queries and invokes actions without a second storage read
- `GET /harness/models`: `{models:[...]}` with public catalog fields, without provider authentication data.
- `GET /harness/families`: `{families:{...}}` from the world's model definitions.
- `GET /harness/extensions`: the loaded extension status, also visible through `/proc/extensions`.
- `GET /harness/credential-requests`: `{requests:[...]}` with pending conversation requests and host approval links.
Approval stays on the host page.
- `GET /harness/credential-requests`: `{requests:[...]}` with pending conversation requests and `approvalUrl: "/#approve/ID"` links.
The web UI opens its internal approval view.
The `after` cursor is an exclusive entry ID. Streams replay retained records before live records.
Commit observation starts before replay, so a concurrent commit cannot create a gap.