0:00 Phil Feairheller ｜ Infrastructure for Security ｜ Keri Conference 2026
0:03 Hi everyone. Thanks for showing up
0:04 today. My name, for those of you who
0:05 don't know me, is Phil Feairheller and
0:07 the CTO and co-founder of healthKERI.
0:10 We are specializing in bringing KERI
0:12 technology, as the name would suggest,
0:14 into healthcare, in particular data
0:16 exchange in healthcare to help
0:17 facilitate trust across the healthcare
0:19 ecosystem. I realized I forgot a intro
0:21 slide, so I'm just doing it without a
0:23 slide.
0:24 So, in my job, I end up teaching KERI
0:27 very often to a lot of different people,
0:28 in particular people who have never even
0:30 heard of it before. Sometimes maybe
0:32 they've heard of PKI, sometimes they've
0:34 heard of X.509s, but they've never heard
0:36 of KERI. And this is one of my favorite
0:38 slides to teach KERI because it starts
0:41 at the very bottom of the layers that
0:44 make KERI the security protocol that it
0:46 is. And when Sam first asked me to do
0:48 this talk on KERI infrastructure, I
0:51 immediately thought of this slide
0:52 because the infrastructure that I'm
0:54 going to talk about is very clearly
0:55 spelled out in the layers of security
0:57 that make up the KERI stack. So, I
1:00 won't do the whole spiel that I usually
1:02 do for this, but very quickly, starting
1:03 at the bottom of the self-certifying
1:05 identifiers and CESR, for folks that
1:07 who know PKI, I always like to say that
1:09 KERI solves the two hard problems of
1:11 PKI. One is creating a cryptographic
1:14 binding between the identifier and the
1:16 first set of keys, and the second hard
1:18 problem it solves is key rotation,
1:20 creating the cryptographic binding to
1:21 every other set of keys. And we are able
1:24 to do that with CESR, which is our
1:25 encoding format for exchanging
1:27 cryptographic primitives at scale.
1:30 So, the next layer up is pre-rotation
1:32 Key Event Logs. Already touched on what
1:33 pre-rotation is, and the Key Event Logs
1:36 are of course the data structure,
1:38 append-only data structure that allows
1:40 us to communicate changes in our key
1:41 state that anyone else in the world can
1:43 verify without ever having to phone
1:45 home. Layer three delegation distributed
1:47 group multisig,
1:49 that is something that we only talk to I
1:52 only talk to when I'm dealing with more
1:53 advanced audiences, talking about
1:55 KERI's ability to do delegation both at
1:56 the identifier level as well as
1:59 attenuated delegation with ACDC
2:01 credentials and distributed group
2:03 multisig is one of the more fun
2:06 technologies in KERI. I love working
2:07 with it. I love building it when we were
2:08 at GLEIF, but we don't really dig too
2:11 much into it. And so then if you think
2:13 about what I'm going to talk about
2:14 today, the wallets and then the watchers
2:17 and the witnesses, the first three layers,
2:20 one through three that I just talked
2:21 about are all in the wallet. So I'll be
2:23 able to demo most of these,
2:25 actually all of these capabilities today
2:26 with the wallet. It's our wallet called
2:29 Locksmith. And then when you get to
2:30 layer four, witnesses and watchers,
2:32 those are the other components that I'll
2:33 talk about today that we've donated it
2:35 to the KERI Foundation for open source.
2:37 And those are of course the layer that
2:39 allows us to make our Key Event Logs
2:41 available to other people and keep an
2:43 eye on anyone else we're doing business
2:45 with, keep an eye on their key state.
2:49 So the Locksmith wallet is an
2:51 application that we've built over time.
2:53 It actually started as a pet project of
2:55 mine because I was tired of using the
2:56 command line. Most of the work that we
2:58 did at GLEIF was done building out the
3:00 command line and then actually creating
3:02 the entire
3:04 GLEIF-authorized representative system
3:07 with the KERI command line. And
3:09 at one point I just got tired
3:10 of
3:11 [laughter]
3:11 using the command line over and over
3:12 again particularly when trying to demo
3:14 KERI to people. So I just started
3:15 playing around with what it would look
3:16 like to create a wallet and took the
3:18 KERI command line from KERIpy and
3:20 just started building little features
3:22 one at a time into this and eventually
3:24 it became a tool that I was using all
3:25 the time and we figured it would be very
3:26 useful and started making it a
3:28 production quality wallet.
3:32 The core of it is open source and what I
3:33 mean by core and I'm going to be demoing
3:34 it here in a minute, you'll see the core
3:35 is basically all the KERI
3:36 functionality. Just core KERI
3:38 functionality for working with your key
3:39 state locally, creating what we call
3:41 vaults which if you know KERIpy
3:43 they're called Haberies. (Sorry Sam,
3:45 couldn't call them Haberies in my
3:46 product)
3:48 Creating identifiers inside of those
3:51 vaults, doing delegation, multisig,
3:53 Provisioning
3:54 witnesses is actually on our on our SaaS
3:56 platform, but working with witnesses,
3:59 doing key rotations, etc. We also
4:00 have sections for all the work you do
4:03 with a credential, so uploading schema,
4:06 issuing credentials, granting
4:07 credentials, doing the whole IPEX
4:09 exchange, as well as receiving
4:11 credentials and using them in various
4:12 ways. There's no server required for
4:14 the core Locksmith wallet. You can
4:16 create all of your stuff locally for
4:18 everything that you would need to
4:20 potentially share with someone, we have
4:21 an export feature. So, if you create an
4:23 identifier, you do a couple key
4:24 rotations, you want to share it with
4:26 someone, you can just export the CESR
4:28 of the Key Event Log and email to
4:29 someone.
4:31 And then finally, it's extensible by
4:32 design. We'll get into that
4:34 quite a bit. When we first started
4:36 adding features for our SaaS platform,
4:38 and the healthKERI SaaS platform is
4:40 really just KERI infrastructure.
4:41 We're allowing folks to provision
4:43 witnesses and watchers and use them with
4:45 their identifiers for doing business
4:46 with each other, we realized actually it
4:49 was just because of where we put it on
4:50 the user interface, it looked like a
4:52 plugin. And we thought, well, you know
4:53 what? If we do really want to donate
4:55 this to open source, we're not going to
4:56 donate that part of the product to open
4:58 source, so why not wrap the interaction
5:01 with our SaaS services into a plugin API
5:05 and make it so that anyone can provide
5:07 plugins to that system. And so, I
5:09 believe later today or maybe tomorrow
5:12 we'll see some of the gentlemen from the
5:14 KERI Foundation who have taken this
5:16 open source core and integrated their
5:18 own plugin to deal with their own SaaS
5:19 services. And Two presentations this
5:22 afternoon. Great. On just that? Yeah.
5:25 Excellent.
5:26 And so, what we've also done with it
5:28 over time is part of the business
5:30 that we're getting into, you heard Jared
5:32 talk about today, we're starting to
5:33 bring the vLEI into healthcare. So,
5:36 we're helping folks with the issuance of
5:38 credentials, particularly vLEI
5:39 credentials. So, we've added a new
5:41 component underneath our plugin for our
5:44 SaaS platform that is a credential
5:46 issuance management protocol or
5:48 plug-in. And so that will interact with
5:50 a server component, really wrapping all
5:52 of the hardest part of
5:55 of issuing the vLEIs is managing the
5:57 multisig identifiers required and the
5:59 coordination between participants and
6:01 how they see the credentials and how
6:02 they interact with each other,
6:04 notifications, etc. when issuing
6:06 credentials across an enterprise by
6:08 various parties who may not be sitting
6:10 in the same room all the time.
6:12 (Let's see where to go.) So the
6:13 KERI core already talked about it a
6:15 little bit and I'm honestly not really
6:18 sure where to go to the demo, so I may
6:19 just tell on the slides and go right
6:20 over soon, but
6:22 this is just all the basic stuff you
6:23 would do with a with a KERI
6:25 system. So create your identifiers,
6:26 manage them, do rotations, like I said,
6:29 export them, share them with other
6:30 folks.
6:31 We've broken out group identifiers into
6:33 its own section. We initially
6:35 experimented with having it as just
6:36 another type of identifier you create
6:38 and that was a little bit unwieldy, so
6:40 we have our own separate group
6:41 identifier section. The ability to do
6:43 delegation with any identifier that you
6:45 create, you can send challenge
6:46 responses. I already mentioned the
6:48 credential schemas and then working with
6:49 witnesses
6:50 and watchers, as a matter of fact. And
6:52 then kind of tangential to what you get
6:55 with a normal KERI wallet, but much
6:57 needed is a full notification system
6:59 integrated with KERI messages that go
7:01 back and forth. So if you receive KERI
7:03 messages like IPEX messages for a grant
7:05 that you were given, they turn into
7:08 notifications inside of the user
7:09 interface, kind of separate from the
7:12 actual IXN message itself. (What's next?)
7:16 The plug-in arcitecture is the part ..,
7:22 Down at the bottom here, this is the
7:26 healthKeri plug-in and this is what
7:28 you would access to be able to reserve
7:31 resources on our SaaS platform in much
7:34 the same way that you would go
7:36 reserve a VM from Digital Ocean or from
7:39 AWS. And so we tried to keep that
7:41 comfortable for people who are used to
7:43 dealing with cloud services to say, "Oh,
7:45 I need another witness. I can just go
7:46 rent him, if you will."
7:49 And so when you go into that
7:51 Plug-in, you will see the ability to
7:53 access identifiers, witnesses. We
7:56 give you the opportunity to publish
7:57 credentials,
7:59 we're going to do a lot more with
8:00 that in the future once the KERI
8:02 Foundation starts working on observers
8:04 and registrars. This is just kind of
8:06 a lightweight version of that. We
8:08 have a connections feature which steps
8:10 kind of outside of OOBIs if you just want
8:12 to do quick connections with each other
8:14 and you know the other person is using
8:15 Locksmith at our SaaS platform. And then
8:18 watched identifiers is our watcher
8:20 network. And I'll talk more about that
8:22 later.
8:23 Mailboxes so that you can get
8:25 these messages sent back and forth to
8:26 each other. And then finally servers and
8:28 profiles I'll touch on when I do the
8:29 demo.
8:31 Okay, so we're going to stop
8:32 there and I'm going to switch over
8:36 To the demo. So this is Locksmith.
8:38 Again, I have two of them running here.
8:39 (I don't know how awkward that is to see
8:40 on the screen. Maybe I'll just center
8:42 them both.)
8:46 (With the overlap there, that might be a
8:47 little bit awkward.)
8:48 I have two Locksmiths here so
8:49 that I can demo some of the features of
8:51 going back and forth between them.
8:53 As I mentioned, we call [them vaults, red.]
8:55 Your database environments which you
8:57 can separate out groups of identifiers
8:59 within a KERI system, we call them
9:01 vaults. And so we have the ability to
9:03 create a new vault. You can give it a
9:05 name. So I'm going to go with Alice.
9:08 And create a vault. One of the things we
9:10 focused on here is making it very
9:14 simple to do very simple things. So when
9:16 you're creating an identifier, there's a
9:18 lot of things you can do and it can be
9:19 very complicated and complex to
9:21 understand what all the knobs and
9:23 buttons do on creating an identifier.
9:26 Same with creating a vault here. And so
9:28 we tried to make it so that in the very
9:30 simple case, if you know what you're
9:32 doing, you just need to do something
9:33 quickly, type in a name and go and
9:34 you're done. So that's what we did with
9:35 creating in a vault you could creating a
9:37 vault. You can do two-factor auth with
9:39 it if you want. Not really that
9:41 meaningful or important, but you can cuz
9:42 someone requested it from us. So, now
9:44 I'm going to open the vault.
9:46 And here I am in a KERI environment.
9:47 Over here on the left-hand side, I have
9:50 my menu which gives me the ability to
9:51 work with all the items I talked about
9:53 before. Identifiers are my local
9:55 identifiers. Remote identifiers are
9:57 those with other people who I'm
9:59 doing business with. Group multisigs,
10:02 credentials, proxies, and the
10:05 settings. So, I'll just touch on
10:06 the settings very quickly inside of
10:07 here. These for those of you who have
10:10 worked very closely with KERI under the
10:12 hoods, these are various knobs and
10:15 buttons you can turn to configure your
10:17 environment whether you want a temporary
10:18 data store where if you want to change
10:19 the directory where we store things by
10:21 default, etc. We have a plugin that
10:24 I'll be demoing tomorrow that interacts
10:26 directly with Locksmith for gaining
10:29 access to getting things signed for you
10:32 Submitting IPEX grants so that you
10:34 can log onto a website, that sort of
10:35 thing. You can configure that here as
10:37 well.
10:40 Going back to identifiers. As I
10:41 said, we try and make things very
10:42 simple. So, I'm Alice and I want to
10:44 create an identifier. I just did. So,
10:45 now I have a KERI identifier. It's got
10:47 a Key Event Log, only an inception
10:49 event. And if I look at it, you can see
10:51 that I created it. It has a public key.
10:54 No witnesses or anything like that
10:55 yet. And there's my Key Event Log. So,
10:57 that was really easy. And that's one of
10:58 the things that we really want to
11:00 emphasize here is how quickly we can do
11:02 things. Now, if we want to get more
11:03 complicated with it, you can go into our
11:06 advanced configuration and you have all
11:08 of these options available to you. You
11:09 can we can do a keychain if you want to
11:11 do a hierarchical deterministic
11:13 keychain. You can create that here. You
11:15 can have a salt which you can look at,
11:17 copy and paste, and save in your one
11:19 password so that you could recover this
11:21 identifier and all of its keys in the
11:23 in the case of a catastrophic event.
11:26 If you're a little more
11:28 concerned about security, you can just
11:29 do a random key so that you could never
11:31 get it back if you lose your keys.
11:33 Underneath that, we have our signing
11:34 thresholds. So, you have the number of
11:36 signing keys in the signing threshold.
11:38 This is only the M of N support. We
11:40 haven't built in the support for
11:42 fractionally weighted thresholds yet. We
11:43 will eventually. Some of the other
11:46 features when you create an identifier,
11:47 you can go with establishment only or do
11:48 not delegate. And then if you choose
11:51 delegation, you can delegate from some
11:53 other identifier, whether it's a local
11:55 or a remote identifier. So, I'm not
11:57 going to create any of that right now.
12:01 We have our remote identifiers.
12:04 (That's actually a problem.
12:08 I'll come back to that in a minute.)
12:09 And then in our group identifier
12:11 section, if you wanted to go ahead and
12:12 create a group identifier, you give it a
12:14 name, you select your local identifier
12:16 that you want to use to join that group,
12:18 and then you would select your other
12:19 participants.
12:21 And again, a group identifier is
12:25 exactly like any other identifier in
12:26 KERI. It's just that the keys are
12:28 shared across different machines. So,
12:30 all the other options for specifying
12:32 your thresholds, whether it's
12:33 establishment only or do not delegate,
12:35 all apply in here as well.
12:40 – Quick question. (Yes) Is there a
12:42 discovery built into that
12:44 drop down for adding group?
12:46 Yes, so the other participants would
12:48 be coming from your remote identifiers
12:50 here. So, any identifiers that you OOBI
12:52 with and you've connected with become
12:54 candidates for joining a group
12:55 multisig. So, you already have to know
12:57 about their Key Event Log, and that's in
12:59 that's because of the protocol used to
13:01 create a group multisig. It involves
13:04 taking keys from individual
13:07 identifiers from all the participants
13:09 involved. And only the public keys, we
13:11 don't share the private keys. So, that's
13:13 where they came from.
13:14 – Is that a different concept than like a
13:17 connection, a more general connection,
13:19 or is it specifically scoped to
13:21 Multisig
13:22 group identifier? When you say that,
13:24 are you referring to remote identifiers?
13:25 Yeah. So remote identifiers are just
13:28 ones you OOBI's with. So, in KERIpy, I
13:30 think they're called 'contacts' in KERIpy,
13:32 that's what the remote identifiers
13:34 are here.
13:36 It could be anything. Issuing a
13:37 credential to receiving a
13:39 credential from, anything at all.
13:42 (real quick, I realized I
13:45 forgot to do something, so you're going
13:46 to see a little bit of behind the scenes
13:47 here.)
13:49 (Because I realized I don't have…) – [Inaudible]
13:52 [laughter]
13:53 What do you mean?
14:00 We're going to
14:01 restart my two Locksmiths.
14:05 (And I knew I was going to make that mistake.)
14:12 We should be good to go
14:13 now.
14:15 I'll re-center and size them a little
14:17 more.
14:29 We were in the middle of
14:30 creating Alice, so we will open up her
14:33 vault again, and we'll go over to remote
14:35 identifiers. Good, there they are. Those
14:37 are the two identifiers for our SaaS
14:39 platform. And so, they are configured to
14:42 load when I And these are
14:44 configuration options you can add when
14:46 you package and ship your version of
14:48 Locksmith. Those are OOBIs that he will
14:50 automatically resolve when he starts up,
14:52 so that he has access to them here. For
14:54 in our particular case, verifying the
14:56 signatures against our SaaS platform
15:00 for gaining access.
15:03 Let's go over to the healthKERI,
15:05 SaaS platform. This is
15:09 our 'getting started' screen, creating an
15:10 account within healthKERI. And the
15:13 reason why I'm doing this,
15:14 it won't take very long, but this gives
15:16 me the ability to provision witnesses,
15:17 so we can talk about the witnesses that
15:19 we have, and then also to start watching
15:21 identifiers inside of the healthKERI
15:22 watcher network so we can see the
15:24 interplay there. And then I can talk
15:26 more about what we, you know, what's
15:28 going to be available for all of you
15:29 folks to start working with. So I am
15:31 in Alice, so I will very quickly create
15:33 Alice and this is one of the key
15:34 differentiators of what we do with
15:37 our SaaS platform. There are no usernames
15:39 and passwords. There are only usernames
15:42 and KERI identifiers. So you aren't
15:45 uploading a password here, you're
15:46 selecting a local KERI identifier ..,
15:48 (Hold on.)
15:52 (Create a new one.)
15:56 I'm going to select my healthKERI
16:03 identifier to use and that will be the
16:06 identifier that the public key and
16:08 Key Event Log of that identifier will
16:10 be stored on our services and anything
16:12 that I send to the SaaS platform API will
16:15 be signed and encrypted and anything
16:17 that it responds with, will also be
16:19 signed and encrypted from their AID.
16:21 So we have all of our communications
16:23 between our local Locksmith plugin and
16:25 our SaaS platform secured with what we
16:27 call ESSR which is 'encrypt send sign
16:29 receiver' which is a protocol
16:32 that's built into KERIpy.
16:34 So I'm going to continue into
16:35 the account creation. This is Alice.
16:38 She's on the internet.
16:41 'Alice
16:43 at healthkeri.com'
16:51 Create an account. Now when
16:52 we first created our SaaS platform, we
16:54 based everything off of an individual
16:55 user and you would provision your own
16:57 witnesses and watchers and that
16:58 immediately was revealed to be
17:01 very much too limiting because
17:03 people would want to share accounts. So
17:04 we switched over to a model where we
17:06 have teams and if any of you are
17:07 familiar with using Digital Ocean, it's
17:09 very much modeled off of their
17:11 approach for how you share resources
17:13 across teams. And this came in
17:16 handy later when we started working with
17:18 provisioning services inside of
17:20 enterprises where you have maybe a cloud
17:22 service that needs an identifier and it
17:24 also needs things like witnesses and
17:26 watchers, how you bring that server into
17:29 your platform so he can start doing
17:30 KERI things and reserving resources
17:32 from your KERI account. So this is team
17:36 'Alice .. [@]
17:39 healthkeri.com' and we'll continue to
17:45 access code and as of right now we don't
17:47 have billing built into our system so we
17:49 just base it off access codes. I hand
17:51 out access codes when people want to get
17:52 an account on our system.
17:56 And so I've created a couple for this demo.
17:59 – There's no vLEI
18:03 integration where you're collecting
18:05 their role? No, not in this. No, we
18:07 don't require a vLEI to gain access to
18:09 our to our platform. Okay, so I've gone
18:11 ahead gone ahead and created an account
18:13 Inside of healthKERI. I've added a
18:15 team to that account.
18:17 And now I'm going to add an identifier.
18:18 And this is a little bit of an awkward
18:20 step but one that we were required to do
18:22 for all of the other things you would
18:24 want to do on our SaaS platform. And what
18:25 I mean by that is when we provision
18:27 witnesses, slightly different from what
18:29 many of the other witness
18:31 deployments are right now, when we
18:33 provision witnesses, we provision them
18:34 only for a single AID. So every witness
18:37 that you get on our service will only
18:39 ever witness for the AID you gave it.
18:42 And that's a security measure and also
18:45 it helps us keep the scale of all the
18:46 witnesses very low so that we can
18:48 have a lot of witnesses because we know
18:50 each one will only ever witness for one
18:52 AID. And so in order to do that, we have
18:55 to give it the AID to witness for.
18:57 So that's an example of why we had to
18:59 create a first step that when you want
19:02 to start using our system, you have to
19:03 give us an identifier to start working with.
19:05 – Are there any special caveats for
19:08 group identifiers? No.
19:10 – They have separate witnesses?
19:12 Correct. Absolutely, yep.
19:14 In addition to that,
19:17 if I have, for example, maybe an
19:19 identifier on a phone and I want
19:21 witnesses for it, I can actually do that
19:22 as well from here (and I'll show you how
19:24 you integrate with that later).
19:26 When you first upload an account
19:27 identifier, it can be a remote
19:29 identifier that you OOBI'd with so you
19:31 can get resources for some other
19:32 identifier or a local one from this
19:34 wallet. In addition, we added a
19:36 feature of making this identifier
19:38 publicly available and that's just the
19:40 healthcare platform global OOBI system so
19:43 that whenever you upload an identifier,
19:45 we immediately create a new OOBI for you
19:46 that you can hand out to anyone and
19:48 it'll work for all roles within your
19:50 system. And for those of you who know
19:52 the details of KERI,
19:54 if you OOBI against a specific role, you
19:56 only get back the responses
19:58 for that role like for a witness. So,
20:01 this just gives you everything back with
20:02 one single OOBI. So, I'm going to upload
20:05 Yep, got to select it first. I'm going
20:06 to upload the Alice identifier.
20:09 And you can see that now our SaaS
20:11 platform knows about this identifier.
20:13 It's associated with our account. It has
20:15 our sequence number.
20:17 And broken out on this grid is both the
20:19 local sequence number that I have on my
20:21 machine and the sequence number that the
20:23 remote system has for me. And those
20:26 can get out of sync if I do a bunch of
20:27 rotations and don't come back and update
20:28 healthKERI except for when watchers are
20:31 involved.
20:35 And so now it's also public.
20:36 From here I'm going to jump
20:37 back real quick to
20:40 the wallet side of this
20:42 application, not the healthcare platform
20:45 side, and talk about our
20:47 credential management system. So, inside
20:49 of here, we have the ability to issue
20:50 credentials. We broke credentials out
20:52 into those that you have issued, those
20:54 that you have received, and then
20:56 accepted offers is something very
20:58 particular to the demo I will be doing
20:59 tomorrow.
21:01 And for those of you who were here at
21:03 SEDI and saw me do it yesterday, it's
21:05 where we have integrated IPEX
21:07 protocol into our OAuth servers so that
21:10 you can do a credential presentation of
21:11 an offer without the actual credential
21:13 itself and require the site to sign your
21:16 terms and conditions before you give
21:18 them the full credential. Those signed
21:20 receipts, signed offers show up here.
21:23 And then finally we have the ability to
21:24 do schema.
21:26 We can upload schema from any source.
21:29 I'm going to go ahead and grab the QVI
21:31 schema just cuz I know it doesn't have any ..,
21:32 Doesn't have any chains on it. So we put
21:40 the OOBI in there and it automatically
21:41 pulls out the SAID for you just so you
21:43 see you have that tuple of the
21:46 identifier as well as the OOBI. And then
21:48 this is another use case where we looked
21:49 at it and said, "Okay,
21:52 credential registries make sense to me,"
21:55 but that's cuz Sam has explained them to
21:56 me about five times, maybe probably more
21:58 than that.
21:59 It was really hard for us to explain to
22:00 people what they're doing in that first
22:03 step before you're allowed to issue
22:04 credentials. You have to create a
22:05 registry. Well, what's that? What name
22:06 do I give it? "Where does it live?" And
22:08 so instead of doing that we tried to
22:10 hide all that and this is open for
22:12 debate. This will now be an open source.
22:13 So if folks don't like this it can be
22:15 undone, but we've decided that instead
22:18 we've added a step to uploading a schema
22:20 that says, "I want to use this for
22:22 credential issuance." So when you select
22:24 that, you select an identifier who's
22:26 going to be the issuer for that
22:27 particular type of credential. And when
22:29 you load the schema, not only does it
22:32 load the schema, but it has now created
22:33 a credential registry behind the scenes.
22:35 So that is completely hidden from the
22:36 user and we think that's probably a good
22:38 thing,
22:40 but again open for debate and we're
22:41 willing to accept feedback on that. Did
22:43 you have a question? – Yeah,
22:45 Did you issue a credential registry per schema type?
22:47 Yep. It was just a an allowance that we
22:50 made to try and make it a little bit
22:51 easier for the user.
22:53 When you come into our issue
22:55 credential screen, (I'm not going to
22:56 issue any credentials but I just want to
22:57 show you really quickly), you select the
23:00 type that you want. We dig into the
23:02 schema and present fields for you. These
23:05 are as typed as we can make them based
23:06 on the JSON schema in each of the
23:08 credentials cuz you cannot specify
23:10 formats and stuff in schema
23:12 if you don't want to.
23:14 Calling out required fields and stuff
23:15 like that just to make credential
23:16 issuance a little bit easier
23:19 for the user without hardcoding into
23:21 this app knowledge of any specific
23:23 schema type.
23:24 Okay, so now we're going to go back to
23:29 the healthKERI plugin.
23:31 And
23:32 there we go. Perfect example. So this
23:34 this identifier is now out of sync and
23:36 that is because I created a credential
23:37 registry with it which had which had to
23:39 create an anchor into my Key Event Log
23:41 and now he's out of sync, so you can see
23:42 that the remote server doesn't have my most
23:47 up-to-date key state.
23:49 So I'm just going to go ahead and update
23:51 that. And so this tells me that I'm
23:53 going to be taking the local key state
23:54 where I'm at 1
23:56 and pushing it up to the remote server
23:57 who is at key state 0 for this and
24:00 updating now we're in sync. So he now
24:01 knows about my most recent key events.
24:04 So now we're going to move on to
24:04 witnesses and this is .., (Does it make sense
24:07 to go back to the
24:09 slideshow?)
24:11 So yeah, so I'll just go over this slide
24:12 very quickly.
24:14 So this is witness as a service and as I
24:17 mentioned earlier this gives you the
24:18 ability to reserve individual witnesses
24:21 for your AID. Any number of witnesses
24:23 you want. We have geographically
24:25 disperse witness infrastructure so you
24:27 get to pick where you want your
24:28 witnesses deployed, how many you want
24:30 deployed and then you get to pick your
24:31 threshold that you want of those
24:33 witnesses and our user interface will
24:35 default to the most logical threshold
24:38 based on the What's the name of that
24:40 algorithm?
24:41 The Kawa algorithm. So the
24:43 number of witnesses that you should have
24:45 in your threshold versus the number of
24:46 witnesses that you have.
24:48 So as I said reserve a witness as easily
24:51 as any cloud resource. The core of this
24:53 is open source. I know we're going to
24:54 see demos of the KERI Foundation folks
24:56 who have already put it into production
24:58 in their systems.
25:00 it is a multi-tenant system, so you can
25:03 put it on one
25:04 VM and reserve as many witnesses as you
25:06 think that VM can support. And then what
25:09 we've done behind the scenes for us is
25:10 that we spread that out across multiple
25:12 hosts and we have a round-robin, and I'll
25:14 talk about how we deploy all this later,
25:16 that we can then pick from for any
25:18 particular region.
25:20 We have added, actually I added, to
25:22 KERI core, at the very beginning of my
25:25 work at healthKeri, the ability for a
25:27 two-factor auth for witnesses. So we have
25:29 a one-time passcode that you select
25:33 that you authenticate with the witness.
25:34 He gives you back the one-time passcode,
25:36 then you have to enter that anytime you
25:37 do a key rotation. And that's to make
25:39 sure that your witnesses won't just
25:40 accept the Key Event Log for you from
25:42 anyone. You have to provide that
25:43 one-time password with it. There are
25:45 other ways to do this. We could use our
25:48 our proprietary API with the ESSR to
25:50 accept events for your witnesses, but we
25:54 thought that was more vendor lock-in
25:56 than we really were comfortable with, so
25:57 we went with this one-time password
25:59 solution. They are
26:00 non-promiscuous. They will only witness
26:02 for the people for the one AID that you
26:04 reserve them for. Each witness has its
26:06 own dedicated key store, so there's no
26:08 mixing of keys in like a MongoDB
26:10 or anything. They each have their own
26:11 private LMDB and we manage that across
26:14 multiple servers. This makes it fairly
26:16 scalable, pretty easy to deploy, and
26:18 designed for and in our case implemented
26:20 with geographic distribution.
26:23 (Let's just see the screen. I don't
26:25 need to talk through this.)
26:27 So here we are. So let's add a witness.
26:29 So when you open up the create a witness
26:30 screen, it will of course make you
26:32 select an identifier, so I'm going to
26:33 select Alice. In our system right now
26:36 we have four regions deployed. We have
26:37 New York, Frankfurt, Singapore, and
26:39 Sydney. And you get to choose where you
26:42 want your witnesses deployed. So I've
26:43 already chose I've already selected
26:45 Alice as the identifier that I want
26:47 witnesses for. I can add as many as I
26:49 want in each region. It gives you a
26:52 suggestion of a name for that witness in
26:54 that region. You can name them anything
26:55 you want.
26:57 If you want to, I'm just going to go
26:58 ahead and reserve a witness in each of
27:01 the regions.
27:03 And then I'm going to choose an
27:03 authentication method.
27:05 Trade-off here between security and
27:07 friction, ease of use.
27:10 We've given you the ability to have
27:12 an individual one-time passcode for each
27:13 witness that you reserve. At four,
27:16 that's really onerous, so I wouldn't
27:18 even do it at four. At 12, I couldn't
27:19 even imagine it. So, we also give you
27:21 the opportunity to do a batch one-time
27:23 passcode. One-time passcode for all of
27:25 your witnesses for this AID, and that
27:28 way you can only enter it once, only
27:30 enter one code once when you do a full
27:32 rotation.
27:34 So, we're going to select batch,
27:35 create our witnesses, and you can see
27:37 here I've now spun up four witnesses.
27:39 Pretty fast. This is actually witnesses
27:41 spinning up in our SaaS platform. It's
27:43 very light touch for getting a single
27:44 witness to spin up.
27:46 Each one has its own identifier. You can
27:47 see them here. They're non-transferable
27:49 identifiers, as you would imagine. Here
27:51 are the OOBIs right here that you can
27:53 copy and paste if you wanted to.
27:55 You can also toggle on QR codes for
27:57 those OOBIs. So, if you're doing this
27:59 for a device that's on a mobile phone,
28:01 and you need to scan in these so that
28:03 you can now gain access to them for that
28:04 device, you can do that here with these,
28:07 QR codes. And then finally, we provide
28:10 the opportunity for you to right here
28:11 grab those OOBIs out of this screen and
28:13 just introduce to all of them. So, I'm
28:15 going to go ahead and do this. I'm now
28:16 OOBI'ing with each witness individually
28:18 and saving him into my database. And
28:21 then we did the authentication step,
28:23 where I called into the
28:24 witness, and this was really tricky to
28:26 get right because this like sort of a
28:29 trust a TOFU (trust on first use) case,
28:31 where that witness wasn't authenticated
28:33 anybody, but he would only accept things
28:35 from me. So, I was able to sign one
28:37 request to him to get the one-time
28:39 passcode back from him, and it was
28:40 encrypted between the two of us. So, now
28:42 I have the one-time passcode here. I
28:44 can, again, I could scan that into the
28:46 one-time passcode feature on my phone or
28:49 in this case I'm going to copy it and
28:51 put it in
28:52 one password so I can actually
28:54 do things with these witnesses
28:55 afterwards.
28:57 So, I don't know if any of you knew
28:58 this, but
28:59 What's that?
29:01 – We need your one password? No, I use
29:03 my fingerprint. You don't have that
29:05 again.
29:07 – I just wanted you to type it out for us on screen
29:09 Nope.
29:11 So, I don't know if you knew this, but
29:11 when I discovered this like wow, that's
29:13 cool. They have they have a one-time
29:14 password support.
29:18 Yeah, absolutely.
29:20 Yeah, they have a they have OP command
29:21 line, very cool. Two words or two
29:23 letters, I love that.
29:25 Then finally, the last step would have
29:26 be of course rotation this in. I could
29:28 just go do this manually, but we've
29:29 added the ability to do a rotation right
29:31 here on the screen. It brings up common
29:33 defaults that you'd use. You want your
29:34 new your next keys or signing
29:36 thresholds. We select the TOAD, the
29:38 TOAD = threshold-of-accountable-duplicity
29:43 accountable duplicity of three, which
29:47 makes sense for four witnesses.
29:48 And these are the four witnesses we just
29:49 created. You can add more or remove here
29:51 if you wanted to, but we'll just go
29:52 ahead and rotate them in. And of course
29:54 now it's asking for my one-time passcode
29:56 so I'm going to go over here.
29:58 (I'm very paranoid cuz I'm
30:00 going to wait till it rolls over
30:01 to the next 30 seconds.)
30:03 1:30
30:08 There we go.
30:09 Now I'm going to grab that.
30:10 Paste that in here and do a rotation.
30:17 And we've rotated. Now I have all
30:18 four witnesses rotated into my
30:19 identifier. You can see over
30:21 here on this side. I'm now at sequence
30:22 number 2. I was at sequence number 1.
30:24 All four witnesses gave me
30:26 receipts. There's my threshold. There's
30:27 my new public key. And because this is a
30:29 remote identifier and we know that we're
30:31 given the opportunity to just go ahead
30:32 and upload the new event that you just
30:34 used to rotate in those witnesses into
30:36 your upstream server. So, we'll update
30:37 that. I'm now done with this. You
30:40 see here I've created these four
30:41 witnesses. These are my account
30:43 witnesses. You're now paying for them.
30:45 They're a monthly service, but very
30:47 very cheap. The controller is Alice.
30:49 This is each of the AIDs for those
30:51 witnesses, and these are the regions
30:52 that they're on. So, I now have
30:54 witnesses spread out around the world
30:55 for this identifier. So, someone would
30:57 immediately now have to attack four
30:58 different places around the world to
31:00 eclipse [attack, red.] my witnesses. And that was
31:02 pretty easy, right? I think it was
31:03 pretty easy.
31:04 Thank you.
31:06 [applause]
31:08 And then if we come over here, you can
31:10 see that we have updated to our new
31:13 key state to this remote server
31:15 To our remote SaaS platform, and
31:17 we're now at sequence number 2. If you
31:19 click on this, you can see this is the
31:20 public OOBI I was talking about cuz I
31:22 said "Hey, make this guy public." I
31:23 5 minutes left?
31:25 Oh, man, that went fast.
31:27 I'm not even close to done. All right,
31:29 well all right, let's see if I can do
31:30 this really quick. All right, so let's
31:31 get to watchers really fast.
31:34 And to do that, I'm going to create a
31:35 whole new account. So, let's create Bob.
31:40 Create. Open. Add identifier 'Bob'. Now
31:44 you see how fast this can actually work, right?
31:49 All right. So, I think I
31:53 copied. This is where you get to
31:53 see remote identifiers. I grabbed
31:55 Alice's OOBI, so I'm just going to
32:01 paste her OOBI in here and connect, and
32:04 now I have Alice. So, now I'm connected
32:05 to Alice. I'll go over here. Oh, no, I
32:07 got to create an account ' Bob'
32:10 I 'boob'-ed, oh, jeez, sorry Bob!
32:13 (That was a zero. It wasn't a second O)
32:16 Continue to account access ' Bob'
32:20 Wonderful.
32:22 [laughter]
32:23 – Want to use the healthKERI
32:24 identifier for that?
32:32 [Meanwhile, Phil is typing and speaking out loud]
32:48 These are one-time access codes,
32:49 by the way, if I didn't mention that
32:50 before.
32:51 We're going to grab Bob, paste.
32:55 Paste, continue to invites, no invites.
32:58 Go to identifiers. Let's add Bob an
33:01 identifier. Although, I don't think I
33:02 need to do this, but anyway, you can
33:03 just see how quick this is. And now,
33:05 let's go to the last step, watcher
33:06 network. So, very quickly, I want to
33:07 mention that we initially implemented
33:09 our watcher network the same way we did
33:11 witnesses. You have to rent individual
33:14 watchers and assign them to watch
33:16 people. So, if I wanted to have like
33:17 five watchers watching Sam's AID, I'd
33:19 have to go and get five watchers and
33:20 I'll say watch Sam's ID. That way, it
33:22 was it didn't work well. I talked with
33:24 Sam about it. He said it's no more
33:25 secure giving them VMs inside of our
33:29 infrastructure than if I just created a
33:30 global watcher network. And so, that's
33:32 what we did. We created a global watcher
33:34 network. So, instead of having to worry
33:36 about renting your own watchers and
33:37 assigning them and managing them, we
33:39 just tell you
33:40 tell us an identifier you want to watch.
33:42 We'll distribute it across our global
33:44 watcher network for you at random in
33:45 different locations, and we'll keep an
33:48 eye on it for you. So, that's what we've
33:49 done. So, getting a watched identifier
33:51 is as simple as selecting one of your
33:53 remote identifiers and say watch. He
33:55 immediately pulled the key state for
33:56 that watcher down, and now telling our
33:59 system to go watch that identifier. The
34:01 value of that, of course, is that now I
34:04 can come over here to Alice, and in the
34:06 regular KERI side of the plugin (lock
34:10 that)
34:13 (Hm? 2 minutes? Well, I did that pretty quick then!)
34:15 I'm going to rotate Alice's
34:16 identifier, do a key rotation. (I got to
34:19 get my a one-time passcode.)
34:21 Grab that. 15 seconds should be plenty.
34:24 Rotate. There, I've now rotated. I have
34:27 all four witnesses
34:29 Pulled down for him. And if
34:30 everything works correctly, Bob will now
34:33 get a notice that Alice
34:35 has done an update. This takes a lot
34:37 longer than I wanted it to doing a demo,
34:38 but that's because I have all my numbers
34:39 kind of spun down. There it is, it just
34:41 showed up. Just so I don't burn my CPU
34:43 out. So, I just received a notification.
34:45 This is again the integration of
34:47 notifications into our
34:48 system.
34:50 The notification is available in the
34:51 open source plug-in, and you can
34:52 integrate it anything you want. So,
34:53 whatever you add to the to the health
34:55 KERI if as a plug-in, you can integrate
34:57 into the notification systems to drive
34:59 that as well. Now that I see that I have
35:01 new key state for Alice, we made the
35:03 decision not to automatically pull that
35:05 key state down for you. So, I would just
35:06 go into my watched identifiers. You can
35:09 see that he is now Alice is now out of
35:11 date, and I want to do a sync, and now
35:13 I'm up to date with Alice.
35:15 So, one last thing I'll point out is
35:17 that's all well and good, but I'm
35:19 doing it manually. Where this really
35:21 comes into play is when you're deploying
35:23 servers into enterprise infrastructure,
35:26 and you have a server that has an
35:28 identifier and that is let's say for
35:30 example an OAuth server that's
35:32 validating vLEIs coming in, but needs to
35:34 keep up to date with the key state of
35:36 any of the identifiers that it is now
35:38 interacted with. You can provision it so
35:40 that it can connect through this
35:41 authorization server feature inside of
35:43 our SaaS platform, so that it now has the
35:46 authority to ask our platform to watch
35:48 identifiers on its behalf, and it will
35:50 and I'll talk a lot more about this
35:52 tomorrow. It will then have a side car
35:54 running that is its local watcher that
35:56 integrates with the healthKERI we
35:57 watcher platform to keep up to date on
35:59 key state changes so that anyone that
36:01 you're using towards anyone that is using you
36:03 to authenticate into a system can do a
36:05 key rotation anytime they want and
36:06 automatically get updates.
36:08 I just real quick I'll go to questions I
36:10 guess.
36:15 [applause] Thanks everyone.
36:19 – How diversified is the watcher set
36:23 that you're running? So, right now we're
36:24 in four regions, and the same regions
36:27 that we are in the witness in the
36:28 witness network that are on different
36:29 data centers than the
36:30 witnesses are.
36:31 So, yeah. We have
36:34 I think three servers in each of the
36:35 regions. And we just pick them at random
36:38 when you ask us to watch. We do four
36:40 watchers. So, pick them at random, one
36:42 in each region.
36:43 And that's easy to extend. (I didn't even
36:47 get to how we're deploying the services.)
36:47 No, it was only 40 minutes.
36:49 I know. I realized that when you told me
36:51 I had 5 minutes left.
36:52 [laughter]
36:57 All right, great. Thanks, everyone.
36:58 Dismissed. [applause]