#

ssi

(14 articles)

Sovereignty Over Decentralization: What AI Agents Really Need

## The Decentralization Myth The blockchain and cryptocurrency communities have long championed decentralization as the ultimate solution to technological centralization. This narrative has extended into artificial intelligence, spawning movements for decentralized AI, decentralized agents, and decentralized machine learning. The implicit promise is seductive: decentralization will cure all problems of control, ownership, and autonomy. But this framing fundamentally misunderstands what users actually need. Decentralization is not an end goal — it’s a potential implementation detail. What truly matters is sovereignty. ## Understanding the Locus of Control Decentralization, at its core, concerns the locus of control. It describes whether authority over a system resides in a single entity or distributes across multiple parties. However, a nominally decentralized system can still concentrate control in problematic ways. Consider Ethereum and similar blockchain networks. While technically decentralized across nodes, decision-making often concentrates within closed groups of core developers, large token holders, or mining consortiums. The infrastructure may be distributed, but meaningful control remains centralized. From a user’s perspective, this achieves little beyond technical redundancy. We must distinguish between three related but distinct concepts: **Distributed systems** solve technical scalability problems. When computation or data exceeds what a single machine can handle, distribution becomes necessary. Most modern users already operate in distributed environments — we own multiple devices and expect seamless access across all of them. However, this doesn’t require decentralization; a traditional client-server architecture with a central machine accessible from multiple endpoints serves this need equally well. **Decentralized systems** eliminate single points of failure and control. No single entity can unilaterally shut down the network or monopolize decision-making. While valuable, decentralization alone doesn’t guarantee user empowerment. **Sovereignty** represents genuine user control. It means you control your compute resources and data. You decide what happens with your information, who accesses it, and how it’s used. You can act independently without intermediaries or gatekeepers speaking on your behalf. ## Sovereignty as the True Goal For the average user, the technical architecture — centralized, decentralized, or distributed — matters little. What matters profoundly is sovereignty: the ability to control their own digital existence. Sovereignty encompasses several concrete capabilities: You control your compute and data. This is non-negotiable. Your agents act on your behalf, executing your intentions rather than serving platform interests. You maintain sovereign rights over your data — you know where it resides, who accesses it, how it’s used, and you can enforce your preferences about all of these dimensions. You have persistent access. Your data remains available to you regardless of corporate decisions, platform policies, or service discontinuations. The infrastructure supporting your sovereignty continues operating even if major players exit the ecosystem. You maintain awareness and oversight. You understand what your agents are doing with your data and resources. You can audit their decisions and, critically, roll back actions when things go wrong. Decentralization might implement these sovereignty guarantees, but it’s not the only path. A centralized cloud service could provide sovereignty if it gives you genuine control, transparency, and portability. Conversely, a decentralized blockchain network might fail to provide sovereignty if it locks you into proprietary interfaces, obscures data usage, or prevents you from switching providers. ## The Power of Protocols Over Platforms The genuine benefit of decentralization lies not in distributed infrastructure but in protocols. Protocol-based ecosystems enable multiple providers to offer interoperable services. When applications separate from data, and standardized protocols govern both layers, users gain the freedom to choose between providers while maintaining continuity. This is where sovereignty transforms from concept to reality. If you dislike one provider’s policies, pricing, or features, you switch to another without losing your data, history, or agent capabilities. Everything continues operating seamlessly because providers implement common protocols rather than proprietary platforms. However, this dream requires several preconditions: Applications must separate from data. Your information must exist independently of any specific application, stored according to open standards that multiple applications can access. We need protocols at both the data and application layers. These protocols must be genuinely open, well-documented, and implementable by any motivated developer or organization. Multiple providers must implement these protocols. A single implementation, even of an open protocol, provides no real choice. Competition between protocol-implementing providers creates the market dynamics that keep services aligned with user interests. ## What Average Users Actually Need Most users don’t care whether a solution is decentralized, uses blockchain, or runs on distributed infrastructure. They shouldn’t need to care about these implementation details. What they should care about — and what technology should guarantee — is sovereignty over their digital lives. Consider data storage. It genuinely doesn’t matter whether your data resides in a commercial cloud service or on bare metal servers in your basement, provided you maintain authentic control. If the cloud service guarantees you access, informs you of any other access, makes data portable, and allows you to audit all usage, it respects your sovereignty regardless of its centralized architecture. The solution “feels local” even when physically remote because control remains with you. Open source matters for sovereignty, but not in the ways often assumed. Average users cannot and should not need to modify source code to achieve sovereignty. Open source provides value through enabling audit — technically sophisticated parties can verify that systems behave as claimed, building trust that protects all users. It also enables alternative implementations, creating the provider diversity that makes protocol-based sovereignty practical. Similarly, self-hosting capability supports sovereignty by ensuring options exist beyond commercial providers. However, requiring self-hosting as the only path to sovereignty fails most users. Not everyone can purchase and maintain expensive infrastructure, especially for compute-intensive AI workloads. Sovereignty must be accessible through managed services that respect user control, not just through technical self-sufficiency. ## Sovereign AI Agents: Beyond Decentralization The conversation about decentralized AI agents misses the point. We don’t need decentralized agents — we need sovereign agents. Sovereign agents operate under your control and oversight. You understand what they’re doing with your data and resources. You set boundaries around their actions, particularly concerning spending your money or sharing your information. You can inspect their reasoning, audit their decisions, and intervene when necessary. This sovereignty becomes critical as agents gain autonomy and capability. An agent that can act on your behalf — scheduling meetings, making purchases, negotiating contracts, sharing information — must ultimately answer to you. You need the ability to review its actions, understand its decision-making, and roll back transactions when something goes wrong. Decentralization might contribute to this sovereignty by preventing any single provider from arbitrarily constraining your agent’s capabilities or accessing your agent’s knowledge. Protocol-based agent ecosystems could enable your agents to interoperate with others while maintaining your control. But the decentralization itself isn’t the goal — it’s one possible mechanism for achieving sovereignty. ## Moving Forward with Sovereignty The path forward centers on sovereignty, not decentralization for its own sake. This means building systems that prioritize user control regardless of architectural choices. Technology should empower users to have their own voice in digital ecosystems. It should ensure control over personal data and compute resources. It should enable agents that genuinely act on user behalf rather than optimizing for platform metrics or corporate objectives. When we build AI systems, we must ask not “Is this decentralized?” but “Does this provide sovereignty?” Does it give users genuine control? Can they understand what their agents are doing? Can they enforce their preferences? Can they switch providers without losing capabilities? These questions lead to better outcomes than blind pursuit of decentralization. They acknowledge that most users care about outcomes — privacy, control, autonomy, reliability — not about technical architecture. They recognize that sovereignty can emerge from various technical approaches, some centralized and some decentralized. The blockchain and crypto communities deserve credit for championing these values, even if they sometimes conflate means and ends. The real contribution isn’t decentralization itself but the insistence that users should control their digital lives rather than serving as products for platforms. As we build the next generation of AI agents, let’s be clear about our goals. We’re building for sovereignty — for users who control their agents, their data, and their digital destinies. Decentralization might help achieve this vision, but it’s a tool, not the destination. Sovereignty is what we’re really after, and it’s sovereignty that will determine whether AI agents empower or subjugate the people they’re meant to serve.

