Threat Model
Document status: Informative. See Status of This Document.
This document is informative. Normative requirements are defined in the referenced protocol documents, including privacy.md, security-considerations.md, ui-labels.md, and trust-bundles.md.
OSAP establishes that an issuer signed a fingerprint of an asset at a stated time with a stated claim. It does not determine whether the content or claim is true. The threats below distinguish attacks on protocol properties from risks outside those properties.
1. Propaganda Outlet Signs an Altered Image
Threat. An issuer alters an image, signs a SourceAttestation for it with its valid key, publishes both correctly, and presents the valid signature as an endorsement of the content. The evidence checks pass because the issuer signed those bytes.
Protocol behavior. The signature remains valid. UI requirements prohibit a generic "verified" result and require separate signature and trust labels (ui-labels.md). The result includes "Signature valid: signed by outlet.example" and may include "Issuer outside selected trust bundle" or a caution-level trust status, together with "Claim is made by issuer, not proven as true". If log data contains an earlier attestation of the unaltered original, the verifier can display "Earlier matching source found" (transparency-logs.md).
Residual risk. OSAP does not detect that the image was altered and does not evaluate content truth.
Relevant labels. "✓ Signature valid: signed by …", "⚠ Issuer outside selected trust bundle", "⚠ Claim is made by issuer, not proven as true", "⚠ Earlier matching source found from …".
Example. ../examples/verification-result-untrusted-issuer.json.
2. Metadata Stripping and Screenshot Laundering
Threat. An attacker screenshots or re-encodes attested content and redistributes the copy. The new bytes have a different exact-bytes hash.
Protocol behavior. The original attestation does not validate the altered copy. Attaching it to the copy produces "✕ Asset hash does not match signed fingerprint". The attested original remains verifiable when available.
Residual risk. OSAP v0.1 cannot associate the screenshot with the original. Exact-bytes fingerprints do not survive re-encoding, and perceptual matching is a future extension area. The copy appears unattested, and unattested content carries no negative label (discovery.md § 7).
Relevant labels. "✕ Asset hash does not match signed fingerprint" (when the mismatched attestation is attached); otherwise absence of labels.
3. Reupload Without Attestation
Threat. An attacker reuploads byte-identical attested content without the sidecar or link advertisement.
Protocol behavior. The byte-identical copy retains the original fingerprint. A verifier that holds the attestation or finds it through opt-in hash lookup or log data can associate it with the copy and display "Earlier matching source found".
Residual risk. Discovery is not guaranteed. Without lookup opt-in (privacy.md § 3) or prior knowledge, the reupload appears unattested.
Relevant labels. "⚠ Earlier matching source found from …" (when chronology data is available).
4. Issuer Key Compromise
Threat. An attacker obtains an issuer's signing key and issues attestations as the issuer. The attacker can backdate issued_at because it is asserted by the issuer.
Protocol behavior. The key-compromise procedure requires the issuer to publish the key in revoked_keys with revoked_at at the earliest suspected compromise time, rotate keys, and revoke known forgeries (identity.md § 6). Attestations with issued_at at or after revoked_at produce an error label. For attestations dated before revoked_at, the procedure reports historical validity and directs verifiers to warn that the key was later revoked because backdating cannot be excluded. Independent chronology can bound backdating for logged attestations.
Residual risk. Unlogged forgeries backdated before revoked_at are cryptographically indistinguishable from genuine pre-compromise attestations. An earlier revoked_at invalidates more genuine attestations; a later value permits more forgeries.
Relevant labels. "✕ Signing key revoked at time of issuance", "⚠ Signing key was later revoked", "⚠ Attestation revoked by issuer".
5. Issuer Ownership Change (Trust Drift)
Threat. Control of a trusted issuer's domain, organization, or keys changes through sale, acquisition, or domain lapse. The new controller inherits the identifier and its prior trust status. Because did:web identity represents domain control, this is a change in trust assumptions rather than an identity-binding failure (identity.md § 7).
Protocol behavior. Under temporal trust, bundle maintainers close the trusted period at the change and open a new period with an appropriate status (temporal-trust.md). Earlier attestations retain "published during previously trusted period"; later attestations carry the current status. Temporal Trust § 4 provides an example.
Residual risk. Detection and recording of the ownership change occur outside the protocol. Until a bundle is updated, new attestations evaluate under the prior status. The new controller can also backdate issued_at into the trusted period; logs can bound this only where available.
Relevant labels. "ⓘ Published during previously trusted period", "⚠ Source marked high caution by selected trust bundle", "⚠ Source had limited trust when this was published".
6. Malicious Trust Bundle Maintainer
Threat. A bundle maintainer assigns misleading statuses or rewrites past periods.
Protocol behavior. Bundles are signed and attributable. Statuses can include inspectable reasons and evidence and are scoped and time-bound. Trust Bundles § 8 prohibits verifiers from hard-coding an irreplaceable default. Prior signed versions permit detection of historical rewrites.
Residual risk. A malicious bundle produces a malicious interpretation for users who select it. The protocol does not define an authority that can overrule a bundle.
Relevant labels. All trust-interpretation labels; the bundle id reported in trust_result identifies the applicable bundle.
7. Revocation Suppression (Stale Revocation Lists)
Threat. An attacker serves an old pre-revocation list or blocks retrieval from the issuer's revocation endpoint.
Protocol behavior. Revocation lists carry updated_at; the normative procedure recommends signing them so that fabricated replacements are detectable. Verification § 3, Step 6 requires an unreachable list to produce revoked: null with "Revocation status could not be checked", not revoked: false, and recommends a warning when a cached list exceeds an implementation-defined age.
Residual risk. OSAP v0.1 cannot detect replay of a valid stale list within the freshness window. It defines no freshness proof or transparency mechanism for revocation lists.
Relevant labels. "? Revocation status could not be checked", "⚠ Revocation list may be stale", vs "✓ Attestation not revoked".
8. Hash Lookup Surveillance
Threat. A lookup operator, log operator, or network observer records content fingerprints, requesting endpoints, and query times.
Protocol behavior. Core verification can operate offline (privacy.md § 1). Hash lookup is opt-in (privacy.md § 3), discovery uses local mechanisms first (discovery.md § 7), and verifiers do not transmit the user's bundle selection (privacy.md § 4).
Residual risk. An opted-in query reveals its fingerprint to the operator. Private information retrieval is a future extension area.
Relevant labels. None. This is verifier behavior covered by conformance.md, not a verification outcome.
9. Downgrade Attacks (Stripping Attestations)
Threat. An intermediary redistributes attested content after deleting its sidecar and removing Link headers or <link> elements.
Protocol behavior. Removal does not create an endorsement. Discovery § 7 prohibits negative labels for the absence of an attestation; no positive label is assigned. If the verifier obtains the attestation through a cache, opt-in lookup, or log data, a byte-identical copy still matches its fingerprint.
Residual risk. OSAP v0.1 does not indicate that content should have carried an attestation. Issuer outboxes (outbox_url) and transparency logs could support completeness policies, but such policies are not specified in v0.1.
Relevant labels. None on the stripped copy by default; discovery-dependent labels when the attestation is recovered.
10. Summary Table (Non-Normative)
| Threat | Affected property | Protocol behavior |
|---|---|---|
| Altered content signed with a valid key | None; the signature evidence is valid | Separate labels; trust-bundle evaluation; no generic "verified" |
| Screenshot laundering | Fingerprint linkage | Hash mismatch label; perceptual matching deferred |
| Reupload without attestation | Discovery | Byte-identical fingerprint; opt-in lookup; logs |
| Key compromise | Signature attribution | Key revocation with revoked_at; logs bound backdating |
| Ownership change | Trust assumptions | Temporal trust periods; dual status reporting |
| Malicious bundle maintainer | Interpretation layer | Signed, inspectable, forkable, replaceable bundles |
| Revocation suppression | Revocation freshness | Distinct null and false results; signed lists; staleness warnings |
| Lookup surveillance | User privacy | Offline verification; opt-in lookup; no bundle-selection disclosure |
| Attestation stripping | Availability of evidence | No negative default; multi-channel discovery |