0:00 Alan Davies ｜ ACDCs for Enterprises ｜ KERI Conference 2026
0:03 … and thank you all for being here. So,
0:05 I've been accused many times in the
0:08 past of oversimplifying. I can say
0:11 here and now that I never oversimplify.
0:15 However I do like to simplify
0:19 things and the world out there needs to
0:26 understand what KERI and ACDCs can
0:30 deliver to the world and we need to
0:33 find ways of simplifying our messages to
0:37 them to make sure that they get it.
0:42 I thank Thomas [Mayfield, red.] for his great
0:46 presentation explaining in high-level
0:49 terms what KERI is all about and then
0:51 diving into the lower level detail and
0:54 I'm going to a certain extent
0:58 follow that track.
1:00 Let's get going.
1:03 I want to start by talking about how
1:06 trust used to work.
1:09 It used to be
1:12 all about personal reputation. This
1:14 in the days when you wanted to carry out
1:17 some kind of transaction, buy something,
1:19 you would go along to the person who was
1:21 selling it or providing it. You would
1:24 talk to them, you would make a deal, you
1:25 shake hands and you would decide
1:30 whether you're trusting them or not. If
1:31 you trusted them, you would give them
1:33 their money. They would give you the
1:34 goods and off you went. And so trust
1:39 depended on physical presence.
1:44 All of the verifications that took place
1:47 were pretty well immediate and you
1:50 would decide do I really trust this
1:52 person? If so here's your
1:56 money. I'll take the goods now or
1:59 maybe later.
2:03 Fraud did exist. Of course there would
2:05 be people who would promise to do
2:06 something and then not deliver it but
2:10 the scale was limited to I guess the
2:12 person that they were they were doing
2:14 the deal with.
2:18 So that was in the distant past. Now
2:21 things have changed and in fact they
2:22 changed at least a couple of hundred
2:26 years ago when the ability to
2:29 communicate in different ways came
2:31 along.
2:34 But it they changed in a very big way
2:37 when global communications arrived
2:41 firstly with the telephone and then
2:44 Fax machines and of course now
2:49 the internet.
2:55 What the internet enabled us to be able
2:57 to do is execute transactions remotely
2:59 which is a great thing in many ways.
3:03 It enabled international commerce to
3:06 be able to scale up in so many
3:08 different ways and also allow regular
3:11 humans to participate in that
3:14 kind of commerce. We can go
3:16 online to Amazon, we can buy what we
3:17 want when we want and it turns up the
3:19 next day. It's very convenient.
3:23 In order to support that, when the
3:26 internet came along, it was a almost a
3:29 natural knee-jerk reaction to say, well,
3:31 if people are going to use online
3:33 systems, they need to authenticate to
3:37 be able to access it. And usernames and
3:39 passwords was the way that we did that.
3:42 So you log in, you get a session
3:45 token and the system that
3:48 you're talking to uses that token to
3:49 decide what you're allowed to do.
3:54 The end result so far has been rampant
3:58 online fraud and we've done what we can
4:02 to limit that. Mostly by trying to
4:08 detect fraud which is in my view a
4:13 losing battle. The fraudsters have so
4:18 many tools available to them to be able
4:20 to fool the general public into
4:23 thinking that they are someone
4:26 legitimate.
4:28 and detection is we're always going to
4:31 be losing that battle to try and detect
4:33 fraudulent activity.
4:39 This is my own
4:42 personal view of the distant future in
4:45 which everything that we do will be
4:50 signed. So, it's a signed intent
4:53 world
4:55 and I think the way we'll end up if you
4:57 think maybe four or five years in the
4:59 future
5:00 We will all have an agent on our
5:04 devices that does things for us.
5:08 You'll ask your agent AI agent to do
5:10 something. It'll be maybe move some
5:13 money from your checking account to your
5:15 savings account.
5:22 the AI agent on your device because it
5:23 knows you've authenticated with that
5:24 device biometrically. It'll wrap
5:28 that request in an ACDC,
5:31 sign it with your private key.
5:37 It'll just use your face ID or whatever
5:39 other biometric it's using to make sure
5:41 it really is you.
5:43 It may add additional signatures if
5:47 necessary. So if you're a child
5:50 using your device, it may be that
5:52 whatever you're asking your agent
5:55 to do requires your parents permission.
5:57 So, you may get an additional signature
5:59 added to that request.
6:03 That request may include relevant
6:06 credentials, your SEDI credential for
6:08 example, or who knows what other
6:10 entitlement credentials that
6:12 you may have.
6:15 That request will then get sent to some
6:17 kind of execution service. If it's your
6:19 bank, because you're moving money from
6:20 one account to another, then it'll be
6:22 your bank's online system.
6:25 It'll verify the trustability of that
6:28 request. It'll see where it came
6:31 from. It will see your signature. It
6:35 will see your maybe your parents
6:36 signature if you're a child. It will
6:40 do the usual KERI ACDC stuff.
6:43 Verify it hasn't been tampered with.
6:45 They it they know it's you and the bank
6:48 will then execute that request and make
6:50 a record of it. And
6:54 I don't think there will be a need to
6:56 have a username and password. You won't
6:58 need to login for this because basically
7:00 you've sent a signed sealed
7:03 request to your bank that they know it
7:05 came from you. They'll execute it.
7:07 They'll record it and that's the end of it.
7:12 I'm exaggerating here. I'm sure there
7:14 will be passwords, sessions tokens, and
7:16 2FA for all sorts of stuff, but in
7:20 the long term, they will be at least
7:23 less necessary. And in the example I
7:25 gave you, you can imagine a world where
7:28 everything you do is signed intent.
7:36 I think that this is going to be how we
7:42 reduce the rampant online fraud to ..,
7:44 there's always going to be fraud,
7:46 unfortunately, there always going
7:48 to be someone who will find a way of
7:50 fooling someone else into doing
7:52 something they shouldn't be doing.
7:55 But this is the long-term vision and
7:57 this is all going to be delivered,
8:01 in my view, with implementations of
8:04 KERI and ACDCs,
8:06 and everything that we've been talking
8:07 about today.
8:10 However, there's going to be a lot of disruption
8:14 to be able to enable all of that. I mean
8:18 the example I gave you about the bank
8:21 they need to rearchitect their systems
8:23 so that they are accepting
8:25 signed requests from their customers
8:30 that they identify through their
8:35 their online identity
8:37 that the customers own and that's
8:40 going to be a great world of course
8:42 everybody will be their own identity
8:44 provider which is how it should be if
8:47 you think about it. I'm the only
8:50 person who knows that I am me. And if I
8:54 control a digital identity that
8:58 asserts that, then I'm by far the best
9:01 person to be able to prove who I am.
9:04 And I don't like the idea of delegating
9:07 that to some
9:11 other federated identity provider.
9:14 However, they're not going to like it at
9:16 all. The federated identity
9:20 providers are having lots of information
9:22 from people every time they log in. So,
9:25 there's going to be a lot of resistance.
9:28 Information harvesters are going to
9:32 hate all of this because everything that
9:36 Sam [Smith, red.] tells us that we should be in
9:38 control of is not what they want us to
9:41 be in control of, sadly.
9:43 As I mentioned, all sorts of online
9:47 services will need to do a lot of
9:50 rearchitecting to implement that final
9:52 vision.
9:55 And this isn't going to happen in the
9:57 next 12 months.
9:59 There will be movement towards it but
10:02 In my view, we need to
10:06 do something sooner to start
10:10 getting KERI and ACDC adoption in a
10:13 small way and then move on. So this is
10:17 where we are now. We have rampant online
10:21 fraud.
10:23 Autonomous AI agents are doing more
10:26 and more stuff and working out how to do
10:29 things on their own.
10:32 Mostly because they think that they are
10:35 doing what we want them to do but not
10:38 necessarily.
10:41 The current way of recording what
10:44 happens is really online logging. So the
10:48 the bank will keep a record of what you
10:51 asked it to do moving money from one
10:53 account to another. But if someone
10:57 gets my password and asks my bank to do
11:00 something on behalf of me then as far as
11:02 the bank logging is concerned it was me
11:04 doing it which just is not real. So it
11:08 is it's just weak.
11:11 So what we really need is what I call
11:14 trustability.
11:16 And trustability is the ability to
11:21 be able to make a good trust decision
11:26 on any kind of action that you might be
11:30 Intending to make based on some
11:32 information that comes at you over the
11:35 internet. And it can be something as
11:38 simple as a news article.
11:43 Did this journalist really write this?
11:46 Do I trust this journalist? The trust
11:48 decision might be very weak. I'm just
11:50 going to develop my own opinion
11:53 about whatever is being written about
11:55 based on based on that journalist's
11:59 reputation. But
12:02 other things are much more important.
12:05 If I see a request from one of
12:11 my kids to send some money to a bank
12:14 account because he's in trouble, then I
12:17 need to be able to trust that is
12:19 really from my son. And I need to
12:22 make a trust decision. I might need to
12:23 make it quickly. So how do we
12:27 get trustability into the world of
12:31 online transactions?
12:33 And what we need of course is KERI and
12:36 ACDCs and we need .., I hate to say
12:40 "a little bit of KERI and ACDC" because we
12:42 need the whole thing but we
12:45 can't very quickly implement the
12:49 entire or reimplement the entire online
12:52 access infrastructure to support the
12:55 the long-term vision of how the whole
12:59 world of signed intent is going to
13:02 work.
13:07 And
13:08 where digital trust foundry is
13:10 starting, is saying that what we
13:13 need is something that we call execution
13:16 trust.
13:18 Immediately before making some kind of
13:21 Decision to execute some kind of
13:24 action based on information that's
13:26 coming to us remotely. And that might
13:30 be we're a supplier receiving a
13:33 purchase order. We might be an employer
13:38 being presented with someone's
13:40 academic credentials before we hire them
13:42 for a job. Before we make that
13:46 decision, then
13:49 we need a way to be able to make
13:53 a trust assessment of what's being
13:55 presented to us.
13:59 And
14:00 this is where I think that what the
14:02 world needs is to be able to start
14:05 slowly and to be able to implement
14:09 what we call execution trust into
14:11 existing systems and of course start
14:14 with high value high-risk transactions.
14:17 For example wire transfer fraud. It
14:22 is way too easy for bad actors to be
14:26 able to make changes to wire transfer
14:29 requests as they move from place to face
14:31 before they get to the bank
14:34 that's going to execute that wire
14:35 transfer.
14:38 Taking a wire transfer request, wrapping
14:43 it in an ACDC, getting it signed by
14:48 the owner of the originating
14:52 account
14:53 means that when the bank gets it, they
14:55 can verify it, make a trust decision and
14:58 execute it and then keep a
15:01 cryptographically verifiable record of
15:05 what they were asked to execute for
15:07 any time in the future.
15:11 So what we're talking about is inserting
15:13 a level of trustability into existing
15:16 applications at execution time, hence
15:19 the term execution trust.
15:22 And this can apply to any digital
15:24 artifact. Verifiable
15:27 credentials was really all about
15:30 academic and professional credentials
15:33 but ACDCs are really capable of
15:37 handling any kind of data content that
15:39 might be delivered from one trust domain
15:42 to another.
15:44 Even better in the short term, it makes
15:50 sense even with a single trust domain to
15:54 be able to take some kind of
15:58 action. Let's say, it's updating a
16:03 production system. We have an
16:07 update that we want to make to a
16:08 production system and we want to make
16:11 sure that it's fully authorized before
16:14 we execute it. And of course,
16:16 that update may have been
16:18 generated by AI. So it's kind of
16:20 important that a human gets involved in
16:23 that process. A workflow
16:27 application that's going to apply that
16:29 update to the production system could
16:31 take that description of that update
16:35 request, wrap it in an ACDC, send it to
16:38 the CIO to say, "We're about to
16:41 update your production systems with
16:43 this. Do you approve it?" He would sign
16:46 it, return it back. Then that
16:50 update application would say " Okay, I have
16:52 approval to go ahead with
16:54 with this update, apply the update, keep a
16:57 record" and that all happens within a
16:59 single trust domain. What you've
17:01 done there is applied a little bit of
17:04 KERI and ACDCs to a particular high
17:07 value use case to make sure that
17:12 in that particular example the update
17:15 was being made was fully authorized
17:18 by someone who is the appropriate
17:23 authorizer of that update.
17:26 The same thing applies
17:29 across trust domains where maybe a
17:32 business generates a legal document that
17:35 needs to be signed by the CEO before it
17:36 gets delivered to a partner for them to
17:40 execute. You can build that kind of
17:43 functionality into an existing
17:46 application that's already generating
17:47 these documents. You just say, "Well, we
17:49 already have the document. It's a PDF.
17:51 We're just going to wrap it in ACDC,
17:53 get it signed, and send it off. And then
17:55 whoever gets it, because they know how
17:57 to verify an ACDC, we'll run a
18:00 verification. They know that it was
18:01 signed by the CEO, they can act on it.
18:09 I think that's basically what I'm
18:10 talking about here. And of course,
18:12 multisig comes in very useful in
18:14 situations like this.
18:21 The application at execution time can
18:23 verify and either decide to reject it if
18:25 it's not happy with what it sees or
18:27 executed and keep a permanent record of
18:33 its trust decision and what it made that
18:37 trust decision based on.
18:40 The benefits of this approach
18:43 which is a little bit of KERI and
18:46 ACDCs injected into existing business
18:49 applications for high value
18:50 transactions.
18:52 There are so many business use cases
18:55 that this can apply to across all
18:57 industries.
19:03 I know from personal experience that if
19:05 I use my bank's online system to do a
19:06 wire transfer even though I'm logged
19:09 in, it'll get to a certain point where
19:11 it says " We're going to send you a
19:14 code to your mobile phone and want
19:16 you to type it in. So, two-factor
19:18 authentication to make sure that even
19:21 though I'm already logged in that it
19:23 really is me again, sort of really me.
19:27 This would replace those kinds
19:30 of weak two-factor authentication with
19:33 what we call a hard gate.
19:40 There will be no need to rearchitect
19:42 existing systems. If you take for
19:43 example the bank's wire transfer
19:46 request system, they already have that
19:50 ability in their system. It's part is
19:53 the functionality of their banking
19:55 system anyway. The additional step
19:58 would be just to make an API call to
20:03 a platform that knows how to wrap that
20:06 content into an ACDC, send it to an
20:10 authorized signer, and return the signed
20:13 ACDC back. Then that application just
20:16 makes another API call to verify it,
20:19 looks at the results, makes a trust
20:21 decision, either rejects or
20:23 continues. No need to completely
20:25 rearchitect existing systems.
20:30 This will drastically reduce online
20:33 fraud for high value business
20:35 transactions and it can be done really
20:38 very soon.
20:41 I like to talk about this as
20:44 getting used to KERI and ACDCs one
20:47 bite at a time. So you introduce
20:50 something like this to a high value
20:53 transaction that's already being
20:55 executed by business applications
20:58 Today and they see the immediate
21:01 benefits and then once businesses start
21:05 using this technology in this limited
21:09 constrained way then they will be able
21:11 to see how that the basic technology can
21:14 be applied in all sorts of other
21:16 situations. And this is how we get the
21:18 world starting to use KERI and ACDCs
21:21 without having to make huge changes.
21:27 And also this is another good reason
21:30 for businesses to get a vLEI of course.
21:35 Digital Trust Foundry is a platform that
21:42 enables businesses to do exactly what
21:43 I've described. It's multi-instance
21:46 multi-tenant platform that fully
21:49 implements KERI and ACDCs with our
21:53 witnesses and watchers network.
21:58 (let me see if I'm getting ahead of
22:00 myself here)
22:02 We've implemented what we call a
22:04 trustables API. So the business
22:08 application can say "I have some digital
22:11 content that I want to make trustable."
22:14 It makes a call to the API
22:17 specifying the AIDs of the signers or
22:21 the roles that need to approve whatever
22:25 the digital artifact is that's being
22:28 processed.
22:31 The end result is, it gets back an
22:33 ACDC that it can verify
22:37 and that's where we're
22:39 starting. We're saying that we
22:42 need to provide what we call
22:46 execution trust to existing applications
22:49 so that they can start using the
22:52 power of KERI and ACDCs now in a
22:55 small way but then to see understand
22:59 the value of it by practical experience.
23:07 We're looking for partners. Our
23:10 business model is "Yes, we will deliver
23:13 our a platform" for use by
23:17 businesses generally but also by
23:19 partners who have existing applications.
23:23 It might be workflow applications
23:24 that need stronger approval processes
23:28 for example. And they can work
23:33 with us to build execution trust
23:36 functionality into their applications
23:38 and deliver it to their customers. So in
23:41 this way we build a network of
23:45 businesses who are implementing the
23:49 power of ACDCs and KERI without
23:52 having to build the whole thing
23:53 themselves. They just make use of our
23:56 platform. So in some ways it's similar
23:58 to if you're a business wanting to
24:03 Manage your sales process, you can
24:07 either use spreadsheets and build
24:11 your own application to manage all of
24:14 your sales processes or you can go to
24:16 Salesforce and sign up for a CRM with
24:20 them. they provide the functionality all
24:23 of the low-level detail and you just
24:25 get the benefits.
24:30 We have a list of interactive
24:34 examples of our functionality that
24:38 you can go and play with and just
24:43 to give you some ideas of the sorts of
24:45 things that can be done with that.
24:46 There's about 30 different use cases in
24:49 different businesses. One of my
24:51 favorites is verifiable résumés in
24:56 which an individual who's collected
24:59 digital credentials or professional
25:01 credentials can actually take them
25:04 all and generate a verifiable resume
25:08 that has references to all of each of
25:10 those credentials. and they can provide
25:13 their digital verifiable resume to a
25:16 potential employer who can actually
25:19 click verify on that resume. It will go
25:22 to the issuers of each of those
25:25 credentials, verify them and then return
25:27 a trust report to the employer.
25:32 That's all I have to say for now.
25:34 Thank you very much for your time and if
25:36 you have any questions now is the
25:38 time.
25:47 – I got one question because of the term
25:49 that you coined "trustability."
25:52 I use that in a promotion on
25:56 LinkedIn and it got a red
26:00 dotted line under it. It doesn't exist
26:02 in my translation. So it got
26:04 trustworthiness.
26:06 I heard your
26:10 explanation of trustability but
26:13 could we use the word trustworthiness
26:15 as well in your…
26:16 Of course, yes.
26:19 The ability to be able to make a trust
26:22 decision on something is my definition
26:26 of trustability which may not be a real
26:28 word. But I think it should be.
26:32 We're making trust decisions all
26:34 of the while. But when I receive some
26:39 kind of digital information over the
26:41 internet that I want to make a trust
26:44 decision on then I have, at the moment,
26:49 only two choices. One's called blind
26:51 faith. Well, there's three actually.
26:54 Blind faith. The one is ignore it
26:57 completely. And the third is spend quite
27:00 a lot of time doing some kind of
27:02 verification manually to decide whether
27:05 this is genuine or not. If it's an
27:08 email coming over from me, I look to see
27:10 where it actually came from, for
27:11 example. If you can trust that.
27:16 About a week ago, my wife had a phone
27:19 call from the Bank of America saying
27:22 that they noticed that someone is trying to
27:28 initiate a wire transfer from our
27:31 checking account. They said we
27:36 we can help you fix this.
27:39 They sounded very genuine and
27:42 they said this is my name and if
27:45 you go to the Bank of America's website
27:48 go to a particular branch and you scroll
27:50 down you'll see a picture of me and
27:53 you'll see my phone number and if you
27:55 look that the phone that I'm calling
27:57 from is in fact that phone number. So
27:59 this is me. my wife said, "Mmm,
28:03 well, I'm going to call you back
28:04 anyway." And that was the
28:07 last we heard of them, except we called
28:08 back and spoke to somebody completely
28:10 different.
28:13 We could have
28:16 got caught out very easily. Because
28:20 lots of people assume that if it says
28:23 that phone number and they prove that
28:25 the real person
28:28 controls that phone number that's where
28:29 it came from. Thankfully, we have
28:32 Provenant who is solving that problem for
28:34 us using KERI and ACDCs but for now
28:37 we're in the world where we have to make
28:40 either blind faith, ignore it or
28:43 spend some time doing verification and
28:46 and that's how we get caught.
28:49 Implementing
28:52 execution-time trustability is
28:57 where we think things should start.
29:01 Thank you. Any other question?
29:05 If not, then thank you very much, Alan, for
29:08 your presentation.