Phase 3: land the web demo (W1–W5) on main#35
Closed
djscruggs wants to merge 6 commits into
Closed
Conversation
Reconcile the SPEC.md phased plan with reality: Phases 0 through 2.5 are complete and merged (DB-stack swap, reference-impl polish, L3 selective disclosure, the Cloudflare and DMV demos, the OpenAI-compatible provider), so mark them done and correct the stale "remaining cleanup" list. Add Phase 3 (web demo) and Phase 4 (the deferred L3-8 token bridging + audit trail) so the roadmap and the conformance register agree. Add docs/web-demo-plan.md: a browser demo of the L1/L2/L3 flows reusing the existing pure core through a thin Fastify HTTP shell, with a Vue 3 + Vite client. Records the reviewed decisions — mock-only public with live runs behind a local flag, demo-site scope only, no new conformance rows — and keeps the web layer decoupled in case it becomes a separate repo. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Start Phase 3 (the web demo). Add a third npm workspace, web/, with a thin Fastify HTTP shell over the existing verification core — no crypto or VC logic is reimplemented. Three routes: list the scenarios, build one scenario (a real signed credential plus DIDs, keys stripped), and verify a credential against a requested action via the genuine checkDelegation tool. A pure response sanitizer strips any private-key or signer field at any depth, so the leakage-canary property holds in code, not by convention. The handlers are framework-agnostic and unit-test without HTTP; integration tests drive the real path through app.inject, including a live canary scan. No UI yet — that lands in W2. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
W2 of the web demo. Add a Vue 3 + Vite client that shows the L1/L2 flow as an issue → present → verify pipeline: pick the valid scenario or one of the adversarial variants (tampered, expired, not-yet-valid, wrong agent, missing or wrong claim, bad or expired auth proof), and watch the verifier grant or deny it. The verdict is rendered against the expected outcome, so the denial cases are self-evidently correct. The verdict comes from the server's check_delegation tool, never the page. The client is an isolated TypeScript toolchain (vue-tsc) under web/client; the Fastify server and lib/ stay plain JS + JSDoc. The server now serves the built client (web/public) on the same origin as the API, and the Vite dev server proxies /api in development. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
W3 of the web demo. Add two SD endpoints — derive a minimal reveal (/api/sd/disclose/:mode) and verify it (/api/sd/verify) — driving the holder Model B flow server-side: a wallet holds the full credential and derives a reveal disclosing only age_over_21. Only the reveal document crosses to the browser; the birthdate and the other claims never leave the wallet. The client gains a tabbed shell over a delegation view and a new disclosure view: a wallet/verifier split showing which claims stay hidden and which one crosses, the verifier's verdict, and — for bbs-2023 — that two derivations of the same fact produce different (uncorrelatable) proofs. Both cryptosuites are exposed: ecdsa-sd-2023 (linkable) and bbs-2023 (unlinkable). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
W4 of the web demo. Add /api/demos and /api/run-demo/:name, which run the real demo-agent loop over a real scenario and the genuine fail-closed tools (Cloudflare migration, CA DMV registration), returning the tool-call trace and the authoritative tool decisions. The model is a deterministic mock by default — offline, no key, safe for a public site; a live model stays a local opt-in, and the eval suites cover the misbehaving-model cases. The client gains an Applied demos tab showing the ordered tool calls next to the tool decisions, making the security property visible: the model orchestrates, but the tools decide — the verdict is never the model's prose. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
W5, the final web-demo slice. Add a "Try it in the browser" section to the README (build the client, start the server, the three tabs), list web/ as the third workspace, and add a deploy recipe and a live-model note to web/README.md. Record in CONFORMANCE.md that the web shell adds no new requirements — it delegates to the covered core and only adds the response sanitizer enforcing R-X-2. Mark Phase 3 done in SPEC.md with its five slices. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why this PR
The Phase 3 web-demo PRs (#30–#34) were a stack — each based on the previous branch, not on
main. They all merged into their bases, so the full W1–W5 work now sits at the tip ofphase-3-w5-polishbut never reachedmain(which only has the plan, #29). This PR brings the whole stack intomainin one clean fast-forward (5 commits, no new code).What lands
The complete
web/workspace — the browser demo of the KYA-OS L1/L2/L3 flows:All five were individually reviewed and merged as #30–#34. Full gate was green at each step (mcp-server 191 / demo-agent 102 / web 28; typecheck + lint clean; client builds clean).
🤖 Generated with Claude Code