VC Types: Operational, Legal, Simulation, Credentialal

Structuring Verifiable Credentials by Functional Role and Governance Scope in the NSF Protocol

5.2.1 Why VC Typing Matters

The NSF Protocol uses Verifiable Credentials (VCs) to authorize actions, enforce policy, and prove trust in a zero-trust, decentralized environment. Different types of VCs serve different functions:

• Operational VCs: authorize task-level actions (e.g., disaster deployment)

• Legal VCs: bind agents to treaty, jurisdictional, or contractual compliance

• Simulation VCs: certify forecasting models and outputs used in policy decisions

• Credentialal VCs: attest to the validity of other credentials (meta-credentials)

Each type must follow strict schemas, revocation protocols, and lifecycle rules to maintain trust, traceability, and accountability across NSF's execution architecture.

---

5.2.2 VC Type Overview

VC Type	Primary Use	Examples
Operational	Grants authority to execute or supervise specific policy actions	DisasterReliefOperatorVC, ClausePublisherVC, SimulationExecutorVC
Legal	Confirms binding under legal, regulatory, or treaty frameworks	TreatySignatoryVC, ExportComplianceVC, DAOJurisdictionVC
Simulation	Verifies a model’s provenance, versioning, and approved use	ForecastModelVC, SimulationOutputAttestationVC, AIModelCredentialVC
Credentialal	Certifies issuance, quality, or revocation status of other VCs	CredentialIssuerVC, RevocationAuthorityVC, AuditorAccreditationVC

---

5.2.3 Operational Credentials

Operational VCs are the most common credential type. They:

• Enable real-time access control

• Are checked during clause execution, CAC signing, and simulation submission

• May include geographic, temporal, and DAO-scoped constraints

Example schema:

{
  "id": "DisasterReliefOperatorVC#0x7ad1",
  "issuer": "WFP-DAO",
  "subject": "did:nsf:human:0x83e1...",
  "valid_from": "2025-01-01",
  "expires": "2025-06-01",
  "jurisdiction": "PHL",
  "roles": ["ResourceDeployer", "EarlyWarningSubscriber"]
}

Operational VCs may be time-limited, revocable, and linked to CAC execution history.

---

5.2.4 Legal Credentials

Legal VCs bind a DID to:

• Treaty participation

• Regulatory compliance

• Export, tax, or audit alignment

• Multilateral agreement roles

These credentials are often non-revocable except through dispute protocols, and must include:

• Legal basis reference

• Jurisdiction scope

• Authority that issued the credential

• Any dispute resolution mechanism

Example:

{
  "id": "TreatySignatoryVC#0x3ed1",
  "issuer": "UNFCCC",
  "subject": "did:nsf:org:0x9991...",
  "treaty": "ParisAgreement",
  "binding_clause": "UNFCCC::[email protected]",
  "jurisdiction": "FRA",
  "dispute_policy": "IntlArbCourt-v2"
}

---

5.2.5 Simulation Credentials

These VCs govern the entire forecasting and modeling stack, allowing simulation results to be:

• Proven

• Reproducible

• Auditable

• Traceable across multiple policy executions

Simulation VCs include:

Credential	Use
ForecastModelVC	Declares model origin, authorship, version, dataset scope
SimulationRunVC	Binds a specific execution with output range, governance scope
AIModelCredentialVC	For AI agents used in predictive clauses (must be audit-linked)

They may also reference:

• Clause hash

• Run parameters

• Dataset lineage

• Enclave or ZK execution hash

---

5.2.6 Credentialal VCs (Meta-Credentials)

These credentials verify the trustworthiness of credentialing infrastructure itself:

• Certify that a given issuer is recognized by a DAO or treaty

• Approve use of a revocation registry

• Authorize root key rotation

• Accredit simulation auditors, DAO policy boards, or dispute councils

Examples:

{
  "id": "CredentialIssuerVC#0x991f",
  "issuer": "GCRI-CentralDAO",
  "subject": "did:nsf:org:0x7a9c...",
  "credential_types": ["DisasterReliefOperatorVC", "ForecastModelVC"],
  "audit_interval": "90 days",
  "revocable_by": "UNDRR-GovDAO"
}

These are critical to avoid fragmentation and misuse in decentralized credential networks.

---

5.2.7 VC Schema Compatibility and Signatures

All VCs in NSF must:

• Conform to JSON-LD / W3C VC spec

• Use DID-based subject and issuer fields

• Be cryptographically signed with DAO or enclave key

• Optionally include:

  • CAC reference

  • Simulation output hash

  • Clause binding ID

  • Revocation registry pointer

Signatures must support Ed25519 or BLS12-381 (for threshold or aggregate verification).

---

5.2.8 Validity, Revocation, and Overlap Handling

Each VC must specify:

• valid_from, expires

• revocation_authority (a DID or DAO policy clause)

• reissuance_policy (e.g., retraining required, CAC trigger)

NSF handles:

• Overlapping credentials via execution policy precedence rules

• Revoked credentials via sparse Merkle proofs

• Credential updates via VC Lifecycle Hooks (see 5.9)

---

5.2.9 Registry and Audit Layer Integration

All VCs are:

• Stored in the Credential Registry

• Linked to their CAC source

• Indexed for:

  • Time

  • Scope

  • DID

  • Clause

  • DAO

Queries like:

show all active DisasterReliefOperatorVCs in jurisdiction = "COL"  
issued by DAO = "RedCross-LatAm"

are supported by the Audit Layer, with links to simulation triggers and clause execution logs.

---

5.2.10 Typed VCs as the Nervous System of NSF Trust

In NSF:

• Operational VCs grant action

• Legal VCs grant standing

• Simulation VCs prove forecast fidelity

• Credentialal VCs ensure governance integrity

This structured model allows human, machine, and institutional agents to:

• Operate safely

• Execute predictably

• Audit trust lines

• Scale governance across jurisdictions and treaties