0:00 Samuel Smith ｜ The Future of KERI ｜ KERI Conference 2026
0:02 So I guess I talked too much
0:06 yesterday,
0:08 so I guess I'm gonna be swallowing the
0:11 mic today.
0:12 Anyway, like to thank everybody for
0:15 showing up. Today we're going to
0:18 talk about a little bit about the
0:20 future. So, I did the past yesterday,
0:23 the present. Today's a little bit about
0:24 the future, a little bit about the past.
0:27 And I have a little teaser there: Saving
0:29 the internet. I mean, the reason I
0:32 started doing identity was I wanted to
0:34 save the internet. I wanted to fix the
0:36 broken internet. And I didn't realize I
0:38 had to work on identity to do
0:40 that. And I know other people probably
0:43 knew that better than I did, but I
0:46 didn't realize that. So, one of the
0:48 things that the future of the KERI
0:50 suite is about more and more
0:53 applications that use ACDCs,
0:56 right? And I gave my talk
1:01 last night, talked a little bit about
1:04 what an ACDC is. So I just want to
1:06 review it a little bit. An ACDC is this
1:09 generic
1:11 graph structure for representing data.
1:13 And when we represent data in graphs, we
1:15 get all kinds of useful properties. And
1:18 so we've got a vertex and edges. And we
1:21 can use those to do all sorts of fun
1:23 things. But the most important thing
1:25 that ACDCs provide is perpetually
1:27 verifiable issuances. That's the hard
1:30 problem it solved, that wasn't solved
1:31 before. And now that we have perpetually
1:34 verifiable issuances, we can do all
1:36 sorts of things we couldn't have done
1:37 before.
1:39 Each fragment is separately
1:41 authenticatable.
1:43 So that provides something that a normal
1:45 graph data structure doesn't do. Lots of
1:48 people have graph data structures, but
1:50 the whole data structure source from the
1:52 same source. Where with ACDCs, every
1:55 every node in the graph can have a
1:57 different source. So you can use them
1:59 for a lot of different things that you
2:00 couldn't use a graph data structure for.
2:03 And these are the things that you
2:05 can do with it. Delegable, attenuable,
2:08 aggrable, revocable,
2:10 transferable, authority. And so we have
2:13 some talks today. Phil's going to be
2:15 talking both Phils: Phil [Feairheller] and
2:18 Phil Windley about authorizations. We're
2:21 going to talk about
2:23 some of the things that now
2:25 that we have solved identity, [plus] we solved
2:28 basic issuances, now we can start to do
2:31 more complicated things with ACDCs and
2:33 so I see the future people are going to
2:35 find more and more things to use ACDCs
2:38 for. So the idea is: with ACDCs we
2:43 can have high-fidelity modeling of real
2:46 world authority structures. Can you guys
2:48 hear me? I can't tell. Okay.
2:52 I can't hear myself because normally I
2:54 talk really loud and my whole head
2:56 resonates with my own sound. So it
2:58 sounds like nothing's happening. So,
3:01 one of the things that we can do with
3:03 ACDCs is we can bridge. KERI and
3:07 ACDCs solve the cross trust domain
3:10 transfer problem in an elegant way and
3:13 that's a hard problem to solve.
3:16 Recursive Privilege Escalation Attacks (RPEA)
3:19 are a
3:22 Negative
3:24 consequence
3:26 of using identity systems that don't
3:30 solve the cross trust domain transfer
3:32 problem. Instead, what they do is just
3:35 increase the size of the one trust
3:36 domain because since you can't bridge
3:39 trust domains, make your trust domain
3:41 bigger. And that means now that you can
3:42 do recursive privilege escalation
3:44 attacks. If you keep your trust domains
3:47 small and bridge them properly, then you
3:50 don't have recursive privilege
3:51 escalation attacks. And so with KERI,
3:53 we can solve that problem. So the idea
3:57 is
3:59 that we have two trust domains and we
4:02 use ACDCs
4:04 to move data trust authority between
4:07 those domains. (That was a cool effect,
4:09 right?)
4:11 So perpetual identity leads to
4:14 perpetual issuances means, and I'm going
4:17 to steal Daniel Hardman's phrase,
4:19 lossless trust transfer.
4:21 We don't lose trust when we use carrying
4:24 ACDCs to move trust across trust
4:26 domains.
4:29 So if I have ephemeral identity, then I
4:31 only get ephemeral in issuances. That
4:34 means every time I do trust
4:36 transfer, it's lossy. And that's what
4:39 we're living with right now in the
4:40 internet.
4:42 So now that I can have a lossless conveyor
4:45 of trust, I can also use it to bridge
4:49 ephemeral trust domains and the bridge
4:52 doesn't lose anything. Normally when you
4:55 take cables and connect them together,
4:57 every connection is lossy. And so the
5:00 longer the connections, the less
5:02 signal you get. But if I have really
5:04 high fidelity connections, then I lose
5:06 it in other places. And so this is this
5:09 allows us to take any application that's
5:12 currently using the current stuff,
5:16 and we can bridge it better. So a
5:20 lot of the discussions people have is
5:22 well I want to use ACDC with whatever it
5:25 is
5:27 you know the some existing system. Well,
5:30 it's okay for us to use it to bridge
5:32 those existing systems as long as we
5:34 understand that we don't corrupt the
5:38 ACDCs with lossy stuff, right? And so
5:41 I already mentioned that the whole
5:43 idea is we can remove this is
5:46 like the bane [curse] of current security.
5:49 This thing recursive privilege
5:50 escalation attack vulnerabilities. It's
5:53 it's horrible and we can mitigate
5:56 that.
5:58 So, when we talk
6:00 about end-to-end in the
6:03 the world we talk about edges but we
6:06 also talk about ends and in KERI
6:08 they're pretty much the same thing
6:10 because each AID is its own identity
6:12 provider we're using keys at the edge.
6:15 The edge is where authentication happens.
6:24 There are no third party IdPs, no relying parties,
6:27 no trusted intermediaries.
6:29 So we remove a whole layer of
6:31 infrastructure. It just goes away. Now
6:34 if somebody says you got to have it, you
6:35 got to have a relying party. You got
6:37 to have an OAuth server. Fine, Leave it
6:40 in there. But don't use it to expand its
6:43 trust domain. Go. Well, you want to
6:45 bridge these two trust domains. Don't
6:47 bridge them with more lossy stuff.
6:49 Bridge them with KERI and ACDCs.
6:53 So, in KERI an end-to-end and an edge to
6:57 edge, they mean the same thing, right?
7:01 The middle doesn't matter, the middle
7:03 is just a store and forward network.
7:07 So that leads us to the next thing
7:10 that's going to happen in KERI more
7:12 and more and this is authorization.
7:15 What do I mean by that? Well I got this
7:18 word down here. I love making
7:20 anacronyms. I know somebody
7:22 said that's problem for people to
7:24 understand but you guys
7:26 are the tech people. Edge
7:28 Verifiable Access Control (EVAC). What does
7:31 that mean?
7:33 Well,
7:35 I'm defining authorization
7:38 to access a resource is granted by the
7:41 resource controller. So I'm going to say
7:42 there's some authority that has
7:44 authority over a resource and if some
7:47 other entity wants to get access to that
7:50 resource that authority controller
7:52 grants that access and that access comes
7:55 through an authorization.
7:58 So each authority is itself an edge in
8:01 KERI with respect to other authorities
8:05 resources because it's all edge-to-edge
8:07 end-to-end.
8:10 So each authority can authorize access
8:12 by any other edge to its resources via
8:14 an ACDC. That's the whole point of
8:17 delegable aggrable authority, is that
8:22 you grant authority to somebody and now
8:24 they can access your resources
8:27 because you're the
8:28 authority who can grant that access.
8:30 Each issuer in ACDC graph is potentially
8:33 both a resource authority and an edge.
8:37 Mutually authenticated edge accessor and
8:40 resource authority prevent impersonation
8:42 attacks. A lot of the impersonation
8:45 attacks come because there's a
8:47 a misconfiguration
8:50 of how those two talk with respect
8:54 to each other. You look at how VPNs ..,
8:57 A common VPN problem is that I
9:01 have a VPN and I give an edge access
9:04 through the VPN, but the VPN isn't
9:07 mutually authenticating in a strong way.
9:11 So, the edge thinks that it's talking to
9:13 the VPN, but it's not. It's talking to
9:15 an impersonation of the VPN. So, when it
9:18 grants access, it thinks, "Oh,
9:20 okay, I can now share my other
9:23 credentials to what's ever on the other
9:25 side of the VPN." But I'm not on
9:27 the VPN I thought I was. Because I don't
9:29 have strong mutual authentication. I've
9:31 got a shared secret and that
9:34 means now that I'm going to disclose to
9:36 that other end my credentials to
9:39 get further into the system and I
9:42 rinse and repeat, right? But if we
9:45 have strong mutual authentication at
9:47 every edge, then there is no recursive
9:51 privilege escalation attack.
9:54 So, we basically do
9:59 this with ACDCs. So, I'm going to show
10:01 you how we can use an
10:04 ACDC. This is a proposal.
10:07 I haven't written a white paper on it
10:08 yet. I started writing a white paper on
10:10 it, but I haven't finished published it
10:12 yet of how we can just repurpose ACDCs
10:15 as generic authorizations.
10:18 So if you so there those of you
10:21 who aren't familiar with an ACDC, these
10:24 are the top level fields: version, type, its SAID,
10:27 a UUID, the issuer, the ACDC, the
10:31 registry for the ACDC state, the schema
10:34 section, attribute, edge, and rule section.
10:36 So, there's two registries here:
10:43 There's an Issuance Registry
10:46 and we can now add a Usage Registry and
10:49 the way we manage that is in the
10:51 attribute section. The attribute section
10:54 itself has a SAID, a UUID the issue AID
10:59 and it also can have a registry
11:01 identifier and then a resource map. The
11:04 resource map over here looks like
11:07 object capabilities. You basically have
11:09 a route and then a set of capabilities.
11:12 So it's a list of things like read,
11:13 write, execute, whatever it is. Standard
11:16 standard access control. All we do is we
11:19 just augment ACDCs to have a resource
11:22 list and we can implement any
11:26 sort of authorization
11:28 system. But what we get are some
11:31 properties that are
11:32 difficult to get in other ways, without
11:34 ACDCs.
11:36 So this stuff is actually in the
11:39 spec but I'm pretty sure almost nobody's
11:41 read it. Right here: the
11:46 issuee ID people know about, but in the
11:49 spec we actually have a registry
11:50 identifier defined; but this registry
11:53 identifier is different from that
11:55 registry identifier. This is the issuer
11:57 registry. This is the issuee registry.
12:00 Why does the issuee want a
12:02 registry? [question gets inaudible response]
12:08 That's right. So if the issue wantes to
12:14 know if they .., here's the
12:15 use case: somebody gave me an
12:18 authorization let's say this is my
12:19 authorization
12:26 I want to know if my authorization's been compromised
12:28 now in ACDC if I want to present it
12:31 requires at the very least signing it so
12:34 compromise looks like an a compromise of
12:36 my signing infrastructure now if it's a
12:39 token, compromise looks like somebody
12:42 just steals the token. It's an easy
12:44 compromise. You know, it's much harder
12:46 to steal my private keys. But let's say
12:49 someone has stolen my private keys.
12:52 They can then present
12:55 my authorization someplace and I don't
12:58 know that they've stole my private keys
13:00 unless I require that a verifier check
13:04 that the presentation is anchored in my
13:07 registry. So every time I do a
13:10 presentation I anchor in the registry.
13:12 The verifier checks that the issuer
13:15 issued it by checking the issuer
13:17 registry but checks that the presenter
13:21 actually says "I want ultra security when
13:24 I present. So don't verify the
13:27 presentation unless I anchor the
13:28 presentation." Makes the presentation
13:30 less ephemeral. But it also means now
13:33 that if I have really
13:36 strong security over presentations and
13:39 if somebody steals my private keys as a
13:42 as a presenter,
13:44 I know that they stole them because they
13:46 the only way that they can gain
13:48 access is to anchor it in my registry
13:52 that I control. And so that
13:55 allows me to detect compromise
13:59 of my credentials.
14:07 So here's showing what I just
14:09 said. Here's the issuance registry,
14:10 with a presentation. The issuee just
14:14 signs the presentation. The verifier
14:17 checks, it checks its observer, checks the
14:21 registrar, controlled by the issuer says
14:23 "okay it's good. The ACDC is fine."
14:28 This is what it looks like over here in
14:30 terms of the Key Event Log of
14:34 the issuer and then the
14:37 registry.
14:43 But then we have the registrars
14:45 and the observers.
14:46 But if I'm doing a usage registry, what
14:48 does it look like? Well, the
14:51 presentation itself gets anchored in a
14:54 in a registry that's controlled by
14:56 the issuee. So this one is
14:59 controlled .., this registrar is the issuee's
15:02 registrar and now the verifier checks
15:06 here. So the verifier would have to
15:08 check two registries; has to check the
15:10 issuers's registry and the presenter's
15:13 registry.
15:15 But that makes it so
15:19 that both the issuer and the user
15:21 can detect if either one has been
15:23 compromised and the verifier knows it.
15:26 So that's what it looks like here.
15:35 So basically any presentation gets anchored
15:40 in the issuee's
15:43 registry
15:45 and you can see the state of the
15:47 presentation and you can share one
15:49 registry for all your presentations
15:50 because it's one controller of the
15:53 registry.
16:04 So this is this is a another
16:06 difficult problem in authorizations
16:09 and that's when you have delegation
16:13 and we didn't solve this problem from
16:16 the vLEI
16:18 in this explicit way, but this is
16:20 in the spec
16:22 It solves the problem of
16:26 chained authorizations in a
16:28 delegation chain where the delegate
16:32 issues an authorization and then the
16:35 delegate's authority to issue the
16:37 authorization gets revoked. So the
16:40 question is:
16:42 What happens when a delegate's
16:46 authority or a delegatee's authority to
16:49 issue authorization is revoked. What is
16:52 the status as any authorizations or
16:54 entitlements that it issued before its
16:56 authority was revoked? Are they revoked?
17:03 Well, that would be really bad,
17:05 in some cases,
17:08 Let's say I'm a company and I
17:10 issue a purchase order. My purchases
17:12 agent while he works for me issues a
17:14 purchase order. Purchase order has a
17:16 90-day expiration on it. It's valid for
17:19 90 days, right?
17:21 And then I fire the guy because he
17:23 wasn't showing up for work, right? Do I
17:26 have to go through every purchase order
17:29 that he signed off on
17:31 and reissue it? Well, if it's on paper,
17:37 everybody assumes that it's still valid,
17:39 right? But if it's electronic, if it's
17:42 digital of an ACDC and it's got in a
17:44 revocation registry, I could revoke all
17:47 of them and then reissue them. But maybe
17:50 I'm okay with what he issued. I The
17:52 reason he got fired wasn't because he
17:54 was misuing purchase orders. He got
17:56 fired because he violated HR or
17:58 something, right? So everything that he
18:01 did officially is still good. But he
18:03 doesn't work for me anymore. But if I
18:05 revoke his authority, I break the chain
18:09 of authority. And if I don't have any
18:11 other mechanism, then I am forced to
18:13 reissue everything that he did.
18:16 So that's a hard problem of
18:18 delegation. And we don't solve these
18:20 these problems in general in
18:21 decentralized identity. If I have a
18:23 database, I can solve any problem. If I
18:25 have a centralized database,
18:27 all of these problems are
18:28 easy. It's just software. But if it's a
18:31 distributed decentralized [database], I have to
18:34 solve it cryptographically. I have to
18:36 figure out how I'm going to do it in a
18:37 decentralized way. So how do we
18:40 do that?
18:42 Well, here's a way that we can do that.
18:48 (I just I said that:
18:50 When the chain is broken.)
18:51 This is how we do it. With
18:54 something called a Bound Blinded
18:57 ACDC Register.
19:01 What did I put there? "Reco"?
19:05 That should have been
19:07 <i>Reversion</i>.
19:11 I misspelled that.
19:13 This is how it works.
19:16 We have this situation here. We have an
19:20 issuee AID.
19:22 The issuee is
19:26 the issuer of another ACDC. So we have
19:30 a chained set of ACDCs. There's an
19:32 edge pointing back from the delegated
19:36 one back to the delegating one. Okay. So
19:38 that's the setup. So now we have
19:43 the issuer uses this bound blinded state
19:46 registry
19:48 and the thing that it adds is the
19:50 sequence number and the SAID
19:53 of the key state of the issuee who is
19:57 also the issuer. Right? The guy
20:00 in the middle is both an issuer and an
20:02 issue. He's an issuee of his delegator
20:05 and he gets to issue stuff himself.
20:07 Right. So it's a delegated chain but
20:10 what we're doing is we're binding ..,
20:12 we're binding the key state of
20:16 the issuee at the time
20:20 we give him authority.
20:23 So right here, we issue to him
20:26 authority and we bind his key state.
20:29 And then when we revoke his authority we
20:32 also bind his key state. What that says:
20:35 between two and five
20:38 He has the authority to issue things
20:42 and here's his registry. He can issue
20:44 things in his registry. So in this list
20:47 right here, he can do things
20:51 to this other thing and they all
20:53 work. But number six
20:58 here, he doesn't have authority anymore.
21:02 So even though he's got an update event,
21:04 that update event, the bottom one's not
21:07 not verifiable because he doesn't have
21:09 authority to change that. So we have
21:11 a problem.
21:13 So, the only way that this works is if the
21:20 issuances over here
21:23 are all time expired.
21:29 [Sam sorts out the tools for presenting]
21:42 So, what happens is that the type
21:48 of ACDC that he can issue here have to
21:52 have some sort of timeout because they
21:55 themselves can't be revocable because we
21:57 have an ambiguity about what we do about
21:59 it when we revoke his authority. But as
22:01 long as it times out or something then
22:03 it'll just self-revoke.
22:05 So how do we solve that problem? That's
22:07 the harder problem. So this
22:10 is not in the spec. This is actually a
22:12 proposal for the spec. We add
22:16 another event.
22:20 So the way
22:23 we can solve it .., it's not written up
22:27 in the spec but this is an easy
22:28 modification of the spec, is that because
22:31 there's an edge right here
22:34 that points back to the issuing
22:36 authority
22:38 we can do a reversion of authority. So
22:41 let me give the example. Let's say
22:44 that I'm a lieutenant of a
22:47 company and I take one of the
22:50 members of the company and I give him an
22:52 order and I say you're going to go over
22:54 there, right? And he goes over there,
22:59 right? He has authority to do it. I told
23:01 him to do something. Let's say that I
23:06 I resend that order. He can't
23:09 do that anymore.
23:11 What do I do at that point?
23:15 The authority to do that still rests in me,
23:17 the lieutenant. I can go
23:22 over there and do it or I can
23:25 authorize whatever it is myself.
23:28 So, the authority always reverts to me
23:31 as the higher authority. So what we do
23:34 is that when a subordinate or a
23:37 delegate loses authority because we've
23:40 revoked it, any outstanding issuances
23:44 that were validly issued that we want to
23:47 dynamically revoke the revocation now
23:50 becomes the responsibility of the
23:52 delegator. It just reverts back to the
23:54 delegator. And because we have an edge,
23:56 we know who the delegator is. And so all
23:58 we have to do is make a policy change
24:00 that says in this case
24:04 where I revoked ..,
24:09 his authority
24:11 right here.
24:13 So you see this one
24:17 over here is issued, I can't revoke
24:19 because he's been revoked over here in
24:22 number five. But guess who can revoke
24:24 it? See the line that comes back here?
24:28 He can revoke it. And a verifier
24:31 just needs to know that's
24:34 the policy.
24:36 It just looks it up and says, "Oh, okay.
24:39 The approximate delegate doesn't
24:41 have authority because it's his
24:43 authority has been revoked. The chain's
24:45 broken." But any subsequent actions on
24:48 that ACDC are still the responsibility
24:51 of the delegator. And so the delegator
24:53 can revoke it. So now we can have
24:55 dynamically revocable credentials and
24:58 break the chain and still dynamically
25:00 revoke them. Yeah.
25:10 Well, well, since there's always edges, you can the reversion of authority
25:13 can go all the way up to the top of the
25:14 chain. You can break the
25:17 leak as many times you want and you just
25:19 keep you just rinse and repeat all you
25:22 just ascend the chain. So now you have
25:24 an elegant solution
25:26 for dynamically revocable delegated
25:30 credentials all the way down. You can
25:33 break the chain any number of times and
25:35 still control those credentials
25:37 dynamically.
25:39 So we have solved a really hard problem
25:43 that in ephemeral authorizations isn't a
25:47 problem because no authorizations last
25:49 long enough that you care. But if I'm
25:52 doing perpetually issued authorizations
25:55 that last indefinitely unless they're
25:58 revoked and I'm doing a chain, I need to
26:00 solve that problem.
26:04 So that's the solution.
26:07 You revert the authority to the delegator when the
26:11 delegates authority is revoked and that
26:14 allows you to continue to control
26:16 those issuances.
26:18 Now we can do it even better. This
26:21 requires something not in the spec.
26:24 So this is a proposal to add in the spec
26:26 and that's just adding one additional
26:29 one additional update. It's called a
26:32 transfer event. So if we look over here ..,
26:46 Oh, number three.
26:48 Number three is transfer event. So
26:50 we have an inception event and a
26:52 transfer event. Those are analogous to
26:55 an inception event and a rotation event
26:58 in a Key Event Log. So in a transaction
27:00 event log, we now have meta control
27:04 events. We always had the
27:06 inception event which establishes the
27:09 who's the authority over the
27:11 registry. Now we have a transfer event
27:14 that says 'we can
27:16 transfer authority to a different
27:20 AID.' So that allows us to do an
27:24 authority transfer. So it's not just
27:26 reversion. We have a reversion of
27:28 control. The reversion allows us to
27:31 issue a transfer event. Now we have a
27:33 new delegatee, that now is a control
27:36 of all those credentials that are
27:38 controlled by that registry. So we could
27:40 do a seamless transfer all the way down
27:42 at every level. And all we have to do is
27:44 add one event. And the main thing in
27:46 this event is just that it's got
27:49 It's got the issuer. It's got
27:52 the new issuer AID, not the
27:55 issuer back here. The issuer at
27:57 the end.
28:01 Yeah. – [inaudible question]
28:11 Well, the cryptographic context is that every event
28:14 in all of these registries is anchored
28:17 to somebody's Key Event Log.
28:20 So that's perpetually verifiable
28:23 because all of the security
28:26 mechanisms that protect the key event
28:27 log protect everything anchored to the
28:29 Key Event Log.
28:31 – Right? So post transfer you want to
28:34 minimize the number of nodes you have to
28:38 recurse through in order to get your
28:39 verifications to work.
28:41 Well, you're not minimizing them,
28:43 you're not changing the number because
28:45 you have a chain. So you always
28:48 have to verify the whole chain. Yeah.
28:50 So,
28:50 so you didn't increase the length of the
28:51 chain, you just switched a branch in the
28:54 chain.
28:55 – Right. So, there's a dead branch in the
28:57 chain because the employee got fired.
28:58 Right. – And I don't want to
29:00 maintain his logs forever.
29:02 Well,
29:02 his K logs, right?
29:04 No, you don't have to maintain his key
29:06 event logs, you know. Well, yeah, you do
29:09 have to maintain his Key Event Logs for
29:12 as long as those issuances are valid
29:14 because that's the only way you can
29:15 verify the original issuance.
29:17 That was my question.
29:18 Yeah. So, you wouldn't do it
29:21 for you, you wouldn't do it for
29:23 something that was ..,
29:29 This would allow something
29:31 that's longer lived ..,
29:33 Let's say an employee issues a
29:35 purchase order that you want to be
29:37 dynamic revocable, but you're
29:40 not going to have it sit out there for
29:42 more than a year, right? So, you could
29:44 transfer to a new employee. It still
29:46 lasts a year, but you could still revoke
29:48 it if you found out there was something
29:49 wrong with it. If you're the
29:53 state of Are we out of time? Oh, you're
29:55 just asking questions. Okay. Let me
29:58 let me Yeah, go ahead. I guess
30:01 – I was just curious because you
30:02 nailed it with key rotation can already
30:04 transfer control. So, is
30:07 this analogous to a sort of [key rotation]
30:10 Well, the difference here is that
30:13 key rotation is
30:17 heavy weight transfer because you're
30:20 talking about control of the AIDs.
30:23 – Yep.
30:23 Right. And so in the case of an employee
30:26 leaving, you would at very least have to
30:28 have a multi-sig
30:30 so that multiple employees controlled
30:32 the AID and one of them rotated out.
30:35 This allows you to avoid any of those
30:37 issues
30:38 – because you're doing it on the registry
30:39 level.
30:39 You're doing on the registry level
30:40 instead of the KEL level. So, it's a
30:42 much lighter weight, easier to manage
30:45 situation for doing things at scale.
30:49 – What I'm wondering though is that it
30:50 could this be a point of failure if
30:52 someone were to key compromise and then
30:55 Transfer a registry toward a
30:57 malicious controller out.
30:58 Well, anytime you compromise keys,
31:01 you can do something malicious, right?
31:03 But you can't do it without being
31:04 detected, right?
31:05 Which means you recover from it,
31:08 – Right.
31:08 So that's the point.
31:11 – Okay. I'm just trying to understand if
31:12 it opens up potentially any like
31:14 vulnerabilities.
31:16 Not any new ones.
31:18 – Okay, good.
31:21 This now
31:26 means that we can maintain control over
31:30 issuances, out at the edge of our graph,
31:34 authorizations,
31:35 and they can survive for long periods of
31:38 time and we have dynamic control over
31:40 them and we can change control over them
31:42 dynamically.
31:44 Not all issuances benefit from that.
31:47 There's some you don't want to do that for.
31:49 But in the cases where you have
31:51 really long-lived things, like
31:54 guardianship. This is an
31:56 example of guardianship. You have a
31:59 child who has parents that are
32:02 guardians of the [child, red.] and they get
32:03 divorced. Who's the new guardian?
32:07 Do you want to reissue the birth
32:09 certificate to the child or do you want
32:12 to transfer control of the birth
32:13 certificate to the new guardian? You
32:16 want to transfer control. You don't want
32:18 to reissue the birth certificate
32:22 and lots of authority structures in
32:24 corporations
32:25 that have to do with things like 'who has
32:28 control over the domain name registrar
32:31 for the company?'
32:34 Do you want to reissue all your domain
32:36 names every time that person moves? Or
32:41 do you want to have some mechanism that
32:42 you can transfer control?
32:46 And do you want that mechanism to be a
32:49 multisig group, where you have a group of
32:51 IT people that all have
32:54 a threshold control? You could do it
32:56 that way or you could do it this way. In
33:00 some cases, this is going to be more
33:01 scalable because it's not
33:04 requiring tight coordination for key
33:07 management.
33:13 This would be in version 1.1 of the
33:16 ACDC spec. My proposal would be to add
33:20 another event [transfer event]. So basically we're
33:23 just adding one event so we can do
33:25 control transfer on a registry. And I
33:28 didn't think of it a year ago when I
33:30 wrote up the registry, but as I was
33:32 thinking about this problem some more, I
33:34 said, "No, no, we probably should
33:35 add that one." And I actually changed it
33:37 three or four times because I kept
33:38 trying to decide what I needed. And I
33:40 realized that the
33:43 only thing it needs to have is the
33:44 issuers' AID. Everything else is the
33:46 same as the inception event.
33:49 It just declares a new issuer.
33:54 So it's the event type is the only thing
33:55 that changes. Any
33:58 other questions before I move on?
34:02 Yeah.
34:04 – Does vLEI authority fit into this somehow?
34:07 Yeah, right now vLEI don't solve
34:10 these problems. So with the vLEI, what
34:13 you have right now is
34:16 a grace period. When you're issuing the QVI
34:21 loses its authority, all of the vLEIs they
34:24 issue are still valid for a grace
34:27 period. Karla [mcKenna] wants to answer.
34:31 Go ahead, Karla. Oh, get the mic..
34:36 – Yes. And I knew that this was coming
34:37 Because Kevin told me that you were
34:39 working on it. And so we have been
34:42 looking at a way in order to be able
34:45 not to have to go back to the legal
34:47 entities.
34:49 [Case:] Your QVI is leaving the system,
34:55 you're going to have to hire a new QVI
34:56 and recreate everything that you
34:59 have. And so this way we can transfer
35:02 control to GLEIF and then as the legal
35:05 entities hire their new QVIs we can
35:08 transfer control again to the new.
35:10 That's what happens: GLEIF now becomes
35:12 the authority, not the QVI,
35:15 and then you don't have to make the
35:17 transfer control be forever. It can just
35:21 now be a dynamic time period to give you
35:24 a grace period to find a new QVI and
35:26 reissue. But now the grace
35:29 period now is dynamic instead of fixed,
35:32 right? Right now it's fixed to what? 90
35:34 days. Yeah.
35:35 – Okay. Sam, I'm gonna give you a
35:36 practical example: I work for a civil
35:39 engineering firm. I have my engineer
35:41 stamp. I've stamped the bridge as being
35:44 ready to build or meeting the spec. I leave
35:47 the company. What is the company going
35:49 to do? I'm trying to see that how that
35:52 hierarchy would work, especially
35:53 considering that in the traditional
35:55 world, we just file those blueprints and
35:56 that engineer stamp is always on there
35:58 and we consider it valid.
36:00 Well, right now the engineering stamp
36:03 isn't dynamically revocable.
36:05 There's no mechanism to do that. So,
36:07 this only applies to engineering stamps
36:10 that you already need to dynamically
36:12 revoke.
36:14 So because it's very
36:17 difficult to do dynamic revocation
36:19 almost no real world issuances have
36:22 dynamic revocation. But because now
36:25 we're doing this stuff cryptographically,
36:27 all of a sudden all sorts of use cases
36:28 where we want them to be dynamic
36:30 revocable but we never thought it
36:32 possible so we didn't and we just lived
36:34 with it now become good applications. So
36:37 we're talking about using ACDCs in new
36:39 ways. You can refactor
36:43 multiple licensing regimes to have
36:48 dynamically revokable licenses and it's
36:51 practically workable.
36:58 So there should be some business opportunities there.
37:06 – So the basic idea of this transfer registry
37:10 that you create with that you're
37:12 delegating or changing transferring
37:15 control over a set of identifiers to a
37:17 new identifier. So it creates a
37:19 registry.
37:19 No, you're changing control of the
37:21 registry.
37:22 One identifier, the registry's
37:25 identifier. That's what you're changing
37:27 control of.
37:27 Yeah, I misspoke there. That's right.
37:29 Okay. So just the registry that you
37:31 might have already issued many
37:32 credentials from and so is essentially ..,
37:34 Or one credential that has state changes
37:38 and you don't want to reissue
37:40 that credential. You want the credential
37:42 to continue to have viability. You just
37:44 want to change who has the authority to
37:46 change the state of the credential.
37:48 That's all you're doing.
37:49 – Got it.
37:49 And you're doing that .., I want
37:51 to point out something out here. See
37:53 this event right here, the transfer
37:55 event. See it has two arrows going to
37:57 it. That because a validator first has
38:00 to verify that the reverting
38:02 authority approved it, and has to verify
38:06 that the new authority approved it.
38:10 And then once that happens, then they
38:13 they don't care because it's just the
38:14 new authority.
38:19 All right. Any other questions? All
38:24 right we'll go to the next one.
38:28 – Do you need [to have]
38:32 reversion in place in order to have a
38:33 properly functional transfer registry
38:35 Of this type? ( – yes) There's another type
38:37 of transfer registry that we haven't
38:39 defined yet that I have an
38:42 outstanding issue on KERIpy [for], that's
38:45 different from this. – Okay.
38:46 This is reversion for a hierarchy of
38:49 authorizations and delegation,
38:52 not a replacement for asset transfer.
38:55 Ned [Smith] is going to give a talk on secure
38:57 asset transfer later today.
39:00 – Can I ask one clarifying question? Yes.
39:03 Previously earlier in this talk, I
39:07 thought there was another methodology
39:08 where it was like 2 through 4 was valid.
39:10 So that's a different style, where
39:13 it's a different style of dealing with
39:15 the same problem? No, its the same thing,
39:17 It's the same thing. It's just this says
39:20 once you're invalid, what do you do with
39:23 the ACDC of the controlling authority?
39:27 If nobody's in charge of it? So you can
39:30 revert back to the delegator and
39:33 now the delegator is in control.
39:36 But that now imposes a burden on the
39:38 delegator to have to make a controller
39:40 from that point on.
39:41 – Right. I just thought I understood
39:42 previously like to answer his question
39:45 about that
39:50 use case where you could potentially
39:53 just keep
39:55 a certain subset of the
39:58 issuances of the credentials
39:59 previously.
40:00 Yeah, that works as long as the
40:02 delegated credentials expire on their
40:04 own. If they're dynamically revocable
40:08 and you break the chain, you can't
40:10 revoke them after you broken the chain.
40:12 So, it works for conventional
40:15 issuances that time out. If I have a
40:18 food handlers permit that times out in a
40:20 year, I can fire the employee that
40:23 issued it and it's still valid, but
40:24 it'll expire in a year. But if I have
40:26 something that I want to be able to
40:28 revoke any point in time, then I can't
40:31 break the chain and still I have
40:33 to define what that means. So,
40:35 I could say "it means X,"
40:37 right? But we want to make it so that we
40:40 can actually verify and enforce it
40:43 cryptographically.
40:45 (I sound like somebody that doesn't
40:47 have a voice. All right.)
40:51 So I'm going to move on because
40:52 we're going to run out of time. I have a
40:54 couple more slides. So, the other thing
40:56 we can do is that EVAC can
41:00 also mean edge verifiable agentic control.
41:03 Now, here's the thing.
41:05 An agent
41:06 is an authorized
41:09 delegate
41:11 of a natural person, a legal
41:14 entity, right? An agent can be another
41:17 natural personal legal entity. It can be
41:19 a piece of software. It can be an AI.
41:22 The term agent means .., nothing in
41:25 anything, that I showed you before, is any
41:28 different if it's a person or an AI
41:31 that's in the delegation chain. It all
41:33 works the same. So now if you're worried
41:35 about whether your agentic AI has
41:38 permission to do X, you can
41:41 cryptographically verify that it had
41:42 permission to do X and you can revoke
41:44 its permission to do X and any verifier
41:46 can verify that. It doesn't matter.
41:50 You just give the agent an AID, a
41:52 delegated AID,
41:54 right? So that's the original meaning of
41:56 the word agent. So when see people say
41:58 agentic AI, they're just software agents
42:01 that are a little bit smarter than
42:03 software agents used to be, right? The
42:06 ACDC mechanisms are exactly the same.
42:08 They don't change. So if I want to do
42:10 EVAC, I do evac.
42:14 So you may want to have
42:16 regulations require attributes in your
42:19 chain that says 'this agent is a person
42:23 versus an AI,' you might want to disclose
42:26 that. But as far as verifying their
42:28 authority and what they do with it,
42:31 ACDCs accommodated without any
42:33 changes. Yeah. – One of the other
42:35 problems with delegation is controlling
42:37 the recursion of delegation. And so
42:41 there's a bunch of, you know, weird
42:43 stuff in X.509 for how to do that. I'm
42:45 just wondering what mechanisms exist
42:47 here to manage the
42:50 the degree of delegation that a
42:52 delegate ..,
42:53 What do you mean by
42:54 recursion? Like how many levels ..,
42:55 – A delegate can delegate to another
42:57 delegate.
42:58 Oh yeah. So in KERI
43:01 When you have ACDCs
43:04 they're edge operators and so you can
43:07 have an edge operator that says 'do not
43:09 delegate' or you can have a configuration
43:12 for a delegated AID that says 'do not
43:14 delegate.' You can say how many layers
43:17 down you can have delegation. Right? But
43:19 I'm familiar with that.
43:21 Do you have a whole policy engine
43:23 for how far you delegate? Well, actually
43:25 you can have a whole policy engine with
43:27 ACDCs because we have edge operators. So
43:30 you can you can make it as complicated
43:32 as you want or as simple as you want.
43:36 ACDCs don't care,
43:39 it's up to the user application.
43:41 The cryptographic verifiability is:
43:44 "I have an edge. The edge has properties."
43:46 The properties can define whether that
43:48 edge allows further delegation or not.
43:52 Does that make sense? Did you guys
43:54 understand?
43:56 Yeah. Okay.
43:58 All right.
44:00 Safety. So, I'm going to change topics.
44:01 I have a couple of questions. All right.
44:03 Back here. – I guess it's the same
44:06 with natural people and
44:09 organizations to natural people.
44:11 How would you enforce if possible
44:14 attenuation such that
44:17 subsequent delegates or delegatees do not
44:20 acquire more power than the ..,
44:23 There's two governance mechanisms
44:25 that we use in ACDCs for that. One is
44:28 called an ecosystem governance framework
44:32 okay so for the vLEI there are
44:36 200 pages of documents that say 'this is
44:39 what you can do with these ACDCs.'
44:41 They define the delegation, what you can
44:44 delegate, how much you can delegate, how
44:46 many layers of delegation, what the
44:47 ACDCs are, who does that, .., right?
44:50 That doesn't have to be encoded into the
44:54 ACDCs themselves because the schema
44:57 for the ACDC which is an immutable
45:00 schema is defined to be the schema and
45:04 then you look up the ecosystem
45:05 governance framework for that schema and
45:07 you go "Oh, this is how I use these guys
45:10 In real world you're
45:13 probably going to have quite fixed
45:15 well-rigidly defined ecosystem
45:18 governance frameworks because that's how
45:20 the real world works. We don't go
45:22 around and say, "Hey I want to be
45:26 a real estate agent." 'Agent,' right? Hear
45:30 the word 'agent.' What are the rules for
45:32 real estate agents? How can they
45:34 operate? What things can - and can't
45:37 they do? Well, there's a whole body of
45:39 regulation about it. We don't have to ..,
45:42 we just have to say "Well,
45:46 we're going to make it so they can
45:47 verify that they're an agent. We can
45:49 reference all the regulations that apply
45:51 to them as an agent." Now, we've modeled
45:54 the real world authority that already
45:56 exists, but we just made it so that they
45:59 can do the verification
46:01 quickly and securely without
46:04 impersonation or fraud. We don't have
46:06 to build all of that rulemaking
46:10 stuff if we don't have to.
46:13 There's no reason to do that. But if we
46:16 want to add
46:18 some of that [rulemaking, red.] because it's practical,
46:21 then we can encode it in the edge logic
46:24 with edge operators. But
46:26 we want to minimize that.
46:28 What tends to happen is people try
46:30 to model all of the stuff in the world,
46:33 real world in data, and then they get
46:36 data that is ambiguous. They
46:40 get ontologies
46:42 that are broken.
46:45 Yes. Yeah. – We've been toying with
46:48 with this delegation structure a bit
46:51 more from an application perspective,
46:52 right? An agentic AI is not one thing.
46:55 It's a spectrum, right? So in other
46:56 words, there are rule based on the lower
46:58 end and you have loose guidelines and we
47:01 want to see if the agent that
47:05 is taking control and delegating to
47:07 further agents did it right in the
47:09 context of those guidelines. Right. So
47:12 it is a loosely defined structure?
47:14 Yeah. (Microphone replacement)
48:21 Trying to build other
48:24 systems, you're welcome to do that. I'm
48:26 just saying that we can't solve the
48:28 problem that ACDC solves right now.
48:31 Whatever you're doing isn't solving that
48:32 problem because if you're
48:34 not using ACDCs to
48:36 solve it and you're not doing this, then
48:38 I know what you're not able to do. But
48:40 you can certainly do other things. Does
48:42 that make sense? I'm not prescribing for
48:44 you how you want to solve Agentic AI.
48:46 I'm just saying that if you want to
48:48 solve the act of modelling the authority
48:51 chain in a cryptographically verifiable
48:54 way and the elements of that chain
48:57 happen to be agents, it doesn't change
49:00 it doesn't change the mechanism. The
49:02 mechanism works just as well either way,
49:04 right? Yeah. (A question; waiting for the mic to arrive)
49:15 – The guardrail is that you want least privilege
49:18 built into the system so that
49:20 there isn't an opportunity for a
49:22 delegate to introduce more privilege
49:24 than what was delegated to him
49:26 originally.
49:27 And is the enforcement
49:29 mechanism on the shoulders of the
49:31 verifier (Yes!) or there's something intrinsic
49:33 in the structure that prevents that? No,
49:36 because the only person
49:38 that enforces it is the verifier.
49:40 Otherwise, what you're going to have to
49:41 have is a policy engine that the
49:44 verifier asks to enforce it for them.
49:47 Right. So, you've just moved the
49:49 enforcement someplace else, but it's but
49:51 it's still .. [the verifier's responsibility, red.]
49:53 – That's the part that I think a lot
49:55 of the industry will have difficulty
49:57 accepting.
49:58 Yeah, I'm I'm sure they will. And
50:00 Phil [Windley, red.], I think you're going to talk about
50:01 some of that, right? Or he's writing a
50:03 book on it. So, I'm talking to
50:06 you, Phil Windley.
50:12 I don't think he heard me. Hey, Phil. Phil.
50:13 Oh, he asked a question and I said,
50:16 "You're writing a book on Authorization
50:18 Policy for Agentic .."
50:23 Okay. All right. Later.
50:24 It's all right. I
50:25 – Sorry. What was the question? I
50:26 apologize.
50:27 Well, I just explained how
50:29 we could use ACDCs to do delegate
50:32 authority, and Ned [Smith] asked, "Well, least
50:35 privilege for the delegatee to
50:38 be able to do stuff. How do you enforce
50:39 that? And I said, right now
50:42 in a decentralized system, the
50:44 verifier can enforce it or you could
50:47 have a policy engine that the verifier
50:49 refers to, that enforces it,
50:51 but that's [your option, red.]
50:54 – Yeah so basically I think there are
50:57 two big avenues of how you would do this
51:00 with delegation. One is delegation as
51:03 data. The other one is delegation as
51:06 policy where you essentially write new
51:08 policies for the delegation
51:11 instead of relying on a broad set of
51:13 policies. in delegation as data ACDCs
51:17 especially with what you've described
51:19 today are really nice because you
51:23 can put all of the delegation in the
51:26 ACDC the credential and then, as
51:30 you've pointed out, you can keep that
51:32 from expanding, you can revoke it, you can
51:35 revoke the whole chain when necessary,
51:38 I think that's the
51:40 broad approach, right, as you write
51:42 policies that interpret the data in the
51:44 delegation credential.
51:46 Yeah. And to Ned's point, that's not how
51:48 most people do it now. So they may not
51:50 like it,
51:52 which is a valid point.
51:55 So I'm going to change topics for the
51:58 last five minutes.
52:00 The internet is a dangerous place.
52:04 What we want, what I would like, I hope
52:07 some of you want this, is a digital refuge
52:16 An online shelter,
52:19 an internet sanctuary,
52:22 a surveillance asylum.
52:25 Well, we're protected from all of these
52:27 things when we go online. When we use
52:29 the internet, we want to be able to use
52:31 the internet and be safe
52:40 If we think about those ..,
52:45 "Safe" is to require accountability of the participants.
52:54 If they're not accountable, it won't be
52:55 safe.
52:57 If you can act in any way you
53:00 want and there's no
53:01 repercussions, there's no consequences,
53:04 it's going to incentivize bad behavior.
53:06 And that's what the internet is. That's
53:08 what the internet is, it isn't a safe place because
53:10 there's no accountability on the
53:12 internet. It never came with it
53:14 in the first place. And everybody
53:16 assumed that well people will just act
53:18 the way they normally do. I have a
53:19 really good example of this. My
53:22 daughter who you all saw sing, right?
53:24 Yeah. She has a pretty substantial
53:26 internet presence, lots of followers,
53:29 and there's a lot of trolls that will go
53:31 onto her
53:33 Instagram or TikTok [and do]
53:37 all kinds of really horrible things.
53:40 Well, you know what my wife likes to do,
53:41 who you all met, is when they're do
53:44 really horrible things and they say
53:45 stuff like that occasionally, she will
53:48 go research them and they're always
53:50 using some, you know, alias. They think
53:53 they have anonymity. She'll go figure
53:55 out who they are and then she'll go ask
53:58 them, "Why did you say this about my
54:00 daughter?"
54:01 And they will SCRAMble for the hills.
54:05 It's just like, "Wait a minute. You know
54:06 who I am? You know that I said this
54:08 vulgar thing and sometimes they're just
54:11 average people in your neighborhood who
54:14 act like they don't do this. Well, why
54:15 do they do it on the internet? Because
54:17 they can get away with it. And
54:20 what she always likes to say to them is,
54:22 "So, if you met my daughter in person,
54:24 would you say that to her in person?"
54:26 When they go, "Of course not." Well,
54:27 then why do you say it online? And the
54:29 difference is there's no accountability
54:31 online. So, if you want safety, you have
54:33 to have accountability. Here's the other
54:35 thing that people don't don't believe me
54:37 when I say this. Privacy requires
54:39 accountability. People think privacy
54:41 requires being able to hide. You can't
54:44 have privacy if without accountability.
54:46 Here's why. Second parties to repeated
54:49 interactions can correlate the first
54:50 parties. If I interact with you, even
54:54 though we're both anonymous, the
54:55 interaction themselves is enough to
54:57 correlate.
55:04 So guess what? I can't interact and have privacy.
55:07 I can't.
55:09 So any interaction system that does not
55:12 enable first parties to hold second
55:14 parties accountable is fundamentally
55:16 incompatible with privacy.
55:18 You can't get there unless you start
55:20 with accountability.
55:22 And you don't get privacy by
55:24 hiding, you get privacy by interacting
55:27 with
55:33 digital refuges
55:34 Surveillance asylums where the
55:37 participants
55:39 hold each other accountable and you can
55:41 trust that they'll act in the way you
55:42 want and everybody else is excluded.
55:45 That's the whole point. If I want to
55:47 interact with him or her, right, and I
55:51 can hold him accountable, then I have a
55:53 trusted interaction. If I can't hold
55:55 them accountable, I can't trust it. But
55:58 what I want to do is I want to have that
55:59 interaction and not have anybody else
56:02 surveil it.
56:04 And that's what we really
56:06 want. We want contextualized
56:09 confidentiality with accountability. And
56:11 how do we do that? Well, there's a
56:14 protocol called the Trust Spanning
56:15 Protocol that, combined with the KERI
56:17 Suite, allows us to create and control
56:20 safe relationships where interactions
56:22 protected from surveillance by third
56:24 parties and second parties are held
56:26 accountable for any information shared
56:28 with or by them.
56:31 My breakout talk today will be
56:36 talking about the TSP protocol
56:39 and how we can do that.
56:43 Keep going.
56:43 We only got a minute.
56:49 Okay.
56:49 You can have some of my time.
56:51 All right.
56:54 Okay. So when I do this analysis, I
56:58 always use this model.
56:59 They say "All models are wrong,
57:01 but some models are useful." I find this
57:03 a very useful model. Any
57:06 interaction on the internet involves the
57:08 first party and second party.
57:11 I can encrypt the communications between
57:14 the first party and the second party
57:17 so that the content isn't observable by
57:19 any other party.
57:21 But if I'm using the internet, what I
57:24 can't protect is the metadata of the
57:27 fact that I sent data over the internet.
57:29 It has to be routable.
57:32 Routing tables are public. Routing
57:35 information is subpoenable.
57:37 All of that metadata is not protected.
57:40 The Supreme Court even said so. Right?
57:43 Reasonable expectation of privacy is
57:45 limited to content,
57:49 not non-content metadata. Non-content
57:53 metadata is how you get from first party
57:55 to second party. If I
58:00 can correlate out from the metadata who
58:04 the first party and second party are,
58:06 I've already defeated privacy in
58:08 general. There's no privacy on the
58:10 internet ever. Never has been, never
58:13 will be. If you use that definition,
58:16 right? But what I can do is I have
58:19 privacy where I can make it so that
58:22 I that they don't know who the first
58:24 party and the second party are because
58:26 the first party and second party they
58:28 see aren't the first party and second
58:29 party that matter.
58:31 And so the basic idea is: I don't use
58:35 clandestine means to get privacy. I use
58:38 covert means
58:40 and covert means you have a cover
58:43 identity that basically
58:46 provides a layer of protection to some
58:49 activity that you're doing that isn't
58:51 observable. Clandestine just means
58:53 you're not observable. But any
58:57 information that's broadcast, is
58:59 eventually observable. So clandestine
59:02 can only be used for ephemeral
59:03 applications. And I spent 20 years and
59:06 20, you know, millions of dollars of
59:10 federal money building clandestine
59:15 surveillance mechanisms
59:19 and at some point we said, "Oh, we
59:23 got to make them covert because we
59:25 need Persistent Lliteral
59:30 Surveillance;" that was the name of the
59:31 program. And when we went from ephemeral
59:34 to persistent surveillance, we had to
59:37 change our concept of operations.
59:40 And that's what I'm saying is we have to
59:41 change that. So this is the model. And
59:44 then and to get from first party, second
59:45 party, I have to have intermediaries.
59:47 The intermediaries
59:49 can surveil stuff that a third party
59:51 can't. Your ISP is an intermediary.
59:55 So given that model, these are the
59:58 two principles that we use. One is
1:00:01 end-to-end verifiability which tells me that
1:00:03 I know who the parties are. The parties
1:00:06 know each other.
1:00:09 If I have KERI then I get ambient
1:00:11 verifiability any day anywhere anytime
1:00:14 by anybody of who it came from. So I
1:00:16 can hold the source accountable
1:00:19 right; non-repudiation.
1:00:23 Now the dual of that, is what I
1:00:25 call 'Only At End Viewability'. I need to
1:00:28 be able to send information to somebody
1:00:31 and have reasonable confidence that
1:00:33 they're the only ones that got it.
1:00:36 Because the only way I can hold the
1:00:37 second party accountable is if I know
1:00:40 they're the leaker of data.
1:00:42 Because if I send encrypted data to a
1:00:45 second party that they can decrypt, they
1:00:47 have the data. I no longer have any
1:00:50 ability to restrict where that data
1:00:52 goes. There's no technological means
1:00:54 that allows me to protect that
1:00:56 data once the second party has it. I
1:00:58 have to trust the second party. So I
1:01:00 have no privacy of any information I
1:01:02 share with the second party if the
1:01:04 second party can share it with somebody
1:01:05 else. So there's no longer technology
1:01:08 here. It's all legal, regulatory, and
1:01:11 economic.
1:01:13 So if any information that I interact
1:01:16 with or share in the internet once it
1:01:18 gets to the second party the second
1:01:19 party wants to collude with anybody they
1:01:21 want to then I have no privacy.
1:01:24 The only privacy only comes if I can
1:01:26 trust the second party to respect
1:01:29 the terms and conditions, which is
1:01:31 called confidentiality, of the
1:01:33 information I give them. So what I need
1:01:36 is a mechanism for sending information
1:01:39 from here to there
1:01:41 that is asymmetric. So I need to use
1:01:43 hybrid public key encryption so that I
1:01:45 have asymmetric encryption and I send it
1:01:48 to one end. I don't use group
1:01:50 encryption. I don't do shared
1:01:53 secret encryption. I use hybrid
1:01:57 public key which is technically shared
1:01:59 secret encryption but the
1:02:01 key on my end is ephemeral. So I have a
1:02:04 reasonable confidence that only the
1:02:06 targeted one got it and I can in
1:02:08 include information in it that makes it
1:02:10 unique to that end which they can get
1:02:12 rid of if they if they're smart but it
1:02:14 makes it really hard for them. So I said
1:02:16 reasonable confidence. What that means
1:02:18 is that I have this property of End Only
1:02:20 Viewability. The end that I intend to is
1:02:23 the only one that can view it. So
1:02:25 there's "one data, one where, one time, by
1:02:27 one body," and that means that it's
1:02:30 undeniable. Now they can deny it.
1:02:33 Plausible deniability.
1:02:35 I can't prove, may not be able to prove
1:02:38 it, but I know. And guess what I do when
1:02:41 I know? I break the interaction. I
1:02:44 exclude them from my interaction
1:02:46 profile. I stop talking to them. I stop
1:02:48 sharing data with them because I can't
1:02:49 trust them. So the whole point is: I need
1:02:52 to be able to control who I talk to and
1:02:55 who talks to me. And I need to do it in
1:02:57 a mechanism that allows me to decide
1:02:59 that and to control the
1:03:02 boundaries of that. And that's the way I
1:03:03 do it. And so the TSP protocol
1:03:06 lets you decide with whom they interact,
1:03:10 what they share and why. And so you have
1:03:13 control over your internet presence and
1:03:15 your context when you do this. And we
1:03:18 use relationships graphs. And this
1:03:20 is actually
1:03:23 into my talk for this afternoon. So,
1:03:25 I'll stop there.
1:03:27 Great. Thank you.