> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/standardization/nexus-sovereignty/v.-verifiable-credentials/cross-jurisdictional-credential-recognition.md).

# Cross-Jurisdictional Credential Recognition

## Cross-Jurisdictional Credential Recognition in the Nexus Sovereignty Framework: Federated Trust Resolution, Recognition Metadata, Credential Equivalency, Jurisdictional Scope Enforcement, Conflict Handling, and Verifiable Digital Multilateralism

### The Need for Cross-Jurisdictional Recognition

Cross-jurisdictional recognition is necessary because the Nexus Sovereignty Framework is designed for risks that do not remain inside one institutional, geographic, legal, or technical boundary. Floods cross river basins. Public health signals cross borders. Supply chains span continents. Climate impacts affect multiple jurisdictions at once. Critical infrastructure systems depend on regional coordination. Humanitarian response often involves national authorities, local actors, international organizations, civil society, logistics providers, communities, and technical systems working across different trust domains. AI agents, simulation models, credential issuers, public-safe reviewers, Project SPV evidence rooms, and sovereign nodes may all need to interact across institutional boundaries without surrendering local control.

In such an environment, a credential cannot be assumed valid everywhere merely because it is cryptographically signed. A DisasterResponseEvidenceVC issued in one country may support participation in a regional evidence workflow, but not authorize field operations in another country. A SimulationValidatorVC recognized by one national registry may require additional review before supporting a cross-border model. A PublicSafeReviewerVC may be valid for one public communication context but not another. A ProjectSPVEvidenceRoomVC may be valid for a specific enterprise evidence room but not for public registry claims. A FinanceReadinessEvidenceVC may be usable as controlled evidence in one diligence workflow but not recognized by another. An InsuranceReadinessEvidenceVC may support technical evidence review without implying underwriting, coverage, pricing, or claims determination. An AI-AgentToolUseVC may be valid in one system but rejected by another if the agent’s model, memory policy, or data access profile is not recognized.

NSF therefore needs a formal mechanism for **Cross-Jurisdictional Credential Recognition**. This mechanism allows credentials to travel with context and proof, while allowing each jurisdiction, registry, community, organization, or enterprise workflow to decide whether and how to recognize them. It enables interoperability without flattening sovereignty. It allows portability without automatic authority. It supports multilateral coordination without centralizing trust.

The core doctrine is:

**A credential may be portable across systems only when its issuer, schema, clause binding, status, jurisdiction, recognition conditions, and permitted use are explicitly recognized by the receiving context. Cross-jurisdictional recognition is a governed relationship, not an automatic property of a signature.**

### Recognition Is Not Universal Validity

A credential can be valid where issued and still not recognized elsewhere. This distinction is central. Validity is a claim about the credential’s issuer, schema, subject, status, and proof. Recognition is a claim about whether another jurisdiction or governance system accepts that credential for a defined purpose.

A credential may be valid for domestic use but advisory in a regional workflow. It may be recognized for evidence submission but not operational deployment. It may be recognized for simulation review but not public-safe communication. It may be recognized for historical audit but not new execution. It may be recognized only during an emergency window. It may be recognized only if accompanied by additional local credentials. It may be recognized only if the underlying CAC is included in a rollup. It may not be recognized at all.

This prevents portability from becoming overreach. Cross-jurisdictional recognition in NSF must always answer: recognized by whom, for what purpose, under what schema, in which jurisdiction, during what period, under what revocation rules, with what dispute path, and with what non-meaning boundaries.

Recognition is therefore scoped interoperability.

### Federated Trust Models in NSF

NSF supports multiple federated trust models because not every trust relationship is the same.

A **unilateral recognition model** occurs when one jurisdiction, registry, institution, community, or enterprise workflow recognizes a credential issued by another. For example, a regional evidence workflow may accept a national SimulationValidatorVC for advisory review, while the issuing jurisdiction does not necessarily recognize regional credentials in return.

A **bilateral recognition model** occurs when two trust domains mutually recognize specified credential types under defined conditions. For example, two national nodes may recognize each other’s DisasterEvidenceOperatorVCs for cross-border evidence submission, but not for field deployment.

A **multilateral recognition model** occurs when several jurisdictions, organizations, consortia, communities, or registries recognize a common credential schema, issuer set, status mechanism, and dispute path. This may support regional corridor governance, shared hazard systems, public health coordination, transboundary environmental monitoring, or mutual recognition of simulation credentials.

A **federated registry model** occurs when credentials remain in local registries, but recognition metadata and status commitments are shared. This allows verification without centralizing credential payloads.

