0:00 Daniel Hardman ｜ Open Verifiable Communications ｜ KERI Conference 2026
0:03 - Daniel, you will introduce yourself?
0:05 Sure.
0:07 I'm Daniel Hardman and I'm the
0:09 CTO of company called Provenant.
0:12 You've heard a couple of
0:15 references to work that we're doing in
0:17 telco. And I'm here to explain a little
0:19 bit more about that.
0:25 All of us have been impacted by scamming
0:28 in telco. Usually a day doesn't go
0:32 by that I don't get some kind of a
0:34 message. This morning it was
0:37 somebody running for Congress in some
0:39 state that I've never lived in telling
0:40 me how important it was that I donate $3
0:42 to his campaign. But all of us get these
0:45 kinds of things. And many of us who
0:49 work in cyber security sensitive areas
0:52 are pretty well aware of how scammy
0:56 and fraudulent a lot of it is.
0:58 Even people who don't know anything
1:00 about tech know that this is scammy and
1:02 and full of fraud to the point where
1:05 this is the answer they're coming up
1:07 with. Just don't answer your phone,
1:10 right? Or just stop sending texts.
1:14 That's actually a pretty bad indictment
1:16 of a technical infrastructure when
1:20 the best advice we can give is just stop
1:22 using it.
1:24 But that's kind of the state of affairs
1:26 right now. And that constitutes an
1:30 existential threat for an entire
1:32 market vertical.
1:35 There are billion-dollar companies
1:38 that make their money off of phone
1:41 calls
1:42 or make their money off of texting.
1:45 And so if you have entire influential
1:51 voices, segments in an industry that are
1:53 saying just stop using that tech
1:54 entirely, there's panic going on.
2:01 Microsoft is an interesting example
2:03 of this and so I'm going to use them
2:05 because I know some details about their
2:07 world. One of the common scams is
2:12 maybe you've had a grandparent who says,
2:14 "Oh, I got a call from Microsoft tech
2:16 support."
2:18 The reason that scam is
2:21 dangerous is because Microsoft does have
2:23 a tech support staff and they do
2:25 sometimes call people. They don't
2:28 spontaneously call people, which is the
2:29 way the scam usually works. But if a
2:32 person calls Microsoft tech support and
2:34 they get disconnected,
2:36 Or if they call and they have the
2:38 end of the current conversation, but
2:40 there needs to be follow-up, Microsoft
2:42 does call people.
2:44 The problem is people don't want to
2:46 answer.
2:48 And that's a serious pain point for
2:51 Microsoft.
2:53 And regulators are getting involved
2:56 in this now because Microsoft has
3:00 another characteristic that's kind of
3:02 complicated that would be true of
3:03 anybody who's a giant global
3:05 conglomerate, which is they put their
3:07 people in the most strategic places they
3:09 can for cost reasons and so forth. So
3:13 particular case in point in the UK
3:17 Microsoft has plenty of customers
3:19 that they interact with but Microsoft
3:22 doesn't put their call center staff in
3:24 the UK. They put their call center staff
3:27 in Bulgaria or some other lowcost
3:30 center that can you know make a cheap
3:32 call into the UK. But Ofcom, which is
3:35 the equivalent of the FCC in the UK
3:39 has some problems with that because they
3:41 don't want a phone call to be
3:44 claiming that it's coming from the UK
3:46 and from Microsoft when it's coming
3:49 from Bulgaria.
3:51 And so they have said, you may not
3:55 attribute this phone call to a UK
3:58 number unless you can prove it.
4:01 You have to prove that it's really
4:03 coming from Microsoft
4:05 and this is creating a lot of pain for
4:09 Microsoft.
4:11 So what Microsoft wants is a
4:16 transformation of the customer
4:18 experience from the phone on the left to
4:21 the phone on the right. They'd like it
4:24 to be the case that when the phone
4:25 rings, it shows the Microsoft logo. It
4:29 shows the Microsoft name
4:31 and it shows why they're calling. Oh,
4:34 they're calling because they're customer
4:36 support representative and they want to
4:38 be able to prove it.
4:41 It's not hard to make a phone show
4:44 logos.
4:45 What's hard is to be able to prove why
4:48 you're showing the logo.
4:50 And this is the requirement that
4:51 Microsoft has.
4:56 So, what I'm here to talk about
5:00 what I'm here to talk about
5:00 is .., I'm just going to let this narrator
5:02 take over for a minute and we'll watch
5:03 this demo. This was presented at
5:07 Mobile World Congress about a month
5:09 ago,
5:11 […] a three person consultancy who wish to
5:13 make outbound calls to their customers.
5:17 We then move to a larger organization,
5:19 Microsoft. Their outbound contact
5:22 centers need to be able to make calls to
5:23 customers, but increasingly find that
5:25 their calls are impacted by incountry
5:27 regulation, get spam marked or simply not
5:30 answered because customers do not know
5:32 it's Microsoft calling.
5:35 What you will see looks like a branded
5:37 call. However, it is a little bit
5:39 different. With OVC, the information
5:42 displayed on the handset is based on a
5:44 set of credentials which prove certain
5:46 things about the origin of the call.
5:49 They prove that Microsoft has the right
5:51 to the telephone number that is being
5:53 displayed, that it is Microsoft
5:55 Corporation that is calling you, linked
5:57 back to the Axel legal entity
5:59 responsible for the call using a
6:01 globally unique legal identifier, and
6:04 that they have the right to use the
6:05 brand that is being displayed to you.
6:07 These credentials have all been issued
6:09 to Microsoft and are in their control.
6:12 Microsoft could use these three
6:14 credentials to originate calls
6:16 themselves, but there is a fourth
6:18 credential which allows Microsoft to
6:19 delegate the right to sign on their
6:21 behalf to another platform. For the
6:24 project, we've worked with Infobip,
6:26 Twilio, and Vonage as platforms that
6:28 could be used to sign traffic on behalf
6:30 of an enterprise and they do not wish to
6:32 make their own calls.
6:35 The call you see will leave the platform
6:36 onto a network where it will be verified
6:38 by a transit operator before it has
6:41 arrived at the handset and the outcome of the
6:44 verification is displayed. Let's go and
6:46 make a call. For this example, we're
6:49 going to make a call from Infobip.
6:53 We are logged in as Microsoft and we'll
6:54 send a call from this US telephone
6:56 number which has been allocated to them.
6:59 We will call this Spanish number which
7:00 is a prepaid SIM we bought in Spain for
7:02 the demonstration and is in the handset
7:05 which is mirrored to the right. Let's go
7:07 ahead and make a call.
7:13 You can see here the name, telephone
7:16 number and brand along with a verified
7:19 tick are displayed.
7:21 These are displayed based on a
7:23 successful verification of the evidence
7:25 provided in the communication.
7:28 What we'll do next is have a look at the
7:29 governance model that underpins this
7:31 evidence.
7:35 One of the biggest challenges with
7:36 global verifiable communications is
7:38 ensuring there is thorough and
7:40 consistent vetting of original parties
7:42 that can work in many different
7:43 circumstances.
7:45 OVC has a rich governance model and
7:48 provable chain of evidence to support
7:50 this. It starts with a local governance
7:52 authority that sets the vetting
7:55 standards for OVC.
7:57 We next have policy administrators who
8:00 appointed by the government's authority
8:02 to apply these vetting standards in a
8:04 given jurisdiction. It's important as
8:07 there are many differences of
8:08 regulations and vetting processes in
8:10 different countries. They're responsible
8:12 for certifying vetting agents to be able
8:14 to vet in these jurisdictions for
8:16 different communications channels.
8:19 Once credentials been issued to vetting
8:21 agents, they're able to vet enterprises
8:23 in specific regions and for specific
8:25 communications channels. In the trial,
8:28 we've had brand numerical and [inaudible]
8:30 enterprises.
8:33 The vetting agents verify enterprises to
8:35 prove rights to telephone numbers, that
8:38 they are the legal entity they say they
8:40 are, and that they have the rights to
8:42 use the brand, and then issue the
8:44 enterprises with appropriate
8:45 credentials. This process can support
8:48 support both small businesses and large
8:50 corporations.
8:52 It's important to note that these
8:53 credentials are chained all the way back
8:55 to the governance authority providing a
8:57 provable chain of trust. It is also
9:00 means that it's possible for credentials
9:02 to be revoked at any point in the chain.
9:04 So if for example a vetter does not follow
9:06 the rules and vets bad actors, it's
9:08 possible for a policy administrator to
9:10 revoke their credential and have a
9:12 cascade impact on the credential set
9:14 issue.
9:16 The credentials are held in wallets by
9:17 enterprises to whom they have been
9:19 issued. While the focus of the
9:21 demonstration has been on voice, these
9:23 credentials can also prove other
9:25 communication channels such as RCS, SMS
9:28 or APIs. The final credential which can
9:31 be created if needed is a delegated signed
9:34 credential which we discussed earlier.
9:36 What we'll look at now is how the
9:38 evidence looks for a real call.
9:46 First, we're going to make another call,
9:48 but this time from another one. One of
9:49 the credentials has been removed by
9:51 Microsoft.
9:55 We will call the same number.
10:00 As you can see, in this instance, the
10:02 call fails. This is because the transit
10:04 operator verifying the network attempted
10:06 to verify the call and found that one of
10:08 the credentials had been revoked and
10:10 therefore rejected the call.
10:13 We will now go and look at the evidence
10:14 detail for this call.
10:19 We can see the call here. Evidence
10:21 detail records refer back to the
10:23 evidence and provide a permanent record
10:25 of the evidence accompanying the call.
10:30 We can see the three credentials here.
10:32 The identity credential, the TN
10:35 credential, and the brand credential.
10:38 And we can see here that the TN
10:39 credential has been revoked.
10:42 We can also look into the evidence in
10:44 more detail and see who has vetted
10:47 Microsoft. In this case, it was Aegis
10:50 and even how they gained their authority
10:52 to be a vetter. We can also then see the
10:55 policy administrator and the
10:57 government's authority for the trial.
10:59 These were just placeholders.
11:02 We'll now move on to look at the actual
11:03 call flow for the call that you've seen.
11:16 We started with a set of credentials
11:17 that have been issued to the enterprise
11:19 and delegated to an originator so they
11:22 can make calls on their behalf.
11:25 When the call is made, the originator
11:28 calls out to a signing service from
11:29 Provenant, the technology provider for
11:32 this project. The service returns a
11:34 compact passport, a STIR passport and
11:38 also replicates this passport from
11:39 out-of-band cache. The passport is not a
11:42 shaken passport but a verifiable voice
11:45 protocol passport.
11:48 Once signed, the originating party sends
11:50 the phone onto the PSTN.
11:53 Here it is received by transit
11:55 operator Wavecrest, it takes the passport
11:58 and uses a verification service to
12:00 verify the pool. Verification can happen
12:02 anywhere in the call flow. The ideal
12:05 scenario is that verification takes place in the
12:07 terminating network. In the case of the
12:09 good call, Wavecrest will pass this
12:11 call to the terminating operator. And in
12:13 the case of a bad call, Wavecrest rejects
12:16 the call.
12:18 When the call arrives on the handset, it
12:19 does a look up to an out-of-bound
12:21 passport cache. If a passport is found,
12:24 a verification again takes place and if
12:27 successful, the result is returned to
12:28 the handset. The outcome of the
12:30 verification is then displayed as the
12:33 phone rings.
12:35 In our trial, we relied on verification
12:37 on the handset using a modified version
12:39 of the standard Android dialer provided
12:41 by Google for this project and a lookup
12:43 was to a public out-of-band service. In an
12:46 ideal scenario, the verification would
12:48 take place in the terminating operator's
12:50 network with the cryptographic evidence
12:52 being passed directly to the handset or
12:55 to the out-of-band service to be deployed in
12:57 the operator's network.
13:01 This concludes the demonstration.
13:03 This project has been supported by the
13:05 GSMA Foundry and has had participation
13:08 from the following companies. If you
13:10 would like to find out more, please
13:11 follow the QR code.
13:16 Okay. There was a lot of detail
13:19 in that and I'm going to try to pull out
13:21 of what you saw a few points here.
13:25 The first one in the view that you
13:27 saw that was like this: anybody who
13:31 has seen that telephone call transit
13:34 their network has the ability to prove
13:36 certain things about it. This will
13:38 satisfy a regulator.
13:41 It will satisfy an IT team that's
13:43 worried about regulatory compliance.
13:46 It will satisfy an end user and all of
13:49 those stakeholders matter. Just
13:53 making the end user comfortable isn't
13:55 the only goal here. We had to make
13:57 Ofcom comfortable.
13:59 And so be being able to drill in and
14:03 say for this call, what are the
14:05 credentials that were available and what
14:07 can I know about the party that made the
14:09 call at that time and I need to be able
14:12 to have real time reaction to
14:14 revocation.
14:16 If Microsoft is doing something funny
14:20 and a regulator says don't let that kind
14:22 of call through anymore and we
14:24 revoke one of the credentials the
14:27 system has to react in real time to
14:28 that. So that's one of the things I
14:31 wanted to call out.
14:40 Okay. Being able to
14:42 drill in deeper so it's not just a
14:44 badge but you can you drill into the
14:47 individual pieces of evidence and look
14:48 at their status and you can do this
14:51 historically too. So at the time the
14:55 call is made you can look at it but you
14:57 can also go back a week or a year
15:01 later on a particular call and say what
15:04 was the state of the credentials at this
15:05 time? What was a justified conclusion
15:08 based on what the evidence looked like
15:10 then.
15:12 Now Sam's talked about tipping point.
15:16 I really hope that the telco thing is a
15:19 tipping point. You know it ain't
15:22 over till it's over but we have made a
15:24 lot of progress here. So I want to just
15:26 highlight a few of the things that were
15:28 kind of touched on briefly. VVP is an
15:32 acronym. It stands for Verifiable Voice
15:34 Protocol. That's an IETF draft spec
15:37 right now. For those of you who
15:40 don't work in telco, I've gone through
15:42 this learning curve recently. STIR
15:45 is a technology that is used in VoIP.
15:49 Voice over IP
15:52 and basically a STIR passport is a
15:55 JWT.
15:57 So many of you know what a JWT is
16:00 and how it works. So a JWT carries a
16:04 small amount of information and the
16:06 world's VoIP systems already know how
16:08 to carry these JWTs.
16:10 What VVP does is it says we're going to
16:13 put a little bit of extra information in
16:15 that JWT. And I'm going to show you how
16:18 little I really mean when I say a little
16:20 bit. It's actually remarkable how rich
16:23 we can make this with a very tiny
16:25 addition. And because the world systems
16:28 already know how to carry this
16:29 information, we don't have to modify the
16:32 infrastructure. The narrator in that
16:35 video mentioned just in passing that we
16:37 were calling a Spanish SIM card that
16:40 we had bought off the street, literally
16:43 we flew into Spain for this conference,
16:45 which was a month ago in Barcelona. We
16:48 flew in, we walked into a shop on the
16:50 street, a random one, and we bought a
16:52 SIM card and stuck it in, and we got a
16:54 call to work. And that's important
16:57 because we're not talking about
16:59 proposing to the world that they go
17:01 deploy a whole bunch of new
17:02 infrastructure.
17:04 The networks that carried this call
17:07 with this information had no notice that
17:10 we were doing this. We just did it and
17:12 it worked. So, that's really important
17:15 to the adoption story.
17:18 The events that are
17:20 listed here are kind of in
17:23 chronological order.
17:25 The GSMA is the world's… basically
17:30 the arbiter of mobile technology in the
17:33 world. And so this is important that
17:36 they convened this project
17:38 and those names that are listed there
17:41 are all big names. They all
17:43 participated in one degree or another.
17:46 Google was the handset manufacturer
17:49 who got their dialer modified fastest
17:52 and that's why we used the Google
17:54 handset to do the demos. But Apple
17:58 We had good conversations with them.
18:00 Samsung was there, Cisco was there.
18:04 All of these companies participating
18:07 together and Microsoft is going to
18:09 production in right now as we speak
18:13 in various parts of the world. It's
18:16 not a single big bang. It's a series of
18:18 going to production things in different
18:20 jurisdictions
18:21 and with different kinds of evidence. In
18:24 the UK, they don't need the branded
18:26 calling right now. They just need the
18:28 name Microsoft to appear. So, they don't
18:31 care about the logos. They're going
18:33 live in the UK first because they have
18:35 to satisfy Ofcom in the UK. Then
18:38 they're going to other places. So
18:40 anyway, there's some real live in
18:42 production stuff by companies that you
18:44 know that are doing this and the GSMA
18:48 completed this OVC project in March,
18:54 just a month ago. So now they've
18:56 announced that they're going to have
18:57 some follow-on projects. One of them
19:01 is going to focus on governance.
19:04 And this gets to the whole LEI and
19:08 vLEI topic.
19:10 During the proof of concept
19:13 stuff that we did, we were using an LEI
19:16 to identify the companies and everybody
19:18 agreed that was vital.
19:21 And so now they're looking to extend
19:23 that and fit into the vLEI family.
19:27 That's part of the follow-on governance
19:29 work.
19:31 The other thing is that they explicitly
19:34 want to make this technology usable in
19:37 multiple channels. So the channel
19:40 that we focused on in this first
19:43 experience was voice calls. But they
19:47 care very much since
19:51 the world's mobile technology
19:53 providers. They care about texting
19:56 just as much as they care about phone
19:58 calls. They care about rich chat and how
20:01 iMessage works and bunch of things like
20:03 that. And so when I say multi-channel,
20:07 that's what I'm talking about. Now, I
20:09 never explained the acronym OVC. So, let
20:12 me just spend a minute. OVC originally
20:15 meant Open Verifiable Calling.
20:18 But during this foundry project, people
20:21 said, "Well, wait a minute. There's no
20:23 reason why we couldn't take this
20:24 evidence that we've built into these
20:26 other channels." Right? So OVC has now
20:30 become in the minds and in the
20:32 communications that go on in GSMA
20:36 channels like their mailing list and the
20:39 meetings that they have. They've started
20:40 calling it Open Verifiable Communication
20:44 and that's what OVC now means with
20:48 this check mark. They're
20:50 explicitly pursuing communication as a
20:52 general goal, not just calling. So I
20:56 have a little bit more information about
20:57 that in a second.
21:00 Sam made a point in his
21:03 presentation that we don't want to
21:06 have a single vendor solution.
21:09 Provenant was kind of the enabler of
21:11 this whole thing. And of course
21:14 Provenant is a for-profit company and we
21:16 hope we can sell lots of people on what
21:18 we've built. But it's important for it
21:20 to be open and we believe in that.
21:23 So here's some kind of proof
21:26 points about how open verifiable
21:29 calling and the
21:31 verifiable voice protocol work
21:36 and thank you to this is a shout out
21:39 to the Trust over IP folks who've let us
21:42 build a Dossier specification at
21:46 trustover IP and I'm going to talk about
21:47 what a Dossier is in just a minute. It's
21:49 it's important to this whole concept and
21:54 Also to the folks over at IETF that
21:56 we're working with.
21:58 Okay. Let me talk a little bit since
22:01 this is a more geeky audience. It's not
22:03 just pure business people. I want to
22:05 talk about what's going on underneath
22:06 here.
22:08 When we looked at what we had to
22:11 build, these are the kinds of
22:13 requirements that we felt we were
22:15 getting from the business side
22:19 and the regulatory side. And I'm not
22:22 going to read all of them out loud, but
22:24 I hope when you look at that you say,
22:26 "Well, that's a pretty ambitious list
22:28 because it felt kind of overwhelming to
22:30 us." building half of those would be
22:33 pretty easy, but when you start having
22:34 to build all of those things in or
22:36 address all those requirements, as Sam
22:38 said, you get into a very hard trade
22:41 space where you're making trade-offs and
22:43 some of them are hard. And we didn't
22:45 want to trade away any of these
22:47 requirements. And because we're here at
22:49 a KERI conference, I will just say I
22:52 don't believe we could have built this
22:54 with any other technology. There were a
22:57 number of reasons why you end up at a
23:00 dead end if you try to solve it any
23:02 other way.
23:04 So
23:06 without belaboring that, let me say also
23:09 it was important to identify some things
23:10 we did not have to do. And this is
23:15 important because there are calling
23:18 solutions that deliver significant
23:21 value
23:22 that have some of these requirements and
23:25 we were not asked to address some of
23:26 these. The most interesting one I'll
23:30 just mention the bottom one here.
23:32 Somebody said, "Oh, well, this is all
23:33 well and good, but how do I know that an
23:36 AI is not, you know, sending me words
23:40 and pretending that it's coming from
23:42 another person?" And the answer is we're
23:44 not trying to solve that problem.
23:47 The reason we're not trying to solve
23:48 that problem is because for us, the
23:50 issue is about accountability.
23:53 If Microsoft connects to you, then
23:58 it's on Microsoft if they once they're
24:00 connected with you and you know you're
24:02 really dealing with Microsoft who made
24:03 the call. If Microsoft then sticks an AI
24:07 on the call, that's their problem and
24:08 your problem, but it's not the problem
24:10 of the technology that connected you and
24:12 proved that Microsoft was accountable in
24:14 the first place. So, it's about
24:16 accountability.
24:18 Not about whether it's human or not.
24:20 However, we could certainly
24:24 prove that the party who dialed you was
24:26 an actual human being versus an AI if we
24:29 needed to. And I'll show you where
24:31 that fits if that became
24:33 interesting.
24:35 So, these are some of the things that
24:37 were the places where maybe the
24:38 trade-offs manifest and it would be
24:40 hard to address some of these
24:42 requirements.
24:44 The top one is the maybe the biggest.
24:47 Okay, how do you do all of this but you
24:50 do it with a commodity SIM card over
24:53 networks that haven't been modified. If
24:55 you can do that, that's a big deal.
24:59 Anyway, there another one, the third one
25:01 there, I just want to mention, it's
25:03 possible to prove things between a
25:05 caller and a callee using
25:10 classic trust triangle that
25:13 we've talked about for years using
25:14 verifiable credentials.
25:16 However,
25:18 In that kind of a model, the parties
25:22 have to know who they're talking to
25:25 in a sense before you can prove
25:28 because basically you have to have a
25:34 connection with the other party in
25:36 some kind of an out-of-band way before you
25:38 can then prove with your credentials.
25:41 And the specific characteristic we
25:43 needed for this solution
25:46 was that a stranger could call you. You
25:49 haven't had any prior knowledge about
25:52 who these parties might be that are
25:54 reaching out to you.
25:57 Okay.
25:59 What does this look like? If I gave you
26:01 a really high-level architecture diagram,
26:03 it might look like this. You have a party
26:07 like Acme Corporation that wants to make
26:09 a call. Sometime near when the call
26:14 originates like right at the same time
26:16 or within milliseconds afterwards if
26:19 they're putting traffic on a network and
26:20 they're were you using like a
26:23 cloud provider or whatever as the call
26:26 originates, a signing event occurs the
26:29 signing that we're talking about is a
26:30 signing of the JWT.
26:35 And the JWT is this thing that's called
26:39 a passport That term passport is a term
26:43 of art in the IETF specification
26:50 for these JWTs.
26:53 So this passport contains ..,
26:57 and the blue with the underscore
26:58 here is supposed to suggest this to you,
27:00 contains a hyperlink
27:02 to what we're calling a dossier.
27:06 The dossier is the collection of rich
27:08 evidence.
27:10 So all we're adding to this passport
27:12 that it didn't have before is a field
27:15 that has a hyperlink in it.
27:21 The relationship between the signer of
27:23 the passport and the passport
27:26 itself is crucial and we could talk
27:30 about that offline. I probably won't go
27:32 into it in my talk that much. Suffice it
27:34 to say that you have to prove that the
27:36 party signing has some relationship of
27:39 delegated authority with the party that
27:41 is originating the call. It could be the
27:44 one in the same party, but it doesn't
27:46 have to be. And that's important because
27:47 you have to support things like call
27:49 centers
27:51 That are other businesses. The call
27:53 center is not Microsoft and a regulator
27:56 needs to be able to tell those two
27:57 parties apart. But you have to be able
28:00 to prove that the call center is acting
28:01 on Microsoft's behalf. They can't just
28:03 assert it.
28:08 There's a whole story about how
28:10 evidence is built and I'm not going to
28:12 go into it in detail, but essentially
28:15 you start out with a cryptographic
28:18 identifier for the company
28:21 and a control mechanism. Those two
28:25 things go together. And once you
28:28 have those two, then you build an
28:30 identity credential. And for those of
28:31 you who know how vLEIs work, this is
28:34 straight out of Karla's thinking.
28:40 It's exactly how vLEIs are built.
28:44 Basically steps one through four are
28:46 the journey of getting a vLEI.
28:49 And then you add to that a bunch of
28:51 other credentials.
28:53 Importantly, the credentials are issued
28:55 by different parties.
28:57 So you have a collection of issuers.
29:01 They all have their own revocation
29:02 criteria and their own revocation
29:04 SLAs. So we can't put all of this in a
29:07 single credential.
29:10 And then you bundle all the
29:12 credentials together in a Dossier. And
29:14 the Dossier includes a last thing which
29:16 has to be a credential issued by the
29:18 actual company that we're talking about
29:21 declaring their intentions to make this
29:23 kind of traffic flow.
29:27 And then you can use it in ongoing
29:30 use. Now some of you may be wondering,
29:33 here we are at a KERI conference, can
29:36 this technique be used without
29:39 ACDCs without KERI. No, it can't. You
29:45 can't build this whole solution but you
29:47 can interoperate with other kinds of
29:50 credentials quite nicely. So if a
29:52 company has a credential and the format
29:55 of this credential is a format that's
29:57 required by the EU to prove something
30:00 about the company and they want to use
30:02 that to prove one of the logical
30:03 propositions in the dossier, you can do
30:05 that. You could accept a credential that
30:08 is a W3C verifiable credential. You can
30:10 accept an SD jot. You can accept a signed
30:15 PDF if you want as evidence, but you
30:18 have to wrap it somehow because unless
30:21 you can put it in a verifiable data
30:23 graph and you can reason about it
30:28 in a particular way, the solution falls
30:30 apart. You can't end up generating that
30:32 view that I was showing you in the
30:34 evidence that has the badges and stuff
30:36 like that. So, there's two basic ways
30:38 that you can deal with that. You can
30:41 either use wrapped mode, which is where
30:43 I take a foreign piece of evidence and
30:45 put an ACDC around it, and literally
30:47 the ACDC has the content of the
30:51 other piece of evidence right inside it.
30:54 And it's a reissuance essentially.
30:58 So, you have an issuer of an ACDC
31:00 that's saying, "I looked at this other
31:02 piece of evidence and I used its native
31:06 technology, whatever it is, W3C
31:09 verifiable credential stack or
31:10 something, and I verified it on date X."
31:14 And so now I'm issuing an ACDC that
31:17 says on date X, this credential was
31:19 verified and it was true. That's wrapped
31:22 mode.
31:24 And you can see that wrapped mode
31:26 has some good things about it, and some
31:28 bad things about it. The good things are
31:30 that a party on the other end doesn't
31:32 have to know about any other stacks
31:35 or technology types. It only has to
31:36 verify ACDCs.
31:40 But you have a revocation issue. Does
31:44 the party who's doing the reissuance
31:46 sign up to also track the
31:49 revocation?
31:51 To be determined, right? The other
31:54 one is you can have embedded mode and in
31:57 that mode the party that's creating
31:59 the ACDC doesn't take a lot of
32:01 responsibility. They basically say
32:03 here's an ACDC envelope
32:06 around data but what it means is up to
32:08 you to determine and so you have to have
32:11 a stack that can look and understand
32:13 this other evidence format and decide
32:15 whether it agrees with the guarantees
32:17 that it provides. I don't think that
32:19 embedded mode is a good idea because it
32:22 fragments the verification space.
32:25 But anyway, enough about that. I won't
32:28 go into great detail on this diagram. I
32:30 could talk about it for a very long
32:32 time, but I'll simply say this. The way
32:34 that passports in STIR were conceived of
32:38 is that a passport was supposed to
32:40 include an X5U field that was a
32:45 hyperlink to the certificate of the
32:47 signer of the passport.
32:50 Okay. And when you went and looked up
32:52 that signer certificate, you would see
32:55 that the certificate included
33:00 proof of a cryptographic identity, that
33:02 would be their public key and it
33:04 included information about the
33:08 attributes of this party. So that'd be
33:11 like the common name of the company and
33:13 their organizational unit or you know
33:16 all that other stuff. What we've done is
33:18 we've split that apart and said
33:22 information about identity and
33:24 information about attributes need to be
33:27 handled differently because identity can
33:29 be permanent.
33:31 On this model. How
33:35 often do you have to replace this?
33:39 All the stinking time? I don't know
33:41 exactly what number you're going to come
33:42 up with, but I guarantee it's a number I
33:44 don't like. Right? If it's once a month
33:46 or once every three months or once a
33:48 week,
33:50 SHAKEN in the United States mandated
33:53 by the FCC calls for three-month
33:57 rotations in their guidance. I think
34:00 they enforce a higher number than that,
34:02 but okay. Anyway they're only
34:07 doing it right now. The certificates
34:09 that SHAKEN use are only for big
34:12 companies like Twilio and whatever.
34:14 They're not for the millions of little
34:15 companies around the world. So, they
34:17 said, "Well, let's take this
34:19 thing and we'll start using certificates
34:21 on all the little companies around the
34:23 world." Can you imagine if every little
34:25 company around the world has to replace
34:27 proof of who they are? Let's say
34:30 there's 30 million businesses in the
34:32 United States alone. And so you're
34:35 going to be maintaining a fabric of 30
34:37 million certificates that rotate once a
34:39 month.
34:41 It's completely impractical. And so
34:43 here, how often do we rotate this?
34:48 Zero times. I really love that answer.
34:51 You can rotate the keys as often as you
34:53 want, but I don't have to replace the
34:56 identifier ever.
34:59 And I can't tell you how profound the
35:01 difference in cost is and the difference
35:04 in infrastructure lift when you don't
35:06 have to replace anything. It's huge.
35:10 Now, we do have to change attributes,
35:14 but we only have to change them as often
35:16 as the attributes change,
35:18 right? If your company doesn't rename
35:20 itself, you don't need a new proof of
35:22 what its name is. And if it doesn't lose
35:25 the ability to use a logo in a
35:27 particular jurisdiction, you don't need
35:28 to replace that either. So again, the
35:31 maintenance is dramatically different.
35:35 This is how it actually looks on the
35:38 wire today. On the left is a standard
35:41 SHAKEN passport. This is what
35:44 actually flows over the wire right now.
35:47 And the reason that we could deploy this
35:49 with no changes in infrastructure is
35:51 because this is how different it looks
35:54 over here.
35:56 None of the infrastructure cares.
36:03 I'll highlight
36:05 these two lines. So this is the
36:07 hyperlink in a traditional SHAKEN
36:10 passport that says here's how I can find
36:12 the certificate of the party that
36:14 signed this.
36:16 And here we have a link. This is an OOBI
36:19 to a KEL.
36:21 Okay. And down here we have an
36:25 unsupported assertion from somebody
36:28 saying, I think that this is an A-level
36:31 call. I believe in this call. Here we
36:34 have hyperlink to evidence.
36:39 It's really simple.
36:45 I'm not going to… I'm about out of time.
36:47 So, I'll just say that Dossier can
36:50 prove lots and lots of logical
36:52 propositions, not just one.
36:55 And the list of things that you can
36:57 prove under the previous model had one
36:59 bullet on it. You can prove the opinion
37:02 of the company that signed the JWT
37:05 about whether it was a good call.
37:07 That's not a very long list.
37:10 I mentioned this that OVC is coming
37:13 to mean something different.
37:15 There's active work now going on
37:19 on a variation of this for SMS, a
37:22 variation of it for rich chat. So
37:25 proving who sends you an iMessage or
37:29 the equivalent in the message app on
37:31 Android and web meetings. Wouldn't you
37:34 like it if when you showed up to a Zoom
37:36 meeting you actually had proof of who
37:39 you were and everybody else did too? And
37:42 there are some other transports that I
37:43 won't announce today, but there's cool
37:45 stuff going on with those two.
37:48 So if you want more information, the
37:52 spec for the Verifiable Voice
37:55 Protocol is at this one and the demo
37:58 that I showed you is at that QR code.
38:00 You can watch it again. Any questions?
38:03 [applause]
38:08 – We got time for two questions.
38:11 – Yeah. You mentioned that you were using
38:14 the Google dialer. So, was that [inaudible]
38:21 – So, Google's dialer was actually
38:24 signed by Google and so forth, but it
38:27 it's not in the mainstream distribution.
38:30 Google is still debating whether
38:33 they want to put it in.
38:36 Another question
38:38 – Question about the security of the URL that goes
38:41 to the Dossier. So obviously if it's
38:44 wrapped and signed then the URL is safe.
38:47 The URL itself is safe but at the
38:51 target that's where something can
38:54 change and be malleable. So how are…
38:56 what are you doing to secure the
38:58 endpoint where the URL goes?
39:01 – Well, the URL is an OOBI. So it's
39:03 not a generic URL, meaning that when
39:07 you go there, you must see a signed
39:10 sequence of events that proves the
39:13 its evolution from its origin
39:17 moment, its inception moment. So you
39:21 could have somebody who
39:25 tries to replace the content at that
39:28 location, but if they did, they would
39:30 have to come up with content that still
39:33 evolved from scratch and was still
39:35 related to the identifier in
39:38 question, and that would be detected
39:41 then by the watcher network and so
39:43 forth. So, KERI prevents a bunch of
39:47 monkeying with that. And interestingly
39:49 enough, this is one of the debates that
39:51 I've been having in the STIR working
39:53 group at IETF because people said, "Oh,
39:55 this is a great idea. We'll put a
39:57 hyperlink in there. We'll just accept
39:59 any hyperlink."
40:01 And I said, "No, that's not quite a good
40:04 idea." For the very concern that
40:06 you're talking about, we'll see if I can
40:08 convince them. They might just modify
40:10 the spec and say any hyperlink will do.
40:13 In which case…
40:15 – …that immediately becomes the
40:17 sensitive attack surface.
40:18 – Exactly.
40:21 – One more question.
40:23 Could you grab the mic?
40:27 – In your architecture, you showed a
40:29 couple of phone home paths. What
40:31 are the implications of privacy on that?
40:34 – So the phone home path is not
40:38 a phone home to another party. It's a
40:40 phone home to the originating party. So,
40:44 basically the party that made the
40:46 call might have somebody call them back,
40:51 Or it call their watchers and
40:53 witnesses back. But these are
40:56 entities that they control and have
40:58 chosen. So it's not calling home or
41:02 phoning home to a central registry. It's
41:04 phoning home to… it would be the
41:07 equivalent of on the web calling the
41:10 name server for Microsoft.com that
41:13 Microsoft chose. So you're tracing data
41:16 back to a server Microsoft set up and
41:19 empowered.
41:20 – So it doesn't have to be Provenant in
41:21 every case.
41:22 Oh no, no. Provenant
41:24 implemented this system. But the spec
41:27 is open and anybody could implement the
41:29 system. Yeah, there's no lock-in
41:32 about that.
41:34 – Okay, thank you very much once again. [applause]