0:00 So we start off today with Sam who's going to first talk about the state and the
0:04 future of the KERI suite. All right. Thank you. You guys.
0:12 And since we're recording, if you want to ask a question, we'll pass around the mic
0:17 so that your question gets on the recording. We have a couple of mics. So I
0:22 recognize most of the people here, but there's some that I don't. So is there
0:26 anybody here that has never heard of KERI before other than to come to this
0:30 conference. Okay. Everybody's heard of KERI. Is there anybody here that just
0:35 really doesn't know that much about KERI? Oh, come on. All right. So a couple. Okay.
0:43 So KERI is sometimes described as complicated and I like to say it's no more
0:52 complicated than it has to be to achieve the properties that it provides. It's
0:58 designed to be minimally sufficient to achieve those properties. But those
1:02 properties are significant and difficult to achieve. So if
1:16 something is confusing or something like that, part of this conference is to try to
1:23 explain those things. The KERI Foundation has been publishing videos of a lot of the
1:32 talks. So we now have a fairly big set of videos that you can go watch and learn
1:38 from. And every time we do a presentation or a mini conference, we're attempting to
1:44 add to that corpus of knowledge there. So I want to talk a little bit about KERI.
1:54 2026, we think is a milestone year for KERI and ACDC and the KERI suite of
2:00 standards and there's some reasons for that. Some things that have already
2:04 happened this year. We first had the suite of protocols released as a Linux
2:10 Foundation set of standards. We finalized the specs. It took several years to get to
2:15 that point and some of the people that were instrumental in getting there are
2:20 here today. So thanks for all that. The KERI Foundation was founded in 2025, but
2:26 we received funding, both private and public funding to start building open
2:35 infrastructure for KERI. We got a grant from the state of Utah Governor's Office
2:40 of Economic Opportunity. The telecom industry is using KERI and ACDC to stop
2:51 call spam. There is something called the Open Verify Communications Alliance and
2:57 And that is functionally
3:01 in production. So Microsoft has gone public and announced that they're using a
3:12 software stack developed by company called Provenant to solve call spam. And so
3:16 that's just growing organically that eventually call spam will be a thing of
3:23 the past. Five years from now, people won't be complaining about call spam.
3:27 Yeah, that's how significant that is. And that includes text as well. It's going to
3:31 go into text. The Utah State passed a legislation, Senate Bill 260, that
3:38 implements what's called state-endorsed digital identity. That's a first. No one's
3:44 ever done that before. It passed both houses unanimously. So it's a significant
3:50 achievement. Lots of states have been trying to do various forms of digital
3:55 identity and have been unsuccessful. The reason Utah State's passed is because the
4:02 digital identity was based on constitutional principles as opposed to
4:07 other principles. So, some other things. There's a vital initiative in the
4:14 healthcare industry and actually that's now deepened GLEIF and DirectTrust. So,
4:21 DirectTrust is the organization that vets health information service providers and
4:27 also certifies certificate authorities and that issues certificates and identities in
4:34 the healthcare industry. They are going to issue, they are going to become a
4:39 qualified VLEI issuer. I can't… – Qualification agent. – Qualification
4:44 agent, which will then qualify
4:49 qualified VLA issuers. So this is an example of deepening and extending the
4:56 organizational density root of trust that GLEIF provides that was the early adopter
5:01 of KERI now to a sector that is the largest single market sector in the United
5:07 States, the healthcare sector. So and they've done some proof of concepts pilot
5:12 projects and now have large payers like CVS I don't know if you know how big CVS
5:19 is, but revenue is the same size as Microsoft. It's not worth as much as
5:22 Microsoft because it's not a high-tech company, but that's how big it is. It's
5:26 now starting to use that to connect payers to payers and participants in the
5:35 healthcare industry. There was a summit earlier this spring at Utah State where a
5:41 significant amount of intention was drawn to the SEDI project. We had the first ever
5:46 KERI conference. Some of you attended it. You'll see some of those who didn't attend
5:52 it, you'll get some of what was at that conference today, much reduced because the
5:59 KERI conference was two days with multiple tracks. This is one day with one track. We
6:04 released open source infrastructure, witnesses, watchers, and wallets and
6:08 continue to develop those. And I think and we'll be shortly releasing observers and
6:14 registrars. So this is the KERI MiniConf. And in two weeks in Utah will be the fall
6:22 SEDI Summit, which will have about 250 participants. And there is an anticipation
6:29 that there will be multiple states that will announce their participation in a
6:35 multi-state SEDI consortium. So those are significant things that have happened just
6:40 in 2026. So 2027 looks to be even better. So to give you a little bit of history,
6:49 from my perspective, the journey down this KERI Suite path started for me back in
6:57 2013 and 2014 when I developed an open source, end-to-end encrypted and signed
7:05 communications protocol called RATE, Reliable Asynchronous Event Transport. The
7:12 insight that I learned from the development process is the key management
7:17 was the problem. I could do all sorts of things, but the key management was always
7:23 a sticky thing that I like, you know, we didn't really work. The key management, if
7:28 the key management is not done right, it doesn't matter anything else we do. The
7:32 protocol will fail. I then worked on something called the open reputation
7:37 system, published a couple of white papers, and that's where I identified that
7:42 persistent identity was the hard problem of identity. People were building and
7:48 people still do. Most of identity is not are not persistent or perpetual
7:52 identities. They're ephemeral identities and it's easy to build ephemeral identity.
7:57 It's really really hard to build persistent identity. I didn't know how to
8:00 build it. I knew that I needed to build it and so I started down that path. And then
8:07 I started publishing some white papers as part of Evernym and the Sovereign
8:12 Foundation on this path to perpetual identity. So that takes us to 2016, 2017,
8:23 I call it the era of the ledger wars. Everybody decided that digital identity
8:27 based on blockchain was the coolest thing. And one of the things that blockchain does
8:33 is it does give you a form of perpetual identity. You can put the key state on the
8:38 blockchain so that you can maintain control over an identifier indefinitely
8:43 using the blockchain as your root of trust. The problem is everybody had their
8:48 own ledger and everybody wanted that identity be on their ledger. And as great
8:54 as the idea of Sovereign was, and we have founders of Sovereign here, everybody
9:03 said, well, it's too great an idea. We don't just want one ledger for identity.
9:08 We want every ledger to have their own identity. And that meant that you didn't
9:11 have interoperability. You didn't have the problem and just created a host of new
9:16 problems. And those are all governance problems. So I call that the ledger war
9:21 period. And I have lots of scars from that war because I spent several years fighting
9:28 that war and actually GLEIF adopted KERI because they fought that war and they
9:37 retreated off from the battlefield and said, we don't want to be on that
9:40 battlefield. We want a ledger agnostic approach to identity. And so, you know, we
9:47 have it here and we have, you know, Phil's here too. I pointed out Timothy, but Phil
9:51 was the founding chairman of Sovereign. So we have some of the original ones there.
9:58 So the result of that was that in 2018, they started developing, actually solving
10:06 the problem that identified years before, which is the hard problem, which is key
10:10 management. And so wrote a white paper on fault tolerant key
10:18 rotation. And then started looking at building ACDCs with… if you had perpetual
10:28 identity, then you could have perpetually verifiable issuances and ACDCs did that.
10:33 And published the first KERI white paper in 2019. The core result of that white
10:39 paper was you did need blockchain to have perpetual identity. You could do it
10:43 securely without a blockchain. And that was a heretical concept at the time. I
10:47 remember every time I talked about that, the blockchain bros would beat me up and
10:51 just say, no, no, no, you got to have a blockchain, right? So I fought, I have a
10:56 lot of battles from that fight, right? And then after a year of having the paper in
11:01 the wild and getting lots of feedback and finding all the mistakes and bad things, I
11:06 revised it and came out with version two, which is essentially what KERI is today.
11:10 There have been more incremental improvements since 2020, but the core KERI
11:17 idea hasn't changed much since the version 2 white paper. And the version 2 white
11:22 paper went through multiple iterations over the period of the next couple of
11:27 years, but they were small things. Quantum Secure DIDs was a paper published in 2020,
11:33 which is how we solve the the ability
11:39 to basically be protected from surprise quantum attacks. So that provides surprise
11:47 quantum attack protection, which means that we've pre-migrated KERI identifiers
11:52 today are pre-migrated to be protected so that you can migrate to post-quantum
11:58 secure things, but your existing identity is protected from a surprise quantum
12:05 attack. In 2020, late 2020, GLEIF work began. In 2020, published a white paper on
12:13 universal identifier theory which talked about how you solve organizational
12:18 identity with KERI.
12:23 We started the trusted RIP task force for ACDCs in 2020. So a lot of these protocols
12:29 got started in that day. And then in 2022, GLEIF VLEI went into production. So that
12:35 was the origination of it. And then since then in 2023, I wrote a white paper called
12:44 SPAC, which has now resulted in the trust spanning protocol. And we have Wenjing,
12:49 the co-author there, and it's now in final draft. We voted on it, right? So it should
12:54 go to spec. So this is the fourth spec in the suite of protocols. Although usually
13:04 you don't think of a trust spanning protocol as a KERI suite of protocol, but
13:07 it solves the communication
13:13 metadata surveillance problem, which is what you need to start using some of these
13:20 things in different applications. 2023, as I mentioned, SEDI work begins. And so it
13:29 took three years. I was I was appointed to the Utah State Privacy Commission back in
13:37 2023, and we spent time trying to figure out how to get legislation through the
13:43 system. So it wasn't an overnight thing. It's not like in January of 2026, some
13:49 legislators showed up and said, well, I have a bill. It's called SEDI. Let's vote
13:52 on it, right? That's a result of three years work of setting up the legislation.
13:58 And there are other people in the room that were that were essential in doing
14:04 that. And then 2023 is part of that work I wrote a white paper on sustainable
14:08 privacy. And then we formed the trust RIP KERI Suite Working Group to get the specs
14:13 finalized. The Cardano Foundation adopted KERIs. We have some of the Cardano. Well,
14:18 I guess they're Veridian now, right? Yeah. So, Cardano has spun off a company called
14:23 Veridian. They're here. And then in 2025 was the first legislation where we did
14:30 digital identity rights. And then the KERI Foundation was established at the end of
14:34 2025. And then as I mentioned before, the Linux Foundation standards went final in
14:40 2026. So that's sort of where we got how we got started. So a lot has happened and
14:49 it's happening faster. So the rate is accelerating and I've you know, it's been
14:54 it's challenging to keep up with it all. But everybody that's helped get it to this
14:59 point, I think there's a real sign that it's going to stick and it's going to
15:06 build because it does some things that nobody else can do. And I know we have
15:10 some people in here that maybe think other identity systems are great. I'm going to
15:15 be biased. I'm going to think no other identity system is anywhere close to KERI
15:19 and ACDC, right? But at least I'll make a good argument for it, right? Even if you
15:24 disagree with me. We started with cryptographic agility from the beginning.
15:30 It had to be everything is 100% cryptographically agile at the granular
15:37 level. I don't know of any other identity system that started with cryptographic
15:43 agility as a first order property of the whole system. And so the CESR protocol is
15:48 how we attain that cryptographic agility, which means that we're future-proofed. New
15:53 crypto comes along. We don't have to start from scratch. I mean, anybody's… I mean,
15:59 the the people behind Git and GitHub and the various organizations that use Git
16:07 have a difficult problem because it uses SHA-1 which is broken. But there's so much
16:19 code based on SHA-1 and there's no cryptographic agility that people have
16:23 tried to move it to SHA-2 or SHA-3 and they can't because there's just the lift
16:28 is too heavy. And so they keep patching it around it. But fundamentally, if they had
16:34 built it with cryptographic agility, they could have just switched to a different
16:37 hash and not have to change any of the tooling. So you get that for free anytime
16:42 you build stuff on top of the KERI suite of protocols. Cryptographic agility is
16:45 baked in everywhere. Fault tolerant key management. The answer to security is not
16:55 more crypto. The answer to security is not more sophisticated mechanisms and
17:05 protocols. The answer to security is to fix key management. And the only way you
17:10 can fix key management is to make it fault tolerant because you can't make it
17:14 perfect. Every type of crypto has side channel attacks that are viable. And so
17:27 you no matter what you do, you will fail at some point. So the only way that it
17:33 actually will work is if you make it so that it's fault tolerant. And so a lot of
17:39 times this is a difficult concept. It takes a time for some people in the
17:43 security industry to understand that you really want to build things with fault
17:49 tolerance using first principle fault tolerance. So a lot of people hear the
17:53 term fault tolerant and a lot of people in the blockchain world are familiar with a
17:59 brand of fault tolerance, you know, like Byzantine fault tolerance, but in the
18:04 critical systems infrastructure world, in the reliable engineering world, in the
18:11 survivable engineering world, these are worlds that I came from. I spent years in
18:17 those worlds before I ever looked at identity. The building systems that are
18:22 fault tolerant as a principle design is a well-known there are a well-known set of
18:28 techniques. And so what I did is I took those techniques and I applied them to key
18:32 management. And once I applied them to key management, all of a sudden key management
18:36 became a solvable problem. And so the first solution is you have identity that
18:42 is perpetual. And it's perpetual because under the hood, it's fault tolerant. If I
18:48 have a secure enclave like on my phone and I store my private keys in the secure
18:53 enclave, it's a piece of hardware. It's really, really hard to get to those
18:56 private keys. But it's not impossible. So if I don't have a way to recover from
19:06 losing those private keys, my identity is only survives as long as the first exploit
19:12 of my private keys. And then once I lose my private keys, I have to start over. So
19:17 it can't be perpetual if I can't recover from a compromise. I have to build
19:24 compromise recovery into my system. So the very first thing we did is we assume in
19:30 KERI that your signing keys will be compromised. It's not like the blockchain
19:37 world where if your signing keys are compromised, you're done. It's a
19:41 catastrophic failure. That's what it means. I mean, if you lose your Bitcoin
19:46 address, your private key, then anybody can spend all your Bitcoin money and you
19:52 can't ever recover it. You're done. Done. We can't allow, we can't for identity that
19:58 is attached to a person, it has more value than the money in your bank account. It is
20:03 you. It is your identity that you want to control perpetually. So it has to be fault
20:09 tolerant to the faults that are going to happen. The most likely faults and those
20:13 are your keys are going to get compromised. Your signing keys are going
20:16 to get compromised. Now that you have perpetual identity, you say, well, what am
20:22 I going to do with it? Right? I have an identity. I can improved control over
20:26 identity, but what am I going to do with it? Well, how do you do things with it?
20:30 Well, you issue things. People issue things to you. You issue things to other
20:34 people. You present things issued to you to other people. So you need to have
20:38 issuances that have similar properties. So you need issuances that are perpetually
20:42 verifiable. And the interesting thing is that if I have a mechanism that makes my
20:48 identity perpetually perpetual, I can use that same mechanism mechanism to anchor
20:56 and make issuances perpetually verifiable. So we got a two for one. It's like we
21:01 built one set of infrastructure and it solved a whole nother set of problems
21:05 without having to build additional infrastructure. Well, we had to build some
21:07 additional infrastructure, but the core infrastructure we didn't have to rebuild.
21:11 And then we said, well, in the real world, if I'm going to do things with identity,
21:17 especially in organizations, I need delegation. So delegation wasn't an ad hoc
21:24 thing. Delegation is a first-order property of both KERI with delegated AIDs
21:29 and ACDC with edges and delegated issuances. So we have two types of
21:36 delegation that can work synergistically. And they're not something that people like
21:43 right now this year, I'm seeing people talk about delegation in all sorts of
21:49 identity contexts. We were talking about delegation since 2020. 2020. We've been
21:55 talking about delegation for six years and we have hardened the concept of delegation
22:01 to where we know how it works, how to make it work and what to do with it. We're not
22:04 just inventing it this year. Lots of people are reinventing delegation this
22:09 year. I'm seeing lots of examples of, well, how do you do delegation? It's like,
22:13 no, no, we've been doing it for six years. And delegation, the same mechanism that
22:20 allows you delegation, allows you to do any kind of relationship. It doesn't have
22:24 to be a delegation relationship. It can be any kind of relationship and that
22:27 relationship can be provable, secure, verifiable, all of those properties. And
22:32 we have six years of doing that. So KERI is no half measures for security. We don't
22:37 compromise on security. We go all in on we're going to make this as secure as you
22:44 can practically make it. Okay.
22:50 So another way to think about what KERI and ACDC do, I call the four A's of data
22:57 value, right? The whole point of doing this is to have data that's more valuable,
23:02 to be able to exchange data that's valuable. So the first thing in the four
23:07 A's is it's authored. You want to be able to have a stable source of that
23:12 information that you can, that you know, that who authored that data. You want to
23:20 then be able to authenticate the data and know that it came from that author. You
23:25 can securely attribute it. That means that everything that everybody does in the
23:29 ecosystem, they can be accountable. Now, you don't necessarily have to make it
23:34 accountable to a person or an entity. It can be accountable just to the identifier
23:38 and the identifier can have some degree of privacy associated with it, but it's still
23:45 accountable to the identifier. And this is important when you get into the agent
23:49 world because agents are these things that are operating, but who's accountable for
23:56 what the agent does? Is the agent accountable? I mean, this question came up
24:00 this morning as we were driving here. I noticed we passed, I think it was seven
24:06 Waymo autonomous vehicles that did not have drivers, right? So when I was here
24:13 last spring, I didn't see that many. There was like seven just in like a mile. And
24:19 Caleb asked me the question, so if the Waymo gets pulled over, who does the
24:25 policeman issue the ticket to?
24:31 Who's the accountable party for that agent that's driving that car? If you can't
24:38 solve the accountable party problem, you can't practically have agents in the real
24:42 world because they're things. They're not people. Our whole legal system, our whole
24:48 society is based on the fact that people are the accountable agents. And so you
24:52 have to associate agents with the people that hold the liability. You have to make
24:57 them accountable. Authorized, authority chains, accountability by reference,
25:02 chains of authority. All of those things are part of making information valuable
25:07 when you're talking about permitting things to happen with data. And then
25:12 finally, authoritativeness. Can you trust the data? Is it reputable data? Is the
25:17 information there something that has value? And often we can't reproduce the
25:25 process of determining whether a statement has veracity. We can say, well, we know
25:32 who said it, but we don't know if they're lying when they said it. We just know who
25:38 said it. How do we trust the data? Well, one of the ways you trust is by reference,
25:44 by reputation. If somebody that I trust says that you can trust Alice, if I trust
25:52 Bob and Bob says, I know Alice, you can trust Alice, then I trust Alice by
25:58 reference. And so much of trust in the real world, the bootstrap of trust comes
26:03 by reference. And so for example, GLEIF is a global root of trust for the ultimate
26:09 beneficial owner of a legal entity. and the roles of the people that run the
26:16 organization and the roles of any of the members of the organization. And you trust
26:23 because you trust by reference. And if you can trust by reference, you need to and
26:28 you can securely attribute and do the other ones above it, then you have a basis
26:32 for trust. Yes. Yes. Oh, yes. Sorry. Here. – There's reputation dependent on… I'm
26:43 sorry. – I just wanted to point out there's a recursive element here too
26:46 because knowing that the reputation is trustworthy all goes back to the start
26:55 from the authored part and goes back in. – Yeah, you can't have reputation if you
27:00 don't have the other ones. And then once you have reputation, then you can start to
27:03 trust the authoritativeness of the information. Like I have a PhD, right? And
27:08 so you would say, well, I can trust you because you have a PhD. Well, why can you
27:13 trust me? Well, because the institution that granted the PhD was accredited to
27:19 grant PhDs. Now, if you said, well, I'm going to tell you how to, I have a PhD.
27:25 I'm going to tell you all about how
27:31 to make explosives. And you might go, well, wait a minute. What's your PhD in? I
27:38 say, well, it's electrical computer engineering. Well, I don't think they
27:42 teach electrical computer engineers how to make explosives. That would be like a
27:46 chemical engineer. So already the authoritativeness
27:53 of what I say is a function of the reputation that tells you whether or not
28:00 there's some basis for trusting me. Right? So without this ability to security
28:08 attribute up the chain to have reputation and systems of reputation, we don't have a
28:15 basis for trusting data that comes in over the internet. And we certainly can't trust
28:20 agents that are operating electronically without that. So we have to solve that
28:24 problem. So the mission of the KERI Foundation is to foster open
28:28 infrastructure. It's the eye in KERI. There's a reason KERI is infrastructure.
28:34 Because to solve the perpetual identity problem in a fault-tolerant way requires
28:40 infrastructure. There's no way to solve it without infrastructure. But we want to
28:45 minimize that infrastructure. We want to make that infrastructure work in a certain
28:48 way. So I use the phrase, I use the acronym DKMI for decentralized key
28:56 management infrastructure to describe what KERI is. KERI is a decentralized key
29:01 management infrastructure. It's a set of protocols that allow you to do that. And
29:06 it was designed to be web scalable to solve the cost for problem of blockchain.
29:11 So they said, well, blockchain is way too expensive. The cost for is way too high,
29:15 right? So we want it to be web scalable. We want an ultra low cost for because it's
29:20 infrastructure and infrastructure costs money. It's not free. So you want to at
29:27 least use infrastructure that's as cheap as the cheapest possible infrastructure
29:30 right now is web scale infrastructure. That was a design decision because we
29:34 couldn't get away from it. A lot of people have complained about KERI and said, well,
29:37 it's too complicated. You got to have witnesses. You got to have watchers.
29:42 That's too much. I want an identity that doesn't have that infrastructure. Well,
29:46 you can have an identity that doesn't have that infrastructure, but you can't trust
29:49 it. It's not secure. It doesn't satisfy the minimal properties. So, you either
29:55 decide that you're going to live in a world where your hacked continually or
30:00 you're going to build the minimal amount of infrastructure that need to be secure.
30:04 And I can't think of any less infrastructure than a web-based open
30:10 source open standard things
30:15 that run at web scale. So the idea is that we have a cooperative model so we can get
30:23 meta network effects. I wrote a white paper on meta network effects which says
30:27 that if you're sharing value that transfers across trust domains that you
30:32 get a meta network effect of that value. And so reputation and the four A's of
30:39 data, all of those things are about secure attribution, identity. Those are all
30:46 things that move across trust domains. It doesn't matter. It's like I use this
30:51 example.
30:54 Reputation, some really good people have talked about reputation as being three
30:59 things. It's competence, honesty, and reliability. So if I can trust somebody, I
31:08 have three reasons to trust or not trust. Somebody can be very competent, but if
31:13 they're not reliable, I can't trust them. Somebody can be very reliable, but not
31:18 competent. Like I have a younger brother who's an engineer. He's really reliable.
31:24 He's really competent in engineering, but I would not trust him to do open heart
31:27 surgery on me. Now, he actually has a son who's a doctor that I might trust to do
31:34 open-heart surgery on me. He's not quite yet. He's just barely out of residency, so
31:38 he hasn't reached that point yet. And then you have people and a lot of people think,
31:42 well, it's, you know, are they dishonest? Well, dishonesty is only one part of being
31:48 able to trust. So what you want is those things that move across trust domains. So
31:57 if I hire somebody to mow my lawn and they're reliable, like they show up on
32:03 time, they mow it, don't leave weeds, stuff like that. And then they come back
32:07 at the end of the season and say, hey, I'm starting a business where I'm going to be
32:13 shoveling snow. Okay. Well, right off the bat, I know that they're reliable. They
32:18 may not be competent at shoveling snow, although it doesn't take much to be
32:22 competent at shoveling snow. So would I trust them? Well, I would trust them a lot
32:25 more than somebody who was not reliably mowing my lawn, right? So it's not a
32:32 single property that we have to worry about. But there are lots of things like
32:37 that that do move across domains and a lot of them are identity-based. So you can
32:46 reconstitute your control of your identity from any copy of your key event log. And I
32:53 haven't gone to any detail inside the things. But this is an important property
32:58 because it means that as long as there's some infrastructure out there and you lose
33:03 all of your copies of your key history, as long as somebody has a copy, you can
33:11 reconstitute it. So that makes it portable,
33:17 right? It's truly portable. There's no wallet vendor lock-in. We have true
33:20 portability across all the infrastructure providers. We have non-cooperative key
33:25 custodianship. So a lot of people that say, well, keeping my private keys is too
33:32 difficult. Grandma can't manage your private keys. Well, if I have a keys
33:36 custodian that's managing on her behalf, I want to be able to have that management
33:42 happen and be able to move to a different provider without requiring the cooperation
33:48 of the original provider. I mean, if for some reason they die in a snowmobiling
33:56 accident and they lose all of my grandma's keys, I can still move to a different
34:04 custodian.
34:08 Witness pools with no common mode failure sources benefit everybody that uses them.
34:13 And then the watcher network makes it so that you can tech duplicity. It was an
34:19 interesting thing. I used the term duplicity, but that was the biggest aha
34:24 moment in writing the KERI white paper is that if I can make every fault exhibit as
34:34 duplicity, then all I need is one mechanism. I need a duplicity detection
34:40 mechanism and now I can detect all faults. And the key to fault tolerance is you have
34:46 to detect faults. One of the in my early days, I attended a seminar by the original
34:56 team that was working on the Mars lander. And we were talking about they were
35:03 talking about a fault tolerance. Like the seminar went to a conference and I was
35:08 working on autonomous underwater vehicles, which aren't as cool as a Mars landers,
35:12 but they're still pretty cool. Right. So anyway, so I was trying to learn from them
35:17 and they said, you know, and so the whole thing was about fault tolerance. It's like
35:21 how to build fault tolerance systems, how they put fault tolerance in the Mars
35:24 lander. And the key insight they said is, you know, we realize that we just can't
35:29 build any system that we can afford to put on a rocket and ship across space that is
35:38 imperfect, that is impervious to failure and impervious to fault. There's always
35:44 going to be faults that we can't account for. We just can't build them all in. But
35:47 they said, but what we could do is we could build a system that never failed to
35:53 detect a failure. So we can't prevent it from failing, but we can certainly always
35:58 detect the failure. And then if we have enough time and resources, we might be
36:02 able to recover from failures. And I don't know if you pay attention to the early
36:05 days of the Mars Lander, but they recover from pretty severe failures. They had a
36:10 botched software upgrade and the system just like didn't work. And then they
36:15 figured out that if they did some things, stuff like that, they could could boot it
36:20 in a particular mode where they could download a recovery program, you know, and
36:24 they were eventually able to recover it, you know, so the point is detect failures.
36:31 Build failure detection as your first and most important piece of infrastructure.
36:39 Then you can build on top of that. And so duplicity, once I only had one thing I had
36:47 to detect, then failure detection got easy. I just have to detect duplicity. I
36:51 force everything to look like duplicity. KERI is designed so that every bad
36:55 behavior that an attacker could successfully benefit from exhibits as
37:01 duplicity. And so the duplicity detection then detects it so I can recover from it
37:05 before they gain full control over my identifier. So we have something called
37:11 the five Ws and we're going to have some more talks about that. These are shorthand
37:17 for wallet witness watcher. Those are the three primary infrastructure
37:24 components. We have the web runs on the web and the wizard is smarts behind the
37:29 scene. Now we have two other ones that didn't fit in the five Ws. These are
37:33 registrars and observers, but we'll say that they're part of the web
37:37 infrastructure and we'll talk about those. So that's what KERI infrastructure looks
37:41 like. So you see that it's always two parties, You have entity A and entity B.
37:51 Each party has their own set of infrastructure. The infrastructure that's
37:54 shared is the watcher network. So entity A controls their own witnesses. entity B
37:59 controls their own witnesses, which means you can't trust them. So the watcher
38:03 network observes duplicity and therefore you can trust them because you only trust
38:08 them as far as they're not duplicitous and as soon as they're duplicitous you stop
38:11 trusting. It solves the governance problem because in blockchain the watcher network
38:17 and the witness network are the same network. So you then have to have shared
38:22 governance between entity and A and B. And if they don't agree to shared governance,
38:27 then you have the ledger wars. So we got rid of the ledger wars by separating
38:32 witnesses and watchers and separating the network that manages trust into two
38:38 pieces, one that's controlled by the entity and one that's not controlled by
38:42 anybody. It's just anybody can be a watcher and all watchers do is detect
38:47 duplicity. So, so they don't, they don't have anything else that they have to do.
38:51 Um, and so, and so, uh, any watchers is good. You know, the watcher network, uh,
38:56 is, is mutually benefits everybody. Uh, and nobody, nobody has to, nobody cares
39:02 about how it's built because it doesn't benefit benefit them any more than anybody
39:06 else. So that, that was the, that was, so we call that deconstructed blockchain. So
39:11 I told that to some people and they go, Oh, okay, that makes sense. Now we
39:14 deconstructed the blockchain into a, into two different networks, a witness and a
39:19 watcher. Then we have mobile wallets. We have some wallets. We'll do some demos on
39:24 those that run on the different platforms. And then we have the other two are
39:30 registrars and observers. And these are necessary for perpetually verifiable
39:37 issuances. And in the SEDI example, they're essential become essential
39:42 participants registrars for ACDC state. And the observer is how you isolate the
39:48 registrar from the points of validation so that you don't have any surveillability
39:54 back to the issuer. So we solved the privacy problem, but yet we still have
39:59 revocation registries that aren't correlatable because of that separation.
40:04 So we also did a split, right? We split the registrar which is controlled by the
40:08 issuer that publishes state and then the observer which is controlled by the
40:13 verifiers
40:17 can observe the state, but the issuer can't observe the verification action. So
40:23 it also deconstructed blockchain because those used to be on the same network as
40:26 well. And then this is the process of presentation. An issuee gets an ACDC, they
40:33 present it, the verifier goes to an observer who has the ACDC state from the
40:38 registrar. They can verify whether the state of the ACDC at the time of
40:41 presentation is still valid. without creating a correlation point. There are
40:49 lots of systems that when you go to revocation registries, you lose all your
40:53 privacy because the revocation registry becomes a super correlator. And there was
40:57 a lot of work trying to build revocation registries using cryptographic
41:04 accumulators, but nobody's after Sovereign, nobody's really done anything
41:09 serious with that. Lots of people just now use like a like the W3C is their standard
41:17 is a bit status string, which is perfectly correlatable. Yeah. Is there a problem
41:24 with cryptographic cumulators or just too difficult? Too difficult. It's just
41:29 they're just too difficult. The performance, I mean, you know, Sovereign
41:31 spent years trying to get the performance to where it was reasonable. So technically
41:37 a cryptographic cumulatively would work, but practically they just it just never
41:43 worked out. So I said, well, I got to do something that's web scale that works
41:49 cheaply. And so separating into pieces actually solves the problem in a and we
41:57 get something that nobody's ever had before. In fact, I'll do the next slide.
42:03 So with bulk issuance, we can get herd privacy with sparse milkletrees, with bulk
42:10 updates, We can get herd privacy and bulk issuance allows you to together it solves
42:17 the vendor to vendor linkability problem. But here's a cool thing that we came up
42:24 with in the specification. And I call it perfect forward privacy. So by going to
42:35 this registry approach, which you can't do with a cryptographic accumulator. So this
42:39 is better than a cryptographic accumulator is that you can blind the state of the
42:45 ACDC so that the presenter or holder can unblind it, but they unblind it at
42:53 presentation. And then you issue the issuer can issue an update that's a
43:00 vacuous update, no change, right? So you can have a no change update. It doesn't
43:03 change the state, but because the state is blinded, the verifier that verified the
43:08 previous state doesn't know the current state anymore. Whereas a cryptographic
43:12 accumulator once they know how to verify the state, they can verify it
43:16 indefinitely. So that is a unique feature of this approach that we use now with KERI
43:26 is that you can present the state, the verifier can verify the state today, but
43:32 then tomorrow they don't know what the current state is. All they know is there's
43:37 been an update to the state. It might be an update that doesn't change state. It
43:40 might be an update that doesn't change state. It might be an update that does
43:41 change state. They don't know. The only way they can know is then to have a new
43:45 presentation with a new unblinding that tells them what the current state is. So
43:50 it solves all the privacy problems associated with dynamic updates. So it
43:57 doesn't become, you know, it's a really good solution, I guess is the way I'm
44:01 going to say it. But we went even further because remember I said the key to key
44:07 management is detecting faults. So in the conventional world of verifiable
44:15 credentials, there's no way for the user to detect whether or not their keys have
44:21 been compromised and an imposter is now presenting their credentials fraudulently.
44:28 Like if the keys that I use that control the identity that an issuance has been
44:37 issued to and I do the presentation and I sign it. I sign that presentation and they
44:42 go, okay, yes, it was signed. So at the time of presentation, whoever's presenting
44:46 it controls the keys that control the identity that to which it was issued. So
44:50 we'll trust it, right? The verifier has to trust it. Well, we can do better than
44:55 that. So we can make it so that an issuance requires a presentation registry.
45:00 So it's a registry just like an issuer registry, but the registry in this case
45:05 controlled by the holder, not by the issuer. So when the holder presents the
45:11 credential, the verifier has to check the user's presentation registry. It has to
45:16 check two registries.
45:20 Sorry. It has to check the issuer registry to know that it was correctly issued. But
45:26 it checks the user's registry to see that the user has actually anchored it in their
45:33 KEL, the presentation. presentation. What that means is now the user can check their
45:39 KEL and if any presentation show any anchor show up in the KEL that they didn't
45:44 in this registry that they didn't approve, they know their keys have been
45:48 compromised. So now they can recover from it. So they can limit the damage. So you
45:54 don't have unmitigated
45:58 impersonation fraud potential based on key compromise. You can you force the
46:05 detection of the key compromise by the use of the keys result in something that you
46:11 can detect. You can't stop the key compromise, but you can make it so that
46:16 anybody to benefit from the key compromise does something that you can detect. And
46:20 now you know that you need to fix your keys. So here's how it looks like. So
46:25 here's the issue has a has their key event log. Here's their registry. Each time that
46:32 there's a presentation, they anchor the presentation in this log which gets
46:38 anchored in their KEL and if their keys are compromised and somebody is able to
46:43 anchor in this log in order to do a successful presentation, the holder can
46:50 detect it because this has to be anchored in their KEL. So, they can't put it here
46:56 unless they can get it in their KEL. And if they get it in their KEL, then they
47:00 know their keys have been compromised because the only way it gets it in their
47:03 KEL is their keys are compromised. And the witness pool allows them to detect that
47:09 because they're forced to get it in the KEL. They have to get the witnesses to
47:14 witness it. So these are things that don't happen in key management. Yeah, we got a
47:21 couple minutes left. Right. So I'm going to I'll cover more of this stuff, but
47:26 these detailed fault tolerant things don't happen in key management in general. When
47:32 you ask people, how do you manage keys. They'll say things like, in fact, I see
47:37 this in almost every protocol that is in the identity space. You go to the security
47:45 section and they say security considerations. And what did they say in
47:50 the security considerations? We assume that your private keys have not been
47:54 compromised. We assume that. If your keys are compromised, then all sorts of bad
47:59 stuff happens and this protocol isn't secure. So they already assume away the
48:04 hard problem. They assume away the problem that makes everything insecure. They just
48:09 say it can't happen. And if it doesn't happen, then everything else we do is
48:13 secure. Great. That's the easy problem. The hard problem is how do you still
48:18 survive even though your keys are compromised? That's always been the hard
48:22 problem identity and nobody has solved it until KERI did. That's our claim to fame.
48:28 We solved the hard problem of security because we solved the hard problem in key
48:31 management. So I try to come up with a simplified way to think about KERI. So
48:40 KERI is about reputable autonomic pseudonymity. Big words, but if you
48:47 remember the words and you remember what the words mean, then it translates.
48:51 Reputable means that the identity is perpetual. You can attach reputation to it
48:57 and the reputation sticks. So you can trust it. Autonomic means the user
49:02 controls it, right? Self-governing. You the user controlled identity, not some
49:06 other entity. And pseudonymity means that it's an identifier. It isn't your name. So
49:14 you can have some degree of separation between the identity and the natural
49:18 person or the identity and whatever. So you can have as much privacy as
49:23 practically possible, right? So it's pseudonymity and you use a cryptonyms. The
49:30 other side is control over confidential context. This has to do with what do you
49:36 do with this side? Well, if I want to exchange data with somebody, I want to be
49:42 able to have a high value exchange. I want that exchange to have the four A's.
49:48 Author, authenticated, authorized, and authoritative. How do I do that? Well, I
49:56 want to do that in a way that two of us can exchange data like that, but we don't
50:02 want any third parties to see that. And so I need a way to control a confidential
50:06 context. Now people say, well, that's privacy and it's not. There's two
50:11 definitions of privacy. One of them is really intimate, intimate knowledge that
50:17 only you know. So when I say private key, that's using the true definition of
50:21 privacy. It's a private key, only you know it, you never share it, right? The other
50:25 definition of privacy, which has changed in the last 20 years since we had the
50:30 internet, is really confidential. I'm exchanging data and you're not going to
50:38 share it with somebody else. Well, confidential is a very clear meaning. You
50:42 share data with somebody. Once they have the data, they have the data. I can't stop
50:46 them from knowing what they know. And if they share it with somebody else, I can't
50:51 stop that. There's no way for me physically, technically to stop that.
50:55 There's no technical solution to the problem of sharing data. Once the other
50:58 person has it, they can share it. I can't technically stop them. I might be able to
51:02 stop them with liability, with regulatory, with incentive structures, with taking
51:09 them to court. I can do all sorts of things to try to prevent them from sharing
51:13 because I de-incentivize it, but I technically cannot stop them. Once they
51:19 know something, they can share it with anybody they want. So there's no technical
51:23 solution to the privacy problem. if privacy includes sharing data. You can
51:28 technically solve privacy if it means not sharing data. I can make it so I don't
51:32 share data and I can protect it so nobody else can see it. But once I share data, I
51:36 can't prevent them from sharing it. Technically, I can only do it regulatory
51:40 ways. Yes.
51:45 So I call this control over confidential context. Anyway, so the shorthand for this
51:52 is RAPC3 or Rhapsody. So my only comment Sam was if you had a mechanism in the data
52:01 you shared that required some type of key that you could rotate to access it you
52:07 could share that data temporarily but then change its access after the fact. Couldn't
52:11 you not? Well if they decrypt it and copy it then you can't stop that. Right but
52:16 there is a window. Well yeah but like I said it doesn't fundamentally prevent the
52:22 the hard problem which is they have data, they know the information, they can share
52:27 it in a different form. The information leaks out, somebody else can correlate it,
52:32 re-identify it, all of that works. Yeah, there's lots of little tricks that people
52:36 have tried but they don't fundamentally solve the hard problem. And if we think of
52:40 it in the wrong way, then mentally we never think about the right solutions
52:43 because we're always thinking about the wrong solutions. More questions? Yes.
52:53 What do you think about zero-knowledge proofs? There are lots of different types
52:59 of zero-knowledge proofs. Technically, a zero-knowledge proof is any proof that
53:04 discloses some data without forcing you to disclose other data. So a Merkle tree is a
53:12 zero-knowledge proof. A digital signature is technically a zero-knowledge proof. Any
53:16 every you know just standard digital signatures are technically zero-knowledge
53:20 proofs because you have a private key in a NOTS, you can prove that somebody who knew
53:24 the private key in a NOTS created the signature without disclosing the private
53:28 key of their NOTS. So that's technically a zero-knowledge proof. Now, there are
53:31 families of zero-knowledge proofs called anonymous signatures, anon-creds, things
53:35 like BBS+, which attempt to make it so that you can prove that something was
53:41 issued by somebody without the issuer knowing at the time of proof. And those
53:47 are only good for ephemeral applications because as soon as the issuer's keys are
53:52 rotated, you can't trust any of those proofs. And so they've been misused. When
53:57 used appropriately, they work just fine. If I have a situation like let's say a
54:02 blind auction where I issue the permissions to be in the auction the day
54:08 of the auction and they expire the next day, perfectly fine. Because I expect that
54:13 those keys that I used to issue them are going to be strong and not compromised for
54:17 a day. But if I'm issuing a driver's license, or a birth certificate that has
54:22 to survive for years or a whole lifetime and I'm using an anonymous signature to do
54:27 that, the issuer's keys aren't going to last a lifetime. That means every single
54:32 issuance is automatically invalidated when you rotate keys. Not when it expires when
54:38 the keys rotate. And what determines key rotation? It's something called a crypto
54:41 period. So a crypto period is a statistical concept. But for example, if
54:47 you read a special publication 857, from NIST, one of the things that determines
54:53 the maximum crypto period for a set of keys is your IT staff turnover. So let's
54:58 say you're an issuer and you're issuing a bunch of driver's license or a bunch of
55:01 birth certificates and you hired an IT staff and they have access to the private
55:06 keys and one of them says, oh, I don't really like working for you. I'm going to
55:09 leave. And it's like a week after you issued a million birth certificates. What
55:14 are you going to do with those million birth certificates? If you're going to be
55:18 secure, you would have to revoke them and reissue all a million because that one guy
55:22 left because he had access to the private keys used to issue them and therefore he
55:25 could issue fraudulent ones and you have no control over them once he walks out the
55:29 door. So the idea of using those sorts of zero knowledge proofs for long-term
55:34 issuances was always a bad idea. And even though I would argue with people about it,
55:39 they'd say, oh, no, no, it's not a bad idea. It's because it's a bad idea for key
55:43 management reasons, not because of the algorithm. The algorithm is just fine. I
55:47 don't care about it. The algorithm works as an algorithm, but the key management
55:51 assumptions don't work. In fact, the W3C BBS plus standard in its security section,
55:58 you know what it says? If the issuer keys are compromised, there's no security. It
56:06 says that. So they assume already that your key that the issuer's keys can never
56:09 be compromised during the lifetime of any of these proofs. And then they never talk
56:13 about what does that mean practically for somebody to issue proofs. It means you can
56:17 only use them for a ephemeral applications. Those type of zero knowledge
56:21 proofs. Now there are other ones. There's SNARKs, the STARTS, all of those all have
56:25 different properties. They have different applications and they work really well in
56:29 those applications. Often what happens is people take them over there and say,
56:33 here's some magic. Here's some black crypto magic. We want to apply it to
56:37 identity. And they ignore all the assumptions that say how you can use it.
56:44 They ignore those assumptions and they're often key management assumptions and they
56:48 apply in a domain which is identity where none of those assumptions are valid. And
56:54 so it's not because the crypto is bad, it's because the assumptions don't apply
56:58 to the application and so you can't use it in that application. So that's what I
57:02 think is zero knowledge proof. So I hate it when people say Sam doesn't like zero
57:05 knowledge proofs. I love zero knowledge proofs when they're used correctly, not
57:09 when they're used incorrectly. They're really, really bad and just because they
57:14 have a really cool name like zero knowledge proof, you shouldn't be using
57:17 them just because it's a cool name. Right? That's a bad idea. Yeah. So anyway, are we
57:23 done? Okay, I'm done. Thank you.