I got word early last week that Kim Cameron, a giant of the identity world, had passed away. I was shocked. I still am. Kim was one of those people who played such a big role in my life over so many years, that it's hard to imagine he's not there any more. The week before we'd been scheduled to talk and he'd canceled cause he wasn't feeling well. He wanted to talk about verifiable credential exchange over OpenID Connect SIOP. I guess we'll never get that last talk.
I had met Kim and talked to him at several identity conferences back in the early 2000's. But my relationship with him grew into friendship through Internet Identity Workshop (IIW). We held the first IIW in October 2005. Along with many others, Kim was there to talk about his ideas and plans for identity. He'd already published his Laws of Identity and was working on a project called Information Cards.
At that first IIW, we went to dinner at the end of day one. The idea was that everyone would pay for their own meal since the workshop hadn't collected any money in the registration for that. Kim, with his typical generosity, told everyone that Microsoft would buy dinner...and drinks. Later he confided to me that he wasn't sure Microsoft would really pick up the tab—which turned out to be surprisingly large because of the alcohol—but he'd make sure it was covered either way. That started a tradition. Microsoft has sponsored the workshop dinner at every in-person IIW we've held. Not only with dinner, but in countless other ways, Kim's participation and support was instrumental in building IIW over the years.
Over the last several years I've remarked several times that Kim must be a being from the future. With his laws, Kim was telling us things about identity in 2004 that we weren't ready to hear until just the last few years. Kim not only saw the need for a set of laws to govern online identity system architecture, but also foresaw the need for an identity metasystem on the internet. Whether you view the laws as leading to the metasystem design or springing from it, they are both necessary to a future where people can live rich, authentic online lives. The laws are Kim's legacy in the identity world.
Kim's technical excellence got him a seat at the table. His position at Microsoft gave him a big voice. But what made Kim effective was his gentle approach to technical discussions, especially those he thought might be contentious. He listened, asked questions, and guided discussion. As a result of his leadership we made progress in many ways that might not have otherwise happened. The identity world will sorely miss his leadership. I will miss his company, learning from him, and, most of all, his friendship.
Other tributes to Kim can be found in these links:
In a recent thread on the VRM mailing list, StJohn Deakins of Citizen Me shared a formulation of interactions that I thought was helpful in unpacking the discussions about data, identity, and ownership. His framework concerns analog vs digital memories.
In real life, we often interact with others—both people and institutions—with relative anonymity. For example, if I go the store and use cash to buy a coke there is no exchange of identity information. If I use a credit card it's rarely the case that the entire transaction happens under the administrative authority of the identity system inherent in the credit card. Only the financial part of the transaction takes place in that identity system. This is true of most interactions in real life.
In this situation, the cashier, others in the store, and I all share a common experience. Even so, we each retain our own memories of the interaction. No one participating would claim to "own" the interaction. But we all retain memories which are our own. There is no single "true" record of the interaction. Every participant will have a different perspective (literally).
On the other hand, the store, as an institution, retains a memory of having sold a coke and the credit card transaction. This digital memory of the transaction can easily persist longer than any of the analog memories of the event. Because it is a digital record we trust it and tend to think of it as "true." For some purposes, say proving in a court of law that I was in the store at a particular time, this is certainly true. But for other purposes (e.g. was the cashier friendly or rude?) the digital memory is woefully anemic.
Online, we only have digital memories. And people have very few tools for saving, managing, recalling, and using them. I think digital memories are one of the primary features of digital embodiment—giving people a place to stand in the digital world, their own perspective, memories, and capacity to act. We can't be peers online without having our own digital memories.
StJohn calls this the "analog-digital memory divide." This divide is one source of the power imbalance between people and administrative entities (i.e. anyone who has a record of you in an account). CitizenMe provides tools for people to manage digital memories. People retain their own digital memory of the event. While every participant has a similar digital memory of the event, they can all be different, reflecting different vantage points.
One of the recent trends in application development is microservices, with an attendant denormalization of data. The realization that there doesn't have to be, indeed often can't be, a single source of truth for data has freed application development from the strictures of centralization and led to more easily built and operated distributed applications that are resilient and scale. I think this same idea applies to digital interactions generally. Freeing ourselves from the mindset that digital systems can and should provide a single record that is "true" will lead to more autonomy and richer interactions.
Self-sovereign identity (SSI) provides a foundation for our digital personhood and allows us to not only taking charge of our digital memories but operationalize all of our digital relationships. Enriching the digital memories of events by allowing everyone their own perspective (i.e. making them self-sovereign) will lead to a digital world that is more like real life.
Ephemeral Relationships—Many of the relationships we have online don’t have to be long-lived. Ephemeral relationships, offering virtual anonymity, are technically possible without a loss of functionality or convenience. Why don’t they exist? Surveillance is profitable.
Fluid Multi-Pseudonymity—Fluid multi-pseudonymity perfectly describes the way we live our lives and the reality that identity systems must realize if we are to live authentically in the digital sphere.
Can the Digital Future Be Our Home?—This post features three fantastic books from three great, but quite different, authors on the subject of Big Tech, surveillance capitalism, and what's to be done about it.
Suppose Peggy needs to prove to Victor that she is in possession of a secret without revealing the secret. Can she do so in a way that convinces Victor that she really does know the secret? This is the question at the heart of one of the most powerful cryptographic processes we can employ in identity systems: zero-knowledge proofs (ZKPs). Suppose for example that Peggy has a digital driver's license and wants to prove to Victor, the bartender, that she's over 21 without just handing over her driver's license or even showing him her birthdate. ZKPs allow Peggy to prove her driver's license says she's at least 21 in a way that convinces Victor without Peggy having to reveal anything else (i.e., there's zero excess knowledge).
This problem was first explored by MIT researchers Shafi Goldwasser, Silvio Micali and Charles Rackoff in the 1980s as a way of combatting information leakage. The goal is to reduce the amount of extra information the verifier, Victor, can learn about the prover, Peggy.
One way to understand how ZKPs work is the story of the Cave of Alibaba, first published by cryptographers Quisquater, Guillou, and Berson1. The following diagram provides an illustration.
The Cave of Alibaba has two passages, labeled A and B, that split off a single passageway connected to the entrance. Peggy possesses a secret code that allows her to unlock a door connecting A and B. Victor wants to buy the code but won't pay until he's sure Peggy knows it. Peggy won't share it with Victor until he pays.
The algorithm for Peggy proving she knows the code proceeds as follows:
Victor stands outside the cave while Peggy enters and selects one of the passages. Victor is not allowed to see which path Peggy takes.
Victor enters the cave and calls out "A" or "B" at random.
Peggy emerges from the correct passageway because she can easily unlock the door regardless of which choice she made when entering.
Of course, Peggy could have just gotten lucky and guessed right, so Peggy and Victor repeat the experiment many times.
If Peggy can always come back by whichever passageway Victor selects, then there is an increasing probability that Peggy really knows the code. After 20 tries, there's less than one chance in a million that Peggy is simply guessing which letter Victor will call. This constitutes a probabilistic proof that Peggy knows the secret.
This algorithm not only allows Peggy to convince Victor she knows the code, but it does it in a way that ensures Victor can't convince anyone else Peggy knows the code. Suppose Victor records the entire transaction. The only thing an observer sees is Victor calling out letters and Peggy emerging from the right tunnel. The observer can't be sure Victor and Peggy didn't agree on a sequence of letters in advance to fool observers. Note that this property relies on the algorithm using a good pseudo-random number generator with a high-entropy seed so that Peggy and third-party observers can't predict Victor's choices.
Thus, while Peggy cannot deny to Victor that she knows the secret, she can deny that she knows the secret to other third parties. This ensures that anything she proves to Victor stays between them and Victor cannot leak it—at least in a cryptographic way that proves it came from Peggy. Peggy retains control of both her secret and the fact that she knows it.
When we say "zero knowledge" and talk about Victor learning nothing beyond the proposition in question, that's not perfectly true. In the cave of Alibaba, Peggy proves in zero knowledge that she knows the secret. But there are many other things that Victor learns about Peggy that ZKPs can do nothing about. For example, Victor knows that Peggy can hear him, speaks his language, walk, and is cooperative. He also might learn things about the cave, like approximately how long it takes to unlock the door. Peggy learns similar things about Victor. So, the reality is that the proof is approximately zero knowledge not perfectly zero knowledge.
The example of Alibaba's Cave is a very specific use of ZKPs, what's called a zero-knowledge proof of knowledge. Peggy is proving she knows (or possesses something). More generally, Peggy might want to prove many facts to Victor. These could include propositional phrases or even values. ZKPs can do that as well.
To understand how we can prove propositions in zero knowledge, consider a different example, sometimes called the Socialist Millionaire Problem. Suppose Peggy and Victor want to know if they're being paid a fair wage. Specifically, they want to know whether they are paid the same amount, but don't want to disclose their specific hourly rate to each other or even a trusted third party. In this instance, Peggy isn't proving she knows a secret, rather, she's proving an equality (or inequality) proposition.
For simplicity, assume that Peggy and Victor are being paid one of $10, $20, $30, or $40 per hour. The algorithm works like this:
Peggy buys four lock boxes and labels them $10, $20, $30, and $40.
She throws away the keys to every box except the one labeled with her wage.
Peggy gives all the locked boxes to Victor who privately puts a slip of paper with a "+" into the slot at the top of the box labeled with his salary. He puts a slip with a "-" in all the other boxes.
Victor gives the boxes back to Peggy who uses her key in private to open the box with her salary on it.
If she finds a "+" then they make the same amount. Otherwise, they make a different amount. She can use this to prove the fact to Victor.
This is called an oblivious transfer and proves the proposition VictorSalary = PeggySalary true or false in zero knowledge (i.e., without revealing any other information).
For this to work, Peggy and Victor must trust that the other will be forthcoming and state their real salary. Victor needs to trust that Peggy will throw away the three other keys. Peggy must trust that Victor will put only one slip with a "+" on it in the boxes.
Just like digital certificates need a PKI to establish confidence beyond what would be possible with self-issued certificates alone, ZKPs are more powerful in a system that allows Peggy and Victor to prove facts from things others say about them, not just what they say about themselves. For example, rather than Peggy and Victor self-asserting their salary, suppose they could rely on a signed document from the HR department in making their assertion so that both know that the other is stating their true salary. Verifiable Credentials provide a system for using ZKPs to prove many different facts alone or in concert, in ways that give confidence in the method and trust in the data.
In the previous examples, Peggy was able to prove things to Victor through a series of interactions. For ZKPs to be practical, interactions between the prover and the verifier should be minimal. Fortunately, a technique called SNARK allows for non-interactive zero knowledge proofs.
SNARKs have the following properties (from whence they derive their name):
Succinct: the sizes of the messages are small compared to the length of the actual proof.
Non-interactive: other than some setup, the prover sends only one message to the verifier.
ARguments: this is really an argument that something is correct, not a proof as we understand it mathematically. Specifically, the prover theoretically could prove false statements given enough computational power. So, SNARKs are "computationally sound" rather than "perfectly sound".
of Knowledge: the prover knows the fact in question.
You'll typically see "zk" (for zero-knowledge) tacked on the front to indicate that during this process, the verifier learns nothing other than the facts being proved.
The mathematics underlying zkSNARKs involves homomorphic computation over high-degree polynomials. But we can understand how zkSNARKs work without knowing the underlying mathematics that ensures that they're sound. If you'd like more details of the mathematics, I recommend Christian Reitwiessner's "zkSNARKs in a Nutshell".
As a simple example, suppose Victor is given a sha256 hash, H, of some value. Peggy wants to prove that she knows a value s such that sha265(s) == H without revealing s to Victor. We can define a function C that captures the relationship:
C(x, w) = ( sha256(w) == x )
So, C(H, s) == true, while other values for w will return false.
Computing a zkSNARK requires three functions G, P, and V. G is the key generator that takes a secret parameter called lambda and the function C and generates two public keys, the proving key pk and the verification key vk. They need only be generated once for a given function C. The parameter lambda must be destroyed after this step since it is not needed again and anyone who has it can generate fake proofs.
The prover function P takes as input the proving key pk, a public input x, and a private (secret) witness w. The result of executing P(pk,x,w) is a proof, prf, that the prover knows a value for w that satisfies C.
The verifier function V computes V(vk, x, prf) which is true if the proof prf is correct and false otherwise.
Returning to Peggy and Victor, Victor chooses a function C representing what he wants Peggy to prove, creates a random number lambda, and runs G to generate the proving and verification keys:
(pk, vk) = G(C, lambda)
Peggy must not learn the value of lambda. Victor shares C, pk, and vk with Peggy.
Peggy wants to prove she knows the value s that satisfies C for x = H. She runs the proving function P using these values as inputs:
prf = P(pk, H, s)
Peggy presents the proof prf to Victor who runs the verification function:
V(vk, H, prf)
If the result is true, then the Victor can be assured that Peggy knows the value s.
The function C does not need to be limited to a hash as we did in this example. Within limits of the underlying mathematics, C can be quite complicated and involve any number of values that Victor would like Peggy to prove, all at one time.
Quisquater, Jean-Jacques; Guillou, Louis C.; Berson, Thomas A. (1990). How to Explain Zero-Knowledge Protocols to Your Children (PDF). Advances in Cryptology – CRYPTO '89: Proceedings. Lecture Notes in Computer Science. 435. pp. 628–631. doi:10.1007/0-387-34805-0_60. ISBN 978-0-387-97317-3.
The other day Lynne called me up and asked a seemingly innocuous question: "How do I share this video?" Ten years ago, the answer would have been easy: copy the URL and send it to them. Now...not so much. In order to answer that question I first had to determine which app she was using. And, since I wasn't that familiar with it, open it and search through the user interface to find the share button.
One of the features of web browsers that we don't appreciate as much as we should is the consistent user experience that the browser provides. Tabs, address bars, the back button, reloading and other features are largely the same regardless of which browser you use. There's a reason why don't break the back button! was a common tip for web designers over the years. People depend on the web's consistent user experience.
Alas, apps have changed all that. Apps freed developers from the strictures of the web. No doubt there's been some excellent uses of this freedom, but what we've lost is consistency in core user experiences. That's unfortunate.
The web, and the internet for that matter, never had a consistent user experience for authentication. At least not one that caught on. Consequently, the user experience is very fragmented. Even so, Kim Cameron's Seven Laws of Identity speaks for consistent user experience in Law 7: Consistent Experience Across Contexts. Kim says:
The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
Think about logging into various websites and apps throughout your day. You probably do it way too often. But it's also made much more complex because it's slightly different everywhere. Different locations and modalities, different rules for passwords, different methods for 2FA, and so on. It's maddening.
There's a saying in security: "Don't roll your own crypto." I think we need a corollary in identity: "Don't roll your own interface." But how do we do that? And what should the interface be? One answer is to adopt the user experience people already understand from the physical world: connections and credentials.
Kim Cameron gave us a model back in 2005 when he introduced Information Cards. Information cards are digital analogs of the credentials we all carry around in the physical world. People understand credentials. Information cards worked on a protocol-mediated identity metasystem so that anyone could use them and write software for them.
Information cards didn't make it, but the ideas underlying information cards live on in modern self-sovereign identity (SSI) systems. The user experience in SSI springs from the protocol embodied in the identity metasystem. In an SSI system, people use wallets that manage connections and credentials. They can create relationships with other people, organizations, and things. And they receive credentials from other participants and present those credentials to transfer information about themselves in a trustworthy manner. They don't see keys, passwords, authentication codes, and other artifacts of the ad hoc identity systems in widespread use today. Rather they use familiar artifacts to interact with others in ways that feel familiar because they are similar to how identity works in the physical world.
This idea feels simple and obvious, but I think that conceals its incredible power. Having a wallet I control where I manage digital relationships and credentials gives me a place to stand in the digital world and operationalize my digital life. I think of it as digital embodiment. An SSI wallet gives me an interoperable way to connect and interact with others online as me. I can create both rich, long-lived relationships and service short-lived, ephemeral relationships with whatever degree of trustworthy data is appropriate for the relationship and its context.
We have plenty of online relationships today, 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. Consistent user experience is a key enabler of digital embodiment. When we dine at a restaurant or shop at a store in the physical world, we do not do so within some administrative system. Rather, as embodied agents, we operationalize our relationships, whether they be long-lived or nascent, by acting for ourselves. The SSI wallet is the platform upon which people can stand and become embodied online to operationalize their digital life as full-fledged participants in the digital realm.
Rainbow's End is one of my favorite books. A work of fiction, Rainbow's End imagines life in a near future world where augmented reality and pervasive IoT technology are the fabric within which people live their lives. This book, from 2006, is perhaps where I first began to understand the nature and importance of computing at the edge. A world where computing is ambient and immersive can't rely only on computers in the cloud.
We have significant edge computing now in the form of powerful mobile devices, but that computing is not shared without roundtrips to centralized cloud computing. One of the key components of 5G technology is compute and storage at the edge—on the cell towers themselves— that distributes computing and reduces latency. Akamai, CloudFront, and others have provided these services for years, but still in a data center somewhere. 5G moves it right to the pole in your backyard.
But the vision I've had since reading Rainbow's End is not just distributed, but decentralized, edge computing. Imagine your persistent compute jobs in interoperable containers moving around a mesh of compute engines that live on phones, laptops, servers, or anywhere else where spare cycles exist.
IPFS does this for storage, decentralizing file storage by putting files in shared spaces at the edge. With IPFS, people act as user-operators to host and receive content in a peer-to-peer manner. If a file gets more popular, IPFS attempts to store it in more places and closer to the need.
"title": "The IPFS Address",
"body": "<p>If I go here:</p><p><a href=\"https://ipfs.io/ipfs/
My vision for picos is that they can operate on a decentralized mesh of pico engines in a similar decentralized fashion. Picos are already encapsulations of computation with isolated state and programs that control their operation. There are two primary problems with the current pico engine that have to be addressed to make picos independent of the underlying engine:
Picos are addressed by URL, so the pico engine's host name or IP address becomes part of the pico's address
Picos have a persistence layer that is currently provided by the engine the pico is hosted on.
The first problem is solvable using DIDs and DIDComm. We've made progress in this area. You can create and use DIDs in a pico. But they are not, yet, the primary means of addressing and communicating with the pico.
The second problem could be addressed with IPFS. We've not done any work in this area yet. So I'm not aware of the pitfalls or problems, but it looks doable.
With these two architectural issues out of the way, implementing a way for picos to move easily between engines would be straightforward. We have import and export functionality already. I'm envisioning something that picos could control themselves, on demand, programatically. Ultimately, I want the pico to chose where it's hosted based on whatever factors the owner or programmer deems most important. That could be hosting cost, latency, availability, capacity, or other factors. The decentralized directory to discover engines advertising certain features or factors, and a means to pay them would have to be built—possibly as a smart contract.
A trickier problem is protecting picos from malevolent engines. This is the hardest problem, as far as I can tell. Initially, collections of trusted engines, possibly using staking, could be used.
There are plenty of fun, interesting problems if you'd like to help.
If you're intrigued and want to get started with picos, there's a Quickstart along with a series of lessons. If you need help, contact me and we'll get you added to the Picolabs Slack. We'd love to help you use picos for your next distributed application.
The information revolution of the past thirty years blossoms into a web of conspiracies that could destroy Western civilisation. At the centre of the action is Robert Gu, a former Alzheimer's victim who has regained his mental and physical health through radical new therapies, and his family. His son and daughter-in-law are both in the military - but not a military we would recognise - while his middle school-age granddaughter is involved in perhaps the most dangerous game of all, with people and forces more powerful than she or her parents can imagine.
For Account-based identity, you need to be sure of the identity of the account holder (the User ID / Password of your Facebook-account, your company-network, etc.). For Token-based identity (Certified claim about your age for example) you need a certified claim about an attribute of that identity.
In other words, while account-based identity focuses on linking a person in possession of authentication factors to a trove of information, token-based identity is focused on claims about the subject's attributes. More succinctly: account-based identity focuses on who you are whereas token-based identity is focused on what you are.
One of my favorite scenarios for exploring this is meeting a friend for lunch. You arrive at the restaurant on time and she’s nowhere to be found. You go to the hostess to inquire about the reservation. She tells you that your reservation is correct, and your friend is already there. She escorts you to the table where you greet your friend. You are seated and the hostess leaves you with a menu. Within a few moments, the waitress arrives to take your order. You ask a few questions about different dishes. You both settle on your order and the waitress leaves to communicate with the kitchen. You happily settle in to chat with your friend, while your food is being prepared. Later you might get a refill on a drink, order dessert, and eventually pay.
While you, your friend, the host, and waitstaff recognized, remembered, and interacted with people, places, and things countless times during this scenario, at no time were you required to be identified as a particular person. Even paying with a credit card doesn't require that. Credit cards are a token-based identity system that says something about you rather than who you are. And while you do have an account with your bank, the brilliance of the credit card is that you no longer have to have accounts with every place you want credit. You simply present a token that gives the merchant confidence that they will be paid. Here are a few of the "whats" in this scenario:
The person sitting at table 3
Guest who ordered the medium-rare steak
Someone who needs a refill
Person who owes $179.35
Person in possession of a MasterCard
You don't need an account at the restaurant for any of this to work. But you do need relationships. Some, like the relationship with your friend and MasterCard, are long-lived and identified. Most are ephemeral and pseudonymous. While the server at the restaurant certainly "identifies" patrons, they usually forget them as soon as the transaction is complete. And the identification is usually pseudonymous (e.g. "the couple at table three" rather than "Phillip and Lynne Windley").
In the digital realm, we suffer from the problem of not being in proximity to those we're interacting with. As a result, we need a technical means to establish a relationship. Traditionally, we've done that with accounts and identifying, using authentication factors, who is connecting. As a result, all online relationships tend to be long-lived and identified in important ways—even when they don't need to be. This has been a boon to surveillance capitalism.
Account- and token-based identity are not mutually exclusive. In fact, token-based identity often has its roots in an account somewhere, as we discovered about MasterCard. But the key is that you're leveraging that account to avoid being in an administrative relationship in other places. To see that, consider the interactions that happen after an automobile accident.
In this scenario, two drivers, Alice and Bob, have had an accident. The highway patrol has come to the scene to make an accident report. Both Alice and Bob have a number of credentials (tokens) in their digital wallets that they control and will be important in creating the report:
Proof of insurance issued by their respective insurance companies
Vehicle title issued by the state founded on a vehicle original document from the vehicle's manufacturer.
Vehicle registration issued by the Department of Motor Vehicles (DMV)
Driver's license issued by the Department of Public Safety (DPS) in Alice's case and the DMV in Bob's
In addition, the patrol officer has a badge from the Highway Patrol.
Each of these credentials is the fruit of an account of some kind (i.e. the person was identified as part of the process). But the fact that Alice, Bob, and the patrol officer have tokens of one sort or another that stem from those accounts allows them to act autonomously from those administrative systems to participate in a complex, ad hoc, cross-domain workflow that will play out over the course of days or weeks.
Account-based and token-based identity system co-exist in any sufficiently complex ecosystem. Self-sovereign identity (SSI) doesn't replace administrative identity systems, it gives us another tool that enables better privacy, more flexible interactions, and increased autonomy. In the automobile scenario, for example, Alice and Bob will have an ephemeral relationship that lasts a few weeks. They'll likely never see the patrol officer after the initial encounter. Alice and Bob would make and sign statements that everyone would like to have confidence in. The police officer would create an accident report. All of this is so complex and unique that it is unlikely to ever happen within a single administrative identity system or on some kind of platform.
Token-based identity allows people to operationalize their digital lives by supporting online interactions that are multi-source, fluid multi-pseudonymous, and decentralized. Ensuring that the token-based identity system is also self-sovereign ensures that people can act autonomously without being within someone else's administrative identity system as they go about their online lives. I think of it as digital embodiment—giving people a way to be peers with other actors in online interactions.
I'm using "token" in the general sense here. I'm not referring to either cryptocurrency or hardware authentication devices specifically.
Photo Credit: Tickets from Clint Hilbert (Pixabay)
Each Kitty is distinguishable from all the rest and has a unique identity and existence
Each kitty is owned by someone. Specifically, it is controlled by whoever has the private keys associated with the address that the kitty is tied to.
This is a good description of the properties of NFTs in general. Notice that nothing here says that NFTs have to be about art, or collectibles, although that's the primary use case right now that's generating so much hype. Cryptokitties were more interesting than most of the NFT use cases right now because the smart contract allowed them to be remixed to produce new kitties (for a fee).
Suppose I rewrote the quote from my post on Cryptokitties like this:
[E]ach verifiable credential (VC) has some interesting properties:
Each VC is distinguishable from all the rest and has a unique identity and existence
Each VC is owned by someone. Specifically, it is controlled by whoever has the private keys associated with the address that the VC was issued to.
Interesting, no? So, if these properties are true for both NFTs and verifiable credentials, what's the difference? The primary difference is that right now, we envision VC issuers to be institutions, like the DMV, your bank, or employer. And institutions are centralized. In contrast, because NFTs are created using a smart contract on the Ethereum blockchain, we think of them as decentralized. But, not so fast. As I noted in my post on Cryptokitties, you can't assume an NFT is decentralized without examining the smart contract.
There is one problem with CryptoKitties as a model of self-sovereignty: the CryptoKitty smart contract has a "pause" function that can be executed by certain addresses. This is probably a protection against bugs—no one wants to be the next theDAO—but it does provide someone besides the owner with a way to shut it all down.
I have no idea who that someone is and can't hold them responsible for their behavior—I'd guess it's someone connected with CryptoKitties. Whoever has control of these special addresses could shutdown the entire enterprise. I do not believe, based on the contract structure, that they could take away individual kitties; it's an all or nothing proposition. Since they charged money for setting this up, there's likely some contract law that could be used for recourse.
So, without looking at the code for the smart contract, it's hard to say that a particular NFT is decentralized or not. They may be just as centralized as your bank1.
To examine this more closely, let's look at a property title, like a car title, as an example. The DMV could decide to issue car titles as verifiable credentials tomorrow. And the infrastructure to support it is all there: well-supported open source code, companies to provide issuing software and wallets, and specifications and protocols for interoperability2. Nothing has to change politically for that to happen.
The DMV could also issue car titles as NFTs. With an NFT, I'd prove I own the car by exercising control over the private key that controls the NFT representing the car title. The state might do this to provide more automation for car transfers. Here too, they'd have to find an infrastructure provider to help them, ensure they had a usable wallet to store the title, and interact with the smart contract. I don't know how interoperable this would be.
One of the key features of an NFT is that they can be transfered between owners or controllers. Verifiable credentials, because of their core use cases are not designed to be transferred, rather they are revoked and reissued.
Suppose I want to sell the car. With a verifiable credential, the state would still be there, revoking the VC representing my title to the car and issuing a new VC to the buyer when the title transfers. The record of who owns what is still the database at the DMV. With NFTs we can get rid of that database. So, selling my car now becomes something that might happen in a decentralized way, without the state as an intermediary. Note that they could do this and still retain a regulatory interest in car titling if they control the smart contract.
But, the real value of issuing a car title as an NFT would be if it were done using a smart contract in a way that decentralized car titles. If you imagine a world of self-driving cars that own and sell themselves, then that's interesting. You could also imagine that we want to remove the DMV from the business of titling cars altogether. That's a big political lift, but if you dream of a world with much smaller government, then NFT-based car titles might be a way to do that. But I think it's a ways off. So, we could use NFTs for car titles, but right now there's not much point besides the automation.
You can also imagine a much more decentralized future for verifiable credentials. There's no reason a smart contract couldn't issue and revoke verifiable credentials according to rules embodied in the code. Sphereon has an integration between verifiable credentials and the Digital Assets Markup Language (DAML), a smart contract language. Again, how decentralized the application is depends on the smart contract, but decentralized, institution-independent verifiable credentials are possible.
have a wallet that holds and exchanges NFTs and credentials according to the rules encapsulated in the pico.
be programmed to interact with the smart contract for an NFT to perform the legal operations.
be programmed to receive, hold, and present verifiable credentials according to the proper DIDCommm protocols.3
NFTs are currently in their awkward, Pets.com stage. Way too much hype and many myopic use cases. But I think they'll grow to have valuable uses in creating more decentralized, trustworthy data objects. If you listen to the reality 2.0 podcast starting about 56 minutes, Greg, Katherine, and Doc get into some of those. Greg's starting with games—a good place, I think. Supply chain is another promising area. If you need decentralized, automated, trustworthy, persistent data containers, then NFTs fit the bill.
People who live in a country with a strong commitment to the rule of law, might ask why decentralizing things like titles and supply chains is a good idea. But that's not everyone's reality. Blockchains and NFTs can inspire confidence in systems that would otherwise be too costly or untrustworthy otherwise. Picos are a great way to create distributed systems of entity-oriented compute nodes that are capable of using PDOs.
Note that I'm not saying that Cryptokitties is as centralized as your bank. Just that without looking at the code, you can't tell.
Yeah, I know that interop is still a work in progress. But at least it's in progress, not ignored.
These are not capabilities that picos presently have, but they do support DIDComm messaging. Want to help add these to picos? Contact me.
I traveled to Munich for European Identity Conference several weeks ago—my first international trip since before the pandemic. Post-pandemic travel can be confusing, international travel even more so. To get into Germany, I needed to prove I had been vaccinated. To get back in the US, I had to show evidence of a negative Covid-19 test conducted no more than three days prior to my arrival in the US. Figuring out how to present these, which forms to fill out, and who cared led to a bit of stress.
Once in Munich, venturing out of the hotel had its own surprises. Germany, or maybe just Munich, has implemented a contract tracing system. Apparently there's one or more apps you can use, but I had a tough time figuring that out. Restaurants were spotty in their demands and enforcement. After showing them my US vaccination card, one small place just threw up their hands and said "just come in and eat!"
You'd think all this would have been a perfect opportunity for me to use a health pass app, but whose? None of the ones I knew about had a way for me to get my vaccination status into them. Delta airlines didn't accept any that I could tell. Munich has its own—or three. In short, it's an interoperability nightmare.
Apple recently announced that you can store your Covid-19 vaccination card in the Health app. And soon you'll be able to put it in the phone's wallet app. Android users have similar options. But there's also hundreds (really) of apps for doing the same thing and each has its own tiny ecosystem. PC Magazine even wrote a guide with every US state's chosen app.
[Interoperability] is the better way. Instead of enshrining Google, Facebook, Amazon, Apple, and Microsoft as the Internet's permanent overlords and then striving to make them as benign as possible, we can fix the Internet by making Big Tech less central to its future.
It's possible that people will connect tools to their BigTech accounts that do ill-advised things they come to regret. That is kind of the point, really. After all, people can plug weird things into their car's lighter receptacles, but the world is a better place when you get to decide how to use that useful, versatile ANSI/SAE J56-compliant plug—not GM or Toyota.
By enforcing interoperability, we avoid empowering Apple, Google, or anyone else as the sole trusted repositories of health data and then hoping they'll not only do the right thing, but also have all the best ideas. We can let the hundreds of Covid-19 health pass apps thrive (or not), secure in the knowledge that people can pick the app they like from a company they trust and still have it work when they travel across borders—or just across town.
People with decision making authority can help this process by choosing the interoperable solution and avoiding closed, proprietary technology. Why are organizations like NASCIO (National Association of State CIOs), for example, not doing more to help states find, chose, and use interoperable solutions to common state IT problems? Beyond health pass applications, things like mobile drivers licenses need to be interoperable to be useful.
In Health Passes and the Design of an Ecosystem of Ecosystems, I wrote about efforts to create interoperable health passes on principles that respect individual privacy and autonomy. Those efforts have created real apps, with real interoperability. But too many decision makers jettison interoperability in search of profit, dominance, or simply time to market. The lesson of the internet was not that it was the cheapest, easiest way to build global network. We had CompuServe for that. The lesson of the internet was that it was the best way to build a network that was generative and provided the most utility for the greatest number of people. Interoperability was the key—and still is.
JSON is robot barf. Don't get me wrong. JSON is a fine serialization format for data and I have no problem with it in that context. My beef is with the use of JSON for configuration files, policy specs, and so on. If JSON were all we had, then we'd have to live with it. But we've been building parsers for almost 70 years now. The technology is well understood. There are multiple libraries in every language for parsing. And yet, even very mature, well supported frameworks and platforms persist in using JSON instead of a human-friendly notation.
When a system requires programmers to use JSON, what they're effectively asking developers to use an "abstract" syntax instead of a "concrete" syntax. Here's what I mean. This is a function definition in concrete syntax:
And here's the same function definition expressed as an abstract syntax tree (AST) serialized as JSON:
I don't know any programmer who'd prefer to write the abstract syntax instead of the concrete. Can you imagine an entire program expressed like that? Virtually unreadable and definitely not maintainable. Parsing can take as much as 20% of the time taken to compile code, so there's a clear performance win in using abstract syntax over concrete, but even so we, correctly, let the machine do the work.
I get that systems often start out simply with simple configuration. Some inputs are just hierarchies of data. But that often gets more complicated over time. And spending time figuring out the parser when you're excited to just get it working can feel like a burden. But taking the shortcut of making developers and others write the configuration in abstract syntax instead of letting the computer do the work is a mistake.
I'd like to say that the problem is that not enough programmers have a proper CS education, but I fear that's not true. I suspect that even people who've studied CS aren't comfortable with parsing and developing notations. Maybe it's because we treat the subject too esoterically—seemingly useful for people designing a programming language, but not much else. And students pick up on that and figure this is something, like calculus, they're unlikely to ever use IRL. What if programming langauge classes helped students learn the joy and benefit of building little languages instead?
I'm a big believer in the power of notation. And I think we too often shy away from designing the right notation for the job. As I wrote about Domain Specific Languages (DSLs) in 2007:
I'm in the middle of reading Walter Isaacson's new biography of Einstein. It's clear that notation played a major role in his ability to come up with the principle of general relativity. He demurred at first, believing that the math was for someone else to come along later and tidy up. But later in his life, after the experience of working on general relativity, Einstein became an ardent convert.
Similarly, there is power in notation for computing tasks. Not merely the advantage of parameterized execution but in it's ability to allow us to think about problems, express them so that other's can clearly and unambiguously see our thoughts, and collaborate to create joint solutions. What's more, languages can be versioned. GUI configurations are hard to version. Notation has advantages even when it's not executed.
The DSL becomes the focal point for design activities. The other day, I was having a discussion with three friends about a particular feature. Pulling out pencil and paper and writing what the DSL would need to look like to support the feature helped all of us focus and come up with solutions. Without such a tool, I'm not sure how we would have communicated the issues or whether we'd have all had the same conception of them and the ultimate solution we reached.
As this points out, clear notations have advantages beyond being easier to write and understand. They also provide the means to easily share and think about the problem. I think system designers would be better off if we spent more time thinking about the notation developers will use when they configure and use our systems, making it clear and easy to read and write. Good notation is a thinking tool, not just a way to control the system. The result will be increased expressiveness, design leverage, and freedom.
I have a Philips Sonicare toothbrush. One of the features is a little yellow light that comes on to tell me that the head needs to be changed. The first time the light came on, I wondered how I would reset it once I got a new toothbrush head. I even googled it to find out.
Turns out I needn't have bothered. Once I changed the head the light went off. This didn't happen when I just removed the old head and put it back on. The toothbrush heads have a unique identity that the toothbrush recognizes. This identity is not only used to signal head replacement, but also to put the toothbrush into different modes based on the type of head installed.
Philips calls this BrushSync, but it's just RFID technology underneath the branding. Each head has an RFID chip embedded in it and the toothbrush body reads the data off the head and adjusts its internal state in the appropriate way.
I like this use case RFID because it's got clear benefits for both Philips and their customers. Philips sells more toothbrush heads—so the internet of things (IoT) use case is clearly aligned with business goals. Customers get reminders to replace their toothbrush head and can reset the reminder by simply doing what they'd do anyway—switch the head
There aren't many privacy concerns at present. But as more and more products include RFID chips, you could imagine scanners on garbage trucks that correlate what gets used and thrown out with an address. I guess we need garbage cans that can disable RFID chips when they're thrown away.
I was recently talking to a friend of mine, Eric Olafson, who is a founding investor in Riot. Riot is another example of how thoughtfully applied RFID-based identifiers can solve business and customer problems. Riot creates tech that companies can use for RFID-based, in-store inventory management. This solves a big problem for stores that often don't know what inventory they have on hand. With Riot, a quick scan of the store each morning updates the inventory management system, showing where the inventory data is out of sync with the physical inventory. As more and more of us go to the physical store because the app told us they had the product we wanted, it's nice to know the app isn't lying. Riot puts the RFID on the tag, not the clothing, dealing with many of the privacy concerns.
Both BrushSync and Riot use identity to solve business problems, showing'that unique identifiers on individual products can be good for business and customers alike. This speaks to the breadth of identity and its importance in areas beyond associating identifiers with people. I've noticed an uptick in discussions at IIW about identity for things and the impact that can have. The next IIW is Oct 12-14—online—join us if you're interested.