What Is Decentralized Identity?

Phil Windley // Mon Jun 17 07:42:00 2024 // identity ssi decentralized+identity verifiable+credentials

In Yeah, yeah, yeah, yeah, yeah, nah, Alan Mayo references my recent blog post, Decentralized Identity Comes of Age, and says:

My challenge to the decentralization community is for them (someone) to explain how it works in relatively simple and reasonable terms. I say relative because identity is not simple, so we should not expect simple solutions.

This post is my attempt to do that for Alan and others.

Identity is how we recognize, remember, react to, and interact with other people, organizations, and services. Put another way, identity is about relationships. Online we suffer from a proximity problem. Since we're not near the parties we want to have relationships with, our natural means of recognizing, remembering, and interacting with others can't be used. Digital identity systems are meant to provide us with the means of creating online relationships.

Traditional identity systems have not served us well because they are owned and controlled by companies who build them for their own purposes. The relationships they support are anemic and transactional. We can't use them for any purpose except what their owner's allow.

Decentralized identity systems¹ on the other hand allow you to create online relationships with any person, organization, or service you choose and give you the tools to manage and use those relationships. They help you recognize, remember, react to, and interact with them. The most important tool is a decentralized identity wallet. The world of decentralized identity wallets is still young, but organizations like the Linux Foundation's Open Wallet Foundation give me hope that useful, interoperable wallets are a tool we'll all be able to use soon. They are as foundational to decentralized identity as a browser is to the web.

Besides helping you manage peer-to-peer relationships with others online, wallets hold verifiable credentials, the digital analog to the credentials and cards you carry in a physical wallet. One of the most important aspects of digital relationships is providing information about yourself to those you interact with. Sometimes that information can come from you—it's self-asserted—but many times the other party wants to reliably know what others say about you. For example, if you establish a banking relationship, the bank is legally obligated to verify things like your name and address independent of what you say. Decentralized identity wallets allow you to prove things about yourself using credentials others provide to you. At the same time, they protect your privacy by limiting the information disclosed and forgoing the need for the party you're interacting with to directly contact others to verify the information you provide.

In summary, decentralized identity systems allow you to create digital relationships with other parties independently, without relying on any other organization or service. These relationships are direct, private, and secure. They also provide the means for you to prove things about yourself inside these relationships so that even though you're operating at a distance, you and the other party can have confidence in the relationship's authenticity.

How Does It Work

The preceding paragraphs say what decentralized identity is, and provide its benefits, but don't say how it works. Alan and others will likely want a few more details. Everything I describe below is handled by the wallet. The person using the wallet doesn't need to have any more knowledge of how they work than the operator of a browser needs to understand HTTP and HTML.

