# Cross-Jurisdictional Credential Recognition

#### **5.10.1 The Need for Cross-Jurisdictional Recognition**

In the NSF protocol, Verifiable Credentials (VCs) are used by:

* **Agents operating across borders**
* **Multilateral treaty participants**
* **Simulation actors modeling transboundary risks**
* **Emergency responders mobilized via international coalitions**

To ensure these actors are interoperable and verifiable across trust domains, NSF implements **Cross-Jurisdictional Credential Recognition**—a framework for:

* Federated trust resolution
* Credential equivalency
* DAO-to-DAO validation
* Treaty-aligned compliance enforcement
* Execution-layer compatibility

This mechanism provides **seamless policy portability**, without compromising governance integrity.

***

#### **5.10.2 Federated Trust Models in NSF**

NSF supports three trust relationship types:

| Model                          | Description                                                            | Example                                                         |
| ------------------------------ | ---------------------------------------------------------------------- | --------------------------------------------------------------- |
| **Bilateral Equivalence**      | Two jurisdictions/DAOs declare mutual recognition of specific VC types | “Canada and Mexico accept each other's EmergencyHealthVC”       |
| **Multilateral Accreditation** | Credentials accepted if issued under shared treaty, DAO, or standard   | “Any UN-affiliated DAO can issue DisasterReliefOperatorVC”      |
| **Trust Delegation**           | One DAO recognizes another as a credential issuer for a defined role   | “WFP delegates access credentialing to JordanDAO for logistics” |

These relationships are cryptographically anchored, logged, and dispute-resilient.

***

#### **5.10.3 Recognition Metadata in VC Format**

Each credential includes optional recognition metadata:

```json
"recognition": {
  "recognized_by": ["ETH", "KEN", "UNFCCC-DAO"],
  "based_on": "Treaty::DigitalInteroperabilityPact@1.0",
  "trust_model": "multilateral"
}
```

This allows:

* Clause runtimes to evaluate credential scope
* Credential oracles to validate jurisdictional compatibility
* Simulations to accept foreign data or authorities when properly credentialed

***

#### **5.10.4 Jurisdiction Tags and Execution Scoping**

Each VC carries a `jurisdiction` tag:

```json
"jurisdiction": "FRA"
```

Execution environments validate:

* Clause jurisdiction vs credential jurisdiction
* Presence of a valid recognition agreement
* Whether the issuing DAO is in the **Recognition Registry**

Cross-scope execution is denied unless all checks pass.

***

#### **5.10.5 DAO-to-DAO Recognition Agreements**

DAOs can formally declare:

* Which VCs they recognize from which peers
* The conditions under which that recognition is valid
* The expiration and revocation protocols for foreign credentials

Example recognition record:

```json
{
  "recognizing_dao": "UNHCR-DAO",
  "recognized_issuer": "JORDAN-GovDAO",
  "credential_type": "FieldAccessVC",
  "valid_until": "2026-01-01",
  "revocation_policy": "shared_crl",
  "audit_link": "ar://auditrecord0x99abc..."
}
```

These records are anchored in the **Interoperability Registry** and queried by clause runtimes, DAOs, and oracles.

***

#### **5.10.6 Treaty-Based Credential Portability**

Treaties in NSF (see Chapters 3 & 9) define:

* Common credential schemas
* Shared revocation and audit rules
* Unified DAO governance overlays
* Mutual recognition of simulation, legal, and operational credentials

This allows agents to:

* Act under shared clause logic
* Use credentials across sovereign or organizational boundaries
* Present treaty-signed VCs that are valid wherever the treaty applies

***

#### **5.10.7 Resolving Credential Conflicts Across Jurisdictions**

If a credential:

* Is valid in one domain but not another
* Is revoked in a foreign DAO
* Conflicts with local execution policy

…then the **clause runtime triggers a dispute condition**, invoking:

* Credential Oracles
* DAO-to-DAO arbitration
* Treaty-level override clause (if applicable)

Resolution paths are clause-defined and may include:

* Execution freeze
* Alternate credential request
* DAO quorum vote

***

#### **5.10.8 Cross-Jurisdiction Rollups and Attestation Chains**

When CACs (Clause-Attested Computes) include cross-domain credentials:

* The rollup includes recognition proofs
* ZK verifiers check that all foreign VCs:
  * Are recognized by host DAO
  * Have valid revocation status
  * Were signed by a valid issuer key

Rollups become **jurisdictional proof graphs**, validating agent action under shared governance.

***

#### **5.10.9 Governance Dashboards for Credential Recognition**

NSF exposes real-time dashboards that show:

* Which credentials are recognized where
* Trust topology graphs
* Credential usage volume by jurisdiction
* DAO vote logs on recognition status
* Revocation propagation across borders

This enables transparent multilateral governance and public trust.

***

#### **5.10.10 Interoperability Without Centralization**

Cross-jurisdictional recognition in NSF ensures:

* Every credential travels with **context and proof**
* Every domain retains **sovereign control over execution**
* No central registry governs trust—only **decentralized agreements** and **cryptographically signed policies**

NSF creates the **conditions for digital multilateralism**—secure, auditable, and verifiable across the world's most sensitive domains.


---

# 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/cross-jurisdictional-credential-recognition.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.