Know who signed it, under trust you chose.
The BitRep binary-attestation protocol and its reference verifier. The accepted v1 interface checks Ed25519 signatures against an operator-configured issuer-key trust snapshot and evaluation time. Success means issuer_signature_only under those conditions, not factual truth or institutional authority.
Unverified identity flags, copied verification JSON and unsigned legacy imports cannot show who signed a statement or whether the key is still admissible.
Signed statements checked against issuer keys you configure, at a stated evaluation time, with conservative handling of revocation.
version, algorithm, issuer and key, subject, type, audience, content digest and validity times.
operator-controlled issuer keys; no default trusted issuer is supplied.
signature, key status, audience and time checks, with conservative revocation behavior.
v1 records kept apart from legacy data; identical resubmission is idempotent, conflicting content rejected.
malformed or unsupported inputs rejected; placeholder privacy and platform checks kept outside accepted assurance.
A downstream system such as the Evidence Registry supplies the expected subject, audience and content binding. The verifier checks the statement locally or through the reference service. The consumer still compares the digest with the exact bytes it uses and decides how much weight to give the assertion. Two signatures over the same bytes are not independent corroboration.
Configure a trust snapshot with one issuer key, then verify a valid, an expired and a wrong-audience statement.
Open the repository →No reputation score, real zero-knowledge proof, external identity verification, blockchain inclusion verification, signed portable result receipt or caller-selected historical verification in v1. Issuer enrollment, secure time, snapshot distribution, anti-rollback and production transport authentication remain deployment work.