Move credential ceremonies into the world web UI and ignore proxy environment
This commit is contained in:
+8
-18
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user