0:00 Jonathan Rayback ｜ KERI Bridge to the DID World ｜ KERI Conference 2026
0:03 Okay, well, let's get started everybody.
0:06 Thank you for coming to this session.
0:09 Hopefully, you'll find it interesting.
0:12 Let's see if I can get my cur- whoa,
0:14 my cursor. There we go.
0:25 So, my presentation is on DID:Webs.
0:30 My name's Jonathan Rayback.
0:33 I am a co-chair on the DID:Webs task force
0:40 underneath the KERI stack working group
0:42 at TrustoverIP.
0:43 My other co-chair is Kent Bull here,
0:46 is here with me.
0:47 And I'm going to be talking about
0:49 DID:Webs.
0:50 I also am a chair of the DID methods
0:55 working group at Decentralized Identity
0:57 Foundation. So, I am squarely in the DID
1:00 ecosystem and community.
1:02 And the
1:07 idea behind this talk is really to talk
1:11 about DID:Webs, which is the KERI entry
1:13 into the DID:Webx
1:16 genre of decentralized identifier.
1:19 So, the talk today is going to be
1:23 I would say pretty technical, and I'm
1:25 going to really assume that the audience
1:28 is fairly familiar with KERI. I'm not
1:30 going to assume that the audience is
1:32 familiar with DIDs. I'm going to sort of
1:34 that's kind of the point of the talk is
1:36 a little bit to describe DIDs and
1:38 why we have DID:Webs and how it relates
1:41 to KERI.
1:42 So, that's kind of I guess my prelude.
1:47 Let's see if I can actually get this to…
1:56 We're going to go through a little
1:57 bit about DIDs. We're going to do a
1:59 brief discussion on DID:KERI itself cuz
2:01 there is DID:KERI came before DID:Webs
2:03 and it is another DID method. We'll talk
2:06 about DID:Web,
2:07 the original DID:Web at W3C. We'll talk
2:10 about DID:Webs and why it exists
2:12 why DID:Web exists.
2:14 Then, we'll do a little bit of a
2:16 conversation about the relationship
2:17 between DID:Webs and DID:web. We'll
2:19 talk about some other DID:WebX methods,
2:21 the status of DID:Webs from a standards
2:23 point of view, and then I'll do a little
2:25 demo.
2:28 So, decentralized identifiers or DIDs.
2:32 It is a W3C
2:33 official recommendation
2:36 As of several years ago.
2:39 There's a 1.0 core spec and I think
2:41 they're working on a 2.0 spec now.
2:44 You can click through to the actual
2:47 specification there at on that
2:49 hyperlink.
2:50 It's a type of identifier. It's
2:52 formally a URI identifier that allows an
2:55 entity to communicate things like
2:57 cryptographic material keys,
2:59 Verification methods, and or service
3:01 endpoints like say an authorized agent.
3:05 And this communication happens by
3:07 resolving is the term the DID. So, you
3:10 resolve the DID like you would resolve a
3:11 URL. And when you resolve a URL, you get
3:14 back a usually a
3:16 chunk of HTML like a webpage or
3:17 something like that, some resource. When
3:20 you resolve a DID, what you get back is
3:21 a DID document and the DID document will
3:23 contain information like what are your
3:25 current public keys, do you have any
3:27 authorized agents, etc. etc.
3:30 So, the scheme
3:32 for a DID is you have
3:35 the mandatory URI scheme
3:38 prefix, which is DID,
3:41 the colon, similar to a URL.
3:43 So, like in a URL if it's the HTTP, you
3:45 know, and then whatever. This is in this
3:46 case it's DID, whatever.
3:48 The DID method name, so in the case of
3:50 DID:Webs this would be Webs. And then
3:53 each DID method has its own method
3:55 specific identifier that's determined by
3:58 the designers of the specification for
3:59 that DID method. This is an example of
4:01 an imaginary one.
4:04 You have, in addition to the DID
4:06 document, the DID method itself
4:07 describes how do you create, update,
4:10 delete, you know, etc.
4:12 the DID documents, and every DID method
4:14 has its own mechanism for that, along
4:16 with its own method specific identifier.
4:19 There are currently hundreds of DID
4:20 methods out there in various states of
4:24 standardization.
4:27 Many are associated with specific
4:30 blockchain technologies.
4:32 There are lots of other creative ones.
4:34 There are a few that deal specifically
4:37 with web and web protocols and web
4:39 infrastructure, of which DID:Webs is
4:42 one.
4:44 If anybody has questions, by the way,
4:46 at any point, feel free. Oh, there'll be
4:48 time for questions at the end,
4:49 hopefully, but if you just want to ask a
4:50 question, ask a question.
4:53 Okay, cool. So, decentralized
4:55 identifiers, as I mentioned, there are
4:57 four method operations that every DID
4:59 method must explain. So, if you're going
5:01 to create a new DID and then have a new
5:02 DID method, you have to explain at least
5:04 how to do these four things. How do you
5:06 create them? How do you resolve them?
5:08 How do you update them? How do you
5:09 deactivate them?
5:10 Then the DID document itself is
5:16 always called did.json, so it's a JSON
5:19 format following the specific DID core
5:21 JSON scheme.
5:24 And
5:26 every DID that's compliant with the DID
5:29 spec is going to have a DID document
5:32 did.json, and it's going to follow that
5:34 particular scheme, right?
5:36 Including DID:Webs.
5:38 DID document has specified
5:41 properties, including
5:43 and I listed these out cuz these are
5:45 the ones that are particularly relevant
5:46 for DID:Webs.
5:47 The subject of the DID is in the ID
5:51 field.
5:52 The DID can have other identifiers that
5:55 it calls out as equivalent IDs
5:58 basically, "also known as"
6:01 You'll see that in a minute. It has
6:03 Verification methods
6:05 Which is basically, you know, the
6:07 list of the keys that the
6:10 DID controller is publishing the DID
6:12 document. It can have verification
6:14 relationships, for example,
6:16 authentication saying this key is
6:18 authorized to authenticate for me or
6:20 this key is authorized to sign on my
6:23 behalf in these two cases.
6:26 You can also list out various services
6:28 that are relevant to you as a
6:29 controller.
6:30 DIDs ..,
6:33 DID identifiers do support parameters
6:35 like URLs do, so you can have a DID and
6:38 then like a question mark and a
6:39 parameter on the end that
6:41 allows you to, you know, adjust the kind
6:43 of information you're going to get back
6:44 from the resolver.
6:45 And there's also metadata that comes
6:47 back when you resolve a DID. You'll see
6:49 that later when we do the
6:51 demo.
6:54 So this is an example DID document. This
6:56 is pulled from the core DID spec.
6:58 You can see in this case
7:00 the subject is this DID.
7:03 And this particular the controller of
7:05 this DID has authorized this key
7:09 which is an Ed25519
7:11 key.
7:13 This one in particular.
7:16 they've authorized it to serve as
7:19 authentication method.
7:20 It's basically what this DID document
7:22 says.
7:23 Okay?
7:24 Questions so far?
7:25 Yes. Yeah.
7:27 – There's no “also known as”…
7:30 In this one. Also known as is a optional field
7:33 in the core spec. Yeah.
7:36 Technically, authentication is
7:40 also an optional field.
7:43 In DID:Webs is not an optional field,
7:45 and that's why I called it out earlier
7:46 cuz DID:Web asset does makes, you know,
7:49 has certain
7:51 additional requirements above and beyond
7:53 the core spec, okay?
7:56 So, I just wanted to cover this really
7:58 quickly. I added this morning cuz
7:59 like if I was in a KERI conference,
8:01 I thought someone would ask what do I
8:02 DID:KERI. There absolutely is a DID:
8:04 KERI, okay? There's a specification for
8:06 It hasn't been touched in 4 years.
8:11 It's mostly
8:13 stub, I would say.
8:16 It's like got all the sections,
8:18 but each section kind of says, "Need to
8:20 fill this in," right? Like it hasn't
8:21 really been filled in yet. It's
8:23 very early draft, very draft, right?
8:27 A DID:KERI is very simple. It's just,
8:32 you know, the
8:33 prefix, the name of the DID method, which is
8:36 KERI, and then the AID. That's a DID:
8:39 KERI.
8:40 The thing about DID:KERI is, it is
8:42 entirely silent on the topic of
8:44 discovery. How do you discover
8:46 the KEL essentially? How do you ..,
8:49 cuz like if you know the KEL, this
8:51 is totally sufficient for you to go do
8:53 whatever you need to do, right? You just
8:54 you have the ID, you go to the
8:56 Key Event Log, you can do whatever
8:58 you need for validation. But the
9:00 DID method itself doesn't give you any
9:01 hint on like how am I supposed to get
9:03 this KEL? And I think this
9:05 spec was actually written pre-OOBI world.
9:07 So, like they didn't have the idea of
9:09 OOBIs even yet. So, now you would say
9:12 you're probably just going to get an OOBI
9:13 or something, right? But
9:14 in the day, you know, we just
9:17 don't have this. So, it has limited
9:18 practical use is what I'm saying, right?
9:20 In the real world today.
9:22 Because
9:23 you are going to have to negotiate how to
9:27 discover the
9:30 verifiable history
9:33 outside of the method itself.
9:37 Okay, so DID:Web going to the other side
9:40 of the world. So in the W3C, right, it's
9:42 the
9:44 web specification, web standards
9:46 organization, they thought, "Well, if
9:48 we're going to have these DIDs, we
9:49 should have a DID:Web. That would be
9:50 amazing, right?" So yes, there is a DID:Web
9:52 and it's an unofficial draft right
9:55 now at the W3C, but
9:56 it's used and it's used in
9:58 production. People use DID:Web. When
10:00 when I was at Gen
10:02 Digital, the solution we were
10:04 developing was built around DID:Web.
10:09 The thing about DID:Web is it's
10:11 all web technology, it's all web
10:14 infrastructure. So,
10:16 the way that you resolve
10:18 a DID:Web is you turn it into a
10:21 URL and resolve the URL in your browser,
10:25 with Curl, you know, programmatically,
10:28 with a headless
10:30 browser, whatever,
10:31 And you get back did.json. And that's
10:35 amazing. It's a very
10:38 very extremely limited practical use
10:41 because
10:42 there's no history of that DID document.
10:44 That DID document could change at any
10:45 time. It's subject to any of the
10:48 exploits that are common on the web,
10:49 man-in-the-middle attacks, hijacking,
10:52 you know, DNS, like any of these things.
10:54 It's completely subject to
10:56 all those problems. When you get a
10:58 DID document, you have no way of knowing
11:00 that the key that's published here now,
11:02 frankly, is the key. But you also have
11:06 no idea of knowing this controller at
11:08 some point in the past may have had
11:09 other keys, may have signed things with
11:11 other keys.
11:12 Don't know. None of that. You know You
11:14 know none of that with a DID:Web. Yes.
11:18 – I wanted to plus one and add a bit of
11:22 bit of history. So, I was one of the
11:23 co-creators of the DID:Web
11:26 spec and it was always meant to be
11:29 training wheels.
11:30 Right? This was like, "Hey, you're just
11:32 dipping your toe into DID world. You're
11:35 going to try to do key
11:37 and then, you know, try DID:Web like to
11:40 resolve it over the network."
11:42 But, it has all of the
11:44 downsides that you just mentioned.
11:46 Right? There's no key history.
11:48 There's no cryptographic binding of that
11:50 identifier to the key, all that stuff.
11:53 The funny part is, so
11:56 I've at least always meant to
11:58 add that to it.
12:00 But, what happened was… so I was
12:02 one of the authors of this spec.
12:04 And I opened an issue like, "Okay, now
12:07 that we've gotten it out there, let's
12:09 add cryptographic binding. Let's add key
12:10 history."
12:12 And the other developers were like,
12:14 "Nope." And I was like, so basically
12:15 there was a lot of pushback against
12:16 that. They're like, "We're going to keep
12:17 it super basic. We're
12:20 going to leave the binding and the
12:22 history to other methods."
12:24 This is…
12:26 So.
12:27 that's that's basically what ended up
12:29 happening. Hence, DID:Webs
12:31 and all that stuff.
12:32 – Yeah, thanks. Appreciate the
12:33 history.
12:35 So this is a the main thing I wanted
12:37 to show here was kind of just give a bit
12:39 of background, but then
12:41 if you look at the syntax of a DID:Web,
12:45 this is like relevant as we move
12:47 into DID:Webs and other DID:Webx
12:49 methods. So, you're going to have,
12:52 basically the method specific
12:55 identifier for a DID:Web is looks very
12:57 much like a URL. So, you're going to
12:59 have your you know, host information.
13:02 You can have an optional port
13:04 information. It has to be percent [%]
13:06 encoded like this with URL safe.
13:08 And then some path to whatever the
13:11 document is. This would then translate
13:13 into a URL that looks like this, right?
13:16 So,
13:17 your host is example.com on port 3000,
13:20 path to document did.json. You resolve
13:23 this, you're going to get back that JSON
13:26 DID document.
13:28 So,
13:29 because of DID:Web having the
13:32 shortcomings that it has, a number of
13:35 designers have proposed solutions.
13:38 DID:Webs is one of them.
13:40 I think it was really the first,
13:42 honestly, and then some others spun off,
13:44 but
13:45 DID:Webs has a specification. Kent and
13:48 I are responsible for it. We're working
13:50 on it.
13:51 But what DID:Webs does
13:55 is it separates discoverability from
13:58 verifiability. So we use the web to
14:02 discover the information about the
14:06 identifier, and you can use the DID
14:08 document to get the keys and all of
14:10 that. But, if you want to verify the
14:12 information in the DID document, you do
14:16 that via KERI events
14:20 through something we call the KERI
14:23 Event Stream, the KERI Event Stream,
14:26 which is kind of an
14:27 aggregation of various KERI events from
14:31 various sources that
14:32 may be relevant to the controller, and
14:34 that's aggregated into this KERI event
14:36 stream. So, to resolve a DID:Webs, you
14:39 actually are resolving two resources,
14:41 two endpoints. You resolve the did.json
14:44 and get the DID document, but then you
14:45 also resolve the KERI CESR, and you
14:48 have to validate that just like you
14:49 would any other KERI Event Stream. We
14:52 have a question back here. – Yeah, I just
14:54 wanted to ask you is it possible to get
14:56 the copy of the slides? – Yeah. There's a
14:59 Yes. There's a little QR code at the
15:02 end if you want to just scan it.
15:06 – All slides all presentations.
15:11 – Well, I must have missed that in the
15:12 beginning.
15:18 – So, it's more widely
15:20 adoptable than DID:KERI because, you
15:22 know, it's got existing web
15:23 infrastructure. It solves the problem of
15:24 how you do discoverability.
15:26 And it keeps the security
15:28 properties of KERI.
15:30 It provides way better verifiability
15:32 than DID:Web certainly, but
15:34 also than other DID:Webx methods. And
15:36 we'll talk about DID:Web versus other
15:37 DID:Webx methods a little bit at the
15:39 end. But there are properties you get
15:41 from DID:Webs that you don't get from
15:43 any other DID:Webx method.
15:48 This is a DID:Webs identifier. You can
15:50 see it looks super similar to a DID:Web
15:52 identifier. The only difference is
15:54 the last segment of the method
15:57 specific identifier is always the
15:59 autonomic identifier. It's always the
16:00 AID of the controller.
16:03 So: "da da da",
16:05 path, you've got the host,
16:07 you've got the port, optional port,
16:09 you've got the path, and then at the end
16:11 you've got the identifier.
16:13 In order to resolve this, you're going
16:15 to turn this into essentially a URL up
16:18 to the path, and you're going to go get
16:19 the slash did.json and the slash
16:22 KERI.cesr,
16:24 and the very first thing you better see
16:25 in that KERI.cesr is the inception event
16:29 for that AID.
16:31 If you don't see that, you're already
16:34 no go. No bueno. Right?
16:37 – So that path is not is just to a web
16:41 server that's serving the redirect. It's
16:43 not necessarily the KERI watcher.
16:46 – It's not the KERI watcher. 100% not the
16:48 KERI watcher. It is where you go to get
16:51 the
16:52 Ultimately, it's where you go to get the
16:53 KERI.cesr stream.
16:56 But it's also where you can for
16:57 convenience get the did.json file,
16:59 because it's a DID. By specification,
17:01 you have to have a did.json file there
17:03 at that endpoint as well. – And then with
17:05 that DID.keri stream, that's where
17:08 you're going to confirm against the
17:09 watcher to make sure that it verifies correctly.
17:12 Sure. KERI.cesr, you're going
17:13 to take the information from
17:15 the
17:16 KERI Event Stream With the file is
17:19 called KERI.cesr.
17:21 It's a CESR encoded stream of KERI
17:22 events and you're going to use that,
17:24 yeah, sure, against the watcher or
17:26 whatever validation you're
17:27 going to do. What's going to happen
17:28 first is your DID resolver is going
17:30 to validate that. That's what a DID:Webs
17:32 resolver is supposed to do is check
17:34 that.
17:36 – So, I mean I'm not hearing so I'm
17:38 trying to understand.
17:40 The CESR file is the source of truth for
17:42 that Key Event Log? – Yes. – Okay, it's a
17:46 – The CESR is the
17:48 credential encoding format used by
17:50 KERI.
17:51 Correct? – CESR, it's a
17:54 streaming yeah, it's a streaming
17:56 protocol.
17:59 Which includes encoding, yes.
18:01 So given that we are reversing we're
18:04 giving responsibility to the controller
18:07 for his/her keys? – Yeah.
18:10 – Is there a protocol that, given
18:13 this
18:14 exception log, gets pushed to the domain
18:17 of some
18:20 DNS host
18:22 or I mean a website?
18:25 Or…
18:25 – Yeah. – I'm
18:26 looking at it from the custodian
18:28 perspective. So, I have my customers, I
18:30 assign them a DID:Webs DID. – Mhm. – But
18:33 then
18:34 it breaks the whole purpose of KERI,
18:36 right? Where my controller is…
18:38 – No, we'll talk about that in a minute,
18:39 actually. But
18:42 theoretically you could provide a
18:44 hosting
18:45 platform for individuals to have a
18:48 DID:Webs. You could certainly do that. – And
18:51 the individuals have to push their own?
18:54 – You could do that for them, but
18:56 there's a mechanism that DID:Webs
18:58 has that is intrinsic to KERI that
19:01 allows the controller to authorize that
19:05 endpoint as the definitive endpoint for
19:07 their DID.
19:09 And we'll talk about that in just a
19:10 minute. And that's actually one of the
19:11 unique features of DID:Webs that other
19:13 DID:Webs methods do not have. And this
19:15 is maybe a good point, too, to bring out
19:17 the fact that
19:19 in DID:Webs, and it may seem
19:22 like a minor kind of detail, but it's
19:24 actually functionally has some pretty
19:27 important ramifications.
19:29 DID:Webs, the DID document is always a
19:33 derivative of some KERI Event Stream.
19:39 Always.
19:40 So, there's no idea of like
19:42 I'm going to go write this
19:44 like type out my DID document or
19:45 something like that, right?
19:48 The DID document should always be
19:50 generated from some KERI Event Stream,
19:52 and the current key state and all of the
19:54 other events that have happened in that
19:56 have a consequence on what shows up in
19:59 the DID document. This is reversed from
20:02 other DID:Webx methods like DID:Webvh,
20:05 where it's kind of the other way around.
20:07 The DID document and the state of the
20:09 DID document creates the verifiable
20:11 history as hashes.
20:14 It's the other way around. And
20:16 there are some ramifications for this
20:19 that come up.
20:22 It's a less nuanced
20:26 differentiation than you might think.
20:28 – Are you going to cover those
20:29 ramifications? At the end, yeah. We'll
20:31 talk about it for a little bit, yeah.
20:32 – You just piqued my interest.
20:33 [laughter]
20:34 So DID:Webs has some features that
20:37 just come because it's KERI based. You
20:39 get multi-party signatures.
20:41 You get delegation. I want to be
20:43 clear this is really clear for
20:46 people who are in KERI land, there's
20:47 kind of there's two kinds of delegation
20:48 we can talk about, right? There's
20:50 ACDC-based delegation that you get
20:53 through like vLEI, where you get
20:56 this hierarchy of credentials that
20:58 go back to a root credential. That's not
21:01 what we're talking about here. This is
21:02 AID delegation. This is where my
21:05 identifier is specifically saying, "And
21:08 this identifier is allowed to act on my
21:10 behalf". Okay? That's a different kind of
21:12 delegation. We can we can encode that
21:14 into a DID:Webs DID document. It
21:17 supports services that are relevant to
21:18 KERI like OOBI endpoints, witnesses,
21:21 agents, mailboxes, and it supports
21:23 designated aliases
21:26 through ACDCs. So this is an ACDC
21:28 delegation concept, but this is where
21:31 for example
21:33 it's required in the DID:Webs spec that
21:35 if I'm going to have my DID:Web…
21:39 I, as a controller, am required
21:40 by the spec
21:42 to authorize
21:43 the host and path information
21:45 that's going to be in my identifier
21:47 with an ACDC credential
21:49 or it's not a valid DID:Webs.
21:51 Again, that's another differentiating point
21:53 from other DID:Webx methods
21:55 because they give you no way,
21:57 other than implicitly, to say
21:59 this is the correct host and path
22:01 information,
22:01 like when I give you my DID:Webvh
22:04 and it says example.com in it,
22:07 implicitly I'm telling you I've
22:08 authorized this. In a DID:Webs when I
22:11 give you Moisey's service.com
22:15 or whatever, it is you're hosting for
22:16 people.
22:18 The person who's verifying my DID gets
22:20 to go through my KEL and gets to see
22:22 that I actually did at one point give
22:25 you the authorization to host that at
22:26 this location. This is the only DID:Webs
22:29 method that provides that capability.
22:31 – Sorry. The DID controller's KEL?
22:33 Where does it live?
22:35 They live in… the authorization?
22:38 Are you asking where does what live?
22:40 – The controller's KEL live.
22:42 – The controller's KEL lives wherever
22:45 the controller's KEL lives cuz it's
22:47 KERI, but the information from that KEL
22:50 that's relevant to the DID:Webs is
22:54 aggregated into this KERI Event Stream
22:56 and encoded in a KERI.cesr file which
22:58 lives on your server cuz you're hosting it.
23:02 Yeah, Kent.
23:04 – May I add something to
23:05 what you said earlier?
23:07 So, earlier you said, and this is
23:09 important
23:10 for those that are new to DID:Webs,
23:11 you said
23:13 the DID:Webs DID document is always
23:16 derived from the KERI Event Stream.
23:18 And I think it's worth
23:20 highlighting the fact
23:22 that based on what you just barely said
23:23 about the path information being in an
23:25 ACDC,
23:27 that the DID document will always be
23:30 derived
23:31 from an ACDC as well. You've got the
23:34 KERI Event Stream with the KERI
23:35 event logs, and actually the TEL and
23:38 ACDC. So,
23:40 cuz when I was first learning the
23:41 DID:Webs spec, I was like, oh, is there a…
23:44 Does it make sense to just have a
23:45 KEL cuz I you know, that
23:47 was simpler. I thought it
23:48 was a good idea at the beginning.
23:50 Then as I got more familiar, I thought,
23:52 you know what? Actually,
23:54 cuz my goal was maybe we can have a
23:56 DID:Webs version that only depends on
23:58 KERI, not KERI and ACDC. I tried
24:00 to simplify it.
24:01 But actually, when you look at the
24:02 security characteristics that you're
24:03 going to get into in just a minute,
24:05 Jonathan,
24:06 you want there to be an explicit
24:09 authorization
24:10 of the path segments of the whole DID.
24:13 So, it's important to realize that
24:15 the KERI Event Stream I think it
24:17 bears repeating that the KERI event
24:19 stream will always include at least one ACDC.
24:22 It has to have one ACDC. You
24:24 cannot have a DID:Webs unless there's
24:25 at least one ACDC because at the very
24:28 least, you have to authorize the host
24:30 and path information for the DID:Webs.
24:33 Period. That's all. – Why is DID:Webvh
24:37 inherently unsafe? – Well, it's not
24:40 inherently unsafe. It does a lot of
24:41 things fine. One thing it does not do is
24:44 it doesn't let you as a controller
24:45 explicitly
24:48 authorize host and path information for
24:51 your identifier. It's always implicit
24:53 because like I'm going to give you my
24:56 DID:Webvh and it's going to say
24:58 rayback.com and because I gave that to
25:01 you by whatever mechanism, you're going
25:03 to assume implicitly that I've
25:04 authorized that.
25:06 KERI says no, I'm going to actually
25:09 validate that because I'm going to check
25:11 to see if you issued an ACDC authorizing
25:14 this cryptographically. That's an
25:16 explicit authorization versus implicit.
25:19 – So that makes sense. I just want to add
25:24 Webvh implicitly authorizes, it not just
25:28 by handing over but by
25:30 signing. Right? There's an…
25:32 The identifier.
25:33 – The identifier. There's there's an
25:34 implicit authorization
25:36 signed with the [inaudible]
25:38 that serves as a…
25:40 Yeah. True.
25:43 And I might as well just get to the
25:44 point cuz I may not get to the slide
25:45 cuz I realize I'm running out of time.
25:47 But like the other thing that DID:Webvh
25:49 does not do as well as DID:Webs is the
25:52 long-term long-lived
25:54 multi-decade
25:56 identifier problem.
25:58 The spec really tries to make sure that
26:00 it's possible to do that but it gets
26:02 quite awkward. If you're going to change
26:05 like hosting, you're
26:07 going to change path websites over time.
26:10 And this is where I think that stems
26:12 from the fundamental difference. Like
26:14 you're essentially going to publish a
26:15 new
26:16 DID document with new
26:18 location information in it and then you
26:21 have to kind of go and make sure that
26:22 your verify history. A: it got transferred
26:24 from one domain to another, B: that it
26:26 like has all of the steps in it, that
26:28 nothing got missed. Like that's all
26:29 really important. Managing that over
26:31 time is much less practical than a DID:Webs
26:34 because it's the other way around.
26:36 In DID:Webs all of this is happening by
26:38 stuff in the KEL or the TEL or
26:40 one of the KERI artifacts which ends up
26:42 in the KERI.cesr and therefore your DID
26:44 document is always going to be like
26:46 reflective of the actual current state
26:48 of things cuz it's derived from the
26:51 KERI event information. – So they
26:53 tried to do KERI light and now they
26:54 have to bolt on.
26:56 They have a whole section on
26:57 witnesses and watchers now, so yeah
27:01 So, this is the also known as I want
27:04 to get into this really quick.
27:05 The spec requires there to be an
27:07 “alsoKnownAs” section in every DID:Webs
27:09 document. You must list the equivalent
27:11 DID:KERI as part of the “alsoKnownAs”.
27:14 So, at least there's going to be a
27:15 DID:KERI in every DID:Webs document cuz
27:18 that's considered an “alsoKnownAs”, it's
27:19 always by definition
27:22 any DID:Webs is also known as DID:KERI
27:24 whatever the ID is.
27:26 You may, if you choose
27:29 authorize a DID:Web endpoint.
27:32 So, that would happen by ACDC, the same
27:34 ACDC that the DID:Webs identifier shows
27:37 up in. You can authorize a DID:Web
27:39 endpoint, which means you're authorizing
27:41 a DID:Web resolver to go resolve the
27:43 DID:Web version of the
27:46 Identifier
27:49 for interoperability or for whatever
27:50 reasons you want to you want, but like
27:52 you have to explicitly authorize that
27:54 and if you don't authorize it
27:57 nobody should assume that like it's
27:58 DID:Web resolvable. You have to look for the
28:00 actual identifier in the DID document to
28:02 know that.
28:04 Verification method. Okay,
28:07 this is
28:09 what a verification method looks like in
28:11 a DID:Webs DID document. This is all
28:14 standard, you know, one of the various
28:15 options that's in the DID standard.
28:17 We support JSON web keys. We support
28:20 Ed25519. There are two or three other ..,
28:23 Whatever key
28:27 public key
28:28 are supported in KERI, we support in
28:30 DID:Webs.
28:33 verification relationship. This is
28:34 optional. It's optional to have this in
28:36 your DID:Webs, but the DID:Webs
28:39 spec does say specifically if you are
28:41 going to include verification
28:43 relationship
28:45 any key that you publish as a
28:47 public key must be authorized both for
28:49 authentication and assertion. That's the
28:51 one thing. If you're going to have it,
28:52 you have to have both.
28:54 So,
28:55 again, because KERI itself
28:58 any keys that you publish are for
29:01 either authentication or assertion.
29:06 We support these services, these
29:07 KERI services, which would look
29:09 familiar, I think, probably. Looks
29:11 something like this in the
29:14 in the DID document. So, this service
29:16 is a witness service. You can get to it
29:18 at this URL or this TCP endpoint.
29:26 Parameters, as I said, you can have
29:28 parameters on the end of a did
29:30 identifier, just like any other URI. So,
29:32 for example, this one has a version ID
29:34 parameter on the end.
29:36 This lets you tell the resolver
29:38 that you want version one of the… So, you
29:40 can go back in time and derive the DID
29:42 document that existed after
29:45 event with sequence number one occurred
29:47 in the KEL, right?
29:52 We also support this transform keys
29:54 extension, which just…
29:57 I don't actually think we have this
29:58 implemented in the resolver right now,
30:00 but like theoretically, the spec says we
30:01 should support this. This basically just
30:03 means if you pass this in as part of the
30:06 parameter, we're going to transform all
30:08 the keys in the document to that format
30:11 for convenience. This is for convenience
30:13 for people who when they resolve the
30:14 DID.
30:16 – What other formats would you use besides
30:17 CESR?
30:19 – I mean, they're like the native
30:20 format that we support is this JWK.
30:23 – Okay.
30:24 – JSON web key, right?
30:25 – I opened an issue on this. There's
30:27 public key JWK and public key
30:28 multi-base. – Yeah, those are the two. – I'm
30:31 already using public key multi-base in
30:33 the W3C cross walk, and so it's going to
30:34 be added to the resolver. – And
30:37 the spec says we should be supporting
30:38 public key CESR as well. But,
30:41 then there's document metadata.
30:43 This is where you get into some like
30:45 I'm not going to get into much detail
30:46 here, but the main one has to do with
30:48 this equivalent ID. There's a bit of a
30:50 distinction, but the idea is anything
30:52 that should show up in the equivalent ID
30:53 in the metadata. This is not in the DID
30:55 document itself, it's in the document
30:56 metadata.
30:57 Should be other DID:Webses that
30:59 you've authorized. And again, this is
31:01 going to happen via some ACDC. But, it's
31:03 possible you have a DID:Webs
31:04 example.com, but there's an equivalent
31:06 DID:Webs foo.com. That's fine. You can
31:09 have that. It has to
31:12 be authorized by ACDC. Yeah. Mhm.
31:15 – Why “equivalentId” and not put it in
31:19 “alsoKnownAs”?
31:20 This goes back to the DID
31:23 core spec. So, the idea is
31:26 equivalentId are equivalentId of the
31:29 same DID method.
31:33 So, if I have a DID:Webs identifier,
31:36 any other DID:Webs identifier that I
31:39 want to call equivalentId goes in
31:40 equivalentId.
31:42 If I have a DID:Webs identifier, it
31:46 might also be known as a DID:KERI DID
31:47 method, it might also be known as a DID:
31:49 Web DID method. You have It's more
31:51 inclusive. The alsoKnownAs section is
31:52 meant to be more inclusive. The
31:54 equivalentId is meant to be within the
31:56 scope of that DID method because it's
31:58 meant to be processed by a specific
32:00 resolver. That's going to be a DID:Webs
32:02 resolver, right?
32:04 [inaudible]
32:09 I mean, it could be that.
32:10 It could be for any other any number of
32:12 reasons, but…
32:13 – I can give an example there.
32:16 So, we like to do some work that's
32:19 called up with
32:20 DID:Iota and the twin. So, the
32:24 DID:Iota Foundation. And the integration
32:26 point, the initial integration point
32:28 between DID:Iota and DID:Webs was just
32:31 through mutual alsoKnownAs. So, from
32:33 their DID document, they put the DID:Webs
32:34 And from our DID document, we put the
32:36 DID:Iota in the alsoKnownAs sections.
32:39 – So, I'm going to go through this really
32:40 quickly cuz I want to do the little demo
32:41 and I only have about 5 minutes.
32:43 This is important though because this
32:45 is something we had to like deal with
32:47 because of KERI cuz there was no way to
32:48 deal with this in the DID document. So,
32:51 when you have
32:53 multi-signature. So, this particular
32:57 verification method type,
33:00 ConditionalProof2022, there's a spec for it at
33:01 W3C.
33:03 That's what it looks like. This is the…
33:06 This is actually the KERI Event
33:08 Stream. So, you can see here that
33:10 there's a threshold. It's a two out of
33:12 three threshold involving these three
33:14 keys.
33:15 When you get to the DID document itself,
33:17 it looks like
33:19 Oh, this is delegation. When you get to
33:20 the DID document itself, it looks like
33:21 this.
33:23 So, you get a verification method,
33:24 ConditionalProof2022. Says there's a
33:26 threshold of two, here are the keys, and
33:28 then here are the keys listed. We'll
33:30 look at that more detailed later.
33:32 And then this is a delegation of the AID
33:33 itself. It just basically, you have to
33:35 provide the delegator OOBI so that the
33:37 person can go look up the delegator's
33:39 KEL and validate that the delegation
33:41 event is in that
33:44 doc. Okay.
33:45 I'm going to really quickly.
33:48 Specification status, there's a bunch of
33:49 stuff we've done. We've registered it
33:51 all the right places. There's a bunch of
33:53 like. There's a final draft version
33:55 that's being reviewed at under the KERI
33:57 stack working group. There's a
33:59 new IANA media type registered. We also
34:02 are in the final review stage at DIF to
34:04 become a DIF recommended DID method.
34:06 Okay. We're going to do the demo here
34:08 now really quick. – Five more minutes.
34:11 – Yeah, that's why I want to do this. This
34:13 is pretty. This is more like an
34:14 illustrative demo.
34:17 [inaudible]
34:27 Why? Oh.
34:40 Okay. What we're doing here is
34:42 we're just going to kind of start doing
34:44 some KERI stuff. So, the first thing
34:45 I'm going to do is I'm just going to
34:46 accept an AID, right? So, I've
34:48 created this AID.
34:50 It has that public key.
34:54 This is what the
34:56 KEL looks like. This is what the KERI
34:58 Event Stream looks like.
35:01 Okay? So, you've got the
35:04 the AID, you've got the key.
35:06 At this point,
35:08 I cannot have a DID:Webs.
35:10 Why?
35:13 There's no ACDC authorizing the host and
35:15 path information. So, that's the next
35:16 thing I have to do. I have to issue the
35:19 the ACDC.
35:21 Here's the ACDC that I just issued
35:24 that's authorizing for this identifier
35:27 these two
35:29 identifiers. For this AID
35:31 identifier, these two DID:Webs or DID
35:34 identifiers. One is a DID:Web In this
35:36 case, I'm authorizing a DID:Web endpoint
35:37 as well in the correct format.
35:40 So, now I have this Key Event
35:44 Log, this KERI Event Stream
35:47 that includes
35:49 the ACDC right here.
35:51 Right? That has my
35:54 host and path information
35:56 committed to, right? Now, I can create a
35:59 DID document.
36:00 So, this is what DID:Webs
36:03 DID document would look like. This is
36:04 almost the most simple possible DID:Webs
36:06 DID document.
36:08 I don't have to have a witness service
36:09 if I'm working in direct mode. So,
36:11 that's optional. I don't have to have a
36:14 DID:Web identifier.
36:16 Beyond those two things, this is about
36:18 the most simple possible DID:Webs DID
36:19 document you could have.
36:21 Okay?
36:22 Now, let me show you a multisig
36:23 example.
36:25 So, I'm going to set up a multisig
36:26 group.
36:30 And they've got to do all the chatter
36:32 back and forth to get each other's
36:33 KELs.
36:36 Okay, so now I've created a multisig
36:38 group. It involves three identifiers
36:42 with each having one key.
36:48 You can see here that the keys are given
36:51 each one half weight. So, this is
36:53 fractional weight using KERI fractional
36:55 weights. That means that there are three
36:57 keys and each key gets half a vote.
37:00 So, in order to have a full vote, two of
37:02 the three have to vote, right? Two of
37:04 the three have to approve. That
37:05 gives you quorum.
37:10 That produces a DID document that looks
37:11 like this.
37:13 So, I've got my, you know, my identifier.
37:16 I have my alsoKnownAs. Now, here's my
37:18 verification method ConditionalProof
37:19 2022. It correctly determines that two
37:23 out of three, so two of these three
37:25 keys, which are listed in detail here,
37:28 have to sign in order for something to
37:30 be valid, right?
37:33 And then we get our cute pony.
37:35 CUTE PONY.
37:37 [applause]
37:40 So, there's that.
37:42 And then let me really quick just
37:45 show you in the last minute or so.
37:48 We have
37:50 Yeah, we have the…
37:53 This is the Universal Resolver and
37:54 [inaudible] the Universal Resolver. This
37:56 is mostly Marcus and his work that he's
37:58 done on this. It's pretty amazing. Kent
38:00 wrote the driver for this. So, we have a
38:02 DID:Webs driver that goes here.
38:04 Let me grab my
38:10 DID:Webs identifier here.
38:19 I'm going to resolve this DID:Webs DID
38:22 at the Universal Resolver.
38:27 There it is.
38:28 Tells me where the witness is.
38:32 You can look at the DID document, see
38:33 the DID document.
38:37 You can see the document metadata where
38:40 you should get the equivalent IDs.
38:43 Okay.
38:45 And
38:46 this is where you cannot because
38:49 DID:Webs has the unique property of
38:50 the KERI.cesr that's not available
38:53 on the Universal Resolver page.
38:55 If you want to see that.
39:02 I can resolve that. Just by Curl here.
39:10 And you'll notice too that this CESR
39:13 that's getting
39:14 printed to the terminal.
39:16 Looks really great.
39:18 This is a tool that Kent wrote recently
39:20 here that's a really nice that annotates
39:22 and prettifies the CESR stream.
39:25 This is the
39:28 aggregated chunk of KERI events that we
39:31 call the KERI.cesr, the KERI Event
39:33 Stream that created that DID document.
39:36 So you're going to go all the way back
39:37 you're going to see an inception event
39:39 here.
39:40 Somewhere in here you're going to notice
39:42 that there's going to be an ACDC.
39:45 It's very bottom.
39:48 Right here.
39:50 That authorizes the endpoints.
39:53 So.
39:55 So there you go. That's what I got.
39:57 Time up. [applause]