0:00 Okay, so this is a really long title. What I wanted to do is I wanted to take
0:06 something that's happening in the SEDI world and relate it to what has now become
0:11 people call it AI anxiety, right? In fact, I had my daughter send me a text and say,
0:18 so when the world ends because of AI, what should be our emergency plan? And then
0:25 they live a couple miles away and it says, how do we communicate? How do we get food?
0:30 What do we do? You know, and I'm fully off griddable
0:35 because I have solar panels and batteries and stuff like that. And I have a swimming
0:39 pool. So I have, you know, years worth of water and a bunch of stuff. So I just
0:43 said, no, you know, just get from your house to my house and you're good. Right?
0:47 So you got two miles, you know, you got to fight off the zombies for those two miles,
0:52 but otherwise you're good. But it was just because of all the AI anxiety. So this is
0:57 a little bit to address that problem. So what is the AI surveillance problem? Well,
1:02 people have been using this term and it's now gotten to be a bad word called
1:06 continuous identity. What is continuous identity? Well, it means that I determine
1:12 who you are by continuously surveilling everything that you do. And if I
1:17 continuously surveil everything you do, I can build a persona of your behavior that
1:24 an AI can't deep fake or can't deepfake today, but might deepfake tomorrow, which
1:32 means the level of surveillance has to get more pervasive. So the assumptions always
1:39 is there are things that I can permit somebody to know about me that an external
1:45 AI attacker can't get to yet. So as long as it can get to stuff that they can't,
1:52 then it can build a higher fidelity surveillance model than the AI can. And so
1:57 the AI can't deep fake me. Like, does the AI know my weight? Right? Well, it knows
2:03 my image because my image is everywhere. Right? But does it know my weight? Well,
2:07 if I have a monitor in my bathroom scale that's measuring my weight every day and
2:13 that monitor is air-gapped, then I could build a model of me that had my weight
2:23 data that the AI can't fake. Right? So, I have to securely present that data and
2:29 then they go, oh, okay, well, you know, that's within the range of what we've been
2:32 measuring over the last year for your weight. So we'll trust you. That's the
2:36 example of what you have to do to make continuous identity work is that you have
2:41 to be able to surveil stuff that the attacker AI can't surveil, at least for
2:47 now. And then you can build a better persona than your wallet or whatever it is
2:53 that you're authenticating against or whatever host that you've allowed to
2:58 surveil you presents on your behalf, right? So does this scare anybody? Is
3:03 anybody worried about this? Okay. All right. So another term they use, which is
3:06 a little friendlier term, behavioral biometrics. It's just another type of
3:10 biometric. It means we know everything about you and that is your biometric,
3:14 right? It's a behavioral biometric because it has nothing to do with your DNA or your
3:19 skin or your fingerprints. It has to do with everything else about you besides
3:22 those, right? Another friendlier term, participatory identity. You participate in
3:30 your identity by letting your identity provider know everything about you. Isn't
3:35 that fun? Persona-based authentication, right? That's the more technical term.
3:41 It's essentially authentication via statistical correlation. You basically use
3:46 all of data science to statistical correlate more about you than the attacker
3:51 can correlate, right? If you think about what authentication factors are. Things
3:55 you know, things you have, things you are, right? They're just data points that you
4:00 can present that the attacker can't present, right? But since all of the
4:06 standard authenticators have been very easily hacked recently, right? Then it's
4:11 like, well, how do we make authenticators that are harder to hack? And if you're a
4:16 company that lives on correlation, what your natural thing is, well, wait, if we
4:23 could just surveil everything about you, we can build a really high fidelity
4:26 persona that the attackers don't know as much as. And guess what? You can't do
4:31 anything or go anywhere unless you share everything about you with us because the
4:36 way you authenticate is to ask us to present this persona that we've generated
4:41 from surveilling you. Does that feel like a world you'd like to live
4:46 in? But you understand that that is the world we're in right now. You
4:51 go look online and you security companies look at the biggest billion dollar
4:55 security companies and guess what their new products are? Continuous identity,
5:00 behavioral biometrics. That's what they're selling. Everybody you want to go to this
5:04 is well, you know what? The AI can can fish everything. They can attack
5:09 everything. So what we need to do is have a counter AI that fights against it. And
5:15 what does the counter AI use? Well, what do AI's use? Correlation, right? That's
5:21 how they work. An LLM is just a correlation machine. So you build a model
5:26 that correlates you better than the deep fake can correlate you. That's all it is.
5:31 And so guess what that turns into? The more pervasive surveillance, the higher
5:36 the fidelity of the model, the more likely it will distinguish a real person from a
5:40 fake. But that just means you've created an arms race of surveillance. You've
5:45 basically given yourself a way to just being surveilled to guess what's going to
5:49 happen. You know, you're going to start having monitors in your body monitoring
5:54 things that are essentially you know somebody in North Korea can't monitor
5:59 because they have to they attack but in order for it to be useful you have to un
6:05 -air gap your body right in order that the AI that is creating your model so you're
6:09 actually weakening your ability to protect yourself because you're un-air gapping
6:15 everything about you right and so it just becomes an arms race the more they know
6:20 the more your AI needs to know. And guess what? Any breach of your
6:27 AI immediate makes the attacking AI that much smarter. So guess what? You have to
6:33 be even more pervasive in order to have a delta. So it never ends. You just become
6:40 perfectly surveilled. And once you're perfectly surveilled, there's nothing
6:46 left. And then nobody has any security. So the end state is zero security. The end
6:54 state, but somebody will make billions of dollars or trillions of dollars in the
6:57 process. So… – I thought there were just more and more turtles. – No, no. At the
7:03 bottom, there's an egg.
7:07 There's an egg and once that egg's cracked, no more turtles. All right. So
7:12 the solution cannot, must not be more surveillance, but that's what the world is
7:18 telling us. The only answer to AI cyber attack is AI defender and it's an
7:25 arms race of surveillance because they're just surveilling yourself. So here's
7:31 some facts that we can use to fight back. Strong crypto is not vulnerable to
7:37 brute force attack. It is computationally infeasible. It doesn't matter how big the
7:41 AI is. It doesn't matter how many servers there is. Strong crypto is designed so
7:46 that a trillion servers operating for a trillion years can't break it. Does that
7:51 make sense? So that's what computational feasible means and AI
7:55 doesn't have any advantage in that world. All of the atoms in the solar system would
8:02 have to be computing machines before you'd start to reach that level of 120 bits of
8:08 cryptographic strength. So how does AI work when it attacks? It's not brute
8:16 forcing any of the crypto. That's not none of those attacks are brute forcing the crypto.
8:20 Every once in a while somebody will publish a thing that says, oh, AI cyber
8:25 defeated some crypto algorithm. And then you go read the fine print and no, no, it
8:29 was a side channel attack. They didn't actually brute force anything. They didn't
8:33 invent a new attack. They just figured out a better side channel attack. Right? What
8:37 is a side channel attack? Everybody familiar with the term? Do I
8:41 need to find that? It's any other attack besides brute force essentially. So
8:46 phishing is a side channel attack. If they phish your secret, that's a side
8:50 channel attack. If there's a bug in the software running on your phone that allows
8:57 them to get access to your private key, that's a side channel attack. They didn't
9:01 brute force the public key to get to the private key. They just found the private
9:05 key because you had bad software. – The policy engine emits its own credentials. –
9:09 Yes, something like that, right? Or an IT person walks out of the building with the
9:17 secrets and you know, shares on the internet, right? Those are side channel
9:22 attacks. Or for example, there was a recent crypto wallet that had multisig. By
9:28 the way, multisig has never been successfully attacked other than through
9:34 code supply chain attacks or bugs in the wallet. So if you eliminate wallets that
9:40 have bad bugs, attacks that can successfully do like a three of five where
9:47 they have to get compromised three keys, you know, or even a two of three. They
9:52 don't, there are no published examples where they're successful to do that other
9:55 than a code supply chain attack. So a recent crypto wallet and exchange had a
10:01 successful attack and here's the attack. The three people that had the keys, it was
10:06 a two of three, right? Got an email that said, Hey, there's a bug in your wallet.
10:12 Click on this link and upgrade your wallet to the new one that fixes the bug. All
10:16 three of them clicked on the link. And what did the link do? It downloaded a
10:21 wallet that exposed their private keys. Okay. So it wasn't an attack on the
10:30 strength of the crypto or a strength on the multisig. It was an attack on the
10:34 strength of the gray matter between the ears of the holders of the keys. Right?
10:40 That's a side channel attack. So if it comes in here and comes out here, it's a
10:44 side channel attack. Right? All right. Okay. So what's the solution? Well, if I
10:51 have key management that detects and can recover from successful site channel
10:56 sites, because guess what? People will be tricked. You can trick people. You can
11:03 cause them to do things, right? Even experts in moments of weakness, in moments
11:09 of stress can be tricked into doing bad stuff. I can count probably half a dozen
11:17 times were in a moment of stress or worry or hurry or something like that, that I've
11:24 accidentally clicked on a link without thinking about it and almost compromised
11:30 did something. And then I go, wait a minute, that's not right, right? And
11:35 caught myself. And there's been a couple of times where I've lost like a couple
11:39 hundred bucks or something because I did something stupid, right? It's not hard to
11:44 trick people into being attackable with side channel attacks. So if you want to
11:53 actually protect it from AIs, you have to allow the fact that the AI is going to be
11:58 successful in side channel attacks. What you want to be able to do is detect those
12:04 and be able to recover from them to limit the damage or limit the blast radius or
12:08 limit the extent of the attack so that the damage is minimized, right? Right?
12:16 Well, if I have multiple complementary threshold structures that have combined
12:25 with the detection and recovery from side -channel attack, then I can make a system
12:30 that is practically unassailable from AI cyber. That's a very strong claim, but I
12:36 will back it up. Right? So there is an answer and it's not continuous
12:41 surveillance. It is just key management. If we do key management well, AI cyber
12:47 can't attack us, can't attack you, can't attack anybody. There is a solution and it
12:53 isn't spending more money on correlation machines and super aggregators who want
12:58 your money and your services and all of your data. And they will say, well, give
13:02 me all your data and then you will be secure. But I'll know everything about you
13:06 and I will sell you to the highest bidder. So what does that look like? Wait, wait.
13:16 Oh, that's just sorry. I forgot to delete that slide. That's a duplicate slide.
13:22 Okay. Threshold structure. Okay. What is a threshold structure? I use that term. A
13:27 threshold structure multiplies the number of attack surfaces that must be
13:31 simultaneously compromised for a successful attack. So if you think about
13:35 normal armor, right? It doesn't have threshold structures. It has a helmet. If
13:40 I breach the helmet, you're dead. It has a breastplate. If I breach the breastplate,
13:44 you're dead. Okay? That's not a threshold structure. A threshold structure would be
13:48 a shield and a breastplate. I have to pierce if the arrow comes through the
13:53 shield, it has to pierce the shield and pierce the breastplate at the same time.
13:57 If it's over here and the arrow comes in that direction, it goes through the
14:01 shield, I'm not going to do this, right? I'm going to go, oh, wait, there's an
14:05 arrow in my shield. I guess I need to break it off before I use it, put the
14:10 shield in front of my breastplate. You see the difference? In other words, the arrow
14:14 has to go through two in order to kill me. It can't just go through one. Right? So an
14:20 example of threshold structures. Okay, I'll get to examples. A fault-tolerant
14:26 system. So when I use the term fault -tolerant, detects and recovers from a
14:31 partially successful attack, therefore reverting the attack progress. So let's
14:36 say that they shoot an arrow at me. It goes through my shield. Right? But my
14:41 shield is out here. So I got this arrow sticking out of my shield, right? It
14:45 didn't happen to go through my arm. That would have been bad, right? But it went
14:48 through the shield. If I break the arrow off, pull it out of my shield, I reverted
14:52 the attack progress. The only thing now is I have a hole in my shield. So if they can
14:56 put an arrow through the same hole, then I got a problem because it'll probably come
15:00 right through and hit me, right? But otherwise, they have to start the attack
15:04 over again, right? Because they have to go through both the shield and my breastplate
15:08 to kill me. And so as long as I can nullify the first attack before the second
15:12 attack is successful, then they have to start over, right? That's the whole idea
15:17 is that you reset their effort to attack. So it's like, okay, we got 90% of the way,
15:23 but we failed. Now we have to start from zero and go all the way again every time
15:28 that it's detected and recovered from. So what you have with a fault-tolerant system
15:34 is potentially a perpetually secure system. It's never breached ever because
15:40 the cost of a breach breach is too high for them ever to fully succeed in a
15:46 breach. And that's the only type of security system that is going to be AI
15:50 resilient. It has to be perpetually secure. That means it has to be fault
15:53 tolerant. In general, security systems are not fault tolerant. They don't detect and
15:57 recover from attacks. They don't even detect attacks. Usually the attacker says,
16:02 Hey, by the way, six months ago, we breached your system. We exfiltrated all
16:06 your data. We've now gotten all the value out of it. We just wanted to let the world
16:10 know that we breached you so that we can get higher ransom next time because our
16:15 reputation goes up. That's how most breaches are discovered. They're not
16:18 discovered by the people that are breached. They're discovered because the
16:21 people breaching them tell them that they were breached. The average time to detect
16:25 a breach is six months. The average time to contain a breach is two months or three
16:32 months. So you have nine months of time where the attacker can benefit from the
16:37 breach. That's not a good thing to have. And that's why people can legitimately
16:41 say, well, the only solution is continuous identity because we have to do something
16:47 about that. So an allowable fault is a side channel attack on signing keys. In
16:53 KERI, we say side channel attacks on signing keys are allowable. Our system is
16:59 fault tolerant to those faults. We can detect and recover those faults. Loss of
17:06 control over the identifier is the system failure which is not allowed. If they gain
17:10 control, of your identifier, then we call that a failure. You have to start over. So
17:16 we want to make that really, really hard.
17:22 And if we can do that, then we can minimize the damage. So how do we do that?
17:28 We do that with threshold structures. So what are the threshold structures? Well,
17:31 we talk about this a lot. Signing keys and pre-rotated rotation keys. That is a
17:36 threshold structure. It's like the shield, my signing keys, my breastplate, my
17:40 rotation keys. They don't get control of me. They don't kill me until they breach
17:45 both of them at the same time. They breach my signing keys. Great. I can throw the
17:50 shield away, get a new shield. Throw the shield away, get a new shield. Every time
17:54 they have to start over, right? They never get to the breastplate. So why won't they
17:58 just attack the breastplate? Well, I can protect my rotation keys much better
18:07 because I don't care about friction, right? If I'm signing stuff all the time,
18:12 friction matters. It's not usable to the user if it's too hard to sign. If I said
18:17 to you in order for you to sign to log in to your account at your bank, you have to
18:23 go to the bank, go to a safe deposit box, pull out your safe deposit box. Inside
18:33 your safe deposit box is a sub-safe with some keys on it. it, take that home, open
18:42 it up, find your login and then log in to get to your bank. Okay. That's too much
18:48 friction. But it would be a hard for an attacker to attack that. Well, yeah,
18:54 because one it's air-gapped. Two, they have to be physically present. They have
18:59 to impersonate you physically. They have to go to your bank. They have to be able
19:02 to get into your safe deposit box all before they can log in. So is that really,
19:08 really, really, really secure for almost all the attacks on your identity? Well,
19:13 unless you're a really, really high value individual, that's probably more friction
19:17 than any attacker ever wants to execute. Right? Some attacker in North Korea or
19:22 China is not going to come to your bank. Right? Unless you're worth a lot of money
19:27 and then they won't come to your bank, they'll hire somebody to come to your
19:29 bank. Right? But it still requires somebody to come to your bank. And that
19:33 means that somebody, when they fraudulently impersonate, you could get
19:37 arrested and go to prison. Right? So the cost the attacker is potentially to be
19:42 imprisoned. How many hackers want to be in prison? Why are most hackers in foreign
19:49 countries on the internet? Because they're not liable to be imprisoned because
19:54 they're not in the jurisdiction of the place where they're attacking. So I can
19:58 make the pre-rotated keys as secure as I need to because the friction of recovery
20:05 only occurs if they're a successful side channel attack. So there's a differential
20:11 that allows me to make it so the overall security is really, really, really secure
20:18 and still have low enough friction that it's practical to use the system. Okay,
20:23 multisig signing keys. I already mentioned the multisig is really hard to do. Well, I
20:27 can have two of three. Now they can they can phish one set of keys, but they got to
20:33 phish another set in order to get to me. And if they try to use the one set, Well,
20:39 if my system's designed right, it might be detectable that they're trying to use one.
20:44 I know that one set of keys has been compromised. I can do multi-sig for my
20:50 rotation keys. So I can have single-sig signing keys for low friction, but I can
20:55 have multi-sig rotation keys when I need to recover. So now they can say, well,
21:00 yeah, okay, we know that you have a rotation key here. Oh, but you have two or
21:06 three rotation keys and the other rotation keys over there. So now we got to attack
21:09 two different places. The return on our investment isn't good enough there. Delegated
21:16 AIDs. A lot of people don't understand that. A delegated AID is a threshold
21:20 structure. If I have a three-layer hierarchy, each layer is a threshold
21:27 structure for the lower layer because I can compromise the lower layer, but if
21:31 they don't compromise the layer above, the layer above can recover the layer below.
21:36 And if I compromise two layers, the top layer can recover both layers below. So
21:42 they have to compromise all three layers at the same time. If they only compromise
21:47 one layer, it's detectable recoverable. They have to start over every time. Now,
21:52 if you're an attacker and you go, okay, I'm going to spend all this time and
21:54 efforts. I'm going to compromise one key. And then as soon as I try to benefit from
22:00 that compromise, it becomes detectable. And then they're going to rotate me away.
22:04 They're like, crap, I've got like literally a day at most, not nine months,
22:10 a day, maybe an hour where I compromise a key I can do something with. And as soon
22:14 as I do anything with it, they're going to detect it like the minute, the second I do
22:19 something with it, like seconds, network propagation time, they'll detect it. And
22:23 then it's however long it takes for them to figure out to recover from it. So then
22:27 they're looking at, well, wow, you know, we can't, you know, it's like the
22:31 attackers that compromise Google in 2025. You guys all know this, right? That every
22:36 Google email account at Google was compromised in 2025. All five billion of
22:41 them. So everybody that has a name, an address, a phone number, and any other
22:47 data, they didn't compromise your password, but they compromised the account
22:53 data. So now they know who you are. They know whatever information else that Google
22:59 has. And so they can try to phish you, try to impersonate you, whatever. But all five
23:04 billion of those were compromised and they had several months to do it and Google
23:08 didn't know that it was happening and then it got detected after all the data had
23:13 been exfiltrated. Okay, so that's the problem that AIs make all of those attacks
23:18 cheap, but they don't make attacks that are threshold structures where you
23:23 differentially protect things that are hard for them to get to. They don't make
23:26 those cheap. Witness pools. If I have a witness pool that say a three or four in
23:34 order for an event to get witnessed, I have to compromise three witness keys. So
23:42 that's a threshold structure. So what's the final one? The watcher network, right?
23:51 In order to not be detected, but duplicity, they have to compromise every
23:57 possible watcher that a verifier would talk to. And they don't know which
24:02 watchers verifiers are using. So it's a really hard compromise. But let's look,
24:06 let's say that I have a two of three signing key, a two of three rotation key.
24:11 I'm using a two layer delegation and a three of four witness pool. How many
24:19 simultaneous side channel attacks do they have to execute to be able to compromise
24:27 me? Huh? Like 10? Do you know how often anybody's ever been able to simultaneously
24:35 compromise 10 keys? Ever? In the history of the world? I don't know of any. It's
24:42 really hard to do. Compromising private keys is really hard to do, but it's not
24:47 impossible. And we just made it practically infeasible by nesting
24:53 threshold structures, which means you actually can have security without
24:58 continuous surveillance if you use KERI. And so, perpetually secure. KERI allows…
25:04 So, we've talked about perpetual identity, perpetual verifiability. You get perpetual
25:08 security because you can control your identifier even against cyber AI. So, give
25:14 an example from SEDI. This is a draft proposed example for what the SEDI
25:22 identity structure looks like for the state of Utah. So, what we have here is
25:28 the state of Utah has a root ID. It issues an organizational unit delegation
25:34 credential that delegates a unit AID that issues an issuing agent delegation
25:40 credential which delegates an agent AID. This is the issuing agent that issues SEDI
25:45 credentials. So it's in some ways similar to GLEIS. Yeah. So this would be the this
25:54 would be the QVI. Yeah. So the agent would be the person the the so this so
26:00 organization's unit would be like driver's license division or the health and human
26:09 services, whoever it is, right? Issuing agent could be an employee in the driver's
26:14 license division. It could be an identity proofer like id.me or whoever they want to
26:21 proxy that role out to. And they have an agent AID. So they're going to issue a
26:27 core identity credential to a citizen AID. Now the citizen person creates that AID.
26:34 The state doesn't. If they don't want any of these, they just don't go to the state
26:39 and say, give me these credentials. They just use paper. Okay. One of the things
26:44 that people don't understand is that if you don't allow people to opt out of
26:49 digital identity, then there will be whole swaths of the electorate that will go out
26:56 of their way to make sure your bill doesn't get passed. So one of the things
27:00 that make it so that SEDI was passed unanimously to everybody that said, no,
27:05 no, no. You create this identifier. We don't create it for you. If you don't
27:10 create it, there's you have there is no digital ID for you. You have to use paper.
27:17 If you decide not to create it, there is no there is no identifier. There is no way
27:22 for the state to issue you digital stuff. You just go paper, right? And they go, oh,
27:28 okay. Well, I guess that I guess we can't complain now, right? And so like, really?
27:34 Is that's it? That's it? There isn't some subterfuge that you're doing that you
27:39 didn't? No, no. It's state endorsed digital identity, citizen sourced, right?
27:46 Citizen creates the identity. The state just says, I'm going to apply reputation
27:49 to it, right? So, this core identity is issued to the citizen AID. And then we
27:55 have three other credentials. We have a proof of residence, we have a proof of
27:59 age, and we have a high resolution image because in some cases your biometric, the
28:05 biometric using the core identity is a facial image and that's because state law
28:10 requires it. And in some cases you need a high-res image. So that's the basic idea.
28:14 So to attack this system, they got to attack a two-layer delegation. The citizen
28:21 can decide how secure they want their own AID to be. Do they want single SIG
28:25 everywhere? For most people, that's probably secure enough because they at
28:30 least have one threshold structure. They have signing keys and rotation keys,
28:34 right? They all have to have witnesses. So they've got a second threshold structure.
28:38 So now they have to attack really hard to make it so you can't detect that your keys
28:45 have been compromised when you're using your credential. So that's a simple
28:49 structure that gives the citizen AID and then they can just add other entitlements.
28:54 We call these entitlements. These are the core ones and then you can throw in like
28:59 your like if you're on food stamps, you know, whatever, you want a driver's
29:06 license, you want a hunting license, you want a food handler's permit, all of those
29:10 things just become more things in this list of things that are issued, right? And
29:17 we're using edges. These green binds, those are edges in the ACDCs. And edges
29:28 are a normative feature of ACDCs. We spent years figuring out how to use edges
29:33 correctly. The edges make it so that the relationships are just as secure as
29:38 everything else. And so an attacker can't forge relationships. So that's another
29:44 threshold structure. If I have multiple edges that are cryptographically bound
29:50 together and each edge is anchored in a different KEL in order for an attacker to
29:57 recreate an edge structure they have to compromise multiple KELs. And if the state
30:04 of these ACDCs is in a registry that's anchored in KELs, then for them to
30:08 recreate this structure, they have to compromise multiple registries and
30:13 multiple KELs. Those are all threshold structures. So if I went back, I should
30:18 have added registries and edges as threshold structures, right? So how many
30:26 threshold structures do you have to break before you can break this identity. It's
30:31 now like 20 keys. I don't know. It's a big number. It's an unassailable big number
30:39 because the likelihood of compromising one private key is really, really low. And now
30:44 I've got to do it 20 times simultaneously, not 20 times in sequence, but
30:49 simultaneously. It's a different set of it. So as you're multiplying the
30:52 probability. So if I got 0.001 times 0.001 to the 20th, how small a number is that?
30:58 Yes. Yes.
31:02 I'm probably missing something, but you said each edge has a different KEL. I
31:08 mean, I know that the citizen AID has a KEL, agent AID has a KEL, and all of those
31:12 edges are products of those two things, right? Yeah. So, but this ACDC, its edge,
31:21 this ACDC's identifier is a hash of the ACDC, which includes the edge, right? So
31:29 when you hash that identifier in order for you to fraudulently issue that credential
31:34 that has this edge, you have a registry that's anchored in the KEL that you have
31:42 to then you have to fraudulently change the registration that is bound to the set
31:51 of this ACDC in order for you to forge the ACDC. So you have to compromise the
31:57 registry. not just the ACDC. Okay. Got it. Does that make sense? Yeah. Now, if they
32:03 weren't registered ACDCs, then that wouldn't be true. But all of the ones in
32:06 this state one are all in registries and the registries are all anchored in KELs.
32:11 And all the edges are bound to the SEDs of the ACDC and that SED is anchored in a
32:17 registry which is bound to a KEL. So it's doubly bound. It's bound in the issuers,
32:25 you know, well, no, it's not doubly bounded. It's issued. It's turtles all the
32:28 way down. It's turtles all the way down. Yeah, in this case it truly is turtles all
32:31 the way down.
32:35 So now let's go to guardianship. So this is the guardianship thing. Now I know this
32:40 looks really complicated, but under the hood, it's no more complicated than
32:44 guardianship really is. Okay. So we have the same delegation chain, but now this
32:49 agent AID is issuing a guardianship delegation, right? So this is a
32:55 guardianship delegation, which is a citizen that designates the citizen ward
32:59 AID, but it's delegating to a citizen guardian AID the rights to be a guardian.
33:06 And now this AID, which is not part of the state hierarchy, but it's part of the
33:10 hierarchy to get this social media access authorization. So the social media access
33:16 authorization is protected in this delegation chain that the ward can now
33:23 present to gain access. So you have the same structure and then you have for the
33:31 citizen ward, this is the citizen ward's AID and his core identity and stuff like
33:37 that. It's all nested down here. But now you've introduced the guardian. You have
33:41 additional edges in here that bind it all together. So all of the cryptographic
33:47 verification across the edges and the edges are anchored in registries because
33:51 you're putting these things in registries to register the state. All add security
33:55 that an attacker has has to compromise multiple things at the same time to be
33:59 able to forge the forge this this these set of relationships. And if the
34:04 relationships aren't normative, then you have no guarantee that the security
34:10 properties apply. You're just dependent on somebody's bespoke software to make it
34:16 happen. But in ACDC land, those edges are normative parts of the ACDC that operate
34:23 in secure ways. They're essentially, this is essentially is a Merkle tree. People
34:29 don't understand. This is describing a type of Merkle tree. We call it a it's not
34:34 a tree because you can have edges can be mary, but it's an mary Merkle tree if that
34:40 makes any sense. Where the branching can be as many branches at each layer of the
34:45 tree, but you basically have a hash tree. And so you have to so if you forge any
34:51 hash, it would break the tree because the root hash would be different, right? So
34:56 you got this root hash up here for this credential, you know, well actually it's
35:02 the root would be is this one. The bottom credential is the root because it goes
35:05 backwards. The edges point backwards. So to forge this one, you have to forge those
35:11 and to forge this one, you have to forge all the ones there for it to be valid. So
35:16 it's a very secure, very hard to attack data structure. Yes. Sam, this might be a
35:22 detail, but that core identity credential, that's the first one that you got on the
35:28 other slide? Yes. That one right there. Is that the birth certificate or? No. Okay.
35:34 Where does the birth certificate come in? It would be another credential. Okay. But
35:37 it has to come before the PIPOR identity. The SEDI legislation only authorized
35:42 these. Okay. So that was going to require additional either legislation or what they
35:49 call it rules from the agency. Okay. So the the rendering that was on the slide
35:57 before is for an existing person who already exists, not somebody who was just
36:01 born. There will be more legislation. Yes, there will be more legislation and
36:06 rulemaking that happens. There will be lots of rules. There will be lots of
36:09 rules. But the legislation in 2026 only authorized two things guardianship and the
36:17 other one. And you don't need the other stuff to do guardianship. Guardianship was
36:23 the driving factor. They passed a law in 2023. for social media access with no idea
36:28 how to implement it. And then, you know, there's some people in the room in 2023 in
36:34 like January, I think Timothy and I went and talked to people at the state of Utah
36:38 and said, well, you can do it with KERI, right? And, you know, and it's like, oh,
36:43 okay, how do we do that? Right? And so it took took a while to get there. – So Sam,
36:48 a related topic. – Oh, microphone. A related topic just of interest to people
36:56 is this whole idea of guardianship is that this is a great technical structure, but
37:03 the real problem is that there is actually no database anywhere that says who is
37:08 whose guardian. That's right. It's all in court documents. Yes. If you're lucky,
37:13 they might be PDFs. Yes. And this would protect children better than the court
37:20 documents. Because this one doesn't show two guardians, but most children have two
37:27 guardians. And so the guardianship relationship, the state could revoke one
37:34 of the guardians based on a court proceeding that then doesn't allow the
37:41 revoked guardian any opportunity to pretend to be a current guardian. So if
37:47 they show up at the school and say, hey, I want to check the kid out of school, they
37:50 can check check that they're no longer a guardian instantaneously and say, no, no,
37:55 you're not guardian anymore. You can't check the kid out of school. So, so it's,
37:59 it really helps protection. Yeah. You had a question. Yeah. So, um, back when I was
38:05 first learning about all this, the legislation does not define the technology
38:10 that will be used. It's the guardrails, right? Um, so I'm wondering now, this was
38:15 your proposal to them. Has Utah in one department or whatever said yes, we're
38:21 going to use KERI or is it still fighting against other technologies? Okay. So in
38:28 multiple meetings, they have effectively said that, but they haven't officially
38:34 said that publicly for political reasons. But the, but when you come to the SEDI
38:39 summit, if you come to the SEDI summit in two weeks, then they, then they are going
38:43 to say that. That's the plan. Okay. So, so I have to be careful because it's very
38:50 political. So, okay. So, I've got 20 minutes. So, I think I'm going to skip
38:57 through some slides here because I think I want to get to… –
39:06 You need to AI delegation? – Huh? – Are you going to show that same slide that you
39:11 just had in the form of AI delegation? – Well, yes.
39:19 So, So, all
39:23 right.
39:31 Okay. So I'll show this slide because that's a good thing. Okay. So agentic
39:38 control is no different than everything that we've done. Everything that KERI has
39:44 been doing for the last six years with delegation maps perfectly to agentic
39:52 control. There's no change. The only difference would be that you might have an
39:57 attribute in the delegating instrument, the ACDC that says the AID of that I'm
40:06 delegating to is an agent instead of a person. That's the only thing that
40:11 changes. The security, the properties like from my talk this morning about authored
40:17 authentication, authentication, authorization, and authoritariveness all
40:26 applies without any changes. We've already solved the agentic control problem from
40:31 the standpoint of the secure infrastructure that you need to do it. You
40:35 just take what's already in KERI and ACDC and just have the AID belong to an agent
40:41 instead of a person. There's fundamentally no difference in how it works. So it's a
40:48 solved problem already. It's just a matter of talking about it in different ways. So
40:54 an agent is a verifiable authorized delegate of a natural person or legal
40:58 entity. Agent could be a natural person or legal entity or agent could be a piece of
41:04 software or it could be an IoT device or it can be an AI harness. It doesn't matter
41:11 from the standpoint of the tooling. It's the same. An agent has its own AID. this
41:20 is the original meaning of the word agent. I mean, when they call AI agents agents,
41:24 you're not doing anything other than saying, well, agent is something that you
41:28 delegate to, right? It's just that right now the delegation is broken. There's no
41:33 accountability of AI agents because it's a prompt. And you say, well, do this for me.
41:42 And it's like it goes and does it and then like nobody checked that it was doing it
41:47 for you. They just say, well, some agent showed up and did this. Right? So people
41:52 are now trying to put in delegation to solve this problem. We've been we've
41:57 already built the infrastructure for that over the last six years. So that's really
42:03 all amounts to. So the details are how do you do the specifics of the authorization?
42:09 That's still something you have to work out. Like are you using MCP? You know,
42:13 what are the APIs look like? What are the details? Are you are you bridging from
42:18 KERI ACDC land to OIDC, OAuth land, right? Those are all valid bridging points. Those
42:26 are valid things that require work. But the core property that gives you the
42:33 security that makes your system impervious to AI attack is not that. It's what we've
42:40 already talked about. That you have this identity, this AID that is protected via
42:48 key management that is fault tolerant with multiple threshold structures that an AI
42:53 can't attack. So you can always securely attribute who the accountable party is.
43:00 The agent isn't the accountable party. The agent has no legal standing. The person or
43:07 legal entity that authorized that agent is the accountable party and we can make that
43:12 securely attributable and bound in a way that an attacker can't forge. And so
43:17 that's the problem. Everything else is just in the just details. It's just it's
43:23 execution details. It isn't solving any hard problems. The hard problem is a
43:27 solved problem.
43:31 So edges are how you authorize access to resources in an ACDC, right? You can use
43:43 those edges to bind resources to access. with. And that edge is part of a
43:50 cryptographic verifiable data structure which is a graph of ACDCs. It is a graph
43:55 of ACDCs is a M-ary Merkle tree in construction. That's what it looks like.
44:01 So if I change any node in the tree, it changes the root. So it's detectable. So
44:06 any attempt to attack it is detectable. It's not just an integrity graph. It's an
44:13 integrity authenticity graph because every entry in that graph is not just hashed,
44:19 but it's signed and anchored in a KEL. So it's bound to key state. So it is secure
44:26 in a way that no other system secures it because people don't hash and sign and
44:32 anchor except in the blockchain world. But nobody uses blockchain anymore because of
44:38 the ledger wars. So we have all the good properties of blockchain and none of the
44:43 bad properties. That's what KERI ACDC is, well, you know, there's a lot of good
44:49 stuff on blockchain, but there's a lot of bad stuff that we just can't get around.
44:52 So let's keep the good stuff and throw away the bad stuff. So we kept the good
44:55 stuff. So now we get all of those security properties without any of the governance
44:59 problems. So every issuer is potentially both a resource authority and an edge.
45:07 Mutually authenticated edge accessor and resource authority prevent impersonation
45:11 attacks. And so this is what it looks like, right? Right? And ACDC is this graph
45:18 fragment. It has attributes and edges. And then I chain them together. And then I get
45:25 a graph. And this is the root or the origin of the graph. And I verify this and
45:32 then I walk back. Right? And these are the leaves of this graph. And I can't change
45:38 any of the nodes without changing this one because this is literally a hash graph.
45:43 It's a Merkle tree. That's how a Merkle tree works. It's just that it's a very
45:48 flexible Merkle tree that isn't a tree. This is shown as a tree, but each of these
45:54 each ACDC could have any number of edges, right? So it's an M-ERI tree.
46:00 So edge verifiable agent control is we already do that with ACDCs. Anybody that's
46:08 delegated is an agent. All I have to do is put the word AI in little quotes there and
46:14 then I've solved the agentic AI problem from the authorization authentication
46:20 security point of view, not the details of what specific things that it does. You
46:26 still have to manage that. So I'm not claiming that I've solved all of the
46:30 problems. There's lots of really good meaty problems there. But the problems
46:34 that most people aren't solving, that they're hand-waving, that they're just
46:38 saying, oh, we assume key management is secure. Right? When as soon as somebody
46:41 does that, when they go, key management is secure, I know, okay. Okay. You just
46:47 avoided the hard problem. You just assumed the hardest problem to solve. Somebody
46:52 else is going to solve. And now you're going to work on the cool sexy problem
46:55 that you want to solve, but you basically left yourself open to all forms of attack.
46:59 You're insecure because you didn't solve the key management problem. That's my
47:03 contention. Anytime anybody does that, I just go, okay, I'm not interested in what
47:07 you're doing because you didn't solve the hard problem. Once you solve the hard
47:10 problem, then I'm interested in the other stuff that you're doing. Okay, so let's
47:14 see how it works. Right? Here's an ACDC. These are the top level fields. You have
47:19 an issuance registry. Okay. Here's the fields in the issuance registry. You have
47:25 a usage registry. These are the fields in the usage registry. And then you have a
47:29 resource map. Routes and capabilities. This would be like a, you know, object
47:36 capabilities type authorization structure. This is a well-known thing. Not
47:41 reinventing the wheel here. What we're reinventing is that how this gets secured
47:46 is through these key management based security threshold structures.
47:57 Okay, so I'm going to skip these slides because those are just getting into
48:00 detail. I'm going to skip ahead to these slides. I got just a few minutes. So this
48:06 is going to be somewhat controversial. The reason it's somewhat controversial is
48:11 because it's contrarian to the way the world thinks. Now, this isn't contrary.
48:16 The internet is a dangerous place, right? Everybody agrees? Dangerous place to be.
48:21 Right? So, what we need is a digital refuge, an online shelter, an internet
48:26 sanctuary, a surveillance asylum, right? Cool word, right? We want to go to the
48:30 asylum to be protected from surveillance, right? Safety requires accountability.
48:36 Does anybody disagree with me that safety requires accountability? accountability.
48:46 Can you think of a way that you can be safe from people who are going to harm you
48:50 if the people harming you can't be held accountable for harming you?
48:58 If they can get away with harming you, what's to stop them from harming you? I
49:04 mean, if you, I mean, you could say, well, you personally could hold them
49:07 accountable, but it's still the same thing. Self-defense is a form of
49:09 accountability, right? If they're not held accountable, harm will happen. So
49:14 fundamentally safety comes from accountability. It doesn't come from
49:17 anything else, right? You could say, well, you could hide. They can't find you. Okay.
49:24 That's one way to protect yourself is to hide. But if you're hiding, what else
49:29 aren't you doing? Everything else that matters in your life, right? Anybody in
49:35 here ever lived off grid for any significant amount of time? Okay. What was
49:40 it like? Yeah, you completely off-grid? You're one of the ones that doesn't want
49:46 to be on the camera? Okay. So what things did you have to give up to live off-grid?
49:59 Okay.
50:04 We're talking about food and clothing, right? So you can't use a bank online,
50:10 right? But not be off-grid.
50:17 Okay. So off-grid more than just power. I don't mean off-grid power. I mean truly
50:22 off-grid, not using the internet for any purpose. Because I'm talking about the
50:27 internet as a dangerous place, not whether your neighborhood's a dangerous place. All
50:32 right. So I know people that are off-grid on the internet and they live in the
50:37 mountains and they can't go anywhere or do anything because as soon as they leave
50:42 their enclave, they become observable. They become surveillable. Huh? Like Steven
50:48 Hawkins in World Wargate. Yeah, that kind of that level. Yeah, that level of it.
50:54 Okay. So safety requires accountability. That means privacy requires
51:00 accountability. This is where it gets controversial. People don't think that
51:03 privacy requires accountability. So So think about it. Second parties to repeated
51:09 interactions can correlate the first parties. That's true.
51:16 So if I never interact with somebody, then there's nobody to hold accountable, right?
51:23 As soon as I interact with somebody, there's somebody now that can harm me. And
51:29 if they can correlate me by repeated interactions, even if I'm as anonymous as
51:35 I can make myself, if there's a way to correlate me, then eventually they knew
51:38 who I am, which means that eventually they can harm me. Right? You heard the phrase,
51:43 right? I know where you live. What does that mean? It means, well, I know where
51:48 you live, which means if you wrong me, I know where to go to harm you, to get
51:53 revenge, to get to, you know, restitution for the harm you did me because I know
51:58 where you live. I know where you're vulnerable, right? Well, if you're on the
52:02 internet and you're interacting on the internet, at you've made yourself
52:05 vulnerable to harm. The act of interaction makes you vulnerable to harm. That means
52:10 if you truly want to be private,
52:15 you need to be the whole anybody you interact with accountable for what they do
52:20 because one of the ways they can harm you is through a third party. They can just
52:24 share whatever data you have shared with them with a third party and the third
52:27 party is the one that harms you. But that the source of the harm came from the party
52:32 that you interacted with who didn't respect your privacy. All right. Using the
52:38 wrong definition of the word privacy. Any interaction system that does not enable
52:43 first parties to hold second parties accountable is fundamentally incompatible
52:46 with privacy. That's my argument. If you can't hold people accountable, you can't
52:51 have privacy, which is counterintuitive to the idea that privacy comes from hiding.
52:59 If you're interacting, you're not, you can't hide. There's no way to hide if
53:03 you're interacting. Everything you try to do always leaks information. And when you
53:08 have surveillance that it has sufficient coverage, sufficient scope, every piece of
53:16 information you leak eventually will be able to correlate to create an identity of
53:22 you. What is continuous identity? It's just using correlation. They're already
53:27 doing it. Everybody's already the reason they can even propose it is they've been
53:31 doing it for years and calling it something else and then said, Oh, well,
53:34 heck, we can re-identify people. That means we can identify people. We'll use it
53:40 for authentication. We won't use it for re -identification. We'll just use it for
53:46 first, you know, you go to their websites and say, Oh, use continuous identity. What
53:50 it says is, Well, you can improve the user experience because as soon as the user
53:55 touches your website, we know who they are so that you can guide the user knowing
54:01 that you know who they are. And the user didn't have to click a button that said
54:04 cookies or not cookies or login or anything like that. You don't even have to
54:08 log in. They know who you are just from what browser you used. And so it's lower
54:16 friction because it's like, well, you don't have to give me a password. I know
54:21 who you are because I know that you're logging in from this cell phone and this
54:26 cell phone happens to be in this location and it correlates positively to being you.
54:31 Somebody didn't steal your cell phone and log in because if they stole it, they
54:35 wouldn't be in your bedroom at 4am, right? They'd be someplace else at 4am, right? So
54:40 we know that when you're logging in from your bedroom at 4am, it's highly likely
54:44 you, so we can trust it and we'll remove that friction of you supplying us an
54:50 authenticator. That's what continuous identity is saying, right? So if you think
54:55 it through far enough, you realize there is no such thing as privacy without
54:59 accountability because privacy really isn't privacy if you're interacting. It's
55:03 confidentiality. You have to get people to respect that the data you share with them
55:08 stays between you. It's confidential to you too. It doesn't nobody else has any
55:14 right to it. And that's a type of privacy, but it's intimacy between parties, not
55:20 truly private. So how do you enforce accountability? Well, there's a protocol
55:27 called the trust spanning protocol, which is you can use the KERI suite for, but you
55:33 create and control safe relationships where interaction is protected from
55:37 surveillance by third parties and second parties are held accountable for any
55:40 information shared with or by them. This part isn't part of the TSP protocol, but
55:45 if you're using secure authorization, then you can then layer on accountability. And
55:52 one of the things in this Utah state law, and I know we're almost out of time, is it
55:56 called a duty of data loyalty. Duty of data loyalty is the latest and greatest
56:01 legal principle for reversing the harm on the internet. And what that says is that
56:09 succinctly anybody that interacts with you or uses data about you or from you that
56:16 comes from an interaction has to be loyal to your best interests. They can't use
56:22 that data in a way that isn't in your best interest. That means they can't do
56:27 something like trick you into saying things like, oh, we're going to de
56:34 -identify this data and then it's not data about you. That's a lie, right? But what
56:41 can you do, right? Well, if they've agreed to use it in your best interest, then they
56:48 no longer have a safe harbor. If they take that data and sell it to a third party,
56:52 whether it's de-identified or not, and they come back to harm you, you have
56:56 recourse against them because they were disloyal. And the burden of proof of
57:00 disloyalty is different from the burden of proof for harm. Disloyalty, all you have
57:04 to prove is that they self-dealed. If they benefited from it, whether you are harmed
57:09 or not, they're presumptively disloyal and you can sue them. And so your ability to
57:15 enforce increases exponentially. So that's in the Utah state law. And we snuck that
57:22 in, honestly, because the data aggregators don't like it. And I'm done. So, all
57:28 right. Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:35 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire Dire
57:36 Dire Dire Dire Dire Dire