OSAP Attestation Types and Claims

Status: See Status of This Document.

This document normatively defines the five attestation types and the baseline claim types of OSAP v0.1.

1. Claim Semantics

Verifiers and user interfaces MUST NOT present claims as OSAP-verified facts. See ui-labels.md for the required labeling, including the warning label "Claim is made by issuer, not proven as true".

Each claim is an issuer assertion. Successful verification establishes that the issuer signed the claim about a specific asset fingerprint at a specific time. Trust-bundle interpretation is defined in trust-bundles.md.

2. Claim Objects

A claim is an object with:

• type (REQUIRED, string) — the claim type.
• value (OPTIONAL, any JSON value) — the claim's content. Its shape depends on the claim type.
• note (OPTIONAL, string) — free-text explanation by the issuer.

Claim types are open-ended strings in v0.1. Verifiers MUST NOT fail verification because they encounter an unknown claim type; they MUST still report the claim as an issuer assertion. The baseline claim types below have defined semantics.

3. Baseline Claim Types

Claim type	Typical value	Meaning (as asserted by the issuer)
published_by	true	"I published this asset."
original_source_claim	true	"I am the original source of this asset."
derivative_of_original	true	"This asset is a derivative of an original I reference in derived_from."
correction	string	"I am correcting something I previously attested"; the string describes the correction.
revocation	string	"I withdraw a previous attestation"; the string states why.
context	string	"Here is context about this asset"; the string carries the contextual statement.

Note (non-normative): original_source_claim does not establish actual origin. An earlier matching fingerprint in a transparency log (transparency-logs.md) is contrary evidence and produces the "Earlier matching source found" label.

4. Attestation Types

The envelope type member selects one of five types. Common structure is defined in envelope.md.

4.1 SourceAttestation

The issuer attests that it published the subject asset and, optionally, claims to be its original source.

• MUST include a subject with at least one exact-bytes fingerprint.
• SHOULD include published_by and MAY include original_source_claim.
• Example: ../examples/source-attestation.json.

4.2 DerivativeAttestation

The issuer attests that the subject asset was derived from other attested content.

• MUST include a subject covering the derivative asset.
• MUST include at least one derived_from entry referencing the attestation of the source asset by attestation_id, optionally with a relation (crop, resize, transcode, excerpt, translation, composite, other) and a note.
• SHOULD include a derivative_of_original claim.
• The lineage is an issuer assertion; verification does not establish that the transformation occurred. Example: ../examples/derivative-attestation.json.

4.3 CorrectionAttestation

The issuer records a correction to something it previously attested.

• MUST include corrects with the id of the corrected attestation.
• SHOULD include a subject covering the corrected content (for example, the corrected article) and a correction claim describing what changed.
• A correction does not invalidate the corrected attestation. The original remains valid evidence of what was published; the correction adds to the record. Verifiers MUST surface known corrections when presenting the corrected attestation (see verification.md).
• Example: ../examples/correction-attestation.json.

4.4 RevocationAttestation

The issuer withdraws a previous attestation.

• MUST include revokes with the id of the revoked attestation.
• SHOULD include a revocation claim stating the reason.
• MAY omit subject, since the target is an attestation rather than an asset.
• Revocation withdraws the issuer's claim; it does not erase the historical record that the claim was made. Verifiers presenting a revoked attestation MUST label it as revoked rather than hiding it (see ui-labels.md).
• Issuers SHOULD also add the revoked attestation to their revocation list (data-model.md § 6); the revocation list is what verifiers poll, while the RevocationAttestation is the signed, inspectable record of the act.
• Example: ../examples/revocation-attestation.json.

4.5 ContextAttestation

An issuer — often a third party such as a fact-checking desk — attaches contextual information to an asset it did not necessarily publish.

• MUST include a subject fingerprinting the asset the context is about.
• SHOULD include a context claim carrying the contextual statement, and SHOULD include evidence entries supporting it.
• A ContextAttestation is the issuer's signed opinion about the asset. Its trust status is determined by the user's selected trust bundle.
• Example: ../examples/context-attestation.json.

5. Multiple Attestations per Asset

Any number of issuers MAY attest the same fingerprint, including with conflicting claims. Verifiers MUST be able to present multiple attestations for one asset side by side, each with its own evidence results and trust interpretation, and MUST NOT merge them into a single aggregate judgment. OSAP does not arbitrate conflicts.

6. Future Extension Areas (Non-Normative)

The following are explicitly out of scope for v0.1 and reserved as extension areas: perceptual and content-aware fingerprint scopes, C2PA interoperability, richer machine-readable claim vocabularies, private or encrypted attestations, and claim schemas negotiated between issuers and verifiers.