# DID Format (Human, Org, Machine, System)

#### **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:

```plaintext
plaintextCopyEditdid:nsf:<category>:<hash>
```

Example:

```plaintext
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:

```json
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:

```json
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:

```scl
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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/v.-verifiable-credentials/did-format-human-org-machine-system.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.