UI Labeling Requirements

Status and normative language: See Status of This Document.

1. Aggregate Indicators

• Implementations MUST NOT display a generic "verified" badge, checkmark, seal, or equivalent aggregate indicator for OSAP results. This prohibition includes wording such as "verified", "authentic", "genuine", or "real" without a named check and visual shorthand, such as a lone green checkmark on content, that implies such a judgment.
• Implementations MUST NOT collapse multiple check results into a single pass/fail indicator. Each dimension below is labeled separately.
• Rationale (non-normative): all evidence checks can pass for false content signed by its creator (threat-model.md § 1). An aggregate indicator does not preserve the distinction between signature validity and content truth.

2. Labeling Dimensions

A conforming verifier UI MUST use distinct labels for each of the following dimensions, and MUST NOT merge dimensions into one indicator:

1. Signature validity — did the cryptographic proof verify, and under whose key?
2. Identity binding — was the issuer's key discovered via its did:web metadata, and was it valid at issuance?
3. Asset integrity — do the local bytes match the signed fingerprint?
4. Chronology — when was this issued; is there earlier evidence of the same content elsewhere?
5. Lineage — is this asset attested as derived from other attested content?
6. Correction / revocation status — has the issuer corrected or withdrawn this attestation?
7. Trust-bundle interpretation — how does the user's selected bundle regard this issuer, historically and currently?

3. Label Catalogue

Labels are objects with a level (success, info, warning, error, unknown) and a text, per data-model.md § 8. The catalogue below is normative for semantics and level. The exact wording SHOULD be followed in English UIs and MUST be translated meaning-preservingly otherwise. {…} marks substituted values. Display glyphs (✓ ⚠ ⓘ ✕ ?) are RECOMMENDED renderings of the level and are not part of the label text.

3.1 Signature validity and identity binding

Level	Label	MUST be shown when
success	✓ Signature valid: signed by	valid_signature: true. The issuer MUST be named in the label.
error	✕ Signature invalid	valid_signature: false.
unknown	? Issuer key not found: signature not checked	Key discovery failed; valid_signature: null.
error	✕ Signing key was not valid when attestation was issued	issuer_key_valid: false (validity window).
error	✕ Signing key revoked at time of issuance	Key revoked with revoked_at ≤ issued_at.
warning	⚠ Signing key was later revoked	Key revoked with revoked_at > issued_at (identity.md § 6).
unknown	? Attestation is not a valid OSAP 0.1 document	Schema or canonicalization failure (an error presentation is also acceptable); nothing further was checked.

3.2 Asset integrity

Level	Label	MUST be shown when
success	✓ Exact asset matches signed fingerprint	asset_hash_match: true.
error	✕ Asset hash does not match signed fingerprint	asset_hash_match: false.
unknown	? Asset not available: fingerprint match not checked	asset_hash_match: null and the envelope has a subject.

3.3 Chronology and lineage

Level	Label	MUST be shown when
warning	⚠ Earlier matching source found from	earlier_source is populated.
info	ⓘ Attested as derived from earlier attested content ({relation})	Envelope is a DerivativeAttestation with derived_from; wording MAY be adapted to the relation.
info	ⓘ Issued at	RECOMMENDED whenever an attestation is displayed; issued_at SHOULD always be visible (security-considerations.md § 5).

3.4 Correction and revocation

Level	Label	MUST be shown when
success	✓ Attestation not revoked	revoked: false.
warning	⚠ Attestation revoked by issuer:	revoked: true. The attestation MUST remain viewable as historical evidence, labeled — never silently hidden (claims.md § 4.4).
unknown	? Revocation status could not be checked	revoked: null. MUST NOT be rendered like "not revoked".
warning	⚠ Revocation list may be stale	Only a cached list older than the implementation's freshness threshold was available.
info	ⓘ Correction issued by source	A known CorrectionAttestation targets this attestation; the correction MUST be reachable from the label.

3.5 Trust-bundle interpretation

Level	Label	MUST be shown when
success	✓ Source trusted for {scope} under selected bundle	Historical status trusted; scope named when the matched period is scoped.
warning	⚠ Issuer outside selected trust bundle	trust_result.status: "outside_bundle".
info	ⓘ No trust bundle selected: issuer not evaluated	trust_result.status: "no_bundle".
warning	⚠ Source had limited trust when this was published	Historical status limited_trust.
warning	⚠ Source marked high caution by selected trust bundle	Historical status high_caution (append "when this was published" when the current status differs).
warning	⚠ Source marked untrusted by selected trust bundle	Historical status untrusted.
info	ⓘ Published during previously trusted period	Historical status trusted AND current status is worse or null. MUST accompany, not replace, the current-status label (temporal-trust.md § 3).
warning	⚠ Source currently marked {current status} by selected trust bundle	Current status is limited_trust, high_caution, or untrusted and differs from historical.
warning	⚠ Claim is made by issuer, not proven as true	Claims are present and historical status is not trusted (including outside_bundle / no_bundle). MAY be shown unconditionally.

4. Presentation Rules

• All labels produced by verification MUST be available to the user. Compact surfaces MAY summarize per dimension (e.g. an icon per dimension) provided the full labels are one interaction away; they MUST NOT summarize across dimensions into one indicator (§ 1).
• Error and warning labels MUST NOT be visually subordinated to success labels. A valid signature MUST NOT be styled to overshadow a trust warning on the same result.
• The identity named in the signature label MUST be the cryptographically bound one (issuer domain / DID, optionally with the self-asserted name), never the name alone, since name carries no identity weight (identity.md § 1).
• The selected bundle's identity MUST be inspectable from any trust-interpretation label, so the user can see whose interpretation they are reading.
• Absence of attestations MUST NOT produce any negative label on content (discovery.md § 7).
• Label text MUST name the check, not the conclusion: "Signature valid: signed by example.com" is conformant; "Content verified" is not.

Worked label sets appear in the three verification-result examples: ../examples/verification-result-valid.json, ../examples/verification-result-untrusted-issuer.json, ../examples/verification-result-earlier-source-found.json.