TRIS Security
TRIS Security
TRIS Security defines the lifecycle of identity protection within Tythe’s trust framework. It ensures that each issued TRIS ID — whether for a Human, Organization, or AI Agent — maintains verifiable authenticity, recoverability, and proof integrity without compromising privacy.
All security operations follow the principles of selective disclosure, revocable proofs, and non-custodial recovery. Only hashed commitments and key references are anchored on-chain; all raw data remains encrypted and locally controlled.
1) Identity Security Model
Off-chain (Private)
Key custody & credential proofs
Wallet keys, credential bundles, and zk-proofs stored locally or within secure enclaves.
On-chain (Public)
Root anchoring & key references
TRISRegistry anchors DID hash, active key references, and credential commitments.
Cross-layer (Verification)
Proof integrity
All verifications require a valid wallet signature referencing the active key set.
Security is maintained through the combination of ownership verification, epoch-based credential hashing, and root anchoring inside the TRISRegistry.
2) DID Lifecycle and Key Management
Every TRIS identity is issued as a Decentralized Identifier (DID) following W3C standards.
Creation
TRIS ID issued with DID + initial key pair.
DID hash and key reference stored in TRISRegistry.
Rotation
User or org rotates keys without re-issuing TRIS.
New key hash replaces old reference; old key marked inactive.
Delegation
Optional secondary signing key for multi-sig orgs or registrants.
Delegated key added to DID document.
Deactivation
Identity intentionally revoked or terminated.
DID reference nullified; cannot sign new proofs.
Recovery
Key loss or compromise, verified through guardian or proof recovery.
Recovery proof verified off-chain; updated key hash re-anchored.
Only the latest active key hash is valid for signature verification. All prior keys remain visible for audit purposes but inactive.
3) Credential Proof Refresh
Credential proofs (zk-KYH/KYC/KYB/KYA) have defined validity periods and can be refreshed without re-issuing the TRIS ID.
zk-KYH
12 months
User-initiated or epoch reminder
zk proof regeneration
zk-KYC (ID only / ID + AML)
12 / 6 months
Expiry or AML list updates
Reclaim verification
zk-KYB
12 months
Ownership or domain change
Dual-source verification
zk-KYA
6 months
Behavioral deviation or Registrant rotation
New fingerprint hash
All proof refreshes update the credentialsRoot in the next DISCRegistry epoch for verifiable continuity.
4) Two-Factor Authentication (2FA)
TRIS supports TOTP-based Two-Factor Authentication (2FA) for sensitive actions and dashboard access. This secondary factor provides an additional verification layer without storing user secrets on Tythe infrastructure.
Activation
Users can enable 2FA by pairing their TRIS account with an authenticator app (Google Authenticator, Authy, etc.).
Mechanism
Time-based one-time password (TOTP) generated locally on the user’s device; validated at login or sensitive action execution.
Scope
Recommended for all; mandatory for users verified with zk-KYC (ID and ID + AML), zk-KYB, or zk-KYA tiers.
Storage
Secret key stored locally by user; Tythe never retains 2FA seed or recovery codes.
Fallback
Recovery through pre-registered Guardian TRIS or secondary email (optional).
This ensures two layers of control — cryptographic ownership (wallet) and temporal verification (TOTP) — while maintaining full user custody.
5) Revocation and Enforcement
User-initiated
Human or Org manually revokes TRIS
Identity disabled; DID reference nullified
TRISRegistry event Revoked(trisId)
BAD Status enforcement
DISC-layer violation
Identity remains active; credibility penalized
DISCRegistry → badRoot
Validator consensus
Systemic fraud or duplicate proof
TRIS revoked; root entry archived
Multi-sig validator threshold
Revocations are permanent for the affected DID but do not erase historical records.
6) Selective Disclosure & Privacy Controls
Metric-level
Limit DISC visibility per metric.
Policy-bound Access Policy.
Temporal
Restrict historical query range.
Trovebook disclosure window.
Entity-based
Permit queries only by specific Orgs or Validators.
Whitelist in DISC API token.
Anonymity
Use pseudonymous handle only.
Omit credentialsRoot inclusion.
Selective disclosure ensures verifiers can confirm proof integrity without exposing identity details.
7) Attestation Integrity
Every verifiable claim must be signed with an active TRIS key.
Key binding
Signature must match active key hash in TRISRegistry.
Nonce + timestamp
Prevents replay attacks; ensures freshness.
Proof binding
Claim linked to credential tier (Human/Org/Agent).
Epoch anchoring
Inclusion in DISCRegistry ensures chronological immutability.
Attestations with expired keys or invalid proofs are automatically rejected.
8) Security Principles
Minimal Exposure
Only hashed roots and key references stored on-chain.
Self-Sovereign Custody
Users retain full control of keys and 2FA.
Recoverable by Design
Guardian or proof recovery enables restoration without central authority.
Composability
Unified security model across Humans, Orgs, and Agents.
Epoch Verifiability
All changes provable against anchored Merkle roots.
9) Recovery & Guardian System
Guardian-based
Trusted TRIS co-signs recovery or unlock.
Guardian signature verified off-chain.
Proof-based
Pre-registered recovery secret regenerates zk-proof.
ZK-validation against hashed secret.
Recovery resets key references while preserving TRIS identity and Trovebook continuity.
10) Threat Mitigation Overview
Key compromise
Rotation + Guardian recovery + 2FA.
Duplicate registration
zk-KYH uniqueness constraint.
Replay attacks
Nonce & timestamp validation.
Credential forgery
zk proof verification + validator oversight.
Unauthorized disclosure
Selective disclosure policies.
On-chain correlation
Minimal anchoring; no PII or direct links.
Last updated
Was this helpful?