A **treaty-aligned evidence model** occurs when credentials are mapped to treaty-related concepts, reporting frameworks, or public international norms, without implying official treaty enforcement unless a competent treaty body or state process has adopted that use.

A **community-controlled recognition model** occurs when community or Indigenous governance bodies define whether external credentials may access, use, or interpret community-governed data or protected knowledge.

A **enterprise evidence recognition model** occurs when Project SPVs, National Consortium Companies, operators, investors, insurers, contractors, or controlled evidence rooms recognize credentials for defined evidence workflows, without implying public-good endorsement, finance approval, or underwriting.

These trust relationships should be cryptographically anchored, signed, status-checkable, audit-linked, privacy-aware, and dispute-resilient. They should be explicit enough for Smart Clauses and Credential Oracles to evaluate them automatically.

### Recognition Metadata in VC Format

Credentials should include recognition metadata where cross-jurisdictional use is expected. This metadata does not guarantee recognition, but it helps verifiers resolve recognition rules.

A simple recognition block may look like:

```json
{
  "recognition": {
    "recognized_by": ["ETH", "KEN", "RegionalDisasterEvidenceNetwork"],
    "based_on": "DigitalInteroperabilityRecognitionRecord@1.0",
    "trust_model": "multilateral",
    "purpose": "evidence-submission",
    "valid_until": "2026-01-01"
  }
}
```

A mature recognition block should include recognizing authority, issuer set, credential type, accepted schemas, status root, revocation propagation, clause compatibility, jurisdiction, purpose, conditions, dispute path, and non-meaning boundaries:

```json
{
  "recognition": {
    "recognition_id": "RecognitionRecord#0x99abc",
    "recognized_by": "did:nsf:org:EastAfricaRegionalRiskRegistry",
    "recognized_issuer": "did:nsf:org:KENNationalCredentialRegistry",
    "credential_type": "DisasterEvidenceOperatorVC",
    "trust_model": "regional-conditional",
    "recognized_for": [
      "cross-border-evidence-submission",
      "restricted-risk-briefing-access"
    ],
    "not_recognized_for": [
      "official-public-warning",
      "field-deployment-command",
      "relief-disbursement-approval"
    ],
    "jurisdiction_scope": ["KEN", "UGA", "TZA"],
    "valid_from": "2025-01-01",
    "valid_until": "2026-01-01",
    "revocation_policy": "shared-status-root",
    "dispute_policy": "RegionalCredentialRecognitionDisputePolicy@1.0",
    "audit_link": "audit-0x..."
  }
}
```

The seed uses `UNFCCC-DAO`. Unless a formal UNFCCC-linked governance object exists, examples should use `UNFCCCRef` or climate evidence registry terminology. Recognition metadata can reference treaty-aligned frameworks, but should not imply official UNFCCC recognition or treaty enforcement unless authorized.

Recognition metadata allows clause runtimes to evaluate scope, Credential Oracles to validate compatibility, simulations to accept foreign model or data credentials where recognized, and audit systems to trace why a credential was accepted or rejected.

### Jurisdiction Tags and Execution Scoping

Every credential used for jurisdiction-sensitive execution should carry jurisdiction metadata. Jurisdiction may be national, subnational, municipal, regional, treaty-aligned, community-defined, enterprise-defined, SDZ-defined, or domain-specific. For machine verification, jurisdiction tags must use controlled vocabularies where possible, such as ISO 3166 for countries, but NSF must also support non-state and functional jurisdictions, including river basins, regional corridors, community territories, protected data zones, controlled evidence rooms, and enterprise domains.

A simple jurisdiction field may be:

```json
{
  "jurisdiction": "FRA"
}
```

A more complete structure may be:

```json
{
  "jurisdiction_scope": {
    "country": "FRA",
    "subnational": "optional",
    "sdz": "FRA-SDZ-Health-01",
    "domain": "public-health-evidence",
    "recognition_scope": "domestic-only"
  }
}
```

Execution environments should validate clause jurisdiction against credential jurisdiction. They should determine whether the credential is issued inside the same jurisdiction, recognized by the host jurisdiction, valid under a regional recognition record, accepted by an enterprise evidence room, or restricted to another context. Cross-scope execution should be denied, restricted, or routed to review unless recognition checks pass.

Jurisdiction scoping is not only legal. It is also technical. A credential may be valid only inside a national SDZ. A machine credential may authorize execution only on domestic nodes. A public health credential may allow data access only within a protected health environment. A community credential may allow access only under community-controlled governance. A Project SPV credential may allow evidence access only inside an enterprise evidence room.

