Evidence Revocation and Status Protocol for Proof of Process

Introduction The Proof of Process (PoP) specification defines how Attesters generate Evidence during document authorship. However, Evidence is not immutable once generated. Authors may need to:

Mark old Evidence as superseded by newer Evidence
Revoke Evidence if it was generated in error or under duress
Update Evidence status after device key compromise
Correct declarations or metadata errors

This document defines protocols for Evidence status management and revocation, as well as a Verifier registry enabling federated verification services.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Evidence Status Model

Status Values Evidence packets may have the following status values:

active:: Evidence is current and valid. This is the default status for newly generated Evidence.
superseded:: Evidence has been replaced by a newer Evidence packet. The superseding packet-id is recorded. Superseded Evidence remains verifiable but should not be considered current.
revoked:: Evidence has been explicitly revoked by the author. Revoked Evidence should not be trusted. A revocation reason is recorded.
suspended:: Evidence is temporarily suspended pending investigation or dispute resolution. May transition to active, revoked, or remain suspended.
expired:: Evidence has exceeded its validity period (if one was declared). Expired Evidence may still be verifiable for historical purposes but should not be considered current.

Status Update Structure Status updates are CBOR-encoded structures signed by the original Evidence author. The following CDDL defines the status update format: Status transitions MUST follow these rules:

active MAY transition to any other status
superseded is terminal (no further transitions)
revoked is terminal (no further transitions)
suspended MAY transition to active or revoked
expired MAY transition to revoked only

The signature MUST be created using the same key that signed the original Evidence packet. If the original key is compromised, the key compromise protocol in applies.

Revocation Mechanisms

Author-Initiated Revocation Authors may revoke their own Evidence by publishing a signed revocation statement. The statement includes:

packet-id of the revoked Evidence
Revocation reason code
Optional explanatory text
Timestamp of revocation
Author signature (using same key that signed Evidence)

Key Compromise Handling When a device signing key is compromised, all Evidence signed by that key may be affected. The key compromise protocol:

Author generates new device key
Author publishes key compromise notice (signed by new key + optional secondary authentication)
Notice specifies compromise window (earliest and latest possible compromise times)
Evidence within compromise window is marked as suspicious
Evidence outside window may be re-endorsed with new key

Revocation Distribution Revocation information may be distributed through:

Well-known URI: /.well-known/witnessd-revocations
Revocation list embedded in Attestation Results
Push notifications to subscribed Verifiers
Blockchain or transparency log publication

External Verifier Registry This section defines a protocol for discovering trusted Verifiers and obtaining federated verification services.

Verifier Discovery Organizations may publish their trusted Verifiers at: This endpoint returns a signed JSON document listing:

Trusted Verifier identities and endpoints
Verifier certificates
Supported appraisal policies
Service level agreements

Federated Verification Federated verification enables Relying Parties in one organization to accept Attestation Results from Verifiers in another organization. The protocol operates as follows:

Relying Party receives Evidence packet from an author
Relying Party queries its organization's trusted Verifier list
If the author's organization has a trusted Verifier, the Relying Party forwards the Evidence to that Verifier
The remote Verifier appraises the Evidence and returns an Attestation Result
The Attestation Result is signed by the remote Verifier and includes the Verifier's identity for accountability
The Relying Party validates the Attestation Result signature against the trusted Verifier list

Trust delegation allows organizations to designate other Verifiers as authoritative for specific author domains. Delegation statements are signed by the delegating organization and published in the Verifier registry. Attestation Results from federated Verifiers MUST include:

Original Evidence packet-id
Verifier identity and organization
Appraisal policy applied
Timestamp of verification
Result validity period

Verifier Accountability Verifiers MUST maintain audit logs of all appraisal operations. Audit logs include:

Timestamp of each appraisal request
Evidence packet-id appraised
Appraisal policy applied
Result issued (without sensitive details)
Requesting party identifier (if authenticated)

Audit logs MUST be retained for a minimum of 7 years to support legal and compliance requirements. Logs SHOULD be stored in append-only format to prevent tampering. Misbehavior reporting enables Relying Parties to report Verifiers that issue inconsistent or incorrect Attestation Results:

Relying Party detects inconsistency (e.g., same Evidence receives conflicting results from same Verifier)
Relying Party submits misbehavior report to registry operator
Registry operator investigates and may revoke Verifier listing
Misbehavior reports are published for transparency

Organizations MAY implement reputation scoring for Verifiers based on consistency, availability, and misbehavior history. Reputation scores are advisory and do not replace explicit trust decisions.

Security Considerations

Revocation Freshness Verifiers MUST check revocation status using fresh data. Cached revocation lists have a maximum validity period (RECOMMENDED: 24 hours for general use, 1 hour for high-security contexts).

Revocation Service Availability Verifiers MUST handle revocation service unavailability gracefully. Two modes are defined:

Hard-fail mode:: If revocation status cannot be determined, the Verifier MUST reject the Evidence as unverifiable. This mode is RECOMMENDED for high-security contexts where accepting potentially revoked Evidence poses significant risk.
Soft-fail mode:: If revocation status cannot be determined, the Verifier MAY accept the Evidence with a warning flag indicating revocation status is unknown. The Attestation Result MUST clearly indicate this condition. This mode is acceptable for lower-risk contexts where availability is prioritized.

Verifiers SHOULD implement the following availability measures:

Cache revocation lists with appropriate TTL
Support multiple revocation distribution endpoints
Implement exponential backoff for failed queries
Monitor revocation service health proactively

Relying Parties MUST be informed of the Verifier's failure mode and MAY override the default based on their risk tolerance.

Revocation Privacy Revocation queries may reveal which Evidence packets a Verifier is checking, potentially leaking information about document verification patterns. The following mitigations apply:

Verifiers SHOULD download complete revocation lists rather than querying individual packet-ids to prevent query correlation
Revocation services MUST NOT log individual query patterns in a way that enables tracking specific Verifier behavior
Batch queries SHOULD be supported to allow Verifiers to check multiple packet-ids in a single request, reducing metadata leakage

For high-privacy deployments, Verifiers MAY use Private Information Retrieval (PIR) techniques to query revocation status without revealing which packet-id is being checked. PIR support is OPTIONAL and deployment-specific. Revocation lists MUST NOT include information beyond what is necessary for status determination. Specifically, revocation reasons are available only to authenticated parties with a legitimate need to know.

Privacy Considerations This section addresses privacy implications of Evidence status management and Verifier registry operations.

Verifier Tracking Prevention Verifiers process Evidence from multiple authors and may accumulate significant metadata about verification patterns. To prevent misuse:

Verifiers MUST NOT correlate verification requests across different Relying Parties without explicit consent
Verification logs MUST be purged of personally identifiable information after the retention period expires
Verifiers MUST NOT share verification metadata with third parties except as required by law

Metadata Minimization Status updates and revocation statements contain metadata that could be privacy-sensitive. Implementations MUST:

Include only the minimum metadata necessary for status determination
Avoid including IP addresses, device identifiers, or location data in status update structures
Use opaque packet-ids that do not encode author identity

Anonymous Verification Mode For privacy-sensitive contexts, Verifiers MAY support anonymous verification where:

Relying Party identity is not required for verification
No verification logs are retained
Rate limiting is applied to prevent abuse

Anonymous verification provides weaker accountability guarantees and is not suitable for all deployment contexts. Verifiers MUST clearly document whether anonymous mode is supported.

IANA Considerations This document requests registration of the following well-known URIs:

URI suffix: witnessd-revocations
URI suffix: witnessd-verifiers

Change controller: IETF Specification document: [this document]