0:00 Samuel Smith ｜ The Digital Identity Tradespace ｜ KERI Conference 2026
0:03 My name is Sam Smith.
0:06 If anybody
0:08 can't remember my name,
0:10 [laughter]
0:12 it's because you're more identity
0:14 challenged than my parents thought I
0:15 would be than they gave me that name.
0:18 Anyway, that's all right. Great.
0:21 I'm going to talk about the trade space
0:23 of KERI, not in detail,
0:26 but I'm going to talk about why
0:29 we solve
0:31 the privacy problem using bulk issuance
0:35 instead of other mechanisms. And
0:38 I'll give you the shorthand
0:40 to the trade space.
0:43 KERI's policy is security first always,
0:47 which means if we're ever in a situation
0:49 where we're going to make a trade, and
0:51 we're going to trade for weaker security
0:54 or stronger something else,
0:56 we're not going to make that trade.
0:58 We're going to always trade for stronger
1:00 security. We're not going to
1:02 say, "Well,
1:04 that security's okay.
1:06 We can do this," because
1:11 the trajectory of technology for
1:14 security is that every weak trade for
1:17 security is a bad trade. May
1:19 not be today, but in your lifetime it'll
1:23 be a bad trade. So, let's try to be
1:26 creative about solving the other
1:29 problems without starting off by saying,
1:32 "Well, it's easier to solve those
1:34 problems if we just throw security under
1:36 the bus."
1:37 Actually say, "You know what? If my
1:39 constraint is I'm not going to throw
1:41 security under the bus, what's the best
1:43 I can do? And is it good enough?" And
1:44 that's really the
1:46 the difference in the ethos.
1:49 So
1:51 for those of you know,
1:53 With KERI, each AID controller is
1:57 its own identity provider.
1:59 So, we use this phrase Keys-at-the-Edge.
2:02 Each edge self-authenticates.
2:04 What that means is there are no
2:06 third-party IDPs, no relying parties, no
2:09 trusted intermediaries.
2:11 Every interaction is end-to-end or
2:14 edge-to-edge, depending on your
2:17 your mental model, right? If I have
2:19 a network and I have people at the edge
2:21 trying to get in, it's called an edge.
2:23 If I'm trying to communicate across a
2:24 network, it's called an end, but they're
2:26 the same thing from KERI's perspective.
2:30 In my plenary this morning,
2:33 I ended with this idea of Reputable
2:35 Autonomic Pseudonymity in Control over
2:38 Confidential Contexts.
2:40 The way we solve privacy
2:43 is with this one, control over
2:44 confidential contexts. And bulk issuance
2:47 gives the user precise control over
2:51 confidential contexts. So, they get to
2:53 decide
2:55 what the reach and scope of their
2:58 disclosure are in terms of their
2:59 correlatability.
3:02 We understand that every piece of
3:04 information that we share over the
3:06 internet
3:08 is correlatable.
3:09 There is no such thing as
3:12 no correlation.
3:14 Unlinkability is not the same as
3:17 uncorrelatability.
3:20 So, you know, we called it Rhapsody [RAPC3].
3:23 Let's see how we use ACDCs for this.
3:27 ACDCs… And I think most of you are
3:30 familiar, but I recognize some faces
3:32 in here that maybe haven't actually sat
3:34 through,
3:35 you know, something about ACDC. So, I'm
3:37 going to give a couple of just short
3:39 introductions cuz I've got a lot of
3:41 detail to go through, and if
3:43 if you thought this was going to be a
3:46 high-level talk like the plenary this
3:48 morning, I'm really going to disappoint
3:50 you.
3:51 This is
3:54 going to go fast.
3:55 So, think of an ACDC as a graph fragment
4:00 that has
4:01 edges that point to other graph
4:03 fragments.
4:04 And so, if you take graph fragments and
4:06 connect their edges, you get a graph.
4:09 That's the point.
4:11 But, the edges are part of the ACDC.
4:15 And the reason for that is the
4:17 authority and the authentication for
4:20 each graph fragment includes its edges.
4:24 So, you authenticate the
4:27 attributes which are the node and its
4:29 edges, and that is an ACDC. And now I
4:32 can compose
4:35 arbitrary data structures from graph
4:38 fragments because all data can be
4:39 graphed. Right?
4:42 And the edges (It's called a labeled
4:45 property graph) because the edges have
4:47 properties.
4:48 The edges can be blinded. They can be
4:51 private edges. They can have
4:53 operators. They can be grouped together.
4:57 They can be aggregated. They can be used
4:59 in various ways. The edges have
5:02 their own set of individual attributes
5:06 that are metadata about the way you
5:09 compose the information
5:12 in a secure way.
5:14 And other approaches to composing
5:16 information don't allow you to securely
5:20 compose the information from multiple
5:22 sources. They put it all in one data
5:25 structure that under the hood is
5:27 actually a graph, right? If I have a
5:29 nested
5:30 set of JSON blocks, it's a graph,
5:33 but it's not composable in a secure way.
5:37 It's all or nothing.
5:39 And so, ACDC says, "No, that's a bad
5:40 idea. We need secure
5:43 composition."
5:44 ACDCs are designed to solve
5:48 problems where you need Perpetually
5:50 Verifiable Issuances. Can you use an
5:52 ACDC with a bare signature
5:55 with a short crypto .. [inaudible]
5:56 Absolutely. You don't have to anchor
5:59 your ACDCs in a Transaction
6:02 Event Log or a KEL to make them
6:03 perpetually verifiable.
6:05 But we have to solve the perpetual
6:07 verifiability problem.
6:09 So let's solve the hard problem first.
6:12 So I use this sometimes that people are
6:14 familiar with it. If I have a bunch of
6:16 rocks, a bunch of gravel, and a bunch of
6:19 sand, and water, and I want to get all
6:22 of that into a jar, and get the most
6:25 that I can get in there,
6:27 what do I put in first?
6:31 The water, right? I put the water in,
6:33 right? No, I put the rocks in first,
6:35 then I put the gravel, then I put the
6:37 sand, and then the water fills in the
6:38 blanks. So ephemeral applications are
6:41 the easy thing. Everybody knows how to
6:43 do ephemeral application. Nobody solved
6:46 the perpetual verifiable problem before
6:48 KERI and ACDC in a
6:49 decentralized way. Obviously, if you
6:52 have a database and a central authority
6:54 to the database, you can solve any
6:55 problem you want. It's easy, right? But
6:57 that's not the
6:59 hard problem of decentralized data. The
7:02 hard problem of decentralized data is
7:05 how do I solve perpetual issuances
7:06 without a centralized authority?
7:09 Right? Each fragment is separably
7:12 authenticatable. That means the graph
7:14 doesn't have a single source. Every
7:16 node, every fragment can come from a
7:18 different source. They can all come from
7:20 one source or different ones. That
7:22 allows me to do delegation, all sorts of
7:23 things.
7:24 Right? So I have
7:26 Delegable, Attenuable, Aggrable,
7:29 Revocable, Transferable Authority.
7:32 – Can we break that down?
7:34 – Okay.
7:36 Well, I haven't talked about
7:37 aggregating, but notice that if I have
7:39 multiple ones going in one thing, I've
7:41 aggregated. If I have a chain, that's
7:44 attenuable
7:46 delegable. And transferable means that I
7:48 can
7:50 I can change who's in control.
7:54 And actually I'll talk about that in my
7:57 plenary tomorrow. All right.
8:00 What this allows us to do
8:04 for verifiable credentials, which are
8:06 all about authority,
8:07 is that we can have high fidelity
8:09 modeling of real world authority
8:11 structures.
8:13 Not authority structures that are the
8:16 best we can do because we have a broken
8:18 model, which is
8:20 current security, current OAuth
8:23 OIDC. It's all broken models because it
8:25 says, "Well, this is what we can do with
8:26 the technology we have. We have to use
8:28 the secure sessions. We have to use
8:30 encryption. We have to use things like
8:32 Diffie-Hellman, TLS key exchanges, and
8:35 we have to do ephemeral stuff because we
8:36 don't know how to solve the
8:38 perpetual verifiability problem. And
8:41 then we'll make the rest of the world
8:42 change their authority structures to
8:44 match that."
8:45 And what ACDCs say from the
8:48 beginning is, "No, no, that's not the
8:50 way real world authority structures
8:52 work. Real world authority structures
8:54 have these properties."
8:57 And it doesn't matter whether it's
8:58 organizational identity or personal
8:59 identity, right? If I'm a parent and
9:02 I have a child and I want to do
9:04 and I want to have
9:07 control over what my child is allowed to
9:10 do, then I've got a delegable
9:12 attenuable authority structure.
9:15 Right?
9:16 It looks like organizational identity.
9:19 So those are the problems we're
9:20 solving.
9:24 This was supposed to be animated. I
9:26 messed up. Okay.
9:29 I'm not going to talk about this stuff.
9:30 I put this on the slide because I'm
9:32 going to talk about blind
9:34 bulk issuance.
9:36 But a lot of people say because I spend
9:38 a lot of time
9:40 talking about
9:43 about the other things that ACDCs do,
9:46 that we actually don't support all of
9:48 the least disclosure mechanisms that
9:50 all the other credentials do. We
9:52 just don't support a particular type of
9:54 proof stuff because we feel that
9:56 it makes an unfortunate security
9:59 compromise. So, we follow the
10:02 principle of least disclosure. We have
10:03 something called gradual
10:05 disclosure
10:07 that allows us to progressive least
10:09 disclosures
10:11 so that we can negotiate how much
10:13 information is disclosed in a particular
10:15 context. Now,
10:17 control over confidential context. That
10:21 means I don't disclose any more
10:23 information than I need to,
10:26 to facilitate a transaction. And that
10:30 transaction might mean negotiating over
10:33 what I'm going to disclose.
10:35 And so, I can have multiple
10:39 interactions and transactions to
10:41 negotiate the full set of disclosures
10:45 and how I do those disclosures. And so,
10:47 we have something called compact
10:48 disclosure, metadata disclosure, partial
10:50 disclosure, nested partial disclosure,
10:53 full disclosure, and selective
10:54 disclosure. Those are all disclosure
10:56 mechanisms that don't exist anywhere
10:57 else except in ACDCs, except for
11:00 selective disclosure. They have one
11:02 mechanism for selective disclosure and
11:03 nothing else. And so, it means you
11:05 can't model real-world authority
11:08 structures when it comes to disclosing
11:09 information. You need more
11:11 capability. And then, you can do
11:14 combinations of the above. And then, we
11:16 have bulk issued instance disclosure,
11:18 which I'm going to talk about today. So,
11:20 so I'm only going to talk about one of
11:22 the things on this list. And then, we
11:24 have contractually protected disclosure,
11:26 which you've heard about, right? There's
11:28 several people that have mentioned that.
11:29 You've seen demos of contractually
11:31 protected disclosure. So, that is
11:33 essential if we're going to have a
11:35 comprehensive approach to privacy.
11:37 Comprehensive approach says you invert
11:39 the economics. One of the ways you
11:41 invert the economics is impose
11:43 liability
11:45 on the recipient of the disclosure. They
11:48 don't get a safe harbor. They don't get
11:50 to do things like de-identify the data
11:52 and then they can do whatever
11:54 they want with it. You attach
11:56 strings to the data and those strings
11:58 are enforceable which changes their
12:01 their behavior. So, we're changing
12:03 behavior of the recipient of the
12:05 disclosure, not trying to minimize the
12:08 disclosure and then hoping they can't
12:10 use it against us. We actually say you
12:12 can't use it against us and if you do,
12:14 this is what we're going to do to you.
12:16 Right? So, we need to have a contractually
12:18 protected disclosure and we need to have
12:20 one that the recipient will agree to.
12:23 And that's why we need graduated
12:24 disclosure so that we can gradually move
12:27 into a situation where we're
12:29 mutually agree. And then we have
12:31 blindable ACDC state registries. Those
12:34 are a little bit a part of bulk issuance
12:36 so I'll talk about those a little bit as
12:37 well. So, that's the full set
12:40 of mechanisms
12:43 and there's a lot. And that's why often
12:45 people look at ACDCs they
12:47 go, "Oh, there's a lot there." Right?
12:50 But if we want to really do it right, we
12:51 have to do all of those things.
12:54 All right. So, let's talk about
12:55 infrastructure.
12:57 Just to remember,
13:00 we have controllers, they have witnesses
13:02 and watchers. That's for KERI. That's
13:05 key to it. ACDCs
13:07 are built on top of KERI. So, when we
13:09 talk about ACDCs, it's another protocol,
13:12 it's another set of infrastructure, it's
13:14 a bunch of new stuff that you have to
13:16 learn about.
13:18 So, we have registrar and observer
13:21 and this is what they look like.
13:23 And then we have
13:25 We can do bulk issuance with the
13:27 registrar and observer if we do it
13:29 right. And we use sparse Merkle
13:32 trees to be able to do that. Sparse
13:34 Merkle trees are technically a type of
13:38 zero-knowledge proofs. We do use
13:40 zero-knowledge proofs. A digital
13:42 signature, a conventional digital
13:44 signature, is technically a type of
13:46 zero-knowledge proof.
13:48 Just nobody calls them that, but if you
13:50 look at the math, a digital signature is
13:52 disclosing that somebody who knew a
13:54 private key and a nonce
13:57 created the signature without disclosing
13:59 either the private key or the nonce.
14:00 It's a zero-knowledge proof. A Merkle
14:02 tree, you can do an inclusion proof or
14:04 an exclusion proof
14:06 of entry in the tree without disclosing
14:09 all of the tree. That's a zero-knowledge
14:10 proof, by the book. Right? So, we take
14:13 advantage of those. We just don't take
14:15 advantage of the ones that have weak
14:17 security because the crypto periods for
14:20 perpetual verifiable
14:23 issuances. But, if the application
14:26 fits an ephemeral application, I have no
14:29 problem with using zero-knowledge proof.
14:31 I use them all the time. I just don't
14:32 call them that because most people don't
14:34 call them that either.
14:36 We also have something called a user
14:38 presentation registry, which is also a
14:40 new thing that nobody else does as far
14:42 as I've never seen anybody do it, which
14:44 allows presenters to detect compromise
14:47 of their proofs that are in their
14:50 credentials that they're
14:52 presenting. So they themselves
14:54 will protect it from fraud, not just the
14:56 issuer. So, what does an issuance
14:59 registrar registry look like? Here's the
15:01 block diagram. You have Let's see, can
15:04 you see my cursor?
15:07 No. No. All right.
15:41 So, we have
15:42 an issuer,
15:44 an issuee,
15:46 and we use that terminology, it's a
15:48 little bit odd because we don't want to
15:50 get confused about a data subject or a
15:52 holder. We're really talking about
15:55 the ACDC is targeted. We have untargeted
15:58 and targeted ACDCs, and if it's targeted,
16:00 then we're issuing it to some entity,
16:02 and that's the issuee.
16:04 The issuee makes a presentation.
16:06 The presentation can either be bare
16:08 signed, which means
16:11 it's ephemeral,
16:13 or it can be anchored, which makes it
16:17 so that they can detect if they've
16:19 been compromised because a verifier will
16:22 have to check to see if the presentation
16:24 is anchored. This is an unanchored
16:26 presentation.
16:27 The issuer
16:30 creates a registry of the state
16:33 of the ACDC, it
16:37 hosted by a service called registrar,
16:39 and then an observer,
16:42 which is controlled by the verifier,
16:44 the registrar is controlled by the
16:46 issuer,
16:48 notice that this models the witness
16:51 watcher governance structure. So, we
16:54 learned a lesson. We shouldn't have
16:56 shared governance.
16:58 So, we have witnesses that are
16:59 controlled by controllers, watchers that
17:01 are controlled by verifiers. We split
17:03 the verification between two places.
17:05 We do the same thing with ACDCs. We have
17:07 registrars controlled by the issuers,
17:10 and observers controlled by the
17:12 verifiers,
17:14 and the ACDC state goes to the observer,
17:17 the observer gets it from the registrar,
17:19 the verifier checks the state against
17:21 the presentation says, "Oh yeah, that
17:23 credential hasn't been revoked." For
17:24 example, if I have dynamic state
17:27 ACDCs. So, that's not a new concept.
17:32 Here's what it looks like from a
17:37 a cryptographic point of view, the data
17:39 point of view. So, what I have is I have
17:42 the Key Event Log of the issuer.
17:44 And I have events in the Key Event Log
17:46 and I just show different types of
17:47 events, incept, interact, rotate. But
17:51 each event in the Key Event Log can have
17:53 it sealed.
17:54 We call these anchoring seals.
17:57 They basically are hashes. They're
17:59 actually technically SAIDs of things I
18:01 want to anchor.
18:03 They are privacy preserving because
18:05 I don't know what the hash is. It's
18:07 a cryptographic hash. I can't infer what
18:10 the hash is of unless I know
18:12 what it is to begin with. But I can
18:14 cryptically verify once it's disclosed
18:16 to me what it is, that it's
18:17 there, right? So, I have a
18:19 cryptographic anchoring of
18:22 a registry. A registry is essentially
18:26 another type of log. We call them a
18:29 Transaction Event Log. It is a hash-
18:31 chained data structure.
18:33 But it's
18:34 managing not key state but ACDC state.
18:38 So, if my ACDC is dynamically revocable,
18:42 I have issued and revoked, are
18:43 the two states. And I have this new
18:45 thing called No Change and that's
18:47 because this is a blinded state TEL.
18:49 So, I can issue events to the
18:52 registry that are blinded. I don't know
18:55 what the state is.
18:57 A third-party observer can't
18:59 correlate the state just by looking at
19:01 the registry.
19:02 Only second parties that I disclose
19:05 to, can figure out what the state is.
19:07 So, a given issuer
19:09 can have a registry
19:12 per ACDC that they issue to manage
19:15 the state.
19:17 So, blinded state registry.
19:19 These are the fields in an ACDC.
19:23 The top-level fields.
19:25 And the S, A, E and R, we call them
19:30 sections because they typically are
19:32 expanding the block of other things.
19:35 But we have attributes, edges, rules. I
19:37 talked about edges. We have schema.
19:39 We have a registry field that points to
19:42 the registry that governs this
19:44 ACDC. ACDCs don't have to have
19:46 registries. If they're issued and
19:49 they expire with time, they're not
19:51 dynamically revocable, they don't need a
19:52 registry. So, the registry field's
19:54 missing.
19:55 Empty.
19:57 I then have in my registry, I have a
20:00 Registry Inception Event,
20:02 which defines governance for the
20:04 registry. So, what is governance? Well,
20:07 it's the issuer AID. It says this
20:10 registry is governed by this AID. And
20:12 then it has a SAID like everything, has a
20:15 serial sequence number, has a date time.
20:18 And then I can issue blinded updates.
20:21 The blinded updates
20:23 have
20:24 a prior
20:26 connection so that
20:28 change age
20:29 sequence number. And then has this BLID,
20:31 which is this blinded ID.
20:33 So, I don't know what the state is if I
20:36 look at the registry. The registry's
20:37 blind to me. Third party looks at it and
20:39 says, "Okay, you got a registry got
20:40 events in it. I don't
20:42 know what ACDC it manages. I don't
20:44 know what it's doing because all of that
20:46 important information is blinded over
20:48 here."
20:51 So, my blinded attribute block is where
20:54 I get that information. So, I have this
20:56 the BLID, I have a UUID, which means the
20:59 BLID is universally unique.
21:01 I call it a salty nonce.
21:04 I have the SAID of the ACDC and then I
21:07 have the state.
21:08 So, the only way I
21:10 can get this is that the presenter,
21:12 the issuee, unblinds it
21:15 for me and gives it to me. And they only
21:17 unblind it after
21:19 for example, if I'm a verifier, I agree
21:22 to the terms if it's contractually
21:24 protected disclosure or after we
21:27 negotiate what it is or what parts that
21:29 you know, that I'm going to
21:31 disclose. And now they can at least
21:33 verify that the ACDC is validly issued,
21:36 but maybe the ACDC used selective
21:38 disclosure to only disclose one field in
21:40 the attribute block. But now I can at
21:42 least look it up and say, "Yeah, it was
21:45 professionally verifiable because
21:48 I can trace it." So, this
21:51 is what it looks like.
21:52 I've got the Key Event Log.
21:55 I've got the events in the registry. So,
21:57 I've got an incept. Incept is vaculous.
22:00 It just creates the registry. Why is
22:03 this useful?
22:05 Well, I don't want the creation of the
22:07 registry to be correlatable.
22:10 So, if I'm the state of Utah and I'm
22:12 issuing birth certificates, and babies are
22:15 born, I create a registry on their
22:17 birthday,
22:20 then I've correlated their birth date to
22:22 the registry creation. That's a
22:23 really bad thing to do. So, I want to be
22:25 able to do is just create registries
22:28 bulk
22:29 that are just placeholders.
22:31 And so, on day one of SEDI, the state of
22:34 Utah will create enough registries for
22:36 all the citizens of the population of
22:38 the state of Utah for the next
22:40 however many years they want to do that.
22:42 And now they're only correlated to the
22:44 date that's went into place.
22:47 Anybody that's born before that date,
22:49 their registry is created on that date.
22:51 Anybody born after that date, their
22:52 registry is created on that date. A lot
22:54 of mechanisms that people build for
22:57 privacy don't actually consider the
22:59 statistical correlatability of the meta
23:02 data that they use when they build their
23:04 systems. And so every time I look at
23:06 something I go is there metadata there?
23:08 Yes, there is. That metadata is
23:10 inherently correlatable. It will defeat
23:12 any mechanisms I use that are
23:14 cryptographic because I just have to pay
23:17 attention and I can correlate it.
23:19 So I have to build into the system
23:22 anti-metadata correlation mechanism. So
23:24 bulk issuance, this is bulk issuance.
23:27 That is a… Sorry.
23:29 Oh, no. I got to go redo that.
23:33 So it's helpful to focus. All right.
23:39 I got to go slower. 1 2
23:40 3
23:41 4. There we go. All right. What else is
23:44 on here?
23:45 Well, I update… See all these updates?
23:49 They just have these BLIDs in them.
23:52 The BLIDs are blinded. I don't know
23:53 what the update is. Look over here. This
23:55 one
23:56 is an update but it doesn't have
23:59 [inaudible]
24:00 update my registry with
24:03 nothing.
24:05 Well, if I wanted to make sure that like
24:07 let's say
24:09 that as the state
24:12 once a day
24:14 I create updates whenever I issue new
24:17 birth certificates.
24:18 Now the update is correlatable to the
24:21 birth certificate. So I want to do is I
24:23 want to have a bunch of registries that
24:25 I just update randomly.
24:27 So that there's no correlatable
24:29 information but the fact that I had an
24:31 update.
24:32 A lot of mechanisms for verifiable
24:34 credential that have revocation
24:36 registries, you look at the metadata
24:38 when the transaction was posted to the
24:40 to the registrar or the verifiable data
24:42 registry, it means you can
24:44 correlate out the information you're
24:46 trying to protect. You don't actually
24:47 have to have anything. You don't have to
24:49 break anything. You just have to pay
24:50 attention. You just have to be a good
24:51 data scientist.
24:53 Since I started my life as an AI
24:55 data scientist, I always think about
24:57 those things first. I'm late comer to
24:59 cryptography. I go, "Well,
25:01 cryptographers don't think about data
25:03 science. They don't know how to… They
25:04 don't really think about statistics.
25:05 They don't know about much of the
25:07 statistical stuff that they use. They
25:08 just know that there's certain things
25:10 that they can get away with." And I'm
25:11 sorry for criticizing cryptographers.
25:16 Anyway,
25:17 so I wanted to do that and I keep
25:20 hitting the wrong one. All right, one
25:21 more time. Sorry about this.
25:25 I guess I could just exit out of the
25:27 animation. All right.
25:32 Here we go. It's on here. All right, so…
25:34 No, this is the wrong… This is No, that
25:36 won't work. That's a different one. All
25:38 right, here we go.
25:40 Go slow.
25:43 It's sensitive. All right, so what
25:45 I have here is the one that's actually
25:48 issued. It's some update.
25:51 And then I can update it with the
25:54 same state,
25:56 but somebody looking at it doesn't know
25:58 what the update means.
26:00 So this example actually came up
26:02 with when I was talking to some people
26:05 a few years ago for Swiss ID, and they
26:08 looked at the existing KERI stuff and
26:10 they said, "Well, yeah, one of the
26:12 problems they have with at the point in
26:13 time pretty much all of the verifiable
26:15 credential systems on the planet is that
26:18 if you know what the state is at any
26:20 point in time,
26:22 and there's only two states,
26:24 and there's an update, then you don't
26:26 have to actually be disclosed the
26:28 update. You can infer, cuz there's only
26:30 two states, that the update changed the
26:32 state and what the current state is.
26:34 So the example is I apply for a job
26:37 someplace, and I'm using a verifiable
26:40 credential
26:41 that's privacy-preserving,
26:43 and I disclose that I'm an employee of
26:46 a company,
26:47 and then they don't hire me,
26:50 but they put me on the list of saying,
26:52 you know,
26:54 we want to keep track cuz we really like
26:55 this guy, but he just won't… Timing
26:57 wasn't quite right, right?
26:58 But, since now they know the registry
27:00 can then
27:02 watch it. And if there's a new state in
27:04 there, and they know that there's only
27:06 two states issued and revoked, guess
27:07 what? They know when I get fired.
27:10 Might be 5 years from now, and then they
27:11 go, "Oh, he got fired. Let's see if he
27:13 wants a job with us."
27:15 So, I need to have my state updates be
27:17 blinded
27:19 so that there's no statistical
27:20 correlatability. Has nothing to do with
27:22 cryptographic correlatability or
27:24 cryptographic linkability. It is I don't
27:26 have any metadata that is statistically
27:28 correlatable. So, that means I have to
27:30 be able to update my state
27:32 with blinded updates
27:34 in a way that it… and the user can
27:37 request this. The user can go back to
27:38 the issuer and say, "Hey, you know what?
27:40 I did three presentations of my state. I
27:42 want you to issue a new one
27:44 so that decorrelates everything that I
27:46 just did." Because now they can't go and
27:48 look and see the latest state cuz the
27:50 latest state is after the one they had,
27:52 so they don't know what the state is.
27:53 They don't know if it went to revoked
27:55 or it went to some other state. They
27:56 just know they don't know it. And then
27:58 when you revoke it,
27:59 you can just keep updating it every
28:02 once in a while, and they go, "Oh, well,
28:03 it may must still be employed
28:05 because his registry is still updating,
28:08 right? He didn't abandon the registry."
28:09 So, it gives you perpetual protection
28:12 from metadata correlation because
28:14 the registry can live forever and
28:16 protect you.
28:17 All right, so… – Is it
28:19 derived from something? – Yes, it's a blo…
28:21 it's an HD
28:24 process. So, what we're trying to do
28:26 is minimize the key management. So, the
28:29 issuer and the issuee exchange a salt.
28:32 And then you use the salt to derive the
28:34 blinding factors.
28:35 So, you don't have to have any
28:36 interactions.
28:38 What happens is the issuee can go
28:41 look at the registry, see
28:43 that there's a new event, and they can
28:45 figure out what it is cuz they know the
28:47 salt.
28:49 And so they can actually try
28:51 all the combinations of state to figure
28:53 out which one it is, without them
28:56 having
28:58 to have any ongoing interaction. So I
29:00 hate interactions. If you ever pay
29:02 attention, I think interactive protocols
29:04 are bad idea. I want non-interactive
29:07 protocols in general. So that's a
29:09 non-interactive way to allow them to do
29:11 it is to use a salt. All right. So
29:13 Shared Blinded State Registry. So
29:16 maybe you say registries are expensive.
29:18 I don't want to have all these
29:19 registries. Well, because the state's
29:21 blinded and the blind includes the
29:24 actual ACDC that the registry's for,
29:26 there's no reason you can't share one
29:28 registry across any number of ACDCs. So
29:31 as an issuer
29:32 I could use one registry for all of the
29:36 credentials I issue. Now, that means
29:38 that the registry might get heavyweight
29:39 over time and I start to get what looks
29:41 like blockchain bloat,
29:43 so I may not want to do that if I'm
29:45 issuing a lot, but I can certainly can
29:48 decide what the granularity I want to
29:51 manage that, right? So that's the
29:53 advantage of a blinded
29:55 state registry.
29:57 Yes.
29:59 – The salt?
30:01 You know, exchange something like a
30:03 symmetric key exchange? – Yes.
30:05 But it's not for security, it's for
30:07 privacy. So KERI says it's okay to use
30:10 shared secrets
30:12 for confidentiality because every
30:15 encrypted thing that you send somebody
30:17 is has to use a shared secret. – Does that
30:19 create a class of algorithm which has
30:22 [inaudible] salt and symmetric salt exchange
30:25 for which
30:26 you know, the cryptography
30:29 community doesn't know what that is.
30:32 – I'm not sure I understand the
30:33 question. – I'm just drawing a parallel
30:36 between symmetric key exchange protocols
30:39 and salt exchange protocols.
30:42 And are they different? – No, it's just a
30:44 secret.
30:45 – How are they secure? Have they been
30:46 looked at by cryptographers?
30:48 – Well, anything that you would exchange
30:49 with Diffie-Hellman is just a secret.
30:52 So, the security of the exchange is
30:55 whatever Diffie-Hellman gives you.
30:56 Diffie-Hellman doesn't care what
30:58 what secret you're exchanging.
30:59 – Hellman is anonymous by design,
31:00 right? – Yeah.
31:02 So, it doesn't care.
31:05 Yeah, so basically you can use… your
31:08 salt can be the shared key that
31:11 the Diffie-Hellman gives you. So, that's
31:13 the easy way to do it. – Okay, I think
31:15 there's a man-in-the-middle attack, but
31:16 I don't know. – Yeah. – Isn't that why
31:18 you designed SPAC, though?
31:20 – Well, no, but yes.
31:23 [laughter]
31:24 SPAC solves a lot of other problems.
31:26 You can certainly do an out-of-band
31:28 salt exchange.
31:30 And the reason you can do that is that
31:31 when you do the identity assurance,
31:34 if you're doing IAL level three identity
31:37 assurance, it has to be an in-person
31:40 thing, and then you can exchange the
31:41 salt then, and it's out-of-band. And
31:43 then you don't have to worry about
31:44 Diffie-Hellman. But that's it.
31:48 Well, it scales for SEDI because you can't get a SEDI credential
31:53 unless you do the IAL at the start.
31:56 And that means you can exchange the
31:57 salt. – That's physical registration
31:59 stuff? – Huh? – Your physical registration?
32:02 – Yeah. Yeah.
32:04 And I'll talk about that. Yes, I have
32:07 a slide on that.
32:08 Right, so let's talk about
32:11 this infrastructure. I have registrars
32:13 with registries. I have observers. All
32:16 our observer is doing is it's keeping
32:18 track of the registry state. So, it's
32:21 asking the registrar, what are
32:24 you registries you have? What state do
32:25 you have? And now it has a local cache
32:27 copy, and then when a verifier wants to
32:30 verify something, he goes to his
32:32 observer and says, "Tell me
32:34 what the state of this ACDC is."
32:38 So for this to work,
32:40 you want to use bulk updates. That means
32:42 you don't update
32:44 instantaneously, you update like say
32:46 once every 24 hours.
32:48 Otherwise, if you update it instantly,
32:50 then the observer
32:52 could correlate
32:54 a change to some registries
32:58 and not others. But if all the
33:00 registries, 100% of them update
33:03 at the same clock time,
33:05 because that's when they
33:07 broadcast the bulk update, then there's
33:10 [synchronization] in the time of update. Every
33:12 time you do anything,
33:14 if you want to make it so that it's not
33:16 statistically correlatable, you have to
33:18 do it in a bulk
33:20 or herd privacy protected way. You can't
33:22 do things one-on-one
33:25 because the act of doing any kind of
33:27 interaction one-on-one leaks
33:30 correlatable metadata and it can't be
33:32 defeated. You will correlate around
33:34 whatever else you're doing because you
33:36 leaked it, right? So even Tor, you can
33:39 correlate around Tor because guess what
33:42 metadata Tor leaks? Anybody know what
33:45 metadata Tor leaks?
33:49 Tor uses variable packet size.
33:52 Right? You get enough of that, you can
33:53 figure out
33:55 Tor. So SPAC, TSP protocol, we
33:59 have
34:00 uniform size packets. So there's
34:03 no… So packet size can't be used for
34:06 correlation and we have no packets that
34:09 are just like vaculous blinded updates,
34:11 so you can whiten your time of arrival,
34:14 time of departure. And that's built into
34:16 the protocol because otherwise,
34:18 you do all of this work to
34:19 cryptographically
34:22 encrypt stuff
34:23 and to try to protect your metadata from
34:26 being correlated and then your protocol
34:29 just leaks it all away. So the
34:33 basic idea is I want registries that bulk
34:36 update the observers.
34:38 The observers can't infer anything
34:41 because it's bulk updated, so you have
34:42 herd privacy.
34:44 What is the weakness here? The weakness
34:46 here is that if an observer is malicious
34:49 and the issuer is malicious,
34:51 they can collude
34:53 and the observer can say, "Did you issue
34:55 this? Did you change the state of this
34:57 particular
34:59 point?" Right? So, you
35:02 depend on repressing observers and
35:05 issuers from correlating, but there's no
35:07 phone home here.
35:09 The issuer can't force an observer
35:13 because there's no phone home.
35:16 Because all it needs is the
35:17 information in the registry to do the
35:19 verification. So, there's no
35:22 built-in mechanism for the observer to
35:24 trace anything in the system. It
35:25 requires criminals
35:27 to get together and form a criminal
35:30 thing, and as long as you make it
35:32 sufficiently legal, it might happen
35:34 sometimes.
35:36 But then you are in the boat of,
35:39 "Well, you've got fraud in the system."
35:41 And guess what? You can
35:43 catch them because
35:45 because they're
35:48 colluding against the law and
35:52 and you have repression. But
35:54 yes, it doesn't make it
35:56 impossible. Right? There's no technical
35:59 thing that makes it impossible in
36:01 this, but what it does is it means that
36:04 there's no easy way for them to do it.
36:08 So, the first step in SEDI is an
36:11 identity assurance process. What is
36:13 identity assurance?
36:15 Identity assurance solves one problem.
36:18 It's called the cheap pseudonymity
36:20 problem.
36:22 Anybody can create
36:24 a pseudonym, a cryptographic pseudonym,
36:27 and prove control of creating an AID,
36:29 right?
36:30 And as soon as they use the AID for
36:32 something and they did it for bad and
36:34 they say I'll just abandon and create a
36:36 new one.
36:37 Right? So, nobody can trust an AID that
36:39 anybody can create. Decentralized
36:41 identity has a big problem. The problem is
36:45 anybody can create as many AIDs
36:47 as they want and then abandon them
36:49 whenever they want to. So, nobody can
36:50 trust them, right? So, they're only good
36:53 ephemerally. If I want them good for
36:55 long-term, they need to have a
36:56 reputation that says there's a reason
36:58 why you can trust this.
37:00 So, what GLEIF does is
37:02 provide with