Transparency Logs

Status: Informative extension-area document; see Status of This Document.

This entire document is informative in v0.1. It describes a minimal entry format for interoperability experiments; mechanisms for operating logs at scale are not specified.

1. Purpose

An attestation's issued_at is an issuer assertion and can be backdated. A transparency log is an append-only record, operated by a party other than the issuer, that records when it observed an attestation.

A log entry indicates that the identified attestation was observed by the named log no later than logged_at. It does not establish the truth of the attestation's claims, the issuer's trustworthiness, or the accuracy of issued_at. According to the log, the attestation existed by logged_at.

2. Entry Format

Log entries follow osap-transparency-log-entry.schema.json; fields are listed in data-model.md § 7.

{
  "osap": "0.1",
  "type": "TransparencyLogEntry",
  "log_id": "log:chronicle.example",
  "index": 421337,
  "logged_at": "2026-07-01T08:00:12Z",
  "attestation_id": "osap:attestation:sha256:4a44dc15364204a80fe80e9039455cc1608281820fe2b24f1e5233ade6af1dd5",
  "attestation_hash": {
    "alg": "sha256",
    "value": "b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c"
  },
  "issuer": "did:web:good-news.example",
  "asset_hash": "4a44dc15364204a80fe80e9039455cc1608281820fe2b24f1e5233ade6af1dd5"
}

attestation_hash is the SHA-256 of the attestation document itself (so the log commits to the exact signed bytes), while the optional asset_hash duplicates the subject's exact-bytes fingerprint to make asset-oriented queries possible without fetching every attestation.

3. Earlier Matching Source

A verifier examining an attestation for asset hash H can query log data for entries with asset_hash = H. If an entry exists whose logged_at (or whose attestation's issued_at, corroborated by an earlier logged_at) precedes the attestation under examination, and its issuer differs, the verifier can populate earlier_source in the verification result (data-model.md § 8) and show:

⚠ Earlier matching source found from good-news.example

The worked result in ../examples/verification-result-earlier-source-found.json shows an issuer outside the selected bundle claiming an image after another issuer attested the same exact bytes eleven days earlier. This establishes only the observed chronology, not which issuer is the source.

Because v0.1 fingerprints are exact-bytes only, a re-encoded copy has a different hash and will not match. Perceptual matching is a separate future extension.

4. Explicitly Deferred

The following mechanisms are not specified in v0.1:

• Merkle inclusion and consistency proofs — v0.1 entries are bare records; a log operator could omit or reorder entries without cryptographic detection.
• Signed log heads, gossip/witnessing between logs, and split-view detection.
• Log discovery, submission APIs, and rate limiting.
• Query privacy for log lookups (a log query leaks interest in an asset, exactly like a hash lookup API — the warnings in privacy.md apply).
• Relay networks and Nostr-like distribution of log entries.

Given these omissions, log data can provide only weak corroborating evidence and does not prove chronology. Verifiers should identify the log operator in the UI, for example, "according to log:chronicle.example".