0:00 Daniel Hardman ｜ Applying KERI to General Evidence Problems ｜ KERI Conference 2026
0:03 Okidoke. I suppose everybody's pretty
0:04 tired at this point, but I hope that
0:07 I can keep your attention and keep
0:10 you awake through this presentation.
0:13 This is about Dossiers.
0:18 I think that this is actually one of the
0:19 more profound topics that this
0:22 community could be ..,
0:27 thought leaders and world experts on
0:30 there's a lot of untapped potential in
0:32 this and I don't think we realize
0:36 how cool that potential is. So, I hope I
0:39 can convince you and get you guys
0:40 excited about this.
0:42 This topic represents
0:50 kind of the synthesis of a bunch of
0:52 stuff that I've been working on in the
0:54 telco space, but it really is not a
0:57 telco topic.
0:59 I remember when I first heard Sam talk
1:02 about ACDCs circa 2019.
1:07 He came to a Trust over IP working
1:11 group meeting and started talking
1:13 about ACDC theory and Sam mentioned
1:18 This phrase that ACDCs are a
1:21 verifiable data graph and at the time I
1:24 thought oh that's cool and it didn't
1:26 really like impinge on my consciousness
1:28 that deeply but I have since come to
1:32 feel that's actually quite a
1:34 profound statement and there's more to
1:36 it than we give it credit for and we
1:38 could use this to solve some problems
1:40 that people can't solve elsewhere.
1:43 So let me describe the problem as I
1:47 encountered it in telco.
1:51 I came to telco from a background in
1:54 verifiable credentials.
1:56 And in verifiable credentials the
1:58 assumption is that you prove something
2:00 to a verifier and you the party who is
2:03 proving something are having a direct
2:05 interaction with the verifier.
2:08 Right? the verifier sends you a proof
2:09 request or something and the proof
2:12 request arrives at your wallet and
2:14 you get you know it gets your attention
2:17 and you make a decision and then the
2:18 proof flows back the other way. Well,
2:21 guess what? That does not work in telco,
2:25 at least in the use cases I was
2:26 exploring, because for one thing, we
2:30 wanted it to be the case that the party
2:32 that emitted a communication and signed
2:35 something
2:37 Could have that thing that they're
2:39 trying to prove verified all along the
2:42 way.
2:45 Not only that, the party on the other
2:47 side doesn't have a channel to go back
2:49 yet.
2:52 So we needed basically one-way
2:54 multiple-party verification
2:59 and not only that I needed verification
3:03 to be possible
3:04 Completely out of the out of band as
3:07 well like having an auditor or a
3:09 regulator pull a transcript of the
3:12 conversation and verify it a day later a
3:16 year later or whatever to see if we were
3:19 taking the right actions.
3:21 And again that's not really what
3:25 verifiable credentials are built to do.
3:28 This is all setting aside the more
3:30 fundamental problems which are, you
3:32 know, verifiable credentials have
3:34 mutable schemas and all those other
3:36 things. But anyway, if you set all that
3:39 aside, I still couldn't solve the
3:40 problem, right?
3:44 The other thing that became very
3:46 obvious is that we needed a much richer
3:49 evidence model than the typical
3:54 verifiable credential would provide.
3:58 Almost 100% of the verifiable credential
4:02 workflows that you see demoed or
4:04 discussed
4:05 anywhere out in the community are single
4:08 credential workflows:
4:11 "Show me your driver's license" or "show me
4:13 some subset of the driver's license,"
4:15 right? Or "show me your passport" or "show
4:18 me your COVID thing" or whatever. But
4:21 there are all kinds of scenarios in real
4:24 life every day that call for very rich
4:28 collections of evidence.
4:32 I listed a few up here and I put
4:34 them under kind of headings because I
4:36 see these patterns showing up. So,
4:39 there's all kinds of processes in the
4:41 real world that are evidenceoriented
4:43 that deal with applications, right?
4:46 You're going to apply for a grant.
4:48 You're going to apply to go to college.
4:51 You're going to submit a regulatory
4:54 filing. You're going to apply for a
4:57 job. All of these are processes. They're
5:00 typically multi-step processes where a
5:02 large body of evidence has to be
5:04 assembled and submitted.
5:07 That's not the same pattern as this nice
5:10 tidy request response
5:13 Of verifiable credentials.
5:17 There's also research activities that
5:19 happen. you're conducting a scientific
5:22 study and you want to compile a whole
5:24 bunch of evidence
5:26 and if you'd like to solve the
5:28 problems that we have in the world of
5:30 academic research with a
5:32 nonreproducibility, you'd like that
5:34 evidence that you compile to be
5:36 verifiable, right?
5:38 Investigative journalism,
5:41 Criminal investigations,
5:45 all of these fall into this category
5:47 as well. And notice here, the evidence
5:51 that you're putting in a lot of these
5:53 things accretes over time. It's not just
5:56 evidence that you just have in one
5:59 issuance event and then you're done.
6:03 When you're trying to document
6:06 something, maybe you're trying to prove
6:08 Some things about the reasons why
6:11 your company was valued a particular way
6:13 to regulators or investors, or you're
6:16 trying to capture the results of a
6:17 forensic accounting audit. Or you're
6:21 trying to submit documents for a
6:23 court case,
6:25 A court filing. All of these are
6:28 cases where evidence is quite important
6:30 and verifiability is quite important.
6:32 But the simple trust triangle that we
6:35 talk about in the verifiable credentials
6:37 world is really quite different from
6:40 what the patterns of behavior are.
6:44 Another thing that became really
6:47 clear to me is in realworld hardcore
6:52 ambitious use cases.
6:55 Lifespans of evidence,
6:58 is a big deal.
7:00 It's surprising .., now that
7:03 I've become sensitized to it,
7:05 it's almost shocking to me that this is
7:07 never said, but you'll hear somebody
7:09 analyzing you know can we prove 'xyz'
7:13 with let's lsay with
7:16 certificates or with credentials or
7:20 whatever and they'll go through a whole
7:22 deep analysis about whether it can be
7:24 proved
7:26 and they'll completely omit the fact
7:28 that they've got four different kinds of
7:32 evidence that they're trying to prove
7:33 with. And the evidence has different
7:36 lifespans,
7:37 right? So, one piece of evidence that
7:39 they're building from has a year-long
7:41 lifespan.
7:42 Another piece of evidence has a 20
7:44 minute lifespan.
7:46 And when you combine those two, what's
7:48 the combined lifespan of the thing? 20
7:50 minutes. But nobody ever analyzes it
7:53 that way. And so, they're the very naive
7:55 views about lifespan of evidence.
8:00 And you know, I just kind of
8:02 randomly picked it: Three different
8:05 categories. You could group evidence
8:07 into very different lifespan categories
8:09 than these ones I picked. But the
8:11 point is we need to start thinking about
8:14 the lifespan of evidence a little bit
8:15 more carefully. And if we do, we're
8:18 going to realize that the simple way
8:21 that we've been trying to solve certain
8:22 problems is really quite inadequate.
8:29 Another thing is that the purpose of
8:31 the different constituent pieces of
8:34 evidence that you might assemble in a
8:36 collection could be quite different and
8:38 have very different assumptions.
8:40 You don't see this when you're only
8:42 doing kind of .., it's dismissive
8:47 for me to say "Mickey Mouse"
8:48 demonstrations, but when you're doing
8:51 demonstrations are really quite
8:52 simplistic and you're using one
8:54 credential and you're saying I can
8:55 either show you all of my driver's
8:57 license or part of it, you don't realize
9:00 this, but as soon as you start
9:02 assembling
9:04 Evidence to solve a real world
9:06 problem, you find that the different
9:09 kinds of evidence that you're grouping
9:11 together introduce some interesting
9:13 complexity. So in this particular slide,
9:16 I'm imagining what's the evidence that a
9:19 loan officer has to assemble to get you
9:22 qualified for a mortgage. Okay? And I
9:25 just profiled four
9:27 different kinds. So one piece of
9:29 evidence that a loan officer has to
9:31 assemble is your last three paystubs.
9:34 Right? Now, how those last three pay
9:37 stubs are stubs are verified is pretty
9:40 different from some of the other things
9:41 up here. And how long those paystubs can
9:44 be useful is different from some of the
9:46 other things up here and so forth. So,
9:48 that's the last three paystubs. And the
9:51 purpose of putting it together in this
9:53 collection is, you're trying
9:56 to prove that the person has a certain
9:58 kind of income. And that means (my red
10:00 text there) these have to be three
10:02 consecutive paystubs and they have to be
10:05 recent and you know all these other
10:06 rules apply to that right then how about
10:09 proof of employment that's a whole
10:11 different kind of evidence
10:14 and proof of employment is probably you
10:17 want quite recent proof of
10:21 employment maybe a different recency
10:23 standard than you have to meet with the
10:25 paystubs
10:27 and the kind of credential you're
10:29 using to prove this is quite different
10:31 as well and it has a different issuer,
10:35 right?
10:37 How about the credit report? Yet
10:40 another issuer,
10:42 yet another standard, yet another
10:44 governance, and so forth. If you're really
10:48 trying to solve a serious use case
10:51 with rich evidence,
10:54 what you have to model about that
10:56 evidence and prove about that
10:59 evidence to achieve what Sam said years
11:02 ago about, you know, a verifiable data
11:04 graph is really quite sophisticated.
11:06 It's not as simple as "Oh, show
11:08 somebody a credential" and you're done.
11:14 You also kind of need to know what's
11:16 the purpose of the collection of the
11:18 evidence you're putting together. You're
11:20 not just stuffing evidence in a drawer
11:21 somewhere so you can call upon it. In
11:24 the case of the loan, going back to
11:26 that, all of these pieces of evidence
11:28 that I was talking about are going
11:31 to be evaluated at funding.
11:34 That's the time of the
11:36 evaluation or the verification. Now,
11:39 actually, in the case of a mortgage,
11:41 they're pre-evaluated once or twice
11:43 before that and re-evaluated at funding.
11:46 After funding, they don't get evaluated
11:48 anymore. So, you have to kind of know
11:50 when you're building up a collection of
11:51 evidence what you're building it up for
11:53 and when you plan to have it be
11:56 verified.
11:58 Ideally, you want to be able to verify
11:59 it forever, but in the context of the
12:02 event that was important. So,
12:03 you're never going to ask the question,
12:05 would I give somebody this loan today, a
12:08 year after they got their mortgage, but
12:10 you might go back a year after they got
12:12 their mortgage, and say, were they
12:14 qualified for this loan when they got
12:15 it, which is a different question.
12:22 As we wrestled with issues like
12:26 this, and I used the mortgage example
12:28 here just so that you wouldn't think I'm
12:29 only thinking about telco, but you know,
12:32 again, it was telco that was forcing me
12:34 to think about this. People were asking,
12:36 well, how can I prove and then fill in
12:39 the blank with a bunch of telco related
12:41 questions and I was grappling with all
12:43 of these issues. And this is where I
12:44 kind of ended up. And I feel like I
12:46 kind of came back to "Oh, KERI has a
12:49 superpower that I wasn't giving enough
12:51 credit to before."
12:53 So first of all, we started
12:56 calling this construct of a bunch of
12:58 evidence that you've assembled a
13:00 Dossier, for lack of a better word, seem
13:03 to resonate with people. I could have
13:05 called it a file, but that's so generic
13:06 that I just picked dossier.
13:10 You notice that I'm using these
13:12 icons here to represent the fact that
13:14 it's a collection of different evidence
13:16 types
13:19 and you have some kind of a process
13:21 that feeds all this evidence in
13:24 and then you go through this curation
13:27 process.
13:30 You basically get the evidence to the
13:32 point where you like it. This is like
13:34 going to the loan officer and
13:37 saying, "Okay, I've got all my documents
13:39 in. Now you can evaluate and decide
13:41 whether to give me a loan." Right?
13:44 Now you actually might have more than
13:45 one of those points. You might evaluate
13:47 it one time or seven times. Or you
13:50 could evaluate it for a very long time
13:52 to come. But you need to know what your
13:55 plans are about that.
13:59 The idea here is that this dossier is
14:03 intended to be shown to somebody but not
14:07 presented in the sense of a
14:10 verifiable presentation.
14:13 You don't have to prove
14:15 that you are the issuee of everything in
14:19 the dossier.
14:21 Let's say it's an
14:23 investigative journalism dossier.
14:26 you're not proving
14:28 entitlements with this thing
14:29 but you have to prove that all
14:32 of these interviews that happened with
14:34 certain sources really took place or
14:36 whatever. So, it's not the simple model
14:39 that you get with verifiable credentials
14:40 where you're saying here's the thing and
14:42 I'm proving it for myself on behalf of
14:44 myself and I'm entitled to something.
14:51 Once you have a dossier, this
14:54 is the other thing that I became very
14:57 comfortable with in the telco context.
15:00 The world's telco systems are built
15:03 to move very small amounts of
15:07 metadata.
15:09 So let's take the case of SMS. When you
15:12 send an SMS message, in theory, you're
15:14 sending 140 characters or less.
15:16 Nowadays, phones will send stuff over
15:19 RCS instead of SMS. And so you can
15:21 exceed that limit. But the original S
15:24 SNPP protocol wanted to move 140
15:27 character or less things. And now
15:31 imagine that you were trying to move the
15:34 equivalent of let's say a verifiable
15:36 credential or even an ACDC in the
15:39 headers of that.
15:44 You have headers that are like five
15:46 times as big as the message itself.
15:48 That's not very effective.
15:51 What we can do though, is we can
15:54 derive, and this is part of KERI's
15:56 superpower, we can derive from a
15:58 dossier. If it's really a verifiable
15:59 data graph, that means it has a SAID.
16:04 Which means, I can just send the SAID in
16:06 this really light form and somebody on
16:10 the other side who understands that it's
16:12 a SAID can say, "Oh, I bet there's a
16:14 whole bunch of data behind that." And go
16:16 fetch it and it works.
16:20 And we can make that a little bit more
16:21 convenient by turning the set into a
16:23 OOBI.
16:27 Basically now I can take something
16:29 and here I wrote 'token,' this is a word
16:32 that I don't like a lot, I kind of
16:34 roll my eyes when people talk about
16:35 security and tokens. But in some
16:39 contexts that's the way security is
16:40 enforced. So in the case of
16:44 voice calls, for example, every VOIP
16:47 system in the world carries a JWT
16:50 with every .., well it can, it's built to
16:53 carry a JWT with every SIP invite. So
16:57 when you pull out your phone and you
17:00 dial a phone number and you hit the
17:02 dial button, your phone is causing a SIP
17:05 invite, which is a small message to
17:07 flow over the world, the
17:10 internet. And typically it uses
17:15 the real internet for parts of the
17:17 transmission and then it flows over
17:19 specialized telco circuits for other
17:22 parts of the conversation. But anyway,
17:26 somehow your SIP invite ends up on the
17:28 other side and that's when the phone
17:29 starts ringing is because the SIP invite
17:31 arrived at the other location.
17:34 That SIP invite looks very much like an
17:36 HTTP request and it has headers. The SIP
17:40 protocol and the HTTP protocol are
17:42 kissing cousins. They look so similar.
17:45 They even to the point where 400 range
17:47 errors in SIP are 400 range errors in
17:49 HTTP and everything
17:51 - Intentionally?
17:52 Yeah, they very deliberately copied
17:54 HTTP when they built SIP. So all that
17:58 you're doing really with that
18:01 infrastructure, if you want to decorate
18:03 your call with evidence, is you're
18:06 putting a header ..,
18:09 and think of it like an HTTP header,
18:11 It's almost identical. It says identity
18:13 colon space and then a bunch of stuff
18:16 that's B64 encoded. And that B64
18:19 encoding is
18:25 that B64 encoding is the JWT that
18:28 I'm talking about.
18:30 And that JWT can have a field in it, a
18:33 claim that is the URL to your evidence.
18:38 That's basically all we're doing.
18:41 But this same technique can be applied
18:44 well outside of telco.
18:47 And that's why I'm interested in this.
18:48 So you can derive any number of tokens
18:50 that keep referring back to the same
18:52 piece of evidence. And that's what we're
18:54 doing over and over again when you make
18:56 phone calls. If you're Microsoft and
18:58 you're making outbound calls,
19:01 every outbound call that you make
19:03 carries a hyperlink back to the same
19:04 evidence, but a new signature, right?
19:08 There's a new signature on the JWT,
19:10 but the evidence behind it, the stable
19:13 evidence doesn't change.
19:17 So what does a dossier actually
19:21 look like? For those of you who
19:23 are ACDC people, this is a
19:26 trivially simplified version of an
19:28 ACDC, I have JSON and in it I have
19:33 a field called A and a field called E.
19:37 You know what those mean, attributes and
19:39 edges. All that a dossier is really
19:43 is a particular kind of ACDC or maybe I
19:47 should say a flavor of ACDC
19:49 where the A fields are used to carry
19:54 curation metadata like who built and
19:57 assembled this thing when was it
20:00 assembled under what governance rules
20:02 was it assembled what are the
20:03 assumptions about how it's going to be
20:04 used that kind of stuff but none of the
20:07 credential content
20:10 is in the A field.
20:12 All of the credentials are then in
20:14 edges.
20:16 So, you're just saying
20:18 "I assembled .., I'm applying for a
20:20 loan. Here's my mortgage
20:22 qualification packet." That's all up
20:25 here. And then every individual piece of
20:28 evidence that I submitted is down in the
20:30 edges.
20:34 The edges just point to another ACDC.
20:36 That's right. The edges just point to
20:38 another ACDC.
20:40 And this is where we get verifiable data
20:42 graphs. Yeah.
20:48 There's a lot of different kinds of
20:53 evidence that you might want to put in a
20:55 verifiable data graph. The obvious
20:58 one is credentials. All of us think
21:00 about credentials a lot. But in fact,
21:03 the more I have worked on this, the more
21:05 I think these other ones on the left
21:07 side of this slide may be more
21:09 compelling in some ways. I want to put
21:12 A signed PDF in my evidence. I want
21:16 to put an MP3 file in my evidence
21:18 because I'm a journalist and I
21:19 interviewed somebody. I want to put
21:22 a movie in there because I captured some
21:24 video. I want to put an AutoCAD
21:27 drawing in there. I mean anything you
21:29 can imagine we can embed
21:33 In an ACDC simply by using the
21:37 attachment mechanism
21:40 and that's quite important. Some of
21:42 these might be so big that we don't
21:44 actually want to put them in an ACDC.
21:47 We just want to put a hash. So like a
21:50 genome, your full DNA. I don't think
21:53 you'd want to put a 40 gigabyte genome
21:55 inside of an ACDC, but you could
21:57 certainly put a hash of your 40 gigabyte
22:00 genome inside the ACDC along with a URL
22:03 of where to find it or something like
22:05 that.
22:07 Anyway, so these two techniques,
22:10 embedding and wrapping are what I'm
22:12 contrasting on this slide. The idea with
22:14 embedding is you have data that's not
22:16 credential oriented, but it's still data
22:19 that's important.
22:21 Scientific readings you know, all
22:23 these other examples I went through. So,
22:25 you want your assembly of evidence to
22:27 reference it.
22:30 Let's suppose you're an NTSB crash
22:32 scene investigator and a plane crashed
22:35 and now you're trying to
22:37 take photographs of all these different
22:38 parts of the plane and how the wreckage
22:41 was spread out and all this other stuff.
22:43 you would be embedding JPEGs
22:47 or hashes of JPEGs in your dossier when
22:50 you're filing your accident report.
22:55 Wrapping is relevant when the thing
22:59 that you want to put in your verifiable
23:02 data graph is another form of verifiable
23:04 data, but it's what I would call foreign
23:08 to the ACDC world. So if you have an
23:12 X.509 certificate and you want to put it
23:14 in your verifiable data graph or if you
23:18 have a W3C verifiable credential and you
23:20 want to put it in your data graph, you
23:22 can do that. The tech now you can do it
23:25 by doing an embedding but I don't think
23:27 that's a good idea and I'll explain why
23:28 in a second. So what I would recommend
23:30 is this wrapping. What you're
23:32 essentially doing is you're verifying
23:33 the evidence with its native stack
23:37 and then you're issuing a new ACDC that
23:39 says on such and such a date I so and so
23:43 verified this credential and it was
23:46 legit on that date and you're making an
23:49 explicit claim one way or the other
23:51 about whether you take any
23:52 responsibility for revocation status.
23:55 You can say, "I explicitly disclaim any
23:57 responsibility for telling you ..,
24:00 in the ACDC land, I'm not going to
24:02 reflect the revocation status. So all
24:04 I'm telling you is it was valid on this
24:06 date." The end. Or you could say, "No,
24:09 I'm a really super fancy service and
24:11 this kind of evidence is really
24:12 important and I will just [tell you],
24:15 within one day of latency, I'll tell you
24:17 if the other thing gets revoked, I'll
24:19 revoke the ACDC wrapper." That's
24:22 kind of up to the person, but the
24:23 wrapping is the name of the technique
24:25 that I'm talking about. And I could
24:28 imagine doing this because it builds a
24:30 very nice bridge. You can stick an ISO
24:32 mobile driver's license in this. You can
24:34 stick a verifiable credential W3C
24:39 generation 1 or generation 2. You can
24:42 stick in a nonredit presentation in
24:43 that, whatever you want.
24:51 I anticipated that at this
24:54 conference there might be some people
24:55 here who know a lot more about
24:58 verifiable presentations than I do and
25:01 that they might be asking, well, isn't
25:02 this the same thing as a verifiable
25:04 presentation
25:07 In
25:09 VC land?
25:11 And the answer is it does have some
25:14 similarities. That top line of this
25:15 table, both of these are
25:19 cryptographically verifiable containers
25:21 of evidence.
25:24 But there are some profound differences
25:26 too. And these differences lead to a
25:29 very different set of addressable use
25:31 cases.
25:33 Without belaboring the point too
25:36 much, I'll simply say that
25:42 the life cycle is really
25:46 crucial here. A verifiable presentation
25:48 is intended to be verified when it's
25:50 generated and then it's thrown away.
25:52 It's ephemeral.
25:55 A dossier is not right. You don't throw
25:57 it away. Yes, you make a decision about
26:00 whether to fund the loan for the
26:02 mortgage on a particular date, but I
26:05 guarantee every one of you that has a
26:06 mortgage your loan officer has a
26:08 file somewhere in their back room or
26:10 whatever that has all the data that you
26:12 ever submitted and they can look it up
26:14 whenever they want because that's
26:16 important data to keep on file.
26:19 And the same thing would be true if
26:20 we're talking about investigative
26:22 journalism. If we're talking about crash
26:24 scene investigations or if we're talking
26:27 in my case about the reputation of
26:30 Microsoft and proof that it can use the
26:32 world's telco infrastructure in a
26:34 particular way, it needs to be on file
26:36 and kept.
26:42 The other line that I want to just call
26:45 out here is the bottom one.
26:47 Really the meaning of these is a little
26:49 bit different.
26:50 In the case of a dossier, what you're
26:53 saying as the person who assembles
26:55 the dossier is here's a bunch of data
26:58 that I put together that I'm signing
27:01 over it, but I'm not necessarily
27:03 asserting that everything in this data
27:05 is something I believe. Like if I'm an
27:08 investigative journalist, I could well
27:10 have interviewed a bunch of people who
27:11 lied to me on camera or while I
27:14 was taking notes. And I want to document
27:17 that they lied to me. And I'm not
27:18 necessarily asserting that they told me
27:20 the truth just because I signed over it.
27:22 I'm asserting when I sign that I was
27:26 the collector of this body of
27:28 evidence and collectively it represents
27:30 some purpose that's described in the
27:32 metadata about that dossier.
27:35 Right? So maybe I'm assembling all of
27:38 the evidence from somebody who lied
27:40 to me because I want to, you know, take
27:42 him to court later. So it could be
27:45 full of lies. Everything that I put in
27:46 the dossier on purpose.
27:49 The again the metadata of the dossier
27:51 tells you the purpose. Whereas a
27:54 verifiable presentation is always about
27:57 proving enough to get me the
27:58 entitlement.
28:04 I feel like I'm just talking and
28:06 talking. Everybody's listening quietly.
28:08 I want to shake the room up and do
28:10 something, but I don't know what to do.
28:11 Anybody have any questions? Richard.
28:14 - When we talk about a verifiable
28:16 presentation, the protocol includes the
28:18 ability to make claims across the
28:21 different credentials ination.
28:23 Does the dossier I don't know if it's
28:25 going to be a protocol. We haven't got
28:26 to that part of the conversation, but
28:28 does it include the ability to say this
28:30 name on this one is supposed to
28:32 reference name on that one?
28:34 But it doesn't do that because of
28:35 the dossier. It does that because that's
28:37 a native feature of ACDCs. When you
28:39 declare an edge in an ACDC, you can say
28:42 this edge must be related to that edge
28:45 in the following way. There's an
28:46 operator that you can declare the
28:48 dossier spec by the way to kind of
28:52 prefigure your question about protocols.
28:55 A dossier is not really a protocol, but
28:57 it is a data format. It's a
29:00 specialized form of ACDC and there's
29:02 enough kind of extra rules that we
29:05 want to attach to a dossier I think that
29:07 It needs a spec. So we're writing
29:10 a spec about it. And the spec right now
29:14 introduces a couple of new operators
29:17 to enrich what edges can say about
29:22 one another and things like that. Sam, I
29:24 saw your hand go up.
29:26 Oh, Phil.
29:27 Yeah, two questions. This is one I think
29:28 is an obvious yes, but can a dossier
29:30 point to another dossier?
29:31 Yeah, for sure.
29:32 And then I thought the use of an OOBI in
29:35 the SIP header was an elegant way to
29:40 AID itself. Have we considered doing
29:42 that in edges either in the dossier or
29:45 in the ACDCs?
29:46 I have not thought about that.
29:49 But as soon as you said it, I was
29:50 like, wow, why didn't I think of that?
29:52 That's a really great idea. I love that.
29:54 What was your idea first?
29:57 Edges are actually a block. You can
30:01 add as many properties in an edge as you
30:04 want. So it's just a matter of saying
30:06 you're going to add an UI to an edge.
30:09 Okay.
30:10 Cool.
30:11 This is an example of the kind of thing
30:13 that the dossier spec needs to say is
30:15 here's a really useful way to, you know,
30:17 make this more powerful. Yeah.
30:29 Since your voice is quiet, why don't you use the [mic]?
30:31 Anyway,
30:32 no, but he's only recording his
30:34 thing.
30:35 Yeah, for the camera.
30:37 The gent speaking to his name.
30:39 Yeah, I got
30:41 I got to talk. I'll be No, don't pick up
30:43 my sound.
30:44 Okay, pick me up.
30:47 It wasn't that I said verifiable data
30:49 graph
30:51 20 years ago or 2020 or whatever it
30:54 was just came out of nowhere. It is
30:58 comes out of the theory of automated
31:00 reasoning. Automated reasoning you build
31:06 verifiable data graphs with aggregation
31:09 operators. The only difference is
31:12 that you're trying to do often live
31:15 control of something where you're saying
31:18 I've got 50 sensors, I've got
31:23 data process, I got a database, I got a
31:25 map, I got all of this stuff and I have
31:27 to make a live decision with the best
31:30 available data to me at the time that I
31:32 do it. And all the data is aggregated
31:35 differently. So you have a whole family
31:36 of aggregation operators and you just
31:38 have connections between all of your
31:40 sensors and you know sensors
31:43 aggregate to aggregate and
31:45 then and it just looks like this big
31:47 complex graph and all I had to do was
31:49 say "Well, if I want to make a
31:51 trust decision that's no different than
31:54 any other automated reasoning." So we
31:56 should be able to map ACDCs directly to
31:59 how you actually do the processing.
32:02 You shouldn't be building some
32:03 artificial thing that is
32:06 divorced from the actual way you make
32:08 you make decisions. And so ACDCs
32:11 model how you actually make
32:13 automated decisions.
32:15 And that resonates for me because of
32:18 that earlier slide that I was
32:20 showing about how to make a decision for
32:21 a mortgage. You're actually .., this
32:24 is the real way that the real world
32:25 works, right? You're assembling a bunch
32:27 of evidence and evaluating it and .., yeah.
32:31 Go ahead. – So very different approach to
32:34 all of this. But from the legal
32:36 standpoint, we're now starting to move
32:39 to modeling where the fair
32:44 information practices are actually going
32:46 to be mandated. Your original
32:50 definitions
32:52 solved a number of problems because the
32:54 the data collected is the minimal
32:58 data necessary to fulfill the purpose.
33:00 it is a specific purpose that even
33:04 though the information may be kept in
33:06 the dossier, it isn't ending up in some
33:09 giant data lake that then can be used
33:12 for other purposes later on. And I
33:15 think the other piece of this
33:18 that's really elegant is that if you
33:24 have, in government, social
33:27 programs that require three or four
33:29 agencies to interact right now they
33:33 claim they need a data lake.
33:36 So this allows you to decentralize
33:39 that none of them is in effect the
33:42 steward. they are just the steward of
33:44 the particular piece of it that they
33:46 need to integrate for the programmatic
33:49 utilization.
33:50 I love it. And this actually segways
33:54 directly to what I was going to say
33:55 next. Traditional verifiable
34:00 credentials and in fact most ACDC use
34:02 cases that we think about assume a
34:06 single issuer,
34:08 right? But one of the things we're
34:10 introducing in the dossier spec is the
34:13 idea of joint issuance.
34:16 And the idea here is not that you
34:20 have joint issuers all using a single
34:22 multi-IG even. You just have joint
34:24 issuers. They're all individual parties
34:27 representing themselves with different
34:29 AIDs.
34:30 But in the ACDC, in the dossier,
34:33 you can say this dossier takes effect as
34:36 soon as I have five of the following 18
34:40 people who've signed.
34:43 And it's just a completely asynchronous
34:45 thing. And I put a picture of the
34:47 signing of the Declaration of
34:48 Independence up here because you had a
34:50 bunch of people in a room. But actually,
34:51 in some ways, that picture is bad
34:53 because it suggests everybody got
34:54 together right at the same time. In
34:57 fact, what we're suggesting here is you
34:59 don't have to do that.
35:00 You can have one party sign and
35:04 then a week later in a different place
35:06 under different circumstances you can
35:08 have another party sign and another
35:09 party and so forth. Sam,
35:11 – I just want to clarify you're using sign
35:14 as a euphemism for actually
35:18 anchoring into the registry that is
35:21 of stuff like that but it's the same
35:24 thing. You're anchoring the same
35:26 thing with the different AID, but
35:29 everything else is the same. And so it's
35:31 a joint issue because everybody issued
35:33 the same facts.
35:37 Yes.
35:39 In order to verify, we would need
35:42 the verifier to do a little bit of
35:44 work that it doesn't currently do,
35:46 right? It's going to have to go look up
35:47 signatures in five different places or
35:49 something. Unless this bottom line an
35:52 optional finalizer can say, "Look, I've
35:54 already done all of that work. Here's a
35:57 a thing in my KEL that just lists
35:59 everybody that already signed and you
36:00 can go verify it." So, that would
36:02 be a nice thing. But I really like this
36:04 model. I think that joint issuance is
36:06 going to create a lot of useful
36:09 flexibility for us. You can also have
36:11 models, by the way, that aren't M ofN
36:13 models. You can just say this is a
36:15 petition and as soon as we get a
36:17 thousand signatures on it, whatever.
36:20 There's no N in it, right? It's just
36:23 this is the threshold is M, you know. So
36:26 anyway, there's some really neat things
36:28 about that and I can see how there's
36:30 certain legal behaviors that
36:33 this facilitates very nicely.
36:36 Now I wanted to say something else.
36:39 This is another way that some of the
36:41 superpowers of ACDCs come into play
36:44 in the telco use case that I had. I had
36:47 a case where I wanted parties all along
36:50 a chain to be able to verify but the
36:52 amount of data that they needed to see
36:54 varied.
36:56 Okay. A regulator needs to see more
37:00 and an intermediary on a transmission
37:02 chain needs to see less.
37:05 And the beauty of it is I can have a
37:07 dossier that is sparse for one
37:09 audience and full for another and it's
37:11 the same dossier and they can both refer
37:13 to it the same way
37:16 which means you have the option of
37:18 assembling this dossier but having many
37:20 different variations on the verifiable
37:22 data graph that expose lots or little
37:26 amounts of what's needed.
37:29 So in telco when you have the rule
37:31 about lawful intercept for example law
37:34 enforcement agencies require that
37:36 they be able to see certain things about
37:39 Your communications. Anywhere
37:41 where there's a jurisdiction like that I
37:43 can solve that problem with a nice rich
37:45 dossier view and anywhere where I can
37:48 show less I will do it.
37:52 So are you using selective disclosure to
37:54 mean the category of controlled
37:56 disclosure or just the specifically
38:00 selective disclosure as opposed to any
38:02 of the other variations of disclosure?
38:05 Well, the original title of this slide
38:07 When I wrote it a month ago, it said
38:09 graduated disclosure.
38:11 And then I thought, oh, I could play
38:14 around with this. Oh, I could stick it,
38:15 you know, I could take contractually
38:17 protected disclosure. There's all these
38:18 variations on it. I don't know which
38:21 is the exact frame that you want to
38:24 use in a particular context. The point
38:27 though is that I can suppress data or I
38:30 can show data using variations
38:34 that all have the same root hash and
38:37 I don't know what you would call that
38:40 control this thing is called partial
38:43 disclosure but essentially it is
38:45 creating a nonbinary Merkle tree of the
38:49 data so that the fully compact is
38:52 essentially the root and then he's just
38:54 tracing it out, but the hashes
38:56 along the way are generated. So you
38:59 can do a proof of conclusion the same
39:01 way you would a Merkle tree just by
39:04 walking down and then expanding it
39:06 at that point saying, "Oh, here's what
39:07 it is." So, it's a non-binary
39:12 hash graph that you can do some sort of
39:15 booster.
39:16 So, if I had to use a different
39:18 word, I'd call it contextual display.
39:20 Okay.
39:22 That's a good one.
39:24 Okay. I'm basically done with my
39:26 presentation at this point. This is
39:29 this is where you can get more
39:31 information. The spec is currently at
39:33 version 0.6.
39:35 We'd love to have people contribute or
39:37 if you don't feel like contributing
39:38 because you're way too busy like me.
39:41 I get it. But at least keep track of it.
39:43 I'd love to have some people just
39:46 show up and fix a typo so that I can at
39:48 least put more names on the spec besides
39:50 me.