0:00 Please go ahead and get going on this one. All right. For those most of you who
0:07 probably don't know who I am, my name is Ryan Hanson. I'm a member of the KERI
0:11 Foundation Development Team, the small team that Sam put together to kind of help
0:15 bring the five Ws to life. So I'm going to give you a quick rundown of what the five
0:20 Ws are. Sam already introduced them, but we're going to go through them a little
0:25 bit more. And then I'll give you a little bit of a state of where we are in the
0:31 development of these. So this alternate title is the state of the key state. This
0:36 is my state of the key state address to this community. So, that
0:47 was weird. Okay. I've got to make sure my slides line up with these slides. So,
0:52 first of all, I'll give you a quick why when it comes to the five Ws. KERI, as
0:59 those of you who are very familiar with it and as Sam has already established, KERI
1:05 is all about key state. Implied in that is identity and keys themselves. But what
1:10 good really is an identity and keys that you if you can't prove the state of those
1:17 keys that they're still within your control and are still verifiable. So proof
1:24 itself requires witnesses. It's all well and good for me to assert an identity or
1:30 assert that I've done something, but it's not as strong or it's weaker without
1:36 witnesses that will attest to that particular assertion of some kind.
1:44 Witnesses also need to be independent, meaning something outside of me or the
1:51 control of that particular ID, whatever it might be. And we'll get into that a little
1:56 bit more. highly available, meaning that state can be determined whether like I
2:05 particularly am online or not. And kind of to wrap that up, the Ws are a big part of
2:14 the I in KERI. There's more to it than just what I'll be talking about today, but
2:19 infrastructure in KERI is what the Ws kind of are about. So with that, the five W's
2:29 as Sam already has kind of gone through. We have the wallet and I won't spend a lot
2:35 of time on each one of these in this slide but we'll move through these pretty
2:38 quickly. Wallet, witnesses, watchers, web, and wizard. So each one of these are
2:50 critical part of the KERI overall ecosystem as Sam already
2:54 illustrated before. So let's get into each one of those little bit more. Starting
2:58 with the wallet. Wallet has some primary responsibility and function which is first
3:06 of all it's the home of our of the identity and the keys. That's where all
3:11 these things live. It's that secure enclave as Sam said to house the identity
3:19 itself and the keys. It is also responsible for the KE in KERI which is
3:26 the the key events, all the events that take place relative to that particular
3:32 identity and the keys that it controls. Those events are inception, rotation, and
3:43 interaction. There's a few more when we get into the details of the specifics of
3:48 the KERI protocol, but effectively these are what your wallet will do. The wallet
3:56 does in the KERI ecosystem is to generate those events and publish those or keep the
4:05 record of those in the key event log in its own key event log.
4:12 Next with witnesses, their primary responsibility is a witness of the truth
4:18 of the key state or to assert that the key state is what it is. Is that a fair
4:25 statement, Sam? Yeah. It's the R in KERI because it's the receipts. Funny you
4:30 should say that. Yes. Exactly right. So when the key event is issued, let's say
4:40 it's created an event and is published, when the witness then basically gives back
4:47 the receipt or creates the receipt on that event with its own keys, but then
4:53 establishes more firmly that that key event log is intact, that the math lines
5:00 up, everything is in order. So obviously that's the R in what KERI stands for.
5:07 Again, high availability witnesses are designed to be able to be highly available
5:10 to run in a situation where that those key events in the key event logs that they're
5:17 witnessing for are available at any time whether the wallet itself is online or not
5:22 or available or not. So that it that any verifier that needs to verify that key
5:29 event log can do so, can get it from a witness.
5:35 And choose your own meaning independent. What I mean by this is that when you
5:40 establish and I'm using the word you, any controller really is what I'm talking
5:44 about, but when in
5:50 choosing what witnesses are going to witness for any given ID that you might
5:55 create with your wallet. The idea is that there would be many different witness
6:03 providers or witness services available that you could choose from. And in an
6:08 ideal scenario, you would have more than one and all of them would be independent
6:13 of each other. So there's no collusion between that, no possibility or less
6:18 possibility of collusion between them about you know, anything that might be
6:24 they might want to assert. No way to kind of fudge it, I guess. It makes it makes it
6:30 less likely that you could do anything untoward with the assertions of the key
6:39 state itself.
6:43 Okay, watchers. And I'm kind of going through these fairly quickly because
6:46 mostly I want to get to what the state of development on these particular tools.
6:55 Watchers are independent witness observers. So they're always watching as
7:02 our little friend the monkey from Toy Story 3 if you guys recognize that one. It
7:08 was always watching. It was always there. Their entire role is really duplicity
7:15 detection and duplicity just so that we're all on the same page about what that
7:20 means. is duplicity would be when any two different records of the same key event
7:27 log disagree about what that the state of that identity is or the keys of that
7:34 particular identity. So if there's any kind of disagreement between them, that
7:38 would be duplicity. Watchers' whole purpose is to watch the witnesses to make
7:43 sure that they all align and agree about that key state of that particular ID. And
7:47 if there is any kind of duplicity, they detect that and and then you can take
7:52 action necessary to rotate and do what you need to do. So the idea becomes trust me
8:00 turns into see for yourself rather than just trust me on telling you this my
8:04 identity. This is with all these mechanisms you can you can actually verify
8:08 for yourself effectively is what that's what that's suggesting. Can I add? Sure.
8:13 So duplicity is in no I got a mic. Duplicity is independently verifiable. It
8:19 isn't something you ever have to trust somebody fund. Anybody that detects
8:23 duplicity can prove it to anybody else. So if I detect duplicity, I can prove that
8:27 it's duplicity. You don't have to trust me. Yeah. Yeah. Great. Thanks for that. So
8:35 really
8:42 the key thing for watcher is somebody bothered to watch with. You just it
8:49 doesn't matter who's watching, any watcher is as good as any other watcher because
8:53 you don't trust the watcher. It just proves to you its odd duplicity. So the
8:58 worst that a watcher can do is not watch. Right. Yes. So to that point, if you want
9:03 to weaken the security and anti
9:09 -fraud properties of KERI, then as they say in the movie, get rid of that monkey.
9:14 You know, we've got to get rid of that monkey. So. All right. Web. There's a
9:23 number of things that are implied by web or meant by web. Discovery, as we all
9:28 know, the web is a series of tubes. That's a common old joke for those who are old
9:32 enough to remember. Remember that one. But there's a number of things that web
9:40 implies in the KERI world. The ability to discover, discovery meaning other… I don't
9:48 know, how would you describe it, Sam? and discovery of other witnesses. Yeah,
9:54 discovery of infrastructure. We don't need a secure discovery mechanism. We just need
9:58 one that works well and the web already is there. So why not just use the web for
10:03 discovery instead of inventing a new discovery mechanism. Right. Yeah. The
10:08 expert, ladies and gentlemen. Communication. So once discovery has
10:11 happened, obviously it's about communication between which also implies
10:15 transport, which includes messages, any kind of messages, events, and things like
10:19 that. like that between these different parts of the infrastructure wallets and
10:23 witnesses and watchers and all of this. So all this done over web protocols. So no
10:34 other special infrastructure is needed for that. It's all web protocols and agnostic
10:39 of the transport itself, whether it's HTTP, Bluetooth, NFC, whatever the
10:44 transport mechanism might be that KERI can travel across all of those mechanisms
10:51 without any particular issues or any special needs. It doesn't trust anything
10:58 that the web does. Right. It doesn't need to trust, but it can certainly use it to
11:04 send stuff. Now, it's kind of it's interesting because we talk about trust a
11:07 lot when it comes to identity and all these kinds of things. But ultimately, as
11:11 many of you know, what we're going for is not having to trust anything and not
11:16 trusting anything and being making it verifiable and provable. And that's what
11:22 this whole ecosystem and KERI itself is designed to provide. And then finally,
11:29 wizard. And wizard becomes a little more, I
11:35 guess it's a little more, a little harder to describe exactly. The idea would be
11:41 sort of one-click KERI. That maybe is a little bit of ambitious. I don't know that
11:47 one-click might ever be the thing, but that's the idea that we're trying to
11:50 suggest with Wizard. Making KERI as usable as possible for as many people as possible
11:59 by determining some things like safe and useful defaults when it comes to creating
12:04 IDs and setting up witnesses and things like that.
12:10 Abstraction APIs for developers. KERI itself, the protocol can be pretty dense
12:16 and pretty difficult to get up to speed on quickly. But by providing potentially some
12:22 abstraction type APIs and libraries that wrap some of the lower level functionality
12:28 of KERI machinery in a little more accessible calls and things like that,
12:35 then we get a little bit closer to making adoption of KERI an easier thing, an
12:40 easier path. And ultimately what we what wizard concerns itself with is trying KERI
12:48 more into product than protocol. So building product around the protocol to
12:53 make it something that average individuals can at least get their head around enough
13:00 to recognize it's something that they want to use and then make it easy for them to
13:05 do so. So that's the intro to what the five Ws are. So now as far as the state of
13:15 those five W's itself. We have the KERI Foundation has a repository or a presence
13:23 on GitHub under KERI Foundation and within that organization
13:29 on GitHub we have several different repos that are of interest there. First of all
13:35 is Locksmith. Locksmith is our reference implementation of a desktop application
13:41 wallet. This is kind of where the core work of the wallet goes in and then that
13:46 funnels down from Locksmith to these other repos. One of them we have one called
13:53 Fortweb which is… – Yeah and I just want to note that Locksmith was donated to the
13:58 KERI Foundation from HealthKERI which is a company building KERI based stuff in the
14:04 healthcare sector. – Yeah good call out. HealthKERI has given us a lot of good
14:09 boosts. We'll talk a little bit more about that in a minute. But Fortweb is the same
14:13 wallet but in a web browser type of environment, WASM-based browser
14:18 environment. And from FortWeb, we're able to bundle and create FortiOS or FortiOS,
14:26 whatever you want to call it. And FortiOS, so the iOS and the Android mobile apps of
14:34 these two things as well. And then in more of the infrastructure side of things or
14:41 the deployment infrastructure, we have KFboot, which is… You see my beautiful,
14:47 really detailed architectural diagram here. We have KFboot, which is kind of an
14:53 onboarding service that communicates with the wallet to onboard an ID and set up
14:59 witnesses and that kind of stuff.
15:04 We have WitnessHK and we have WatcherHK, both of which the HK in those once again
15:10 is HealthKERI. They were the originators of those libraries and donated them very
15:15 generously into the community and open sourced them for us to use and to start to
15:20 build on even more. And then we have also KF mailbox which has a little asterisk
15:27 because this is something new. It's not quite ready for use just yet, but it's
15:31 something we're introducing now as a mailbox service that can be used within
15:37 the deployment infrastructure.
15:42 And then, so, I mean, this basically… There we go. The state of the key state
15:53 without KERI is… Who else? We don't actually know what it is. Well, that's my
15:59 way of asserting that and joking that KERI is the way to go when it comes to being
16:06 able to prove our key state. And with it, that's where we are. So silly pictures. So
16:14 that's
16:19 pretty much it for my particular slide. Sam, unless there's any questions, I got
16:23 through that quicker than I anticipated, but well, we can certainly go into in more
16:27 detail. So let's ask, but I think this is a good place to ask questions because I
16:33 know I cover things very quickly and then, you know, there's lots of latent
16:38 questions. and saw him use the whiteboard to answer those. I've got a question about
16:43 KFBoot. Is this on? Okay. It's going to the video. If the light's on, it's on.
16:51 It's just the reverb of like boom. Yeah. All right. So for KFBoot, you said that it
16:56 communicates with the wallet when you've set your identifier up. I looked at
17:01 KFBoot. My understanding is that there were five standard and you could dive into
17:05 this. There were sort of five main pieces of infrastructure helps you stand up and
17:09 then there was a little bit more definition. If you could, if you could
17:12 dive into that, I had never heard what you just really said, which is when you set up
17:16 an identifier, it walks you through some things. Can you detail that for me and
17:20 then we can sort of come to some questions to the other parts? Evan could probably
17:24 address that a little bit easier. Evan does a lot of work with the wallet itself
17:29 and that communication process. Yeah. So, I mean, you came from when we got this
17:35 infrastructure from HelpKERI, they had their like healthcare platform that they
17:39 use to orchestrate this sort of stuff. And so like they stripped it out, sent it to
17:45 us to be open sourced and we had to kind of fill in the gaps of the like identity
17:50 infrastructure orchestration. So that's sort of what we have KFBOOP4 now as like
17:54 an open source identity infrastructure orchestration like Ryan's. Kind of like a
17:59 plug-in infrastructure, right? Exactly. Yeah. So anybody that creates witnesses,
18:03 anybody that creates a watch or service could register with with KFBoot, right? Do
18:09 we have a registration yet? We don't, right? But we have to have a way to
18:14 discover. Is there a way to discover their services? Or we have an implemented data?
18:20 Yeah, like when we set everything up on DigitalOcean. Yeah. So you'd have to
18:25 they'd have to add up like a connector. But if you have that connector, then then
18:30 any services that KFBoot knows about, then that wallet could say, Oh, I want
18:35 witnesses from this service. and I want a watcher from this service. Part of why I
18:41 ask is since we at Glive work with the ecosystem with lots of players and there's
18:47 going to be potentially many different providers of infrastructure. I wonder is
18:51 this generalizable or generalized infrastructure discovery tool as KFBoot
18:58 and it interacts with sort of a set of infrastructure providers and a set of
19:02 wallets that recognize that discovery protocol? Am I characterizing it
19:06 correctly? Am I going in the right direction or am I misunderstanding?
19:12 I mean, it's early enough in its development that it could go a number of
19:16 ways. All it does for us right now at its current state is it's the first landing
19:23 point that the wallet uses to discover what witnesses are available to add those
19:28 to your configuration for your particular AID. So that's the first step and that's
19:35 really what it's doing. at this point is kind of facilitating that initial
19:41 onboarding to be able to set up your witnesses. Where it goes from there, I
19:45 mean, I guess there's lots of different ways you could take it. It's fairly simple
19:48 little service right now and it's all it's all work in progress still. There's still
19:53 much to be done on that. So, yeah. So, I guess I have one. I guess for GLEIF, the
20:02 important thing is to be able to offer to to holders of VLEIs, for example, and to
20:11 allow companies who want to implement the VLEI credentials to have alternatives to
20:19 custodial wallets offered by QVI. So we're looking to be able to build up in the
20:27 ecosystem alternatives for standalone wallets. And so with the capability that
20:36 this has at this particular point, are we talking about functionality that would
20:41 allow a holder of a legal entity level credential, an official organizational
20:47 role credential, ECR credential to accept that credential and then be able to
20:53 present it in whatever.
20:58 That's not KFU I think. No, no, that doesn't sound like it to me, but we
21:02 probably need to go into that a little bit more and understand because I would need
21:05 to understand implications of what you're I think what she's asking is it that's
21:10 really the wallet the open source wallets would be able to do that KF boot is is
21:15 bootstrapping the infrastructure the witnesses and watchers so if you set up
21:20 your wallet and you want to have four witnesses where do the witnesses come from
21:25 if you're not standing up your own witnesses you're just some person but
21:29 let's say company A has a witness service and company B has a witness service and
21:34 company C has a witness and a watcher service, then you would want to be able to
21:39 have a way to click on a list of service providers and say, configure me a witness
21:45 in this data center that has these properties. And then you could create your
21:51 witness pool from providers. But right now, it's just really basic. It's just
21:58 allowing the KERI Foundation wallets to configure witnesses and watchers. The KERI
22:04 Foundation stands up. Certainly, the idea is that eventually we want to have that
22:09 sort of plug-in architecture. It's just, you know, it's a resource thing. So, as
22:14 you see here, this KERI Foundation, that's actually a plug-in within this wallet
22:17 infrastructure. The idea would be that many providers could provide plug-ins that
22:22 could plug right into this and you could just choose from them and see what
22:25 services they have available and set up based on that. So, we do have the plug-in
22:29 stuff, but not the other provider. Thanks for the clarification. So, I'm always
22:34 interested in the wizard part of it, the user interface. I'm curious, is there…
22:40 what's your vision for… Say there is a duplicity event by launchers or observers.
22:52 How does that surface to the user? To the Verify, for example. I mean, there's… it's
22:58 pretty open to however an organization wants to implement that kind of
23:02 capability. We don't have anything built into it, just yet to handle that as it is,
23:08 but that's something that's pretty open to whatever tooling you want to put in place
23:12 to be able to watch for that event that's emitted by the watcher to say that there's
23:16 a duplicity thing and then whatever path you want to send it down at that point,
23:19 whether it's a pager duty message or whatever it might be, or even an automated
23:24 process that connects in and somehow rotates the keys automatically. I don't
23:28 know. It's kind of a decision-making process within the implementing
23:33 organization. So the mailbox can help with that because you can post duplicity
23:38 notifications into the mailbox and then your user experience would go, oh, yeah,
23:44 this particular AID that we're interacting with, their key state has evidence to
23:51 duplicity. And duplicity will be no duplicity and at some event there's
23:57 duplicity. And is it reconciled or is it unreconciled? Well, at that event, you
24:03 shouldn't trust anything that you do with that AID. So you can trust everything that
24:09 happens before. So if somebody presents you a credential issued before the
24:13 duplicity, you can trust the entries in their key event log. But at the moment of
24:17 duplicity, anything new you wouldn't trust. You wouldn't trust something they
24:22 signed because you don't know if the signature is with the correct key state
24:25 because the current key state is uncertain. So you don't do any new things
24:32 with them. And so your user experience would have to say, okay, you can't do
24:36 certain things with this entity because we can't trust their key state until it gets
24:41 reconciled. And in some cases they can reconcile it and then you can start
24:45 trusting, but then you'd have to see that it was reconciled. So you'd have to look
24:49 at their key event log and go, oh yeah, it was reconciled. They did a rotation. They
24:53 did a recovery rotation. It cleaned up their key state. Now I can trust it. I
24:58 can, but for that, so it is an important an important user experience that we
25:04 haven't we're just at the point where people building wallets need to address
25:10 that. So it's a really good problem to solve. And just to reiterate this, we
25:15 refer to all this as reference implementation because we are as a
25:20 foundation fairly resource constrained. And so we can't build all the things that
25:24 we want to build right out of the box. So we're working our way there as much as we
25:27 can. This is all meant to give an idea of what can be done with this and to give
25:33 some baseline to start from. It's all open source. It's all things that people could
25:37 take and start to build from. But obviously we're not going to be able to
25:40 build a fully fleshed out production level capability, at least not as we are right
25:48 now in the foundation. I want to go back to the point about the wallet being the
25:52 source of key events and the log. And two questions come to my mind. Is it the kind
26:00 of thing where if I run different devices, a laptop, a phone. I could have a single
26:05 wallet that shared persistence of where the wallet data was in the cloud and my
26:09 app was running. And in order for someone to inspect my key of that log, you have to
26:14 have access to my devices. So in the past, I never really thought about where the log
26:18 was. But now that the concept of the log being somewhere and can be looked at, can
26:24 be verified by a copy of the events. Yeah, well your witnesses hold a copy of your
26:29 log. Yeah, witnesses have a copy. That's recovery aspect of things. No, no. That's
26:33 for anybody to verify. Right. Okay. So they don't have to look in your wallet to
26:37 know what your log looks like. They just ask your witnesses. Do I only have one
26:40 device where my wallet is or can I actually access a wallet from my laptop or
26:44 my phone? Well, there's different wallet architectures. I know the rooting guys are
26:47 here and there's an open source wallet that Gleif uses called the Signify TS
26:52 architecture, which is a hosted wallet. So you have what's on your device, which is
26:58 your private keys. Everything else is in the cloud. Well, right. That's kind of
27:03 what I'm thinking is I've been in the world of Apple where the photos and things
27:07 get copied between device you can access your your cloud account securely from
27:11 multiple devices. I would certainly like to be able to do that with with my
27:16 identity in a KERI SIS from a log that had access to the persistent state of my log
27:21 somewhere under my control. I mean as we've been implemented right now that's
27:25 not possible just because what it requires is you to actually copy the keys to that
27:30 other device. device. You're going to create any kind of an event from some
27:33 other device. You've got to have the keys to be able to do that. So if you want to
27:36 spread out your footprint a little bit, then that would be possible. But we
27:41 haven't implemented anything like that yet. – What if my keys are stored
27:46 securely?
27:50 – Secure key storage is on a spectrum, right? There is no such thing as perfectly
27:58 secure key storage. So the question is, what are you trading off? So if I store it
28:07 in a secure enclave, secure enclaves have the property that you can't export the
28:12 private keys. I could store them in a hardware security module like a ledger or
28:21 an ubi key or something like that. Some of those allow you to export them. Some of
28:26 them don't. So it's a property of what they can do. because KERI supports
28:32 multisig, you could horcrox yourself so that you have multiple keys that control
28:40 your identifier, each key stored on a different device. And as long, then you'd
28:44 have to do like a two or three or something, or you could do a one event,
28:48 right? You could say any one of the keys can sign. I just need one key and that
28:55 just changed your security property, right? Or you could decide that if you're
28:59 that you're going to allow your private keys to be exportable and then you can
29:04 share them across devices but you share them in a secure out-of-band way. So for
29:09 example the hard drive is on my laptop and my secure enclave in my laptop in my room.
29:15 Yes. But the extension of that where that was now on Apple cloud service is less
29:19 secure just because those keys are not encrypted there. Well, no, you would want
29:24 to do that. I know, but is there a way? If you do end-to-end encryption on on Apple,
29:28 then they're encrypted and Apple can't see them. Okay, so that would be a viable…
29:32 Yes, that's a layer. That's a different… I mean, one of the things is you have to
29:38 look at the likelihood of exploit and the susceptibility to exploit. And this is all
29:43 part of survivability engineering. Survivability engineering says, how
29:50 susceptible are you to exploit? Well, if you're a high value individual, you're way
29:55 more susceptible to attack than grandma is. Grandma's got $100 in a bank account.
30:01 Nobody's going to spend more than $100 in resources to get it. Right? It's not worth
30:07 it. Which means that her security doesn't have to be as much as security at somebody
30:12 that has 4 million. Now like I know somebody whose
30:18 phone was SIMjacked. But that person had a Coinbase account with millions of dollars
30:27 in it. They went to a lot. They knew that that person had a Coinbase account with
30:32 millions of dollars in it. So they went to great lengths to SIM jack them. I know
30:36 millions of other people who have never been SIM jacked and nobody's ever
30:41 attempted to SIM jack them because there's no ROI to the attack. So storing your keys
30:50 in Apple's cloud end-to-end encrypted, Apple doesn't have the keys. The risk to
30:55 you is, do you lose the decryption key? That's your failure point. Not being in
31:01 the cloud. The cloud itself isn't the failure point. Strong encryption isn't
31:05 breakable. They can't break the strong encryption. What they break is your key
31:09 management. I'm just looking for a way to make the use of the wallet manageable. So,
31:13 yes. As opposed to confined to a device that might lose. That's right. So, some
31:17 people will complain and say, you know, you have to use hardware keys that are
31:21 stored on a device. And that's not a viable position to take because it doesn't
31:26 reflect the actual totality of the threat environment. For most people, storing your
31:32 keys in the cloud encrypted with an end in encryption is a viable place to store
31:36 them. And now what you have to do is not lose your decryption key. You have not
31:41 forget your decryption key. Well, if you have one password and you're storing
31:44 secrets in one password, then you have to say, well, is one password sufficiently
31:48 secure, right? For your threat profile, if it is, then there's all of those things
31:55 that are available to you as a wallet designer. When people are doctrine error
32:01 about certain thresholds of security without looking at the total landscape,
32:05 then they're not valuing the trace space correctly. And what they're either doing
32:09 is they're over securing things and adding too much friction to users they don't need
32:13 the security and they don't benefit from the friction. Or to solve for that, they
32:20 make everything the lowest common denominator, which means for people that
32:23 need more friction and need more security, can't have it. Is there a way for KERI to
32:27 actually play a part in rotating those encryption keys? Well, KERI is a protocol,
32:32 so it's not a person. I mean, there might be somebody in the hallway that's named
32:36 KERI. We can ask her as a separate application of a KERI service to keep
32:41 track of other forms of encryption. Yeah, that's not part of the KERI protocol, but
32:46 certainly it's something that people could. Well, I talked about hosted key
32:49 management. Right. So KERI enables hosted key management. So if people want to
32:53 provide a hosted key management service, Absolutely. I mean, I could have a
32:57 separate KERI account just for managing my own encryption keys. Yeah, that's right.
33:01 That's what I'm talking about. Yeah. All of those are available. Good questions.
33:08 Let's keep passing the mic. Oh, he's got one. Speaking of discoverability, I think
33:16 DNS is a beautiful protocol. Do you think it makes sense to embed some of the
33:23 witness endpoints into TXC records or SRB records. How are you thinking about
33:31 weaving this network? The way we use DNS right now is we use well it's technically
33:38 it's part of DNS right is the well-known protocol.
33:46 So if anybody that has a web service can make it so that all of their
33:51 infrastructure is discoverable by public publishing that those infrastructure
33:55 endpoints as well-knowns, right? So there's a well-known protocol called a
33:59 well-known protocol that you can publish and just say, you know, witness and here's
34:05 the identifier and here's the endpoint. And so we take advantage of that and
34:10 that's crawlable. So people can crawl the web, discover everybody's witnesses and
34:15 everybody's watchers from the well-knowns. So that's one thing. And then we have
34:19 something called an OOBI, right? The out -of-band introduction and you can publish
34:26 those and use those for discovery. So we do a lot of that kind of stuff. DNS
34:35 itself, you know, yes, you could publish in XPO9's anything you want, right? It's a
34:44 flexible document protocol. So I could see people publishing if they wanted to. I
34:50 mean, a certificate authority might want to do it that way. They may want to
34:55 publish stuff in X509s that enables discovery because the people are
34:59 discovering the X509s already. So I know he perked up because he's a CA. – So we
35:06 want to talk a little bit about Merkle trees. We got five minutes left and lunch
35:10 right here. So we want to talk about Merkle trees or what's that we were doing
35:15 next? Oh, yeah. Oh, sorry. Yes. So since it's about the current state of these
35:23 things, what watcher and witness infrastructure networks are available that
35:30 people plug into that are live today? Okay. Sorry, I forgot to mention that.
35:35 That we actually have a
35:40 handful of servers that are running on DigitalOcean that are available. We'll
35:46 publish, I don't have those up yet, but we'll publish the like that information of
35:50 where that stuff is. But there is a witness network and watchers available
35:56 that people can use as kind of an entry level into testing it out. Sorry, I don't
36:05 have that information up here. I don't have it in my slide deck, but we'll get
36:08 that out onto the repo, make sure everybody knows what IP addresses and all
36:12 that kind of stuff. But that's a good question. So, HealthKERI, they provide
36:18 witness and watcher services to their customers. So it's not publicly available.
36:22 You have to be in their space. The GLEIF ecosystem, there are witnesses that
36:27 various people run, but they're primarily for that. So the main, I think one of the
36:36 main outcomes of the state of Utah SEDI initiative is that you will, it will
36:41 force, it will be a forcing function for providers of KERI infrastructure to all of
36:48 the citizens in the state of Utah. So it doesn't exist yet, but one of the things
36:52 that we're doing is we're open sourcing the core libraries so that other people
36:57 can start to stand up those services. But nobody's spun them up yet because it's a
37:03 chicken and egg problem right now. It's like the state of Utah isn't using SEDI
37:07 yet. They're about to, right? And in order to do that, people have to start spinning
37:14 up witness and watchers and wallet services for citizens. So they meet weekly
37:19 to foster the community to start talking about these things. So it should happen
37:25 over the next couple of years. So that brings a follow-on question. So you said
37:30 HealthKERI has theirs that are working in their ecosystem. GLEIF has theirs that are
37:35 working in the VLEI system, but they're not publicly available at this point. So
37:42 then my question is as this… Well, they're publicly available to the extent you're
37:46 using a VLEI. Okay. So, but what are the advantages and disadvantages for
37:53 ecosystems such as health carrier, GLEIFs setup to make those publicly available for
38:00 other ecosystems to be able to auto to use as the watcher network? I think
38:07 advantages, disadvantages, why you would have your own versus you know, putting it
38:13 out into the global infrastructure. So, so that's a really good question because it's
38:19 about how do we bootstrap infrastructure, right? Who pays for the infrastructure,
38:23 right? That's a challenge problem. And Phil wrote a white paper, some
38:28 presentations about this. One of the challenges is the identity infrastructure
38:31 who pays for identity insurance. The state of Utah is going to pay for identity
38:35 insurance so that everybody gets identity insurance for free, right? And then the
38:39 question is who pays for the other infrastructure, which is witnesses and
38:42 watchers, right? Well, the state of Utah has a vested interest in making those
38:46 available for disadvantaged populations in the state of Utah. So they're going to
38:51 fund some of that. Every business that wants to leverage the free identity
38:57 assurance now has an incentive to make witnesses and watchers available to their
39:03 customers for free.
39:08 It's sort of how do you bootstrap that kind of infrastructure. And so with SEDI,
39:12 do you think… And I don't know if Phil had a comment. Oh, sorry. Okay. We've said it.
39:17 Do you see as this goes beyond the state of Utah and this new consortium that's…
39:22 Yeah, that's the idea. If other states adopt it… …that they'll start helping that
39:26 to happen. Yeah, it's the classical cold start problem for infrastructure, right?
39:31 How do you start infrastructure that benefits when the infrastructure exists?
39:36 And until it exists, everybody's like, well, if I stand it up and I spend money
39:40 on it, when do I make money? Well, I don't make money until I get to scale, right?
39:44 So, you have to you have this cold start problem. And so the state of Utah is a
39:47 forcing function to enable to solve the cold start problem. That's one of the
39:51 things that's really cool about SEDI is that we have somebody who has an incentive
39:59 to solve the cold start problem. Yes. And this state is also both an issuer and a
40:08 recipient of stuff. So they actually can create an entire ecosystem that then other
40:13 go, oh, that's working. Maybe I should sit on top of this or you sit beside it sit
40:19 beside it and use it so yeah so the state needs witnesses and watchers at scale to
40:24 interact with millions of citizens for no other reason than just the state to
40:30 conduct its own business but if you then at that point have witnesses and watchers
40:34 at scale for millions of citizens just to do business with the government it then
40:39 becomes easy for other people to say well wait there's already a there's already
40:43 millions of these out there millions of users, I can start to compete in that
40:48 space. I will offer a witness service because the state already created a market
40:53 for me. So that was actually the name of the proposal that I wrote to the state,
41:01 which is a public information utility, a public identity utility. So we're building
41:08 stuff in the KERI Foundation that we're donating to anybody. We're not going to
41:12 build those utilities. We're just providing the stuff for else to do it. So
41:16 somebody else has to catch the vision. And I know the reading guys are trying to do
41:19 that, right? Is that fair?
41:25 Yeah, they're not. Okay. I will contribute though from a blank perspective. It might
41:31 not be evident, but we have some internal bootstrapping going on in the way that the
41:37 governance framework is written for the BLEI issuers. So when anybody comes into
41:43 the infrastructure they can share witnesses. They have to set up five, spin
41:51 up five, but two of those can be shared. And then they have to increase the witness
41:57 pool by three. The overall VLEI ecosystem infrastructure by three at that point. So
42:06 that's how we grow our witness pool. And we have not even discussed at this
42:13 particular point in time whether it would ever be a possibility that we would offer
42:19 something to anybody outside our ecosystem where the public sector is much better
42:26 placed in order to be able to do such a thing. This gentleman here had to do it.
42:33 So I wanted to add another. So SEDI is an adoption vector that is trying to that has
42:40 to solve the cold start problem. Right? And the state of Utah has the best
42:44 industry. The healthcare sector has a similar problem. Now, it's the healthcare
42:47 sector, but those two start to move together. And the reason is that right now
42:53 in this administration, they passed new regulations that say all healthcare
43:00 information, people that work in healthcare, all patient data has to be
43:07 portable. So, they're saying we want patient data to be portable. So, those
43:11 regulations are causing problems in the healthcare sector because they have on one
43:16 hand all these HIPAA rules that say you have to protect this healthcare data and
43:22 on the other hand they just said but we have to make it portable and the reason is
43:25 is that providers in the healthcare sector tend to want to capture their patients and
43:33 one way they capture them is make it so their data is importable. So if I get a
43:37 bunch of tests done and I have a bunch of scans and things like that and I want to
43:41 go to a new provider provider, well, the new provider says, well, I can't treat you
43:48 because I need to do all of these tests. And you say, well, no, my other provider
43:53 did them. Just get the data from them. And the new provider says, they won't give it
43:58 to me because they don't trust me. They have no way to know that they can send it
44:02 to me and not violate their regulations. So the new regulations are saying, no, no,
44:05 you have to give it to the new guy. And the old guy says, yeah, but we can't give
44:09 it to the new guy because these other regulations say we can't do it. So KERI
44:13 and ACDC solves that cross-trust domain transfer problem. These two can trust each
44:18 other so they can move your data from one provider to the other. And that's patient
44:22 data, which means the patients now have a reason to have a wallet, have a reason to
44:27 have infrastructure, and that then starts to merge those two ecosystems. Because if
44:32 I have a wallet so I can do business with the state and I need a wallet so I can do
44:37 business with my healthcare provider, it can be the same wallet because it's the
44:40 same protocol under the hood. And now you start to get that flywheel effect. – I
44:46 assume. – Yes. – Wasn't the case already HIPAA took care of that just by the
44:50 patient authorizing the transfer, right? – They don't trust the patient authorizing
44:54 the transfer. It's, well, yeah, you can do it that way, but it takes weeks. – Yeah,
44:58 but I'm going to say that's the way it has been done. – Yes, it's manual, right? And
45:01 it takes weeks. – Right. – And if you're suffering from a serious illness and you
45:05 might not live weeks, that doesn't really help you, right? – The patient's
45:08 essentially the middle man. – Yes.
45:12 So back on the topic of public infrastructure. Yeah. I'm curious if
45:17 you're familiar with the app protocol ecosystem and their identity system did
45:22 PLC. Yeah, I've heard of that. Yeah, I see it is kind of like a it's not KERI, but
45:28 it's like a verifiable key history. So it has some similarities. I think it's easier
45:31 to use, but doesn't have the same security properties. But one of the things I think
45:36 is nice or convenient about the ecosystem is they just provide a directory service,
45:42 which is like analogous maybe to a witness. But I haven't really thought
45:46 through kind of the security properties of it because like like de facto it's a
45:51 centralized directory. Yeah, that's right. But it's interesting relative to this
45:55 question. Yeah. So if I centralize things, it makes it much easier. The world becomes
46:00 really easy when I centralize things. So that's always been a problem for KERI is
46:05 that we wanted KERI to be fully, totally zero trust, decentralized and that means
46:10 we have a hard problem to solve. So yeah, I get it. We created a hard problem by
46:17 forcing it to be totally decentralized. But that's why we've been searching for
46:21 these forcing functions like healthcare or state of Utah. Actually, prominent telecom
46:26 is not a forcing function because it all happens behind the scenes. When it stops
46:32 call spam, it's your cell phone provider that's signing and checking the
46:37 signatures. You, the user, never never even know that it's happening. You just
46:40 see something on your screen that says, yeah, this call came from Microsoft. You
46:45 can trust it. And you go, okay. – And I would say that is actually a turning point
46:53 for KERI because the early use cases were all organizational, right? – Yeah. –
46:59 Provenant, those kinds of things. – Yeah. – So state of Utah, health, health KERI,
47:05 those are things that are different than what has happened before. So we need to
47:10 watch them because that will say, you know, how does this actually work? Yeah.
47:16 Yeah. Yeah. That's what that's given me. That's why I'm optimistic because I see
47:21 those as real serious adoption vectors and there's drivers that aren't going to go
47:26 away. There's regulations involved. All of those things are forcing functions that
47:30 will force things. And let me say something about, I mean, I don't want to,
47:37 I mean,
47:41 DidPLC, DidRevvh, there's a couple of other ones, have adopted many of the
47:47 mechanisms in KERI for key state. What they have not adopted are the mechanisms
47:54 for perpetually verifiable issuances, which means you can't use them for many of
48:00 the applications that people want to use them for. It's similar to my criticisms of
48:05 zero knowledge proofs. You can't use them for things that for issuances that need to
48:10 survive a long time because there's no way to verify them once you rotate keys. You
48:13 know you rotated keys, but everything issued under the old keys becomes
48:17 unverifiable the moment you do it unless you're anchoring those issuances to your e
48:21 -state. That means they have to change their protocols and as soon as they do
48:25 that, they now become as complicated as KERI and why do it that way then? Yes. –
48:30 So I wanted to add to that to what you said. So I'm involved in DIDWebVH and
48:37 involved in decentralized social protocols such as AT protocol. I'm familiar with
48:42 DIDPLC, etc. To add to what Sam is saying that there first of all, there is osmosis
48:53 of KERI security properties to some of the DID methods for those exact same reasons
49:00 because it's same shape of the problem, same security space, very similar shaped
49:05 solutions and things like that part
49:10 of the unsolved problem in both DIDWebVH space, in the social media space and in
49:16 KERI as we've been discussing is exactly who's going to run the infrastructure,
49:21 right? In social media space, it's always been Twitter. Okay. Twitter's running the
49:28 infrastructure or Facebook or whatever in the hopes of monetizing. Blue Sky came
49:34 along who is operating DIDPLC, the servers. and they're providing the
49:38 infrastructure and they're venture capital funded in the hopes of finding a business
49:45 model and monetizing, right? What's the alternative? The essentially one and a
49:50 half to two things that we have been mentioned governments, right? So on the
49:55 federal state or city level like SEDI or what we've been seeing in the
50:00 decentralized social media space such as Macedon, basically small communities and
50:05 volunteers. Right. Yeah. It was run the common infrastructure of the… Yeah. And,
50:11 and, and yeah, so it, it, it has its challenges. I'm not saying that it's not
50:16 challenging. So how much, we got 10 minutes left? You got a question? Somebody
50:22 else had a question. Yeah, I was going to say, did PLC? They can't hear you on the
50:27 recording.
50:32 So there's delegation and multisig are challenging to get right in a way that is
50:39 usable. And those are things two things that KERI does that no other DID method
50:43 does. I've looked and I could be wrong. It's been a while since I've looked at
50:47 DIDWebVH. But when the last time I looked at DIDPLC… – Well, I read the DIDWebVH
50:53 latest spec as of like three weeks ago and it doesn't have any of those in it. –
50:58 Yeah, so I… – Is that right? – It's it has a new user space. It has it in application
51:05 space, not in the protocol. So for those listening to the recording, VidWebH is
51:12 working on multisig in sort of application space, not in the signature space. So
51:19 they're trying, they're working on it. Yes. Once you decide to accept you need
51:24 multisig and delegation and anchor disuances, you have KERI. Completely.
51:30 You've recreated exactly the same thing. I got one. Yeah, we got 10 minutes left. 10
51:41 minutes left. Well, I could talk seven minutes. I could talk a little bit about
51:45 how witnesses and how witnesses solve the detectability problem and the availability
52:01 problem. You guys interested in that? So a lot of KERI infrastructure, a lot of KERI
52:09 protocol does multiple duty. It's like for me a sign of a good design is that I
52:20 design something to solve one problem and then serendipitously it solves other
52:27 problems that I hadn't yet got to yet. And they go, oh, wait a minute. this also
52:32 solves that problem. So delegation, delegated AIDs solve multiple problems.
52:38 Witnesses solve two different problems. The first problem they solve and Ryan
52:45 mentioned this, the first problem is availability. So originally, one
52:54 of the problems that people complain about is, well, if I have a wallet and all my
52:57 keys are in my wallet and my wallet it's offline, nobody can verify my key state
53:03 because my wallet's offline. I can't have a presence because my wallet has to be
53:11 online. And a lot of people approach it and say, well, then I need a hosted wallet
53:14 so that my host has my stuff. And so a lot of people solve it that way. I have hosted
53:20 wallets. Now they go to the host to get it. But the problem is, is the host now
53:25 becomes something I don't control and I can't trust. And so now I've basically
53:32 solved the availability problem, but I've introduced an even worse security problem.
53:38 So witnesses solve the availability problem without introducing a security
53:42 problem. Yeah. What's the threat model on the host? You said something you can't
53:50 control. Aren't the key event logs still secured by the user's keys? Well, my copy
53:59 is secured, right? But the host could publish a key event log to anybody they
54:05 wanted to and I wouldn't know they were publishing a duplicate copy. I wouldn't be
54:09 able to tell that they were cheating. Got it. Right? So because they because my host
54:14 can eclipse me. So I'm subject to an eclipse attack if I just have a host. So I
54:20 need an eclipse attack proof availability mechanism. Well, the only eclipse attack
54:25 proof availability building mechanism is a Byzantine fault tolerant distributed pool.
54:30 Now, it doesn't have to be total ordering. It just has to be Eclipse
54:38 proof. So when I say deconstructed block data, I said I've got to solve this
54:44 Eclipse attacks problem. The only way to solve an Eclipse attacks problem is a
54:48 distributed pool, but I don't need the distributed pool to do a total ordered
54:52 replicable state machine, which I need for double spend proof. I don't have to do a
54:58 double spend proof. I just have to know that there's duplicity. Double spend proof
55:03 is actually duplicity hiding. It says there's only ever one valid copy and if
55:08 somebody cheats then we'll just take the cheat and say yeah that's the true state
55:14 because the cheating is they've compromised your keys. So I need to detect
55:19 that my keys have been compromised. I'll also have it be highly available and so
55:24 that's why it's solves multiple problems because it solves availability with a
55:30 distributed pool. There's lots of ways to solve availability. You can have master
55:34 slay or whatever they call it nowadays. Sharded. You can have a sharded
55:40 architecture. You have a host architecture. There's lots of ways to
55:42 solve availability, but a distributed pool of independent servers that exchange data
55:52 using a fault tolerant exchange change algorithm is a way to do it. The reason
55:59 you pick that way is because it doesn't just solve the availability problem, it
56:04 solves the eclipse problem. So it prevents you from being eclipsed. Now you need to
56:12 control that pool so that you don't have to trust anybody. So it's under your
56:17 control which means that ultimately they can't trust what you published because you
56:23 could publish, you could do an eclipse attack on the people reading from your
56:28 watcher pool. That's why, I mean, reading from your witness pool, that's why you
56:32 need to have a watcher pool that they control because they can then detect that
56:36 you're not eclipsing them. So it's just one step after another to go, okay, I have
56:41 to solve this problem. And then once I solve it, then it's done. Yeah. So you
56:46 have availability, eclipse attack, and then detection. The third one is detect
56:53 detect key compromise. Now here's the thing. If I'm doing a
57:04 key event log, the key event log doesn't enable me to detect key compromise.
57:09 There's no key compromise detection in a key event log. The witness pool gives me
57:16 key compromise detection, but only if I'm anchoring issuances. If I anchor issues,
57:21 the only way I can get anchored is it gets entered in the key event log that a
57:26 witness witnesses. And if I have my own copy of the key event log and I check my
57:32 witness and the witness has a different copy than I have and there's stuff in the
57:35 witnesses copy that is anchored that I did and the only way I can get there is if my
57:39 keys have been compromised then I detect the key compromised. But until you anchor
57:43 issuances you can't actually detect key compromised. So you don't get the most
57:46 important security property of KERI which is I can detect key compromised. You have
57:52 to trust that there's some other mechanism to detect your keys. So yeah, you can
57:55 rotate your keys, but you don't know when to rotate. With a witness pool, you know
57:59 when to rotate. But the witness pool doesn't tell you when to when to rotate
58:02 unless you're anchoring issuances. Any issuances that aren't anchored are not
58:06 detectable when you get your keys compromised. So you don't need to anchor
58:10 everything because not everything's important enough. But the important stuff
58:13 you anchor and that allows you to detect it. So without anchoring, you've missed
58:18 most of the security properties of what KERI provides. But it's complicated,
58:23 right? You have to complicate your system. Okay, I'm done. Thank you.