Identity System Architectures

I deeply believe that practically every business runs a few identity systems. Identity is unavoidable. Sometimes you need to be made aware that you manage an identity system. Some examples of identity could be quite uncommon. - Online or offline event tickets - order receipts We should rethink identity as a relation, not personalities or users. Well, today, we will focus on broader categories of identity systems. Such a quick categorisation of identity systems based on **the root of trust** - Administrative - Algorithmic - Autonomic ## Administrative The total and almost exclusive majority of modern identity is Administrative identity. Administrator founds trust basis. An administrator could be a person, organization, or system managed by organizations. In an administrative system, an identifier could be issued or owned by the Administrator or could be owned by another system. Still, it is bonded — assigned by the administrator to the controller (user). So controller-identifier or AI binging is weak and controlled by the administrator. In such systems, keys could be a password or MFA authentification factor. The source of truth is an administrative database that stores an identifier to controller bindings. Quite often, this system is centralized and owned by Organisations. ![](https://miro.medium.com/v2/resize:fit:1244/1*DCfsHUEXu6a7NOn4mDmFww.png) The trust basis — Administrative System ## SSI systems SSI systems introduce a completely different approach as an alternative to Administrative systems. First of all, network effects in such systems play a key role. Every member of a system has equal rights. The controller has full ownership of his identity. Such systems have an interconnected mesh of sovereign administrators. One of the key challenges in such systems is the root of trust. Roots of trust derive a key difference in the next 2 Architectures. The key concept is not decentralization — it is only an implementation detail. Key of SSI identity systems is sovereignty and user control of identity. ## Algorithmic Relay on *Verified Data Registry.* VDR is publicly open for reading and discovery. VDR has an algorithmic and protocol-driven architecture which means it is controlled algorithmically based on open standards and public algorithms. In rare cases, it could be centralized and managed by the organization but still follow open standards. The more preferred way is decentralized distributed consensus-based data storage. It could be public or permission blockchains—some blockchains designed for identity only, like hyper ledger Indy or similar. In Algorithmic systems, keys usually mean asymmetric cryptography key pairs. The controller generates a key pair and registers a public key in a VDR. Everybody can access a VDR and retrieve public keys based on the identifier. In the best-case scenario, an identifier is cryptographically derived from a key pair or the same cryptographic material. The majority of blockchain DID methods are a perfect example of VDR. VDR could store much more than public keys or identifier bindings. VDR is a key enabler in AnonCreds Verifiable credentials that enable ZKP credentials to store VC schemas, blind links, VC metadata, and **public information** about issuers together with a revocation list, etc. In the case of did: corporate web domain, a website could act as a primitive centralized VDR. Any DTL and decentralized file systems like IPFS could be used as VDRs. VDR is a bit more than storage it brings governance and policies that enable trust and regulation in the network ![](https://miro.medium.com/v2/resize:fit:1244/1*RbabbAvUj8b3G07UhA8PLg.png) trust basis on algorithmic identity systems ## Autonomic Similar to Algorithmic in a flow but completely self-administrated and self-certified. Cryptographic material owned by the controller still drives the identifier. All bindings between an identifier, controller, and identifier govern by a protocol and recorded in a controller Key event log. The key difference here — we eliminate a VDR and replace it with co-local architecture owned and run by the controller. As a result, we get a high-scale, resistant, autonomic system that could operate without any third-party services. In this case, the root of trust is self-certified by the controller. It creates a question should we trust and rely on self-certified data? A few tries to create self-certified systems in the past failed to build trust relations. That's why it is critical to creating open to audit end-to-end verifiable systems and protocols that could create a network of trust. Such systems could involve witness networks and network participants' cross-verification of key event logs. ![](https://miro.medium.com/v2/resize:fit:1400/1*rOdEFrJOnISLWkj5gVQVyg.png) autonomic system — trust basis AIDs or autonomous DIDs fail in this bucket well together with the KERI protocol. You can read more about AID in my article. And discover DID:Web as a simplified AID for organizations All key event logs or did document storages for did:peer is some form of co-local storages that still require end-to-end verifiability. You can discover more about micro ledgers The pioneer and most matured solution now for autonomic identity systems infrastructure is KERI It is still a lot of work in adoption of SSI identity systems but i see a stable trand in this space.

