> 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/credential-bundling-and-vc-composability.md). # Credential Bundling and VC Composability ## Credential Bundling and Verifiable Credential Composability in the Nexus Sovereignty Framework: Modular Trust Assemblies, Dependency Graphs, Delegated Authority, Atomic Authorization, and Audit-Visible Credential Inheritance ### Why Credential Composability Matters Credential composability matters because real governance actions rarely depend on one credential alone. A high-consequence action may require a human role credential, an organizational standing credential, a machine execution credential, a model-status credential, a public-safe review credential, a jurisdictional recognition credential, and a clause-bound CAC evidence credential. A disaster readiness workflow may require a field operator, a simulation model, a national node, a public-safe reviewer, and an authorized program administrator. A public health workflow may require health data access, epidemiological model status, privacy review, jurisdictional authority, and controlled disclosure approval. A Project SPV evidence workflow may require asset operator credentials, evidence room credentials, climate model credentials, safeguard reviewer credentials, finance-readiness evidence credentials, and insurance-readiness evidence credentials. An AI agent may require identity, model-status, tool-use, memory-policy, data-access, and public-safe-output credentials before it can perform a bounded action. If every clause had to check these credentials manually, governance logic would become rigid, repetitive, and fragile. If every actor had to hold one massive credential covering all roles, the system would become unsafe, because authority would be over-bundled and difficult to revoke. NSF resolves this through **credential bundling** and **Verifiable Credential composability**. Instead of treating credentials as isolated tokens, NSF allows credentials to be assembled into structured, signed, dependency-aware trust bundles. A credential bundle does not erase the individuality of component credentials. It does not merge separate authorities into a single unlimited credential. It creates a verifiable composition: this actor, workflow, node, project, agent, or institutional function has these credentials, under these dependencies, in this jurisdiction, for this time period, under this clause or governance scope, with these inheritance rules, revocation propagation rules, and audit obligations. Composability is therefore the mechanism by which NSF handles multi-role governance without creating monolithic permissions. It enables modular authorization. It supports delegation. It preserves revocation. It makes trust graphs inspectable. It allows Smart Clauses to evaluate complex authority conditions atomically. It allows AI agents to reason about permissions without guessing. It supports cross-jurisdictional coordination while keeping recognition scoped. The core doctrine is: **Credential bundles may assemble multiple credentials into a governed authorization graph, but they must preserve each component credential’s issuer, scope, validity, revocation status, clause binding, jurisdiction, and non-meaning boundaries. Composability increases coordination capacity; it must not inflate authority.** ### Credential Bundles Are Trust Graphs, Not Super-Credentials A credential bundle is not a super-credential that overrides its components. It is a signed trust graph. The bundle references component VCs, declares dependencies, defines the conditions under which the bundle may be used, and allows the execution engine to verify the whole set consistently. The bundle can make credential use easier, but it cannot create authority that no component credential, issuer, governance rule, or recognition record provides. This distinction is critical. If a bundle includes a DisasterOperatorVC, SimulationModelVC, and PublicSafeReviewerVC, the bundle does not automatically authorize relief disbursement, official public warning issuance, legal enforcement, finance approval, insurance underwriting, procurement approval, or regulatory determination. It authorizes only the actions declared by its binding clause, component credentials, issuer scope, jurisdiction, and governance policy. If one component credential expires, is suspended, becomes disputed, or falls outside jurisdiction, the bundle must respond accordingly. Credential composability should therefore be understood as **structured least-privilege coordination**. The bundle reduces operational overhead while preserving scoped authority and revocation paths. ### Credential Bundle Definition A Credential Bundle is a signed object that references multiple Verifiable Credentials and declares how those credentials operate together. It may be used to authorize a clause execution, access a controlled evidence room, validate a multi-party workflow, route a public-safe review, assign a temporary operational team, support a Project SPV evidence package, or allow an AI agent to perform a bounded task. A bundle should include bundle ID, issuer, subject, included credentials, dependency graph, binding clause, jurisdiction, governance scope, validity window, allowed actions, prohibited actions, revocation propagation rules, disclosure profile, audit requirements, and proof references. It may also include component-holder signatures, multi-party countersignatures, CAC references, rollup references, or ZK proofs. A mature bundle structure may look like: ```json { "bundle_id": "vcbundle-0x9a7c", "type": "CredentialBundle", "issuer": "did:nsf:org:RegionalDisasterEvidenceRegistry", "subject": "did:nsf:org:EmergencyResponseTeam-17", "includes": [ { "vc_id": "DisasterReliefOperatorVC#0x91a2", "role": "field-evidence-submission", "required": true }, { "vc_id": "ForecastModelVC#0x4ff9", "role": "risk-forecast-support", "required": true }, { "vc_id": "PublicSafeReviewerVC#0x18f2", "role": "public-output-review", "required": true } ], "dependency_graph": { "PublicSafeReviewerVC#0x18f2": [ "ForecastModelVC#0x4ff9" ], "DisasterReliefOperatorVC#0x91a2": [] }, "binding_clause": "DisasterRef::Relief::MultiRoleEvidenceRoutingClause@2.0", "jurisdiction": "EGY", "authority_class": "evidence-support-and-routing", "valid_until": "2025-12-31", "non_meaning": [ "not-official-public-warning", "not-relief-approval", "not-financial-transfer-authorization" ] } ``` The seed uses `UNDRR-DAO`. Unless an official UNDRR process exists, examples should use claims-safe identifiers such as `RegionalDisasterEvidenceRegistry`, `UNDRRRef`, or `DisasterRiskReductionReferenceProfile`. NSF should avoid implying that UN bodies, treaty bodies, or public authorities issue or govern bundles unless that has been formally established. A credential bundle becomes valid only if its own signature verifies, all required component credentials verify, dependencies resolve, scopes match, revocation status is active, clause bindings are compatible, jurisdictional constraints pass, and the requested action is within the bundle’s declared purpose. ### Use Cases for VC Bundling Credential bundling is useful wherever governance requires multiple proofs at once. In disaster response, a bundle may combine field operator authority, training evidence, sensor provider credentials, public-safe reviewer authority, national node recognition, and simulation model status. This allows a clause to determine whether a team can submit evidence, receive restricted briefings, or request evidence routing. In public health, a bundle may combine health data access, privacy officer authority, model review status, national jurisdictional scope, and public-safe output clearance. This allows CACs to support restricted analysis while preventing public disclosure of sensitive health signals. In supply chains, a bundle may combine facility operator credentials, inspection credentials, product traceability credentials, geospatial evidence credentials, emissions evidence credentials, and jurisdictional export evidence records. The bundle supports traceability without implying legal clearance unless a competent authority issues it. In AI governance, a bundle may combine AgentIdentityVC, ModelStatusVC, ToolUseVC, DataAccessVC, MemoryPolicyVC, HumanSupervisorVC, and PublicSafeDraftingVC. This allows the agent to operate only when all required controls remain active. In Project SPV workflows, a bundle may combine ProjectSPVEvidenceRoomVC, AssetOperatorEvidenceVC, ClimateScenarioReviewerVC, SafeguardEvidenceReviewerVC, DataProviderVC, FinanceReadinessEvidenceVC, and InsuranceReadinessEvidenceVC. This supports evidence review without implying investment advice, finance approval, underwriting, claims determination, or insurability. In community and Indigenous data governance, a bundle may combine CommunityStewardVC, ProtectedKnowledgeReviewVC, PublicSafeMapClearanceVC, GrievanceFacilitatorVC, and DataAccessVC. This preserves community safeguards while enabling controlled evidence workflows. In cross-jurisdictional operations, a bundle may combine national recognition credentials, regional coordination credentials, and local execution credentials. This allows a regional workflow to verify that each actor has standing in the relevant jurisdiction without flattening local authority. In simulation governance, a bundle may combine ForecastModelVC, DatasetLineageVC, SimulationRunnerVC, SimulationValidatorVC, ModelStatusVC, and CAC evidence records. This supports model-dependent clause execution and later audit. Credential bundles make these workflows more efficient while retaining modular trust. ### Dependency Graphs in Bundled Credentials A credential bundle should declare a dependency graph. The dependency graph shows which credentials depend on other credentials, which credentials are foundational, which are optional, which are alternatives, and which revocations propagate. For example: ```json { "dependencies": { "ForecastModelVC#0x44a1": [], "SimulationRunProofVC#0x81bd": [ "ForecastModelVC#0x44a1", "SimulationRunnerVC#0x32fa" ], "ReliefOperatorVC#0x91a2": [], "PublicSafeOutputReviewVC#0x74cc": [ "SimulationRunProofVC#0x81bd", "ReliefOperatorVC#0x91a2" ] } } ``` This graph allows the execution engine to reason about trust. If the ForecastModelVC is suspended, the SimulationRunProofVC may become under review. If the SimulationRunProofVC is disputed, the PublicSafeOutputReviewVC may no longer support public-facing outputs. If the ReliefOperatorVC expires, field evidence submission may fail, while model review remains valid. If the PublicSafeOutputReviewVC is revoked, internal evidence workflows may continue, but public publication is blocked. Dependency graphs support clear paths of authority, nested trust chains, execution-time evaluation, audit visualization, and dispute reconstruction. They prevent systems from treating a bundle as a flat list of credentials. Authority often depends on sequence and relationship. The graph captures that. Dependency graphs should support AND, OR, threshold, sequence, exclusion, and conditional dependencies. A clause may require any two of three validators, or a national credential plus one local recognition credential, or a public-safe reviewer only if the output is public. These structures should be explicit. ### Composable Credential Types Composable credentials may include operational credentials, standing credentials, simulation credentials, credential governance credentials, node credentials, AI agent credentials, public-safe credentials, community stewardship credentials, Project SPV evidence credentials, registry credentials, emergency credentials, and controlled-room access credentials. Each composable credential should expose metadata that allows safe bundling: Credential type. Issuer DID. Subject DID or commitment. Validity window. Jurisdiction scope. Authority class. Allowed actions. Prohibited actions. Clause binding. CAC evidence binding. Credential status method. Revocation propagation rule. Delegation permissions. Disclosure profile. Recognition rules. Compatibility constraints. A credential that does not declare these fields is difficult to compose safely. For example, if a credential does not declare whether it may be delegated, it should not be delegated. If it does not declare jurisdiction, it should not be assumed cross-jurisdictional. If it does not declare revocation propagation, the bundle should take a conservative approach and mark dependent actions under review when the credential changes status. Composable credentials must be designed for machine interpretation. Ambiguous credentials create governance risk. ### Bundle Signature and Validation Each credential bundle should be signed by an authorized issuer or bundle coordinator. The signer may be a national registry, regional registry, community steward body, credential governance registry, enterprise evidence room, Project SPV governance function, public-safe governance function, or other authorized issuer. DAO tooling may support bundle approval, but the bundle authority should be represented by a DID, credential, and registry scope. Some bundles may require countersignatures. A multi-party operational bundle may require component credential holders to consent. A Project SPV evidence bundle may require evidence room, asset operator, and reviewer countersignatures. A cross-jurisdictional bundle may require national and regional signatures. A community bundle may require community steward signatures. A high-risk AI agent bundle may require operator, safety reviewer, and tool owner signatures. Bundle validation should check: The bundle signature. The bundle issuer’s authority. The component credential signatures. The component credential statuses. The component credential issuer statuses. Validity windows. Jurisdiction and recognition rules. Dependency graph satisfaction. Clause binding compatibility. CAC evidence references. Revocation propagation rules. Disclosure constraints. Execution environment scope. Replay and one-time-use constraints. Safe-mode or dispute status. Partial validation may be possible. A public verifier may validate the public portion of a bundle, while restricted component credentials remain hidden behind commitments or ZK proofs. This is important for privacy-preserving workflows. A bundle is valid only under its declared action and scope. It should not become a portable authority object outside that scope. ### Inheritance and Delegation Rules Credential bundles support inheritance and delegation, but only under explicit rules. **Role delegation** allows a primary credential holder to delegate specific actions to another DID. For example, a national disaster coordinator may delegate field evidence submission to a municipal operator. The delegation must identify the action, jurisdiction, time period, revocation path, and supervising authority. **Time-bounded inheritance** allows temporary access based on a superior credential. For example, an emergency field team may receive 72-hour restricted access to CAC streams during a flood event. The access expires automatically. **Geographic scoping** restricts delegated or inherited roles to a jurisdiction, municipality, corridor, basin, facility, community territory, or SDZ. **Clause-bounded inheritance** restricts use to specific clauses or clause families. A delegated credential may support evidence submission for one hazard clause, not all disaster workflows. **Data-class scoping** restricts access to public, restricted, confidential, sovereign-controlled, community-controlled, or enterprise evidence fields. **Override logic** defines how a parent credential, governance body, issuer, national node, community steward, or enterprise evidence function can suspend or revoke a bundle. Delegation VCs must include a revocation path and trusted anchor signature. They should also include non-delegation rules. Some credentials should never be delegable, such as certain public-safe approvals, issuer root credentials, high-risk machine keys, or legal standing credentials. Inheritance must not expand authority beyond the parent credential. A delegate cannot receive broader scope than the delegator has. A bundle cannot inherit public authority from a credential that does not carry public authority. Delegation makes governance scalable, but only if it remains bounded. ### Nested Credential Evaluation During Clause Execution When a Smart Clause references a bundle, the execution engine must evaluate the bundle atomically. It should not simply load all component credentials and assume that more credentials mean more authority. A clause may declare: ```scl require bundle("EmergencyReliefEvidenceOperatorBundle") ``` The execution engine should then resolve the bundle ID, verify the bundle signature, load disclosed component credentials, verify component signatures and statuses, resolve dependencies, check issuer authority, validate jurisdictional filters, confirm clause hash compatibility, check CAC bindings, enforce privacy and disclosure rules, and evaluate whether the bundle satisfies the clause’s authorization condition. If any required component fails, the bundle fails for that action. If an optional component fails, the clause may proceed with reduced authority only if policy permits. If a component is under review, the clause may route to manual review. If a credential is expired, the bundle fails unless a valid emergency override applies. If jurisdiction does not match, the bundle fails or requires recognition. If a dependency is broken, downstream credentials cannot be relied upon. Atomic evaluation prevents partial trust from being misread as full authorization. ### Bundle Revocation and Propagation Credential bundles must define what happens when component credentials change status. This is revocation propagation. If a required credential is revoked, the bundle may become invalid. If a supporting credential is suspended, the bundle may become under review. If a model credential is deprecated, model-dependent actions may be blocked while other actions remain valid. If a public-safe reviewer credential is revoked, internal evidence routing may continue but publication must stop. If an issuer credential is revoked, credentials issued by that issuer may require review. If a parent delegation credential expires, child delegated credentials should fail. Bundle-level revocation may also occur. The bundle itself may be revoked, suspended, expired, superseded, or restricted. This may be necessary if the bundle was issued under false assumptions, if its dependency graph was wrong, if its jurisdictional recognition changes, or if the workflow ends. Revocation propagation rules should be machine-readable. They should distinguish invalid, restricted, under review, historical-only, and superseded states. They should preserve history. They should generate audit events. Bundle revocation is how composability stays safe over time. ### Selective Disclosure in Credential Bundles Credential bundles may include sensitive credentials. A verifier may not need to see all component details. NSF should support selective disclosure for bundles. A bundle may disclose that it contains a valid SimulationValidatorVC without revealing the validator’s personal identity. It may prove that a public-safe reviewer credential exists without disclosing internal training records. It may prove that a Project SPV evidence room has active access credentials without revealing commercial details. It may prove that a community steward approved a public-safe map layer without exposing protected knowledge. ZK proofs, commitments, status roots, and selective disclosure VCs can allow partial validation. The bundle can prove dependency satisfaction without exposing every field. The Audit Layer can preserve restricted details for authorized review. Selective disclosure prevents credential composability from becoming identity aggregation or surveillance. ### Registry and Audit Layer Integration Credential bundles should be registered with unique bundle IDs and indexed in the Credential Registry. The registry should link bundle ID, issuer, subject, component credentials, dependency graph hash, binding clause, jurisdiction, valid period, status, revocation propagation rules, disclosure profile, and audit records. The Audit Layer should display bundles as trust graphs. Reviewers should be able to inspect which credentials support which actions, which dependencies exist, which credentials are active, which are disputed, and what happens if one component changes status. Useful queries include: `Show all bundles that include ForecastModelVC#0x44a1.` `List bundles expiring before 2025-09-01 in jurisdiction = KEN.` `Find all Project SPV evidence bundles containing a suspended data provider credential.` `Show all public-safe output bundles dependent on SimulationModelVC#FloodRiskSim@3.2.` `List all bundles with delegated emergency access active in the last 72 hours.` `Find all AI agent tool-use bundles containing ModelStatusVC = QUARANTINED.` These queries allow governance bodies to correct trust at scale. ### Bundle Compatibility Across Jurisdictions Cross-jurisdictional bundles require explicit recognition rules. A bundle valid in one country is not automatically valid in another. A regional disaster bundle may include national components from several jurisdictions. Each component credential may have different recognition rules. The bundle must declare which jurisdictions accept which components for which actions. A bundle may be valid for regional evidence coordination but not domestic field deployment. It may support public-safe summary review but not official warning issuance. It may support cross-border simulation review but not national credential issuance. It may support Project SPV diligence review but not procurement approval. Cross-jurisdictional bundle validation should check each component’s recognition status, the bundle issuer’s scope, and the invoking clause’s jurisdiction. If recognition is partial, the execution engine should restrict the action accordingly. Interoperability is not universal acceptance. Composability makes differences machine-readable. ### Credential Bundles for AI Agents AI agents should rely heavily on credential bundles because agent authority is multi-dimensional. An agent may require identity, operator, model status, data access, tool permission, memory policy, public-safe policy, human supervision, and jurisdictional scope credentials. These should be bundled for specific tasks. An AI Agent Operational Bundle may include: AgentIdentityVC. ModelStatusVC. ToolUseVC. DataAccessVC. MemoryPolicyVC. HumanSupervisorVC. PublicSafeDraftingVC. JurisdictionalScopeVC. The bundle should define allowed tools, prohibited actions, data classes, retention rules, output review requirements, and expiration. If the model is quarantined, the bundle fails. If tool permission expires, tool use stops. If public-safe reviewer credential is missing, public output is blocked. Credential bundles prevent AI agents from operating with vague or stale authority. ### Credential Bundles for Project SPVs, Finance-Readiness, and Insurance-Readiness Project SPV workflows are natural candidates for credential bundles. A Project SPV Evidence Bundle may combine: ProjectSPVEvidenceRoomVC. AssetOperatorEvidenceVC. DataProviderVC. ClimateScenarioReviewerVC. SafeguardEvidenceReviewerVC. MaintenanceEvidenceVC. PublicSafeSummaryReviewVC. FinanceReadinessEvidenceVC. InsuranceReadinessEvidenceVC. Such a bundle can support controlled evidence review, readiness reporting, and diligence workflows while preserving boundaries. It should state clearly that the bundle is not investment advice, not finance approval, not credit rating, not underwriting, not coverage, not claim determination, not procurement approval, and not public authority endorsement. If a data provider credential is revoked, the bundle may become partially under review. If a climate model credential is superseded, the climate component may require rerun. If an evidence room credential expires, controlled access stops. If a public-safe review credential is missing, publication is blocked. Credential bundles make capital-relevant evidence modular and correctable. ### Credential Bundles Across GNC, RNC, and NNC Architecture At the national level, National Nexus Consortiums may issue or recognize bundles for domestic operations, national SDZ access, public-safe review, disaster coordination, public health workflows, Project SPV evidence, and national credential issuers. At the regional level, Regional Nexus Consortiums may support bundles for cross-border simulations, shared hazards, corridor governance, regional public-safe outputs, mutual recognition, and regional evidence coordination. At the global level, the Global Nexus Consortium may define bundle schemas, dependency graph formats, interoperability rules, conformance profiles, and claims-discipline vocabulary. It should not centrally authorize all bundles. At the community level, community and Indigenous governance bodies may define bundles for protected knowledge, community stewardship, public-safe map review, grievance processes, and local data access. At the enterprise layer, National Consortium Companies, Project SPVs, operators, providers, insurers, investors, contractors, and evidence rooms may use bundles for lawful implementation and controlled evidence workflows. This allows credential composability to operate across the full public-good and enterprise stack without collapsing governance boundaries. ### Credential Composability Boundary Statement Credential bundling and VC composability support modular authorization, multi-role coordination, delegation, nested trust chains, dependency graphs, atomic clause authorization, selective disclosure, registry indexing, audit visualization, AI agent control, Project SPV evidence workflows, finance-readiness evidence, insurance-readiness evidence, and cross-jurisdictional recognition checks. They do not by themselves create public authority, legal compliance, professional licensing, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty enforcement, legal liability, or universal recognition. A credential bundle proves that multiple credentials were assembled, signed, and evaluated under a declared scope. Its authority depends on component credential authority, issuer authority, clause binding, jurisdiction, recognition rules, credential status, governance policy, applicable law, contracts, community rules, and institutional adoption. A bundle is not a super-credential. A dependency graph is not legal authority. Delegation is not unlimited transfer of power. Cross-jurisdictional composition is not universal recognition. A finance-readiness bundle is not finance approval. An insurance-readiness bundle is not underwriting. A disaster response bundle is not official emergency command unless competent authority provides that status. This boundary must appear in bundle schemas, credential registries, verifier tools, AI agent policies, audit dashboards, public-safe outputs, and documentation. ### VC Composability as a Governance Primitive VC composability turns credentials into modular trust assemblies. Instead of forcing every actor to carry a broad credential or every clause to recreate complex authorization logic, NSF allows credentials to be bundled, dependency-checked, selectively disclosed, revocation-aware, and evaluated atomically. This makes NSF modular because credentials can remain separate by role. It makes NSF scalable because workflows can reuse trust components. It makes NSF auditable because every dependency is declarative. It makes NSF programmable because clauses can evaluate nested authority. It makes NSF safer because revocation propagates through explicit graphs. It makes NSF interoperable because jurisdictions can declare partial recognition instead of all-or-nothing acceptance. It makes NSF AI-ready because agents can reason over structured authority rather than natural-language labels. It makes NSF correctionable because trust bundles can be updated without erasing history. Credential bundling is therefore not a convenience feature. It is a governance primitive for complex institutional systems. It allows humans, machines, institutions, communities, and enterprise actors to coordinate through precise, bounded, composable trust. That is the role of Credential Bundling and VC Composability in the Nexus Sovereignty Framework: to transform credentials from isolated tokens into verifiable, modular, dependency-aware trust structures capable of supporting real-world governance across jurisdictions, domains, and execution environments. --- # 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/credential-bundling-and-vc-composability.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.