feat(ceremony): hold the token request's head to required and forbidden headers, not a fixed set

[xgreenx]

What changes

_checkTokenHead compared the revealed head against the profile's whole header list: every line once, nothing else. The "nothing else" bound every prover to sending exactly what one HTTP library sends, for no verification gain: a header outside the list changes only what the platform answers, and a wrong answer is a response the verifier cannot read, not one it can be fooled by.

The head is now held to what actually decides what the platform did with the request:

• Required, each exactly once with its value: host naming the pinned authority, and content-type: application/x-www-form-urlencoded, which selects the parser (REQ-COMMON-21B).
• One content-length equal to the body the notary signed, as before.
• Forbidden by name, any spelling: authorization (which client the platform authenticates), content-encoding and transfer-encoding (which bytes it parses), cookie (which session it answers for), x-http-method-override, x-http-method and x-method-override (which method it runs). New error ForbiddenRequestHeader(bytes name).
• Everything else ignored.

Names are compared lowercased, with whitespace before the colon removed and _ read as - (a CGI-style stack folds them); values exactly with the optional whitespace removed; a line no colon splits is refused. requireCrlfLineEndings runs first and now also refuses a bare carriage return.

The identity request

Two closures of the same shape there. The uniqueness count of REQ-COMMON-39 matched authorization:bearer, so a second authorization: Basic or authorization: token line was never counted, and the platform answered for whichever credential it honoured; the bearer the exchange is bound to is the one thing the cross-bind fixes, so a leaked token in the uncounted line named someone else's account under it. The needle is now authorization: under any scheme. And the forbidden names hold on the identity request too, authorization excepted since its one line is what the count checks: cookie is the other credential a platform might honour over the bearer.

Profile data

A token session now states requiredHeaders, the two lines the verifier compares, and nothing else: the send list (requestHeaders, request_headers, X_TOKEN_REQUEST_HEADERS) is gone from profiles.json, the generator and all three tables, since nothing reads it once only the required pair is checked. What a runtime sends beyond those two, accept, connection, a user-agent, is its own. profiles.json also gains requests.forbiddenHeaders, one list for both notarized requests, emitted everywhere as FORBIDDEN_REQUEST_HEADERS. The generator refuses a required list that is not exactly host, naming the pinned authority, and content-type; and a forbidden name that is not a lowercase field name or that the verifier itself reads.

Minor bump for libid-profiles and @libid/contracts when released: request_headers / requestHeaders and request_header_block / requestHeaderBlock are replaced by required_headers / requiredHeaders.

The generator now prints arrays the way rustfmt and biome keep them, from the widths in rustfmt.toml and biome.json, so the generated tables pass both formatters unformatted; the one-line arrays used to pass rustfmt only because an unbreakable string beside them made it skip the struct.

Tests

479 pass, up from 450. XPlatformVerifier.t.sol: test_rejectsAForbiddenHeaderOnTheTokenRequest, test_rejectsEachForbiddenHeaderOnTheTokenRequest (all five names, in other cases and without the space), test_rejectsATokenRequestMissingARequiredHeader, test_rejectsARequiredHeaderTwice, test_acceptsATokenRequestWithoutAnUncomparedHeader (accept dropped), test_acceptsUnlistedHeadersOnTheTokenRequest, test_acceptsARequiredHeaderInAnotherSpelling, test_rejectsAHeaderLineWithoutAColon, test_rejectsABareCarriageReturnInTheTokenHead; on the identity request test_rejectsASecondAuthorizationHeaderOfAnotherScheme, test_rejectsACookieOnTheIdentityRequest, test_acceptsAnUnlistedHeaderOnTheIdentityRequest, test_rejectsABareCarriageReturnOnTheIdentityRequest. GitHubPlatformVerifier.t.sol: test_acceptsAnUnlistedHeaderOnTheExchange, test_rejectsASecondAuthorizationHeaderOfAnotherSchemeOnTheIdentityRead, test_rejectsACookieOnTheIdentityRead. The heads the runtimes send, byte for byte: test_verifiesTheTokenRequestTheBrowserSends (X, with the content-length the browser sets itself, third of five), test_verifiesTheIdentityRequestTheBrowserSends on both platforms (GitHub's with the browser's user-agent and API version); the service's exchange is the happy path already; both fixture tests now say the profile's required pair is among the head's lines. Rust: the vectors tests check the required pair names host and the media type and that no forbidden name is required; the hyper wire tests drive the required pair plus the runtime's own two through the encoder, and a caller-set content-length as X's browser sets it, and check the head passes the new rule with the length written once.

The records the Rust pipeline produces

Two fixtures under test/fixtures/, x-ceremony-session.json and github-ceremony-session.json, generated by libid-rs (cargo run -p libid-tlsn --example ceremony_fixtures, libid-org/libID-rs#19): the requests composed as the browser and the Token-Exchange Service compose them and encoded by hyper, the layouts libid_transcript::ceremony's, the commitments tlsn's SHA-256 plaintext hashes, the record AttestedData::from_observed, signed by anvil #0. A ceremony minus the MPC and the platforms' own bytes, with nothing written by hand. test_verifiesTheRecordsLibidRsProduces in each suite verifies its two records with those signatures unedited and reads the claim out; it first asserts the fixture's digest is the suite's, so a drift between the Rust derivation and the chain's fails by name.

Two ceremonies that actually ran

x-ceremony-real.json and github-ceremony-real.json, captured on 2026-09-11 by libid-rs examples/capture_ceremony.rs (libid-org/libID-rs#19): for each platform a real MPC-TLS token exchange with a real authorization code under the PKCE challenge derived from the suites' digest, then a real identity read with the bearer the platform issued, the verifier in the prover's process signing as anvil #0. Nothing in either file was written by hand; the bearers and GitHub's secret are committed and absent from the bytes. test_verifiesTheRecordsACeremonyProduced in each suite verifies both records with their signatures unedited, at a clock a minute past the identity read, and reads the claim out. The GitHub identity record carries the pretty-printed response GitHub serves for the pinned media type, which is what #37's normalization reads; X's are compact, recorded rather than assumed. This merge also brought #37 in.

Verification

Command	Result
solidity/ forge test	479 passed, 0 failed
solidity/ forge fmt --check, forge lint	clean
scripts/regen-ceremony-profiles.py --check	up to date
rust/ cargo +nightly fmt, clippy -D warnings, cargo test -p libid-profiles	clean, 12 passed
ts/ pnpm build && typecheck && test && lint && fmt:check	24 tests, clean

Companion: the specification side is REQ-PLAT-56A/B/C and REQ-COMMON-39/39A in libid-org/libID#31.

🤖 Generated with Claude Code