idOS Security & Privacy: Much More Than You Wanted To Know
Download FileidOS Security & Privacy: Much More Than You Wanted To Know
Imagine a future where proving your identity online doesn’t require handing over copies of your passport or trusting a centralized exchange with your personal documents. In traditional finance, massive data breaches and identity thefts have shown how fragile centralized identity systems can be. Now, web3 promises self-sovereign identity – you control your data – but with that power comes new security challenges. How do we keep user data private and secure while available online? How can a system be decentralized and user-owned, yet protect against unauthorized access and leaks? These questions are at the heart of our mission.
In this deep dive, we’ll explore idOS’s security philosophy and the careful trade-offs the team made to balance decentralization with privacy. We’ll walk through why decentralized identity needs a new approach, the guiding design principles behind idOS, an overview of our security core, some tough decisions and compromises made along the way, and what’s next on the horizon.
Background & Stakes
Digital identity is high-stakes territory. In web2, identity data lives in siloed databases held by banks, governments, and big tech – prime targets for hackers. One breach can expose millions of personal records. Users have little control: we repeatedly share the same sensitive documents across services, hoping each custodian keeps them safe. Decentralized identity flips this model by letting users own and control their personal data, but it also raises the bar for security. The challenge is clear: build an identity system that’s user-centric and trust-minimized without creating new vulnerabilities.
Getting decentralized identity right means protecting user privacy, preventing unauthorized access, and meeting compliance standards, all while delivering a smooth user experience — otherwise people wouldn’t want to use the system at all.
We see data is our blast radius. That’s why we must live and breathe security — continuous, testable, and publicly accountable security — because one leak can end us faster than any competitor ever could. Our entire value rests on being a trustworthy steward of identity data. If that trust cracks, everything else falls.
We’re not securing an abstract ledger or a cryptographic primitive; we’re securing the raw identity data of people and institutions.
That isn’t theatrics. We’ve lived through scars from industry failures — and our own. The Fractal hack taught us what happens when the wall breaks, how hard it is to regain confidence no matter how small the number of users impacted, no matter how well prepared we were. Data can not be unleaked, it can’t be reimbursed. We’ve watched talented teams undone by a single misconfigured bucket, a one-off token leak, a “temporary” debug path that never got removed. Those stories rewire your instincts. They teach you to design for failure. “Unlikely” is “inevitable given enough time.”
Privacy, for us, isn’t a value statement, it’s a product constraint. We build as if user data were radioactive: handle only what you must, for as short a time as possible, with tooling that makes mishandling hard and auditing easy.
Most importantly, today every team is alone in this. Each onboarding funnel, each centralized database needs to be designed, built and maintained with security in mind. If Coinbase or even 16bn USD heavy identity giant Okta can be hacked, then so can everyone going alone. We are building idOS as a common good where individual contributions make it better for everyone. We need to all rally around a stack, any stack – to even start being able to deal with threats like AI-infused hacks, identity theft and privacy nightmares. Alone, we’ll be overrun.
Security and privacy aren’t static: threats evolve, practices mature, and blind spots emerge. What we’re publishing here is the start of an ongoing public dialogue about our posture, one that will feed back into the system and make it stronger over time. An ongoing public conversation about how we keep raising the bar, operationally, cryptographically, and socially. Not in theory, but in the real world, where adoption, integration, and attack vectors actually live.
We're pragmatists. Perfection without adoption helps no one. We’d rather build a better system that is battle-tested in the open and incrementally hardened than one that hides behind idealism but never gains traction. Perfection doesn’t scale; discipline does. Security that lives, breathes, and adapts is what defines us.
Design Principles
When you design a system, you're inevitably making decisions on behalf of those who will use the system. When what you build touches data or money it becomes consequential.
As an ecosystem effort, it's on us to be both mindful, transparent and inclusive about the trade-offs we choose. This should extend beyond the classic security/convenience spectrum of a given feature: an open debate regarding roadmap priorities and resource availability is increasingly necessary to cut through the bullshit.
Security isn't a feature you set and forget. Security is culture. It's the proud stewardship of continuous introspection, review and monitoring processes. It starts with honest awareness and deep understanding of how and where what you build stands: stronger, at par, or worse than other solutions. And it must become a continuous dialogue. The teams we admire model this. Signal open-sources its protocol, ships reproducible builds, and invites adversarial review. Cloudflare writes public postmortems that name root causes and remediation. Let’s Encrypt normalized transparency logs so mistakes can be audited in daylight. We want that level of candor to be our default: publish assumptions, document failure modes, invite critique, and show our work.
We’ll keep shipping with this posture: call the tradeoffs, show the receipts, and keep the conversation public. The goal isn’t to win arguments, it’s to build a system that stands up to them.
This is especially important to us because idOS is – as we progressively decentralize – a permissioned chain. We are initially asking for a bit more trust than a public blockchain would require. And so we surface tradeoffs, name risks, and publish constraints. Security is a conversation: continuous, inspectable, and accountable. We own where we’re strong and where we’re merely average, because pretending otherwise is how systems fail.
Self-sovereignty
Users own their data. idOS acts as an infrastructure for storage and sharing, but the user remains in control at all times. This means every piece of personal data in idOS is encrypted with keys that only the user has, meaning that not even node operators or the network itself can read your information.
That’s the magic of per-user keys and end-to-end encryption. All personal data stored through idOS is protected using strong cryptography. By default, data added to idOS is encrypted using the user’s public key (asymmetric encryption), ensuring that only the corresponding private key – held by the user – can decrypt it. The encryption scheme selected (NaCl/libsodium’s x25519-xsalsa20-poly1305) follows modern best practices for confidentiality and integrity. In simpler terms, even if someone intercepts the stored data or if a storage node is compromised, all they see is gibberish – encryption is the shield that keeps user data secret.
In summary, idOS reverses the power dynamic. Rather than companies siloing your identity data and granting you access to your own information, idOS lets you silo your data and grant companies access to only what’s needed.
Data availability
Regulated entities must be able to present KYC/AML records — the full dataset — to competent authorities, —typically for at least five years after a user terminated an account. That requirement doesn’t vanish if we minimize data, it just pushes integrators to keep their online copy somewhere. Instead of creating several slightly different, partially secured copies, we keep one canonical dataset online in idOS. This reduces data proliferation, concentrates security investment where it matters, and still meets record-keeping and disclosure duties.
And no, this doesn’t make idOS “a single honeypot”. It’s a consolidated surface, not a flat one: per-user encryption and access, revocable access grants, and immutable audit trails. Systemic risk drops when you eliminate hundreds of weak copies.
This is also the reason we haven’t yet invested much in selective disclosure, zero-knowledge proofs, or other privacy maximization technologies. Their use is extremely limited for our first use case. We’ve spent that energy instead in ensuring we secure what we can’t make disappear.
A general remark regarding KYC/AML: while we agree with parts of the spirit of prevailing regulation, there is much about its implementation which we believe ranges from disagreeable to preposterous. That said, idOS was not created as a lobbying organization designed to push for regulatory change. We are not politicians, but builders — including our legal team — and what drives us is the opportunity to build a better system despite existing regulatory constraints. Our mission is to enable self-custodial identity for the new financial rails taking over the world.
We don’t ship for just one tribe
Systems that appease a faction rarely cross the chasm. Systems that many can live with — even if nobody gets everything they want — get used, get trusted, and endure. And so, we’re not optimizing for a single crowd.
Users, developers, issuers, enterprises, and regulators all sit at the table — with different needs and different fears. Our bar is simple: the system must be useful, legal, and adopted. Hitting that bar means trade-offs. If every group has one thing to complain about but still chooses to use it, that’s product-market-policy fit. We’re not here to impress a faction; we’re here to build infrastructure that survives contact with reality. A decade of decentralized identity has yielded no real adoption. All we do at idOS is about making sure decentralized identity is widely used in production.
Some will say it's too open, too risky — others that it's too gated and not web3 enough. Some will complain the system is too opinionated, and others that we leave too many decisions up to them. This is a useful and healthy tension that we'll use to inform our development. When we hear equal complaints from each side of these and other binaries, we know we're probably balancing correctly.
Adoption, security and convenience
A related point is the classic security vs convenience trade-off. The product needs adoption, so it must limit friction. If the product doesn't get adopted, we don't get to make privacy and security better for everyone. But some friction will always be needed to protect people from attackers and themselves.
Good systems pick when to add friction (risk-based), where to add it (only on sensitive flows), and how to make it feel natural (progressive disclosure, good defaults).
A timeless example is folks being forced to use passwords, and taking convenience into their own hands by writing them on post-it notes attached to their screen. Another one is too many confirmation steps leading to people getting used to mindlessly clicking through those steps once they’ve seen them once or twice.
This is the reason that today, our default mechanism for this uses familiar wallet signatures to drive an MPC process. Those used to securely managing passwords might pick the password route, but most folks are likely better off signing a message with their wallet.
Where idOS is Stronger than Centralized Systems
Building idOS was informed by almost a decade of working with web3 users and dapps, and actually helped dapps in the space meet their compliance requirements when onboarding and seving users. We picked and chose from today's state of the art to create a data storage layer that strikes a balance between the needs and fears of these different stakeholders.
With idOS, users are truly sovereign over their data, and can freely choose who they want to share data with and for how long. Dapps can easily ask users to share their data and keep it stored in idOS, and no longer need to build their own secure and compliant data storage. Whenever a regulator approaches an app, their needs can be easily met by exercising an access grant. And all of this works without users needing to download and install any new apps.
“Can’t be evil”
Never mind "don’t be evil"; we want to build a company that actually can’t be evil. — Austin Hill
Centralized systems concentrate risk; one misstep becomes everyone’s worst day. We design the opposite: compromise an operator and you get ciphertext and scraps — not a mother lode.
We couldn’t be a data broker even if we wanted to. “We can’t sell your data” is more than a slogan, it’s architecture and design. We don’t store sensitive data in plaintext. Access to data is explicitly granted and scoped. We can’t do a future pivot where we quietly monetize user data and insights, because our plumbing makes that impossible.
Data security and self-sovereignty
Permanent data availability discourages data copying, meaning there's dramatically less places your data could leak from. When the only way to “be sure” is to download a CSV, people download CSVs — then those copies leak from laptops, email threads, and long-forgotten S3 buckets. By making authorized, auditable access reliably available on demand, we remove the perceived need for ad-hoc hoarding. Fewer stray copies means fewer leak paths.
Access grants ensure users are sovereign over their data, while per-user data encryption makes leaks effectively worthless and offers users an additional layer of protection should user access keys leak.
Open source posture
We are too small to build and maintain the best privacy-preserving, compliant identity system: Good that we have a little help from our friends. Being an open source platform is a powerful tool to allow us to still compete by including all tribes around a common public good. Concretely that means specifying clear interfaces, publishing high-quality reference code and documentation, and letting the best ideas — ours or other's — plug in and win on merit.
Today, we already lean on specialists for critical primitives: Kwil for data storage, Partisia for MPC, FaceTec for liveness. That’s intentional. Instead of reinventing every wheel, we choose to integrate modules built by those whose entire mission is to make them world-class. The result is faster iteration, better security, and the progressive development of a community of contributors.
We’re wallet agnostic by design. We don’t "support Ready or MetaMask": we "support wallets". Today, if a wallet speaks our interface, it will work. Tomorrow, we want to extend this philosophy beyond wallets. We want the same neutrality and composability to apply to several components across all layers of idOS.
With that posture, idOS can also become a distribution channel. Neobanks and dapps should be able to pick their preferred tools from a curated menu instead of sourcing and stitching everything themselves. That creates real incentives for vendors to compete on security, privacy, and UX, and it raises the floor for everyone as better combinations emerge.
Building in the open makes this sustainable. Public, well-documented repos and a responsive core team invite contributions. We’ll add fuel, such grants for missing modules, bounties for hardening and audits, and partnerships with vendors. And with this approach we will make the identity ecosystem safer, more private, and more adoptable over time.
Core Technical Guarantees - Security in depth
Layers matter. Take the Signal messaging app as an example: TLS on the wire, encrypted blobs at rest, and end-to-end encryption for good measure. Even if a server is breached, there’s nothing readable to attackers. Similarly, idOS stacks controls so a single miss doesn’t cascade into a catastrophic failure.
Better security emerges from composing different layers, rather than pointlessly obsessing over making any single one ostensibly bullet-proof. Layered security is better than the sum of its parts. Defense in depth works because different controls fail in different ways and, when one breaks, the others ensure incidents stay small and boring. In other words:
Data encryption and storage
Per-user encryption
We built idOS to make it very hard for anyone (including us) to intentionally or unintentionally leak data. Much like Signal couldn't leak your messages if it wanted to, idOS can't leak your data. That is because each user holds their own encryption keys. This makes sure idOS can't be evil.
There are a number of other security features we'll get into, but this is one of the most powerful, protecting not only the data of our users but also the attack vector on our core developers by taking away the incentive. Contrast this to how centralized web2 databases are secured traditionally. A straightforward production deployment of following established best practices will look something like this.
Admins such as core devs have unrestricted access to web servers, and thus have transitive access to all of the databases as well. In the natural course of operations, users will send plaintext data (encrypted only in transit) to the application server, which then stores it in the database for future retrieval.
Such traditional systems present multiple opportunities for compromising attacks that can place the entirety of their data at risk. Any software or human vulnerability enabling an attacker to access the database directly (or via the application server) is game over all database storage.
This works differently in idOS. Instead of plaintext data, sensitive data such as credentials are encrypted on the user's device before being sent. And so, once data leaves the user's device, it will only ever be readable by the owner of the decryption key. This means that even if all security layers are pierced and an attacker finds their way to the database, they'll be holding on to a lot of nothing.
This blinding of the entire idOS stack is an extremely efficient way to keep data secure because it makes data exfiltration worthless: neither external attackers nor rogue/bribed/coerced core devs or node operators are able to make sense of any data they might get their hands on.
This user-level encryption has an additional benefit: it acts as a powerful extra factor for data access. That's because, even if an attacker gets a hold of Alice's idOS access keys and are thus able to retrieve data on her behalf, said data would be encrypted and hence worthless — the attacker would need not only her access keys, but her decryption key as well.
NaCl’s crypto_box aka x25519-xsalsa20-poly1305
Technically, idOS uses authenticated asymmetric encryption. Encryption being asymmetric means that Alice can encrypt a message for Bob (and vice versa) without them having to previously agree on a shared, single encryption key. It being authenticated guarantees message authenticity and integrity, each property respectively assuring Bob that the message was indeed encrypted by Alice and wasn’t tampered with.
To do this, we employ NaCl’s crypto_box construction, often summarized as x25519-xsalsa20-poly1305: a modern and proven ECIES Hybrid Encryption Scheme. The idOS Enclave includes https://github.com/dchest/tweetnacl-js, a famous and audited implementation of this scheme. Let’s break it down and see what it means.
Say Alice wants to encrypt a message for Bob. To do this, she needs 3 things: the message, her private key, and Bob’s public key.
- Key agreement First, Alice uses these private and public keys to compute a unique shared secret. She does this using the x25519 ECDH function, a key agreement algorithm based on the Curve25519 elliptic curve.
- Symmetric encryption Alice then generates a nonce to be used with this shared secret to encrypt the message with the xsalsa20 symmetric stream cipher. This is an algorithm used to symmetrically encrypt data of arbitrary size.
- Sender authentication Finally, Alice calculates a message authentication code (a MAC) using the Poly1305 algorithm. This MAC is sent along with the encrypted message and can be used to verify that it wasn’t tampered with.
- Bob’s turn To decrypt and authenticate the resulting ciphertext, Bob does a mirror version of this process to obtain the original message.
There is a trade-off inherent to this encryption scheme being authenticated, whereby an encrypted message is decryptable not only by its receiver (Bob) but also by its sender (Alice). We’ve since decided the advantage of sender authentication wasn’t worth the loss in forward secrecy and switched to using ephemeral keys (as in crypto_box_seal). Given the provenance guarantees provided by W3C Verifiable Credentials and the Access Grants related to a re-encryption flow, we chose to reduce the blast radius of a key leak — especially that of an Issuer.
Data access control
Reading or writing data on idOS is done by making signed requests to idOS nodes. When an idOS node receives a request, it will first make sure authentication and authorization succeed. If both do, it will comply with the request.
Authentication: who signed this request?
Most requests to idOS nodes must include a message, a public key, and a signature (a public key is required because not all signatures allow for the public key to be extracted). To authenticate the signer of the request, an idOS node will use magic maths to validate the signature in the request.
The process depends on the type of signature, but in general involves confirming that this specific signature could only have been produced by whatever private key corresponds to this specific public key when signing this specific message. Authentication is considered successful if this is true.
Once the authentication stage is cleared, the node can move on to authorization.
Authorization: what can this signer do?
A successful authentication means that the idOS node can be certain that it was indeed the owner of this public key that made this request, and it moves on to the authorization phase.
To do this, the node first checks its database for records belonging to the owner of this public key. One or more records must be found for authorization to succeed.
Upon successful authorization, the node will execute the request.
Signers and signature schemes
Naturally, crypto wallets are ubiquitous among web3 users. While there’s significant diversity in wallet software, virtually all share the ability to store private keys and use them to sign messages. That follows from the basic fact that blockchain transactions are essentially messages signed by an address owner, that a miner/validator then includes in a block.
When a wallet asks you to confirm a transaction, it shows a very different interface than for asking you to sign a message. This is not only to help informing the user about gas and whether the transaction will succeed or fail. It’s also because wallets tend to carefully make sure that they never ask the user to sign a message when that message could be used to make a transaction.
For example, Ethereum wallets don’t simply sign the message you ask to be signed, they use the eth_sign method (see EVM wallets). In short, given the message please sign, the wallet takes its character count (11) and sign an EIP-191-standardized \\x19Ethereum Signed Message:\\n11please sign payload.
We currently support the following signers:
- EVM wallets producing EIP-191 secp256k1 signatures (aka personal_sign);
- NEAR wallets producing NEP-413 ed25519 signatures (aka signMessage);
- arbitrary signers producing vanilla ed25519 signatures.
Access grants
Data sharing flows in idOS happen are powered by access grants. They’re an authorization primitive that enables its receiver (the grantee: a dapp) to retrieve a specific data record owned by its sender (the owner) in idOS. Since they must be signed by the data owner to be recognized by idOS, access grants are a form of verifiable consent.
This authorization can be revoked: at any time, users retain full control over their data and can revoke access, immediately disabling the recipient’s ability to retrieve or decrypt the information. If a data recipient no longer requires access, or if a user changes their mind, revocation ensures that data permissions are always dynamic and adjustable.
For cases where regulatory compliance requires specific retention periods, access grants can be time-locked, ensuring that data remains accessible to the dapp for a predefined duration before revocation is complete. For example, a financial institution may require a five-year data retention period due to compliance regulations. In such cases, revocation will only be possible once the time lock expires, ensuring compliance with data governance policies.
Access grants make it easy to securely share data. The original data to be shared is re-encrypted to the grantee’s public key, and access authorization remains verifiable and sovereign.
Enclave sandboxing
The idOS Enclave is a browser wallet for encryption: a secure browser-based environment for handling sensitive operations such as password input, key derivation, encryption, decryption, and looking through credentials' encrypted content.
Just like e.g. MetaMask does regarding signatures, the Enclave ensures the user’s private key isn’t accessible by dapps. Whenever data needs to be decrypted, we ask the user to “unlock” the Enclave. As such, the Enclave operates in isolation from the host application, ensuring that plaintext data remains inaccessible to unauthorized parties. This component is critical for maintaining the end-to-end encryption guarantees of the idOS system.
Some practical examples of how we think
Security is a culture, and owning our edges is part of that culture. While we're proud of what we've built so far, we feel it's important — not just for transparency and education, but as a request for comments — to emphasize where idOS remains at par with existing alternatives, and call attention to conscious trade-offs we made in our design choices.
Re-encryption guarantees
Users re-encrypt their data in the context of granting access to a new data consumer. This process is unverified by idOS: consumers requiring re-encryption guarantees (i.e. ensuring the user didn’t modify the payload in between decryption and re-encryption) must currently retrieve, decrypt and verify the re-encrypted credential.
This does not have an easy solution, because no secure cryptosystem can offer permissionless re-encryption functions, whereby a third party (such as the consumer, or idOS) can re-encrypt a piece of ciphertext it can’t decrypt in the first place.
In other words, given plaintext S and ciphertext E1 resulting from encrypt (S, SK1), a secure cryptosystem can’t logically have the function reEncrypt(E1, PK1, PK2) -> E2. If it did, anyone would be able to create a new keypair (SK2, PK2), use reEncrypt(E1, PK1, PK2) to obtain E2, and decrypt E2 using SK2.
FHE is far from being able to help here realistically, and while we could employ a TEE for this re-encryption, that approach would require a little too much trust for comfort. Verifiable Encryption mechanisms are a promising candidate solution which we’ll be looking into.
No data access throttling / restrictions
This is important to discourage data copying (good luck getting compliance officers to not look at all). If access is smooth and fast, dapps build directly on our pipes instead of snapshotting, and teams don’t hoard CSVs “just in case”. Instead, it nudges them toward fresh reads, revocation-aware flows, and a smaller attack surface. Remember that most headline breaches start with stray dumps and misconfigured buckets, not broken ciphers.
User primacy is also a motivator. If a user grants a dapp access, the system shouldn’t second-guess them. Sovereignty means honoring explicit consent. Your data isn’t safer because it’s slow; it’s safer because it’s scoped, encrypted, and accountable.
On the other hand, dapps with which a lot of data has been shared becomes a high-value exfiltration target
Permissioned chain
Networks like Bitcoin, Ethereum or Polygon are multi-purpose chains built to reliably produce blocks settling balance movements within a permissionless adversarial environment. The idOS network is different: what its blocks settle are data changes. We are starting idOS to be permissioned and operated by a small number of nodes that all stakeholders of the system can vote for.
idOS is decentralized, but not anarchic. Initially it operates as a permissioned network of node operators – partners who run the infrastructure – to ensure a baseline of trust and accountability. Eventually, the community should be able to choose who these partners should be. However, early on everyone can express their confidence and indirectly impact who they believe most trustworthy. Why permissioned? Because we are aiming for a staged approach to observe the system before going the next steps towards decentralization. For now our approach requires operators to be authorized (and known entities) so that if a node misbehaves – say, fails to delete data when instructed or tries to collude – there are legal and economic consequences. It’s our training wheel phase that we are aiming to graduate from rather sooner than later.
All nodes collectively secure the ledger through consensus, meaning no single node can unilaterally alter or tamper with data without detection. This distributed consensus also ensures high availability: user data is replicated across nodes, avoiding any single point of failure or dependency on a single company’s server. In short, no honeypot, no single point of failure, and a clear path to punish or exclude bad actors.
However, as long as most of idOS remains permissioned, it’ll be harder for others to trust it and build an ecosystem around, and for idOS to grow into the sustainable, reliable system we want it to be. To be clear: It’s still nothing like the platform risks incurred in central systems as some of our consortium partners and others wouldn’t risk their reputation and collude to the disadvantage of the users — and their interests are simply too divergent to make such a scenario realistic. We still need to open up as much of idOS as possible without compromising the privacy and self-sovereignty of its users. There are practical reasons for this, such as the fact that an open chain enables permissionless innovation since anyone can deploy contracts.
On the one hand, node operators must meet security and compliance requirements, making it viable for regulated industries. Permissionlessness also reduces attack surface from SDK bugs, curve failures, and post-quantum cryptography. Last but not least, it allows manual intervention during the network’s gestation period; it helps retain human-in-the-loop controls while the system matures.
Trustlessness is an aspirational goal in crypto, training wheels are common practice, and we're no different. Much like your favorite L2, where we extend trust to sequencers whose code we can inspect but not verify, we're not a black box — all our code is open-source and hence readily inspectable. Additionally, our node operators are public, reputable, slashable, and voted on by the idOS community — it's unrealistic to expect a group with such diverse interests to successfully keep a secret regarding the code they're actually executing.
Online data
As we already discussed above how keeping user data online and available discourages copying. Another benefit to idOS data storage (as opposed to e.g. a data wallet) is that users don’t need to download, install, and learn to operate new software.
Purely local wallet-based storage requires users to manually sign and share data every time a third party requests it. This can be cumbersome and lead to poor UX, especially because it makes it impossible for a dapp to interact with an offline user. Because of that, it can't be relied on for compliance use cases and thus has not seen adoption. But even if adopted, these data availability requirements would require data consumers to store all data on their end, entirely defeating their purpose.
With idOS Access Grants, users can predefine access policies for specific entities, reducing friction while maintaining full control over who can access their data. As such, a major advantage of the idOS access management system is that data remains continuously available, even if the original user is offline.
Once an access grant has been issued, the recipient can retrieve the authorized data at any time, provided that the grant remains active. This eliminates reliance on user availability and allows businesses and services to securely access user data without requiring permanent downloads or redundant storage. This persistent availability enables organizations to use idOS as a decentralized, privacy-preserving customer relationship management (CRM) tool for verified users. Businesses and service providers can access user data on demand, maintaining a live and up-to-date identity verification process without storing unnecessary copies of user data, reducing compliance risks.
Data sovereignty without training wheels
We don’t run an app store. Anyone can issue credentials or consume them. That preserves openness and avoids paternalism — but it also raises the odds of malicious or sloppy dapps. We accept the risk and counter with cryptographic consent, transparent provenance, strong revocation, and public accountability — tools over gatekeeping.
Composability trumps curation. As the open web, Let’s Encrypt, OAuth, and DeFi taught us: when anyone can plug in, ecosystems compound fast.
Additionally, the ability for users to inspect, correct, port, and revoke permissions aligns with data privacy laws on access, portability, and dignity.
The trade-off here is that, by making it easy for users to always read their own data without paternalistic blocking, malicious dapps could convince users to exfiltrate plaintext.
Permissionless integration
Anyone can set themselves up as an issuer or data consumer in idOS. No registration is required for either.
Becoming an issuer in idOS is as simple as integrating our Issuer SDK, creating a credential for them, securing a write grant from a user, and using it to write the credential to their idOS profile.
Consuming this credential is similarly straightforward: integrate our Consumer SDK, ask the user for an access grant to the credential you need, and use it to retrieve it from idOS if needed.
The user is at the center of idOS. Since credential issuance and consumption always depends on user consent, we believe it would be unnecessary (and paternalistic) to second-guess the user's intent.
The flipside is that we lose the opportunity to block issuers or consumers who don't have the best interests of the idOS user base or system at heart.
Enclave popup
Whenever the idOS Enclave needs the user to unlock it, it will open a popup window where they can enter their password. While a popup is often perceived as a clunkier experience than, say, a lower-impact modal window, we decided for it due to phishing concerns.
Technically, since the Enclave runs in a secure browser context segregated from the host dapp, users wouldn’t risk leaking their password were they to enter it in an iframe instead. However, modal windows are easier to copy than popups, which makes it easier for malicious dapps to pretend to substitute a password harvester for the legit idOS Enclave.
Since browsers will show the user the domain a popup is running in, users can rest assured that they’re interacting with the real thing rather than a fake.
Quantum safety
Our embraced cryptosystem is, like all production systems are, quantum-vulnerable. Yes, this includes not just Bitcoin and Ethereum, but HTTPS and SSH as well.
Since the idOS Storage Network is encryption-agnostic, it can trivially support any cryptographic protocol — but it doesn’t. Strictly speaking, idOS users can use any encryption scheme, but our SDKs only implement/support x25519.
We want to get way ahead of NIST's ECC deprecations, and follow their Post-Quantum Cryptography Standardization effort towards lattice-based cryptography. We're currently leaning towards a classic McEliece scheme given the relative abundance of supporting libraries. Because of our goal of eventual full decentralization of idOS, we have the ambition to engage with the cryptography community to cooperate on getting to a cyphering scheme that'll let us accept anybody to become a node operator (and, therefore, have a copy of the ciphertext) without putting users at risk.
Biometric signers
Crypto wallets have certainly come a long way, but as a space we're still lagging behind the convenience of centralized UX. This is a problem as it entices the whole space to resort back to central solutions, threatening user security and control. UX isn’t just design: Cross-device interoperability is hard, and so are backup and recovery flows. Since authentication and authorization flows in idOS are signature-based, our system's usability is tightly coupled with wallet usability.
We first experimented with passkeys as a way to make idOS independent from external wallet software, but their limited portability kept sticking out like a sore thumb. This is why we created FaceSign.
FaceSign is a wallet users can't lose. It lets you sign messages using their face no matter where they are or what device they're using, all without needing to download and install any new apps. FaceSign protects users by enforcing liveness detection before creating or using any keys. This means that a video or mask of a face won't do — FaceSign will only work with a real user in front of their device.
Biometric data being extremely sensitive, we had to design this system in a way that folks could rest assured their privacy was being preserved. To do this, we employ a trusted execution environment (TEE). First, your device captures some information about your face.
This information is encrypted and sent directly to a TEE, ensuring that not even idOS has access to it. This TEE then transforms this information into a feature vector, a description of your face usable only for pattern matching, and from which no human-readable representation of your face can be derived.
Aside from offering superior cross-device UX, FaceSign helps ensure that users never lose access to their idOS account — without requiring everyone to employ best backup practices.
An important design decision is that using biometrics is not a requirement to use idOS. We don't enforce uniqueness in the system. Users can nevertheless use biometrics to get issued a credential proving that they're unique in the system, which enables one-person-one-vote and other use cases requiring sybil resistance.
What We Are Tackling Next
Selective disclosure and zero-knowledge proofs
Both these technologies are commonly mentioned in the context of data privacy, and for good reason: they provide assurance without requiring oversharing.
Selective disclosure is a mechanism whereby the holder of a specially-produced credential can reveal a subset of credential attributes, instead of the whole credential, while still being able to prove to a verifier the veracity of the information. For example, if you have a credential containing all your passport data, selective disclosure allows you to reveal you’re a German citizen without having to reveal the whole passport.
Baking selective disclosure into our SDK is a simple way to enable users to share only parts of a credential with a dapp without breaking the dapp’s ability to verify its authenticity and provenance.
However, zero-knowledge proofs offer users more flexibility in this regard, by allowing users to create derivative proofs from their credentials. In the example above, a German citizen could prove they’re not a US citizen using a zk-SNARK, by providing a witness satisfying a circom circuit implementing a proof of non-membership in set.
Similarly, an “age of majority” proof could be generated from a credential containing a date of birth, without revealing said date.
Today, these technologies are of limited use in the context of our clear go-to-market focus around KYC re-usability for OpenFi. That is because in the overwhelming majority of AML compliance scenarios, obliged entities (such as financial services providers) are mandated to guarantee access to the data underlying a KYC verification.
As pragmatists, we thus see little incentive in the short term for idOS to start rolling out solutions for data minimization. This is likely to change in the medium term: at least in Europe, there are already good examples of regulatory openness to zero-knowledge proofs in the context of less involved due diligence processes such as age verification.
Additionally, we do see this class of solutions as inevitable requirements if we want to encourage idOS usage outside of the currently emphasized KYC/AML use case.
Encryption key rotation
Key rotation is the process of creating new encryption keys to replace existing ones. In our context, you can think about this as enabling an idOS user to swap their existing decryption key out for another.
Since encryption is not an authorization layer, one cannot simply tell a piece of ciphertext to enable decryption to another key. If your idOS credentials are all encrypted to a certain key and you want to start using another, the only way you can do that today is by retrieving, decrypting, re-encrypting and replacing every single credential. Not exactly an elegant solution.
This is particularly taxing for large data consumers who are sitting on a large amount of encrypted data. Scenarios like these can be helped using envelope encryption techniques, where the data is encrypted by a random data encryption key (DEK), which is itself then encrypted with a key encryption key (KEK) and stored next to the data ciphertext. Rotation in this scenario involves only re-encrypting the DEK under a new KEK. While significantly more performant, it still involves large numbers of retrieval, re-encryption and replacement.
Proxy re-encryption schemes are a promising research avenue to deliver a better solution here. It allows re-encryption to be performed, without decryption, by an untrusted party. In this scenario, Alice — who owns encrypted data in idOS — would generate a re-encryption token that idOS nodes would use to perform bulk re-encryption of her ciphertexts into her new key (all without seeing plaintext or either private key).
Grantee access key rotation
idOS users can freely add (and remove) wallets/signers to their account. One reason to do this is access redundancy. Having more than one signer associated with your account means you can lose one and still retain access. A second critical reason is information security: if one of your signers leak, you want idOS to stop authorizing requests from that signer.
This second reason is particularly important for data consumers. As discussed elsewhere in this document, data consumers stand to be granted access to large volumes of data, all of which stands to be leaked (albeit in encrypted form) should their access key leak.
Unlike with users, data consumers currently have no way to rotate their access keys. This is a critical feature to implement.
The good news is that, in our context, rotating access keys is a lot easier than rotating encryption keys since it involves no changes to data payloads.
Data sharding
Every idOS node stores a full copy of all idOS data. This helps ensure data availability and keeps the consensus process simple, while making it easy to reason about the system as a whole. It's an effective solution for the place we are now. There are however very good reasons to consider changing this.
One such reason is to reduce storage costs. This can be done (while retaining comparable availability guarantees) through the use of erasure codings. Erasure coding sharding lets you divide your data into overlapping chunks and distribute them among a number of nodes; the number of shards and amount of overlap are parameters that can be adjusted based on the expected availability behaviour of average network nodes.
The main reason idOS cares about sharding is for data security. For this purpose, techniques like Shamir's secret sharing (SSS) are a better fit. While erasure coding more or less literally splits the data into recognizable chunks, SSS makes sure each chunk is meaningless in isolation.
We currently see data sharding as a prerequisite for going from a permissioned network to a public one, as it would ensure that node operators in a post-quantum world don't pose a data security risk.
__
We are so proud of what we’ve built, and so aware that there’s so much else left to do. We think that airing all of this out in the open will help keep us accountable, invite feedback and engender trust.
Please do reach out if you feel we’ve left anything out, disagree with our trade-offs, or need more clarity on any topic. Force us to explain ourselves — if we missed something we’ll get it on our roadmap, and if we didn’t you’ll leave feeling reassured; regardless, in either case we build trust.
idOS Security & Privacy: now you know much more than you probably wanted to, but hopefully you see why it matters. The next time you’re asked to upload your ID or trust a platform with your personal data, remember that a better way is emerging. A better future for personal data is on the horizon, and idOS is helping lead the way.