DID Format (Human, Org, Machine, System)

Establishing Cryptographic Identity Across Governance Agents and Execution Systems

5.1.1 Why Decentralized Identifiers (DIDs) Matter in NSF

The NSF Protocol operates in a trustless, multi-agent environment. Every policy execution, credential issuance, clause deployment, and DAO action must be:

• Signed by a verifiable actor

• Traceable to a governance identity

• Revocable and auditable across jurisdictions

• Bound to legal or treaty-recognized scope

To achieve this, NSF mandates the use of Decentralized Identifiers (DIDs) across all actors—human, organizational, and machine.

DIDs form the backbone of authentication, authorization, and accountability in the credential layer.

---

5.1.2 DID Categories in NSF

NSF defines four canonical DID categories, each with distinct signing, scoping, and revocation logic:

DID Type	Description	Typical Use
Human DID	Individual, person-bound identity	DAO delegates, field agents, operators, scientists
Org DID	Legal entity or multilateral body	WFP, WHO, UNDRR, city governments, treaty bodies
Machine DID	IoT, sensor, or embedded hardware	Remote sensing devices, AI agents, EO pipelines
System DID	Software runtime or enclave node	TEE executor, simulation module, rollup builder

Each DID is:

• W3C-compatible

• Stored in the NSF Registry Layer

• Governed by DAO-issued credential policy bindings

• Used to sign, verify, and attest across all layers of execution

---

5.1.3 DID Format and Method

NSF DIDs are typically represented as:

plaintextCopyEditdid:nsf:<category>:<hash>

Example:

plaintextCopyEditdid:nsf:human:0x84b1f9...
did:nsf:machine:0x491e7c...

All DIDs:

• Point to a DID Document with:

  • Public keys (Ed25519, RSA, or BLS)

  • Key usage definitions (signing, encryption, revocation)

  • Credential compatibility metadata

  • Service endpoints (e.g., credential registries, audit logs)

• Are signed and published by governance DAOs, organizational VCs, or node registrars.

---

5.1.4 Role Binding and Scope Tagging

Every DID in NSF must declare:

• Role types: e.g., TriggerAgent, SimulationValidator, ReliefCoordinator

• Jurisdiction scope: ISO 3166-1 or treaty-defined zone

• DAO binding: Legal accountability for execution or misuse

• Credential issuance or consumption rights

Example:

jsonCopyEdit{
  "did": "did:nsf:org:0x59fe...",
  "role": "ClausePublisher",
  "jurisdiction": "ETH",
  "dao": "UNFCCC::RegionalDAO",
  "revocable_by": "UNFCCC-GovernanceDAO",
  "issued_credentials": ["EmissionsOperatorVC"]
}

---

5.1.5 DID Registration and Governance

DIDs must be:

• Registered in the NSF DID Registry

• Approved by relevant DAO validator quorum

• Anchored to a VC of origin (human credentials, machine attestation, org registry)

• Indexed by:

  • Type

  • Jurisdiction

  • Credential history

  • Revocation status

  • Clause interaction logs

DAO governance rules enforce:

• Onboarding

• Permission delegation

• Role escalation

• Expiration

• Revocation

---

5.1.6 Signing and Verification Workflows

DIDs are used to:

• Sign CACs and clause deployments

• Issue and consume Verifiable Credentials

• Register new nodes or policies

• Initiate DAO votes or overrides

• Interact with simulation runtimes, policy triggers, and oracles

All signing actions are:

• Logged in the Audit Layer

• Linked to a credential and policy

• Validated through cryptographic keys in the DID Document

• Revoked automatically if underlying keys or credentials expire

---

5.1.7 DID-to-VC Linkage

Each DID may be bound to one or more VCs that define:

• Operational authority

• Access rights

• Legal compliance status

• Credential usage scopes

These VCs can define active periods, threshold capabilities, and cross-jurisdictional roles.

Example binding:

jsonCopyEdit{
  "did": "did:nsf:human:0x9f3e...",
  "credential_ref": "DisasterOperatorVC#0x1823...",
  "valid_from": "2025-01-01",
  "expires": "2025-06-30",
  "jurisdiction": "KEN"
}

---

5.1.8 DID Revocation and Rotation

DIDs can be:

• Revoked by DAO, automated clause, or court order

• Rotated for key updates

• Expired by credential conditions

• Challenged through dispute protocol

Revocation is anchored via:

• VC status registries

• Sparse Merkle Trees

• CRLs signed by governance nodes

All revocation actions are:

• Timestamped

• Stored in the Audit Layer

• Verifiable by third parties

---

5.1.9 DID-Based Authorization in Clause Logic

Smart Clauses use DIDs to authorize actions:

sclCopyEditif signer in did:nsf:org:WFP-DAO and hasVC("ReliefCoordinatorVC") {
  execute(ResourceTransferClause)
}

This provides:

• Precise, programmable authorization

• Enforcement of role-based governance

• Traceable decision provenance

---

5.1.10 DIDs as Trust Anchors for Global Digital Governance

In NSF:

• Every action is linked to a DID

• Every DID is linked to a credential and governance scope

• Every credential is linked to a clause or CAC

• Every clause executes in a runtime scoped by DIDs

This creates a global, cryptographically verifiable identity substrate for the execution of digital law, policy, and risk management—across humans, machines, and systems.