Credential jurisdiction is the anchor that prevents portability from becoming uncontrolled authority.

### Recognition Agreements

Recognition agreements define which credentials one trust domain recognizes from another, under what conditions, and for what uses. They may be bilateral, multilateral, regional, community-controlled, enterprise-specific, treaty-aligned, or public-good reference records.

The seed calls these DAO-to-DAO recognition agreements. In mature NSF language, they should be **recognition records** or **recognition agreements** between credential issuers, registries, national nodes, regional consortia, community steward bodies, enterprise evidence rooms, or governance bodies. DAO tooling may be used, but should not be the universal constitutional frame.

A recognition record may look like:

```json
{
  "recognition_record_id": "RecognitionRecord#0x99abc",
  "recognizing_party": "did:nsf:org:RegionalHumanitarianEvidenceRegistry",
  "recognized_issuer": "did:nsf:org:JordanNationalCredentialRegistry",
  "credential_type": "FieldAccessEvidenceVC",
  "recognized_for": [
    "restricted-logistics-evidence-access",
    "cross-border-field-attestation"
  ],
  "not_recognized_for": [
    "official-border-clearance",
    "public-authority-command",
    "relief-disbursement-approval"
  ],
  "valid_until": "2026-01-01",
  "revocation_policy": "shared-crl-and-status-root",
  "status_endpoint": "did:nsf:org:JordanNationalCredentialRegistry#status",
  "audit_link": "audit-0x99abc",
  "dispute_policy": "RegionalRecognitionDisputePolicy@1.0",
  "signature": "0x..."
}
```

The seed uses `UNHCR-DAO` and `JORDAN-GovDAO`. Unless authorized, examples should avoid official-sounding governance bodies for UNHCR or governments. Safer identifiers are `RegionalHumanitarianEvidenceRegistry` and `JordanNationalCredentialRegistry`, or “where authorized by the competent entity.”

Recognition records should be anchored in the Interoperability Registry, Credential Registry, or Recognition Registry. Clause runtimes, Credential Oracles, and AI agents query these records before accepting foreign credentials.

Recognition agreements should include expiry and revocation propagation. If the recognized issuer is suspended, recognition may pause. If the host registry changes conditions, credentials may require revalidation. If a credential is revoked in its home jurisdiction, the receiving jurisdiction should know whether revocation propagates automatically.

Recognition is a policy object, not a handshake hidden in code.

### Treaty-Based Credential Portability

Treaty-based credential portability must be framed with careful legal discipline. NSF can support common credential schemas, shared revocation and audit rules, evidence profiles, interoperability mappings, and treaty-aligned reporting structures. But NSF should not imply that a treaty automatically creates NSF credential validity, that treaty bodies have adopted NSF, or that NSF credentials enforce treaties unless competent authorities have established that relationship.

A safe formulation is:

**Treaty-aligned credential portability allows credentials to be mapped to treaty-related obligations, reporting categories, cooperation mechanisms, or shared evidence frameworks where authorized by participating jurisdictions or competent institutions.**

In an authorized treaty-aligned framework, participating jurisdictions may agree to common credential schemas, shared revocation roots, mutual recognition records, standard proof profiles, simulation credential compatibility, audit commitments, and dispute processes. This can allow agents to operate under shared clause logic across participating jurisdictions, while each jurisdiction retains control over local execution.

A treaty-aligned credential may be valid wherever the recognition agreement applies, not automatically wherever the treaty exists. The credential should state whether it is treaty-issued, treaty-referenced, treaty-aligned, or treaty-compatible. These are different claims.

Treaty portability can be powerful for climate evidence, disaster risk reduction, health coordination, aviation, maritime systems, migration protection, biodiversity, finance transparency, and infrastructure resilience. But official legal effect must always depend on competent adoption.

### Resolving Credential Conflicts Across Jurisdictions

Credential conflicts are inevitable. A credential may be valid in one jurisdiction but not another. It may be revoked by the issuer but still cached in a foreign system. It may conflict with local execution policy. It may be recognized for one purpose but presented for another. A credential issuer may be suspended by one registry but trusted by another. A simulation credential may be accepted regionally but rejected nationally. A Project SPV evidence credential may be accepted by one evidence room but not another. An AI agent credential may be valid for public data in one system but prohibited from controlled evidence in another.

When conflicts arise, the clause runtime should not guess. It should trigger a defined conflict condition.

A conflict workflow may include:

Credential Oracle review.

Recognition Registry lookup.

Host jurisdiction policy check.

Issuer status verification.

