# RFC-VERITAS-VC-v0.1 — Validator Credential Issuance & Revocation

**Status:** Working draft v0.1 · *Editor:* Collaborative Fact-Checking Working Group · *Date:* April 2026

> *This document specifies how validators in the Veritas Protocol obtain, present, rotate, and revoke verifiable credentials that authorise them to attest within named consensus domains. The protocol is permissionless at the chain-write layer — anyone with a cryptographic identity can post a signed attestation — so credentials are post-hoc reputation primitives, not pre-hoc admission gates. Credentials let CPML authors filter the validator pool to those whom a credential-issuing institution has vouched for in a specific domain.*

---

## Status of this document

Working draft. Comments at § 11. The format follows W3C Verifiable Credentials Data Model 2.0 conventions and is intended as upstream input to the W3C Credentials Community Group.

## Abstract

Validators on the Veritas Protocol post signed attestations about primary claims; the protocol does NOT gatekeep who can post. The post-hoc reputation layer that lets consumers filter the validator pool is a system of **verifiable credentials**: an academic institution credentials its faculty in `scientific-default-cochrane-grade`, a court credentials its judges in `legal-jurisdiction-eu`, a journalism school credentials its alumni in `journalism-default`, and so on. A user's CPML names which credentials count and how they weight. This RFC specifies the credential format (W3C VC 2.0 profile), issuance and revocation flows, scope-of-authorisation semantics (credentials are domain-scoped), and the on-chain credential registry described in `spec/ARCHITECTURE.md` § 1.3.3.

## 1 · Introduction

### 1.1 Motivation

The protocol's permissionless write layer is a structural commitment: a single foundation cannot credentialise validators neutrally across mutually-hostile cohorts (state-aligned narratives, ideologically-opposed religious traditions, dissident communities). What the foundation CAN do is operate a **credential-registry** through which independent issuing bodies publish credentials that consumers may choose to weight or ignore.

Consumer-side filtering is the load-bearing trust mechanism. A user's CPML says "for `scientific-default-cochrane-grade`, I trust attestations whose signing validator presents a credential issued by Cochrane Collaboration; ignore everything else for that domain." Without standard credential format and issuance flow, every CPML implements its own validator-trust logic ad hoc and the protocol's plural-verdict promise becomes brittle.

### 1.2 Scope

This document specifies:

- **Issuer profile** — who issues credentials, and the institutional-vetting criteria (§ 3).
- **Credential schema** — the JSON-LD shape of a Veritas validator credential (§ 4).
- **Domain-scoped authorisation semantics** — a credential authorises attestations only within named consensus domains (§ 5).
- **Revocation** — Status List 2021 profile for compact revocation checking (§ 6).
- **Lifecycle** — issuance, renewal, rotation, recovery from compromised key (§ 7).
- **On-chain registration** — encoding the credential into the L2 Validator Credential Registry (§ 8).
- **Conformance** — what issuers, validators, and aggregators MUST do (§ 9).

Out of scope:
- Reputation math composing per-validator weight from credential set + cross-attestation agreement signals (specified by federation aggregators; not normative here).
- Validator-side cryptographic-identity creation (any W3C-compliant DID method works; see `RFC-VERITAS-CASCADE-v0.1` § 8 for hardening guidance for high-impact contexts).
- Foundation governance over issuer-vetting decisions (foundation-charter document).

### 1.3 Terminology

Standard BCP 14 terminology. Domain-specific:

- **Issuer** — an institution authorised to issue Veritas validator credentials in one or more named domains.
- **Subject** (or **holder**) — a validator who has received a credential; may use the credential to enrich their attestations with provenance.
- **Verifier** — a federation aggregator that consumes credentials when applying CPML filtering rules.
- **Credential subject DID** — the DID of the validator the credential is about.
- **Credential issuer DID** — the DID of the issuing institution.

## 2 · Architecture context

The credential layer interacts with three other layers:

```
ISSUER (academic, journalistic, governmental, religious, civil-society institution)
  ↓ issues credential (W3C VC 2.0; signs with issuer DID; publishes status list)
SUBJECT (validator)
  ↓ presents credential when attesting; credential metadata is included with attestation
L2 ATTESTATION REGISTRY + VALIDATOR CREDENTIAL REGISTRY
  ↓ aggregator reads attestation + checks credential validity + checks revocation
L3 FEDERATION AGGREGATOR
  ↓ applies user CPML's credential-filter rules; composes verdict
L4 CONSUMER (browser ext / MCP grounding / CPML profile file)
```

