§6 C2PA: unverifiable

1.0 §9 imposes an unconditional MUST — “when a manifest is present it MUST be validated” — over a three-value status vocabulary that has no term for the common outcome: a well-formed manifest whose validation could not be completed. Under 1.0 a Producer facing an unreachable trust list, an expired signer, or an unimplemented claim generator must either report a falsehood or omit provenance.c2pa and forfeit L3 (E28).

provenance.c2pa.status gains a fourth value, unverifiable: a manifest is present and structurally well-formed, and validation could not be completed.

reason is REQUIRED when status is unverifiable, and MUST NOT be present otherwise (both halves schema-encoded). It is a machine-readable token, one of:

Token	Meaning
unsupported_algorithm	A signature or hash algorithm in the manifest is not implemented
trust_store_unavailable	The trust list or anchor set could not be consulted
manifest_malformed	The manifest is present and parseable enough to detect, but its structure defeated validation
network_unavailable	A required network fetch (OCSP, timestamp, remote manifest) failed
credential_unavailable	The signer's certificate or key could not be obtained
validator_error	The validator failed for a reason internal to it

or an authority-namespaced escape <authority>/x-<token> for a case this list does not cover. A Consumer MUST treat an unrecognised reason as validator_error for the purpose of acting, and MUST preserve the value it received.

error_detail is OPTIONAL and non-normative in every status: free human-readable text for an operator. A Consumer MUST NOT branch on it. It was REQUIRED-and-only-for-unverifiable in an earlier revision of this draft, which put a machine obligation on a string written for people; reason now carries the machine obligation and error_detail carries the explanation.

unverifiable MUST NOT be used in place of invalid. A manifest that was validated and failed is invalid, always. A Consumer MUST NOT treat unverifiable as any degree of positive evidence: it carries exactly the trust of an unsigned assertion, and any assertion sourced from such a manifest carries trust tier unsigned, never c2pa_verified.

The E28 consistency rules stand: availability.c2pa: "present" and provenance.c2pa.status ∈ {valid, invalid, unverifiable} are two views of one fact and MUST agree.