0:00 Okay. So this is a little bit of an audible on what we're going to present.
0:11 Some of you may have seen this or some that are watching may have seen this. I
0:15 went through this in our first KERI conference. So it's a little bit geared
0:19 toward the infrastructure as it was back then, but I'll kind of update on the fly
0:24 as we go through this to where we are now. demo. We already showed you these repos
0:31 that we'll be dealing with. There's a setup guide out there which I mentioned is
0:35 a little bit outdated. This is geared toward running an infrastructure on one
0:40 host and in a demo sort of way as opposed to what we have now which is four
0:44 different hosts to spread out the services. So and there's the there's a QR
0:50 code to the oops sorry if people want to follow along with the setup guide you you
0:56 can hit that QR code and pull it up.
1:07 This is a little longer now than it was originally. So core concepts here is I
1:14 mean obviously we've talked about KERI being all about keys, key events. I'm
1:20 going to kind of jump through these fairly quickly till we get to the well let me
1:23 just jump to the more important stuff. off. Okay, so as Sam showed this one
1:31 earlier, this is the KERI ecosystem, kind of the basics of the KERI ecosystem. What
1:37 we're going to go through is kind of a setup guide of how we actually set up this
1:41 infrastructure and what exists out in DigitalOcean right now and how you could
1:45 actually deploy this kind of a stack yourselves. Any of you who are more
1:50 technically inclined or want to get into some of this stuff. So it's not terribly
1:55 technical but there is some more technical detail for those who are interested in
2:00 those kinds of things. So the core components, we have our boot service, as I
2:07 mentioned, we have witnesses and we have watchers. So these are a good way to
2:11 remember that. Just watch all these movies and then you'll remember that.
2:18 If I have questions, should I ever watch the movies? Yes. Yeah, just go back to the
2:22 movies.
2:51 It's still not. It's all Python code. It's not as early anymore. This was several
2:58 months ago when this came up. But this is really a demo only or maybe not quite to
3:04 the point of a staging environment that you could use, but it's definitely not a
3:07 production kind of a deployment. So keep that in mind. This is what a production
3:13 deployment might look like. Maybe-ish. If you were to imagine the wallet having
3:18 connections to multiple different providers of plug-ins in the wallet itself
3:24 and each of them is connected to some sort of cloud or data center and they
3:29 distribute the services throughout according to availability zones and
3:33 regions and all that kind of stuff. It might look something like this. Again,
3:38 this is not something we say that you should do or you have to do, but maybe
3:42 that's what it would look like. That is not what this looks like. Yeah, yeah, Ken.
3:46 So is it intentional to have only one KF on each data center? It doesn't really…
3:52 well, there's two actually here. Two, but… and it doesn't really matter. Actually,
3:58 there's two on both. Right. So, you can run advantage. You can make it as
4:01 redundant or as not as you want. KFboot can handle quite a bit, so you wouldn't
4:07 necessarily need to make that vastly redundant. But, I mean, if you want a
4:12 really resilient service, obviously, you won't at least spread it out across zones
4:15 or something like that. So, can I say something? Yeah. Yeah. In a full
4:19 production environment, every service is potentially subject to DDoS attack, which
4:26 means that you have to have load balancers. That's the only way you're
4:29 going to be protected from DDoS attack. So all of these services have to sit behind a
4:34 load balancer, otherwise somebody could just DDoS them out of existence. For sure.
4:39 Yeah. And so what the plugin architecture of the wallet allows is that you could
4:45 have like let's say a KERify.net, which I don't know who owns that? It might be
4:50 someone in this room that might own that particular domain. But that particular one
4:55 might be two different data centers that's spread out across their entire
5:00 infrastructure is spread out across two different entirely different cloud
5:04 providers or something like that. Whereas a KERI foundation might be just in one.
5:08 So, you know, there's a million ways you could figure that out and smarter people
5:11 than me can come up with the best ways to make a really solid KERI ecosystem that is
5:17 very resilient and powerful. but that's not really what we're solving in the
5:20 foundation right now. So, base requirements for this as it is right now.
5:30 Ubuntu 24.04 is what we built it on. I think that's the latest LTS or maybe 24
5:37 .10. Yeah, 24.4, I think. Libsodium, which is the crypto library. PySodium, which
5:46 wraps Libsodium. Nginx, which handles the reverse proxying and TLS termination.
5:56 Certbot to just handle the certificates and Circus to actually manage the
6:02 services, the Python services themselves. So those are the kind of base requirements
6:07 for this setup.
6:11 The way we set it up was we created a service user called KERI There's no login
6:18 on that one. It's just key only and it's just kind of for that purpose.
6:25 It's only meant for the service itself to run. It's not really meant to be logged
6:29 into. And this is the path that we put it in. Again, this is all just how we set
6:38 this one up. It doesn't mean you have to do it that way. We also use UV and Python
6:43 3.14 specifically in this case. So anybody have any questions or anything you want to
6:49 say, certainly chime in because I'm going to move through this fairly quickly.
6:56 And there's three installs that you can do. Now, this is based on releases that we
7:00 have not actually done yet. So we haven't actually released into like into Pypy or
7:05 anything with opnet and WADopnet as those names just yet or KFboot for that matter.
7:10 But you can install them straight from from GitHub. If you just point to the
7:13 repos, you can install them at whatever point you want. want to. So, but
7:18 eventually the plan is that we'll create formal releases for those and we'll
7:21 release them out into PyPy and then they'll be available under those names.
7:28 Next, the configuration. Again, this is based on a single host with multiple
7:37 instances running. In the real case that we have now, you wouldn't need four of
7:43 these on the same host, but you would create one of these to determine what the
7:48 URLs are that will be available to Locksmith when it connects in.
8:00 Sorry. And the watcher one looks very similar. Just need one of those. Launch
8:10 scripts. This is for being able to actually launch the commands that run the
8:16 services. So again, anybody have any questions? Caller out or… Yeah, just some
8:24 tips for our… Microphone.
8:30 So, thank you. So is the WIT opnet and the WOT opnet, is that just one per process?
8:37 So it's not like something that provisions many, it's just one per process. Just one.
8:40 Yeah, just one instance will run, you know, one like one watcher, for example,
8:48 or one witness, for example. So as many of those as you run would be it's a one-to
8:55 -one, you know, does that make sense? Okay. Yeah. Thank you.
9:00 Okay. And KF boots config. All this stuff is again, this is all in the guide itself.
9:06 So if you're following along or if you want to actually set this up, all this
9:09 stuff is available in that guide. So this is mostly just to kind of give you some
9:13 view of it. in this setting here.
9:21 Just one of the environment variables to… Sorry.
9:31 I think this is actually out of date. Sorry. I'm going to skip this one. Let me
9:35 jump past this.
9:43 Yeah. Yeah.
9:49 Okay. And then pretty simple circus install.
9:59 And then certbot and all that stuff gets set up as well. So that's the core pieces
10:05 of what it takes to actually get this stuff up and running. All right. Okay. So
10:13 all that being done, apologies for the issues there, but all that being done, you
10:21 end up with four
10:25 witness processes, watchers, and a KF boot. And right now I have this running.
10:33 I'm only doing this locally right now, but I have in this one here is KF boot along
10:38 with a witness and a watcher. This is going to mirror more how we're actually
10:42 running it now in our environment in DigitalOcean. So the KF boot is running on
10:49 one host with a witness and a watcher. And on the all subsequent hosts, there's
10:55 actually three others. They're just one witness and one watcher instance. And with
11:00 that setup, I can actually run Locksmith. I'll just give you a quick view of this
11:09 and we'll get into a little more details about Locksmith in a second. And so what
11:13 I'm doing, this is a fresh clean version of Locksmith that's just starting up with
11:18 as if it was brand new. And initialize a new vault first of all. We'll just call it
11:24 demo.
11:28 I'm going to add a this part here I'm actually creating my ID, my AID.
11:37 And now you see there that KERI Foundation is the that's the plugin. in itself. And I
11:45 have it configured so that it connects to my local Docker to hit those hosts. And
11:51 you can see that it's the connection is connected here. So it's able to make that
11:55 connection. I choose that AID from the list. I'm going to do a three of four
12:02 because I have four instances running. And when I click this, if I had all four
12:09 terminals, it'd be cooler, but But you'll see basically what's going on with KFBoot
12:14 on the left side here on your right and the witnesses and watcher service on the
12:21 other side. So you can see that this is actually doing stuff for real. It's not
12:26 we're not just kind of vapor wearing this. This is actually doing what it's supposed
12:30 to do. And on this side. Can I ask a question? Yeah. So this is locksmith on
12:36 either your local computer.
12:41 Microphone. Clearly I need help. I think it's just that I'm tired. It's the end of
12:46 the day. All right. So this locks what I'm looking at and I want to make sure I'm
12:49 understanding what I'm seeing here. Sure. Yeah. This locksmith you're running on
12:53 your machine is targeting those digital ocean machines that you've got. And it's…
12:58 No, not right now. Okay. This is my local locksmith that's pointing to my local
13:02 Docker deployment of four hosts, which is exactly like we have it in in
13:10 DigitalOcean, but there was an issue with the DigitalOcean environment right now. So
13:14 I'm just running it locally. But as far as the actual structure of it, it's set up
13:19 the same way. Got it. So it's just using local URLs? Is that the only difference?
13:22 This is all done locally here. Okay, cool. Got it. That's it. So it's a little bit
13:26 canned in that sense. But as far as the code, it's all running the same code. It's
13:30 deployed exactly the same way. I'm just running it on my local host here. So any
13:35 other questions about that? You see we got this QR code back, which basically means
13:39 that our witnesses got connected. We can go back over here. You can see all the
13:45 lists of the witnesses here and one watcher that got connected to the wallet.
13:52 So, I'm sorry? What is the QR code for? What do we do with that? You can scan it
13:59 and it'll take you to like an authenticator app if you have it on your
14:03 phone. Oh, right. That's right. So now everybody can steal his local witnesses.
14:08 Right. So at this point I'm going to turn it over to you to give a little more.
14:14 Yeah. So because a controller controls their own witnesses, you can add MFA to
14:22 your witnesses so that even if your keys were compromised, your signing keys were
14:30 compromised, they couldn't publish your witnesses unless they also compromised
14:34 your NFA, your MFA. Okay. So that makes it doubly hard for them to publish anything.
14:41 And even if they've compromised your keys, that isn't enough by itself if you add the
14:47 MFA to your witnesses. So that's built into the witness structures and MFA. So
14:52 you could do a you don't do pass keys right now. You just do authenticator apps,
14:59 right? Yeah. So you have an authenticator app that you'd have to also pass in
15:02 addition to sending a signed key key event to the witnesses. Right. So any questions
15:09 at this point? Anything else you want to see about that? Particularly, I'm going to
15:13 give Evan some time to show you a little more, maybe talk a little more about
15:17 Locksmith itself. – Data storage is just local files. – LMDB. – LMDB. – So you need
15:23 to use a staple set. – Use a what? – Staple set like in Kubernetes. – Yes, yes,
15:33 yes, you would need to. Yeah, for sure. Definitely. Definitely. Yeah. Definitely.
15:36 Yeah. The reason he's using Circus is for is so that you could run your witnesses
15:46 and watchers bare metal, which means that you're not you're not exposing yourself to
15:52 all of the Docker Kubernetes security vulnerabilities. Right. Most people don't
15:57 know this, but NIST released a report that says anybody that care I'm paraphrasing
16:01 anybody that cares about security does not use Kubernetes. because it's a single
16:05 point of failure for all of your infrastructure. One compromise of one IT
16:09 person's keys compromised 100% of infrastructure. And one of the recent
16:13 supply chain attacks was an AI that was collecting Kubernetes credentials. And if
16:20 that attack had gone on longer than I think they caught it after a few hours, if
16:25 it had progressed, it would have captured all the Kubernetes credentials for
16:30 everybody's cubes over the whole internet if it had had time. time. And so it would
16:35 have brought down the whole internet hard. And that's because Kubernetes has a single
16:40 point of failure. A single credential is enough to take down everything. And that's
16:44 why NIST says if you care about security, you don't use Kubernetes. I know everybody
16:48 hates that if you're in DevOps, but we at least did it in a way that it will run on
16:54 bare metal. So you can't say, oh, well, you guys didn't give me a way to be
16:58 secure. So if you want to run in Kubernetes, you know, by all means, at
17:03 your own risk, but you can use this bare metal if you want to. I was tired of
17:06 running on bare metal. I know bare metal hurts.
17:14 It's true. All right. We'll give the mic over to Evan for a minute to show a little
17:20 more of Locksmith. Maybe talk a little more about that specifically. Do you need
17:24 this? I mean, I could just click through yours. Yeah, by all means. I don't know if
17:28 people have questions about other things in Locksmith.
17:35 Locksmith as a whole, you can go back and you have these isolated vault environments
17:42 where you can hold different sets of keys. You can have two-factor authentication on
17:51 your vaults. If you download a password, there's no password. Yeah, you can get
17:59 remote identifiers. This would be how you connect to other wallets, for example. So
18:05 if you were able to do some sort of out-of -band introduction with identifiers from
18:11 other wallets, you could import them here. You would see them here. That's why when
18:15 you see like the these
18:20 identifiers, witnesses and watchers, they'll show up as remote identifiers
18:25 because they have identifiers associated with them.
18:31 And then yeah you can add like identifiers on your account. So the way we we have
18:37 created this plugin in Locksmith and our overarching idea is that when other people
18:42 want to contribute their own infrastructure they're able to just add a
18:47 plugin to this menu and add their own compatible infrastructure. And that way
18:55 you don't have to rely on a single service provider within your wallet to get
18:59 witnesses and watchers.
19:03 So the method for like creating a plugin is really simple. You can kind of like if
19:07 you want to you could just like copy the folder of code in the repository, register
19:14 a new plugin here and then change your UI to your heart's computer. So I'd really
19:20 love that if somebody in here who's building KERI infrastructure writes a
19:25 plugin for this so that we can publish that and then when we do a demo they'll
19:29 have their logo up there and not just the KERI Foundation. Just saying.
19:35 On that note, so is the plugin just essentially discoverability for let's say
19:42 I had like a testnet infrastructure and I want to connect my Locksmith to my
19:47 testnet. Do I would I then write a plugin so the Locksmith knows where to look or
19:52 like what exactly is threaded through the plugin? Yeah, it would be where to look
19:56 for the infrastructure. So like for example, the KERI Foundation plugin is
19:59 looking at KF boot, which is kind of our infrastructure orchestration. So if you
20:04 wanted to do your own version of that, you could just have it talk to your… – And
20:08 there's config in the plugin itself that lets you specify those addresses or hosts
20:13 or whatever to designate where it's going to look for that stuff. – Isn't the config
20:17 just a JSON file? – Not in this one. It's code for this plugin code. It's just part
20:25 of the code. Yeah.
20:29 Yeah. We also are working through credential exchanges.
20:34 So you're able to load in schema and then apply for credentials and issue
20:42 credentials. And we're working towards getting Sam's full IPEX exchanges, which
20:48 are issuance and presentation exchanges between two wallets working. These are
20:54 version two. Yeah, this is version two. of KERI and ACDCs. – When you say credential,
20:59 that's ACDC. – Correct. – Right. – Yeah. So the IPEX exchanges will allow us to
21:04 create those beautiful graphs of delegated authority that Sam was showing us earlier.
21:12 – So at the SEDI summit demo, the graduated disclosure, which is what is
21:23 supported in IPEX v2. So the current set of infrastructure that the people are
21:31 using ACDC for credentials like VLEIs aren't doing graduated disclosure. That's
21:36 in the spec, but it wasn't fully implemented. So we're fully implementing
21:41 that part of the spec. So we don't have it in the wallet yet, but that's our target
21:48 is two weeks from now to have it running in the wallet. We have it very close.
21:51 There's a one remaining, I think only one remaining edge operator that has to be
21:56 implemented, which we have an actual PR for which hasn't emerged yet, but it's
22:00 very close. So we're we are well on our way and should be ready to go for the SEDI
22:06 conference to have this whole IPEX exchange in place. So that's coming along
22:11 quick. Yeah, good question. So let's say let's say I'm a city and I want to set up
22:20 a witness for my the residents of my city. So I set up what I set up one, two, three,
22:30 four of those maybe. Well, our recommendation is either it's either one,
22:34 which is not as secure, but it's either one or it's four. So you can do a three of
22:39 four. Right. Okay. So, but ideally again, if I'm just checking my knowledge here. So
22:46 like let's say my city sets up one witness. Okay. And then let's say my bank
22:53 sets up a one witness and then let's say my university sets up one witness. And so
23:01 then I now I make an identity and then I say, okay, I want my city and my bank and
23:10 my university to then witness my logs. And that's a secure way. Is that am I is this
23:17 am I saying right stuff here? Each of those would be the currently the way it's
23:22 built. each of those would be a separate plugin in the wallet and you could do a
23:26 configuration of one per each of those. So my bank and my university and my… Yeah. So
23:33 if they provided plugins to the Locksmith wallet, I believe it's right. You could
23:37 configure the identity to use four witnesses from four different plugins.
23:44 Okay. Different organizations. Yeah. Yeah. Yeah. Okay. And so, okay. Follow-up
23:50 question to that. Yeah. So if I'm again, I'm a city. So let's say I set up one
23:55 witness in the city and that one witness can support all of my residents. So I can
24:02 have there'll be multiple AIDs and all those AIDs can use the one witness. I
24:08 don't have to like I don't have to instantiate another witness per AID. No,
24:12 no, no. Yeah, yeah. So I wouldn't recommend you do it that way. I would
24:17 recommend that you have one witness service. and then that witness service is
24:24 a host that's running witnesses, but each witness for each person could have a
24:29 different identifier. But if you did one witness, it would work. So you can do one
24:37 witness with multiple AIDs, but that's not recommended? Is that what you said? Well,
24:42 it's just… Again, I'll have the other ones too. Yeah. But if my university does that
24:51 and my, you know, if all of those locations do that and I'm using all of
24:57 those, then it's okay for just the city to do that. Yeah, it'll work. It's okay. It's
25:06 not ideal. But you got to understand that I live in this ideal world. Right. So. And
25:13 you got to also make sure we make the distinction between the witness service,
25:17 like WitOPnet is a witness service and each one that… – Yeah, each AID gets its
25:24 own witness within the witness service. – Within that service. – So that's why I'm
25:27 saying this is that you your bank would set up a witness service, but it wouldn't
25:32 use the same witness AID for everybody's wallet. It would just spin up a separate
25:37 witness. All that… so that separate witness is really just an AID that says
25:45 I'm going to sign with this AID. So everybody's witness is signing with a
25:50 different AID. So you're not reusing AIDs to sign receipts. But you have one witness
25:56 service that is basically running an endpoint where people send events to it
26:00 and it has one database and it's storing the stuff in the database. Sorry, Karla
26:07 had a question. Oh, yeah. Have you made any load tests on this service? We haven't
26:16 gotten that point of really hitting it with a lot of load. No. But I don't know.
26:21 Healthcare might have done that. We haven't done that as a foundation. We just
26:24 haven't had the resources to really throw that much at it just yet. But it's a
26:28 fairly lightweight services though. So it's hard to imagine that it would… It's
26:33 in my to-do list. I would share results whenever I get to it. For sure. Yeah,
26:39 actually it was more of a comment than a question. I was going to bring up the
26:43 issue or the concern of consideration of scale because GLEIF set up five witnesses
26:50 for the infrastructure for the VLEI and each QVI has to set up a total of five as
27:00 I said before with two that they could share from existing witnesses that have
27:06 already been spun up. So net each QVI adds three more witnesses to the overall
27:14 witness service for the the VLEI ecosystem. And that was in order to be
27:19 able one of the considerations with scale. Yeah, we haven't put it through major
27:25 scale testing, but then again, to be clear that you're talking about witness
27:29 services, right? Not witnesses themselves. Witnesses themselves.
27:40 So witness service of every two of them. My own. Take my own. My own advice. Each
27:47 ecosystem governance framework requires that each QVI set up five witnesses. And
27:54 in total, it's one witness service with five witnesses or more of that witness
28:00 service. Okay. So it's not a big code change to change the witness so that what
28:12 you're now calling a witness could become its own witness service. So it's the same
28:17 endpoints and stuff like that. You're just allowing it to have to create AIDs on the
28:26 for each wallet that wants to use it as a witness service. Right? And so it creates
28:34 the AID for the wallet, not for the whole witness service. Now, would that be a
28:41 consideration right now? mostly everything is running on a custodial wallet from the
28:47 QVI's that offer that. Would they have to do that? No, for a custodial wallet, they
28:53 may want to do it a different way. Right? The thing is, is it from it's really we're
29:00 not talking KERI protocol anymore. We're talking infrastructure deployment. KERI
29:07 just says there is a witness with an identifier that you designate as the
29:13 witness for your KEL and when and you need a witness service and a witness service
29:18 could be one service with one AID that witnesses multiple KELs or it could be a
29:26 witness service that allocates a different AID for each KEL it witnesses. Those are
29:31 two different arrangements and there's some niggly differences between how they
29:39 perform. But under the hood, the infrastructure is the same. You have a
29:43 database that stores KELs and you receipt KELs when you get them and the service
29:48 says, oh, I witnessed this KEL, right? And I sign it with what AID? Well, if I have
29:55 one, I sign every KEL I witness with the same ID. If I have one AID per KEL, then
30:00 if I'm witnessing an event from this KEL, I sign it with a different AID than if I
30:04 witness an event from that KEL. That's the only difference. It's just whether you
30:08 multiply the AIDs or you have one AID. And multiplying the AIDs means that you have
30:14 more flexibility in terms of adding and subtracting services and stuff like that
30:19 because you're not locked to one AID for everybody. Because if that AID gets
30:26 compromised, it's compromised for every KEL that it witnesses. And so that's why
30:30 it's that's why it'd be better to have an AID per KEL than one KEL shared across
30:35 multiple AIDs. So on that note, is there anything with regard to provisioning or a
30:43 provisioner in KF boot or is right now is KF boot more just an interface for
30:50 something like Locksmith to use that plugin to discover already provisioned
30:55 infrastructure? No, we do provisioning. Like the way that the code that we got was
31:00 set up is that like the witness HK to create witnesses you had to hit like its
31:10 local endpoints. And so you have to put like a we had to put the boot service on
31:16 the same machine as the witness service so that we could securely create witnesses
31:24 and watchers and coordinate all that. So it does provision. Oh, so help me
31:28 understand that. So the boot service can talk to the widopnet and the watt optnet
31:35 to provision witnesses and watchers on demand. Correct. Do you have the you can
31:39 pull up like the witness and watcher repository. The readme is good. Oops.
31:43 Sorry. Pretty good. Browser around here somewhere.
31:59 Just gonna win.
32:05 Yeah. So like in here
32:15 Here's the HTTP API. So to provision witnesses for these controller AIDs,
32:25 you're hitting these like boot server ports.
32:32 And then to like actually talk to your witnesses. is there's a different port to
32:37 that. So you said securely provision these things. Is there a what's the relationship
32:46 from a security perspective between your Locksmith wallet and the boot server? Is
32:51 that determined by something? Is that part of the plugin configuration? And is it
32:55 just okay? You probably want to use like ESSR to talk to your things, but I don't
33:00 know if we have all that set up. Okay. So the Locksmith talks to the boot server.
33:06 The boot server then is installed in the same infrastructure where it's allowed to
33:11 provision through these boot ports. Okay, I gotcha. So this is the that's the config
33:18 file inside the Locksmith code and that's those are the two addresses that I gave it
33:22 to point to my local Docker. Earlier I had those pointed to our our DigitalOcean
33:28 environment just to make sure I could connect to it and I could connect okay to
33:32 one of the hosts but a couple others were having trouble which is why I did the
33:35 Docker thing instead for this particular demo. But that's where you change that. –
33:39 So final question, is the same approach being taken towards essentially every
33:44 infrastructure repo inside of the KERI Foundation is that there's like a boot
33:49 port where you can boot one up and then it's just there to use for Locksmith? –
33:54 Wait, say that again. Sorry. – Like it's the same provision or approach being taken
33:58 to the mailbox and the other infrastructure. – Those will be a little
34:02 bit different, but But we're still kind of in development on those, so I'm not going
34:05 to speak to those too much yet. So I don't want to give you an answer and then end up
34:09 doing something else. So, you know, we'll try to keep it as consistent as we can,
34:14 but we're not sure yet exactly how that's going to last. Okay. I have another
34:18 conceptual question here. So I asked about witnesses before now on the watcher side.
34:25 So now let's say like I'm a car salesman. Like I have a lot of of cars and I want to
34:34 you know get financing or somebody and so that is that a situation where then I
34:40 would I would need some watchers then to to watch people or is that not? Well
34:48 watchers are watching witnesses. Right so then yeah so then they would watch the
34:53 witnesses of like I said those other ones like the university and the bank and and
34:57 all that stuff. And if you want I mean if you want the KERI ecosystem as it's
35:02 designed And you're always going to want at least a watcher watching. Yeah. But my
35:06 question though is like, because if I understand correctly, the witness is a
35:15 controller concern primarily. It's like it's my infrastructure as a controller and
35:21 then a watcher is more of a validator's concern. Like I want the watchers so that
35:30 I can. Is that true? Yes. That's one exception. Every controller should have a
35:36 local watcher that they use to watch their own infrastructure. So you want a watcher
35:42 you trust to watch your witnesses. That's how you detect whether or not your
35:46 witnesses have been compromised. And then you have watchers that watch other
35:50 people's infrastructure. And that's what normally people think of as watchers,
35:55 right? The outside watcher network is watching other people's infrastructure
35:59 detect duplicity, but you want a watcher to watch your own infrastructure that you
36:03 trust. So that's why the default configuration is you set up one watcher
36:08 you control. So you control one watcher and four witnesses. That's your
36:12 infrastructure. And that one watcher is mainly to watch your stuff. It can watch
36:18 anybody else's stuff as well. But you want to have something watching your
36:23 infrastructure. And the reason is is that the only way you can tell whether your
36:28 witnesses have been compromised is if it goes through watcher logic. And so watcher
36:33 logic only will see an event if everything is perfect. So if it's delegated, it has
36:42 to be delegated. If it's witnessed, it has to be fully witnessed. Whereas a witness
36:47 will witness something, any event that comes from a controller. A witness doesn't
36:52 wait till all the other witnesses witness it to witness it. It just witnesses it
36:56 when it verifies that it's in the KEL. Right? So you can't tell whether your
37:00 witness pool has been compromised without a watcher that watches your witness pool.
37:05 Now you could trust somebody else's watcher to watch your witness pool, but it
37:09 makes sense to have your own watcher you control. If you're spinning up witnesses,
37:12 you might as well spin up a watcher that controls your stuff. Or you could have a
37:16 watcher run locally in your wallet, but then it's not highly available, you know,
37:21 so that's a trade-off as well. Does that make sense? Yes. And then to round out the
37:28 watcher thing, like, what would be a reason why I might want to watch other
37:33 people's witnesses? To detect duplicity, whether they've been compromised. So like
37:38 in a business sense, right? Like if that's where if I'm dealing with somebody and I
37:43 want to make sure that this person I'm dealing with is reputable. Yeah, because
37:47 you can't tell the difference between somebody who's been compromised and
37:51 somebody who's malicious. Both of them look like duplicity, which is a good thing
37:55 because if you see duplicity, you know, don't trust. trust. Because it doesn't
38:00 matter whether they've been compromised or they're malicious, you know not to trust
38:03 it. – So if I have customers and they and I UBI them, then I know who their
38:09 witnesses are. – That's right. – And then I could choose to watch those witnesses of
38:14 my customers or whatever. – Yeah. – Yeah. – Okay. Thank you. – Yeah, we're good.
38:23 Okay. I think that's pretty much it. – I don't think You can just the demo, right?
38:30 I mean, is there anything else that people want to show? We're going to want. Can you
38:36 do a credential issue?
38:40 I don't have to get someone to the normal ones. Probably not from my machine. I
38:44 don't have the or you can go get those schemas. Yes, they're built in, aren't
38:49 they? Oh, yeah. So Sam has published a draft of some of the SEDI schemas in in a
38:58 repository called SEDI in the KERI Foundation GitHub. And so I grabbed them
39:03 and built them in here so that you don't have to think about it. And so you can
39:10 grab one of these schemas, load it in.
39:18 And then
39:30 I might have needed to grab the previous witness code. I'll show you. And those
39:36 schemas are again ACDCs? Schema for ACDCs. Schema for ACDCs. They're JSON schema.
39:49 Oh, wait.
39:58 to see it to going to do an ubi here. I just exported this local identifier. Let's
40:05 see if I can import it into this one.
40:12 And why are you switching vaults? Just to have two vaults talk to each other to
40:17 prove that you know because the two vaults are isolated key environments. So it'd be
40:21 the same as if I just had two wallets running.
40:26 So let's see.
40:33 I think I need to also take this one, put it in the other vault. Oh, that shouldn't.
40:46 And so is this going through a mailbox or is it all or
40:53 is there no mailbox involved here yet? Well, that's a good question. Did you
40:56 connect it up yet? We have the mailbox service, but we haven't quite finished
41:00 with the implementation on thing. Yeah, so it might not work because we might not
41:03 have the mailbox service running. Okay.
41:08 So I can apply for a credential from… All
41:18 right, the contact isn't showing up.
41:23 Yeah, you'd be able to apply for a credential from one of your remote
41:28 identifiers.
41:33 and from there you'd be able to do an exchange.
41:40 I don't know where it is. I don't know why it's not showing yet.
41:48 Yeah, it might just be we need the mailbox set up to send messages between and
41:53 Donfarus. Yeah, so we're working on the mailbox. You've done it locally, right?
41:57 Yeah. That's my I don't know what you're saying. – Yeah, I don't know what's
41:59 running on my box right now either. Yeah, then you would have like, we have
42:05 notifications here. And so you would send like an application message to an
42:15 identifier. It would show up in your notifications and then you could see each
42:19 of the steps in your exchange where you're disclosing which fields
42:27 for a presentation that you would want or to create a credential and then send that
42:31 credential to somebody who would be applying for that credential. And then
42:35 you'd be just sending the notifications to the mailbox and they would show up here.
42:41 So the problem is that do they need to these two vaults I guess with AIDs in
42:47 there they need to ubi each other or something? Is that in that little We need
42:53 to get their mailboxes to configure to each other to send like messages between
43:00 each other. The issuance exchange would go over the mailbox. It could use a different
43:07 transport but the way Locksmith is set up is to use the mailbox. Just the
43:12 contributed version of Locksmith didn't include the mailbox. We had to write our
43:17 own mailbox. and stuff like that. Yeah. But yeah, and then for like a… Oh, yeah,
43:22 sorry. No, go ahead. No, I was just going to say that for example, for a
43:26 presentation where you're going to the liquor store and you want to buy like a
43:34 beer, you would show your credential and then you could choose to disclose that you
43:40 were, for example, over 21, but then you wouldn't have to disclose some of the
43:44 other information about yourself within that credential. And so then, you know, we
43:48 would have a field where you would be able to choose which information you would like
43:55 to disclose and send to a verifier such as a liquor store as an individual. So my
44:03 question is on the original issuance of the credentials. You said that that was
44:08 also going to use a communication with an application through the mailbox. Did I
44:15 misunderstand or understand that? Sorry, what was that? For original issuance of a
44:20 credential, there was going to be an application function that was then going
44:25 to send a request to have a credential issued and then send that credential to
44:32 the person who was supposed to get it. Right. Correct. Okay. So I understood
44:35 that. Yeah. All right. In that, I think that what Joe was asking was, so for the
44:41 VLEI, we have an identity authentication layer that does a challenge response
44:46 process before actually giving the credential to the person who's supposed to
44:52 get it. Is that part of this in the background somewhere? Yes. I'm also
44:57 working on like a identity proofing challenge response. That's just exactly
45:02 what you're describing. So yes. So for SEDI, the state has defined their own
45:08 challenge response mechanism that's slightly different from the GLEIF
45:13 ecosystem challenge response. Okay. So to support both of those, the wallet would
45:20 have to support both types of challenge response. Okay. So it might be worth
45:26 taking a look in order to be able to see what they've done and compare. What they
45:30 do, the main difference is that instead of just signing both sides of the challenge
45:36 response, which is what the GLEIQ one does, which is simpler, because the state
45:42 of Utah is planning to use external proofing agents for the identity assurance
45:48 instead of a GLEIF authorized representative or a QBI like in the case
45:57 of or a qualification like in case of direct trust they would just hire they
46:01 might just hire somebody that they're requiring that the response be anchored in
46:08 the KEL of the user as opposed to just signed by the user. So it's more secure.
46:14 It's more secure. Yeah. Because we're having issues with people coming to us and
46:20 telling us that it's too much the way that we're doing it. And this is on top of what
46:26 we're doing. The state is now going to have millions of people who are going to
46:30 be really lax with their key management. So basically by anchoring, having the
46:38 wallets automatically anchor, then we take that away from them. They don't get to be
46:44 so lax. But it happens under the hood from their perspective. – Okay. Thanks. – So
46:51 can what's that automatic anchoring you were just referring to? – Identity
46:56 proofing. – Identity authentication. – Yeah. Yeah. In an identity and an IAL,
47:03 NIST IAL level three. So it's not two plus, it's level three for the state of
47:07 Utah. – Well, we do the identity proofing first and then as a second step the
47:11 identity authentication. – But then an IAL level three, the last step in identity
47:15 proofing is you have to bind an account or an identifier to the proofing session. So
47:21 it has to be done in session. In session. In session. So in session, the proofing
47:27 agent sends a challenge over a non -internet channel. So either an NFC or
47:34 Bluetooth something, you know, well maybe not even Bluetooth, but or optic
47:39 optically, right? Like a QR code. It can't be Bluetooth or anything that somebody can
47:43 surveil. And then you anchor the challenge in your KEL, which means you're signing it
47:50 to anchor it. But now it becomes detectable if somebody showed up and
47:57 impersonated you. Let's say somebody who looks like you stole your identity
48:02 documents and showed up at the proofing agent. And they said, okay, you're just a
48:07 person. So you don't have all of the security that you have at GLEI because
48:10 you're dealing with people that represent entities that have layers of management
48:15 for them to show up. You just have, you know, a homeless person off the street,
48:20 for example, show up and say, Hey, I want an ID, right? And they go, Well, here's my
48:24 documents, right? And they may not, you know, and they may have a grainy picture
48:28 that, you know, doesn't look really good and they go, Well, it's the best you got.
48:32 So, so this way, if if somebody stole their signing keys, if they were
48:40 compromised, then at least they could detect that they were compromise. So
48:45 between the proofing session when they actually go back to the state and apply
48:48 for their SEDI, there's an opportunity to verify those anchors. So it adds some
48:57 extra security that might be useful.
49:03 Okay. I'm sorry. I have one more question. So the
49:09 KF boot thing. Okay. I noticed you had to add a schema here. So I assume that means
49:17 that when you booted stuff up, there were no… Is there a way to include schemas?
49:21 Because for example, like again, if I was a university and let's say I made my
49:25 plugin, I would probably have my diplomas or the things that I offer and everything
49:32 like that. And so when I have my plugin and my boot, not only am I going to be
49:38 like, okay, here's you can set up witnesses and watchers for your
49:41 university, but these are all the schemas and things that, you know. So schema
49:46 discovery is what you're talking about. Yeah. Yeah. The schema isn't to do with KF
49:50 boot. It has nothing to do with your infrastructure. The schema are only for
49:53 the actual credentials. Yeah, but a credential, an ACDC credential. And if I'm
50:00 a university, wouldn't that be the diploma? Like I'm… Yes, but it doesn't
50:04 have anything to do with KF boot. You just said something about credentials for the
50:09 schema for KF boot. That's what That's what confused me. – I guess I was bundling
50:12 it in there because it's like I'm trying if I'm a university and I'm trying to
50:16 bootstrap my university infrastructure, I don't know. I would suspect that might be
50:22 a good place to just put all the schemas in there. – Well, we have a plan for
50:27 schema discovery within the wallet. Doesn't really have anything to do with
50:31 the booting and onboarding of the infrastructure. Just a separate mechanism.
50:36 So you could publish, for example, or the university could publish their list of
50:40 approved schemas and then the wallet could go find that. So like they could publish
50:45 all of their credential schemas as dot well-knowns for example. And then anybody
50:51 that wanted to talk to the university would go go say, oh, here's the schema
50:55 that the university uses for their ACDCs. And they can publish them in multiple
50:59 places. And because each schema has a hash as its identifier, anybody changes the
51:06 schema, it's a different hash. So you can detect that it's been tampered with. So
51:11 you know it's not the right one. You just have to get the authoritative publication
51:15 of the hash someplace and say, yeah, this is the one the university uses. So the
51:21 university would have a vested interest in making sure that the hashes and schema
51:25 they use are published in well-known locations that people can verify came from
51:29 the university and then any wallet can be preconfigured with those if they want to
51:35 or they can discover them on the fly. But you know, there's an advantage for people
51:40 in the university ecosystem to just pre -configure their wallets with those
51:44 schema. – So KF boot wouldn't be the right place for it anyway because it's even
51:48 though they're kind of related in a way in the sense it's KERI ecosystem, KF boot
51:53 itself doesn't really have any understanding of schemas or credentials or
51:57 any of that stuff. So it's really not the right place for that kind of stuff to be.
52:02 So separate consideration. – Thank you. – Cool. Cool. Anything else? Any other
52:10 questions? We pretty much run through the time. All right.
52:21 Thanks everyone. Thank you.