The credential is presented WITH the attestation; it is NOT a precondition for the attestation to be recorded on-chain. An uncredentialed attestation is still valid data on the L2 Attestation Registry; CPMLs simply choose whether to weight it.

## 3 · Issuer profile

### 3.1 Eligibility

An institution may apply to be a credential-issuer. Eligibility is established through:

- **Independent legal personality** — a registered foundation, university, journal, court, government office, or comparable institution. Anonymous or pseudonymous individuals are NOT eligible to issue.
- **Domain expertise** — the institution publicly maintains expertise in the domains it will issue for. A medical journal credentials in `scientific-default-cochrane-grade` because that domain is its established competence; the same journal does NOT credential in `legal-jurisdiction-eu`.
- **Editorial independence** — the institution is not under the direct editorial control of a state party with a stake in any specific claim. (Some state-affiliated institutions are appropriate issuers in their own right — a national academy, a national statistics office, a national court — but they MUST be transparently scoped: a state-academy credential is good evidence about that state's mainstream science, not a global authority.)
- **Public-vetting process** — the institution's own validator-vetting process is itself public and reviewable.

### 3.2 Vetting

The Veritas Foundation maintains a directory of vetted issuers. Vetting:

- **Application** — the institution submits a public application describing its domains, vetting process, governance structure, and contact information.
- **Public-comment window** — the application is published for 30 days of public comment.
- **Foundation review** — the foundation's editorial board reviews application + comments and either approves, requests amendments, or rejects.
- **Dispute-panel ratification** — approvals require dispute-panel simple-majority for non-controversial issuers, supermajority (7-of-9) for issuers in politically-sensitive domains.
- **Annual re-attestation** — issuers re-attest their continued eligibility annually.

### 3.3 Listing

The vetted-issuer directory is published as a JSON-LD document at `https://veritas-protocol.example/issuers/v0.3.jsonld`. Aggregators refresh the directory at least every 24 hours.

Each directory entry contains: issuer DID, institution name, listed domains, governance link, vetting history, current status (active / suspended / retired).

## 4 · Credential schema

A Veritas validator credential is a W3C Verifiable Credential v2.0 with the following JSON-LD shape:

```jsonld
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://veritas-protocol.example/vc/v0.1"
  ],
  "type": ["VerifiableCredential", "VeritasValidatorCredential"],
  "issuer": "did:plc:cochrane-collaboration",
  "issuanceDate": "2026-04-01T00:00:00Z",
  "expirationDate": "2027-04-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:plc:dr-jane-doe",
    "type": "VeritasValidator",
    "name": "Jane Doe",
    "authorisedDomains": [
      "scientific-default-cochrane-grade",
      "scientific-default-peer-review-mainstream"
    ],
    "institutionalAffiliation": "did:web:university.edu",
    "credentialTier": "individual"
  },
  "credentialStatus": {
    "id": "https://veritas-protocol.example/issuers/cochrane/status/2026-04",
    "type": "StatusList2021Entry",
    "statusListIndex": "94567",
    "statusListCredential": "https://veritas-protocol.example/issuers/cochrane/status/2026-04#list"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2026-04-01T00:00:00Z",
    "verificationMethod": "did:plc:cochrane-collaboration#key-2026",
    "proofPurpose": "assertionMethod",
    "proofValue": "..."
  }
}
```

### 4.1 Required fields

- `@context` — MUST include both the W3C VC 2.0 context and the Veritas VC context.
- `type` — MUST include both `VerifiableCredential` and `VeritasValidatorCredential`.
- `issuer` — DID of the issuing institution. MUST be in the foundation's vetted-issuer directory.
- `issuanceDate` and `expirationDate` — REQUIRED. Maximum credential validity is 2 years; longer expirations are rejected by aggregators.
- `credentialSubject.id` — DID of the credentialed validator.
- `credentialSubject.authorisedDomains[]` — REQUIRED. One or more canonical consensus-domain names (per `RFC-VERITAS-CPML-REGISTRY-v0.1`). The credential authorises attestations ONLY in these domains.
- `credentialSubject.credentialTier` — one of `individual`, `institutional`, `editorial-board` (see § 5.2).
- `credentialStatus` — REQUIRED. A `StatusList2021Entry` for compact revocation checking.
- `proof` — REQUIRED. Either `DataIntegrityProof` with `eddsa-jcs-2022` cryptosuite (RECOMMENDED) or a JWS proof.

### 4.2 Optional fields

- `credentialSubject.institutionalAffiliation` — DID of an additional affiliated institution.
- `credentialSubject.specialisations[]` — narrower sub-domain expertise within the authorised domains.
- `credentialSubject.languageOfCompetence[]` — IETF language tags identifying which languages the validator competently attests in.

## 5 · Domain-scoped authorisation

### 5.1 Scope

A credential's `authorisedDomains[]` is the EXCLUSIVE set of domains in which the credential carries weight. An attestation in a domain NOT in the credential's authorisedDomains is treated as uncredentialed for purposes of CPML filtering — even if the validator holds a separate credential for some other domain.

This is structural: a Cochrane-credentialed reviewer attesting in `legal-jurisdiction-eu` carries no Cochrane authority for that legal claim. The CPML composer does not silently extend credentials across domains.

### 5.2 Tiers

`credentialTier` distinguishes:

- **`individual`** — credentialed person (e.g., a faculty member, a senior journalist, a court judge). Scope is the person's expertise; revocable by the issuing institution.
- **`institutional`** — credentialed institution (e.g., a publication, a research group, a chamber of commerce). The institutional credential allows attestations to be signed on the institution's behalf, with internal sign-off rules opaque to the protocol.
- **`editorial-board`** — credentialed group operating under joint authority (e.g., a journal's editorial board, a trial chamber). Attestations require multi-signature from board members; the credential carries higher reputation weight per attestation than individual or institutional.
- **`chapter-convenor`** — credentialed individuals authorised to co-sign cascade events (per `RFC-VERITAS-CASCADE-v0.1` § 4.2) and other foundation-roster operations. Chapter-convenor credentials are issued by the Veritas Foundation, NOT by independent issuers in the vetted-issuer directory of § 3. The `authorisedDomains[]` field for a chapter-convenor credential is interpreted as the cascade-event domains the convenor may co-sign for (typically the convenor's chapter's domain set), and the credential additionally carries the `authorisedCascadeEventClasses[]` and `authorisedImpactTiers[]` claims described in § 5.4.

CPML authors may filter or weight by tier. A skeptical CPML may require `editorial-board` tier for the highest weight. The `chapter-convenor` tier is operationally distinct: chapter-convenor credentials are not used by CPML composers for primary-attestation weighting; they are used by aggregators for cascade-event verification.

### 5.3 Aggregation

Multiple credentials per validator are common. A medical researcher may hold credentials from Cochrane (in `scientific-default-cochrane-grade`), a national academy (in `scientific-default-academy-consensus`), and her university (in `software-engineering` if she also publishes in ML). Each credential is independent; revoking one does NOT revoke the others.

CPML composers MAY apply rules like "weight × log(credential_count_in_domain)" to reward broadly-credentialed validators, but no such rule is normative.

### 5.4 Chapter-convenor extension claims

Chapter-convenor credentials (tier `chapter-convenor`) carry two additional claims beyond the standard subject fields:

```jsonld
{
  "credentialSubject": {
    "id": "did:plc:convenor-jane",
    "type": "VeritasValidator",
    "credentialTier": "chapter-convenor",
    "name": "Jane Doe",
    "chapter": "did:web:eu-chapter.veritas-protocol.example",
    "jurisdictionISO": "DE",
    "institutionalType": "academic",
    "authorisedDomains": ["scientific-default", "legal-jurisdiction-eu"],
    "authorisedCascadeEventClasses": [
      "cascade:RETRACTED_BY_SOURCE",
      "cascade:REVERSED_BY_FORENSIC_RECOVERY",
      "cascade:CORRECTED_BY_SOURCE",
      "cascade:SUPERSEDED_BY_REVISION",
      "cascade:AUTHORITY_TRANSFERRED",
      "cascade:EMERGENCY_EXPEDITION"
    ],
    "authorisedImpactTiers": ["high", "critical"]
  }
}
```

- `chapter` — the DID of the chapter the convenor represents.
- `jurisdictionISO` — ISO 3166-1 alpha-2 country code; used by aggregators to verify the jurisdictional-diversity requirement of `RFC-VERITAS-CASCADE-v0.1` § 4.2.
- `institutionalType` — one of `academic`, `civil-society`, `governmental`, `journalistic`, `religious`, `professional` (used for the institutional-diversity requirement).
- `authorisedCascadeEventClasses[]` — the cascade-event types the convenor may co-sign for. A convenor's authorisation MAY be limited to a subset (e.g., a journalism-chapter convenor may co-sign retraction-class events but not authority-transfer events).
- `authorisedImpactTiers[]` — the impact tiers (`low`, `medium`, `high`, `critical`) the convenor may co-sign at. Most chapter-convenor credentials authorise `high` and `critical` (the tiers requiring co-signature); some may authorise additional tiers for specialised use cases.

Chapter-convenor credentials are issued under the foundation's governance charter; issuance criteria, revocation triggers, and renewal cycle are specified in the foundation charter (separate document, not normative in this RFC).

Aggregators verifying a cascade event with co-signatures MUST:
- verify each co-signer holds a `chapter-convenor` credential issued by the foundation;
- verify the credential's `authorisedCascadeEventClasses[]` includes the event's `@type`;
- verify the credential's `authorisedImpactTiers[]` includes the event's effective tier;
- verify the jurisdictional + institutional diversity requirements per `RFC-VERITAS-CASCADE-v0.1` § 4.2 using the `jurisdictionISO` and `institutionalType` fields.

This closes the V2 super-review finding C2 (chapter-convenor credentials referenced in CASCADE but not present in VC).

## 6 · Revocation (Status List 2021)

The protocol uses **W3C Status List 2021** for compact revocation checking. Each issuer maintains a status list per quarter (or more frequently) at a stable URL; each credential's `credentialStatus` field points into the list at a specific bit position.

### 6.1 Status list shape

```jsonld
{
  "@context": ["https://www.w3.org/ns/credentials/v2", "https://w3.org/2021/status-list/v1"],
  "type": ["VerifiableCredential", "StatusList2021Credential"],
  "issuer": "did:plc:cochrane-collaboration",
  "validFrom": "2026-04-01T00:00:00Z",
  "credentialSubject": {
    "type": "StatusList2021",
    "statusPurpose": "revocation",
    "encodedList": "<base64url-encoded zlib-compressed bitstring>"
  },
  "proof": { ... }
}
```

The `encodedList` is a 16,384-bit (2KB compressed) bitstring with one bit per indexed credential. Bit value 1 = revoked; 0 = active.

### 6.2 Aggregator behaviour

Aggregators MUST:

- Fetch the status list referenced by every credential they verify.
- Cache the status list with its declared `validFrom` / `validUntil`.
- Refresh the cache at least every 24 hours.
- Reject (do not weight) attestations whose credential's status bit is 1.

If the status list URL is unreachable, the aggregator MUST refuse to weight the attestation (fail-closed). This prevents an attacker from suppressing revocation by DoS'ing the status-list endpoint.

### 6.3 Reasons for revocation

Common revocation triggers:

- **Compromised key** — the validator's signing key is known to be compromised; all attestations signed after the compromise window are suspect.
- **Misconduct** — the validator has demonstrably attested in bad faith; the issuing institution exercises its prerogative to withdraw the credential.
- **Departure** — the validator no longer represents the issuing institution (resignation, retirement, expulsion).
- **Re-issuance** — the validator's prior credential is rolled forward into a new credential with updated parameters; the old credential is revoked to prevent confusion.

## 7 · Lifecycle

### 7.1 Issuance

A new credential is issued through the issuing institution's normal vetting process. The credential is delivered to the validator (via secure channel — out of scope here). The validator chooses whether to enrich subsequent attestations with credential proof.

### 7.2 Renewal

Credentials expire (max 2 years per § 4.1). Renewal is a fresh issuance with a new credential ID; the old credential's `expirationDate` is reached at which point aggregators stop weighting it. Issuers SHOULD issue renewal credentials at least 30 days before expiration to give validators time to update their on-chain credential references.

### 7.3 Key rotation

Validators rotate signing keys periodically. A key rotation does NOT invalidate the credential — the credential is bound to the validator's DID, not to a specific key. The validator updates the DID document with the new key. Aggregators verify attestations against the DID document's current key set.

### 7.4 Recovery from compromised key

If a validator's signing key is compromised:

1. The validator publishes an emergency DID-document update revoking the compromised key.
2. The validator notifies the issuing institution(s).
3. The issuing institution(s) revoke the credential via their status list (bit set to 1).
4. The validator SHOULD obtain a new credential after generating a new signing key.

Attestations signed by the compromised key BEFORE the DID-document-update timestamp are interpretable but their reliability is questionable; aggregators MAY (but are not required to) discount them. The dispute-panel may declare specific compromised-key attestations as cascade-event-target events for forensic reversal under `RFC-VERITAS-CASCADE-v0.1`.

## 8 · On-chain registration

The L2 Validator Credential Registry is a smart-contract event log on Base L2. Each credential's existence is registered (not the credential body itself, only the cryptographic commitment to it):

```solidity
event ValidatorCredentialRegistered(
  bytes32 indexed credentialHash,        // SHA-256 of the canonicalised credential
  address indexed issuerAccount,         // issuer DID resolved to chain account
  address indexed subjectAccount,        // subject DID resolved to chain account
  bytes32         authorisedDomainsHash, // SHA-256 of sorted domain list
  uint256         issuanceTimestamp,
  uint256         expirationTimestamp
);
```

The full credential body is stored off-chain (issuer's URL or IPFS) and referenced by hash. Revocation status is checked via the Status List 2021 endpoint; on-chain revocation is NOT recorded (would be too expensive given the rate of revocations).

This hybrid (off-chain credential + on-chain commitment + off-chain revocation list) is consistent with W3C VC 2.0 patterns and avoids the L2 cost overhead of recording every credential body on-chain.

## 9 · Conformance

### 9.1 Issuers

Issuers MUST:

- Be listed in the foundation's vetted-issuer directory.
- Issue credentials following the v2.0 W3C VC profile defined in § 4.
- Maintain a Status List 2021 endpoint with at least 24-hour freshness.
- Re-attest annually.
- Publish their internal vetting process.

### 9.2 Validators

Validators using credentials MUST:

- Hold the credential before referencing it in attestations.
- Reference the credential's `credentialStatus.statusListCredential` URL in their attestation envelope so verifiers can check revocation.
- Stop referencing a credential within 24 hours of receiving notice of its revocation.

### 9.3 Aggregators (verifiers)

Aggregators verifying credentials MUST:

- Verify the issuer DID is in the vetted-issuer directory.
- Verify the credential's cryptographic proof against the issuer's published key.
- Verify the credential's status (per § 6.2 fail-closed semantics).
- Verify that the validator's `consensus_domain` on the attestation is in the credential's `authorisedDomains[]`.

### 9.4 CPML authors

CPML authors using credential-based filtering MUST express their filter rules in the CPML's `validator_credentialing[]` section (per `RFC-CPML-v0.1` § 5).

## 10 · Comments and amendments

Comments welcomed at the contact form. Future amendments may broaden the supported cryptosuites or add new credential tiers as governance evolves.

## 11 · References

- `spec/ARCHITECTURE.md` § 1.3.3 (Validator Credential Registry).
- `spec/cpml/RFC-CPML-v0.1.md` § 5 (validator-credentialing rules in CPML).
- `spec/cpml-registry/RFC-VERITAS-CPML-REGISTRY-v0.1.md` (canonical domain names).
- `spec/cascade/RFC-VERITAS-CASCADE-v0.1.md` § 8 (DID hardening for high-impact issuers).
- W3C Verifiable Credentials Data Model 2.0 (15 May 2025).
- W3C Decentralized Identifiers v1.0 (19 July 2022; v1.1 Candidate Recommendation).
- W3C Status List 2021.
- W3C Data Integrity Proofs.
- IETF RFC 8785 (JCS).

---

*Drafted as forthcoming-RFC stub for v0.3 (workstream W6 partial). Cross-referenced from `spec/ARCHITECTURE.md` and the V0.3 plan. Comments welcome. — Collaborative Fact-Checking Working Group, April 2026.*