The GOVP-1 Record Format
This document is the normative definition of a GOVP-1 record: the exact bytes an implementation must produce and accept. The protocol overview explains; this text decides — together with the conformance vectors, which pin it byte-for-byte.
The key words must, must not, should, may are to be interpreted as described in RFC 2119.
The plain-text edition is byte-stable and archivable — the copy to keep alongside your evidence.
1Data model
A GOVP-1 record is a set of key–value fields that binds a digital asset (identified by a SHA-256 fingerprint) to a publisher operating under a canonical domain identity, sealed with an Ed25519 signature. A record is self-contained: everything needed to verify it — including the public key — travels inside it.
2Wire format
A record is UTF-8 text. Each field is one line of the form Display-Key: value. Lines beginning with # are comments; comments and blank lines carry no meaning and are not covered by the signature.
A JSON bundle form may accompany the text record for machine consumption; the text record is the canonical artifact.
3Parsing
A parser must process each line as follows:
3.1 Legacy aliases
A parser must accept these aliases and map them to canonical keys:
| Alias | Canonical key |
|---|---|
| type | asset-type |
| sha256 | asset-sha256 |
| pubkey | public-key |
| timestamp | generated-at |
4Fields
| Key | Req. | Definition |
|---|---|---|
| version | MUST | The literal GOVP-1. Any other value is a different format. |
| canonical | MUST | Absolute HTTPS URL of the issuing identity — normally https://<domain>/.well-known/govp.txt. Binds the record to its domain (§10.3). |
| publisher | MUST | Human-readable name of the declaring party. |
| asset-type | MUST | One of the registered type codes (§8), lowercase. |
| asset-id | MUST | Stable identifier of the asset within the publisher's namespace. |
| asset-sha256 | MUST | Lowercase hex SHA-256 (64 chars) of the asset bytes. |
| govp-id | MUST | Content-derived identifier (§7). Verifiers recompute and compare. |
| evidence | MUST | URL where the declared asset (or its statement) is published. |
| signature | MUST | Base64 Ed25519 signature (64 bytes) over the signing input (§5–6). |
| public-key | MUST* | Base64 raw Ed25519 public key (32 bytes). *Required to verify the signature; a record without it cannot pass §10.2. |
| generated-at | SHOULD | RFC 3339 UTC issuance time. Issuer-asserted unless anchored (§9). |
| profile | MAY | Named profile label (§9). |
| license | MAY | License of the published evidence (e.g. CC-BY-4.0). |
Unknown fields must be preserved and included in the signing input like any other field; verifiers must not fail on fields they do not recognize as long as §10 passes.
5Canonical signing input
The signing input is a deterministic byte string. Implementations must construct it exactly as follows:
Field order in the file, display capitalization, comments and blank lines have no effect on the signing input. Two records with the same field values always produce identical bytes.
The conformance vectors pin the SHA-256 of this byte string for every test record — e.g. vector 01-valid-document pins d3263b7c87442418f76768caa4048fbad6fa108583837966a2ff04d7e1df26ff.
6Signature
The signature is Ed25519 (RFC 8032) over the signing input of §5. The public key is the 32-byte raw form, base64-encoded in public-key; the signature is the 64-byte form, base64-encoded in signature. No pre-hashing variant is used: the signing input is passed to Ed25519 directly.
7GOVP-ID derivation
The govp-id is derived from content, so independent parties compute the same identifier. Implementations must derive it exactly as:
Note the separator is a literal line feed (\n, 0x0A) between the three components. asset-id is not lowercased.
8Type-code registry
| asset-type | Code | Meaning |
|---|---|---|
| document | DOC | A document, declaration or statement. |
| dataset | DATA | A dataset snapshot. |
| model | MODEL | A trained model artifact or model card. |
| agent | AGENT | An agent's operating declaration. |
| pipeline | PIPE | A build/release pipeline record. |
| benchmark | BENCH | A benchmark result set. |
New type codes are added through the change process; additions are backward-compatible.
9Profiles
The profile field names the guarantees and conventions a record claims. Two families exist today:
9.1 Time-anchoring profiles
| Profile | Guarantee |
|---|---|
| GOVP-BASIC | Integrity and authorship only. generated-at is issuer-asserted and not anchored to external time. |
| GOVP-RFC3161 | The fixation is bound to an RFC 3161 timestamp from an independent TSA. |
| GOVP-QTSP | Anchored by an eIDAS qualified timestamp (QTSP). |
9.2 Sector profiles
Deployment conventions such as industrial-manufacturing, quality-inspection, compliance-control, esg-disclosure, audit-evidence, release-record, website-integrity. Sector profiles label the use case; they add no cryptographic guarantee by themselves. A record whose profile is not a time-anchoring profile must be treated as GOVP-BASIC for time purposes.
10Verification algorithm
A verifier must evaluate the following checks and report them individually. The record is core-valid only if all applicable checks pass.
10.1 format
All of the MUST fields of §4 are present and non-empty, and version equals GOVP-1.
10.2 signature
Rebuild the signing input (§5) from the parsed fields and verify the Ed25519 signature against public-key.
10.3 canonical binding (conditional)
When the record was fetched from a URL, that URL must equal the canonical field exactly. When verifying a local file offline, this check is skipped and must be reported as not evaluated — not as passed.
10.4 govp-id
Re-derive per §7 and compare with the declared govp-id.
10.5 asset hash (conditional)
When the asset bytes are available, their SHA-256 must equal asset-sha256.
11Publication
An issuing domain should publish:
Read endpoints should be served with Access-Control-Allow-Origin: * — evidence is public and must verify from any origin. Durability depends on a surviving copy (domain, mirror or exported bundle); publication at the canonical URL is the primary copy, not the only one. See the HTTP surface reference.
12Security considerations
12.1 Issuer-asserted time
Under GOVP-BASIC, generated-at is a claim by the issuer; a determined issuer can backdate a bare record. Only the anchoring profiles (§9.1) or independent witnesses make time provable. Implementations must not present BASIC time as independently anchored.
12.2 Comments are unsigned
Comment lines are outside the signing input. An attacker can add or alter comments without breaking the signature; renderers must not present comment content as verified.
12.3 Domain binding limits
The canonical check (§10.3) detects re-hosting only when the record is fetched from a URL. A record shared as a file proves integrity and authorship of its fields — including the claimed canonical — but not that the domain currently serves it.
12.4 Key custody
Whoever holds the private key can issue records for that identity. Keys must be kept out of the web root; high-value signing should use an external signer (KMS/HSM). See the integration guide.
12.5 Hash agility
GOVP-1 fixes SHA-256 and Ed25519. A migration to other primitives is a new format version, never a silent change (see compatibility rules).
13Conformance
An implementation conforms to GOVP-1 if and only if it reproduces every vector of GOVP-CORE-CONFORMANCE-1 exactly: same canonical bytes (pinned by signing-input SHA-256), same derived GOVP-ID, same per-check verdicts. The prose above explains; the vectors decide.
14Change log
| Date | Change |
|---|---|
| 2026-07 | First publication of the normative text for the frozen GOVP-1 format, matching the reference implementations and GOVP-CORE-CONFORMANCE-1. |
Amendments follow the governance process. Editorial fixes may be applied in place; any change to canonical bytes mints a new format version.