OSAP

Appearance

Trust Bundles ​

Status and BCP 14 terminology are defined in Status of This Document.

This document defines signed trust policies for evaluating issuers by scope and time. Temporal evaluation is defined in temporal-trust.md.

1. Role of Trust Bundles ​

A trust bundle records a maintainer's assessment of attestations from an issuer for specified claim categories and time periods. A bundle does not determine whether content is true. OSAP defines no global trust authority, default bundle, or aggregate trust score.

2. Document Format ​

A trust bundle MUST validate against osap-trust-bundle.schema.json; fields are defined in data-model.md § 5. It is signed by its maintainer using the same proof mechanism as envelopes (envelope.md § 6): JCS canonicalization, Ed25519, DataIntegrityProof with cryptosuite eddsa-jcs-2026, signing input being the document minus proof.proofValue.

  • The maintainer id SHOULD be a did:web identifier so the bundle signature can be verified via the maintainer's issuer metadata (identity.md).
  • expires_at SHOULD be set. Verifiers MUST warn the user when evaluating against an expired bundle and SHOULD offer to fetch the current version.
  • Each entry maps one issuer identifier to one or more trust periods (temporal-trust.md). Trust periods SHOULD carry a reason, and SHOULD carry evidence for statuses of high_caution or untrusted, so users can inspect why a status was assigned.

Examples: ../examples/trust-bundle-basic.json, ../examples/trust-bundle-temporal.json.

3. Trust Statuses ​

StatusMeaning assigned by the maintainer
trustedAttestations from this issuer, within scope and period, are regarded as reliable by this maintainer.
limited_trustReliable only within the stated scope, or reliability is under review.
high_cautionAttestations should be treated with strong skepticism within the stated scope.
untrustedThe maintainer regards this issuer's attestations as unreliable within the stated scope.

Two further statuses appear only in verification results, never in bundles: outside_bundle (issuer has no entry) and no_bundle (the user selected no bundle). See data-model.md § 8.1.

Note (informative): Statuses are assessments attributable to the bundle maintainer. Different bundles may assign different statuses to the same issuer.

4. Scoping ​

A trust period MAY carry a scope array of claim-category strings (e.g. publication_claims, correction_claims, local_reporting, political_claims). Absent scope means the period applies to all claim categories.

Scope strings are an open vocabulary in v0.1; maintainers SHOULD document their categories in the bundle description or accompanying material. A shared registry of claim categories is an open issue (index.md § 11).

5. Evaluation Algorithm ​

Given an attestation (issuer I, issued at time T_issued, carrying claims), a verification time T_now, and a selected bundle, the verifier MUST:

  1. Verify the bundle itself. Check the bundle's schema and proof (via the maintainer's published keys). A bundle whose signature fails MUST NOT be used; report the failure to the user.
  2. Find the issuer entry. Locate the entry whose issuer equals I. If none exists, the result is status: "outside_bundle" with historical_status and current_status both null, and the warning label "Issuer outside selected trust bundle".
  3. Select applicable periods by scope. Determine the claim categories relevant to the attestation's claims. A trust period is in scope if it has no scope array, or if its scope intersects the relevant categories. In v0.1 the mapping from claim types to categories is bundle-defined; verifiers unable to map claims MUST fall back to treating only unscoped periods as applicable, and SHOULD report scoped periods to the user for manual inspection.
  4. Evaluate historically. Among in-scope periods, find those covering T_issued (valid_from ≤ T_issued, and valid_until absent or > T_issued). The resulting status is historical_status. No covering period yields null.
  5. Evaluate currently. Repeat step 4 with T_now, yielding current_status.
  6. Resolve overlaps. If multiple in-scope periods cover the same instant with different statuses, the verifier MUST use the most cautious one, ordered untrusted > high_caution > limited_trust > trusted. Maintainers SHOULD avoid overlapping periods.
  7. Report. Populate trust_result per data-model.md § 8.1 (status carries the historical evaluation) and emit labels per temporal-trust.md and ui-labels.md.

6. Maintainer Responsibilities ​

A conforming trust bundle maintainer (see conformance.md):

  • MUST sign every bundle version and keep its verification keys discoverable.
  • MUST record status changes by closing periods and opening new ones, never by silently rewriting history. When a maintainer's assessment of a past period changes, it SHOULD amend that period with a stated reason, preserving the distinction between the earlier and revised assessments in the bundle's version history.
  • MUST NOT present the bundle as an authority on truth; a bundle is a documented, attributable policy.
  • SHOULD publish bundles at a stable HTTPS URL, version them (e.g. an id suffix like :v0.1), set expires_at, and keep superseded versions retrievable.
  • SHOULD state reasons and evidence for negative statuses, and a documented process for issuers to dispute entries.

7. Bundle Selection by Users ​

  • Verifiers MUST let the user choose which bundle (or none) to apply, and MUST NOT hard-code a default bundle that cannot be replaced.
  • Verifiers MAY ship with suggested bundles, but selection MUST remain visible and changeable, and the active bundle's id MUST be reported in every trust_result.
  • Verifiers MAY support evaluating multiple bundles side by side; each evaluation MUST be reported separately, never merged into a combined score.
  • A verifier MUST NOT reveal the user's selected bundles to any party as a condition of verification (privacy.md).

8. Forkability and Replaceability ​

Anyone MAY copy a bundle, modify it, and republish it under their own maintainer identity and bundle id. The resulting fork is a new signed bundle and does not modify the original. OSAP grants no bundle a privileged position. See threat-model.md for the malicious trust bundle maintainer case.