OSAP

Appearance

OSAP — Open Source Attestation Protocol ​

1. Abstract ​

OSAP (Open Source Attestation Protocol) specifies how to publish, discover, and verify signed claims about content fingerprints, issuer identity, chronology, derivation, correction, and revocation. It also specifies how a verifier applies a user-selected trust bundle without treating a claim as a verified fact.

2. Status of This Document ​

This is an experimental draft (v0.1) developed in the open. It is not a standard, is not endorsed by any standards body, and every part of it is subject to breaking change. Feedback is welcome via the repository's issue tracker.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals.

All documents in the Document Roadmap are normative except transparency-logs.md and threat-model.md, which are informative. Sections and notes explicitly marked informative or non-normative do not define requirements.

3. Scope and Goals ​

OSAP v0.1 specifies:

  • Signed, inspectable claims that can be published using a domain, a key pair, and static files.
  • Local verification without a network connection, registry, or permission when the required inputs are available.
  • Separate reporting of evidence checks and trust-bundle interpretation.
  • Signed, attributable trust policies scoped by time and claim category.
  • Additive correction and revocation records that preserve prior evidence.
  • Offline operation without required disclosure of reading activity or trust-bundle selection.

4. Non-Goals ​

OSAP v0.1 does not:

  • Determine whether content is true, accurate, or authentic in any editorial sense.
  • Provide or endorse any global trust authority, global registry, default trust list, trust score, or truth rating.
  • Issue "verified" badges of any kind (see ui-labels.md).
  • Detect content manipulation (OSAP fingerprints exact bytes; it has no opinion about pixels).
  • Replace or interoperate with C2PA in v0.1.

The following are future extension areas, deliberately unspecified in v0.1: blockchain anchoring, perceptual hashing, C2PA support, ActivityPub federation, DID resolution beyond did:web, global registries, trust scores, truth ratings, relays, transparency logs beyond the minimal non-normative sketch in transparency-logs.md, IPFS transport, Nostr-like relay networks, private encrypted attestations, and post-quantum signatures.

5. Terminology ​

Terms including attestation, envelope, issuer, fingerprint, trust bundle, trust period, and historical and current trust status are defined in terminology.md.

6. Roles ​

  • Issuer: Creates and signs attestations; identified by did:web (identity.md).
  • Verifier: Checks schemas, canonical forms, fingerprints, signatures, and revocations, and evaluates a selected trust bundle (verification.md).
  • Trust bundle maintainer: Publishes signed trust policies (trust-bundles.md).
  • User: Consumes verification results and selects a trust bundle, if any.
  • Log operator (extension area): Operates an append-only chronology record (transparency-logs.md).
  • Relay (extension area): Redistributes attestations it did not issue; relay behavior is unspecified in v0.1.

A party can perform multiple roles.

7. Document Roadmap ​

The specification consists of the following 16 documents, in recommended reading order:

  1. index.md — scope, status, roles, roadmap, and open issues.
  2. terminology.md — terms used throughout the specification.
  3. data-model.md — document and field definitions.
  4. envelope.md — envelope structure, identifiers, canonicalization, and signing.
  5. claims.md — attestation and claim types.
  6. identity.md — issuer identity, metadata, and key handling.
  7. discovery.md — attestation and metadata discovery.
  8. verification.md — verification algorithm and result semantics.
  9. trust-bundles.md — trust-bundle format and evaluation.
  10. temporal-trust.md — historical and current trust evaluation.
  11. transparency-logs.md — non-normative transparency-log extension.
  12. privacy.md — privacy requirements.
  13. security-considerations.md — implementation security requirements and guidance.
  14. threat-model.md — attack analysis and protocol treatment.
  15. ui-labels.md — result-labeling requirements.
  16. conformance.md — conformance levels and test-vector requirements.

8. Protocol Overview ​

An issuer publishes a signed envelope containing an asset fingerprint and claims. A verifier validates the document, canonicalizes it with JCS, checks the exact-byte SHA-256 fingerprint, resolves the issuer's did:web Ed25519 key, verifies the signature, checks revocation status, and optionally evaluates a user-selected trust bundle at issuance time and verification time. The verifier reports each outcome separately.

9. Transport Model ​

OSAP v0.1 uses HTTPS static JSON files and GET endpoints. Fetches MUST use HTTPS with certificate validation (security-considerations.md § 7). Verification is transport-independent after the required documents are obtained and supports offline operation (privacy.md § 1).

Relays, federation, IPFS, and Nostr-like distribution are future extension areas.

10. Test Vectors ​

Test vectors are in ../test-vectors/; coverage is specified in conformance.md § 5. Documents in ../examples/ are structural fixtures whose proofValue fields are placeholders. Vectors under test-vectors/valid/ and test-vectors/invalid/ contain signatures made with keys in test-vectors/keys/.

11. Open Issues ​

Tracked here during the draft period; none of these are settled:

  1. Extension mechanism. All schemas set additionalProperties: false; there is no way to extend documents without a version bump. A namespaced extension member is under consideration.
  2. Claim-category vocabulary. Trust-period scope strings are an open vocabulary; scope matching across bundles needs at least a registry convention (trust-bundles.md § 4).
  3. osap-attestation link relation registration with IANA (discovery.md § 4).
  4. Attestation id uniqueness. The id derives from the asset hash, so two issuers attesting the same asset produce the same id; (issuer, id) pairing works but a self-describing globally unique form is under discussion (envelope.md § 3).
  5. RevocationAttestation identifiers. The id format presumes a subject asset hash; the convention for subject-less attestations is unsettled.
  6. Revocation-list freshness. No mechanism prevents replay of stale signed lists (threat-model.md § 7).
  7. Verification-result signing. Whether verifiers should optionally sign results for auditability.
  8. Multiple simultaneous bundles. Side-by-side evaluation is permitted; whether a standard presentation exists for disagreeing bundles is open.
  9. Test-vector completeness. The test-vectors/ directory covers the MVP verification checks; coverage for discovery mechanisms and edge-case canonicalization is still growing.