Trust Decay Framework (TDF)

A Confidence-Based Classification System for Digital Credentials
Version 1.0.0 Editor's Draft
Sirraya Labs • Open Specification • April 2026

Abstract

The Trust Decay Framework (TDF) defines a standardized approach for assessing and expressing the current trustworthiness of a digital credential over time. Trust is not static—it naturally diminishes without ongoing evidence of security and identity consistency. This specification provides a mechanism for credentials to carry a confidence level that decays according to predictable rules and can be refreshed through cryptographic proofs, heartbeat mechanisms, and risk assessment.

Built on established standards like W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs), TDF enables issuers to create credentials with an initial trust level, and verifiers to evaluate the current trust level based on age, cryptographic strength, zero-knowledge proofs, and risk signals.

📘 About This Document
This is an open specification developed by Sirraya Labs. It is intended for implementation experimentation and community feedback. All content is licensed under the MIT License.

1. Introduction

In digital identity systems, trust in a credential should not be permanent. A credential issued today may be less trustworthy tomorrow if the holder's device changes, if suspicious activity is detected, or simply because time has passed without re-verification.

The Trust Decay Framework addresses this by introducing:

1.1 Design Principles

💡 Example: Banking Application
A bank requires Level 3 (High Trust) for wire transfers. The user holds a Level 4 (Maximum Trust) credential that has been active for 45 days. The system calculates the current trust level, finds it at Level 3, and grants access.

2. Core Concepts

2.1 Terminology

Confidence Level
A four-tier classification (Level 1 to Level 4) indicating the current trustworthiness of a credential, with Level 4 being the highest.
Trust Half-Life
The period after which confidence decreases by 50% without refreshment.
Heartbeat
A cryptographic proof that the credential holder remains in control, used to slow or reverse trust decay.
Risk Signal
An observable event that may indicate compromised security, triggering immediate trust reduction.
Zero-Knowledge Proof (ZKP)
A cryptographic method that proves a statement is true without revealing the underlying data. Used to verify risk status without exposing sensitive information.
Pairwise Identifier
A unique identifier derived for each relationship, preventing correlation across different services.

3. Trust Levels

The framework defines four confidence levels. Each level has distinct characteristics, proof requirements, and decay properties.

Level Name Half-Life Typical Use Cases Required Proofs
Level 1 Basic Trust 7 days Anonymous access, low-risk services None
Level 2 Standard Trust 90 days Standard enterprise, retail banking No recent high-risk activity (24h)
Level 3 High Trust 90 days High-value banking, corporate access No high-risk + device consistency (7d)
Level 4 Maximum Trust 30 days Government services, critical systems No high-risk + device consistency (30d) + stable location (72h)
Why Different Half-Lives? Higher trust levels require more frequent refreshment because they grant access to more sensitive resources. Level 4 decays in 30 days, while Level 2 can last 90 days without renewal.

3.1 Trust Operations

Demotion: When trust decays or risks are detected, the level decreases. A Level 4 credential becomes Level 3 after sufficient decay.

Promotion: When valid heartbeats are provided, trust may increase. A Level 2 credential with a valid biometric heartbeat may be promoted to Level 3.

Promotion is limited to the credential's original issuance level—a Level 2 credential cannot become Level 4 through heartbeats alone.

4. Credential Format

A Trust Decay credential extends the standard Verifiable Credential format with confidence level information. 

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://spec.sirraya.com/tdf/v1"
  ],
  "id": "urn:uuid:3c4c7e5d-8b2a-4f1e-9c6d-7a3b8e2f5c1d",
  "type": ["VerifiableCredential", "TrustDecayCredential"],
  "issuer": "did:example:issuer123",
  "issuanceDate": "2026-04-01T10:00:00Z",
  "expirationDate": "2027-04-01T10:00:00Z",
  "credentialSubject": {
    "id": "did:example:holder456",
    "confidenceLevel": "Level4",
    "assessmentPolicy": "https://spec.sirraya.com/tdf/policies/v1",
    "validFrom": "2026-04-01T10:00:00Z",
    "validUntil": "2027-04-01T10:00:00Z"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-04-01T10:00:00Z",
    "verificationMethod": "did:example:issuer123#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5hNqKjVkG8P3qR2sT1uVwX9yZ4aB6cD7eF8gH9iJ0kL1"
  }
}

4.1 Credential Fields

5. Trust Decay Calculation

The current trust level is calculated using a deterministic formula that considers age, cryptographic strength, and available proofs.

5.1 Decay Formula

DecayFactor = 2 ^ (-(EffectiveAge × CryptoMultiplier) / HalfLife)

