[xgreenx]

Stacked on #2 (feat/ceremony-constructions). Independent of #9 — different files, no overlap.

What was missing

Every value a prover must get exactly right was a caller argument with no home. libid-transcript held none of it: every occurrence of login, username, api.x.com or api.github.com in the crate was a test fixture. Each caller kept private copies, and a wrong one failed on chain, where the error names an offset rather than the constant behind it.

	X	GitHub	on chain
token authority	api.x.com	github.com	CeremonyProfile.AUTHORITY_*
identity authority	api.x.com	api.github.com	↑ (GitHub's two differ)
request lines	POST /2/oauth2/token , GET /2/users/me	POST /login/oauth/access_token , GET /user	_tokenRequestLine, _identityRequestLine
identity fields	id (string), username	id (integer), login	_identityFields()
committed body field	none	client_secret	_tokenSentCommitments() 0 vs 1

Why a second copy is safe here

It is a second copy, and that is the whole problem with writing one — a copy nothing checks looks authoritative and drifts in silence. So it is checked.

CeremonyProfile.t.sol pins each platform id and authority id to a value computed with cast keccak, independently of that library. The new profile_vectors test hashes the strings here and asserts the same hex. Two implementations now measure themselves against one set of numbers: a string edited on either side turns one of them red, instead of both staying green while a notary names a platform no verifier is registered for.

Deriving the ids instead would not do the same job. A derivation follows whatever string is present — rename github to gitgub and it produces a fresh id and agrees with itself perfectly. The literal is the pin. The contract makes the same choice: its constants are keccak256(bytes("x")), and its test asserts them against a number computed elsewhere.

What it derives rather than restates

• request_line() from method and path, so the two cannot disagree with it and the trailing space — which is what stops /user matching /users/me — cannot go missing.
• attestation_count() from the sessions present, which is what REQ-COMMON-41 asks and what CeremonyProfile.attestationCount does. A count written beside the list can disagree with the list.
• uri() for the absolute form prover_generic takes before rewriting to origin-form.

It has a caller

ceremony_end_to_end now takes its layout arguments from the table instead of restating them, so this is not a third copy waiting for a consumer. The real consumer is the GitHub Token Service, which is the one session the deployment runs.

Verification

• cargo +nightly fmt --all -- --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace — 107 passed (11 new: 7 table, 4 vectors)

Still one-sided

The request lines and identity field names have no vector on the contract side — only the fixtures its verifier tests decode. Closing that needs a matching test in libid-contracts asserting keccak256 of each verifier's literals against the same numbers. Worth doing; not in this PR.

The stronger form, which this repo already has a precedent for in handles.json + regen-identity-handles.py --check, is to generate both sides from one source with a CI drift check — removing the second copy instead of checking it.

[xgreenx]

Closing while the generated version is built in libid-contracts.

The table here is hand-written, and the plan is to replace it with a generated, published crate driven by a profiles spec beside handles.json — so landing it would mean shipping a copy we intend to delete, and possibly consuming it somewhere before the generated one exists.

Nothing is lost: the values were each verified against the contract, and its keccak vectors pass against the numbers CeremonyProfile.t.sol pins. That verification is what the generator's spec file is built from. The branch stays if any of it is wanted back.

Reopens as a consumer of the generated crate once the contracts side lands.