Managing Revocation and Conflicting Claims

Real-world information arrives out of order. A certificate is uploaded; weeks later the certification body withdraws it, effective from a date that has already passed. A distributor describes the certificate's scope differently from the supplier. A buyer's reviewer confirmed the original claim before any of this happened. A system that stores only "the latest document" cannot explain yesterday's answer; a system that only appends prose cannot say what holds now.

Thesis. "Current state" is not the last thing written; it is the result of evaluating an append-only history for a stated subject, time point, knowledge cut, viewer and purpose — and revocation, late evidence and conflict each change that result in different, non-interchangeable ways.

Four boundaries to get right

1. Revocation does not erase history. Withdrawing a claim changes its current standing; it does not remove the fact that the claim was made, by whom, when, and what others did on the basis of it. A certificate withdrawn in May was still asserted in March and still confirmed by a reviewer in March. Deleting or overwriting those records would make every past decision unexplainable. Established mechanisms work the same way: an X.509 certificate revocation list marks a certificate revoked without un-issuing it (RFC 5280), and verifiable credentials express revocation or suspension through a separate status entry rather than by altering the credential (VC Data Model 2.0; Bitstring Status List).

2. Late evidence is not automatically more authoritative. Arriving later says nothing about standing. A late notice from the certification body that issued a certificate carries weight because of who issued it and under what policy, not because it is newer. A late contrary claim from an unrelated party is a new, competing assertion — not a correction.

3. Conflict is a result, not a winner. When two independent sources make incompatible claims about the same question, the honest output is that they disagree. Choosing the newest, the most confident, or the majority is a policy decision; without an explicitly applicable policy and authority, no winner should be selected.

4. "Current" needs four coordinates. Any statement of current state must say for which subject (and which site, product or scope), as of which time — both the business time being asked about and the knowledge cut of what the system had received — for which viewer (what that requester may see), and for which purpose. Two correct answers can differ because any one of these differs.

How these map onto Tinor's protocol

Tinor's protocol records history as Atomic Events on per-object, append-only chains. There are six core event types, grouped by what they act on:

Three consequences matter here:

• Revocation targets an exact prior event, by identifier and hash, and only a party with standing over that event may revoke it. An issuer may withdraw its own assertion; it cannot withdraw someone else's merely by referencing it. It can instead dissent.
• Dissent is a verification with a negative verdict, not a new event type and not a separate claim. Keeping dissent attached to what it disputes is what stops disputes from silently disappearing from derived conclusions.
• Conflict is not an event type or a stored object. It is a read-time value relation computed over eligible assertions that answer the same question. Tinor's resolution contract distinguishes at least single, convergent, conflicting, indeterminate, partial and unavailable, and treats these as orthogonal to coverage and confirmation — a result can be both conflicting and partial. Whether two assertions answer "the same question" is decided by the owning Profile's fact identity (subject, period, scope, basis), never by text similarity. Different scopes or periods are different questions, not a conflict.

Time is tracked with distinct meanings, in the spirit of bitemporal modelling (Fowler, 2021): the claimed occurred time of a business event, the recorded time at which an instance received it, the knowledge cut that bounds what a query may use, and the evaluation time at which validity is judged. A hash chain proves order and integrity within an object; it does not prove absolute real-world time.

This vocabulary is protocol-level. The worked example below is illustrative; which readers implement which parts in production is a separate question addressed at the end.

A worked timeline: five events, three queries

All parties and documents are fictional. Facility A belongs to supplier S. Certificate C-123 is an ISO 9001 certificate issued by certification body CB. Distributor D resells S's products. Buyer B has an access grant to S's restricted evidence; the public does not.

Each query below states its coordinates: subject Facility A / C-123, purpose supplier qualification, viewer B unless noted, and a time point where evaluation time equals knowledge cut unless noted.

T1 — 2026-04-01. Known: E1, E2. Certification status: one eligible assertion (single), from S, within its stated validity window, with one current confirmation from B's reviewer that cites a register check. Scope: single ("injection-moulded parts"). Expected answer to B: S asserts C-123 is valid until 2028-03-31 for injection-moulded parts; B's reviewer confirmed it against CB's register on 2026-03-05. To a public viewer: the same statement without the restricted PDF, and with the confirmation only if B's review is disclosable to the public — usually it is not.

