OSAP

Appearance

Conformance ​

Status and normative language: See Status of This Document.

This document defines the OSAP v0.1 conformance levels and normative requirement checklists.

1. Conformance Levels ​

OSAP v0.1 defines three conformance levels. An implementation MAY claim more than one.

LevelApplies to
OSAP Verifier (Basic)Software that verifies attestations and presents results
OSAP Issuer (Basic)Parties that create and publish attestations
OSAP Trust Bundle MaintainerParties that publish trust bundles

Extension areas (transparency logs, relays, perceptual fingerprints, etc.) have no conformance levels in v0.1; implementations experimenting with them MUST NOT describe that behavior as OSAP-conformant.

2. OSAP Verifier (Basic) ​

A conforming basic verifier:

  1. MUST validate documents against the JSON Schemas in ../schemas/ and reject documents that fail, per verification.md § 3, Step 1.
  2. MUST implement JCS (RFC 8785) canonicalization and the signature verification procedure of envelope.md § 6.2, including strict Ed25519 verification and the 64-byte unpadded-base64url proofValue requirement (security-considerations.md § 2).
  3. MUST compute exact-bytes SHA-256 fingerprints and compare them against subject.asset_hashes (verification.md § 3, Step 3).
  4. MUST resolve did:web issuer metadata from /.well-known/osap.json over HTTPS, verify the id binding, and decode Multikey Ed25519 keys (identity.md).
  5. MUST evaluate key validity at the attestation's issued_at, and MUST NOT invalidate signatures merely because the key has since expired (identity.md § 5, security-considerations.md § 6).
  6. MUST execute the verification algorithm steps in the order given in verification.md and produce results conforming to osap-verification-result.schema.json, distinguishing true/false/null outcomes.
  7. MUST implement revocation checking, reporting an unreachable list as null ("could not be checked"), never as "not revoked" (verification.md § 3, Step 6).
  8. MUST implement trust-bundle evaluation, including bundle signature verification, scope matching, and dual historical/current temporal evaluation (trust-bundles.md § 5, temporal-trust.md).
  9. MUST report historical and current trust status separately; current distrust MUST NOT erase or hide historical trust, and vice versa (temporal-trust.md § 3).
  10. MUST allow the user to select, replace, or deselect trust bundles; MUST NOT hard-code an irreplaceable default (trust-bundles.md § 7).
  11. MUST be able to verify fully offline given local attestation, asset, issuer metadata, revocation list, and bundle; MUST NOT phone home; MUST make hash lookup opt-in; MUST NOT reveal the user's bundle selection to any party (privacy.md).
  12. MUST implement the labeling requirements of ui-labels.md, including the prohibition on generic "verified" indicators, when it presents results to users. (A library verifier with no UI satisfies this by emitting the label catalogue in its results.)
  13. MUST support sidecar and well-known discovery, SHOULD support Link-header and HTML <link> discovery, and MAY support hash lookup (discovery.md).
  14. SHOULD pass the applicable test vectors (§ 5).

3. OSAP Issuer (Basic) ​

A conforming basic issuer:

  1. MUST publish issuer metadata at https://<domain>/.well-known/osap.json over HTTPS, valid against osap-issuer.schema.json, with id matching the serving domain's did:web identifier (identity.md § 3).
  2. MUST publish at least one Multikey Ed25519 key and keep superseded keys published after rotation (identity.md § 5).
  3. MUST produce envelopes valid against osap-envelope.schema.json, carrying "osap": "0.1", signed per envelope.md § 6.1 with issuer.key_id equal to proof.verificationMethod.
  4. MUST compute fingerprints as SHA-256 over exact bytes, lowercase hex, scope: "exact-bytes".
  5. MUST make each attestation discoverable through at least one of the five mechanisms in discovery.md; SHOULD support sidecar files.
  6. MUST publish a revocation list valid against osap-revocation-list.schema.json (which MAY be empty), SHOULD sign it, and SHOULD reference it via revocation.status_url in envelopes.
  7. MUST use RevocationAttestation/revocation-list entries to withdraw attestations, and MUST NOT attempt to retract by deleting or altering published attestations — a changed document simply fails its signature (claims.md § 4.4).
  8. MUST follow the key-compromise procedure of identity.md § 6 when a key is compromised.
  9. MUST NOT describe OSAP attestations as proving content truth in the surrounding presentation; see ui-labels.md § 1.
  10. SHOULD issue CorrectionAttestations for substantive corrections, and SHOULD include evidence where claims rest on identifiable sources (claims.md).

4. OSAP Trust Bundle Maintainer ​

A conforming trust bundle maintainer:

  1. MUST publish bundles valid against osap-trust-bundle.schema.json, signed per envelope.md § 6, with verification keys discoverable (SHOULD: via did:web issuer metadata).
  2. MUST express all trust as trust periods with explicit status values; MUST NOT publish any aggregate numeric trust score or truth rating.
  3. MUST record status changes by closing and opening periods, preserving history rather than silently rewriting it (trust-bundles.md § 6).
  4. MUST version bundles, SHOULD set expires_at, and SHOULD keep superseded versions retrievable.
  5. SHOULD provide reason for every period and evidence for high_caution and untrusted periods.
  6. SHOULD document its claim-category scope vocabulary and a dispute process for listed issuers.
  7. MUST NOT present its bundle as an authority on truth or as the canonical OSAP trust source; bundles are replaceable and forkable (trust-bundles.md § 8).

5. Test Vectors ​

Conformance test vectors are in the ../test-vectors/ directory. Coverage includes:

  • JCS canonicalization inputs and expected canonical bytes (canonicalization/), including number- and Unicode-edge cases.
  • Signed scenarios with real keys (keys/): one directory per case under valid/ (source, derivative, correction, context, revocation attestation) and invalid/ (modified envelope or asset after signing, malformed proof, unknown/expired/revoked key, missing issuer metadata, revoked attestation, trust-period and scope mismatches), each bundling the attestation, issuer metadata, revocation list, trust bundle, and expected verification result.
  • Temporal trust evaluation against bundles mirroring ../examples/trust-bundle-temporal.json, verifying dual historical/current status output.

The documents in ../examples/ additionally serve as structural fixtures; their proofValue fields are placeholders and do not verify cryptographically.