0:00 ｜ KERI Conference 2026
0:03 Hi everyone. For those of you who don't
0:04 know me, I'm Phil Feairheller, CTO and
0:05 co-founder of healthKERI. And
0:09 those of you who are presenters will
0:12 know that we had to submit our talks
0:15 ahead of time to get the slides
0:18 approved. And so I submitted a talk on
0:20 ACDCs for authentication. But I'm
0:23 going to pull a little bit of a fast one
0:25 and switch it up because there I think
0:26 is a much more important topic that we
0:29 need to discuss and that is HIO. Why
0:33 Sam? I'm just kidding. I'm not going to do.
0:38 Totally kidding. I'm actually doing
0:39 ACDCs for authentication.
0:42 Okay, so this talk is based on the
0:45 demo that we did for the SEDI conference
0:48 and I have it here. I'm just going to
0:50 run the video of it real quick and
0:53 talk through what we did.
0:56 Let me get it started. In this demo,
0:58 we start with our Locksmith wallet. We
1:00 show that the wallet is holding a couple
1:02 of credentials, a vLEI credential and a
1:04 fake Utah SEDI health identification
1:07 card credential and the various fields
1:09 that are in it.
1:12 And then we switch over to the site
1:14 which is a fake healthcare portal and
1:16 demonstrate how we could use those
1:18 credentials to first create an account
1:20 and second to authenticate and log into
1:22 the account from there on; go through the
1:25 fact that you could allow the user to
1:27 type in the information and suffer
1:29 through typos and everything else or you
1:31 could use the SEDI credential and get
1:33 accurate data and much more secure
1:36 connections. In addition to that, we
1:38 went over the fact that we could
1:39 introduce at the beginning of the OAuth
1:41 flow an offer stage that allows me to
1:44 offer the credential without sharing the
1:46 data and require a signed receipt back
1:49 from the site that they agree to my
1:51 terms and conditions before I give them
1:53 my credential and all the data in it. So
1:56 that's what we're doing here. We're
1:57 doing the offer.
1:59 We also demonstrated that the site is
2:00 built so that anyone using any other
2:02 KERI tool can create an offer and
2:04 upload it. You don't need the plugin.
2:05 We just use the plugin make it
2:07 work a little more smoothly. And then
2:09 here they have returned the signed
2:11 receipt.
2:13 You can view the receipt in the accepted
2:15 offer section
2:21 and then submit the full credential and
2:23 now you're logged into the site. You've
2:25 created your account.
2:27 All the data is extracted from the
2:29 credential
2:31 and you are now signed in. And then you
2:33 can go through the process and sign in
2:34 again. And the point here was that we
2:36 made it such that the process of
2:39 using a any kind of ACDC credential for
2:42 this form of authorization can be just
2:44 as easy as using a passkey, for
2:46 example, but of course much more secure
2:48 because it's based on a KERI identifier
2:51 through the stuff I'm going to show
2:52 next. Key rotations work seamlessly. You
2:56 can do them anytime you want. And if you
2:58 use this AID in this account,
3:01 (how do I go next? There we go.) If you
3:04 use this AID for multiple sites that
3:06 you've logged into, you do one key
3:08 rotation and they'll all get your new
3:10 keys. So you don't have to worry about
3:11 changing a password, remembering
3:13 passwords for many different sites, etc.
3:16 So that demo was something that we kind
3:20 of backed into because of the work that
3:22 we've been doing in healthcare. And so
3:24 what I want to cover today is how we got
3:26 to that by starting to work with
3:30 integrating the vLEI into the OAuth
3:32 protocol for a specific purpose related
3:35 sorry specific per purpose related to
3:37 these protocols. But then we realized
3:40 that if we just keep going and extend it
3:42 a little bit further into OAuth, we could
3:44 do end user authentication. So these
3:46 protocols I realized this morning
3:48 looking at my slide you've all heard
3:50 about them now I think at least three
3:52 different times in three different
3:53 sessions. So I'm going to go over them
3:54 very quickly but to make a very
3:56 specific point about them. So HL7 FHIR
4:00 think of it as REST APIs for healthcare
4:02 very simple but extensible data model
4:06 specific to healthcare. It supports
4:08 real-time APIs documents and messages.
4:11 It is actually written into HSS
4:13 regulations and it was informed by all
4:16 of these other standards that have been
4:18 used in healthcare for 30 years, Mark.
4:20 20 years. Yeah. And so the old way, Mark
4:22 explained this in another session
4:23 yesterday. The old way was is that as
4:26 they were starting to exchange more and
4:27 more data, they were just exchanging
4:29 documents over these protocols and
4:32 the documents were just getting bigger
4:34 and bigger because they had to send the
4:35 whole thing. So FHIR, what it did was
4:37 allow people to send distinct sections
4:40 of records that were much easier to
4:42 transmit and of course modernized
4:44 because they're REST APIs. So the FHIR
4:47 modules are broken down into these
4:48 different categories. You have your
4:50 foundation and base resources and then
4:52 of course you have the specific
4:53 resources that are defined for things
4:56 like clinical, financial, specialized
4:58 resources. And you can see all the
4:59 categories here. they're not
5:01 particularly interesting to us or
5:02 KERI, but I wanted to point out that
5:04 what we're trying to accomplish is
5:07 the ability to do authorization at a
5:10 level that's as low as this. So, very
5:12 particularly, we are working on
5:15 something called payer-to-payer access,
5:16 which allows payers to, for example, if
5:19 you switch from one payer to another, get
5:21 your information over to the other payer
5:22 much more seamlessly than happens today.
5:25 But we only want the two companies to be
5:28 able to exchange data for
5:29 payer-to-payer, not for anything else.
5:31 So, we're able to dig in at this level
5:33 and create authorizations very specific
5:36 to the purpose of use.
5:39 Okay. And what got us here? What got us
5:41 here was CMS-0057-F final rule. Easy to
5:45 say and it mandates that Medicare
5:47 Advantage, Medicaid and CHIP plans. So
5:49 anyone that interacts with these people
5:51 have to implement FHIR-based APIs to
5:54 streamline prior off and accelerate
5:55 decision times.
5:58 So you have the impacted players here as
6:00 I said anyone who works with these
6:02 people. The one that's probably most
6:05 interesting to folks in the industry is
6:07 the Prior Auth because that's always been
6:08 a sticking point. Takes forever. It's
6:11 manual in some cases. They want this
6:13 to be automated much more quickly.
6:16 Patient access, so getting into patients
6:18 being able to get a hold of their own
6:20 data at the FHIR level. But then the one
6:23 that we focused on because it's the
6:25 easiest to get pilots going, it's the
6:27 most constrained use case was the
6:29 payer-to-payer data exchange. So this
6:31 mandate is forcing by January of 2027
6:35 health plans to implement this. So that
6:37 was our opportunity and what gave us the
6:39 idea, actually Mark the idea, that we
6:42 could integrate the vLEI into this, to
6:44 accelerate the connections that are now
6:47 going to be needed between these payers
6:48 and then down the road between payers
6:50 and providers and then down the road
6:52 even further between patients and payers
6:54 and providers. So you're starting to see
6:56 the number of connections that are going
6:57 to be needed. Making those connections
7:00 quickly and securely would be a limiting
7:03 factor without what we're trying to
7:04 implement.
7:07 OAuth 2.0, I don't really need to go
7:09 into this, most of you probably are aware
7:11 of what it is, legacy, kind of like
7:14 using the word legacy, authorization
7:16 authentication protocols,
7:18 essential for
7:19 interoperability and that's the key so I
7:22 think the biggest lesson learned for
7:25 healthKERI here is meeting the customer
7:27 where they are. A little history when we
7:30 first started out we created a product
7:33 called RACK: Routing Authenticity and
7:36 Confidentiality with
7:38 KERI. I like making acronyms, too.
7:42 And what that was, is a API gateway
7:45 that wrapped every transaction in an
7:49 ESSR packet. So, signed and encrypted to
7:51 a specific destination and provided full
7:54 security between those two endpoints. No
7:56 need for TLS, no need for VPNs, anything
7:58 else. And it also created a
8:00 cryptographically verifiable audit log
8:02 of every single transaction.
8:04 Nobody wanted to use it because it was
8:06 not interoperable. So what we have done
8:09 over the course of the last six months
8:10 is slowly back our way out and meet the
8:13 customer where they are by integrating
8:15 with OAuth because FHIR requires
8:19 or mandates or includes the
8:22 ability to use OAuth for authentication
8:25 a protocol I'm about to talk about next.
8:27 UDAP had taken OAuth and added five or
8:31 six, I only mentioned four here, new
8:33 profiles that allowed the use of X.509s
8:37 embedded into these different flows to
8:40 do authentication.
8:42 Mark Scrimshire came to us and said
8:45 that seems to work, but what happens
8:48 when everyone hits their 47-day limit
8:50 and they have to rotate all their
8:51 certs? What happens? And so as the
8:54 companies we were talking to, they're
8:55 like, "Well, I have to manage my certs,
8:58 but now I got to worry about everyone
9:00 else's certs. How what do I do when they
9:02 all have to rotate? How do we
9:03 reestablish these connections?" And so
9:05 he identified that the vLEI would be the
9:08 perfect opportunity to introduce true
9:10 organizational identity and KERI to
9:14 solve this problem in a very similar way
9:16 that UDAP did, but replace X.509s with
9:18 the vLEI.
9:20 And there's quite a bit more
9:22 detail underneath. I'm not going to get
9:24 into it, but we have other credentials
9:25 that chain off of vLEIs to define the
9:28 purpose of use to allow them to be that
9:31 more specific authorization I was
9:32 talking about, but we don't need to
9:34 go to that level of detail. So these are
9:37 the four protocols or profiles that
9:39 were defined in UDAP that we are
9:42 going to be augmenting or replacing.
9:46 The first one and this is where we were
9:47 going to stop before we decided to do
9:49 something for the SEDI presentation
9:51 and that is dynamic client registration.
9:54 So in OAuth is what is it RFC7591
9:57 dynamic client registration that allows
10:00 people without having a developer go to
10:02 a developer portal and register your
10:04 client ID get a secret or enter a secret
10:06 get it back so that your client app can
10:08 now make token requests. There is a
10:12 RFC that allows for that to be dynamic.
10:14 And so what UDAP had done was say "Okay,
10:16 if we insert a signed statement from the
10:19 client and a reference to their X509 certs
10:23 if we have an ecosystem of CAs that we
10:25 trust for this purpose, we can allow a
10:28 client to be registered dynamically and
10:30 and automatically." We saw that and
10:32 said "Okay, cool, works great, just replace
10:35 X.509s with vLEIs and now we're on to
10:37 something." So that's the first thing we
10:39 did. So we automated the ability, payer-to-
10:41 payer, remember that's what we're
10:42 focusing on. We automated the ability
10:44 for one payer to submit a credential to
10:46 another payer, and without any human
10:48 involved, be registered to start
10:50 interacting payer-to-payer APIs and from
10:54 that point down, the rest of their
10:57 stack stays the same. They're using
10:59 they're using FHIR APIs. They're using
11:01 token. They're doing the token requests
11:03 because this is client
11:04 authentication, so there's no
11:05 authorization-code step first. And so
11:08 that worked great. Then when we decided
11:11 that okay, that authorization server
11:13 works great. There's a real good
11:15 opportunity here to insert ahead of, or
11:18 after client authentication, after client
11:20 registration and then client
11:21 authentication, to do user
11:23 authentication. So they had JWT-based
11:26 user authentication which allowed for a
11:28 cert to be used to sign a JWT that would
11:31 then assert who the user is. So you
11:33 could do the user authorization flow
11:35 which involves getting a code first then
11:37 it redirects back to you and then you
11:38 use that code to get the token. We
11:40 replaced that with vLEI as well and that's
11:42 what I demoed here. The last step was,
11:45 after having conversations with the
11:47 fine folks in the state of Utah,
11:49 George and Chris, we realized that there
11:52 was still one problem left to solve and
11:54 that was "Okay, if we're using these
11:56 credentials, how do we still know that
11:58 our data is being protected?" And that's
12:00 when we added a new step that's not part
12:02 of OAuth, the <i>credential offer</i>.
12:04 Doing the credential offer allows us to
12:06 offer a credential based on a schema. So
12:08 the structure of the fields, a
12:10 cryptographic commitment to what the
12:12 data will be and require the site to
12:15 sign your terms and conditions with that
12:17 cryptographic commitment before you
12:19 reveal the data to them. Then once you
12:20 reveal the data, they can verify that
12:22 yep, it matches the schema. Yep, that's
12:23 the data they promised to give me
12:25 without revealing the data. Now I can
12:27 register them and allow them through.
12:31 So I pretty much just talked about
12:32 this but the client
12:35 credentials flow with UDAP and vLEI
12:38 involved, like I said, dynamic
12:39 client registration with vLEI, we do a
12:42 sign inserted inside of the
12:46 client registration request, it's
12:48 slash register is an IPEX presentation in
12:51 the OAuth registration request itself the
12:54 flip side of this, one of the things that
12:56 UDAP had that we borrowed from, is a
12:57 .well-known for the server so that we
13:00 could identify the server. So we can
13:02 avoid having a server that we get a man
13:04 in the middle or whatever. So in our
13:06 case, we just have in the .well-known an
13:08 OOBI that identifies the AID of the
13:10 server that we're going to be
13:11 interacting with.
13:13 Pardon me. Oh, so then finally, and
13:17 most importantly in this case, the
13:18 client ID is mapped to the SAID of the
13:21 presented credential. The SAID of the
13:23 presented credential. And there's no
13:25 client secret. Every token request from
13:28 here on out is a signed request. So you
13:31 eliminate a shared secret from the
13:32 equation and you have fully signed token
13:35 requests. Now of course our hope is that
13:37 once they see the power of this they'll
13:40 say okay now that I can sign these token
13:42 requests can I sign all my other
13:43 requests and then we'll start selling
13:45 them RACK.
13:47 I just touched on the client credentials
13:50 flow. Every other request after that
13:53 is a IPEX presentation
13:56 signed and the client and server key
13:58 rotations are supported by the watcher
14:00 network and I'll talk about how we
14:01 implemented that to enable connectedness
14:04 as trust at scale specifically for
14:08 purpose of use and these extensions to
14:10 the OAuth protocol.
14:13 So then the logical next step
14:16 authorization code flow. Let the
14:18 user now leverage what we've done to log
14:21 in with their vLEI credentials. Okay,
14:23 good. So we extended the model to
14:25 support user authentication with data
14:28 privacy of doing the offer ahead of the
14:31 actual credential presentation. So this
14:33 is a typical OAuth flow. The user
14:37 the resource owner goes to the client
14:39 application. The user gets redirected to
14:40 the authorization server. They say
14:42 approve. It comes back here. The client
14:45 then says, "Okay, here's the code. Can I
14:47 have a token?" You get the token and
14:50 then you send that over to the FHIR
14:51 resource server and you get your data
14:53 because the resource server is able to
14:55 talk to the authorization server behind
14:56 the scenes and say, "Is this a valid
14:57 token!" So that's how it works. This is
14:59 a… I stole this diagram. Actually I
15:00 made it but I looked at someone else's.
15:04 This is what it looks like with KERI
15:05 and the vLEI. Well, KERI and ACDC.
15:08 In this case the resource owner has a
15:10 KERI database. The client application
15:13 has a KERI database and the
15:15 authorization server has a KERI
15:17 database. So in this case when he is
15:20 redirected over there he submits a
15:23 credential instead of username and
15:24 password. You've all done this with log
15:27 on with Google, right? This is the exact
15:28 same thing but it's now log on with your
15:31 ACDC credential.
15:33 So then you get redirected and
15:34 everything works the same. But the
15:36 really important part here is these
15:38 arrows. Everybody is watching the
15:42 watcher network and each other's
15:44 witnesses so that when he decides to
15:46 rotate his keys, he can do it every hour
15:47 if he wants to. We actually did that in
15:49 a in a pilot we were running. It was
15:50 really fun. He can rotate every hour if
15:52 he wants to. It'll get propagated to his
15:54 witnesses. Everyone else's watchers will
15:56 pick it up and now it's still fully
15:58 secure and you have new keys as
15:59 frequently as you want.
16:10 Yes, you can hyper churn your
16:11 credentials.
16:13 And Sam, your voice is sounding better. [laughter]
16:18 IPEX issuance and
16:20 presentation exchange protocol. It's a
16:23 protocol built on top of KERI EXN
16:25 messages and it allows this flow…
16:28 I stole this table from the
16:30 the ACDC spec.
16:33 It allows this flow of messages to
16:37 negotiate credential exchange between
16:40 two parties. So we are only starting at
16:42 the offer phase and you can see where
16:44 you can start. That's the Ys in here.
16:47 And you can see after an apply you can
16:50 spurn it. I love that you use the word
16:52 spurn. (I don't know why I just do.)
16:55 You can offer it. You can either spurn
16:57 or agree to the offer and then you can
16:59 grant the credential. And then once you
17:01 grant the credential, this is an
17:03 important step, you admit it, which
17:04 sends the admission back to the person.
17:06 So you have a receipt that they accepted
17:08 your credential.
17:10 And so what we've leveraged with IPEX,
17:13 one of the I think the driving factors
17:15 for IPEX was graduated disclosure, chain
17:18 link confidentiality, and contingent
17:20 disclosure on them accepting your offer,
17:23 assigned acceptance of your offer. And
17:25 then once you embed the rules inside of
17:28 your credential, the metadata credential
17:30 that you exchange back and forth during
17:32 these exchanges, you get
17:34 contractually protected disclosure as
17:36 well. And that's what we're leveraging
17:38 here
17:41 and I just said that. So this just
17:43 details the contractually protected
17:45 disclosure. The user offers the terms
17:46 and conditions, no data exposed. You get
17:49 a cryptographic commitment in the offer
17:50 to the structure of the data hash of
17:52 what the data will be and then terms and
17:54 conditions which are being enforced. I
17:57 I think in the future we can see sites
17:59 offering a couple of .., just like when you
18:00 create a GitHub account you can pick
18:01 your license for the new
18:03 GitHub repo. I can see a world where
18:06 sites are offering different terms and
18:08 conditions and the user can select which
18:10 one best suits their needs for giving
18:12 the data to the site. And if none then
18:14 they don't give the data.
18:16 the site agrees, returns the signed
18:18 agreement, and then the user saves the
18:20 receipt and grants the full credential.
18:22 And that's what the flow that we showed
18:24 in the demo.
18:27 So, this is just further detailing.
18:29 The credential offer comes back or
18:32 I'm sorry, the site comes back
18:33 and says, "We'll accept an offer, you
18:35 make the offer, you get to see what
18:36 terms and conditions are there before
18:38 you agree to it."
18:41 And then the signed agreement comes back
18:43 from the server. We use our plugin to
18:45 validate it. But again, at any point if
18:47 you don't have our plugin, you want to
18:48 do it yourself, you just download the
18:50 signed agreement, you send it through
18:51 KERIpy, if you want to or any tool
18:54 that supports this flow with KERI
18:56 and you can then upload your offer or
18:58 your full grant, sorry, you upload your
19:00 full grant, which we do with the submit
19:02 full credential and now the site gets
19:04 your information. And when we did this,
19:06 it really did hit home that the
19:08 user benefits greatly for all the
19:09 reasons I just talked about, but the
19:11 site benefits from it is something I
19:12 think George said in one of his talks.
19:14 They get cryptographically verifiable
19:16 data. They're not going to get typos.
19:18 That's going to halt that's going to
19:19 slow down the process of users signing
19:20 onto your site and getting access to the
19:22 data that they need.
19:25 Okay, so this is how we did it. We built
19:28 an ACDC authorization server. It acts
19:30 as both an OAuth 2.0 authorization service as
19:32 well as an OIDC Identity Provider. So
19:35 we're doing it with ACDC schema
19:38 configuration.
19:39 You can configure both the client
19:41 registration schema that you'll accept
19:44 and it can be a list and you also
19:46 specify the user authentication schema
19:49 that you'll accept and it can be a list.
19:52 Each of those supports a base schema
19:54 specification which allows you to
19:57 enforce what issuers you will accept at
20:00 any chain in your credential
20:02 hierarchy. For example, an oversight
20:05 we did with GLEIF. I can
20:08 issue vLEI credentials. They're not valid
20:10 because they don't come from GLEIF root,
20:11 but you can enforce that it has to come
20:13 from GLEIF Root in here by putting the
20:14 issuer of the GLEIF Root AID.
20:19 This was a fun part. ACDC payload to
20:21 OIDC claims mapping. We used a pretty
20:25 simple template syntax (Jinja2 for
20:26 those of you who are familiar with
20:27 Python) to create complex field mappings
20:30 between the credential payload and the
20:32 OIDC claims that come out the other end.
20:35 So when you put all this together, what
20:37 you're really doing is you're creating a
20:40 truly distributed identity provider
20:42 appliance. I can put one of these up,
20:45 specify a list of credentials, I'll
20:46 accept, specify how I want the data to
20:48 look in OIDC.
20:50 Someone will submit their credential to
20:52 me and I'll let him in. Sam can do the
20:55 same thing. We never have to talk. Our
20:57 systems aren't federated. We don't share
20:59 data. If he specifies the same schema as
21:01 me, he'll let the person in the same. It
21:03 looks exactly the same to the user. The
21:05 data comes back to
21:08 the client application,
21:10 of who that user is. But
21:13 there's no federation. You're not
21:15 relying on Google to hold your Gmail
21:17 account. You're doing it with a
21:18 decentralized credential issuance from
21:20 anyone.
21:22 So then these are the flows I've already
21:23 talked about that we worked with, dynamic
21:25 client registration, secret lists, the
21:28 client authentication flow, this is for
21:29 our payer-to-payer model so that the payers
21:32 can then just start as soon as they do
21:33 the DCR the payers can start exchanging
21:35 data by getting the token and then user
21:38 authentication.
21:41 The last part. I talked about
21:44 integration into the watcher network and
21:46 the witness network. For those of
21:49 you who know me, I do actually own a
21:51 Great Dane and a Bull Mastiff, but these
21:53 aren't my dogs.
21:55 So we called it HK Tracker and it's
21:57 what Sam has been calling forever a
21:59 local watcher. And so anywhere where we
22:02 deploy a server or a system
22:05 that needs access to the KERI watcher
22:08 network, it's going to be resolving AIDs
22:10 and it's going to need to keep track of
22:11 key state. Any enterprise system we can
22:14 put as a sidecar. So think of a sidecar
22:17 pod inside of Kubernetes or just running
22:19 along in a VM. We put a local watcher
22:21 service which is configured to our SaaS
22:26 platform to be able to ask our platform
22:29 to start watching new AIDs. So the
22:31 situation where someone authenticates
22:33 for the first time and then continue to
22:34 keep track of their key state changes. So
22:37 it adjudicates the key state changes
22:39 locally and integrates with the KERI
22:41 watcher network. It uses our ESSR
22:43 secure connections to our APIs to get
22:46 the updates for the AIDs that it cares
22:49 about. And the cool thing is it doesn't
22:50 have to do it for any ids that have
22:52 registered with Sam's server because I
22:54 don't care about those only the ones
22:55 that I have authenticated against. And
22:58 so we use, borrowed very heavily
23:01 from Tailscale if any of you are
23:02 familiar with that VPN company, t hey
23:04 have a model for when you want to get a
23:07 headless server on the system you
23:09 go into the site and you get a
23:11 authentication code onetime
23:12 authentication code that you use. And
23:14 so that's how we do it down there.
23:18 And so these are my actual dogs. I just
23:20 wanted to show this. That's Zoe, my
23:22 Great Dean. That's Jackson, our Bull
23:26 Mastiff. And that's Remy
23:28 rescue Pit Bull.
23:32 This is the diagram that
23:34 we've created. I think Jared already
23:35 showed this in one of his talks, but
23:36 this is the diagram we created when we
23:38 were first trying to conceptualize this.
23:40 And the idea here is that when you look
23:42 at the convergence of what's happening
23:44 here, DirectTrust is working very
23:45 closely with GLEIF
23:49 to help facilitate bringing the vLEI
23:53 ecosystem into healthcare.
23:56 You can have these credentials
23:57 issued into a payer and a provider
23:59 wallet, dynamic client registration,
24:02 client authentication.
24:04 They can issue vLEIs down to their
24:05 members. State of Utah can issue SEDI
24:08 credentials and then all of them can now
24:10 authenticate against the site and get
24:12 the data they need using this exact same
24:14 method. So that's what we're trying to
24:15 get at here.
24:19 And that's it. Any questions? Yes. Do we
24:21 have a microphone?
24:32 – Just a quick question. Can you say
24:33 more about the difference between the
24:35 payer and the provider wallets?
24:37 So, like what they're meant for.
24:40 Oh, like the purpose of use, like
24:42 why a payer would be accessing another
24:44 payer versus why they'd be accessing a
24:45 provider. Is that what you mean?
24:46 – Yeah, and what the wallets do;
24:48 what's their provider mean?
24:51 In this case this was just meant to
24:56 represent the fact that you have
24:59 this the same type of wallet.
25:01 – Got it. The payer would be holding his
25:02 vLEI credential and use it to access
25:04 anyone else in the ecosystem. Literally
25:06 anyone else in the ecosystem access
25:07 their data.
25:08 – Got it. Those are just roles, not
25:10 different wallets. Okay. Got it. I
25:11 misunderstood.
25:13 – My question is about the
25:16 authorization server flow. [adjusting volume]
25:21 So, the authorization server waits
25:23 for an ACDC presentation. Does
25:26 that make the ACDC essentially
25:30 the identity provider?
25:32 Yeah. That's why I call it a
25:33 dynamic identity provider appliance
25:35 because it's just you install
25:37 anyone anywhere and you say trust these
25:39 credentials.
25:40 – Okay.
25:40 And it just works.
25:41 – Cool.
25:42 – Is it limited to person
25:56 to business or can also be used in API
26:00 situations business to business?
26:02 Yeah, the client authentication
26:03 flow, dynamic client registration and
26:05 then client authentication flow supports
26:07 business to business.
26:12 In OAuth you can do just client
26:16 authentication where you skip the
26:18 authentication flow you get you don't
26:19 get the authentication code that's just
26:20 payer to payer that's business to business
26:22 so it does support that as well.
26:24 That's why I guess you have a client ID
26:26 because the client can get the data
26:28 themselves not on behalf of a user.
26:33 All right, thank you very much. [Applause]
26:35 – Thank you.