T2 — 2026-06-15. Known: E1, E2, E3. Certification status: unchanged (single, confirmed). Scope: D's assertion answers the same question as S's (scope of C-123) with an incompatible value, so the scope relation is conflicting. Both are retained; no winner is selected, because no policy gives D or S authority over the other's statement. Expected answer: status as at T1; scope reported as disputed between S ("injection-moulded parts") and D ("assembled units only"). An agent should not answer a scope-sensitive question as if either were settled.

T3 — 2026-07-10. Known: E1–E5. E1 is withdrawn by its own issuer, so it is no longer eligible. E2 remains in history as a true record of what B's reviewer did on 2026-03-05, but it no longer contributes a current confirmation, because its target is no longer active. E4 is CB's own assertion that the certificate was withdrawn. Expected answer: C-123 is not currently held: CB reports withdrawal effective 2026-05-20, and S has withdrawn its claim. History: S asserted the certificate from 2026-03-01; B's reviewer confirmed it on 2026-03-05. D's scope claim (E3) is still on record, but scope is moot for a withdrawn certificate.

Replaying the past. Two further queries show why the time coordinates must be separate:

• Evaluate business time 2026-06-01 with knowledge cut 2026-06-15: the answer is T2's. This is what we knew then — the basis for any decision made on 2026-06-15, and it must stay reproducible.
• Evaluate business time 2026-06-01 with knowledge cut 2026-07-10: CB's late notice claims withdrawal from 2026-05-20, so with today's knowledge the certificate was already withdrawn on 2026-06-01. This does not rewrite the earlier answer; it explains why the earlier answer, though correct for its knowledge, was overtaken.

Why E4 resolves status but E3 does not resolve scope. CB is the issuer of C-123; a buyer's policy may reasonably treat the issuer's statement about its own certificate as decisive for status. That is a policy with a named authority, applied explicitly — not a consequence of E4 being later. If D, rather than CB, had claimed the withdrawal, the honest status at T3 would be conflicting between S and D, pending S's own withdrawal or a check against CB.

Design rules that follow

• Store changes as attributable events, never as in-place field overwrites — in provenance terms, every statement keeps its agent, activity and derivation (PROV-O).
• Scope revocation to an exact target and check the revoker's standing.
• Record dissent against the claim it disputes, so it survives into derived views.
• Compute conflict at read time from Profile-defined fact identity; retain all alternatives.
• Make every current-state answer carry its subject, time coordinates, viewer and purpose, and keep historical answers replayable under their original knowledge cut.
• Treat "no eligible assertion" as a gap, not as evidence of absence.

Limits and open problems

• Policy, not physics. Whether an issuer's withdrawal settles status is a consumer policy. Different consumers may adopt different policies over the same history; the protocol keeps that explicit rather than imposing one.
• Fact identity is the hard part. Deciding that D's and S's statements answer the same question requires a Profile contract for that claim type. Where none exists, the honest relation is indeterminate, which is less useful but not wrong.
• Bounded implementation. Tinor's standing and conflict contracts are implemented for specific readers and claim types in the reference implementation; complex compositions — for example, withdrawing a withdrawal — are reported as unsupported rather than guessed. This note does not claim universal automatic resolution.
• Backdated claims. A claimed-occurred time is a claim. A late notice asserting an effective date in the past should be evaluated for the issuer's standing to make it; the protocol does not treat claimed time as proven time.

Related Tinor work

Business Presence surfaces source distinctions and maintained status; Business Response escalates conflicts and withdrawals to a human rather than reconciling them in generated text. Forthcoming engineering notes in the Engineering Reality State series — Truth Has a Time Dimension and When Two Sources Disagree, Who Decides? — develop the time and adjudication questions raised here.

References

• W3C (2025). Verifiable Credentials Data Model v2.0 — validity period and status mechanisms. w3.org
• W3C. Bitstring Status List v1.0 — a credential revocation/suspension mechanism. w3.org
• Cooper, D. et al. (2008). RFC 5280: X.509 Certificate and CRL Profile — revocation of certificates without deleting issuance history. rfc-editor.org
• W3C (2013). PROV-O: The PROV Ontology — entities, activities, agents and attribution. w3.org
• Fowler, M. (2021). Bitemporal History — separating business time from record time. martinfowler.com