Where:

The resulting trust level is:

📐 Decay Example
A Level 4 credential (half-life 30 days) issued 45 days ago with no heartbeats:

EffectiveAge = 45 days
HalfLife = 30 days
DecayExponent = -(45 × 1) / 30 = -1.5
DecayFactor = 2 ^ (-1.5) = 0.3535

0.3535 > 0.25 → Demote two levels
Level 4 → Level 2

6. Proofs and Heartbeats

Credential holders can provide cryptographic proofs to slow decay or restore trust.

6.1 Proof Types

Proof Type What It Proves Effect on Trust Validity Period
No High-Risk Activity No security alerts in the last 24 hours Required for Level 2+ 24 hours
Device Consistency (7d) Same device used for 7 days Enables Level 3 7 days
Device Consistency (30d) Same device used for 30 days Enables Level 4 30 days
Stable Location (72h) Geographic location stable for 72 hours Enables Level 4 72 hours

6.2 Heartbeat Types

{
  "method": "ZkBiometric",
  "issuedAt": "2026-04-01T12:00:00Z",
  "validUntil": "2026-04-08T12:00:00Z",
  "walletSignature": "0x7a3b8e2f5c1d9e4f...",
  "nonce": "0x8b2a4f1e9c6d...",
  "zkCommitment": "0x3c4c7e5d8b2a..."
}

7. Risk Signals

Risk signals indicate potential security concerns and can trigger immediate trust reduction.

7.1 Signal Types

Signal Type Description Default Action
Device Change Authentication from a new device Demote to Level 2
Geographic Anomaly Location inconsistent with normal behavior Temporary demotion (2 hours)
Behavioral Anomaly Unusual usage patterns detected Require heartbeat (15 min)
Concurrent Session Multiple simultaneous logins Depends on severity
Velocity Anomaly Unusually rapid actions Depends on severity

7.2 Severity Levels

8. Cryptographic Requirements

8.1 Supported Algorithms

Algorithm Status Quantum Resistance Requirement
Ed25519 Approved No REQUIRED
ML-DSA-44 Quantum Resistant Yes RECOMMENDED
ML-DSA-65 Quantum Resistant Yes OPTIONAL
Hybrid Ed25519-ML-DSA Hybrid Yes OPTIONAL

8.2 Quantum Considerations

Implementations SHOULD support hybrid cryptographic modes combining traditional and quantum-resistant algorithms. Cryptographic profiles affect trust calculations:

9. Privacy Considerations

Privacy is a foundational concern in trust assessment. This framework incorporates privacy-preserving mechanisms throughout.

9.1 Pairwise Identifiers

Rather than using a global identifier, implementers SHOULD use pairwise identifiers that are unique per relationship. This prevents correlation across different services. 

PairwiseID = HMAC(RootKey, RelationshipContext || ServiceIdentifier)

The same holder interacting with different services uses different identifiers, making it impossible to link those interactions without the root key.

9.2 Zero-Knowledge Proofs

Risk proofs SHOULD be implemented as zero-knowledge proofs:

9.3 Nullifiers

Each proof includes a nullifier that prevents replay attacks while maintaining unlinkability. Nullifiers are derived from the holder's root key and a context value, ensuring they cannot be correlated across different contexts.

10. Implementation Guidelines

10.1 State Management

Implementations SHOULD maintain credential state including:

10.2 Caching Strategy

10.3 Policy Evaluation

{
  "serviceId": "HighValueBanking",
  "requiredLevel": "Level3",
  "requiredProofs": ["NoHighRisk24h", "DeviceConsistency30d"],
  "maxCredentialAge": 604800,
  "acceptHeartbeats": true,
  "requireQuantumReady": false
}

10.4 Decision Types

11. Security Considerations

11.1 Attack Mitigations

Attack Type Mitigation
Replay Attacks Nonces in heartbeats, timestamps, nullifiers in ZK proofs
Key Compromise Key rotation protocol with grace periods and revocation
Sybil Attacks Proof-of-work for node identifiers, reputation systems
Man-in-the-Middle End-to-end encryption with authenticated key exchange

11.2 Key Rotation

  1. Pre-rotation — Generate new keys, create updated DID Document
  2. Rotation — Sign rotation proof, accept both old and new keys
  3. Post-rotation — Remove old key after grace period (7 days)

12. References

12.1 Normative References

12.2 Informative References

Trust Decay Framework (TDF) — Version 1.0.0

Developed by Sirraya Labs • Open Source • MIT License

GitHub Repository | Specification Home