# Time-Limited and Conditional Credentials

#### **5.6.1 Why Time and Conditions Are First-Class Governance Constraints**

In NSF, trust must be:

* **Context-aware**
* **Revocable by design**
* **Tied to temporal or policy-specific scopes**
* **Enforceable in zero-trust, machine-verifiable environments**

Time-limited and conditional credentials allow:

* Operators to act during a crisis period—but not before or after
* Jurisdictional agents to access systems only when simulations forecast risk
* Simulations to be used as evidence—but only for defined policy triggers
* Role escalation to occur dynamically under credential-bound logic

These constraints are **cryptographically enforced**, not merely advisory.

***

#### **5.6.2 Time-Limited Credential Semantics**

Every NSF VC supports:

```json
"valid_from": "2025-01-01T00:00Z",
"expires": "2025-06-30T23:59Z"
```

During clause execution or credential presentation:

* The current UTC time must fall within the defined interval
* Expired credentials are rejected by:
  * Execution environments
  * Simulation verifiers
  * Policy binding clauses
  * Credential oracles

These fields are **non-optional** for operational, simulation, and legal VCs.

***

#### **5.6.3 Grace Periods and Expiration Policies**

DAO governance can define:

* **Grace intervals**: e.g., allow VC use for 72 hours after expiry for rollback safety
* **Soft expiration**: trigger alerts without immediate revocation
* **Auto-renewal conditions**: if clause X or simulation Y executes successfully
* **Revocation-linked expiration**: if a parent credential is revoked, child VCs expire immediately

These rules are encoded in the **Credential Policy Layer** and referenced by the Credential Registry.

***

#### **5.6.4 Conditional Credential Logic**

NSF credentials can embed policy constraints beyond time:

| Constraint Type          | Description                                                 |
| ------------------------ | ----------------------------------------------------------- |
| **Simulation-bound**     | Only valid if simulation X has run with outcome Y           |
| **Sensor-triggered**     | Valid only when IoT input is above/below threshold          |
| **Clause-scoped**        | VC may only be used for clauses matching a defined pattern  |
| **Credential-dependent** | VC valid only if another VC is also active                  |
| **Governance-triggered** | VC becomes valid/invalid via DAO vote or emergency override |

Example:

```json
"conditions": {
  "simulation_dependency": "FloodForecastSim#0x983f",
  "allowed_clauses": ["FloodReliefDispatch@2.1.*"],
  "jurisdiction": "BGD",
  "thresholds": {
    "rainfall": ">= 180mm",
    "disaster_index": ">= 4"
  }
}
```

***

#### **5.6.5 Binding Conditional VCs to Execution Workflows**

Clause logic will enforce:

```scl
if hasVC("FloodReliefOperatorVC")  
and VC.condition_satisfied("simulation_dependency")  
and VC.is_valid(now)  
then execute Clause
```

This turns policy logic into **runtime-executed smart authorization filters**, without human intervention.

***

#### **5.6.6 Dynamic Role Elevation and Temporary Escalation**

NSF supports **tiered VC escalation**, where:

* A base credential (e.g., FieldAgentVC)
* Can be temporarily upgraded (e.g., EmergencyCoordinatorVC)
* If specific conditions are met, such as:
  * Sensor alerts
  * Simulation outcomes
  * DAO vote
  * Clause logic (e.g., trigger from treaty activation)

These credentials are:

* Time-limited (e.g., 72 hours)
* Audited on issuance and use
* Auto-expiring after escalation window closes
* Logically scoped by binding clause hash

***

#### **5.6.7 Smart Clause Binding with Dynamic Validity Windows**

Clauses can reference credentials with logic like:

```scl
accept VC where:
  valid_from <= now <= expires  
  and VC.has_simulation("HealthRiskSim#0x55a8")  
  and jurisdiction in ["KEN", "UGA", "TZA"]
```

These checks are enforced at:

* TEE runtime
* ZK circuit input validation
* Credential oracle pre-verification
* DAO policy oversight

***

#### **5.6.8 Use in Simulation and Forecast Validity**

Simulation outputs can only be:

* Used for action
* Trigger credential issuance
* Inform policy

…if the simulation’s own **SimulationModelVC** and **SimulationRunVC** are still valid.

Expired simulations must:

* Be rerun
* Use updated models
* Trigger revalidation workflows

This ensures **governance decisions reflect current data and models**.

***

#### **5.6.9 Credential Oracles and Expiry Propagation**

NSF Credential Oracles (see 5.8) monitor:

* Expiry status
* Parent-child VC relationships
* Clause compatibility windows
* Policy-defined retirement schedules

They issue:

* **Expiration events** to trigger auto-revocation
* **Bundled status reports** for DAOs and execution layers
* **Warnings** before credential bundles become invalid

***

#### **5.6.10 Temporal and Conditional Logic as a Pillar of Machine-Led Governance**

In NSF:

* Every credential is **contextual**
* Every policy is **time-bound**
* Every execution is **constrained by cryptographic authorization windows**

This removes ambiguity, protects against stale authority, and enables:

* Automated revocation
* Clause-safe execution
* Time-sensitive disaster governance
* Privacy-preserving but verifiable credential lifecycles

Time-limited and conditional credentials make NSF governance **safe, flexible, programmable—and fully auditable.**

***


---

# Agent Instructions: Querying This Documentation

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

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

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/v.-verifiable-credentials/time-limited-and-conditional-credentials.md?ask=<question>
```

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

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