The foundation of a peer-to-peer, decentralized online relationship is an autonomic identifier like a peer DID. Identifiers are handles that someone else can use to identify someone or something else online. Peer DIDs can be created by a wallet at will, they're free, and they're self-certifying (i.e., there's no need for a third party). A relationship is created when two identity wallets create and exchange peer DIDs with each other on behalf of their owners. Peer DIDs allow the parties to the relationship to exchange private, secure messages.

There are four primary interaction patterns that wallets undertake when exchanging messages:

1. DID Authentication which uses the DIDs to allow each party to authenticate the other
2. Single-Party Credential Authorization where the same party issues and verifies the credential.
3. Multi-Party Authorization where the credential issuer and verifier are different parties.
4. Generalized Trustworthy Data Transfer which uses a collection of credentials to aid the wallet owner in completing online workflows.

Verifiable credentials make heavy use of cryptography to provide not only security and privacy, but also confidence that the credential data is authentic. This confidence is based on four properties a properly designed credential presentation protocol provides:

1. The identifier of the credential issuer
2. Proof that the credential is being presented by the party is was issued to
3. Proof that the credential has not been tampered with
4. The revocation status of the credential

The credential presentation can do all this while only disclosing the information needed for the interaction and without the verifier having to contact the credential issuer. Not having to contact the issuer ensures the credential can be used in situations with poor connectivity, that the issuer needn't be online, and preserves the credential subject's privacy about where the credential is being used.

A properly designed credential exchange protocol has four important properties:

1. The system is decentralized and contextual. There is no central authority for all credentials. Every party can be an issuer, an owner, and a verifier. The system can be adapted to any country, any industry, any community, any set of credentials, any set of trust relationships.
2. Issuers are free to determine what credentials to issue and whether or not to revoke them.
3. Wallet owners are free to choose which credentials to carry and where and when they get shared. While some verifiers require a specific credential—such as a customs agent requiring a passport—others will accept a range of credentials. Therefore owners can decide which credentials to carry in their wallet based on the verifiers with whom they interact.
4. Verifiers make their own decisions about which credentials to accept. For example, a bar you are trying to enter may accept any credential you have about your date of birth. This means some credentials (e.g., passports, driving licenses, birth certificates) may be much more useful than just for the original purpose for which they were issued.

These properties make a decentralized identity system self sovereign.

Why is Decentralized Identity Important?

Decentralized identity systems are designed to provide people with control, security, and privacy while enhancing the confidence we have in our online relationships. Some time ago, I wrote the following. I think it's an apt way to close any discussion of decentralized identity because unless we keep our eyes on the goal, we'll likely take shortcuts in implementation that fail to live up to their promise.

Presently, people don't have operational relationships anywhere online.² We have plenty of online relationships, but they are not operational because we are prevented from acting by their anemic natures. Our helplessness is the result of the power imbalance that is inherent in bureaucratic relationships. The solution to the anemic relationships created by administrative identity systems is to provide people with the tools they need to operationalize their self-sovereign authority and act as peers with others online. Peer-to-peer relationships are the norm in the physical world. When we dine at a restaurant or shop at a store in the physical world, we do not do so under the control of some administrative system. Rather, we act as embodied agents and operationalize our relationships, whether they be long-lived or nascent, by acting for ourselves. Any properly designed decentralized identity system must provide people with the tools they need to be "embodied" in the digital world and act autonomously.

Time and again, various people have tried to create decentralized marketplaces or social networks only to fail to gain traction. These systems fail because they are not based on a firm foundation that allows people to act in relationships with sovereign authority in systems mediated through protocol rather than by the whims of companies. We have a fine example of a protocol mediated system in the internet, but we've failed to take up the daunting task of building the same kind of system for identity. Consequently, when we act, we do so without firm footing or sufficient leverage.

Ironically, the internet broke down the walled gardens of CompuServe and Prodigy with a protocol-mediated metasystem, but surveillance capitalism has rebuilt them on the web. No one could live an effective life in an amusement park. Similarly, we cannot function as fully embodied agents in the digital sphere within the administrative systems of surveillance capitalists, despite their attractions. The emergence of self-sovereign identity, agreements on protocols, and the creation of metasystems to operationalize them promises a digital world where decentralized interactions create life-like online experiences. The richer relationships that result from properly designed decentralized identity systems promise an online future that gives people the opportunity to act for themselves as autonomous human beings and supports their dignity so that they can live an effective online life.

Notes

1. I prefer the term self-sovereign to decentralized because it describes the goal rather than the implementation, but I'll stick with decentralized here. All self-sovereign identity systems are decentralized. Not all decentralized identity systems are self-sovereign.
2. The one exception I can think of to this is email. People act through email all the time in ways that aren't intermediated by their email provider. Again, it's a result of the architecture of email, set up over four decades ago and the culture that architecture supports.

Photo Credit: Young Woman Using a Wallet from DALL-E (public domain) Prompt: draw a rectangular picture of a young woman using a wallet.

Decentralized Identity Comes of Age

Phil Windley // Wed Jun 5 09:25:00 2024 // identity ssi decentralized+identity verifiable+credentials

I'm at European Identity Conference (EIC) this week. I haven't been for several years. One thing that has struck me is how much of the conversation is about decentralized identity and verifiable credentials. I can remember when the whole idea of decentralized identity was anathema here. The opening keynote, by Martin Kuppinger is Vision 2030: Rethinking Digital Identity in the Era of AI and Decentralization. And all he's talking about is decentralized identity and how it's at the core of solving long standing identity problems. Another data point: Steve McCown and Kim Hamilton-Duffy ran a session this morning called Decentralized Identity Technical Mastery which was a hands-on workshop. The rather large room was packed—standing room only.

I attended a couple of sessions on decentralized identity where I didn't know the companies, the speakers, or the specific platforms they were using. The space is too big to keep track of anymore. Identity professionals who were ignoring, or talking down, decentralized identity a few years ago are now promoting it.

This truly feels like a tipping point to me. At IIW, it's identity geeks talking with other identity geeks, so it's no surprise to see lots of discussion about new things. EIC is a different kind of conference. There are about 1000 people here I'd guess. Most of them aren't working on new standards or open source projects. Instead they're the folks from companies who come to conferences like EIC to learn how to solve the problems their organization is facing.

In the keynotes and in numerous sessions, the message that they're hearing is "decentralized identity will solve your problems." Martin closed his talk with the proclamation that "decentralized identity is the new paradigm for identity."

Photo Credit: Credential Tipping Point by DALL-E (public domain) Prompt: Draw a rectangular picture that shows a credential at a tipping point. Make the credential look like a lifelike credential, include cartoon picture, and some writing. Use bright friendly colors.

Can LLMs Provide References for Their Work? An Experiment

Phil Windley // Thu May 30 08:52:00 2024 // genai llm chatgpt prompt+engineering

Recently my friend Scott Mace asked this on X in response to a post about the evolution of software and how LLMs will likely follow that same trajectory:

Yes, but how trustworthy will it be? Can I at least see the links it used to create its response?

From X
Referenced 2024-05-21T18:09:06-0400

The short answer is "no", but the real answer is a bit more nuanced because of how LLMs like ChatGPT work. First the short answer: LLMs don't understand what they're saying so they can't reference the material that it used to create a response. They don't work like that. They don't go out, do a bunch of research and then create a response. Instead lots (and I mean LOTS) of material is fed into the program that creates the model, a multi-dimensional matrix of word orders. Then when you ask a question ("give it prompt" in LLM-speak), it processes the question and generates text based on the probabilities of words in its model¹. There's no way it can satisfy Scott directly because the model doesn't—can't, as far as I know—include the references that it used to create the text because it's generating it on the fly from material that has been thoroughly blended together.

But, in fairness, that's not what people do most of the time either. If you asked me over lunch or at the end of a tech presentation to describe zero trust and its pros and cons, I'd start talking. I wouldn't start looking up things on the web and somehow weave them into text complete with references. I'd go look for references if you asked me to back up something I said. So, let's try that with ChatGPT 4o. I gave it the following prompt:

You are a writer for a website focusing on technology. Your specialty is security. Write a 150 word explanation of zero trust with three pros and three cons.

ChaptGPT answered with this text:

Zero Trust is a security model based on the principle of "never trust, always verify." Unlike traditional security models that assume everything inside the network is safe, Zero Trust assumes that threats can exist both inside and outside the network. It requires strict identity verification for every user and device attempting to access resources, regardless of their location.

Pros:

1. Enhanced Security: By continuously verifying users and devices, Zero Trust reduces the risk of breaches and unauthorized access.
2. Minimized Attack Surface: It limits access to only what is necessary, reducing potential entry points for attackers.
3. Improved Compliance: Helps meet regulatory requirements by ensuring strict access controls and logging all access attempts.

Cons:

1. Complex Implementation: Deploying Zero Trust can be complex and time-consuming, requiring a significant overhaul of existing systems and processes.
2. Increased Costs: The initial investment in technology and training can be high.
3. User Experience Impact: Continuous verification can lead to friction and inconvenience for users if not implemented smoothly.

Zero Trust is essential for modern cybersecurity, but it requires careful planning and resources to implement effectively.

That's pretty good. But what if we need some references to other material to back up the pros and cons? I asked ChatGPT to supply them:

Now repeat that task, but this time include references as hyperlinks to back up each pro and con.

ChaptGPT answered with this text:

Zero Trust is a security model based on the principle of "never trust, always verify." Unlike traditional security models that assume everything inside the network is safe, Zero Trust assumes that threats can exist both inside and outside the network. It requires strict identity verification for every user and device attempting to access resources, regardless of their location.

Pros:

1. Enhanced Security: By continuously verifying users and devices, Zero Trust reduces the risk of breaches and unauthorized access (CSO Online).
2. Minimized Attack Surface: It limits access to only what is necessary, reducing potential entry points for attackers (NIST).
3. Improved Compliance: Helps meet regulatory requirements by ensuring strict access controls and logging all access attempts (Gartner).

Cons:

1. Complex Implementation: Deploying Zero Trust can be complex and time-consuming, requiring a significant overhaul of existing systems and processes (Forrester).
2. Increased Costs: The initial investment in technology and training can be high (ZDNet).
3. User Experience Impact: Continuous verification can lead to friction and inconvenience for users if not implemented smoothly (TechRepublic).

Zero Trust is essential for modern cybersecurity, but it requires careful planning and resources to implement effectively.

That looks great! Nice references for each bullet. There's just one problem. All the links, except the NIST reference, are dead. I don't know if they're wrong, made up, or stale. I tried finding content on a few of the sites by searching and came up dry. As I heard Johannes Ernst say once, ChatGPT is a "large language model" not a "large fact model" and this bears that out.

Still, asking for references or evidence for statements is something people are going to want. So, I tried a different tack. This time I asked this:

Why do you say complex implementation is a problem for zero trust? Can you give me a few references on that I can read myself?

ChatGPT responded with this:

Implementing a Zero Trust security model can be challenging for several reasons:

1. Overall Complexity: Zero Trust requires a comprehensive understanding of your network's intricacies, including users, devices, applications, and data. This can involve significant changes to existing infrastructure, which can be disruptive and costly. Organizations need to be prepared for the extensive planning and resources required for successful implementation​ (Help Net Security)​​ (Enterprise Networking Planet​).
2. Legacy Systems: Many organizations have legacy systems that are not designed to operate within a Zero Trust framework. These systems might require different security measures or even complete replacement, adding to the complexity and cost (Help Net Security)​​ (Enterprise Networking Planet​)
3. Cultural Shift: Zero Trust is not just a technological shift but also a cultural one. It requires continuous verification and strict access controls, which can lead to user frustration and resistance if not managed properly. Ensuring user buy-in and minimizing disruption to workflows through training and communication is essential (Deloitte United States)​​ (Guidehouse).
4. Resource Intensive: Implementing and maintaining Zero Trust can put a strain on IT resources due to the need for continuous monitoring and management. The need for advanced security tools and ongoing updates further adds to the resource demands (Help Net Security)​​ (Enterprise Networking Planet​).
5. Stakeholder Alignment: Achieving buy-in from all stakeholders and aligning them with the Zero Trust principles is critical. This requires a coordinated effort to educate stakeholders, prioritize gaps, and ensure consistent understanding and application of Zero Trust principles across the organization (Deloitte United States)​​ (Guidehouse).

These challenges highlight the importance of a phased and well-planned approach to Zero Trust implementation, considering both technological and human factors. For more detailed insights, you can refer to articles from Help Net Security and Guidehouse.

Much better. The links in the bullets all work, but the ones at the end don't. The articles it references aren’t very detailed, so I wouldn’t say they’re stellar references, but at least there’s a pointer to outside material that discusses similar challenges. So, partial success.

I've found that when you're using ChatGPT to do research, treating it like a librarian and asking questions that follow up are the best way to gain confidence that the material is correct and find the supporting material, just as I did above. I'm sure you could wrap additional helper functions around an LLM to make getting references easier. But for now interrogation through chat is the best way to get comfortable with the results.

Notes

1. Yeah, this is really simplified and thus wrong, but it's directionally correct. For a better explanation, see What Is ChatGPT Doing … and Why Does It Work?.

Photo Credit: Older Man Talking to Robot Librarian from DALL-E (public domain) Prompt: draw me a rectangular picture of an older man talking with a robot librarian. Use earth tones.

Internet Identity Workshop XXXVIII Report

Phil Windley // Mon Apr 29 07:47:00 2024 // identity iiw

We recently completed the 38th edition of the Internet Identity Workshop. We had 330 people from around the world who called 169 sessions. As usual there was lots of energy and thousands of side conversations. IIW is a place to get things done and it showed in the energy and the comments people made to me about how much they enjoyed it.

As you can see by the pins in the map at the top of this post, there were attendees from all over the world. Not surprisingly, most of the attendees were from the US (241), followed by Canada (11). Germany, India, and Switzerland rounded out the top five with 9, 8, and 7 attendees respectively. Attendees from India (5), Thailand (3), and Korea (3) showed IIW's diversity with attendees from APAC. And there were 4 attendees from South America this time. Sadly, there were no attendees from Africa again. Please remember we offer scholarships for people from underrepresented areas, so if you'd like to come to IIW39, please let us know. If you're working on identity, we want you there.

For states and provinces, California was first with 122. Washington (16), Utah (10), Texas (10) and New York (10) rounded out the top five. San Francisco (14) Oakland (13), San Jose (12), Seattle (11), and New York (9) were the top cities.

In addition to sessions, we have a demo hour on Wednesday that is a little like speed dating. There were 20 different projects highlighted. There's always more than one session that I want to attend in any given time slot and choosing is hard. That's a common refrain. Luckily we have sessions notes that we publish in a Book of Proceedings.

Here's pictures from all three days courtesy of Doc Searls

You belong at IIW! IIW is where you will meet people to help you solve problems and move your ideas forward. Please come! IIW 39 will be held October 29-31, 2024 at the Computer History Museum. We'll have tickets available soon.

Using X.509 Certs for DID Provenance

Phil Windley // Thu Apr 25 08:31:00 2024 // identity ssi decentralized+identifiers verifiable+credentials x.509

When you used a verifiable credential to prove something about yourself, the verifier can know cryptographically: (1) the identifiers for the issuer, (2) the credential hasn't been tampered with, (3) the credential was issued to you, and (4) the credential hasn't been revoked. These four checks are important because their establish the fidelity of the data being transferred. They don't, however, tell them whether they can trust the issuer. For that, they need to take the issuer's decentralized identifier (DID) that they got from credential presentation and determine who it belongs to.

At the most recent Internet Identity Workshop, Drummond Reed gave a session on how X.509 certificates could help with this. The first step, like always, is to resolve the DID and retrieve the DIDDoc that associates keys and endpoints with the DID. The endpoint can be an HTTP server and, of course, should have an X.509 certificate providing TLS security. That certificate, at the very least, has a a domain name to bind that to the certificate's public key. It can, if you pay for the feature, also include information about the entity that applied for the certificate. The certificate authority proofs that information and is vouching for it when they sign the certificate.

The key to making the X.509 certificate useful for checking the provenance of a DID lies in one key change. X.509 certificates can contain and extended field called a Subject Alternative Name. This following figure shows how it can help.

In this figure:

1. The issuer (Attestor) creates the DID they will use to issue the certificate along with its associated DIDDoc, including an HTTP endpoint for DID verification.
2. Attestor applies for a X.509 certificate for that endpoint, including in the application the DID they created in (1).
3. The certificate authority does it's usual proofing of the application and issues a certificate that includes the DID in the Subject Alternative Name field.
4. The issuer creates a credential definition in the usual way that includes their DID and writes it to whatever Verifiable Data Registry their DID method dictates.
5. Attestor issues a credential to a holder (Alice) using that credential definition.
6. At some later time, Alice presents the credential to the verifier (Certiphi).
7. Certiphi resolves the DID to get the DIDDoc and retrieves the verfication endpoint from the DIDDoc
8. Certiphi retrieves the certificate for that endpoint¹.
9. Certiphi verifies the certificate by checking it's signature and ensures that the DID in the DIDDoc for the credential matches the one in certificate.²

The issuer's DID has now been tied in a verifiable way to whatever information is in the certificate. Provided the certificate includes information about the entity beyond the domain name, the verifier can use that information to determine whether or not the credential is authentic (i.e., issued by who the credential definition purports issued it). That might be all the evidence they need to determine whether to trust the entity. Certificate authorities could also issue verifiable credentials to the customer attesting the same verified claims—after all, it's one more product they can offer.

The benefit of doing issuer validation using X.509 certificates is that there are already many trusted X.509 certificate authorities in business who already do proofing of attributes about businesses. That's a huge chunk of the verifiable data ecosystem that doesn't need to be built because it can be leveraged. To make this work, digital certificate authorities would need to start offering to validate DIDs and include them in a certificate as a Subject Alternative Name. I don't discount that this will take some bureaucratic maneuvering. Certificate authorities will need to see a business opportunity. I'd love to see Digitcert or someone do a pilot on this.

Notes

1. Note that this step might be combined with the previous step if the Verifiable Data Registry is the same server as the endpoint, but that's not necessarily going to be the case for a number of reasons.
2. Note that this does not create a call back wherein Attestor can determine which credential was used, preserving the privacy of the presentation. Attestor does know one of its credentials has been presented to Certiphi. If this information leakage bothers you, then any web-based DID method is potentially a problem.

Relationships are Entangled

Phil Windley // Thu Apr 18 11:59:00 2024 // identity relationships

Identity is the ability to recognize, remember, and react to people, organizations, systems, and things. In the current web, companies employ many ponderous technological systems to perform those functions. In these systems, we are like ghosts in the machines. We have "accounts" in companies' systems, but no good way to recognize, remember, and react to them or anyone else. We are not digital embodied.

One of the great benefits of embodiment is the ability to form and operationalize rich digital relationships. I've written a lot about the nature of digital relationships.

• Relationships and Identity
• Authentic Digital Relationships
• Ephemeral Relationships
• Operationalizing Digital Relationships
• Relationships in the Self-Sovereign Internet of Things
• The Architecture of Identity Systems
• Are Transactional Relationships Enough?
• Fluid Multi-Pseudonymity

One of the discussions at VRM Day caused me to think about a feature of digital relationships I hadn't considered before. Someone said that if you think about a graph with people (or things, organizations, and so on) as the nodes, the relationships are the edges, like so¹:

In this figure Alice and Bob have a bi-directional relationship. This is how I've normally thought about it and how I'd have drawn it. But in today's discussion, someone said that the relationship is shared and that Alice and Bob both control it. But I realized that viewpoint is too simple. Specifically, Alice and Bob each have a different perspective of that relationship and will use it separately.

For example, imagine that Alice is the cashier at a grocery store and Bob is a customer. Alice gives great service, so Bob seeks her out when he shops. Alice on the other hand has no particular recollection of Bob from encounter to encounter. For Alice, the relationship is ephemeral, but for Bob, it's longer term. The nature of each relationship is different. So, we might look at it like this:

But after discussing it some more, I realized that these relationships aren't independent. They're entangled like this:

In the example I gave above, as Bob seeks out Alice more and more, Alice might come to recognize him and call him by name, changing the nature of her relationship with Bob. And that may influence the nature of Bob's relationship with Alice. Over time, these interactions influence both relationships. So, while Alice and Bob both have control over their relationship with the other, actions by one influence the other.

I frequently say that we don't build identity systems to manage identities, but rather to manage relationships. The problem with contemporary identity systems is that they are all one sided, controlled by one party—almost always a company. As I've said before, people are not digitally embodied and thus have no good way to manage their online relationships. As we strive to build better digital identity systems, I think it's paramount that we build systems that provide people with tools that embody them and provide them with the ability to operationalize their online relationships. These are more than decentralized; they are self-sovereign.

Notes

1. Peer decentralized identifiers (DIDs) are a great technology for creating bi-directional relationships.

Web 2.0 is Collapsing Under its Own Weight

Phil Windley // Thu Apr 4 09:45:00 2024 // web identity authentication authorization verifiable+credentials

I don't know if you recall the game Kerplunk. It's a classic children's game that has been around for decades. I remember playing it with my sister. The basic setup involves a transparent plastic tube, a number of sticks, and marbles. The sticks are threaded through the tube to form a web or nest at the bottom on which the marbles rest. We'd take turns removing a stick at a time, trying not to let any marbles fall through the web and out of the tube. At some point, the remaining sticks can't hold the marbles and everything falls down.

The modern web reminds me more and more of a big Kerplunk game and I think the marbles are about to fall. What started out as an easier way to do things like shop, bank, and get health care information has become increasingly complex over time. More and more of the email I receive seems to be simply directing me to log into some bespoke system to retrieve a message or engage in some workflow. And even with a password manager, the act of logging in is often a chore with different user interfaces, custom MFA requirements, and weird rules for passwords. Once you're on the system, session time-outs induce their own form of anxiety since stepping away for a few minutes to attend to something else might require going through the whole Kafkaesque process all over again. The modern web has turned into a dystopian theater of the absurd where even reading a simple appointment reminder from your doctor requires several minutes of stress-inducing interaction with baroque systems and processes.

And it's not just doctors, of course, banks, government agencies, hospitals, ecommerce sites, and customer service systems all adopt these special purpose messaging systems. If you ask these organizations why they use bespoke messaging systems, they'll list things like "timely and improved communication," "convenience," and "privacy and security." But the real reason is that it's more convenient for them because these systems are integrated with their backends and make their processes more manageable. There's certainly nothing about them that's more convenient, timely, or better than email for their customers¹.

I also question the privacy and security premise. Email can be insecure. And your email provider can see the contents of your emails. But the messaging system run by your doctor or bank is likely less secure than the email systems run by Apple, Google, and the others. And achieving privacy by making everything incompatible so that you have to use a different system for each correspondent is like chopping off your finger to prevent hangnails.

How did we get here? Bureaucracy. Not just government bureaucracy, but bureaucracy of all kinds. In Utopia of Rules², David Graeber talks about how power imbalances force the less powerful group to perform what he calls interpretive labor, the work of understanding and implementing what's better or more convenient for the more powerful partner. People are not equal participants in online interactions. We don't have the tools to be fully embodied online³. Because of this we are forced to play by the rules organizations online who are digitally embodied with servers, identity systems, customer management systems, and so on. And part of that is being forced to use their inconvenient and anemic messaging systems.

What's the answer? People need tools. I think digital wallets (a bad name for an important tool), autonomic (peer) identifiers with strong cryptography, and verifiable credentials are a huge step forward. These tools provide the means for people to be peers online rather that mere ghosts in someone else's machine. That's why I insist on using the term self-sovereign rather than decentralized to describe these systems. Cogito Ergo Sum.

Notes

1. For a deeper dive into why one-off messaging systems are never as good as email, see Rich Sharing and Personal Channels. Email and other useful messaging systems exhibit a property called rich sharing that makes them much more robust that the simple idea of "sharing a message" would bring to mind.
2. If you're interested in power imbalances and how they come about, I can't recommend Graeber's book highly enough. He had such a keen understanding of this problem and wrote about it in a way that's both informative and entertaining.
3. I talk about this in more detail in Chapter 17 of Learning Digital Identity when I discuss authentic digital relationships.

Photo Credit: Playing Kerplunk from DALL-E (public domain) Prompt: Draw a picture of a boy and girl playing kerplunk that's 1200x500 pixels

Decentralizing Energy

Phil Windley // Tue Mar 19 09:21:00 2024 // climate+change solar geopolitics energy

My wife, Lynne, recently gave me a copy of Peter Zeihan's book, The Accidental Superpower: Ten Years On. The book was originally published in 2014, but Zeihan has updated it by inserting chapters talking about what he got right in 2014, what he got wrong, and why. The focus of the book is geopolitics—how geography and demographics shapes the world order—and how Bretton Woods changed that in significant ways. The book makes the case that so much of what made Bretton Woods useful to the US and why the US engaged with the rest of the world for the 70 years following World War II is changing. As it changes the free trade system enabled by Bretton Woods is also changing. This will have significant impact on every country in the world.

Much of what changes has to do with energy. One of the things¹ Zeihan got right was his assertion that unlike much of the rest of the developed world, the US doesn't need to import energy—specifically oil—we are a net energy importer. This changes the dynamic wherein the US is willing to be the protector of shipping lanes for the entire world. As a result, the future could see a US that has the luxury of ignoring events in the Middle East, Ukraine, and elsewhere, whereas Europe (to take just one example) cannot. The book is full of other interesting predictions and conclusions just like this one. I encourage you to read it if you find this as fascinating as I do.

Zeihan makes a big deal of shale oil production, which accounted for 66% of US production in 2022. But as I read this, I was thinking about renewables. As I wrote in 2020, I've gone in big on solar power at my house, love my EV, and have replaced most things in the house (like the furnaces) with versions that run on electricity.  I did this because it made my life easier and saves me money. The fact that it's good for the environment is a bonus.

But, solar and wind are not just renewable, they also allow energy production to be decentralized in ways oil and natural gas can't. Oil and natural gas deposits are where they are. Some countries are blessed with them and the others have to buy from those countries. And they're often far away, requiring shipping through potentially hostile waters. But that's not true of renewables. They can usually be built and located where ever the need is². This changes geopolitical equation in significant ways. Areas of the world that are not energy independent, like Europe, are moving toward renewables too slowly to prevent future energy shocks. The problem with renewables is that they're long-lead items—they take years to plan and bring online.

Petroleum and Bretton Woods enabled the modern world, providing portable, storable sources of energy that could easily and safely move to where ever it was needed.³ If we are indeed at the end of the Bretton Woods era, the world is in for significant changes as it adjusts to a life where free trade, and easy access to petroleum-based energy, cannot be assumed. Moving energy production closer to the places it's used is one strategy for dealing with this world-altering disruption. Buckle up.

Notes

1. There are other things that are important to the books overall conclusion besides energy. I'm just cherry picking that because I was thinking about it. For example, the US is largely self-sufficient from an overall import/export standpoint. We don't import nearly as much as many other countries and could replace what we do import relatively easily.
2. It's not just renewables. Nuclear power can also be located closer to demand than an oil deposit. I started my career as a nuclear metallurgist, so I'm a fan. I think many countries are going to be sorry they've closed nuclear plants and made them too hard to construct profitably.
3. The feats of engineering that have enabled these energy flows is truly astounding.

Photo Credit: Oil Tanker at Sunset from Terski (Pixabay)

Identity Metasystems and Lessons from Building the Sovrin Foundation

Phil Windley // Thu Feb 22 08:49:00 2024 // identity ssi podcasts

I recently spoke with Riley Hughes of Trinsic on his Future of Identity podcast about the birth of Sovrin Foundation, its inevitable growing pains, self-sovereign identity, identity metasystems, and adoption. Give it a listen.

I'm grateful to Riley for having me on as a guest.

Zero Trust with Zero Data

Phil Windley // Wed Feb 14 08:18:00 2024 // identity ssi zero+trust zero+data authorization verifiable+credentials

Presenting your ID to buy beer is used so often as an example of how verifiable credentials work that it's cliche. Cliche or not, there's another aspect of using an ID to buy beer that I want to focus on: it's an excellent example of zero trust

Zero Trust operates on a simple, yet powerful principle: "assume breach." In a world where network boundaries are increasingly porous and cyber threats are more evasive than ever, the Zero Trust model centers around the notion that no one, whether internal or external, should be inherently trusted. This approach mandates continuous verification, strict access controls, and micro-segmentation, ensuring that every user and device proves their legitimacy before gaining access to sensitive resources. If we assume breach, then the only strategy that can protect the corporate network, infrastructure, applications, and people is to authorize every access.

From Zero Trust
Referenced 2024-02-09T08:25:55-0500

The real world is full of zero trust examples. When we're controlling access to something in the physical world—beer, a movie, a boarding gate, points in a loyalty program, prescription drugs, and so on—we almost invariably use a zero trust model. We authorize every access. This isn't surprising, the physical world is remarkably decentralized and there aren't many natural boundaries to exploit and artificial boundaries are expensive and inconvenient.

The other thing that's interesting about zero trust in the physical world is that authorization is also usually done using Zero Data. Zero data is a name StJohn Deakin gave to the concept of using data gathered just in time to make authorization and other decisions rather than relying on great stores of data. There are obvious security benefits from storing less data, but zero data also offers significantly greater convenience for people and organizations alike. To top all that off, it can save money by reducing the number of partner integrations (i.e., far fewer federations) and enable applications that have far greater scale.

Let's examine these benefits in the scenario I opened with. Imagine that instead of using a credential (e.g., driver's license) to prove your age when buying beer, we ran convenience stores like a web app. Before you could shop, you'd have to register an account. And if you wanted to buy beer, the company would have to proof the identity of the person to ensure they're over 21. Now when you buy beer at the store, you'd log in so the system could use your stored attributes to ensure you were allowed to buy beer.

