> 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/ii.-architecture/credential-layer.md). # Credential Layer Verifiable Identity, Rights, and Entitlements Across People, Machines, Institutions, and Time ## Credential Layer in the Nexus Sovereignty Framework: Verifiable Credentials, Decentralized Identity, Role-Bound Authority, Revocation, Privacy-Preserving Proofs, and Institutional Trust Fabric ### The Role of Credentials in NSF The Credential Layer is the identity, authority, entitlement, permission, and role-binding fabric of the Nexus Sovereignty Framework. It is the layer through which people, institutions, machines, agents, nodes, models, projects, data providers, public authorities, community stewards, reviewers, validators, and implementation actors become visible to the system as governed participants. Without credentials, NSF would have clauses but no authorized actors, simulations but no accountable contributors, proof receipts but no trusted issuers, governance records but no role legitimacy, data access policies but no identity-bound enforcement, and machine execution without accountable agency. Credentials are the primary interface between governance logic and actionable capability. They determine who may propose a clause, issue a credential, operate a node, access a Sovereign Data Zone, run a simulation, validate a proof receipt, participate in a governance review, call a compute workflow, publish a public-safe report, handle a controlled-room evidence package, invoke an AI agent, inspect a Project SPV record, or act in a defined operational role. Credentials also determine what a subject may claim, what it may do, where it may act, under which jurisdiction, for how long, under which conditions, and subject to which revocation pathway. In conventional systems, credentials often appear as IDs, licenses, certificates, badges, permits, letters, PDFs, registry entries, staff accounts, platform permissions, database roles, inspection records, or institutional titles. These artifacts may be useful, but they are frequently disconnected from live status, evidence basis, rule logic, revocation, jurisdictional scope, and machine-verifiable proof. A PDF certificate may be copied after expiry. A badge may not reveal the standard used to issue it. A license may be valid in one jurisdiction but invalid in another. A platform role may be granted by an administrator without governance trace. A credential may be accepted because of institutional trust, not because the verifier can inspect its evidence path. A machine identity may have API access without a clearly governed role. An AI agent may act as a service account without institutional accountability. The NSF Credential Layer corrects this by making every material credential verifiable, clause-bound, status-aware, jurisdiction-aware, revocable, portable, and governed. A credential in NSF should not simply assert that a subject has a role or permission. It should link that role or permission to issuer authority, credential schema, evidence requirements, clause logic, proof receipt, issuance record, validity period, status registry, revocation conditions, recognition scope, and audit trail. This applies across credential categories. Licenses may identify who is authorized to act in a professional, operational, technical, or public authority context. Permissions may grant access to data, compute, controlled rooms, APIs, simulation environments, or public-safe publication workflows. Certifications, where lawfully issued by competent bodies, may be represented as credentials, but NSF must not imply certification where none exists. Delegations may authorize a person, institution, machine, agent, or node to act on behalf of another actor under defined limits. Evidence credentials may show that an inspection, training, simulation, validation, or readiness check occurred. Governance credentials may define role-bound participation in councils, validator quorums, review cells, or registry stewardship. Simulation credentials may identify model authors, scenario reviewers, data contributors, or validation participants. Risk domain credentials may identify competence in aviation, food safety, climate modeling, public health, cybersecurity, AI governance, disaster risk, geospatial intelligence, finance-readiness, insurance-readiness, or critical infrastructure. The Credential Layer is therefore not an identity product. It is a governed trust fabric. It connects identity to role, role to authority, authority to evidence, evidence to clause logic, clause logic to proof receipts, proof receipts to status, and status to revocation and correction. The core doctrine is: **No role should be assumed without a credential. No credential should be trusted without a schema. No schema should be active without governance. No issuance should occur without evidence. No evidence should matter without provenance. No permission should be permanent. No revocation should be untraceable.** ### Credentials as Governance Objects, Not Mere Badges A credential in NSF is a governance object. It is not merely a digital badge, user attribute, or document. It is a structured, signed, status-aware record that binds a subject to a claim under defined authority, evidence, scope, and lifecycle rules. This distinction is essential. Many systems use credentials as static artifacts. NSF uses credentials as operational governance records. A credential can enable or restrict data access. It can participate in clause execution. It can authorize a machine to call a workflow. It can allow a reviewer to join a controlled-room process. It can allow a node to serve proof receipts. It can allow a model to be invoked in a defined domain. It can support cross-border recognition. It can enable public-safe publication. It can block actions when expired, suspended, disputed, or revoked. Because credentials can shape real-world behavior, their governance must be rigorous. Every credential type must be defined by a credential schema. Every schema must be linked to governance records. Every issuer must have issuer standing. Every issuance must link to evidence or proof. Every credential must have a status path. Every use must be loggable where material. Every revocation must be explainable. Every recognition decision must be scoped. Every public-facing interpretation must be claims-disciplined. A credential that says “Risk Analyst” is not enough. NSF needs to know what kind of risk analyst, issued by whom, under what standard, for what domain, in which jurisdiction, with what evidence, for what period, with what review rights, and with what permissions. A credential that says “Model Approved” is unsafe unless it states approved for which use case, which model version, which data classes, which evaluation profile, which human review requirements, and which prohibited uses. A credential that says “Project Ready” is dangerous unless it states readiness for what purpose and explicitly avoids financeability, insurability, procurement approval, or endorsement overclaim. Credentials therefore carry both capability and boundary. They grant scope, but they also limit interpretation. This is what makes them usable in public-good infrastructure. ### W3C Verifiable Credentials as the Canonical Credential Format NSF should adopt W3C Verifiable Credentials as the canonical credential representation pattern because VCs provide a widely recognized model for portable, cryptographically verifiable claims. A VC can express issuer, subject, claims, proof, issuance date, expiration date, credential schema, credential status, and verification method. This makes it suitable for interoperability across identity wallets, verifier APIs, decentralized identifiers, institutional registries, mobile-first deployments, humanitarian identity systems, sovereign identity stacks, and selective disclosure workflows. However, NSF does not merely use VCs as generic digital certificates. It extends the VC pattern with governance metadata, clause linkage, proof receipt references, jurisdictional scope, public-safe status, data classification, revocation logic, recognition rules, correction state, and role-bound permissions. A standard VC tells a verifier that an issuer made a claim about a subject. An NSF-compatible VC should also tell the verifier which clause or schema governed the claim, what evidence class supported it, what proof receipt or CAC record is linked to it, what the credential can and cannot be used for, which jurisdiction recognizes it, whether it has been superseded, and which governance process can revoke or correct it. Every NSF credential should include a credential identifier, credential type, issuer DID or equivalent issuer identity, subject DID or equivalent subject identity, issuance timestamp, expiration or review timestamp, schema identifier, schema version, credential status method, revocation registry reference, proof method, signature, jurisdictional scope, domain scope, authority class, evidence reference, clause reference, proof receipt or CAC reference where applicable, public-safe classification, delegation limits where relevant, recognition metadata, and correction pathway. For high-consequence credentials, the credential should also include reliance limitations. It should state whether it is an identity credential, role credential, evidence credential, operational credential, training credential, node credential, model credential, governance credential, readiness credential, or public-safe publication credential. It should state whether it supports access, review, issuance, simulation, execution, voting, validation, or reporting. It should also state what it does not do. A readiness credential does not mean finance approval. An insurance-readiness credential does not mean underwriting. A public-good participation credential does not mean public authority. A model evaluation credential does not mean safe use in every context. This makes VC compatibility useful for serious institutions. It allows NSF credentials to interoperate with wider digital identity and credential ecosystems while preserving the stronger governance semantics required for sovereign, public-good, and mission-critical systems. ### Credential Schema Governance Credential schemas are the constitution of the Credential Layer. A credential is only as trustworthy as the schema that defines it. The schema determines what claims may be made, who may issue them, what evidence is required, how status is checked, how revocation works, what scope applies, and what relying parties may infer. In NSF, credential schemas must be governed through the Governance Layer. A schema should not be created casually by a platform administrator. It should pass through proposal, review, simulation where appropriate, public-safe assessment, issuer qualification, authority-boundary review, and activation. Schema governance is especially important where credentials affect human rights, public services, safety, public health, aviation, critical infrastructure, community knowledge, finance-readiness, insurance-readiness, AI systems, controlled-room access, or public authority workflows. A credential schema should include schema name, namespace, version, issuer eligibility, subject type, permitted claims, prohibited claims, evidence requirements, evidence freshness, clause dependencies, CAC or proof receipt dependencies, issuance workflow, renewal logic, expiration logic, suspension states, revocation conditions, dispute pathway, recognition scope, public-safe status, privacy requirements, selective disclosure options, minimum assurance level, storage requirements, audit requirements, and migration pathway. Issuer eligibility is a critical part of schema governance. Who may issue the credential? A public authority? A professional body? A national node? A regional consortium? A community stewardship body? A university laboratory? A technical validator? A Project SPV operator? An enterprise provider? Different issuers produce different authority meaning. A training provider may issue a training completion credential. It should not issue a public authority license unless competent authority exists. A technical validator may issue an evidence validation credential. It should not issue investment approval. A community body may issue a protected knowledge access credential. It should not be overridden by an enterprise platform. Evidence requirements must be explicit. A credential issued without evidence is only an assertion. The schema should state what data, documents, proof receipts, inspections, simulations, training records, node attestations, model evaluations, or governance records support issuance. It should also define whether the credential can be issued automatically after a clause pass, requires human review, requires public authority confirmation, or requires multi-party quorum. Status rules must also be explicit. A credential may be active, expired, suspended, revoked, disputed, provisional, conditional, restricted, superseded, migrated, or archived. These states have different meanings. A suspended credential may be temporarily unusable pending review. A revoked credential may no longer be valid. A disputed credential may require controlled verification. A superseded credential may remain historically valid but no longer current. A migrated credential may have moved to a new schema. Credential schema governance prevents credential inflation. Without it, every actor could issue attractive-sounding credentials that create confusion, overclaim, or false reliance. ### Credential Lifecycle in NSF The credential lifecycle begins before issuance. It begins with a governed schema, eligible issuer, defined evidence requirements, and clause-bound issuance logic. The first stage is trigger. A credential may be triggered by completion of training, passage of inspection, validation of a node, execution of a clause, approval by a governance body, completion of a simulation contribution, verification of domain expertise, proof of community stewardship, public authority recognition, or operational readiness evidence. The trigger must be linked to the credential schema. Not every trigger should issue automatically. Some triggers should produce review-required status. The second stage is evidence binding. The issuer or credential workflow gathers the required evidence. Evidence may include documents, data objects, proofs, CAC records, simulation records, inspection records, training records, identity records, role records, public authority records, or controlled-room evidence. Each evidence object must have provenance. The workflow should verify freshness, integrity, schema compatibility, data classification, and jurisdictional scope. The third stage is clause evaluation. The relevant credential issuance clause evaluates whether the required conditions are satisfied. The clause may run in a standard governed runtime, secure enclave, controlled room, zero-knowledge environment, or national node depending on data sensitivity. The result may be pass, fail, review required, insufficient evidence, provisional, or restricted. The fourth stage is proof generation. If the clause evaluation is material, it should generate a proof receipt or CAC record. This record links the credential to the logic and evidence behind issuance. It should not necessarily expose sensitive evidence, but it should allow authorized verification of the issuance pathway. The fifth stage is issuance. The issuer signs the credential using an issuer key or equivalent verification method. The credential is written to the appropriate registry or delivered to the subject’s wallet, institutional store, machine identity environment, node registry, or controlled credential repository. Issuance should be logged in the Credential Audit Layer. The sixth stage is use. A credential may be presented to access data, invoke a clause, participate in governance, operate a node, validate a proof, enter a controlled room, run a simulation, publish a public-safe output, or interact with another system. Each material use should be verifiable and, where required, logged. Selective disclosure or zero-knowledge presentation may allow proof of relevant attributes without exposing the full credential. The seventh stage is monitoring. Some credentials remain valid until expiry. Others require continuous status checks. A node credential may depend on uptime and security posture. A model credential may depend on monitoring and incident state. A public authority delegation may expire with role change. A Project SPV credential may depend on updated evidence. A training credential may require periodic renewal. The eighth stage is suspension or revocation. If conditions change, a credential may be suspended or revoked under a revocation clause or governance process. Revocation should be signed, reason-coded, linked to evidence, and recorded in a status registry. For privacy-sensitive credentials, the public status may reveal only that the credential is no longer valid, while detailed reasons remain restricted. The ninth stage is renewal or migration. Credentials may be renewed under current schema rules or migrated to a new schema. Migration must preserve historical meaning. A credential issued under an old schema should remain interpretable, even if it is no longer current. The tenth stage is archival. Expired, revoked, superseded, or migrated credentials may require long-term archival for accountability, audit, career records, project evidence, legal review, or intergenerational governance. Archival must respect privacy, retention, deletion, and public-safe rules. This lifecycle ensures credentials are not claimed. They are issued through governed evidence, used under scope, and corrected when conditions change. ### Decentralized Identifiers and Identity Governance The Credential Layer uses decentralized identifiers or equivalent verifiable identity anchors to identify subjects. A subject may be an individual, institution, public authority, community body, company, Project SPV, node, AI agent, model, dataset, simulation, device, drone, sensor, compute environment, registry, jurisdictional profile, or governance cell. DIDs are useful because they allow subjects to be identified without depending exclusively on one centralized platform. A DID can support public keys, verification methods, service endpoints, credential references, key rotation, delegation, and resolution across networks. However, NSF must use DIDs with governance discipline. A DID is not identity truth by itself. It is an identifier and verification mechanism. The authority meaning of a DID depends on credentials, issuer records, registries, trust anchors, jurisdictional context, and governance standing. An NSF DID document or equivalent identity object should include verification methods, public keys, service endpoints, credential index references, status endpoints, key rotation logic, delegation records, controller information, trust anchor paths, jurisdictional metadata where appropriate, governance affiliations, and recovery rules. Sensitive subjects may require privacy-preserving identifiers, pairwise DIDs, pseudonymous presentations, or controlled resolution. DID governance must address key lifecycle. Keys can be rotated, compromised, lost, delegated, or retired. A key rotation should not destroy credential history. A compromised key should trigger status updates and dependent credential review. Delegation should be scoped and time-bound. If an institution reorganizes, successor identity records should preserve continuity. If a node changes operator, identity and credential status must update. If an AI agent is retired, its identity should be marked retired, not reused without trace. DIDs may support on-chain, off-chain, or hybrid resolution. Public identifiers and non-sensitive registry references may be resolvable through public or semi-public networks. Sensitive identifiers may resolve through permissioned registries, national systems, controlled rooms, or pairwise channels. NSF should not require all identities to be publicly visible. Identity visibility must respect privacy, security, community safeguards, and jurisdictional law. Identity governance is the foundation of accountable participation. Without it, credentials can be forged, misattributed, or misused. ### Identity Types in NSF NSF must support multiple identity types because the ecosystem includes human, institutional, machine, model, data, and governance actors. Human identities may include public officials, reviewers, inspectors, analysts, researchers, engineers, community stewards, aid workers, pilots, operators, auditors, validators, and project staff. Human identity must be privacy-protective and purpose-limited. A person may need to prove a role without exposing unnecessary personal attributes. Institutional identities may include ministries, regulators, public authorities, universities, NGOs, regional bodies, standards bodies, companies, Project SPVs, operators, insurers, investors, public-good organizations, and community institutions. Institutional identity should include legal name, jurisdiction, registration where relevant, authority scope, role credentials, and status. Machine identities may include sensors, drones, edge devices, servers, secure enclaves, trusted execution environments, AI agents, software services, robotics systems, AI-RAN components, O-RAN components, industrial controllers, and data pipelines. Machine identity must include device or workload provenance, firmware or software version, operator, credential state, and revocation path. Node identities may include national data nodes, regional compute nodes, global reference registries, controlled-room nodes, community nodes, edge nodes, archive nodes, enterprise implementation nodes, and Project SPV evidence nodes. Node identity must include operator, jurisdiction, function, security profile, data classes, uptime, incident history, and status. Model identities may include AI models, simulation models, digital twin models, risk models, climate models, geospatial classifiers, language models, agent policies, and scoring systems. Model identity must include version, provider or maintainer, evaluation status, permitted use, data restrictions, deployment context, monitoring state, and retirement status. Dataset identities may include datasets, sensor feeds, satellite products, simulation inputs, evidence packages, public-safe outputs, and training corpora. Dataset identity connects to provenance, access, classification, and use permissions. Jurisdictional identities may represent national, regional, treaty, community, or institutional contexts used to scope clauses and credentials. These should not be confused with legal personality or public authority unless such authority exists. Governance cell identities may represent councils, validator quorums, review bodies, controlled-room panels, standards working groups, or public-safe review functions. Their identity should include scope, admission rules, role credentials, and decision authority class. Supporting these identity types allows NSF to govern hybrid systems where humans and machines operate together. ### Credential Types and Domains The Credential Layer should include modular credential classes. These classes allow NSF to express different kinds of authority and evidence without collapsing all credentials into one category. Identity credentials establish that a subject is associated with an identifier under a defined assurance level. They may be personal, institutional, machine, node, model, dataset, or jurisdictional. Identity credentials should not automatically grant permissions. Role credentials define a subject’s role. Examples include RiskAnalystVC, ClauseAuthorVC, PublicSafeReviewerVC, SimulationValidatorVC, DataStewardVC, CommunityStewardVC, CredentialIssuerVC, ComputeAttestorVC, NodeOperatorVC, ModelEvaluatorVC, ProjectSPVReviewerVC, or ControlledRoomReviewerVC. Role credentials should be domain-scoped and revocable. Authority credentials define a recognized authority or mandate. These may apply to public authorities, regulators, professional bodies, standards organizations, community bodies, or institutional governance roles. Authority credentials must be handled carefully to avoid overclaim. NSF can record authority where provided by competent sources. It does not create public authority by itself. Permission credentials grant access or operational capability. These may include DataAccessVC, SDZAccessVC, ControlledRoomAccessVC, ComputePoolAccessVC, EdgeRunnerVC, PublicSafePublicationVC, ClauseExecutionVC, APIAccessVC, or AgentToolUseVC. Permissions should be purpose-limited and time-bound. Evidence credentials represent that an event, check, training, inspection, simulation, validation, or contribution occurred. Examples include TrainingCompletedVC, InspectionEvidenceVC, SimulationContributionVC, ModelEvaluationEvidenceVC, PublicConsultationEvidenceVC, MaintenanceEvidenceVC, SafeguardReviewVC, or IncidentResponseEvidenceVC. Credential issuer credentials define who may issue specific credential types. A HealthCredentialIssuerVC should not allow issuing aviation credentials. A CommunityKnowledgeIssuerVC should not allow issuing public authority licenses. Issuer credentials must be schema-scoped. Governance credentials define participation in governance processes. Examples include CouncilMemberVC, ValidatorQuorumParticipantVC, DomainReviewerVC, VotingEligibleVC, DissentRecorderVC, CorrectionReviewerVC, or EmergencyGovernanceRoleVC. These should replace token-based governance rights. Simulation credentials define roles in model and scenario workflows. Examples include SimulationAuthorVC, ScenarioReviewerVC, ModelMaintainerVC, DataContributorVC, UncertaintyReviewerVC, or ReplayValidatorVC. Node and infrastructure credentials define technical participation. Examples include NationalNodeVC, RegionalRelayNodeVC, ArchiveNodeVC, ComputeNodeVC, EdgeNodeVC, RegistryNodeVC, SecureEnclaveVC, or TEEAttestorVC. These credentials should carry security profiles and status. Model credentials define AI or simulation model status. Examples include ModelRegisteredVC, ModelEvaluatedVC, ModelRestrictedVC, ModelApprovedForAdvisoryUseVC, ModelQuarantinedVC, or ModelRetiredVC. Model credentials must specify use scope and must not imply universal safety. Project and asset credentials define Project SPV evidence and asset status. Examples include AssetRegisteredVC, MaintenanceCurrentVC, SafeguardEvidenceVC, ClimateScenarioRunVC, InsuranceReadinessEvidenceVC, FinanceReadinessEvidenceVC, ProjectEvidenceCompleteVC, or PublicSafeSummaryVC. These credentials must preserve finance and insurance boundaries. Public-safe credentials define publication status. Examples include PublicSafeMapVC, PublicSafeReportVC, RedactionApprovedVC, CriticalInfrastructureMaskedVC, CommunityDisclosureApprovedVC, or OfficialSourceDistinctionVC. Community and rights credentials define community governance participation, protected knowledge access, consent-aligned use where applicable, grievance process standing, or local stewardship. These credentials require strong safeguards. Every type is versioned, governed by schema clauses, and tracked in appropriate registries. There may be global reference registries, regional registries, national registries, community registries, controlled-room registries, and enterprise evidence registries. The term Global Credential Registry may be used for reference interoperability, but NSF should preserve federated registry architecture. ### Credential Revocation, Suspension, and Status Credential revocation is a governance function. It must not be arbitrary, opaque, or purely administrative. A credential that can be revoked without evidence becomes unstable. A credential that cannot be revoked becomes dangerous. Revocation should follow a revocation clause, issuer rule, governance decision, legal requirement, security event, expiry condition, evidence correction, model incident, node compromise, public authority notice, community safeguard trigger, or dispute resolution pathway. The revocation record should include credential identifier, issuer, subject, status change, reason code, clause reference, evidence reference, timestamp, signing actor, jurisdiction, appeal or correction path, and publication class. Suspension is different from revocation. A suspended credential may be temporarily unusable pending review. Suspension may occur when evidence is disputed, issuer status is questioned, a node is under investigation, a model incident occurs, a role conflict arises, or a security event is detected. Suspended credentials should not be usable for clause execution, governance participation, access authorization, credential issuance, or public-safe publication unless the suspension rule allows a narrow exception. Credential status should be verifiable through status registries, status lists, issuer endpoints, national registries, regional recognition systems, or privacy-preserving status proofs. For sensitive credentials, public status should reveal minimal information. A verifier may need to know whether the credential is valid without knowing the reason for revocation. Detailed reasons may remain restricted to authorized reviewers. Revocation may propagate differently by domain. A compromised node credential may need rapid global or regional propagation. A personal health credential may require privacy-preserving status checks. A public authority role credential may propagate through a national registry. A Project SPV evidence credential may propagate only to authorized reviewers. A community knowledge access credential may be revoked by a community stewardship process and restrict future access immediately. Revocation should also trigger downstream dependency checks. If an issuer credential is revoked, credentials issued by that issuer may require review. If a model credential is suspended, AI outputs produced under that model may require annotation. If a node credential is revoked, CAC records from that node during a specific window may require review. If a public-safe reviewer credential is revoked due to misconduct, reports approved by that reviewer may require reassessment. A mature Credential Layer treats revocation not as a delete button, but as a controlled status transition with evidence and consequences. ### Privacy, Selective Disclosure, and Zero-Knowledge Credential Presentations The Credential Layer must support privacy-preserving verification. Many credentials contain sensitive information. A person may need to prove they are qualified without revealing identity. A humanitarian worker may need to prove role in a country without revealing affiliation publicly. A refugee may need to prove eligibility without exposing protected identity. A health credential may need to prove a condition without revealing medical details. A community steward may need to prove authority without disclosing sensitive governance records. A financial or sanctions-related credential may need to prove screening without exposing confidential counterparties. Selective disclosure allows a subject to reveal only the attributes needed for a transaction. A verifier may need to know that a subject is over a threshold age, holds a valid role, has completed training, belongs to an authorized issuer class, or is permitted to access a data zone, without seeing all credential fields. Zero-knowledge credential proofs allow a subject to prove a statement about a credential without revealing the credential itself. A subject could prove “I hold an active AidWorkerCredentialVC recognized for Country X” without revealing name, employer, personal identifier, or full credential history. An AI agent could prove it has an active tool-use credential without revealing internal deployment details. A Project SPV could prove that a required evidence credential exists without disclosing confidential evidence publicly. Pseudonymous governance participation may be appropriate in sensitive contexts, such as anti-retaliation processes, protected participation, whistleblowing, human rights review, community consultation, or conflict settings. However, pseudonymity must be governed. The system may allow role-based participation through zero-knowledge attestations while preserving controlled accountability to an authorized steward, ombudsperson, public authority, or protected registry where needed. Privacy-preserving credentials must still support revocation. This is technically and institutionally challenging. A verifier must be able to determine that a credential remains active without learning unnecessary information. NSF should support privacy-preserving status mechanisms, accumulators, status lists, pairwise identifiers, and controlled revocation proofs where appropriate. The principle is privacy with accountability. NSF should never force unnecessary disclosure as the price of verification, but it also should not allow privacy features to become mechanisms for unaccountable authority. ### Interoperability and Wallet Integration The Credential Layer should be interoperable with existing identity and credential ecosystems. It should not require every institution, country, humanitarian organization, enterprise, or community to adopt one proprietary wallet or identity stack. NSF-compatible credentials should be capable of working with W3C Verifiable Credentials, decentralized identifiers, credential wallets, verifier APIs, OpenID Connect, OAuth 2.0, SAML where needed, mobile-first identity systems, humanitarian credential wallets, sovereign identity systems, digital public infrastructure identity stacks, enterprise identity providers, and machine identity systems. The Framework should support integration with national identity and DPI systems where lawful and appropriate. Examples of relevant identity ecosystems and patterns include European digital identity frameworks, EBSI-style trust infrastructure, MOSIP-like modular identity systems, Aadhaar-like national identity environments where legally and ethically appropriate, civil registry systems, professional licensing registries, public authority identity systems, enterprise IAM, and humanitarian identity approaches. NSF should not assume these systems are equivalent or automatically safe. Each integration must be evaluated for privacy, rights, sovereignty, authority, and public-safe risks. Each NSF deployment should be able to define accepted credential issuers, trusted registries, resolution methods, schema translations, cross-certification policies, recognition conditions, expiry rules, revocation requirements, assurance levels, and fallback behavior. A national deployment may accept credentials from domestic issuers and selected regional partners. A regional deployment may recognize national credentials under mutual recognition profiles. A humanitarian deployment may support offline verification and selective disclosure. An enterprise deployment may integrate with corporate IAM while preserving NSF proof receipts. Wallet integration must support both people and machines. Human users may hold credentials in mobile wallets, institutional wallets, hardware wallets, cloud wallets, or custodial wallets depending on context. Institutions may hold credentials in organizational credential stores. Machines and agents may hold workload credentials, service credentials, device credentials, or node credentials. Offline and low-bandwidth wallets may be required in disaster, humanitarian, rural, or field environments. Interoperability must not become credential dilution. A credential accepted technically should not be accepted institutionally unless issuer, schema, status, and scope match the verifier’s policy. NSF should enable credential translation and recognition, but always with proof scope and boundary discipline. ### Credential Registries and Federation The Credential Layer requires registries, but not one centralized credential registry controlling all identity. NSF should use a federated registry model. A global reference credential registry may publish reference schemas, proof receipt profiles, interoperability profiles, public-good role vocabularies, credential status methods, and cross-domain mappings. It should not become a central repository of all personal or sensitive credentials. National credential registries may maintain domestic issuer records, public authority role records, national credential schemas, recognition rules, and status endpoints. These are essential for sovereignty. Regional credential registries may support mutual recognition across member states or regional systems. They may map national credentials to regional profiles, support cross-border disaster response roles, regional professional recognition, shared trade credentials, or regional public health coordination. Community credential registries may maintain sensitive authority records, protected knowledge access, local stewardship roles, and community consent or safeguard statuses. Access should be controlled and public-safe. Controlled-room credential registries may govern sensitive reviewers, evidence access, security-sensitive roles, or confidential Project SPV reviews. Enterprise or Project SPV credential registries may maintain implementation roles, asset evidence credentials, contractor credentials, operator credentials, maintenance credentials, and evidence workflow permissions. These must remain claims-disciplined and should not imply public-good authority unless recognized through a separate governance path. Credential registries should support discovery, status check, schema validation, issuer verification, revocation, suspension, dispute status, recognition status, migration, and archival. They should also support privacy-preserving verification where appropriate. Federation allows credentials to be portable without forcing all identity into one infrastructure. It also allows credentials to remain jurisdiction-aware. A credential may be valid in one registry, recognized conditionally in another, rejected in a third, and restricted in a controlled context. That is not a bug. It is how sovereignty and interoperability coexist. ### Credential Use in Clause Execution Credentials are not passive records in NSF. They are active inputs to clause execution. A clause may require a credential to run, may produce a credential, may change a credential status, or may restrict outputs based on credential state. An access-control clause may require DataStewardVC, PublicAuthorityVC, CommunityStewardVC, or ControlledRoomAccessVC before allowing data access. A simulation clause may require SimulationAuthorVC and ModelValidatorVC before accepting a model package. A credential issuance clause may require CredentialIssuerVC and evidence proof receipts before issuing a new credential. A governance participation clause may require DomainReviewerVC and no active conflict-of-interest record. A public-safe publication clause may require PublicSafeReviewerVC and SourceEvidenceCompleteVC. An AI agent clause may require AgentToolUseVC before allowing a model to call a tool. Credentials can also be produced by clause execution. If a training completion clause passes, the system may issue TrainingCompletedVC. If a node attestation clause passes, the system may issue ComputeNodeActiveVC. If a model evaluation clause passes for a limited use case, the system may issue ModelEvaluatedForAdvisoryUseVC. If a Project SPV evidence completeness clause passes, the system may issue ProjectEvidenceCompleteVC with strict boundary language. Credentials can be modified by clause execution. A revocation clause may suspend a credential after issuer compromise. A monitoring clause may downgrade a node credential if uptime or security requirements fail. A public-safe incident clause may suspend a publication credential. A model incident clause may quarantine a model credential. A renewal clause may extend validity after new evidence. Every material credential use should be logged. The log should record which credential was presented, what claim was verified, which clause used it, whether selective disclosure or ZK proof was used, what result occurred, and whether downstream status changed. Sensitive logs must be protected. This makes credentials the operational grammar of authority in NSF. ### Credential Use in Governance Participation NSF governance is credentialed governance. Participation in clause lifecycle, credential schema approval, simulation review, node admission, public-safe reporting, correction, dispute resolution, and emergency governance depends on role credentials. A participant may need ClauseAuthorVC to submit a clause proposal. DomainReviewerVC may be required to review a clause in a specific field. SimulationValidatorVC may be required to approve simulation sufficiency. PublicSafeReviewerVC may be required to approve public outputs. CommunityStewardVC may be required for community-sensitive data. ComputeAttestorVC may be required to validate execution environments. CredentialIssuerVC may be required to issue certain credentials. CorrectionReviewerVC may be required to resolve disputes. EmergencyGovernanceRoleVC may be required for time-bounded crisis actions. Governance credentials should be scope-bound. A person or institution may hold multiple credentials across domains, but each should define its limits. Voting or review rights should be tied to active status. Conflict-of-interest records may restrict participation. Delegation credentials may allow an authorized representative to act, but delegation must be explicit, time-bound, and revocable. This model replaces token voting. Governance power is not purchased. It is granted through role, contribution, mandate, domain competence, and institutional standing. It is recorded and revocable. Credentialed governance makes machine-readable policy accountable to human and institutional legitimacy. ### Credential Use by AI Agents and Autonomous Systems AI agents and autonomous systems require credentials because they increasingly perform actions once reserved for humans or institutional systems. An AI agent may query data, draft policy summaries, run simulations, call tools, validate credentials, generate reports, or route workflows. A drone may conduct missions. A robot may inspect infrastructure. An AI-RAN controller may optimize network behavior. A digital twin may update risk states. These systems must not operate as anonymous or unbounded actors. Machine and agent credentials should define identity, operator, model or software version, permitted tools, permitted data classes, allowed clauses, runtime environment, logging requirements, human review conditions, expiry, revocation path, and emergency stop logic. An AI agent with AgentPolicyDraftingVC may draft clauses but not activate them. An AgentSimulationRunnerVC may run simulations but not approve results. An AgentPublicSafeSummaryVC may generate draft summaries but require human review before publication. A DroneMissionVC may authorize a drone for a defined mission, geography, time window, operator, and safety profile. An AI-RANControllerVC may authorize bounded network optimization under public safety constraints. A ModelInferenceVC may permit a model to be used for advisory outputs but not high-impact decisions. Agent credentials should be short-lived where risk is high. They should be monitored, logged, and revocable. If a model is compromised, if a prompt injection incident occurs, if a tool is misused, or if an agent exceeds scope, credentials should be suspended or revoked. This is the basis of machine accountability. Machines become governed subjects in the Credential Layer, not invisible infrastructure. ### Credential Use in Data Access and Sovereign Data Zones Sovereign Data Zones depend on credentialed access. A data zone cannot be sovereign if access is based only on network location or platform permissions. Every access request should be evaluated against identity, credential status, purpose, data class, jurisdiction, clause context, and output policy. A human reviewer may need ControlledRoomAccessVC. A public authority may need PublicAuthorityAccessVC. A community steward may need CommunityDataStewardVC. A model may need ModelAllowedForRestrictedInferenceVC. An AI agent may need AgentRestrictedDataAccessVC. A compute workload may need WorkloadAttestedVC. A node may need NationalNodeActiveVC. A Project SPV reviewer may need ProjectEvidenceReviewerVC. Credentials can also enforce purpose limitation. A user may have access for audit but not for publication. A model may access data for inference but not training. A public authority may access data under a legal process but not for unrelated use. A regional simulation may access aggregate outputs but not raw data. A public-safe report generator may access masked layers but not source layers. Every credentialed access should produce an access record. The record should identify the presented credential, data object, purpose, clause, jurisdiction, decision, and output restrictions. This creates accountability and supports correction. Credentials are therefore the access-control language of the NSF Data Layer. ### Credential Provenance and Audit Trails Credentials in NSF are institutional memory. They record who had authority, when, under which scope, based on what evidence, and with what status. Credential provenance is essential for audit, dispute resolution, public authority review, professional accountability, project evidence, and historical reconstruction. Credential provenance should include issuer identity, issuer credential, subject identity, subject class, schema version, evidence references, clause references, CAC or proof receipt references, issuance timestamp, expiry, status history, renewal history, revocation history, suspension history, recognition history, presentation history where material, and correction history. Presentation history should be handled carefully. Recording every credential use can create privacy risks. NSF should distinguish between material uses that require audit and low-risk uses where minimal logging or privacy-preserving proof is appropriate. Sensitive presentations may use pairwise identifiers or zero-knowledge proofs. However, where credentials enable high-consequence actions, audit trails are necessary. Credential provenance supports questions such as: who issued this credential; under what authority; what evidence supported it; which clause governed issuance; was the issuer active at the time; was the credential valid when used; was it later revoked; did a suspended credential participate in a governance vote; did an AI agent use a tool without proper credential; did a Project SPV evidence credential rely on corrected data; did a public-safe report depend on a reviewer whose credential later became disputed? These questions cannot be answered by a static badge. They require a credential audit fabric. ### Cross-Jurisdiction Recognition and Credential Translation Cross-jurisdiction credential recognition is one of the most important functions of NSF. A credential issued in one system may need to be understood in another. However, recognition is not automatic. It depends on schema compatibility, issuer trust, evidence requirements, legal context, domain scope, public authority rules, and risk. NSF should support recognition records that define whether a credential from one jurisdiction or registry is accepted by another. Recognition may be full, conditional, limited, provisional, expired, rejected, suspended, or review required. A credential may be accepted for advisory purposes but not legal authority. It may be accepted for emergency response but not long-term licensing. It may be accepted for data access but not governance voting. It may be accepted inside a regional corridor but not globally. Credential translation may map one schema to another. For example, a national health worker credential may be translated into a regional disaster response credential if evidence requirements align. A trade inspection credential may map to a customs readiness profile. A technical evaluator credential may map to a regional simulation reviewer role. Translation must preserve differences. If schemas are not equivalent, the translation should state partial equivalence or require additional evidence. Cross-certification should be used carefully. NSF should avoid language suggesting certification unless competent bodies are involved. It may support mutual recognition, schema mapping, equivalence assessment, or interoperability validation. Cross-jurisdiction recognition allows credentials to travel without flattening sovereignty. It is how NSF supports global interoperability with local control. ### Multi-Generation Credentialing and Succession Some credentials must remain verifiable across decades. Land tenure, professional licensing, aviation records, infrastructure maintenance, biodiversity offset obligations, educational qualifications, public service records, Project SPV evidence, climate resilience monitoring, and community stewardship credentials may outlast systems, vendors, governments, and technologies. The Credential Layer must therefore support multi-generation credentialing. Credentials should remain interpretable even after schema updates, issuer reorganization, cryptographic migration, platform migration, or jurisdictional transition. Historical credentials should be linked to their schema version and issuer state at time of issuance. If a schema is superseded, old credentials should retain historical meaning. If a cryptographic method becomes obsolete, archival migration should preserve proof. If an issuer is replaced by a successor authority, succession records should preserve continuity. Delegation and inheritance may be relevant for institutional roles, not personal rights in a broad legal sense. For example, a ministry department may delegate credential issuance to an agency. A project operator may transfer asset records to a successor operator. A community stewardship body may designate new representatives. A node operator may transfer control under governance review. These transitions require successor credentials, not silent account changes. Multi-generation credentialing supports intergenerational verifiability. It allows future actors to inspect who had authority in the past and how that authority changed. ### Credential Layer Security The Credential Layer is a critical security surface. If credential issuance, status, keys, wallets, registries, or verification methods are compromised, the entire NSF trust fabric is weakened. Security controls should include issuer key management, hardware security modules or secure key storage where appropriate, key rotation, revocation, recovery, multi-signature issuance for high-impact credentials, threshold approvals, phishing-resistant authentication, wallet security, device binding where appropriate, credential encryption, presentation policies, replay protection, nonce-based verification, verifier authentication, and audit logs. Issuer compromise must be handled through rapid status updates. If an issuer key is compromised, affected credentials may need suspension, reissuance, or review. If a wallet is compromised, subject credentials may need rotation. If a status registry is compromised, verifiers need fallback validation. If an AI agent credential is stolen, tool access should be revoked. If a node credential is misused, dependent proof receipts may require review. Credential verification should prevent replay and impersonation. Presentations should be bound to verifier challenge, time, purpose, and audience where needed. Selective disclosure should not allow correlation beyond intended scope. Pairwise identifiers may reduce tracking. Privacy and security can conflict. Excessive logging can expose sensitive relationships. Insufficient logging can undermine accountability. NSF must define logging profiles by risk and domain. Credential security is not only cryptographic. It includes governance, issuer discipline, recovery, human processes, and incident response. ### Credential Layer and Public-Good Claims Discipline Credentials can create false reliance if their names or outputs overstate meaning. NSF must apply claims discipline to credential naming, metadata, public presentation, and verification outputs. A credential called CertifiedResilientProjectVC would be unsafe unless a competent certification process exists. A safer term may be ProjectResilienceEvidenceVC, ProjectReadinessRecordVC, or SafeguardEvidenceVC, depending on scope. A credential called FinanceApprovedVC would be inappropriate unless issued by a competent financial actor under lawful process. A safer term may be FinanceReadinessEvidenceVC. A credential called InsuredVC would be inappropriate unless issued by an insurer under a binding policy. A safer term may be InsuranceReadinessEvidenceVC or RiskEvidencePackageVC. A credential called OfficialWarningVC should not exist unless issued by competent public warning authority. A public-safe output credential should distinguish analysis from official public authority communication. Credential verifiers should display boundary statements where necessary. A credential may be valid, but limited. It may support review, not approval. It may show evidence completeness, not outcome quality. It may show training completion, not legal authorization. It may show model evaluation, not safety for all use cases. It may show public-safe review, not official endorsement. This discipline protects NSF from credibility collapse and protects users from misinterpretation. ### Credential Layer Across GNC, RNC, and NNC Architecture The Credential Layer operates across the Global Nexus Consortium, Regional Nexus Consortiums, National Nexus Consortiums, community governance bodies, and enterprise implementation stack. At the global level, the Global Nexus Consortium can maintain reference credential schemas, interoperability profiles, proof receipt mappings, public-good role vocabularies, and global learning loops. It can support cross-regional comparability without becoming a universal identity authority. At the regional level, Regional Nexus Consortiums can manage regional recognition, cross-border credentials, shared disaster response roles, regional technical reviewer credentials, regional public-safe reporting credentials, and corridor-specific operational credentials. At the national level, National Nexus Consortiums can align credentials with domestic law, public authority context, national digital public infrastructure, Sovereign Data Zones, national risk registers, local languages, national credential issuers, and public-safe reporting rules. At the community level, recognized community bodies can manage credentials related to local knowledge, protected participation, community stewardship, public-safe mapping, grievance pathways, and data access. At the enterprise layer, National Consortium Companies, Project SPVs, providers, operators, contractors, insurers, investors, and technical partners may use credentials for implementation roles, evidence workflows, access control, asset monitoring, and readiness records. Their credentials must remain scoped and must not imply public-good authority unless recognized through governance. This multiscale credential architecture allows NSF to identify actors without centralizing all identity. It enables sovereign control, regional interoperability, global reference alignment, community safeguards, and enterprise delivery. ### Credential Layer Boundary Statement The NSF Credential Layer supports identity, role, permission, evidence, authority scope, credential issuance, status verification, revocation, suspension, recognition, selective disclosure, access control, governance participation, machine identity, node identity, model identity, and public-safe reporting workflows. It does not by itself create public authority, legal licensing, professional certification, regulatory approval, procurement approval, finance approval, investment advice, insurance underwriting, treaty compliance, official public warning, or endorsement. Where such effects exist, they must come from competent authorities, lawful issuers, regulated actors, contractual instruments, or applicable law. NSF credentials can represent, support, or verify those effects only when issued and recognized under appropriate authority. A credential is a signed claim under a schema. Its meaning depends on issuer, evidence, status, scope, jurisdiction, and recognition. It must not be treated as universal legitimacy. This boundary is essential for institutional adoption and public trust. ### The Credential Layer as Institutional Trust Fabric The Credential Layer is the institutional trust fabric of the Nexus Sovereignty Framework. It is the interface between governance and agency, between identity and action, between human authority and machine execution, between privacy and verification, between local sovereignty and global interoperability. It ensures that no role is assumed without a credential. No credential is trusted without a schema. No schema is active without governance. No issuer acts without standing. No issuance occurs without evidence. No evidence matters without provenance. No access occurs without purpose and permission. No machine acts without identity. No AI agent uses tools without scope. No node serves trust without status. No public output is published without public-safe authority. No credential remains valid forever without review. No revocation occurs without a record. No cross-border recognition occurs without mapping. No privacy-preserving proof becomes unaccountable. With the Credential Layer, every actor in NSF becomes verifiably governed. Humans, institutions, communities, machines, models, nodes, agents, datasets, and projects can participate in a shared trust architecture without surrendering sovereignty to a central platform or financialized token system. The Credential Layer makes authority portable, but not unbounded. It makes identity verifiable, but not necessarily exposed. It makes permission actionable, but not permanent. It makes credentials machine-readable, but still institutionally accountable. It makes governance interoperable, but still jurisdiction-aware. It makes trust cryptographic, but still human-governed. Without the Credential Layer, NSF would have no actors. With it, every actor can be known, scoped, verified, audited, suspended, corrected, and empowered under the rules of a public-good sovereignty framework. --- # 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/ii.-architecture/credential-layer.md?ask=&goal= ``` `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.