Zooko’s Triangle and DIDs

The Zooko’s Triangle is a concept in the realm of naming systems, specifically for decentralized or distributed networks. It was named after Zooko Wilcox-O’Hearn, a computer scientist and cypherpunk known for his work on the Zcash cryptocurrency. The triangle illustrates a trade-off between three desirable properties in a naming system: ![](https://miro.medium.com/v2/resize:fit:1400/1*jPMtyoiTH9wq7TSyB584uQ.png) 1. **Human-meaningful:** Names are easily understood and remembered by humans. 2. **Decentralized**: No central authority controls the allocation or management of names. 3. **Secure**: Names are unique and cannot be easily taken or manipulated by others. Zooko’s Triangle posits that achieving all three properties in a single system is difficult. Traditionally, a system could have only two of the three properties, leading to various combinations of naming systems with their respective advantages and disadvantages. However, recent developments in cryptographic and distributed systems have led to solutions that challenge the traditional constraints of Zooko’s Triangle. One such system is the Decentralized Identifiers (DIDs). ## DIDs Decentralized Identifiers (DIDs) are a new identifier for verifiable, decentralized digital identity. DIDs are designed to be self-sovereign, meaning that individuals or organizations control their identifiers without relying on a central authority. DID systems are built on top of decentralized networks, such as blockchain or distributed ledgers, providing a secure and tamper-proof infrastructure for identity management. DIDs aim to achieve the three properties of Zooko’s Triangle: 1. Human-meaningful: While DIDs may not be human-meaningful due to their cryptographic nature, they can be associated with human-readable names or aliases. 2. Decentralized: DIDs are managed on decentralized networks, removing the need for a central authority. 3. Secure: The decentralized nature of DIDs, combined with cryptographic techniques, ensures that identifiers are unique, secure, and resistant to tampering. In summary, Zooko’s Triangle presents a trade-off between human-meaningful, decentralized, and secure properties in naming systems. Decentralized Identifiers (DIDs) are an example of a system that seeks to overcome the traditional limitations of the triangle by leveraging decentralized networks and cryptographic techniques to provide a more comprehensive solution for digital identity management.

Autonomous DIDs Identifiers for Organisations

# Organizational identifiers Organizational identifiers have different sets of requirements and functions. It is not enough to have per-to-peer private communications. Organizations are more public, so we need publicly resolvable identifiers. DID:key satisfy this condition entirely but fails to fulfill the organization's needs. - Organizations quite often act as issuers of credentials or attestations. For issuance, it is critical to have the possibility to rotate signing keys or even deactivate or delete identifiers if keys or issuer get compromised or to comply with security company policies. - Organizations often require a split between the Controller of the identifier and the Identifier subject or even a transfer of the identifier subject. - Organizations must have complete control of infrastructure and effectively manage resources and costs. The price of a single identifier should be fixed, and the method of creating new identifiers should be scalable. - One of the essential requirements is trust and governance and transparent mechanics of proving and binding an identifier to an organizational entity and creating trust relations. - Access to Identifier management is quite often controlled by a group of users Nonfunctional requirements - portability - interoperability - scalability - Autonomous and control - security In my previous articles, we talk about Autonomous identifiers and how they differ from regular DIDs. To recap ***Autonomous identifiers (AIDs)*** *are* ***DIDs*** *generated algorithmically from a crypto- graphic key pair in such a way that they are self-certifying, i.e. the binding with the public key can be verified without the need to consult any external blockchain or third party.* [*KERI*](https://keri.one/) *is an example of a decentralized identity technology based entirely on AIDs. ©* [*https://trustoverip.org/blog/2023/01/05/the-toip-trust-spanning-protocol/*](https://trustoverip.org/blog/2023/01/05/the-toip-trust-spanning-protocol/) In a previous article, I show how to create and use a did:key as an Autonomous identifier that feet well to private person-to-person secure communication. Architectures and protocols that build on top of AIDs have few critical properties - self-hosting and self-contained - self-certified and Autonomous - portable - interoperable - full control of infrastructure - cost management Nowadays, I discovered a few AIDs methods - **did:key** — self-contained and public - **did:peer** — self-certified, upgradable but private - **KERI based** did — we waiting for did:keri method to be announced soon, but KERI infrastructure could be used to build internals of did:peer or similar methods. - **did:web** — public, self-certified, and self-hosted method, but still, we have active community discussion and critics as far as it fully relays to ownership of domain name that could be stolen or re-assigned. So we have to choose from did:key did:web and I hope in a future from did:keri. To move forward, we need to understand the DID architecture better and how all parts are connected. In many cases of personal or sovereign entities Subject and the Controller are the same, but for Organisations, it could have a crucial difference. ## DID Subject The DID subject is the entity that the DID represents. It can be a person, organization, device, or other identifiable entity. The DID subject is associated with a unique DID that serves as a persistent, resolvable, and cryptographically verifiable identifier. The subject is the primary focus of the identity management process and typically has one or more DIDs associated with it. ## DID Controller The DID controller is the entity (person, organization, or device) that has the authority to manage the DID Document associated with a particular DID. The DID controller can update, revoke, or delegate control of the DID Document, which contains the public keys, service endpoints, and other information required for interacting with the DID subject. In many cases, the DID subject and DID controller can be the same entity, especially for individual users who create and manage their DIDs. However, in some situations, the DID controller may differ from the DID subject, such as when an organization manages the DIDs on behalf of its employees or when an administrator manages a device. In summary, the DID subject is the entity the DID represents, while the DID controller is the entity with authority to manage the associated DID Document. Depending on the specific use case and requirements, these roles can be held by the same or different entities. ## Key Pair It is simple from the first point of view. Key-Pair is an asymmetric public and private key. One of the main DID functions is the distribution of public keys. DIDDoccument could contain multiple public keys with authorization rules and key roles. ## Identifier Representation of did itself. is a part of DID URI. DID:Key ![](https://miro.medium.com/v2/resize:fit:1400/1*Q-yQXBFuuFIEZIjADkinVw.png) did:key identifier DID web ![](https://miro.medium.com/v2/resize:fit:1076/1*prr0S1NEghhuLlawMUzYaQ.png) did:web ## Relations Relations between all parts of DID identifier can be illustrated in the following diagram. DID method dictate how DID identifier gets created, updated, deactivated, and resolved. ![](https://miro.medium.com/v2/resize:fit:1064/1*ccyyKkG4pIOB47Mi6BNGYw.png) Focusing on the relations of the controller, key pairs, and the identifier is more interesting for us. The most significant power and benefit of DID are decoupling a key pair from a controller and identifier. It allows the rotation of keys and changes the ownership of the identifier and its subject and controller. It is the main competitive advantage of DID and SSI over web3 wallets and raw keys. The ideal case is KERI infrastructure that decouples all parties via cryptographic binding and protocols. To discover more, read the paper. We used did: keys as AID in the previous article. DID:key is a cryptographically bound identifier to the public key but cannot change the binding. As a result, keys couldn't be rotated in the future. The controller has no binding except to prove private key ownership via the signature-based protocol. On the other side, DID:web does not have a cryptographic binding of an identifier to a key pair from one side. It gives an easy possibility to rotate keys but loses the verifiability of the identifier. The most interesting part is the Controller to identifier binding in a did: web. It is based on proof of domain name ownership and website resource. As I mention, it has some security considerations and critics in a community. Still, at the same time, we get a critical mechanism that settles trust and connects identifiers to the organization entity. The mechanism of web domain ownership is well-defined and easy to explain to other users, even outside of SSI and web5 domain. It is getting wider adoption and creating a lot of use cases for organizations. So it helps to create a trust relationship between an identifier and organizational entity in a very transparent, human-readable, and self-explained way — the identifier hosted on the corporate domain belongs to the organization. On another side, it makes the transfer of the controller almost impossible. That's why it is critical to differentiate between a subject and a controller. ![](https://miro.medium.com/v2/resize:fit:1400/1*YAiTdueBSXhO8qAwD_9DOg.png) I believe that did:web still covers a lot of organizational cases and is suitable for issuing Verifiable Credentials and attestations on behalf of organizations. Step-by-step guide on how to create and manage did:web you could find in my article More detailed step-by-step coding guide with the live example you could find in my SSI notebooks book

Authentic Data Specifications and DIDs Critics.

## Authentic Data Specifications and DIDs Critics [Authentic Data Specifications](https://github.com/TrustFrame/authentic-data-specifications) Quite interesting work and concept that rise a few important questions and gives a critical view of current DIDs and did documents. ### DID critics > The first flaw is in the decentralized identity URI standard. The W3C proposed standard conflates identification with location causing complete chaos in the implementation and adoption of the standard. The standard says, "…the DID [string] identifies the DID subject and resolves to the DID document." By creating a standard URI format that both identifies and resolves, it has created a ridiculous explosion of pet storage and provenance solutions, each one having their own decentralized identity method (DID method) standard From one side I agree that did Url point and resolve to a did document but at the same time could point to a did subject or a did controller. So mixed concerns and purposes take a lot of work to address. I can't entirely agree that the variety of DID methods and sets of different trust registers is bad. I see a missed gap in the specs. We need to put more effort into normalizing and bringing more interoperability to the resolution process of DIDs. So we need a Universal resolution protocol. ### DID document critics At the same time folks rise a few topics about DID Docs itself: #### Byte sensitivity and IoT > The second flaw is in the decentralized identity document standard. Ignoring the fact that text based formats (JSON and JSON-LD) were chosen for byte-sensitive, digitally signed documents, the existing standard simply doesn't meet the requirements for an Internet-scale provenance-driven digital identity solution Text base is quite robust and human-friendly but performs purely on IoT where computation and memory are limited and internet environments with limited bandwidth. I agree that the textbase signet document is sensitive and fragile. I like the work of KERI community around a CESR. Composable Event Streaming Representation (CESR) The Composable Event Streaming Representation (CESR) is dual text-binary encoding format that has the unique property…www.ietf.org The Composable Event Streaming Representation (CESR) is dual text-binary encoding format that allows interchanging binary and text representations. It could be a good candidate that solve a format problem. #### Key rotation and history > ….they provide no solution for tracking the evolution of digital identities over time. There is no mechanism for recording key rotations and other provenance aggregations that occur over the lifetime of the controller. It is considered good hygiene to rotate identity keys on a regular basis, even if they have not become compromised. The consequence of having old keys is that there is the potential for old digitally signed data to be stored for years and still require the old keys for verification. DID docs do not support this. It is not fully true some DIDs methods is based on change events and centered around CRDT-based document changes like Sidetree protocol does. https://identity.foundation/sidetree/api/ True changes and diffgrames are not the first part citizen in a did Document, and quite often we have no way to observe a chain of changes, but it is a few dids that focus on this problem. So we mention SideTree and did:ion or did:elem. We still could interact with the side tree nodes and request operations for these dids even if it is not reflected in a document. Another working group is a KERI and KELs that address exactly this Key Event Receipt Infrastructure Key Event Receipt Infrastructure (KERI) An identity system-based secure overlay for the Internet is presented. This is based on a Key Event Receipt…weboftrust.github.io So we get KERL with a history of all changes with keys for the concrete identifier. In a same family or community, we have a did:peer that offer a diff gram protocol and operates with a backing storage https://identity.foundation/peer-did-method-spec/#backing-storage One more simplified and naive model is signed DID docs. This signed docs could form a micro-ledger chain where every key rotation did document change is signed with a previous version of the key or with a specific version of the recovery key. ### Portability > The last flaw in the existing standards is the lack of interchangeability of DID methods/services. Interchangeability is critical for portability of data and the sovereignty of users. Because not all DID methods are the same, moving from one method to another is neither automatic nor universal. Nor is there a standard for a DID document to keep a history of the DID methods that have been used to manage it throughout its past. Truly decentralized systems use standard file formats and standard protocols to ensure that users can take there data from one system to another with minimal effort. The best example we have today is still email. Anybody can use an IMAP client to download all of their email from their email provider (e.g. GMail, Yahoo Mail, etc), store them locally in .mbox files, and then later use the IMAP client to upload them to a different email provider. This is only possible because of the standard protocol (IMAP) and standard file format (MBox) used with email. Well I belive that with CESR serialization and DID doc spec or next iteration of did docs that could be based on ACDC we could have a transferable and portable file format Authentic Chained Data Containers (ACDC) An authentic chained data container (ACDC) is an IETF internet draft focused specification being incubated at the ToIP…www.ietf.org Authentic Data Provenance Logs authentic-data-specifications/Authentic Data Provenance Log.md at main ·… Community Specifications are recommended to be drafted in accordance with international best practices. Doing so…github.com As for 2023 I see that KERI successfully solve a raised challenge. In same time it is mean that we should revisit and apply all good parts of KERI community work streams to a DIDs

Web3 login web3 ID vs Web5 DIDAuth ( DID authentication)

*By Volodymyr Pavlyshyn, [YouTube Video](https://www.youtube.com/watch?v=NwN_4ksbuE4)* ## Introduction Web3 ID or Web3 login is being touted as a solution to many of our problems - it's decentralized, OTP-less, and passwordless. However, before we all move to this new, happier world, there are a few questions that need to be addressed: - How do we rotate a key and deal with a stolen private key? - Is it truly passwordless? How do we unlock a wallet, and how do we recover a password? - How do we make it cross-device? I propose a better answer to these challenges - Web5 Auth, or as we call it in our Affinidi SDK, DIDAuth. ## What is DIDAuth? DIDAuth is an edge auth protocol that proves ownership of private keys based on DID (Decentralized Identifiers). With DID, we decouple but cryptographically bind the Controller (user), private/public key pair, and identifier. So, we could solve the first challenge with a DID method that supports key rotation. With seed migration, we could solve a cross-device experience. Recovery is a more complex story; Affinidi SDK solves it for custodial users and provides building blocks for edge developers to implement their solutions for this challenge. ## The Problem with Web3 Login Web3 login or Web3 identity is a simple concept - login with your wallet, such as Metamask. However, this approach has several issues: - **Key Rotation**: If someone steals your wallet, they steal your identity. Key rotation should be a key feature, but it's not working well with login with Metamask or other similar solutions. - **Passwordless?**: Despite claims, you still need to maintain a password to access your private key. So, it's not truly better than what we already have. - **Portability**: It's not easy to port your wallets to different locations. - **Recovery**: If you forget the password, what should you do? The main concern is the possibility to rotate keys, which is why there are a lot of concerns about the Web3 login. ## The Solution: Web5 Login What I can offer, which has been available in our Affinidi SDK for a few years, is Web5 login. This protocol solves several issues: - **Decoupling**: The Decentralized Identifier (DID) allows you to decouple several elements. This is represented as a triangle, not as popular as the self-sovereign identity triangle, but it's the identity triangle. This triangle is the cryptographic binding between three things: the user or controller, the key pair (public and private key), and the identifier. The DID is your identifier that is cryptographically bound with the private and public key and cryptographically or otherwise bound with the controller. - **Key Rotation**: We need to find DID methods that allow us to keep the identifiers stable but still connected to the private and public key and to the controller, and allow us to rotate the keys. There are several DID methods that allow this, including DID peers, DID Key, and off-chain methods. On-chain methods can be quite expensive and not all of them give you the possibility to easily rotate the signing key. - **Portability and Recovery**: There are still open questions about how we do the portability between devices and how to do the recovery. For the Affinidi SDK, we have the answer for the recovery because we have the backup of the seeds and then you could use your email or phone```markdown to recover with your password. However, if you compromise your key, we need to build some extra protocol that allows us to do the operations in this case. The answer to this could be DID Key or DID Peer, and you could notify all your peers that this key is not valid anymore. While I see a lot of potential in Web5 Auth, I also see a lot of gaps and problems in the idea of logging in with your wallet. I encourage everyone to stay connected, share what you think, and let me know if you need more technical examples. --- *This article is based on the video "Web3 login web3 ID vs Web5 DIDAuth ( DID authentication)" by Volodymyr Pavlyshyn. The video was uploaded on January 29, 2023, and has been viewed 89 times as of the time of writing.* ---

Why self-sovereign identity, holistic identity, and data economy matter

[Youtube video about why ssi matter](https://www.youtube.com/watch?v=XfYehfCB5sY) ## Bloody Enterprice times I want to tell you my story and avoid 100500 talks about how the internet is broken. Let's discover my path and my WHY. I am Ukrainian. We are the most freedom-oriented nation that survived a few totalitarian regimes and fought all the time for fundamental untakable human rights. I am 20 years of experience in software engineering and have always been looking for an ethical and human-oriented business. E-commerce and advertisement are not always ethical and user-centric. It could just force people to buy more. For me, it was a compromise with myself. I am not new in the identity business I built a few big identity systems in 2010 for a US market on top of WIF (Microsoft identity framework). ## TomTom But the first aha moment and entitlement happened with me around 2015. I was a part of the Traffic analytics department of TomTom. TomTom is a defacto navigation system that even creates a verb — to tomtom, similar to google. Every day you commute, you generate billions of traces and data points that fuel a billion-dollar business and create value for TomTom. In the case of Tomtom, it was not so bad that you get something back like better routes, traffic insides, faster way to find parking slots, etc. TomTom is ethical, anonymizes data, and cares about data security or at least forced to do so for you. Your traffic data do not belong to you; all millions of dollars or euros do not go into your pocket. ## Data Soviet Union ![]() I was born in the Soviet Union, and I am a Capitalist in a DNA and could write a book about the free market and the need for democracy and a free market — don't get me wrong. I believe in a co-created ecosystem that works side by side — users together with organizations and businesses. The primary fuel for this ecosystem is data. Data is new oil and gold. Most of the population is unaware of the data economy and owns data and content that we permanently co-create but do not own. So in terms of data on the modern internet, we all live in some kind of Soviet Union where citizens create a value but have no concept of private property. It was eating my brain for a long time till 2020 without an answer. It was a COVID crisis, and a few startups failed. I was practically unemployed. I was lucky and met folk from Affinidi. Well, the first impression was quite strange. I had a feeling that I was talking with some kind of church)) Everybody was talking about an Identity, free data, and a new domain that would change the world!! ## Affinidi Affinidi was building an SDK and building blocks for a Self-sovereign identity. A real decision changer for me was the case of GoodWorker. So it was a company and product that built a system on top of Affinidi SDK that changed millions of lives of blue-collar seasonal workers in India for the better. Seasonal workers migrate from villages to big cities and work in different factories etc. but somehow do not have a confirmation of employment history and verification of skills. As a result — no proof of stable income and the possibility of finding a better job or taking a loan. It is a closed loop full of fraud and sadness. GoodWorker helps create a new identity and build the worker's identity with verified skills, employment, and income. It also partners with platforms that help develop new skills and find a way to a better life. Affinidi has a powerful engineering culture and extraordinary people. So I was hooked. I finally found an answer to my question of how to give data back to users and create a user-centric landscape. I am still on this journey. I focused my Youtube and Meduim on SSI and identity systems and constantly shared my findings. You can find my channel. I made a little book in the form of Jupyter notebooks about Affinidi SDK and core concepts for free. ![](https://miro.medium.com/v2/resize:fit:1000/1*ogMyhiJ03-rktu1G_6Hr7g.png) The ultimate goal is to make data work for you and bring you: - New data inside for a better life and decisions - make money from it - improve a community and world around We must build an interconnected ecosystem and addressable space for data agents to make it happen. I see a few prerequisites for It. - **Holistic Identity** — give an instrument that allows you to name yourself and identify. Naming + addressing - **Data Unlocking** — to share data and get inside, we need to structure data and make them interoperable and portable. You could read more about data unlocking. The next level is more complex how to create **Trust** but keep **privacy** as the first principle. On privacy, I see two cornerstones - Privacy by design - Laws of Identity I am convinced that we are lacking new types of identity systems that should be built on top of these principles and give a user ability to create fluid multi-pseudonymity relations and get the possibility to be authorized without traceability. You can read more here. On the topic of trust, it is still a huge area that requires research and investment. I recommend reading At a point when we manage to give instruments that create trust and data exchange trust protocols — the data economy will get a new spinoff. I worked for a long time on SSI SDK but quickly discovered it was insufficient. It is a building block, but we must do much more and build an ecosystem. SSI is a relatively new domain that struggles for mass adoption and a basic understanding of engineers and regular users. We on the beginning of the adoption curve. A lot of standards is still on developing or even spec and concept face without a straightforward implementation. So it is not even a place to google a solution ![](https://miro.medium.com/v2/resize:fit:1400/1*uMljy8Z_CHZnbrCtkYFsmQ.jpeg) © [https://www.cblohm.com/blog/education-marketing-trends/adoption-curve-education-marketing-strategy/](https://www.cblohm.com/blog/education-marketing-trends/adoption-curve-education-marketing-strategy/) if you follow my articles, I shoved how SSI principles correlate and support laws of identity and privacy by design principles. As same SSI makes data unlock and portability happens. I believe that the future of identity and reputation systems is data and attribution identification and authorization. We will shift from cryptography and key ownership proof to a data and data behavior user profile where data will be the main authorization driver. You are your data points, not your private key. Your public identity in SSI is a combination of DIDs and a VP that shares data publically. > Identity = DIDs + VPs It will form an identity & data loop where data will be a fuel