This scenario is still zero trust, but not zero data. And it's ludicrous to imagine anyone would put up with it, but we do it everyday online. I don't know about you, but I'm comforted to know that every convenience store I visit doesn't have a store of all kinds of information about me in an account somewhere. Zero data stores less data that can be exploited by hackers (or the companies we trust with it).

The benefit of scale is obvious as well. In a zero data, zero trust scenario we don't have to have long-term transactional relationships with every store, movie, restaurant, and barber shop we visit. They don't have to maintain federation relationships with numerous identity providers. There are places where the ability to scale zero trust really matters. For example, it's impossible for every hospital to have a relationship with every other hospital for purposes of authorizing access for medical personal who move or need temporary access. Similarly, airline personal move between numerous airports and need access to various facilities at airports.

Finally, the integration burden with zero trust with zero data is much lower. The convenience store selling beer doesn't have to have an integration with any other system to check your ID. The attributes are self-contained in a tamper-evident package with built-in biometric authentication. Even more important, no legal agreement or prior coordination is needed. Lower integration burden reduces the prerequisites for implementing zero trust.

How do we build zero data, zero trust systems? By using verifiable credentials to transfer attributes about their subject in a way that is decentralized and yet trustworthy. Zero data aligns our online existence more closely with our real-world interactions, fostering new methods of communication while decreasing the challenges and risks associated with amassing, storing, and utilizing vast amounts of data.

Just-in-time, zero data, attribute transfer can make many zero trust scenarios more realizable because it's more flexible. Zero trust with zero data, facilitated by verifiable credentials, represents a pivotal transition in how digital identity is used in authorization decisions. By minimizing centralized data storage and emphasizing cryptographic verifiability, this approach aims to address the prevalent challenges in data management, security, and user trust. By allowing online interactions to more faithfully follow established patterns of transferring trust from the physical world, zero trust with zero data promotes better security with increased convenience and lower cost. What's not to like?

Photo Credit: We ID Everyone from DALL-E (Public Domain) DALL-E apparently thinks a six-pack has 8 bottles but this was the best of several attempts. Here's the prompt: Produce a photo-realistic image of a convenience store clerk. She's behind the counter and there's a six pack of beer on the counter. Behind her, clearly visible, is a sign that says "We I.D. Everyone" .