test: the live ceremony suite, with a notary of its own

[SupremaLex]

The suite behind --features live-ceremony: real MPC-TLS sessions against github.com and api.x.com through an in-process notary, with the bridge under test publishing the configuration a ceremony starts from. Based on #8.

What runs

tests/ceremony starts the real binary on a configuration file, with the loopback port to bind in its environment (tests/common/bridge.rs, shared with tests/startup.rs), reads GET /api/v1/ceremony/config from it as an application would, and runs the notarized sessions of a ceremony with a prover of its own (prover.rs: libid_tlsn::prover_generic over TCP) through a notary of its own (notary.rs: libid_tlsn::verifier, signing with a fresh key). Each record the notary signs is checked against the rules the Platform Verifier applies on chain (session.rs): exact coverage, the request revealed whole with nothing committed, the bearer's commitment framed by "access_token":" and readable nowhere, exactly one authorization: Bearer header with its value committed in the identity request, the two identity members revealed and nothing else.

GitHub (github.rs): the token request is the canonical five-field form of libid#35 — client_id, code, redirect_uri, code_verifier, client_secret — with the published clientCredential as client_secret, laid out whole; a record laid out with the credential committed, the shape the v0.4.0 profile table still declares, is refused. The identity read is GET /user with the bearer committed; the integer id is revealed with the byte that closes it, login as a string.

Rung	Needs	Proves
a refused code	the App	MPC-TLS to github.com; GitHub's bad_verification_code
a refused credential	the App	GitHub's incorrect_client_credentials
a refused bearer	nothing	MPC-TLS to api.github.com; a 4xx
a real authorization	the App, the test account, Chrome	both sessions attested, both signatures recovering to the suite's notary, the login the account's

X (x.rs): the same two sessions for the public PKCE client; a refused-bearer rung, and a real authorization from a signed-in Chrome (browser/x.rs), which restores a saved session and never opens X's sign-in pages unattended. X examines a fresh sign-in, and a run nobody is watching has no answer for what it asks: a session that no longer authenticates stops the rung and names the headed export that makes a new one, and the export refuses a headless run. The rung says which way X took it, the consent screen or a redirect straight back for an app this account has already authorized.

The browser driver (browser/) is one core — Chrome over CDP, a redirect watcher that reads the code off the request nothing listens for, screenshots and page dumps under BROWSER_TRACE — and one module per platform.

Variables

From the environment or a gitignored .env.test; a missing one fails the run. GH_OAUTH_CLIENT_ID, GH_OAUTH_CLIENT_SECRET (the bridge under test publishes it) and LIBID_TEST_PUBLIC_ORIGIN; GH_TEST_ALICE_USERNAME, GH_TEST_ALICE_PASSWORD, GH_TEST_ALICE_TOTP_SECRET and a Chrome for the GitHub authorization; X_OAUTH_CLIENT_ID, LIBID_TEST_X_REDIRECT_URI, X_TEST_ALICE_USERNAME, X_TEST_ALICE_PASSWORD, X_TEST_ALICE_EMAIL and the optional X_TEST_ALICE_COOKIES for X. The README's Testing section has the table.

CI

ceremony.yml: pull requests run the rungs that need no account; the nightly and dispatched runs add the GitHub authorization, one rung at a time; the X authorization runs weekly on a schedule of its own and on a dispatch with x, because a saved session and the account behind it degrade over months. The two schedules carry their own concurrency group. Each job is skipped where its secrets are absent. Not a required check.

Verification

Hermetic: 60 unit, 19 over the router, 4 over the binary, and 7 in the suite (the request layouts, the refused hidden-credential layout, the TOTP code). Live, locally: 12 passed — the three GitHub rungs that need no account, the X refused bearer, and the real GitHub authorization with both sessions attested. clippy -D warnings under --all-features, nightly rustfmt, --locked.

Known gaps

• The X authorization rung has not passed end to end: X refuses the headless sign-in; the headed export is the way in.
• libid-rs's profiles::GITHUB still declares secret_field: Some("client_secret"); the suite lays the request out with secret_field: None per libid#35 until the table follows.