OSAP

Appearance

Privacy Requirements ​

Status and normative language: See Status of This Document.

1. Offline Verification ​

  • A verifier MUST be able to execute the full verification algorithm (verification.md) entirely offline, given local copies of: the attestation, the asset bytes, the issuer metadata, the issuer's revocation list, and the selected trust bundle.
  • No verification step may require contacting the issuer, the maintainer, or any third party at verification time. Network fetches may acquire inputs but are not a precondition for evaluating them.
  • Verifiers SHOULD cache issuer metadata, revocation lists, and trust bundles to make offline operation the common case, and MUST report staleness honestly (e.g. revoked: null or a stale-list warning) rather than refusing to verify.

2. Verification Event Reporting ​

  • The protocol contains no telemetry, no verification-reporting channel, and no callback to issuers. Verifier implementations MUST NOT report verification events (which attestation was verified, when, by whom, with what result) to any party as part of implementing OSAP.
  • Issuers MUST NOT design attestations or metadata so that verification requires a per-verification request to issuer infrastructure (e.g. one-time URLs or per-asset tokens).

3. Hash Lookup Privacy ​

Querying a hash lookup API (discovery.md § 6) discloses to the lookup operator the content fingerprint, the requesting network endpoint, and the query time. The same disclosure applies to transparency log queries (transparency-logs.md).

  • Verifiers MUST NOT perform hash lookups by default. Lookup MUST be opt-in, either per query or via an explicit, revocable setting whose privacy consequence is stated where it is enabled.
  • Verifiers SHOULD prefer discovery mechanisms that leak nothing beyond ordinary retrieval of the asset (sidecar files, in-band Link/<link> advertisement) and MUST attempt them before any lookup (discovery.md § 7).
  • Lookup operators SHOULD publish a retention policy; verifiers MAY surface it at the opt-in point.

4. Trust-Bundle Selection Privacy ​

  • Clients MUST NOT be required to reveal their selected trust bundles to any party. Bundle evaluation is local (trust-bundles.md § 5); the protocol does not transmit the selection.
  • Verifiers MUST NOT embed the selected bundle identity in any outbound request (e.g. lookup queries, metadata fetches).
  • Fetching a bundle necessarily reveals interest in it to the party serving it. Verifiers SHOULD mitigate this where practical (caching, mirrors, bulk fetching) and MUST NOT add identifying information beyond what the transport requires.

5. Data Minimization in Published Documents ​

  • Issuers SHOULD NOT place personal data in public, signed, durable attestations beyond what the attestation's purpose requires, and MUST NOT include information about verifiers or users in any OSAP document.
  • Revocation withdraws a claim but does not erase the record (claims.md § 4.4); it is not a data-deletion mechanism. Issuers SHOULD treat anything placed in an attestation as permanent.

6. Future Extension Areas (Non-Normative) ​

Private or encrypted attestations, anonymous-credential issuers, and private-information-retrieval lookups are future extension areas and are not specified in v0.1.