0:00 Jay Alexander Elliot ｜ Open KERI Infrastructure ｜ KERI Conference 2026
0:03 This version of the Locksmith app is
0:08 an open-source stripped down
0:09 version of what healthKERI has. So, if
0:11 you guys want to follow along, I have a
0:13 open source repo. It's
0:17 https://github.com/jaelliot/locksmith-demo
0:24 and you can follow along. There's some
0:25 instructions in the readme.
0:37 Locksmith is the desktop wallet for
0:41 KERI. This talk is about the
0:41 controller side of the system where the
0:42 keys stay local. Users manage their
0:46 identifiers and control does not
0:48 disappear into a single provider stack.
0:53 users need a
0:56 wallet surface where the keys in
0:59 control.
1:03 The trust
1:05 root lives at the edge and non-hosted
1:07 services.
1:12 In KERI the controller is the
1:14 part that actually controls the AID.
1:17 That means that it manages the keys in
1:20 the key event life cycle.
1:24 If that user-facing wallet gets absorbed
1:26 into one vertically integrated service
1:27 stack, the system may still look open on
1:30 paper, but it becomes less open in
1:31 practice. That's why the wallet boundary
1:33 matters is where the control actually
1:35 lives.
1:37 Many services describe themselves as
1:40 open, but in practice, the wallet, the
1:43 provider, and the integration path are
1:46 all tied to the same stack. When that
1:48 happens, builder choice starts to
1:50 disappear for KERI to remain genuinely
1:52 open. The wallet must remain separate,
1:55 and that separation must be real and
1:57 verifiable. So, with that in mind,
1:59 here's where Locksmith sits in the
2:01 stack.
2:04 Locksmith sets the controller side
2:07 wallet layer. Witnesses stay outside of
2:09 it. The watchers stay outside of it. The
2:12 connectors… the providers connect to
2:14 it but they do not become the wallet.
2:16 And by "providers" I mean the real
2:18 external services, witness and watcher
2:21 operators, credential services, workflow
2:23 services, and other KERI-adjacent
2:25 integrations.
2:35 The first thing that Locksmith proves
2:37 is the local state. It is a real local
2:40 identity vault. It supports multiple
2:43 vaults and local first storage and
2:46 controller-owned state on disk. That
2:48 matters because portability could come
2:50 later. The first proof is local control.
2:52 – What are you defining as portability here?
2:53 You could deploy it to any
2:58 location, I suppose?
3:00 – Okay. Because you say state ownership
3:02 for portability. I imagine that
3:03 means the key state and everything
3:05 necessary for like interacting with the
3:07 service provider.
3:09 Is that what you mean by state
3:10 ownership?
3:11 Yeah.
3:16 The identifier
3:24 credentials and real user workloads
3:26 is where the wallet becomes real for the
3:28 user. Locksmith is the desktop surface
3:31 where someone can create and manage
3:33 identifiers, track credential state, work
3:35 with KERI operations through a usable
3:39 interface. That is what the wallet
3:42 layers for turning core KERI
3:44 behavior into something a person could
3:46 actually use.
3:52 This is where the
3:53 architecture stays open. Locksmith
3:55 has a real plug-in boundary and code,
3:57 providers sit behind that boundary
3:59 rather than replace it. That means that
4:01 the wallet can integrate with outside
4:04 services without collapsing into
4:05 infrastructure. What is real today is
4:07 the boundary itself. What is in
4:09 progress is the broader ecosystem around
4:11 it. More provider side integrations
4:14 and the KERI Foundation's work to carry
4:16 that pattern through more
4:18 completely. So the architecture for now
4:21 is real, and the full provider
4:24 story is currently being built.
4:27 This is our architecture flow. The
4:30 user signs and stores locally in the
4:33 Locksmith vault. From there, the wallet
4:34 can communicate with provider side
4:36 services via the plug-in boundary.
4:40 Separately, events go out to witnesses
4:42 and watchers and receipts come back.
4:44 Verifiers stay out of that path, which
4:47 is the point. Verification
4:50 stays available without turning the
4:53 whole system into one provider-owned stack.
4:57 if somebody wants implementation detail,
5:00 I could go there, at the highest
5:02 level that is the overall shape.
5:08 Let me draw a clean line between what is
5:12 real now, what is next. What is real
5:14 now is the desktop KERI identity
5:16 vault, local vault and the identifier
5:19 workflows, a plug-in boundary encode and
5:21 repeatable setup reset and launch
5:23 evidence. What is next is the broader
5:26 foundation plug-in follow through mobile
5:28 and web portability and the browser
5:31 adjacent work around that…
5:37 I wanted the room to
5:40 leave knowing exactly what the demo
5:42 proof say and what it's still in
5:43 progress.
5:46 And then for getting started with the…
5:48 [Can we ask question now or at the end?]
5:50 [At the end]
5:57 And then for getting started with
5:58 the code I have a demo repo
6:02 that I've forked and I have commands
6:05 for Unix, it'll work on Mac OS or Linux and
6:11 for Windows; that script is
6:14 just a PowerShell script you could
6:15 execute.
6:18 Demo bridge.
6:22 The Locksmith gives KERI a
6:26 real control side wallet surface. I
6:30 wanted to show the a smallest life path
6:32 of this setup can honestly support.
6:34 I'm not going to try to turn this into a
6:36 full network demo is the…
6:39 The work that we had to do to remove the
6:42 the healthKERI code kind of
6:45 made that part still a work in
6:47 progress.
6:54 So, in order to install this
7:00 just run the script where it'll
7:03 detect if something's
7:04 ready there. If it is, it'll get
7:06 rid of it and then it'll set up the
7:09 environment and then I'll deploy it.
7:32 – I came in late. This Locksmith
7:35 is the wallet in KERI?
7:37 – Yes.
7:39 – What's the relation between
7:41 Locksmith and KERIpy 1 that was in
7:43 the session description? – The KERIpy 1
7:47 is that this is the KERI
7:50 Py one's just my fork or KERIPy is
7:54 Wait,
7:58 the other one's my fork
9:04 Sorry. For whatever reason,
9:10 I selected the wrong command.
9:16 Python scripts demo day.
9:21 Come on, please work.
9:28 Sorry, this is taking a while.
9:39 And then we could initialize
9:42 a vault and
9:43 a lot of this stuff is still work in
9:46 progress. A lot of the functionality
9:49 is
9:50 not there because it was stripped out
9:53 from the healthKERI wallet.
9:57 When we have the full
10:04 functionality built out, it'll have
10:07 largely at parity with the
10:10 healthKERI wallet
10:12 and we could create our own identifiers.
10:16 We could set the cryptographic
10:17 strength. I don't have a remote
10:19 identifier that I could connect to right now.
10:23 Same thing for a group identifier.
10:25 Issue a credential.
10:28 No schemas to ..,
10:32 I don't have anything for that
10:33 yet.
10:35 Add a schema.
10:37 And set this. I could change
10:43 the settings for the cryptographic
10:46 Key strength settings or other stuff
10:48 for the cryptography. But this is
10:52 the open source version of the code
10:54 that you guys can go and explore.
10:57 And sorry, I'm just not good at
10:59 public speaking. That's all I've
11:02 got. What questions do you guys
11:05 have?
11:05 Yeah. So essentially is what you've
11:08 showed us the KERI Foundation using the
11:12 plug-in API with Locksmith to run
11:14 against their own infrastructure.
11:16 Yes.
11:17 In this demo.
11:18 That's not in this demo. Okay.
11:26 So this is the open- source wallet that
11:28 we got originally from healthKERI. We've
11:29 debranded it. This is available now for
11:32 anybody to go and fork this, download
11:34 it, use it, build out more if you want
11:36 other features if you want. The plugin
11:38 itself is not shown here.
11:41 You'll see that in my demo, but you and
11:43 I are competing with each other. So now
11:44 we're not
11:45 now we're not gonna now you're not going
11:47 to see it ever. Ah,
11:54 thanks man. Hey Joseph, does so does this sorry this is a dumb
11:58 question but does this wallet here have
12:00 the KEL on in this whatever device is
12:05 installing the wallet does is the KEL
12:06 also there
12:08 you're local
12:09 yeah local
12:09 yeah locally
12:10 so this creates the manages the keys and
12:13 the KEL
12:14 in that environment
12:15 and you publish the KEL to a witness
12:17 yes to one or more witnesses right
12:20 so you would configure the witness here
12:22 Yeah, you'll see that in my demo if you
12:24 come to my demo.
12:25 When did you demo?
12:27 3:15.
12:28 It's Yeah, big
12:32 – And then also the
12:35 TEL stuff is that ..?
12:36 No, that's ACDC related. We're not going
12:38 to cover that in this.
12:40 Would it be on his local ..,
12:44 That's a good question. I don't know
12:45 where theoretically, I guess probably,
12:48 but I don't know that's a
12:49 little bit outside of scope of
12:52 dealt with yet.
12:53 – I know they defined the TEL this
12:54 morning, but I forgot what it stands
12:56 for.
12:56 [TEL = ] Transaction event log
12:57 - And that's for the recipient to detect
13:00 That's for the holder to detect if their
13:02 credentials are being used in the non
13:05 Not necessarily, TELs are
13:08 specifically related to a different
13:09 construct in the KERI ecosystem
13:13 called ACDC, which is more about
13:15 credential issuing.
13:17 Yeah. So the benefit of the TEL you're
13:20 publishing the transaction event so that
13:21 you can
13:22 I'm going to get anchored to the key
13:24 event log
13:25 I can't keep track of the state
13:26 I think a good way is the KEL is the
13:30 state of your keys and the TEL is the
13:33 state of your credentials
13:36 Question what the state of
13:39 because they can be in multiple
13:40 different kind of states depending on
13:41 what the credential is ..,
13:44 – Like revocation status state Yeah. Yeah.
13:48 I would guess that in Phil's ACDC talk
13:50 tomorrow morning, he'll cover this
13:51 stuff.
13:52 Tells everybody
13:53 if he's doing one then. Yeah.
13:54 Yeah. He's talking about ACDC tomorrow
13:56 morning. So if you have more questions
13:57 about that, he might actually have
14:00 production use cases that you could
14:02 guess.
14:05 So about the repos again.
14:08 So the Locksmith demo one is this one.
14:11 And what's in the Locksmith one? That
14:13 just that's the full healthKERI
14:15 that's the
14:16 healthKERI is proprietary.
14:18 Yeah,
14:19 we had to strip out all their fun
14:21 features when they donated to us. But
14:24 we still have like all the core KERI
14:25 stuff like identify creation,
14:29 There's support for like witnesses
14:32 and watchers but in order to connect to
14:34 witnesses and watchers you need to
14:36 connect to a provider such as healthKERI
14:39 through a plugin. So the KERI
14:41 Foundation is going to create
14:42 our own plugin, where you can
14:44 connect to our infrastructure to get
14:46 witnesses and watchers and then in
14:49 theory you could also have, in the same
14:51 UI, you can see KERI Foundations plugin
14:53 and like healtKERI's plugin or any
14:55 other provider who wants to create
14:56 witnesses and watchers.
14:58 [It can] provide infrastructure for you to
15:01 So basically what you want is creating
15:05 a vault
15:08 Encryption storage right Yeah, it's just
15:10 a place to store keys.
15:11 Yeah, but it is like for per wallet
15:13 you have multiple wallets. What is the
15:14 reason for it?
15:16 Just in case you wanted separation for
15:18 some reason.
15:18 It's like one password and bit warden.
15:20 Most of these password managers have the
15:22 similar idea of vaults where you can say
15:23 this is my work vault. This is my
15:25 personal vault.
15:26 Okay.
15:26 It's just applying the same belong to a
15:28 specific vault.
15:29 Yeah.
15:30 So you can't move them across.
15:33 Yeah. That's I don't know.
15:35 I don't think you can move them across yet.
15:36 Theoretically, I guess we could
15:37 eventually I can understand
15:40 I have them.
15:41 Yeah.
15:41 But here I'm trying to understand
15:43 because they're very tightly coupled
15:44 with ID, right? The credentials are very
15:47 tightly coupled with ID.
15:48 And when you have walls,
15:50 I mean how would you move ..,
15:52 you can't move the credentials across
15:53 because different ID
16:00 I would guess that you could probably ..,
16:02 like if you created two vaults I have so
16:04 I don't know. I'm guessing if you
16:05 created like a local identifier in one
16:07 vault, you could OOBI with it from
16:09 another vault as a remote identifier so
16:11 you could watch your own vaults. But I
16:12 don't know why you want to do that.
16:14 The I was looking at the KERI
16:16 Foundation GitHub.
16:18 There's 16 repositories and it looks
16:20 like there's three different wallet
16:21 implementations.
16:22 There's the Fort Web
16:25 the
16:26 No, there's the I think those are just
16:28 different deployment w targets.
16:30 There's one for iOS, there's a web app,
16:32 and one for Android. Yeah.
16:35 Okay. But there's there's the fort
16:37 for Android and fort for iOS and then
16:39 there's the key the Locksmith. Are those
16:43 how are those related?
16:45 The Locksmith is just what we take
16:48 and deploy to the different targets.
16:51 Locksmith is desktop version.
16:53 Okay.
16:54 Well, the Fort Web and Locksmith are
16:58 they're they're they're both desktop
16:59 versions. They're just different
17:00 implementations of the desktop version.
17:03 Essentially, all of them are a wallet,
17:05 right? They're all the same. They're all
17:06 wallet. You make identifiers. You can
17:08 UI.
17:08 So, my question is, why would you pick
17:09 one versus the other?
17:10 Whatever platform you want to use it on.
17:12 Are
17:12 you trying to deploy to a desktop or to
17:13 an iOS?
17:14 But Locksmith is web.
17:16 No, lockmith is just desktop.
17:18 It's
17:18 Oh, this is native desktop.
17:19 Yeah, it's a PIDE 6 applic. Okay, that
17:22 makes sense. Are they coming from the
17:24 same?
17:25 It's multiplatform source bundle. It's
17:28 it's all it the web or yeah they
17:32 they all are getting deploy the same
17:34 stuff the same code is getting deployed
17:36 to all those all those different
17:37 platforms. So for web is just the
17:40 web SaaS
17:44 app of Fort
17:47 also have multiple local identifiers
17:48 right in a single one have multiple
17:51 local
17:52 yes
17:53 that's just talking about
17:56 issuing credential to many identifiers
17:58 some Josh was talking about
18:02 Evan be talking more about the web wall
18:04 tomorrow
18:06 or whatever you want.
18:08 Wow.
18:10 People have other things they want to
18:11 hear about
18:11 or whatever suggestions.
18:13 Basically, he's just going to stand up
18:15 there and let you ask him anything.
18:18 Ask me anything session with that.
18:20 Cool.
18:22 I think that's kind of it.
18:26 Do you guys have any other questions or
18:28 I guess we're kind of still kind of
18:30 pretty early
18:32 tomorrow.
18:40 Yeah, I guess I mean the question I have
18:41 that might be answered tomorrow probably
18:42 in your session.
18:44 Is it clear, based on
18:47 what code that's open source what a
18:50 provider has to do in order to do their
18:52 own plug-in implementation and what they
18:53 have to sort of implement on the
18:55 infrastructure side
18:58 for the plugin kind of. Yeah.
18:59 Yeah. Because I want to do I want I'm
19:01 going to do a blog about it and sort of
19:03 show people how to do it.
19:04 I can make my session how to make your
19:05 own plug-in demo.
19:06 Yeah, that'd be great.
19:08 Yeah, it's pretty cool. A good idea
19:10 because I will definitely be doing it.
19:11 I want to help other people learn too.
19:13 I mean it's it's all there in the repo
19:14 so you could obviously learn how it's
19:17 built but
19:18 I don't think we haven't done
19:19 anything formally yet to describe how to
19:21 build a plugin.
19:22 Okay.
19:23 So that would be a good thing.
19:24 There is yeah healthKERI shipped like a
19:26 plug-in based flask. So they basically
19:27 like define the set of functions
19:29 you need to define in order to make your
19:31 own plugin.
19:32 Awesome. Yeah,
19:34 that's what I want to know.
19:37 Time to go through that sort of thing
19:38 tomorrow.
19:40 Was interesting.
19:41 There are other open source KERI
19:42 wallets besides the Fort and Locksmith one,
19:45 isn't there?
19:46 Yeah. From so I'll talk a little bit
19:48 about this in my session, but there's
19:49 heavyweight wallets and lightweight
19:51 wallets. Lightweight or Signify wallets.
19:53 This is a heavyweight wallet. It's the
19:54 most complete one in the world by far.
19:57 Well, health KERI's is
19:59 Yeah, healthKERI's is I guess
20:00 this is sort of a stripped down
20:02 slightest. So I guess health carries is
20:05 the most complete and then this is
20:06 stripped-down version of but it's
20:08 the furthest of all
20:09 but that's your session tomorrow not
20:11 your session today.
20:12 No I have two sessions today. One is
20:14 the last one is on the KERIA stuff
20:17 about lightweight wall. The first one is
20:19 going to be on the GLEIF Root of Trust.
20:24 Cool. Wow.
20:24 Well thank you. Do you guys have any
20:27 other questions?
20:33 – Who wants to speedrun building a
20:34 provider
20:35 Right now?
20:36 Let's do it.
20:36 Evan can coach you through it.
20:39 All right.
20:40 I just copy our
20:48 Done; 40 minutes? No.
20:51 Sorry that this wasn't very long.
20:54 Good.
20:56 See,
20:59 We got a little time, Jay, you can
21:05 launch the iOS thing if you want.
21:13 Sure.
21:14 Just to show it.
21:16 Yep. So, this is the iOS app.
21:20 Suppose I should
21:24 So yeah, it's functionally speaking
21:30 just it's the same code just it's
21:35 deployed to a the mobile apps
21:38 are just wrappers that will run the
21:41 Locksmith code
21:43 and yeah it's just this functionally
21:46 the same experience on any of the
21:50 devices and that's right I have not
21:53 fixed this yet.
21:54 So, I'm noticing that this looks very
21:56 similar to the flat UI. It's And I know
21:59 it's Pyite 6.
22:01 Mhm.
22:02 Yeah. Well, healthKERI basically just
22:05 translated the flat app into Pyite 6.
22:07 Okay. So, the flat app is,
22:11 right? I just wondered if it was I guess
22:13 did they lift the CSS styling when they
22:16 This is CS. Yeah, I just I left it as
22:18 close as it to what it was.
22:22 Okay.
22:39 Good jokes.
22:40 Nice work.
22:41 Thank you.