Privacy Policy
Effective Date: January 1, 2024
Last Updated: June 17, 2026
This Privacy Policy describes how KryptoOS collects, uses, stores, and protects information when you interact with the KryptoOS project — its website, documentation, open-source software, and public protocol infrastructure.
KryptoOS is a Self-Sovereign Identity (SSI) platform. Privacy is not a feature we bolt on; it is embedded in protocol design: Personally Identifiable Information (PII) stays off-chain, and private keys never leave the holder's device.
This policy applies only to KryptoOS. Applications, wallets, cloud services, or enterprise deployments built by third parties on top of KryptoOS are governed by their own privacy policies — not this document.
1. Scope
This policy covers:
- The KryptoOS website and documentation (
kryptoos.com,kryptoos.web.app, and affiliated domains) - KryptoOS open-source software — SDKs, CLIs, sample apps, verifier/issuer tooling, and reference implementations published under the KryptoOS GitHub repository
- Public KryptoOS infrastructure — documented RPC endpoints, public nodes, and anchoring interfaces used by the protocol
This policy does not cover:
- Third-party wallets, issuers, verifiers, or integrators that use KryptoOS standards
- Private or self-hosted deployments operated by other organizations
- Unofficial forks or modified distributions of KryptoOS software
2. Who We Are
KryptoOS is an open-source Self-Sovereign Identity protocol and developer platform.
For data protection purposes related to this website and official KryptoOS project channels, contact the KryptoOS team via:
- Contact form: /contact
- GitHub: github.com/empoorio/kryptoos (issues and security reports)
- Community: Discord and X / @kryptoos
The KryptoOS protocol itself is decentralized. No single operator controls all network participants, node operators, or third-party deployments.
3. Privacy by Design
KryptoOS is engineered around five core principles:
- Data minimization — Collect and share only what is necessary for a given verification or service.
- Off-chain PII — Names, government identifiers, biometrics, health records, and other sensitive attributes are not written to the public anchoring layer.
- Selective disclosure — Holders present only the claims a verifier needs, not entire credentials.
- Unlinkability — Pairwise DIDs and presentation policies reduce cross-service correlation (see DID Management).
- User control — Holders decide when, with whom, and which attributes to disclose via Verifiable Presentations.
These principles are implemented in protocol design, SDK defaults, and public documentation.
4. What Is On-Chain vs Off-Chain
4.1 On-Chain (Public Anchoring Layer)
When KryptoOS anchors identity state to a public ledger, the following may be recorded:
| Data type | Purpose |
|---|---|
Decentralized Identifiers (did:emp:…) | Public identity anchors |
| Hashes of DID Documents | Integrity verification without exposing document contents |
| Public cryptographic keys | Signature verification |
| Credential anchor hashes | Proof that a credential existed at issuance time |
| Status List 2021 references | Privacy-preserving revocation checks |
| Timestamps, version numbers, transaction metadata | Auditability and ordering |
No raw PII, credential contents, or private keys are stored on-chain.
4.2 Off-Chain (Private, User- or Operator-Controlled)
The following remain off-chain by design:
- Full DID Documents and service endpoint details
- Verifiable Credential contents and Verifiable Presentations
- Private keys and seed phrases
- Biometric templates and KYC document images
- Wallet backups and encrypted credential stores
- Issuer operational databases
Holders store credentials on their own device or in storage they explicitly choose. KryptoOS does not operate a centralized credential vault for end users.
5. Information KryptoOS Collects
What we collect depends on how you interact with KryptoOS.
5.1 Website Visitors and Documentation Readers
When you browse the KryptoOS site or read our docs, we may collect:
- Technical logs — IP address, browser type, operating system, referring URL, pages visited, and timestamps (via hosting infrastructure and CDN logs)
- Analytics — In production, we use Google Analytics (
G-KN9GHR5EKT) to understand aggregate traffic patterns. Analytics is not loaded onlocalhostduring local development - Search queries — Documentation search is processed in-browser; queries are not sent to a third-party search provider by default
- Cookies and local storage — Theme preference (
vitepress-theme-appearance) and similar functional storage
We do not require account registration to read public documentation.
5.2 Developers Using KryptoOS SDKs and Public Endpoints
When you integrate KryptoOS SDKs or call documented public endpoints:
- RPC / WebSocket requests — Public node operators may log request metadata (IP, method, timestamp). Payloads should not contain PII if you follow integration best practices
- GitHub interactions — Issues, pull requests, and discussions on the KryptoOS repository are subject to GitHub's Privacy Statement
- Package registries — Download statistics from npm, PyPI, pub.dev, or similar may be collected by those platforms
KryptoOS SDKs are designed not to phone home with end-user identity data. You are responsible for what your own application collects.
5.3 Protocol Users (Holders, Issuers, Verifiers)
KryptoOS protocol software does not maintain a centralized database of holder identities.
- Holders — Keys are generated locally; credentials and presentations are created and stored on-device or in infrastructure the holder authorizes
- Issuers and verifiers — Organizations deploying KryptoOS act as independent data controllers for PII they collect in KYC, onboarding, or verification flows. They must publish their own privacy notices
- Node operators — May process public on-chain data and infrastructure logs under their own policies
KryptoOS does not access issuer or verifier databases unless explicitly engaged under a separate agreement.
6. How KryptoOS Uses Information
We use information collected through official KryptoOS channels to:
- Operate, secure, and improve the KryptoOS website and documentation
- Measure documentation quality and fix broken or unclear guides
- Respond to support, security, and privacy inquiries
- Detect abuse of public endpoints (rate limiting, DDoS mitigation)
- Comply with legal obligations and enforce our Terms of Service
We do not sell personal information. We do not use on-chain DID data to build advertising profiles.
7. Legal Bases for Processing (GDPR)
If you are in the European Economic Area (EEA), UK, or Switzerland, KryptoOS processes personal data under these legal bases:
| Processing activity | Legal basis |
|---|---|
| Website hosting and security logs | Legitimate interests (Art. 6(1)(f) GDPR) — protecting our services |
| Google Analytics (aggregate usage) | Consent where required by local law; otherwise legitimate interests with opt-out via browser controls and Google Analytics opt-out |
| Responding to contact and privacy requests | Legitimate interests / pre-contractual steps (Art. 6(1)(f), 6(1)(b)) |
| Compliance with legal obligations | Legal obligation (Art. 6(1)(c)) |
On-chain protocol data (public keys, DIDs, hashes) may cease to be personal data once keys are revoked and local credentials are deleted — but may remain personal data while linkable to an identifiable individual.
8. Your Rights
8.1 Rights Regarding KryptoOS Channels
Depending on your jurisdiction, you may have the right to:
- Access — Request information about data KryptoOS holds about you via the website or official project channels
- Correction — Request correction of inaccurate contact or correspondence data
- Deletion — Request deletion of off-chain data we control (subject to legal retention requirements)
- Portability — Receive machine-readable exports where technically feasible
- Objection — Object to processing based on legitimate interests
- Withdraw consent — Where processing is consent-based
Submit requests via /contact with the subject "Privacy Request — KryptoOS".
8.2 Rights Regarding SSI Credentials
Because KryptoOS is self-sovereign:
- Credential contents are controlled by you or your issuer — contact the issuer for credential-specific requests
- On-chain anchors cannot be erased from a public blockchain; you can render them unlinkable by destroying private keys and revoking credentials via Status List 2021
- Right to be forgotten is exercised by: (1) deleting your local wallet, (2) revoking cryptographic keys, (3) requesting issuers delete off-chain copies they hold
The on-chain DID record may persist as a mathematical artifact, but without valid keys it cannot be tied to your real-world identity.
8.3 California Residents (CCPA / CPRA)
California residents may request to know, delete, or correct personal information held by KryptoOS through official channels. KryptoOS does not sell or share personal information for cross-context behavioral advertising.
Submit requests via /contact with "CCPA Privacy Request — KryptoOS".
8.4 Response Times
We aim to respond within 30 days (GDPR) or 45 days (CCPA), subject to applicable extensions.
9. Selective Disclosure and Zero-Knowledge Proofs
KryptoOS is designed so verifiers receive the minimum data necessary to approve or deny a request. This section describes the privacy-preserving mechanisms built into the protocol and SDKs. It does not replace the technical guide — see Privacy & Security for integration examples.
9.1 Selective Disclosure (SD-JWT and BBS+)
Selective disclosure allows a credential holder to reveal individual claims from a credential without exposing the full document.
- SD-JWT (Selective Disclosure JWT) — Issuers can mark fields as selectively disclosable at issuance time. Holders later present only the claims a verifier requests (for example, proving a license is valid without sharing a full name or home address).
- BBS+ signatures — Enable efficient derivation of credentials where only a subset of attributes is cryptographically revealed. The verifier can confirm the derived credential was signed by the original issuer without seeing hidden fields.
In both cases, the verifier learns only what the holder chooses to disclose in that specific presentation. KryptoOS does not centrally log presentation contents.
Holder responsibility: Once attributes are disclosed to a verifier, that verifier becomes responsible for protecting them under its own privacy policy.
9.2 Zero-Knowledge Proofs (ZKPs)
KryptoOS supports zero-knowledge proofs so holders can prove a statement is true without revealing the underlying secret values. Typical use cases documented in KryptoOS include:
- Age thresholds — Prove you are over a minimum age without revealing your birth date
- Range proofs — Prove a numeric value falls within a range without revealing the exact number
- Set membership — Prove membership in an allowed set without revealing which member you are
ZK circuits and proof systems (including SNARK and STARK families referenced in KryptoOS documentation) are used to keep verification fast while preserving privacy. The verifier receives a cryptographic proof and public inputs — not the private inputs used to generate the proof.
Important limitation: ZKPs reduce disclosure during verification; they do not prevent a verifier from storing any attributes you choose to reveal alongside the proof.
9.3 Status List 2021 and Revocation Privacy
KryptoOS implements W3C Status List 2021 for credential revocation. Instead of querying the issuer on every verification, verifiers check a status list bit corresponding to the credential index.
From a privacy perspective:
- Revocation checks do not require transmitting credential contents to the issuer at verification time
- Only the revocation status (valid / revoked / suspended) is resolved — not the underlying PII
- Status list references may be anchored on-chain; list contents are designed to avoid exposing holder identity
Holders can limit long-term linkability by combining status checks with short-lived presentations (nonce and expiry) as described in integration guides.
9.4 Pairwise DIDs and Unlinkable Presentations
Pairwise DIDs allow a holder to use a different did:emp identifier per relationship (employer, bank, healthcare provider, etc.). Services that only see one pairwise DID cannot trivially correlate activity across unrelated verifiers.
KryptoOS SDKs also support unlinkable presentations — fresh randomness and verifier-bound nonces per session — to reduce the chance that two separate verifications can be linked to the same holder session.
These features are optional and must be enabled by wallet and application developers. KryptoOS provides the primitives; deployment choices determine the privacy outcome.
9.5 Verifier Obligations
Even with selective disclosure and ZKPs, verifiers must:
- Request only the claims required for the stated purpose (data minimization)
- Store disclosed attributes securely and delete them when no longer needed
- Not attempt to re-identify holders from on-chain anchors or public DIDs without lawful basis
- Publish their own privacy notice explaining what they collect during KryptoOS-based verification
KryptoOS reference verifiers implement fail-closed checks: if a signature, expiry, nonce, or status list entry is invalid, verification returns negative — there is no partial or best-effort approval path in the default configuration.
10. Third-Party Services Used by KryptoOS
This section lists third-party services that the KryptoOS project uses to operate its website, repositories, and public documentation. It does not describe services used by independent applications built on KryptoOS.
10.1 Google Analytics
In production builds of the KryptoOS website, we load Google Analytics (G-KN9GHR5EKT) to understand aggregate traffic — for example, which documentation pages are most read and where users encounter errors.
- Analytics is not loaded on
localhostduring local development - Analytics is not loaded when the hostname is
localhost, per the site implementation - Data is processed by Google as an independent processor under Google's Privacy Policy
We use analytics for site improvement, not to identify individual credential holders or to profile SSI users across the open web.
10.2 GitHub
Source code, issues, pull requests, security advisories, and contribution workflows for KryptoOS are hosted on github.com/empoorio/kryptoos. If you interact with the repository, GitHub processes your account data, IP address, and contribution metadata under GitHub's Privacy Statement.
KryptoOS issue templates may ask you to describe bugs or integration problems. Do not include private keys, seed phrases, or raw credential payloads in public GitHub issues.
10.3 Website Hosting and CDN
The public KryptoOS site is deployed as a static build (VitePress) served via Firebase Hosting and related Google Cloud infrastructure (kryptoos.web.app and configured custom domains). Request logs, TLS termination, and CDN caching may be processed by Google Cloud and DNS providers under their respective terms.
We do not operate a logged-in user portal on the marketing site; hosting logs are primarily technical (IP, user agent, requested path, timestamp).
10.4 Package Registries and CI
Published KryptoOS SDK packages may be distributed through public registries (npm, PyPI, pub.dev, crates.io, and similar). Download counts, mirror telemetry, and CI build logs on those platforms are governed by each registry's policies — not by this Privacy Policy.
10.5 What Is Not Covered Here
Third-party wallets, issuer platforms, verifier services, RPC providers, explorers, and enterprise deployments that implement KryptoOS standards are independent operators. They may use entirely different analytics, hosting, and logging stacks. Users must review those operators' privacy policies separately.
11. International Data Transfers
11.1 Website and Project Operations
The KryptoOS documentation website and related project infrastructure may process personal data (such as IP addresses in server logs or contact form correspondence) in the United States, the European Union, or other regions depending on hosting configuration and contributor location.
When personal data is transferred from the EEA, UK, or Switzerland to countries without an adequacy decision, we rely on appropriate safeguards where applicable, including:
- Standard Contractual Clauses (SCCs) adopted by the European Commission
- Vendor data processing agreements offered by hosting and analytics providers
- Technical measures such as TLS in transit and access controls on stored correspondence
11.2 Public Anchoring Layer
Data anchored via KryptoOS on a public blockchain is replicated globally by design. Any participant with access to the network can read on-chain fields described in §4.1 (DIDs, public keys, hashes, status references). This visibility is a property of public ledgers, not a transfer decision made by KryptoOS alone.
11.3 Developer and Self-Hosted Deployments
Organizations that deploy KryptoOS outside official project infrastructure choose their own hosting regions and transfer mechanisms. They are responsible for mapping those choices to GDPR Chapter V requirements and local cross-border rules.
12. Data Retention
KryptoOS retains data only as long as necessary for the purposes described in this policy, unless a longer period is required by law.
12.1 Website and Infrastructure Logs
| Data type | Typical retention | Notes |
|---|---|---|
| HTTP / CDN access logs | 30–90 days | May be extended during active security investigations |
| Error and uptime monitoring | Per vendor defaults | Used to restore service availability |
| DDoS and abuse mitigation records | Incident-dependent | Retained until resolution and post-mortem completion |
12.2 Analytics
Google Analytics retention follows the configuration of property G-KN9GHR5EKT and Google Analytics data retention settings. Aggregated reports may persist in analytics dashboards after raw event logs expire.
12.3 Support and Privacy Correspondence
Messages submitted through /contact, GitHub issues marked as privacy-related, or email threads routed to the KryptoOS team are typically retained for up to 3 years after the inquiry is resolved, unless:
- A shorter period is requested and no legal hold applies
- A longer period is required for litigation, regulatory inquiry, or demonstrated ongoing security relevance
12.4 Open-Source Contribution History
Commits, pull requests, and issue comments on the public GitHub repository constitute a permanent open-source record unless redacted under GitHub's policies. Git history cannot be fully erased without rewriting repository history — contributors should avoid committing secrets or personal data.
12.5 Protocol and On-Chain Data
| Data type | Retention |
|---|---|
| On-chain DID anchors | Indefinite — public blockchain immutability |
| Credential anchor hashes | Indefinite — unless network governance migrates state |
| Status list entries | Until updated or superseded by issuer |
| Holder credentials (off-chain) | Controlled by holder and issuer — not by KryptoOS centrally |
When off-chain retention periods managed by KryptoOS expire, we delete or anonymize data where technically feasible.
13. Security Measures
KryptoOS applies administrative, technical, and organizational controls to protect the website, repositories, and reference protocol implementation.
13.1 Cryptographic Controls
- Ed25519 is the default general-purpose signature algorithm in KryptoOS documentation and SDK examples
- Additional schemes (ECDSA secp256k1, BLS12-381, BBS+) are supported for interoperability and selective disclosure use cases — see Cryptography Core
- RFC 8785 canonicalization is used to prevent tampering with nested credential fields
- Presentations should bind to verifier nonce and short expiry to mitigate replay — see integration guides
13.2 Fail-Closed Verification
The reference KryptoOS verification path is fail-closed:
- Resolve issuer DID and obtain verification keys
- Validate cryptographic proofs and signatures
- Check credential expiry and presentation freshness
- Consult Status List 2021 for revocation
If any step fails, verification returns negative. There is no default bypass for convenience or degraded mode in production configurations documented by KryptoOS.
13.3 Key Management Architecture
In the reference holder architecture:
- Private keys are generated and stored on the holder device or approved secure storage (hardware wallet, HSM, secure enclave)
- KryptoOS does not operate a centralized custodial key vault for end users
- Issuers and operators are documented to use HSM or enterprise key storage for production signing keys
Users are responsible for seed phrase confidentiality, device passcodes, and backup encryption.
13.4 Website and Repository Security
- TLS (HTTPS) for website transport
- Access controls on hosting accounts and GitHub organization permissions
- Dependency and supply-chain review via public source and tagged releases
- Security issues can be reported via GitHub — use responsible disclosure practices; do not post exploit details publicly before coordination
13.5 Limitations
No security program eliminates all risk. KryptoOS cannot recover lost private keys, reverse on-chain transactions, or guarantee the security practices of third-party deployments. Operators should run threat modeling, penetration testing, and key rotation appropriate to their regulatory environment.
14. Children's Privacy
14.1 Age Restriction
KryptoOS documentation, website, and open-source project materials are not directed at children under 16 (or the age of digital consent in your jurisdiction, if higher).
We do not knowingly collect personal information from children through official KryptoOS channels such as the contact form or public GitHub issues.
14.2 Parental and Issuer Responsibility
Age-sensitive credential programs (student IDs, minor KYC, parental consent flows) are implemented by issuers and application operators, not by the core KryptoOS website. Those operators must obtain verifiable parental consent where required by COPPA, GDPR Article 8, or equivalent local law.
14.3 Reporting
If you believe a child has submitted personal information to KryptoOS through /contact or a public repository issue, contact us with "Child Privacy — KryptoOS" and we will take steps to delete off-chain data we control. For data held by third-party issuers or apps, contact those operators directly.
15. Data Breach Notification
15.1 Scope
This section applies to personal data breaches affecting systems operated by the KryptoOS project — including the website, official GitHub organization assets, and hosting accounts used to publish documentation.
It does not apply to breaches at third-party issuers, verifiers, wallet vendors, or self-hosted KryptoOS deployments.
15.2 Response Procedure
If we determine that a breach of personal data has occurred, we will:
- Contain — isolate affected systems and revoke compromised credentials
- Assess — identify categories of data, approximate number of individuals, and likely consequences
- Notify authorities — report to the relevant supervisory authority within 72 hours of awareness where GDPR Article 33 applies
- Notify individuals — communicate without undue delay when the breach is likely to result in a high risk to rights and freedoms (GDPR Article 34)
- Document — record facts, effects, and remedial actions taken
15.3 On-Chain Incidents
Compromise of on-chain public keys or fraudulent issuer activity is a protocol and key-management incident, not necessarily a traditional database breach. Affected holders should rotate keys, revoke credentials, and contact their issuers. Public ledger fields described in §4.1 may already be world-readable by design.
15.4 User Reporting
If you believe you have discovered a vulnerability in KryptoOS software or infrastructure, report it through GitHub security advisories or /contact with "Security Report — KryptoOS". Do not include live exploit payloads or third-party personal data in public tickets.
16. Automated Decision-Making
16.1 Core Protocol Verification
KryptoOS core credential verification is a deterministic cryptographic process. The reference verifier evaluates:
- Signature validity
- Schema and proof conformance
- Temporal validity (not expired)
- Revocation status
- Presentation binding (nonce / audience where configured)
The output is a boolean verification result (verified: true or verified: false). There is no opaque machine-learning score or probabilistic approval layer in the reference KryptoOS verifier.
16.2 Third-Party Decision Systems
Applications built on KryptoOS may layer additional rules — for example, risk scoring, fraud detection, credit decisions, or access control policies — on top of cryptographic verification. Those layers:
- Are designed and operated by the application owner
- May constitute automated decision-making under GDPR Article 22 depending on context
- Are not controlled by the KryptoOS open-source project
If you are subject to a solely automated decision with legal or similarly significant effects, contact the application operator that made the decision, not the KryptoOS documentation team.
16.3 Human Review
KryptoOS privacy and support correspondence is reviewed by humans. We do not use automated systems to deny GDPR or CCPA requests without human oversight.
17. Cookies and Similar Technologies
The KryptoOS website uses a small set of cookies and browser storage technologies.
17.1 Strictly Necessary / Functional Storage
| Technology | Type | Purpose | Duration |
|---|---|---|---|
vitepress-theme-appearance | localStorage | Remembers dark/light documentation theme | Until cleared by user |
| VitePress client state | session / local | Navigation and UI state for docs | Session or until cleared |
These are required for basic site usability. Blocking them may reset theme preferences on each visit.
17.2 Analytics Cookies (Production Only)
Google Analytics may set cookies such as _ga and related identifiers on the production KryptoOS site to distinguish sessions and measure page views. Analytics is disabled on localhost.
You can:
- Use browser cookie controls to block analytics cookies
- Install the Google Analytics opt-out browser add-on
- Enable "Do Not Track" or equivalent browser signals (support varies by browser)
See Google's cookie policy for details on Google-specific identifiers.
17.3 CDN and Hosting Cookies
Firebase Hosting, Google Cloud CDN, or DNS providers may set short-lived technical cookies for load balancing, bot mitigation, or TLS session resumption. These are infrastructure-level and not used by KryptoOS to profile individual users.
17.4 No Advertising Cookies
The KryptoOS website does not use advertising pixels, retargeting networks, or cross-site tracking for marketing purposes.
18. Self-Hosted and Third-Party Deployments
18.1 Independent Data Controllers
Organizations that download, fork, or self-host KryptoOS software become independent data controllers (or processors, depending on role) for personal data processed in their environment. This includes:
- Enterprise issuers running KryptoOS issuer services
- Verifiers operating OIDC4VP or direct presentation endpoints
- Managed service providers hosting KryptoOS nodes for customers
- Integrators embedding KryptoOS SDKs in consumer applications
Each operator must publish its own privacy policy, lawful basis, retention schedule, and breach notification procedures.
18.2 Configuration Responsibilities
Self-hosted operators should explicitly configure:
- Logging — RPC, API, and application logs may capture IP addresses or presentation metadata if misconfigured
- Analytics — disable third-party analytics or replace with privacy-preserving alternatives
- Key storage — use HSM / secure enclave patterns documented in Privacy & Security
- Data minimization — request only required claims in presentation definitions
- Retention and deletion — implement issuer-side erasure workflows for off-chain PII
18.3 Open-Source License
KryptoOS is distributed under the Apache License 2.0. The license grants software rights; it does not:
- Transfer KryptoOS data protection obligations to the project maintainers for third-party deployments
- Warrant fitness for a regulated processing activity
- Require the KryptoOS project to operate or monitor private installations
See Terms of Service for usage conditions.
18.4 Forks and Modified Distributions
Modified forks may change privacy-relevant behavior (logging, telemetry, custodial key storage). Users should verify the privacy policy of the specific distribution they install, not assume it matches this document.
19. Changes to This Policy
19.1 Updates
We may update this Privacy Policy when KryptoOS software, documentation, hosting practices, or applicable law changes. Material updates are reflected in the Last Updated date at the top of this page.
19.2 Notice
- Minor clarifications (typo fixes, cross-link updates, non-substantive wording) may be published without separate announcement
- Material changes (new data categories collected by KryptoOS, new third-party processors, changed retention periods) will be announced via the Updates page and KryptoOS GitHub release notes where practical
Continued use of the KryptoOS website or official project materials after the effective date of an update constitutes notice of the revised policy.
19.3 Version History
Previous versions of this document are available in the public Git history:
github.com/empoorio/kryptoos/commits/main/website/src/docs/resources/privacy.md
You may request a plain-language summary of what changed in a material update by contacting us with "Policy Change Summary — KryptoOS".
20. Contact
20.1 Privacy Requests
For privacy inquiries relating only to KryptoOS (website, documentation, official repositories):
| Channel | Use for |
|---|---|
| /contact | General privacy requests, CCPA/GDPR correspondence |
| GitHub Issues | Protocol questions — no secrets or PII in public issues |
| GitHub Security | Vulnerability reports |
| Discord | Community questions — do not post credentials or keys |
| /docs/contribute | Documentation corrections |
Include "Privacy Request — KryptoOS" in your subject or first message so the inquiry is routed correctly.
20.2 What We Cannot Resolve via KryptoOS Channels
The KryptoOS team cannot:
- Recover lost private keys or seed phrases
- Delete immutable on-chain records
- Access issuer databases or third-party wallet backups
- Override verification decisions made by independent application operators
For credential-specific requests, contact your issuer or application provider directly.
20.3 EU Supervisory Authority
If you are in the EEA and believe your data protection rights have been violated, you may lodge a complaint with your local supervisory authority. The European Data Protection Board maintains a list of EU member authority contact points.
21. Summary
21.1 Quick Reference
| Question | Answer |
|---|---|
| What does this policy cover? | KryptoOS only — website, docs, SDKs, and official open-source project channels. |
| Does KryptoOS store PII on-chain? | No. Only DIDs, public keys, hashes, and status references. |
| Who controls my credentials? | You do — on your device or infrastructure you authorize. |
| Can KryptoOS recover my private keys? | No. |
| How do I delete my identity footprint? | Delete local wallet, revoke keys, request issuer deletion of off-chain copies. |
| What about third-party wallets or apps? | They have their own privacy policies and controllers. |
| Does the website track me? | Production site uses Google Analytics; not loaded on localhost. |
| Is verification automated? | Cryptographic verification is deterministic; apps may add separate decision layers. |
| Technical implementation guide? | Privacy & Security |
| Usage terms? | Terms of Service |
21.2 Privacy Mechanisms at a Glance
| Mechanism | Privacy benefit |
|---|---|
| SD-JWT / BBS+ selective disclosure | Reveal only requested claims |
| Zero-knowledge proofs | Prove statements without exposing source values |
| Status List 2021 | Check revocation without issuer callback per verification |
| Pairwise DIDs | Reduce cross-service correlation |
| Fail-closed verification | No partial trust on invalid proofs |
| Off-chain PII architecture | Personal data stays off the public ledger |
21.3 Document Status
This Privacy Policy is a transparency document for the KryptoOS project. It does not constitute legal advice. Organizations deploying KryptoOS in regulated industries (financial services, healthcare, government identity) should perform their own DPIA / PIA and consult qualified counsel.
This document describes KryptoOS data practices only. It does not constitute legal advice. Regulated deployments should consult qualified counsel.