Expand description
The libID ceremony profiles.
What each platform’s notarized sessions request, which host answers them,
and which bytes of the response a Platform Verifier reads. The values are
generated from solidity/contracts/ceremony/profiles.json, the same file
CeremonyProfile.sol is generated from, so a prover and the chain cannot
hold different copies.
§What is not here
Ids. platformId is keccak256 of Profile::platform and authorityId
is keccak256 of Session::authority, and this crate hashes neither: a
caller that needs an id already has a hasher, and a crate that pulled one
in to precompute six values would make every consumer carry it.
Behaviour. Which ranges a session reveals, how a handle normalizes, what a verifier checks – all hand written where they belong. This is the table those read.
Structs§
- Identity
Session - The identity session: the authenticated read that names the account.
- Profile
- One platform’s ceremony profile at one Platform Ceremony Version.
- Session
- One notarized session: which server, and which request.
- Token
Session - The token session: the OAuth exchange.
Enums§
- IdShape
- Which shape a platform’s immutable identifier takes in its response.
Constants§
- FORBIDDEN_
REQUEST_ HEADERS - Header names no notarized request may carry, compared by every
Platform Verifier with the name lowercased, its whitespace removed and
_read as-. Each changes what the platform does with the request in a way no revealed byte shows:authorizationwhich client it authenticates,content-encodingandtransfer-encodingwhich bytes it parses,cookiewhich session it answers for, the three override names which method it runs. The identity request is excepted fromauthorizationalone: its one such header, under any scheme, is what REQ-COMMON-39 counts. On the token request the verifier further requires each session’s requiredHeaders,hostandcontent-type, readscontent-length, and ignores every other header: one outside both lists changes only what the platform answers, and a wrong answer is a response the verifier cannot read. - FUTURE_
OBSERVATION_ ALLOWANCE_ SECONDS_ GITHUB github/v1: how far ahead of Block Time the evidence time may run. The verifier subtracts it, so every version of a platform reports time on one scale.- FUTURE_
OBSERVATION_ ALLOWANCE_ SECONDS_ GOOGLE google/v1: how far ahead of Block Time the evidence time may run. The verifier subtracts it, so every version of a platform reports time on one scale.- FUTURE_
OBSERVATION_ ALLOWANCE_ SECONDS_ X x/v1: how far ahead of Block Time the evidence time may run. The verifier subtracts it, so every version of a platform reports time on one scale.- GITHUB
- The credential GitHub calls
client_secretis sent and revealed, so an attestation publishes it and nothing here is confidential. The two sessions are served by DIFFERENT hosts – which is why one pinned authority per profile would be wrong. - Google’s evidence is a signed token checked against Google’s published keys, so the profile notarizes nothing: no session, no attestation, and no Notary Fee.
- LAUNCH
- The closed launch list. A platform outside it has no profile, and
CeremonyProfile.attestationCountreverts on one. - MAX_
FUTURE_ ATTESTATION_ SKEW_ SECONDS_ GITHUB github/v1: how far ahead of Block Time the token attestation may be dated.- MAX_
FUTURE_ ATTESTATION_ SKEW_ SECONDS_ X x/v1: how far ahead of Block Time the token attestation may be dated.- PROOF_
LIFETIME_ SECONDS_ GITHUB github/v1: maximum age of the token attestation.- PROOF_
LIFETIME_ SECONDS_ X x/v1: maximum age of the token attestation.- X
- A public client with S256 PKCE and two browser-owned sessions, both served by the same host.
Functions§
- launch
- The launch profile for a platform name, or nothing.