0:00 Thank you, Karla. And thank you to GLEIF for letting me work on did:webs. We'll get
0:05 into that a little bit more. We're going to start with the TLDR. But who am I? I'm
0:11 Kent Bull. I work for GLEIF as Karla mentioned. She was actually the person who
0:15 hired me at GLEIF two blessed years ago. Was it two? It's going to be… Yeah, it's
0:20 going to be two in April. Wow. No, that's going to be three. Oh, that's fast. Wow. I
0:26 had three kids and two kids in the last couple of years. Things went fast. All
0:31 right. So did:webs, what's the why the s matters is the s matters most. And of
0:38 course, we've got DIDWeb. We're trying to say this is very close to DIDWeb. And by
0:43 the end of this presentation, we'll circle back to this. You'll see what we add in
0:48 addition to what did:webs provides. And it's just enough so that you can verify
0:53 with KERI ACDC that you actually control the domains and the keys that you say you
0:58 control. So let's start with the CLDR. For those, there are enough people in the room
1:06 that have seen me before that have seen did:webs that know kind of where things are
1:11 at. So let me give you a quick update before we dive into the next 23, 24 slides
1:15 that will go in depth. So essentially seen did:webs today works with KERI ACDC, I'm
1:23 going to say version 1. And when I say KERI ACDC version 2, let me be very
1:28 specific about that. It's actually version 1.1 of the trust over IP specifications
1:34 that the KERI stack working group are working on. I'm calling that KERI 2 just
1:40 for the purpose of this presentation because if you look at the Python
1:44 reference implementation in GitHub, there's something called the main branch
1:48 and the main branch is KERI 2. So it's sort of I spend most of my time in KERI
1:52 API. So when I say KERI 2, it's really 1.1 of the specs. Just sort of keep that in
1:56 mind. And that's confusing. Okay. How would you like me to say that would be
2:01 what would be the least confusing way for me to describe it? No, no, no. Absolutely
2:06 call it KERI 2. I just I also spent a bunch of time trying to figure that out.
2:11 Like, the thing that you're explaining is super confusing. It's because KERI as a
2:19 code base existed for several years before we started the standards track. And so we
2:25 had already advanced to well into the one point whatever you know and so the spec
2:32 actually incorporated a bunch of lessons learned so it was already anticipating you
2:39 know KERI 2.0 but it was one point of the spec. – Maybe you can use the artist
2:44 formerly known as in spec itself right? – Like one on one formerly known as KERI 2
2:49 .0. – Yes, yes, exactly. I'll state that for everybody to hear. So spec version 1.1
2:57 formerly known as KERI 2. Thank you so much Judith. I think you saw me almost
3:04 trip myself there. Yeah, I'm a walker. That's for sure. All right. So the TLDR is
3:16 that did:webs works great with KERI 1 and GLEIF was I was fortunate with GLEIF to be
3:22 able to actually fully integrate did:webs with with ACDC and a W3C presentation. So
3:29 we know that it works all the way through end to end with KERI version 1. There is a
3:34 significant amount of work that's non -trivial to do to make it work for KERI 2.
3:38 So as a part of this presentation, we'll get into later the differences between
3:42 KERI ACDC version 1 and KERI ACDC version 2. Before we get there, so we do have some
3:50 slides that say what next, where are we going to go with this? Just keep in your
3:54 mind everything works with KERI 1 right now. And it's I know it's version 1,
3:58 version 2. It's I just want to delineate between the two. It's not as scary as you
4:03 might think the upgrade from 1 to 2. So we'll get there. You if you understand the
4:08 fundamentals and the basics, all those transfer, there's just really new cool
4:11 capabilities that KERI 2 brings us like graduated disclosure, Blindable State
4:15 tells that are a step above what KERI 1 brings, but everything from KERI 1 still
4:21 applies. All right. So now let's get back to what the TLDR done and we're going to
4:25 dive deep into did:webs. Before we get into that, do we have any questions? Anybody
4:31 already wants to start us off with? And if not, I'll just dive right into it. Great.
4:37 So the idea is that we have the web. And if you look at so many implementations out
4:43 there, remember the DID wars or the not the did the well, there were some DID
4:48 wars. There were the ledger wars. You probably saw Sam's presentation from
4:52 earlier today. There were definitely DID wars. The battles were smaller, there were
4:55 less fighters, but there were wars. And usually what would happen is when somebody
5:01 lost a war, they just used DID web. Or if they didn't know which war to fight, they
5:06 just used DID web because it was simple. And you had a DID JSON document you'd put
5:11 on a web server. That's why I say web hosts, web host delivers the DID doc. And
5:15 in that DID doc, your DID was your URL. Pretty much very straightforward to
5:19 transform a URL into a DID. And then in that DID document, you'd say here are the
5:24 keys they're currently authorized for signing. That's why it worked. It was
5:28 really it's just a web page, DID JSON web page. Here's my authorized keys and here's
5:32 what they can do. Well, it's very similar to how the certificate authority system
5:37 works in the sense that there's one key when it's done, it's over, it's gone
5:41 forever. Well, with DID web, what happens when you change your keys? That's when you
5:46 need DID web s because DID web doesn't support key rotation. So now we actually
5:50 want to support, okay, I'm going to change my keys and I want to have a relationship
5:55 between the old key and the new key so that you can know that Kent version 1, 2,
6:01 3, and 4 are all actually Kent. You don't just have to take my web server's word for
6:06 it. If you want to verify, yeah, you're the same person across time, that's where
6:09 did:webs comes in. And when I say KERI establishes authority, the authority to
6:16 say that I am perpetually one person. I'm not this multiplicity schizophrenic
6:21 identity across many different keys. I'm a consistent thing over time. That's why the
6:25 S in KERI in did:webs is so special. It's because it allows us to add that
6:29 characteristic to the world of decentralized identity. All right. So
6:34 here's what we're going to go through. Now you sort of get the overall specialness of
6:38 did:webs. We're going to walk through just an example with did:web and did:webs. Talk
6:44 about what does it mean to actually resolve a did:webs DID? What are the
6:48 different capabilities that are in the that are in or need to be in the did:webs
6:53 resolver? talk we're going to go into a little bit later how you even though keys
6:58 change you still maintain control of the identifier and then I'll get to a current
7:04 state on where's where's the specification? Where are the libraries?
7:07 Where's the implementations people are using? What needs to be done next? Because
7:11 there's like I mentioned there's KERI 1, there's KERI 2, there's significant work
7:15 to be done for KERI 2 and even for the KERI 1 there's some elements of the spec.
7:19 We got some review from the KERI stack working group So, I should say that I am
7:27 one of the current editors and co-chairs of the DIDWeb S spec and the DIDWeb S sub
7:34 working group instead of the KERI stack working group. When we finish a version of
7:38 the spec, we pass it on up to the KERI stack working group chairs of which Sam is
7:42 one and I believe Philip Fairhiller is another. It might just be those two. So,
7:46 we got our version of the spec ready. We sent it to them and they gave us some
7:49 review points. And so, there's still review points on KERI 1, which is what
7:52 we'll get into a little bit later. And then there's a bunch more KERI 2 work to
7:56 do. And by the end of this presentation, you'll know where the reference
8:01 implementation is. So you can go start to play with this if you'd like. So as I
8:06 mentioned, did:webs provides us a base of DNS, a predictable location for your DID
8:12 JSON. A URL is that predictable location. did:webs doesn't change that. Everything
8:19 you know about how to use DIDWeb still applies in DataWebs. It's just that we
8:25 take and we add another file and we say here's a KERI-CESER. It's a set of bytes
8:31 that has a set of KERI objects expressed in the encoding called CESER. That's the
8:35 first time seeing CESER. CESER is a custom wire protocol for how you express KERI
8:42 data structures, KERI and ACDC data structures. So we take this extra file and
8:47 it's got a lot of data structures in it that allow you to provide verification of,
8:52 okay, I'm the same Kent over time. I'm the same person. I have all these things that
8:57 cryptographically verify to say I had these keys today. I rotated to the these
9:02 keys, the other keys tomorrow and so on and so forth. The KERI CaesarStream has
9:06 all of that data plus a couple of credentials as you'll get into later.
9:11 Okay, and the and those credentials I mentioned, they go directly into the DID
9:16 document and you'll see that a little bit later because all you really need to do is
9:20 you need to say I have a KERI identifier. That KERI identifier has keys. And I also
9:26 need to say which I have credentials to say which domains are authorized. Once you
9:31 know how to process the appropriate KERI keys and KERI credentials, you can derive
9:36 a DID document as you'll see in just a couple slides. All right. So when your
9:45 keys change in did:webs, you just replace the published keys. You do keep the same
9:52 DID because the DID is your URL. But you just change the keys. You throw the old
9:56 keys away. You've got some new keys. Well, there's nothing in DID web that says these
10:02 old keys relate to these new keys. You just sort of have that's implied. It's not
10:07 explicit. It's implicit in the sense because you use the same URL and you just
10:12 transform the URL to a DID. KERI says, no, we're going to be explicit about that.
10:17 We're going to verify the authorized key transitions for the same identifier, which
10:21 is what AID is. Well, how do you verify that? That's where the key event log comes
10:25 in. And what this means is that we're not just replacing published keys. You're
10:32 getting a new pair of keys and the old pair of keys we're saying we've rotated
10:35 away from those. So the relationship between the old and the new keys is
10:38 explicit.
10:41 And it would really this top bullet point is a sort of just another way to say the
10:45 same exact thing. Even though you're going to get the just from a regular web server
10:51 that did that JSON, you actually when I say controller evidence right here,
10:54 controller is a term if you see that for the rest of the presentation, we use
10:58 controller to refer to a person or an entity that controls a KERI key store. So
11:04 I'm just saying give me your KERI evidence and I'm going to use that to verify what
11:07 you're telling me in the DID document. So a couple of purposes that you might use
11:11 for did:webs are similar to what you just need identity for security for in general.
11:18 So let's take this ACME corporation. They're going to host to things at example
11:22 .org, they might want to be able to take the same identity as a company. So GLEI
11:27 solves the problem of organizational identity. We're going to model a little
11:32 bit of an organizational identity problem here, but with did:webs. So what the VLEI
11:38 brings and this isn't a VLEI presentation, but I'll give you a quick quick intro is
11:43 we say, well, we've got this entity identifier that says this is Microsoft or
11:48 this is Google. And then there's the VLEI that says, Okay, well, this is
11:52 cryptographically verifiable based on a key ecosystem that we've a trust ecosystem
11:57 we've established to say this really is Google. It's not an imposter. Well, you
12:02 could consider that to be kind of like this. You want to host some content. You
12:07 want people to be able to say this is who you are. You might want to have content in
12:12 multiple places. And I call it a backup here, but you could really think of it as
12:17 anywhere else in the world that the same company might want to either release new
12:22 products, host other content. You need to be able to say you have a consistent
12:26 identity no matter where your content is hosted. Part of what you'll see through
12:30 the rest of the presentation is that… So, we use something called an AID. Is there
12:36 anybody here that doesn't know what an AID is? Okay. Thank you. So, an AID is
12:41 something called an autonomic identifier. It's what the KERI world describes. It's
12:48 just an identifier. It's there's a couple of cool properties about it that bring in
12:52 the name autonomic. But for this example, it's just your organization ID. Well, your
12:58 organization, let's say you're running an AI agent, which is sort of where this OPS
13:03 ID comes in. I said delegated identifier here. That's another thing that's did WebS
13:10 supports, but it's really based on the KERI support. You might want to take your
13:14 identity as a company and say, I do all these different activities. Maybe I'm
13:18 going to delegate this one to a person, this one to an AI agent or so on and so
13:22 forth. And part of what I've got here on the slide is to say, okay, if you're
13:27 running an organization, you're going to have lots of different concerns at the
13:31 organization and you want to have consistent coherent identity across all of
13:34 them. The foundation for that is KERI ACDC. What we're showing through the rest
13:40 of the presentation is how we're using did:webs on top of that to provide a
13:45 standard interface through these decentralized identifiers, which is a the
13:49 W3C standard to allow you to have a consistent identity across all these
13:52 concerns and where we're going to the biggest part of the work that remains is
13:57 actually in this fourth box right here. I see credential verifier checks issuer
14:01 proof and part of what I wanted to say up front as the as the TLDRs a big part of
14:06 the work is that just because we've got nice things in the KERI world called
14:11 multisig and nested threshold weighted signature multisig doesn't mean that all
14:18 verifiers that you consume that. You might have heard from the W3C world, you might
14:22 have heard of something called the data integrity proof specification. Anybody
14:26 heard of that? So if you know data integrity proofs, well, it helps your
14:31 verifier know to how to use the right keys to verify a credential signature. Is that
14:36 correct? So we have to do that. I just want to thank you for being here so I
14:40 could validate that. I was pretty sure about that when I looked into it in April,
14:44 but thank you. We have to write a similar thing for the DataWebs world. And this is
14:49 a significant piece of work that we didn't quite have time to get to. What it is is
14:55 that so KERI has this amazing capability for multisig. I said nested weighted
15:00 threshold multisig. Just because you can sign a document with this really fancy
15:05 grouping or ordering of signers that can be resilient, fault tolerant and
15:10 everything you want doesn't mean that the verifier is smart enough to pull all the
15:14 right keys out of the DID document because you're going to define what's called the
15:17 verification methods and I'll just let me just skip ahead a little bit. So here's a
15:22 DID document. Your keys are going to be defined in your verification method area.
15:28 And then you're going to say what they can do with the assertion method and you're
15:31 going to say which ones allow you to authenticate the DID document in your
15:34 authentication. Well, just because KERI can produce really in did:webs really fancy
15:39 DID documents that represent our conceptual domain model doesn't mean the
15:44 verifiers have that domain model. So when I'm talking about that fourth box that I
15:48 mentioned. Even after we add version 2 support, KERI version 2, there's actually
15:55 one final piece we need to add beyond that to call it a complete package, which is we
16:01 need to write a spec and a library so that if somebody just decides to use a fancy
16:06 multisig group and put all their keys here, well, the verifier needs to be able
16:09 to detect that it's not just a simple key, but there's a lot of things involved
16:13 because you don't want verifiers verifying credentials that just have one valid
16:18 signature you need to be able to interpret what a multisig nested weighted threshold
16:22 multisig group is. And so it's pretty straightforward for people that know KERI,
16:27 but what we we need to be explicit and clear, which means we need to write a spec
16:31 and then write a library that'll do that. So I'm seeing at least one nodding head in
16:36 the audience. Makes me feel like I'm not a total failure. That's great. Anyway, all
16:41 right. So this is an example of a did-webs did. Let's just walk through it slowly.
16:46 You know, of course, you've got the protocol method at the front did:webs for
16:51 domain which we'll get into the designated alias ACDC later and you've got a path.
16:59 You might have a bunch of different paths here just like a traditional web domain.
17:02 And then on the end here is that thing that I said earlier is an AID, autonomic
17:07 identifier. It's a KERI AID. And one way to think about what did:webs adds on top of
17:15 KERI is we're using the W3C decentralized identifier standard as a standard way to
17:22 discover keystate. That's really this… If you had to say KERI in one sentence,
17:29 DataWebs is a standard is a W3C standard way to discover keystate. And when I say
17:36 keystate, I mean current or prior history for this identifier. Because remember I
17:41 said key rotation, so you could have lots of rotations and lots of history. That's
17:45 really what we're doing here. And you'll give something that looks like this to
17:47 what's called the DID resolver and that DID resolver will go and it'll ask for two
17:52 files as you'll see later and it'll say, okay, tell me what the current keys are
17:56 and who's going to do this. Let's actually put our minds in the mindset of who's
18:01 using this. So let's say you're at a gas station and you see this young looking
18:07 person come into your establishment. They want to buy some tobacco and you're in the
18:13 state of Utah. You're at a place called Maverick. Maverick says give me your
18:17 driver license and you give me your digital driver license and it's a SEDI one
18:20 but for whatever reason their verifier can only accept W3C things and so they use the
18:25 compatibility layer, right? And they've got a SEDI identifier. Somebody has a W3C
18:28 compatibility layer and they've got a credential that's issued that has a
18:32 did:webs in it. Well, how is the verifier going to go and find the right key to
18:38 verify this credential? That's what we're going to learn about through the rest of
18:43 the presentation. But the idea is that they look at the history for this
18:48 identifier and say, okay, what's the current key right now today? So I
18:54 mentioned two files. So when you're in in what I wanted to say with that example is
18:59 that the who of who's who cares to receive this did:webs is a verifier. When the
19:06 verifier says, okay, are you authorized to buy what you're trying to buy? They're
19:09 going to find two things for your identifier. They're going to get your DID
19:13 .json and anybody who's familiar with the DID ecosystem knows this pretty well. And
19:17 I said DID web form right under it. Because DID JSON, it's when we when it's
19:24 actually sitting there on disk or when we retrieve it, it's actually just a regular
19:28 DID web DID JSON. But we have another file that's not DID web. That's what this KERI
19:34 Caesar stream is. So when they verify or they're trying to make a decision, should
19:38 I sell this to you or not, they go and they resolve both the issuers did and your
19:42 did and they get these two files per for the issuer and for you, this is what we're
19:48 talking about as far as verifying a credential. There's a W3C credential
19:53 that's been secured with a KERI identifier. And then we go through this
19:57 process. We put them both together and we essentially say from the KERI Caesar
20:01 string, can we derive the exact same document that was hosted over here? If we
20:06 can, we at least know it from that point, it's coherent and it's cryptographically
20:12 verifiable as far as what you've told me is honest. There's another question that
20:17 we're not going to get into in this presentation of, well, what if verifiers
20:21 want to use witnesses and watchers? What if they want to use registrars and
20:24 observers? That gets beyond what we've decided to solve with the current version
20:30 of the did:webs spec. And here's why. Does the DID world really care about our
20:40 special KERI infrastructure? They don't and they can't. And you can make an
20:46 argument that they shouldn't. What they're limited to here, because here's the thing,
20:51 as soon as you start to become KERI aware, why use did:webs? As soon as you become
20:57 aware of the conceptual model of witness, a watcher, a registrar, observer of all of
21:02 that, and the adjudicator, if you're going to pay that conceptual burden, you can
21:06 just use straight KERI identifiers. We already have a discovery protocol built
21:09 into KERI. It's called out-of-bound introductions. We send everything across
21:14 the wire that's necessary. So if you're already going to pay the architectural and
21:19 conceptual cost to upgrade all of your infrastructure to be KERI aware, just use
21:24 KERI. The use case for did:webs is for verifiers that never, that probably have
21:30 something against KERI, to be quite honest. They say, we don't want to hear
21:35 you say it. Don't talk about it. We know it's behind the scenes, but don't bring it
21:38 up. There are some of those. There are some of those. – Some big ones, notable
21:46 ones that have said almost exactly that. – So we're like, okay, fine. We'll call it
21:51 did my best. We will never use the word KERI. Just don't read the spec. But no, if
21:57 you take an economic argument, you could say there are some people that don't want
22:01 to spend the resources or don't have the resources to spend to get full
22:04 infrastructure support for the I and KERI. Or they've got a really good reason why,
22:09 hey, this for the risk profile here, we can accept these risks So just a plain
22:15 did:webs, that's fine. And so what I'm leading to here is that you're doing a
22:22 check by taking the DIDJSON and the KERI CESER and saying, are they coherent? Can I
22:28 derive my DIDJSON from my KERI CESER? If so, at least that's not lying to you. And
22:33 if that's enough for your verifier to say, yes, you can take this tobacco out of the
22:36 store to the young man he's trying to buy it, that might be enough. So you send that
22:40 all into the DID resolver. You do that for the issuer, do it for the the holder and
22:44 say does it verify? And if so, great. Now you can verify signatures on a credential.
22:49 Now I'm going to have this slide because let me check myself on time. Okay, we got
22:55 about great. I've had questions come up from members of the community that didn't
23:00 know about this fourth thing on the slide. So I'm going to walk you through it. This
23:04 is a little bit deeper. And so if you're if you're new to KERI, don't worry too
23:08 much about what I'm going to say here or if you need to do did:webs. This is maybe a
23:13 little bit deeper. Okay, so this is the KERI-CESER. If you want to go inside that
23:17 file, that box from the last slide of the I said you can derive the DID document
23:22 from the KERI-CESER string. And that's actually what the did:webs resolver does
23:27 behind the scenes. Well, what's in the KERI-CESER string? Four primary kinds of
23:32 content. There's key event logs. Here's my identifier. Here's what keys control my
23:39 current my identifier. There's transaction event logs. Remember I said KERI 1 and
23:43 KERI 2? Well, in KERI 2, we have a new kind of transaction event log. But in KERI
23:47 1, we've got what's called a registry TEL and an ACDC TEL. You're going to have one
23:52 of these for your registry for your credential and you're going to have one of
23:55 them for the credentials life lifespan of cells like issuance and revocation. And
24:00 you're going to have some ACDCs. Now, why do you have ACDCs in the KERI seizure
24:05 stream? It's because of a feature called a designated alias. Right now, this is
24:12 actually something that makes KERI special and distinct. It's the big fake fiberoptic
24:17 S we had at the beginning of the presentation. This is part of what makes
24:21 DDoS special is that you make an explicit commitment to say, I'm authorizing this
24:27 DID on this domain. There's no other DID method in existence that does something
24:32 like that. That's as portable and decentralized as KERI. You might get a
24:37 close approximation for DID methods that are on on blockchains that have something
24:42 like this, but one of the rules, what I'm hinting at is one of the rules for did:webs
24:48 is that you're not authorized to a verifier should reject your DID document
24:57 if you don't have an explicit commitment to example.com or to whatever your domain
25:00 is. So the reason why you have ACDCs is because it's a 100% requirement that if
25:06 you want your DID to be hosted on a given URL, you have to commit to that URL. with
25:11 an ACDC. So, and what that implies, that one requirement implies that every did:webs
25:18 implementation must have full support for KERI and ACDC. There's no way to get away
25:24 with it. This is the reason why you have to have it all implemented for a did:webs
25:28 implementation. Okay, now the fourth part here is a little bit more surprising
25:34 because you're like, okay, it's natural that we've got key event logs. It's
25:37 natural that we've got registry or transaction event logs. It's natural that
25:40 we have ACDCs. Well, what's this RPUI? Well, that's actually shorthand for what's
25:46 called a reply message. And we use them and KERI to describe a couple key records.
25:51 There's like a URL or an endpoint role authorization. And what that does is it
25:57 essentially says this person or this controller, this person that controls
26:00 these key pairs, this identifier is allowed to act in this capacity on this
26:05 URL. And we include that in the DID document because you'll see there's the
26:09 services section of the DID document. They're going to be able to look at okay
26:13 there's a witness or an agent or a there's one other I was going to say watcher
26:20 there's actually one I'm thinking of a delegator. Okay. You might see a couple of
26:24 different services and you want to verify okay was is there actually cryptographic
26:28 commitment and authorization by the controller of this identifier of this
26:33 endpoint and in KERI we could do that in DeadWebs we can do that and we expressed
26:39 that in the KERI Caesar stream with reply messages. Now, these are not anchored to a
26:45 KEL. They are just signed reply messages. And a question came up in the KERI
26:51 community. They said, well, is everything in the KERI Caesar stream, is it
26:55 essentially just a… This is part of the aspect problem we have to fix that I've
26:59 got later in the slides is they said, well, should a KERI Caesar stream just
27:04 always be a subset of a key event log, whether the whole thing or just a part?
27:08 No. And this is why you have to say, well, if I'm going to have a services section of
27:15 my DID document and to say where things are at, there's a way we express that in
27:18 KERI and that's with reply messages. All right. Now that's about as deep as we need
27:22 to get. So those that are new to KERI, the rest of the presentation shouldn't be as
27:27 brutal. But we'll see. I don't want to make any promises. All right. We've talked
27:32 through this. Again, we fetch both the files. We verify that they're coherent and
27:38 And as I mentioned, there's designated aliases and that's where when I say
27:42 authorized DID names here. So we go through the verification process and we
27:45 say, okay, is the URL that you're hosting this DID web-s DID document on, is it
27:50 authorized? If it's in your designated aliases ACDC, it is. And once we check
27:56 that all that's coherent, we essentially just derive the DID document from the KERI
28:00 -CESER stream and compare it with the DID JSON that you've got on your web server.
28:06 And if they if they're the same same document, you verify. You're good. So we
28:11 already saw the slide. We won't spend too much time on it. This is just an example
28:14 of what a DID document looks like if you haven't seen it. I've mentioned there's
28:18 one thing that I should mention on this slide is I mentioned the concept of a
28:21 designated alias and I'll just slowly talk through that again. A designated alias is
28:27 what I was just referring to as this is no other DID method in the world does this.
28:32 KERI makes an explicit commitment to a URL. That URL Well, I was going to say it
28:39 goes in the also known as that some of them do. Now I might have jumped ahead of
28:45 myself here. So some of your designated aliases will be placed in the also known
28:52 as section. So let's say you're essentially trying to tell the world this
28:57 DID document or the location that I'm storing this did:webs DID document isn't
29:02 the only location there is. There's a couple of other locations you can get the
29:07 same DID document, but just under a slightly different URL, but it's the same
29:12 controlling identifier. You'll put those in the also known as and those come from
29:15 your designated aliases ACDC. So now to the multisig stuff. We do have multisig
29:24 support and I'm going to say limited multisig support and you'll see why. Give
29:29 me just a second to drink here. There is something that exists in the W3C
29:35 essentiallyidentity ecosystem called Conditional Proof 2022. And it lets you
29:41 define a threshold structure for signing something. So it was a natural fit for
29:48 DataWebs. DataWebs based on KERI with KERI Multisake. We just needed a way to define,
29:54 okay, well, there's a let's say it's two of three. Like this example, we've got
29:59 three keys that can sign. Two of them are required. Conditional Proof 2022 lets us
30:05 define that sort of a simple threshold structure, but it gets deeper than that.
30:10 Conditional proof 2022 also allows you to do nesting. So the really fancy cool
30:16 threshold weight, nested weighted threshold multisig stuff that KERI could
30:21 do, you can actually express that with conditional proof 2022, which is actually
30:26 what we do in the did:webs resolver. But the way that it works is it's how many
30:32 people here are new to multisig in KERI? Just a couple. All right. So I'll walk
30:38 through that one a little bit slower.
30:43 Let's say you have… So let me introduce this from why would you actually use this?
30:50 And I'll mention a GLEIF example. So we have defined in the ecosystem governance
30:55 framework rules for different participants in the ecosystem. And it's actually useful
31:00 from an operational standpoint because let's say you have a group of three
31:04 employees who's responsible for a role at your company and that role is to manage a
31:08 certain identifier. Well, what if one of them is gone on any given day? What if
31:13 they're sick or they're out or they're unavailable? Do you want to require all
31:17 three to be at work to be able to sign an event? You might not want to do that. And
31:21 there's other lifecycle reasons why you might say, well, let's say somebody gets
31:24 fired or they die or something. It can be really rough if you say, I've got, okay, I
31:30 need three of three signatures. You might just say two or you could say four of
31:34 seven or or two of nine, however you want to define your threshold structure,
31:37 there's actually a lot of business continuity reasons, failover, redundancy,
31:41 reliability, why you would want to use a threshold structure and the way that this
31:44 works from the KERI level and then we'll cascade out to the did:webs level is you
31:49 say, I've got K1, K2, and K3. As long as I have enough signers, okay, this credential
31:56 is valid or this issuance has happened. That's what multisig is. Now, what did:webs
32:03 does is it says, okay, for a verifier that doesn't care about KERI at all. If they
32:10 want to verify that this is a credential, let's say this is a W3C credential that
32:15 has been projected from maybe something in the KERI world, and I want to verify that
32:19 this issuer issued it and that this holder currently holds it. But what if those
32:24 issuers or that's fine if it's single SIG, but what happens if you've got a multisig
32:28 issuer or you've got a multisig holder? Now we need to go in there. We need rules
32:33 to say, okay, well, we need to be able to define the threshold and who is authorized
32:38 to sign. That's what this conditional proof 2022 does is it allows us to define
32:42 that very clearly within did:webs. So with that in mind, let's actually dive into
32:50 what a verification method might look like for conditional proof 2022. You're
32:55 essentially saying and when I say K1, K2, and K3 here, if you're familiar with DID
33:00 documents, you're familiar probably with the verification method section or the
33:05 authentication or assertion method section, that's where this shorthand is
33:09 referring to. There's going to be a verification method that says this
33:11 particular key is K1, K2, or K3. But what you're looking at here, this object here,
33:18 this set of text, this is what a conditional proof 2022 looks like. It
33:23 says, okay, I need two signers and here's the people who can sign. And I mentioned
33:29 the authentication and assertion methods of the DIDDoc. There's a lot of rules to
33:33 remember. whatever, especially if you want to as a verifier be able to support the
33:39 coolest features of did:webs, which is multi-sig issuers and multi-sig holders.
33:43 So, and we just this just walks a little bit through a waiting signing threshold
33:50 thing. We can sort of move on. There's plenty to discuss later. All right. So I
33:55 mentioned remember the four things that were in a KERI season stream. And I said
34:00 you need to it's not just a key event log. You've got service endpoints. You've got
34:04 role authorizations. That's what we talked through on this slide. Is you might say I
34:09 have a witness or I have a mailbox or I have an agent and that has a relationship
34:14 to my to
34:18 the identifier that is giving you this didDoc. And so the way we represent that
34:25 is not with a key event. There's something called the location scheme. The slash LLC
34:29 and slash scheme is the the the name space that we give it in the KERI world. We say
34:35 there's a couple of data structures we use to represent these things when they're
34:39 given into a DID doc. Now, you might ask me, well, why are we including these in
34:44 the DID document at all? Because I thought we said that we should assume that the
34:50 verifier doesn't know KERI at all. That's true. And really what we're doing here is
34:56 we're piggybacking a little bit on the structure of the DID document and say,
35:01 well, maybe people might be interested in discovering that I have a witness or that
35:05 I have a mailbox or that I have an agent. This straddles the line. I mean, it's a
35:09 potentially useful construct. It starts to straddle the line. If we're not pulling
35:13 anything from the witness or from the mailbox or the agent, maybe we don't
35:15 actually need this, but it seemed invaluable and so we kept it in there. But
35:21 it's debatable that if you know how to talk to a witness, if you know how to talk
35:24 to a mailbox and an agent, you'd probably just do that directly. Maybe you wouldn't
35:26 need did:webs, but we've defined it in the spec in case it becomes useful. Cool. So,
35:34 okay, I won't get too far into the delegation because then again delegation
35:37 is also a KERI-specific concept.
35:42 This slide is really just a repetition of what I've told you earlier. I said if you
35:48 want to support the fancy molded-sign stuff from KERI, we need another spec.
35:52 This is when I say credential proof right here. When I say a credential proof has to
35:58 use an authorized method where that's valuable is before we let the kid go out
36:03 of the store with the tobacco and we need to verify the right state of Utah issued
36:07 this and this kid actually holds it. There's rules you have to use to say,
36:14 okay, I can verify the signatures on this credential because they can't come from
36:19 these places in the DID document. And we could walk through this example, but
36:21 essentially when I talk about the assertion methods, the different proof
36:25 formats that we have, it's essentially we would walk through, I I think that's
36:29 probably not a good time to walk through the nitty gritty of what that proof spec
36:36 would be like, but essentially know that we need to write a proof spec and this
36:39 slide gets a little bit deeper into that. Oh, you want to go? Actually, if you want
36:44 to go there, we'll go there. I have a question about the proof purpose. Perfect.
36:50 Okay. Is there a KERI data model equivalence either in the event log or any
36:58 of the delegation mechanisms for assigning proof purpose to keys to not the pre
37:06 -rotation keys but to regular document keys. Can you say this key can only be
37:11 used for authentication, this key for signing stuff and this key for key
37:14 agreement?
37:20 So is the question is there something in the KERI data model that would support
37:24 deriving that from the KERI data model? Yes. I see. That's the question. Can I
37:30 answer that? Yeah. So signing keys can only be used to sign. Oh, you got it.
37:36 Rotation keys can only be used to rotate. And most
37:45 of the time when you're doing something of high value, you anchor in an event, which
37:53 means it must be signed with the signing keys or you anchor it in a rotation event
37:59 which must be signed with the rotation keys, the pre-rotated keys. There aren't
38:06 any other places that you use keys for any other thing in the whole KERI ecosystem.
38:11 Signing is general. You can do anything you want with signing. Right? So you could
38:16 say, well, if I want to sign a particular type of packet, I suppose you could say
38:26 that, but we don't have a another set of keys, right? And then witnesses have their
38:32 own set of keys. But witness keys are only used for receding. So we define keys
38:37 implicitly for the purpose they solve. We don't have keys that you assign to proof
38:44 purpose because where the key appears in KERI determines its purpose. So witness
38:49 key appears in the witness list. Assigning key appears in the signing key list and
38:54 the rotation keys appear in the next rotated key list. So those key key lists
38:58 determine their proof purpose. There isn't a reason to have… I never came up with a
39:04 reason to have to have some generic semantic thing for keys because in
39:09 general, I don't believe that keys are very useful. Bear signatures are highly
39:13 insecure. They're not very useful. So you only use them for ephemeral things. And
39:17 proof purpose seems like something that's not ephemeral. What about the ability to
39:22 designate and rotate key agreement, so encryption keys, which are currently
39:28 derived from signing keys deterministically in the KERI ecosystem.
39:35 Would you be open to having that? – So yes, that's a really good question. KERI
39:40 doesn't do encryption. KERI is all about authentication. Now the trust spanning
39:45 protocol does do encryption. And so there's a need to define how you generate
39:53 your encryption keys. And so we have so that's not defined in KERI. That's that's
39:58 the encryption is a is a different protocol from KERI. So, so yes. So is that
40:05 a potentially yes? That's the potential yes. Yeah. Good question. Now we've been
40:11 getting a little bit deeper into the technical depths. I like going there. I
40:15 know we've got sort of our time is getting shorter. So what I'd like to do is look
40:20 get a little bit more towards the status. We're going to go pretty quickly through
40:22 the rest of the technical stuff. I will be at IIW. you. So I'll be here for the rest
40:27 of the week in case anybody wants to go deeper. All right. So we talked about a
40:33 little bit about the DID document. We won't go too deeply into there and
40:37 historical keys. Let's actually skip ahead a little bit. We already mentioned that
40:42 hosting can change. The identifier stays the same. If you go from your DID from
40:46 example.org to backup.example.org, you can have the same identity and you can
40:51 cryptographically verify that it's the same identity or person who controls that.
40:56 All right. We already talked about sort of threshold identifiers and we talked about
41:03 we don't need to get quite into duplicity detection here or some of the other
41:08 problems here. We're going to skip over. Let's go right to where the spec is at.
41:12 Okay. So the spec we're on version 0.10.3 of the did:webs spec. That's where we're at
41:17 today. We've got a number of open items. We've got about 17 different open items
41:21 that we need to handle and we We thought we had a normative baseline around August
41:28 11th. We've actually been working earlier this year with the DIF recommended DID
41:32 methods to have did:webs become a recommended DID method. We're not quite
41:36 there yet. And as I mentioned, we've still got the KERI version 2 stuff that we need
41:41 to add in. And there's some review points as we'll get into later. I'll just that we
41:49 need to provide clarity around transferable and non-transferable
41:51 identifiers. There's a couple of other things, but there's a little bit of the
41:54 timeline I became aware of the fact that if this is actually going to be used in
42:00 production for a consumer who wants to verify multisig issuers and multisig
42:06 holders, we definitely will need to write that credential proof spec and write a
42:12 library. Right now, everything's usable with simple multisig and with single sig.
42:19 It's pretty straightforward to have a single sig issuer, single sig holder. It's
42:23 because it's just one signature and just one one key. And when I say simple
42:27 multisig, I mean with not nested weighted threshold stuff. I mean, you can have a
42:32 threshold, but if it's just a flat set of multisig members, that's fine. That's easy
42:37 today. It's just the challenge is that verifiers don't know how to interpret the
42:41 nesting is the challenge. And if we're going to have a way for the verifiers to
42:46 interpret the nesting, that's a decision we have to say, do we want to have the
42:51 rules for that interpretation of that nesting, the DataWeb S spec? Probably not.
42:56 DeadWebs should be about keys, right? Not about credentials. We should probably be a
43:01 separate spec if we say this is going to be a spec for verifiers that want to
43:05 interpret the vcdm w3c data model. They're going to verify that credential with keys
43:12 deadWebs that are defined by deadWebs and KERI for a w3c credential that has multi
43:19 -sig issuers, multi-sig holders. That's more of a credential proofing spec. And
43:24 it's not just a spec. You'd want a library as well. That's easy to use. So if we
43:29 decide if somebody decides they want to use this in production for a really
43:33 advanced multisig, that's some work that needs to be done later. So, but where
43:39 we're going though is we want to we want to finish out the diff process. And so to
43:43 get to where we redo we really do want did:webs to be a a fully accepted fully
43:50 supported diff recommended DID method. And we were pretty close earlier this year. So
43:56 is the spec being approved at Trust over IP a prerequisite for DIF to recognize
44:06 did:webs as an acceptable DID method on their list? Now that I I'll repeat the
44:12 question. Yeah, I'll repeat the question just so we can all hear. It's a good
44:15 question. So is TOIP approval of the did:webs spec required in order for the DIF
44:21 recommended DID methods group to put it on their their recommended list. As far as my
44:25 understanding, it's not a hard constraint. It would help. But the more important
44:29 thing is that we have two implementations and that the DIF recommended DIF methods
44:35 team believes that it's stable enough. Now, I don't to be responsible, I need to
44:41 say I don't know for sure. I need to talk to Otto and help with the other people.
44:45 Jonathan, if Jonathan were here, he could say. So I'm pretty sure that they don't
44:50 require it because they're approving it based on DIF. It's a DIF standard. So
44:57 whether or not it's it's trust over IP approved matter doesn't matter. It's just
45:03 that whoever the whoever it is that's that's working under the aegis of DIF has
45:09 to follow the DIF rules. And so that's you and Jonathan. And all you're doing is
45:14 leveraging the task force at trust over IP to get it right. Right. I will say that on
45:20 the criteria like you mentioned from DIFF on the rubric that they give us to
45:25 evaluate how ready we are. There isn't a criteria for whether or not the spec is
45:30 approved. – Yeah, that's what I say. DIFF allows approved specs from just anybody
45:39 that wants to contribute it under DIFF. So it's its own, it has its own approval
45:45 process. – Got it. So it sounds like the answer is no. – So there's no there's
45:51 TrustRIP isn't a gating effect on it. – Okay. And the idea, the goal is that we
46:01 want to be just like DIDWebVH and DIDWebPlus and there might be a couple of
46:05 others now. We do want to be a DIF recommended DID method. It just looks
46:09 good. So once we have the KERI v2 stuff in there and all the open points addressed, I
46:15 don't see why we wouldn't be. So, all right. So there I mentioned some review
46:21 from the KERI stack working group chairs. I say Sam's review up here. It was his
46:25 particular comments. We've got four on this slide, three on this slide. I broke
46:29 them down into a few different categories. We don't have to go into the individual
46:33 depths of what these review criteria are because that's my job and I won't force
46:37 you to go through that. Just be aware there's a significant number of open
46:42 points that we have to clear to get the spec into the next version and it's
46:47 generally around some of them are actually about… Oh, I want to wrong slide. We need
46:53 to show examples. Okay, what is an ordinary did:webs consumer receive? We need
46:59 to walk you through, okay, what does a W3C credential proof look like? And so we're
47:05 going to add that at least for the simple multisig and single sig walk people
47:09 through examples so that you can by the time you're done reading the did:webs spec,
47:15 there should be enough examples in there to be able to give you a pretty good
47:18 illustration of how do I actually use this? And so we're going to add some
47:22 examples there. And this is a harder one. The nested thresholds like I've been
47:28 mentioning. We do have the recursive mapping but we need the worked case. We
47:33 need to show here's if you're going to do a nested threshold multi-safers actually a
47:37 worked case of it done. If we do the most complicated one, the other ones are piece
47:42 of cake. Okay, so we've got there's other things that need to be other open points,
47:49 but the big one is really the KERI-CESER ACDC version 2. We need to be very
47:55 explicit about things like what happens when you have a KEL that begins in version
48:00 1 and then we have some version 2 events. How does the stream declare its supported
48:04 protocol versions? And CESER and KERI 2 already have a way to declare protocol
48:08 versions, but we need to be explicit about that in the spec. We need to acknowledge
48:12 that yes, there can be a version 1 stream or a version 2 stream can be partial. So
48:17 there's a couple of things that we need to go in there and just clean some things up
48:20 and be more explicit about. And then the registry state is going to be a
48:25 particularly interesting one in KERI 2 because we have a new kind of registry and
48:30 it can be blinded. And what about unblinding life cycle of the registry
48:35 state? So we just need to be more clear and explicit about everything that KERI
48:40 version 2 brings into the picture. Okay, this is an there's an interesting
48:46 discussion in. Since we have time, maybe actually let me let me actually jump
48:51 forward a little bit. Yeah, I get a little bit more into some of the other open
48:57 points, but it's probably would be belaboring the issue here. What I think
49:03 would be what would be valuable is to show the existing repositories, show you where
49:08 things are at so that you can go play with it yourself. So right now the if you look
49:12 at the Glyph GitHub, we've got Glyph IT, we've got the did:webs resolver. That's
49:18 what this 037 is right now. That's the current version of the did:webs resolver.
49:23 That's the reference implementation. There's one old pull request to it right
49:27 now, but we'll just go ahead and skip beyond that. So, I'm going to skip forward
49:31 a little bit to show you some resources. Okay, so we do have the ECHI over IP
49:36 specifications. I mentioned there's the did:webs resolver. There's a couple of
49:41 other things that are worth mentioning. So, when you actually build did:webs into a
49:48 wallet or a verifier, you'll want to use this did:webs TS library. That library is
49:56 not a implementation of did:webs and TypeScript. It's just when you are as a
50:02 verifier, you are verifying credentials. There are libraries that like or resolver
50:09 libraries that we use to resolve key state. That's what this is useful for.
50:13 It's actually useful for from TypeScript resolving key state. So you're not
50:19 generating it, but you're pulling it in as a part of standard DIF infrastructure. And
50:24 then as a response to the DIF recommended DID methods work group earlier this year,
50:32 we presented to them the Python implementation. And we were pretty much
50:38 getting to the point where they said, okay, well, we will accept did:webs as a
50:42 DIF recommended DID method. And then they said, does it have a second
50:46 implementation?
50:50 And I'm like, no, it doesn't, but it will soon. And so I started on a TypeScript
50:55 implementation that was I tried to keep it as minimal as I could for as long as I
50:59 could, but I did start a TypeScript implementation of KERI, ACDC and did:webs
51:05 just enough so we can sort of get through that process so that when they ask us that
51:10 question, we can say yes. Personally, I don't think it's fair. I don't think it's
51:15 fair to have that as a criteria because there's it doesn't take into the
51:20 complexity of the different DID methods is completely different. Like if you look at
51:27 the lines of code that are required for some of the other DID methods, it's in the
51:32 thousands. Whereas a KERI implementation could be tens of thousands closer to a
51:36 hundred thousand. There's a lot more complexity going on. So personally, I
51:41 understand people's desire for a second implementation, but to a truly secure
51:45 complete implementation of KERI ACDC is non-trivial. It's a big deal. So I'm going
51:53 through the process just enough so where we can get through if that actually
51:57 becomes a hard blocker. We can be unblocked by that, but that's what this
52:01 second line item is. And if you want to go to a place to learn a little bit more
52:05 about did:webs, this hasn't been quite enough where you want to learn more
52:08 details, you can go to did:webs.info. That's the website actually. This Glyph IT
52:12 on the front of it, that's just where the repositories hosted. But there's a
52:16 informational website you or you can point your AI agent to at did:webs.info. So some
52:23 other work. Go ahead. Oh, let's get you the… You got it? So we got a question in
52:34 the back from Phil.
52:39 So one of my primary interests in this is being able to do DIDCOM on top of KERI. So
52:52 I'm not actually even sure what question to ask, but I mean, is it the case that I
53:01 can create a DID web ask from any KERI anytime? Do they change as you rotate
53:08 keys? I mean, what's happening under the covers? I was a little late, so maybe you
53:13 already answered this, But that's a good question. So how do we support? I'll just
53:18 repeat the question for the benefit of everybody. How do we support DIDCOM with
53:23 did:webs? And then there was a second question there as can we turn any KERI
53:27 identifier into a did:webs at any time? Yes. And there's one decision you have to
53:32 make and then one additional decision. What domain are you going to use for the
53:37 identifier? And the reason is after you make that decision, you take whatever that
53:41 domain is, put it in what's called a designated aliases ACDC and you self-issue
53:45 that. So that's the only other decision you have to make. But other than that, the
53:50 answer is yes, any KERI identifier can be turned into a DID-Webs DID, whether it's
53:54 transferable or non-transferable.
54:02 And as far as support for DIDCOM, I'm curious too. I've never quite done that. I
54:07 haven't looked quite deep enough to be able to know enough about DIDCOM to answer
54:11 your question. I would imagine. So if you just think about the inventory of what
54:16 KERI gives you or what did:webs gives you. So you've got a full key event log, you've
54:19 got keys, your keys can change, you've got consistent identity and did:webs is really
54:24 just a discoverability protocol in that it's a DID document to say, well, what's
54:29 my latest key state? So without knowing anything about DIDCOM, if DIDCOM needs to
54:35 look at a DID document to get latest key state to do communication, did:webs could
54:39 fully support that. So I had a conversation at lunch And what a lot of
54:44 people don't understand about KERI is that KERI normatively can be used in a very
54:49 simple way. A normative KERI AID can be non-transferable, use the term, means it
54:56 does not have a KEL. It has at most an inception event, but it's a vacuous
55:02 inception event, which means a non -transferable KERI identifier is
55:06 equivalent to DIDKey, which means you can use it with DIDKey. It's no harder than
55:13 using DIDKey. It is KERI. It's full KERI. It's fully normative KERI. It just doesn't
55:18 have all the security benefits of a KERI. But it still works. It's still KERI. A
55:25 KERI stack will recognize it as a KERI identifier and treat it appropriately.
55:30 What's cool about the non-transferable identifier is you can essentially derive
55:34 not just the inception event, but you could derive if you knew what domain you
55:37 wanted to commit to, you could derive a DID document just from having a non
55:40 -transferable identifier. Yeah, you just don't get the security benefits of a KEL.
55:43 Right. It's did:webs, DIDWeb that's no more no weaker and no more complicated than the
55:51 DIDKey DIDWeb. So just to repeat that for anybody that might not have heard it. So
55:55 if you're familiar with the concept of a non-transferable identifier in KERI, non
55:59 -transferable means you can't rotate keys. And you might say, well, why design a key
56:03 rotation protocol but not be able to rotate keys? Well, there are certain
56:06 instances where there's a lot of other things you get from KERI. There are a lot
56:10 of instances where you don't need key rotation. For example, witnesses have non
56:15 -transferable AIDs. They don't need KELs. The witness itself doesn't need a KEL
56:20 because its KEL is implicit in the KEL of the controller. The witness's AID is its
56:27 public key and it's a key in the KEL of the controller. So it's rotated when you
56:32 rotate witnesses. So it doesn't need its own KEL. So it is trivially just a key
56:39 pair like did key. So we use them all the time in KERI infrastructure. Whenever we
56:44 need just a bare key pair, we can use it and it's still a valid KERI AID. – And the
56:50 interesting that we're talking about this because some of the open points on the
56:53 spec are to make sure that we make exactly this clear in the did:webs spec is how the
56:58 utility of non-transferable identifiers with did:webs. And I imagine… – And then
57:02 there's another step. You can use a transferable identifier, but use it in
57:06 indirect mode. So it's transferable, but it does not have a witness, right? Which
57:13 means it's equivalent to DIDPEER. So you can do DIDPEER with KERI just like
57:18 DIDPEER. It's essentially DIDPEER, but it's full KERI normative spec because it
57:23 doesn't need witnesses. It has a key event log. So it's better than DIDPEER. It's
57:29 more secure, but it still doesn't require anything, any more infrastructure than
57:32 DIDPEER does. And you just use direct mode to exchange your KEL. Right. Right. Yeah.
57:38 I believe that's in the open. So you don't have witnesses to publish your KEL because
57:42 DIDPIR assumes that you can communicate directly. So if you can communicate
57:47 directly, I don't need the witnesses for high availability. I also lose the other
57:51 things that witnesses give me. But if I don't care about those things, which I
57:54 don't if I'm using DIDPIR, then I just use KERI in DIDPIR mode and it works just
57:59 fine. Right. So does that make sense? Does that help? Yeah. It's just like KERI does
58:04 a bunch of more things simply it's just that we they're sort of throwaways because
58:09 it's like well this is easy we can do that. I have one question. Maybe I just
58:14 misunderstood. Oh, we're done. Let him answer. That's okay.
58:22 What I'm primarily interested in is I've got a million people out there with a
58:28 system based on KERI and I want to be able to enable secure messaging through DIDCOM.
58:36 Yes. Yeah. And you can do that. Yeah. That's Yeah. And that's one reason for
58:41 did:webs is so you can bridge to any DID world because the worst case they'll just
58:48 use it as a DID web and not a DID and not the KERI stuff. Yeah. They don't have to
58:53 have KERI on their end because they'll just say, well, I don't understand KERI.
58:56 So give them the DID web. But I understand keys and I can get the key from the DID
59:00 doc and I'm good. Yeah. And then you're good. Yep. Okay. So we I I will say that
59:05 I've been told by the staff that my presentation is done and so my hour is up
59:11 but I will be here at IAW and you can get me after this as well but I want to make
59:15 room. We do have a break, right? So yeah, we have a break at 3 o'clock so. Thank
59:19 you.