Revocation and status root comparison.

Clause compatibility review.

Public-safe risk check.

Dispute policy activation.

Execution freeze or restricted mode.

Alternate credential request.

Manual or governance review where required.

A conflict should not automatically be framed as wrongdoing. It may simply mean no recognition exists, recognition expired, local law differs, or additional credentialing is required.

Resolution paths may include execution freeze, alternate credential request, partial acceptance, advisory-only status, manual review, credential reissuance, regional recognition update, dispute panel review, or escalation to competent authority. The seed mentions treaty-level override and DAO quorum vote. Mature language should say treaty-level review or recognition override only if an authorized agreement exists, and governance quorum or competent institutional decision where applicable.

Conflict handling is where cross-jurisdictional recognition protects sovereignty.

### Recognition Precedence Rules

NSF should define recognition precedence rules so runtimes know which policy controls when records conflict. A general precedence profile may be:

Local mandatory law and competent authority restrictions.

Public safety and rights-protective restrictions.

Community or Indigenous data governance restrictions where applicable.

Host jurisdiction execution policy.

Credential issuer status and revocation.

Recognition agreement conditions.

Regional or multilateral interoperability profiles.

Enterprise evidence room rules for enterprise workflows.

Public-good registry compatibility guidance.

Default denial or review when ambiguity remains.

This precedence profile may vary by domain, but some principle must exist. A regional recognition record should not override a national prohibition. A credential issuer should not override host public-safe requirements. An enterprise evidence room should not override community-protected data rules. A public-good interoperability profile should not override applicable law.

Precedence rules make recognition predictable.

### Cross-Jurisdiction Rollups and Attestation Chains

When CACs include cross-domain or foreign credentials, rollups should include recognition proofs. A CAC generated in a host jurisdiction using a foreign credential should record the recognition record, issuer status, credential status, jurisdictional compatibility, proof profile, and any restrictions.

A cross-jurisdictional rollup may include:

CAC root.

Recognition proof root.

Foreign credential issuer root.

Revocation status root.

Recognition agreement hash.

Attestation chain.

Jurisdictional constraint root.

ZK proof of credential recognition.

Public-safe boundary labels.

This allows validators to verify that all foreign credentials were recognized by the host context, had valid status, were signed by recognized issuers, and were used within scope.

ZK verifiers can protect privacy by proving recognition without revealing full credential contents. For example, a rollup may prove that all included foreign credentials were active and recognized for evidence submission, without revealing each holder identity.

Rollups become jurisdictional proof graphs. They show not only that execution occurred, but that credentials used in execution were valid under recognition rules.

### Recognition Dashboards and Governance Observability

NSF should expose recognition dashboards for authorized users. These dashboards help institutions, registries, and public-good governance bodies understand where credentials are recognized, under what conditions, and with what risk.

Dashboards may show credential recognition maps, trust topology graphs, issuer relationships, recognition expiry, revocation propagation, credential usage volume by jurisdiction, disputed recognition records, public-safe restrictions, and dependency concentration.

Public dashboards should be carefully limited. They can show general recognition patterns and public-safe status without exposing sensitive credential holders, operational routes, migration status, protected community data, health details, or Project SPV confidential records.

Governance dashboards for authorized actors may show more detail. A national registry may view domestic recognition. A regional consortium may view cross-border recognition. A community steward may view community data access recognition. An enterprise evidence room may view Project SPV credential compatibility. AI governance dashboards may show agent credential recognition.

Recognition observability supports trust without forcing credential centralization.

### Cross-Jurisdictional Recognition for AI Agents

AI agents operating across domains need explicit recognition checks. An AI agent credential valid in one system should not be accepted by another unless the receiving context recognizes the agent identity, operator, model status, tool permissions, memory policy, public-safe profile, and data access scope.

A foreign AI-AgentToolUseVC may be accepted for reading public data but rejected for controlled evidence access. A model status credential may be recognized for advisory summarization but not for clause execution. A public-safe drafting credential may require local language or jurisdictional review.

Agent runtimes should query Credential Oracles and Recognition Registries before acting across borders. Prompt instructions should not override recognition requirements.

Cross-jurisdictional agent recognition is essential to prevent automated overreach.

### Cross-Jurisdictional Recognition for Project SPVs, Finance-Readiness, and Insurance-Readiness

Project SPVs often involve cross-border actors: sponsors, operators, data providers, contractors, financiers, insurers, reinsurers, model providers, and public-good evidence systems. Credentials in these workflows may need recognition across national, regional, enterprise, and institutional contexts.

A ProjectSPVEvidenceRoomVC issued in one jurisdiction may be recognized by an investor evidence room only for controlled review. A ClimateScenarioReviewerVC may be recognized by a regional infrastructure program if the model credential is accepted. A FinanceReadinessEvidenceVC may be recognized as evidence completeness, but not finance approval. An InsuranceReadinessEvidenceVC may be recognized as risk evidence support, but not underwriting, coverage, pricing, claim determination, or insurability.

Recognition records should preserve these boundaries. A credential recognized for diligence evidence should not be recognized as regulatory approval, procurement clearance, public authority endorsement, or investment recommendation.

Cross-jurisdictional recognition makes capital-relevant evidence portable without making regulated decisions portable.

### Cross-Jurisdictional Recognition Across GNC, RNC, and NNC Architecture

At the national level, National Nexus Consortiums define which external credentials are recognized for domestic execution, evidence review, public-safe workflows, Project SPV evidence, AI agent activity, and national registries. National recognition preserves jurisdictional sovereignty.

At the regional level, Regional Nexus Consortiums may maintain recognition records for shared hazards, corridor systems, mutual recognition, regional simulations, and cross-border evidence workflows. Regional recognition must respect national restrictions and raw data boundaries.

At the global level, the Global Nexus Consortium may define recognition schemas, interoperability profiles, controlled vocabularies, proof formats, conformance tests, and public-good reference registries. It should not be the universal authority deciding all credential recognition.

At the community level, community and Indigenous governance bodies define recognition for community data, protected knowledge, local public-safe outputs, and stewardship roles. External credentials should not override community rules.

At the enterprise layer, National Consortium Companies, Project SPVs, providers, operators, insurers, investors, contractors, and evidence rooms define recognition for lawful implementation and controlled evidence workflows.

This layered architecture allows digital multilateralism without centralized credential authority.

### Recognition Boundary Statement

Cross-jurisdictional credential recognition supports federated trust resolution, credential equivalency, recognition metadata, jurisdictional execution scoping, recognition agreements, treaty-aligned evidence portability, conflict handling, cross-jurisdictional rollups, ZK recognition proofs, AI agent interoperability, Project SPV evidence portability, finance-readiness evidence, insurance-readiness evidence, and multilateral auditability.

It does not by itself create legal authority, public authority status, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty enforcement, legal liability, immigration status, export clearance, tax compliance, or universal credential validity. Recognition means a receiving context accepts a credential for a declared purpose under declared conditions. Its legal and institutional effect depends on competent authority, applicable law, recognition agreement, credential schema, issuer authority, jurisdiction, contracts, community rules, and institutional adoption.

Recognition is not sovereignty transfer.

Recognition is not legal equivalence unless competent authority provides it.

Treaty-referenced is not treaty-enforced.

Multilateral is not universal.

A recognized finance-readiness credential is not finance approval.

A recognized insurance-readiness credential is not underwriting.

A recognized disaster credential is not official emergency command unless competent authority grants that status.

This boundary must appear in recognition records, credential schemas, verifier tools, registries, AI agent policies, rollup metadata, dashboards, and public documentation.

### Interoperability Without Centralization

Cross-jurisdictional recognition is how NSF enables interoperability without centralization. Every credential can travel with context and proof. Every receiving domain can decide whether to accept it. Every recognition relationship can be signed, scoped, time-bound, revocable, and auditable. Every conflict can trigger a defined review path. Every jurisdiction can retain control over execution. Every community can preserve data governance. Every enterprise evidence room can preserve confidentiality. Every AI agent can be checked before cross-border action. Every Project SPV evidence credential can be portable without becoming regulated approval.

This is digital multilateralism at the protocol level: not one central registry deciding all trust, but many trust domains expressing recognition relationships in machine-verifiable form.

Credentials become portable because they carry issuer, schema, status, clause binding, jurisdiction, recognition metadata, proof, and non-meaning boundaries.

Sovereignty is preserved because execution remains scoped by the host context.

Trust is strengthened because recognition is explicit.

Auditability is preserved because every recognition use leaves a record.

Privacy is protected because recognition can be proven through commitments and ZK proofs.

Correction is possible because recognition can be suspended, revoked, updated, disputed, or superseded.

That is the role of Cross-Jurisdictional Credential Recognition in the Nexus Sovereignty Framework: to allow humans, machines, institutions, communities, simulations, AI agents, and evidence systems to interoperate across borders and domains without surrendering authority, privacy, or governance integrity.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/v.-verifiable-credentials/cross-jurisdictional-credential-recognition.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.