[MINUTES] CCG Weekly 2025-04-22

W3C TCG Meeting Summary - 2025/04/22

*Topics Covered:*

   - *IRA (Interoperability and Recognition of Acceptance) Overview:* A
   recap of IRA's purpose as a connector of ecosystems, enabling data exchange
   across different trust frameworks. Emphasis on the value proposition for
   holders, issuers, verifiers, and integrators. IRA's role as a connector,
   not a governing authority, respecting ecosystem sovereignty.
   - *IRA Projects:* Discussion of specific IRA projects, including the
   "First Person" project focusing on privacy-preserving proof of personhood
   credentials.
   - *IRA Technical Functionality:* Detailed explanation of how IRA works,
   including its building blocks (registry of registries, conformance test
   suite, type catalog), and the technical interoperability requirements it
   defines. The importance of ecosystem sovereignty in the design was
   highlighted.
   - *Governance and Ecosystem Participation:* Discussion of IRA's
   governance framework, including the process for ecosystems to join the IRA
   trust network and the considerations around different assurance levels
   across various industries.
   - *Authority Verification Profile:* A deep dive into IRA's authority
   verification profile, which addresses the challenges of recognizing
   governance frameworks and verifying issuer authorization across ecosystems.
   This included discussion of the Trust Registry Query Protocol (TRQP), its
   API calls, and the structure of authority statements (recognition,
   delegation, description).
   - *Identifiers:* IRA's approach to identifiers, utilizing Decentralized
   Identifiers (DIDs) for ecosystems and trust registries, while maintaining
   flexibility and ecosystem sovereignty.
   - *Clusters:* Explanation of how IRA supports clusters (industry-led and
   IRA-led) as a mechanism for facilitating collaboration and interoperability
   within specific industry verticals.

*Key Points:*

   - IRA aims to solve the interoperability problem across different trust
   frameworks and ecosystems, focusing on making credentials not just
   interoperable but also valuable.
   - Ecosystem sovereignty is a core principle; IRA acts as a connector,
   not a governing body over individual ecosystems.
   - The Trust Registry Query Protocol (TRQP) provides a standardized way
   for verifiers to query different ecosystems about authorization and
   recognition, enhancing interoperability.
   - IRA's governance model is designed to ensure neutrality and
   inclusivity, enabling the creation of multiple interconnected networks.
   - The use of DIDs for identifiers empowers ecosystems to maintain
   control over their data and identity management while enabling efficient
   interoperability.
   - Clusters provide a structure for focused collaboration and
   interoperability within specific industry domains.
   - IRA provides tools and resources, including a live demo and Docker
   Compose setup, for developers to engage with and utilize its framework.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-04-22.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-04-22.mp4
*CCG Weekly - 2025/04/22 11:56 EDT - Transcript* *Attendees*

Alex Higuera, Andor Kesselman, Chandima Cumaranatunge, Darrell O'Donnell,
Dmitri Zagidulin, Drummond Reed, Erica Connell, Harrison Tang, Hiroyuki
Sano, James Chartrand, Jeff O - HumanOS, Jesse Wright, Joe Andrieu, Kaliya
Identity Woman, Kayode Ezike, Kim Hamilton, Mahmoud Alkhraishi, Mic Bowman,
Nate Otto, Phillip Long, Rob Padula, Ted Thibodeau Jr, Vanessa Xu, Will
Abramson
*Transcript*

Harrison Tang: Hey, Mamu.

Mahmoud Alkhraishi: Hello. Good.

Harrison Tang: How's it going?

Mahmoud Alkhraishi: How are you?

Harrison Tang: right. Busy as always been Surviving. Yeah.

Mahmoud Alkhraishi: That's Happy to hear. Busy is wonderful.

Harrison Tang: I don't know about that. Sometimes it's good busy sometimes.

Mahmoud Alkhraishi: Sometimes not, but usually,…

Mahmoud Alkhraishi: Yeah. …

Harrison Tang: Yeah. Recently is one of those not so good busies.

Mahmoud Alkhraishi: I'm sorry to hear.

Harrison Tang: Yeah. Yeah. It's fine. up and down, right?

Mahmoud Alkhraishi: Actually,…

Harrison Tang: That's life.

Mahmoud Alkhraishi: it starts recording already, right? does it?

Harrison Tang: I thought you start recording at 9.

Mahmoud Alkhraishi: I don't know if it starts recording like this or if it
starts recording right away,…

Mahmoud Alkhraishi: I guess. no. It says this call is being recorded in the
top left.

Harrison Tang: All right.

Mahmoud Alkhraishi: I think we can't do any more pre-called vant anymore.

Harrison Tang: No. Okay. Yeah.

Mahmoud Alkhraishi: I know. But it does make it easier. So, it is what it
is.

Harrison Tang: Yeah. I thought the recording starts at 9:00 or something.
So, yeah. …

Mahmoud Alkhraishi: Shouldn't really matter. Yeah. Yeah.

Harrison Tang: I still like this better. I don't need to do the Yeah.

Mahmoud Alkhraishi: It's so much easier. Whenever I was doing the
traceability ones, it would be very annoying.

Harrison Tang: Andor, how's it going?

Mahmoud Alkhraishi: Hello.

Andor Kesselman: Good. How you doing?

Harrison Tang: Not bad.

Andor Kesselman: Are you back in Pasadena?

Harrison Tang: I don't travel as much as you guys.

Andor Kesselman: That's not bad.

Harrison Tang: Yep. …

Andor Kesselman: How was your IW, by the way? enjoy coming up here.

Harrison Tang: yeah. I thought it was my favorite conference to be very
frank. Yeah. Yeah.

Andor Kesselman: That's awesome.

Harrison Tang: Just kind of relax and then also technical. It's very
interesting.

Andor Kesselman: Yeah. Was there any presentation that particularly sparked
your interest?

Harrison Tang: Most recently I'm most interested in the not Feder visual
identity API.

Andor Kesselman: Yeah, way more presentation than I expected on NCD.

Harrison Tang: So that I attended a lot of those Google Chrome meetings and
obviously the MCP is I wouldn't call it all the rage but a lot of people
are talking about that right so yeah anything about LMS and Aentic AI it's
a hot thing to Hey Drummond, thank you. And Darl, thank you for joining us.

Drummond Reed: Glad to be here, Harrison. Thanks for inviting us.

Harrison Tang: Nowadays, these calls are automatically recorded. I don't
have to press the button or anything like that. So, you can start anytime.

Drummond Reed: Yeah, I've warned Andor that the L foundation also asked for
a meeting with the trust steering chairs at the same time slot too. So, I
have to monitor that in the background. So, I'm going to be on mute most of
the time.
00:05:00

Drummond Reed: Andor is going to be leading on this.

Harrison Tang: Sounds good.

Harrison Tang: Do you guys have a presentation this time or No, we just go.
you do. All right. And I think it would be good to do a recap of what IRA
is. It might be a repeat for some people, but I think a recap of about
three to five minutes will be great. Yeah. All right, we'll start right
away. I don't have to press the recording again. Thanks to for the new
infrastructure, it just does it automatically. so, I'll just Give me a
second. All right. So, welcome to this week's W3C TCG meeting. so today
we're very excited to have Endor, Daryl, and Drummond here to continue a
discussion on IRA.

Harrison Tang: So last time a couple weeks ago when we had a discussion on
IRA we had a great dis great conversation a lot of questions in fact we
couldn't get to all the questions last time so we actually invited them
back to continue this discussion but before we start just want a quick
reminder on the code of ethics and professional conduct just want to make
sure we continue to hold respectful and con constructive conversations here
a quick note on the intellectual property. Anyone can participate in these
calls. However, all substantive contributions to any CCG core items must be
member of the CCG with full IPR agreements so if you have any questions in
regards to getting a W3C account or the community contributor license
agreement, please feel free to reach out to any of the co-chairs. All
right. So these meetings are automatically recorded.

Harrison Tang: and we use Google meet inside GT and if you have any
questions please feel free to just press the raise hand button and then I
will moderate the queue. I just want to take a quick moment for the
introductions and reintroductions. So if you are new to the community or
you haven't been active and want to engage please feel free to just unmute.
I see mostly familiar people here. So, next I just want to take a moment
for the announcements and reminders. Any new announcements or upcoming
events or reminders?

Harrison Tang: any updates on the work items. So we will hold the next work
item update on July 15. So about two three months from now and then I'll
send out an email to remind all the project leads to help us update the
latest work item updates and developments. Anything people want to share on
the IW two weeks ago?

Harrison Tang: I think last week we take but just want to take a quick time
if people have further things to share. All right, pretty simple. I just
want to take the last calls for introductions, announcements, reminders,
work items, or any comments or administrative questions. All right. let's
get to the main agenda. So again, very excited to have Andor, Daryl, and
Drummond back to continue the discussion on IRA.

Harrison Tang: because they have presented last time Ira is trust
frameworks. So this is one of the biggest and the most interesting part
topic for me because at the end of the day technology can only go so far
right so trust has to be anchor somewhere and confidence is a very very
important thing. very excited to have them back and continue the
discussions. I think some of us have questions last time that we couldn't
get them to answer because we ran out of time. So please feel free to use
this opportunity to ask them about Kyra as well as the trust frameworks.
Eyes Close yours.
00:10:00

Andor Kesselman: And this is such an improved meeting over the Jity stuff.
This is nice to be able to screen share and everything else. So, I'm going
to share my screen and get going. First of all, thanks everybody and thank
you Harrison for always recording this stuff. just amazing work. this is
today we're going to go in a little bit more details about some of the
areas that previously we couldn't go into too much depth over. So last time
was kind of overview of what IRA is doing at a high level. today we're
going to get a little bit more how the trust network design works and get
into the sort of the nitty-gritty. but before that for those of you that
weren't a part of the previous presentation or don't remember kind of what
we do IRA is essentially a connector of ecosystems.

Andor Kesselman: So in most ecosystems there's a lot of data but it's
generally staying within an ecosystem. we have a pretty concrete definition
of what an ecosystem means from the context of IRA but initially IRA was
called the global acceptance network. and that's because our goal was to
help enable acceptance across ecosystems and move data out of sort of a
particular single ecosystem. And I don't know if anybody saw matter
recently came up with an article. I liked it so much I'm going to be using
a few slides or from the matter article about why we need And acceptance
networks allow us to create value across various data pipelines in a way
that just having the interoperability requirements don't satisfy.

Andor Kesselman: And what we mean by that is it enables the human trust
elements that allow us to accept on a functional level things from holders,
issuers, verifiers and so forth. So trust makes credentials legitimate but
acceptance makes them valuable and that's really important. So it's
challenging from the perspective of IRA. We have to deal with a lot of
different personas and sort of personalities. we have to deal with issuers
and so without an acceptance network issuers don't necessarily get the
value of being able to leverage your credentials across networks. we have
to also deal with the benefits for holders. so this is from the perspective
of you're a holder you want to move your data across a particular The
ability to r AC across interoperability and governance requirements allows
you to move from one ecosystem to the next.

Andor Kesselman: So there's a lot of value for verifiers, same sort of
deal. if you're a verifier and you want to be able to verify a party
outside of your ecosystem, you need to be able to understand the
interoperability requirements to be able to actually ask for presentation
as well as to be able to ingest the sort of trust elements around the
governance requirements. So IRA is helping with all three of these parties
as well as for integrators and developers. we allow basically this ability
for them to leverage some of the trust frameworks that we put together to
help sort of boost up this process. So there's a lot of benefits across
multiple parties for acceptance networks. It also means that IRA has to
think about all four of these layers when we're thinking about kind of the
network that we're providing above it. So quick pause here. Darl is our
executive director.

Andor Kesselman: he's on the call. I don't know if you want to add anything
here or Drummond, but just about quickly the high level value acceptance
network brings and…

Andor Kesselman: what we're doing here at IRA and then we'll continue on.

Darrell O'Donnell: No,…

Drummond Reed: Same thing.

Darrell O'Donnell: Andrew, I think you've captured it really well. I would
just keep taking it away and happy to answer any questions when they do
come up.

Andor Kesselman: All right. So, what does IRA do? we do a couple things. we
provide the infrastructure at a high level. we support these concepts of
clusters the ability for particular industries and verticals to get
together to basically create business value. and in terms we launch
particular cyber projects and PC's that help actually bring value.

Andor Kesselman: So one of our first projects for example you saw this
slide I think last time this is our project stages we have an exploration
stage a proposal stage development stage and execution stage and in each of
these stages we kind of go through this process where we go and find value
and then we go and deliver that value across the network. I see Daryl. Do
you want to add in here something or you're muted.

Andor Kesselman: You're still muted there.

Darrell O'Donnell: and…

Darrell O'Donnell: rebooted but no my video was on that's
00:15:00

Andor Kesselman: All so here's the first person project that was project
Drummond. Do you want to take this?

Andor Kesselman: This is a project that Drummond's been leading. you might
have heard around it. It was previewed a lot at IW. It's been a work in
progress, but it has been moving along with its…

Andor Kesselman: what we call an IRA project. I'll briefly hand it over to
Drummond to talk a little bit about this work and then we'll continue on.

Drummond Reed: Yeah, this is just one example of a project IRA is project
driven as we tackle whether they're credentialled projects or…

Drummond Reed: they're clusterled red le projects that Andrew will talk
about more later. in this case it's tackling proof of personhood in a
privacy preserving way. we first had a session on that at IW last October
and then wrote it up in the link you see there first person in the IRA
network credentials paper. We introduced the prospect we had a bunch of
sessions on it at IW what two weeks ago but as a they depend on the average
trust network to work across ecosystems. So we're proposing the one key
piece of this project is the first person governance framework at the IRA
association.

Drummond Reed: So that's just quick background on one example project again
one credential focused versus andor we'll talk more about cluster focused
projects as it goes the short answer to that is first person credentials
are a type of proof of personhood credential.

Andor Kesselman: Harrison. Go ahead.

Harrison Tang: Yeah, it's a quick clarification question like what is the
difference between a proof of personhood and first person credentials?

Drummond Reed: They're designed specifically to be privacy preserving using
CKP. but they're also based on what we call verifiable relationship
credentials which are proof of your first person relationships. Literally
the people, communities, and businesses with which you have a verified
relationship. So it's a social graph-based approach. as if you read the
Wikipedia article, you'll see the different approaches, biometric and
social graph-based it's social graph based but very privacy preserving and
it also results in a decentralized trust graph which has a bunch of other
uses. but I hope that answers your question.

Harrison Tang: Yes.

Drummond Reed: Harrison,…

Drummond Reed: you bet.

Darrell O'Donnell: We could also say,…

Darrell O'Donnell: the first person credential is a way of providing proof
of person.

Andor Kesselman: So before we move on and…

Andor Kesselman: we're going to get into how this actually works and what
we're actually doing here on a technical level, but before that any other
questions on what IRA does at a high level and projects and the sort of
goals of positionally before we move on to

Andor Kesselman: the actual, functionality. All right, we'll continue on.
so how does IRA work? So, everybody here is probably familiar with the
trust diamonds. You have a holder, an issuer, a verifier, and a trust
registry. this is actually taken from the technical white paper. the trust
registry is typically governed by a governance framework and a governing
body within an ecosystem. And this is traditionally a single ecosystem
credential exchange. And so if you're a verifier outside of the ecosystem,
you won't necessarily have the ability to actually get that data from the
ecosystem. There's a couple reasons why. first of all, each holder is going
to have the ability to interoperate differently with each verifier. So
there's technical variance. you don't know what credentials to ask for as a
verifier.

Andor Kesselman: you're going to have issues pulling the credentials out.
as well as from a governance level, it's difficult to understand the
business terms and the governance terms that you're interfacing with the
ecosystem on. And there's also, technical variation in how the delegation
and authorization chains work often by ecosystem. So, if you're familiar
with a lot of the work in the EU, for example, they're using IDF. there
There's a number of other ecosystems out there that are leveraging
different types of trust frameworks. And so as a verifier, if you're
outside of the ecosystem, so if you push the verifier outside the
ecosystem, it's very difficult to consume data as a data consumer and for
the holder to present that data to the verifier. So practically, IRA is
trying to solve those problems. It's trying to make those lines viable via
interoperability profiles and u a trust network.
00:20:00

Andor Kesselman: So we'll get into that in more detail, but at a high
level, this is kind of the problem that we're providing a solution any
questions here before I move on? All right. So what we do is we define the
technical interoperability requirements. We govern the wide operating
policies and provide the required infrastructure services. This is to keep
the network running. What we don't do is we are not an authority for any
member ecosystem. We're a peer and that's very important. We respect
ecosystem sovereignty. So we make sure not to and ever, prescribe this is
what an ecosystem must do in terms of their own operations. We're not an
issuer ourselves. there's a very limited case where we're issuing our own
memberships to our own members.

Andor Kesselman: But for ecosystems and participation in the network, we do
not issue and we do not provide ecosyem specific services. So we only
provide stuff at the network layer which is at a layer that uses multiple
ecosystems. it's not at any particular ecosystem. So this is all left to
the service providers, the issuers and the actual ecosystem to determine
how they want to operate their own ecosystem. So, as you can probably
imagine, ecosystem sovereignty was a very core principle in how we've built
a lot of the technology and how we've been thinking about this problem. And
so, that's just kind of how we've done a lot of this work. there's a few
different building blocks. in the trust network, we have the registry of
registries, a conformance test suite, and a type catalog as a fundamental
building blocks.

Andor Kesselman: The trust registry network is essentially giving the
information about who you can connect with. The conformist test suite gives
us the interoperability certifications to say that you can actually make a
connection. When we were initially starting IRA, one of the things we
thought about was the idea of how easy is it is it to for example accept a
business card or for payments to go through if you're using In that same
way for that a credit card system will be able to ingest a Visa card, we
want the same for other types of data, we want the same sort of
functionality and ease of use. and then a market of marketplace is a type
catalog where you can reference ecosystem specific schemas as well as
Iroled schemas.

Andor Kesselman: and at a very high level IRA association governs the Ibra
trust network which manages a registry of registries and that connects
within all the member ecosystems their own trust registry. So we're just
essentially a layer that sits alongside all these other ecosystems but we
do not govern those specific ecosystems and this is all linked together
over a conformance test suite that allows us to verify the connections
across these chains.

Andor Kesselman: And to participate as an ecosystem within the IRA trust
network, basically we have a governance framework and you have to go
through the governance process and as long as you comply with the
governance requirements, you'd be recognized and we basically prescribe
pres we provide in the meta registry network a recognition status to the
particular ecosystem under the governance frameworks that we have. So
that's the process of ecosystem participation. Drummond, do you want to add
anything to the governing process in general with IRA and how we're
thinking about governance and the amount of thought that went into the
governance procedures to manage the network?

Drummond Reed: Yeah I don't want to overdoubt it but since governance is of
what really is a decentralized global layer of trust registries it's a
critical function and one could argue it's the most important function we
actually have to operate the registry of registries function but mostly it
is about accepting ecosystems into that network and maintaining the right
information.

Drummond Reed: So I'm one of three members of the governance team that has
been working on this for over nine months now and a lot of it in the first
six months from July to December of last year was about setting up
governance of the IRA association itself as a Swiss association choosing
the jurisdiction and developing the articles and bylaws and working with
what we call the member advisory council to do that and now transitioning
into the full Swiss association which we will be publishing a site with all
of the u governance materials. We're working on that right now. So that
should be up here soon. and we've going to be working into the first
meeting of the transitional board next week.
00:25:00

Drummond Reed: So it's really governance setup for a global public utility.
and we invite feedback. there will be total of six membership classes that
will are being formalized and look forward to having anyone…

Drummond Reed: who wants to participate in any of those six classes do so.
that's a quick summary andor happy to answer any questions.

Andor Kesselman: Pause here.

Andor Kesselman: Does anybody have any questions on the higher level like
things that IRA does or the governance process and ecosystem participation?
Harrison, go ahead.

Harrison Tang: Yeah. Can you go a little bit into more details on the
governance framework for example what is the assurance levels for different
ecosystems? Is it just give example do you require certain amount of
adoption or…

Harrison Tang: because different ecosystems serve different industries. So
how do you kind of have a consistent quote like a better term universal
like acceptance level and governance across different industries?

Darrell O'Donnell: Yep.

Darrell O'Donnell: Harrison, I'll jump in on that one. We don't have an
assurance level that is consistent or universal. We make room for assurance
levels to be exchanged. So if a high assurance network wants to join, we
make sure that if they have an levels of assurance depending on how you
want to look at it concept in their ecosystem at the wire level we can
exchange that information and they need to follow their own governance and
processes to make sure that their assurance levels are followed inside
their ecosystem.

Darrell O'Donnell: We want to make sure that the outside world can see and
understand what that is, but they defer into that ecosystem for their
definition of their assurance levels. Does that help?

Harrison Tang: Got it. a followup question is on the conformance testing.
if different ecosystems has very different let's say schemas or different
assurance levels and…

Darrell O'Donnell: Yep. This gets into the various different levels at…

Harrison Tang: how do you en enforce con conformance across different
ecosystems?

Darrell O'Donnell: which we operate. One is at the global IRA level where
IRA is actually maintaining and managing a very small number of IRA network
credentials. Then we have the clusters these groups of ecosystems that are
doing that work themselves. They'd be defining what are the credential
formats what are the schema what are the values that are built in what are
the claims and attributes that are shared that would be according to their
own ecosystem level governance. underneath that is another concept of just
ecosystem specific and that's really totally up to them.

Harrison Tang: Thank

Andor Kesselman: And this diagram right here will show you…

Andor Kesselman: how depending on the alignment that you want by cluster
ecosystem or network credentials the conformance test suite will not be
testing every single ecosystem specific. it won't test specific layers, but
if you want to align your credentials with the overall IRA alignment of
conformance, if you'd like. So you can design either your credentials to be
more IRA aligned or keep them completely separate. It's up to you. we'll go
into this later as well, but just wanted to put this up since this was
brought up. Great questions for Harrison. I'll pull it back up. One second.
All right.

Andor Kesselman: And here are some of our members. and one of the things I
wanted to bring up is that a few of you folks might say trust registries
why do we even need them? Who's using them? Most of our members are using
trust registries in some capacity. So, a lot of our membership and we have
Daryl and Drummond here who would also speak to this, but a lot of our
membership joined in because they felt that there was value in connecting
their information they have with their trust registries and using the data
in their ecosystems across other ecosystems and vice versa to ingest and
leverage data from other ecosystems to their ecosystem. So, all these
members do use trust registries in some form.

Andor Kesselman: and so we're working with them today to be able to
actually deploy this in a sandbox environment. And, I don't know, Darl or
Dr, if you want to add anything to that. but just wanted to make sure
people are clear that, this is currently deployed technology people are
using in their own ecosystems. We're just connecting the pieces. so that's
kind of at a very high level why members joined us and how we help existing
infrastructure IRA profile. So, how do we actually make those lines? we
talked about, these two lines. I'm going to pull back here. We have these
green lines on the right. We have one here and we have two here. How do we
make them happen? we offer two profiles. sorry.
00:30:00

Andor Kesselman: One is an authority verification profile which will help
connect between the trust registry in a particular ecosystem for verifier
outside of it and the other one is verifiable credential exchange profile
which is probably what you're more familiar with which is simply the
presentation exchange requirements to be compatible with the network. we'll
focus on the authority verification profile. This is the sort of trust
layer of the profiles. And at a high level if you're a verifier outside the
ecosystem, if you're in ecosystem B and you want to connect with ecosystem
essentially there's two questions that are we think that you're going to be
asking to be able to make a trust decision. The first is do I recognize
this governance framework? how can I recognize this governance framework?
And the second one is this issuer that's authorized to issue this
credential within this governance framework.

Andor Kesselman: So there's a recognition question and an authorization
question and those two questions are required to trust data moving across
network and the authority verification profile bootstraps this process and
helps you answer those questions through a set of technical
interoperability requirements as well as the fact that IRA as an
association onboards people into their governance framework because you
trust IRA to do the proper governance procedures you can actually bootstrap
some of that process in terms of trust decision. So we're essentially
making the process to trust other ecosystems faster. This is the highle
summary of the verification profile. It's online but it is intended to be
used either if you're a trust registry vendor or a holder.

Andor Kesselman: These are all, vantage points that this authority
verification profile sort of impacts. and so it basically gives you the
current authority verification profile gives two queries. first is an
authorization query within a specific So an ecosystem knows who's
authorized to do what. IRA does it's not its business to manage an
ecosystems authorizations. That's an ecosystems layers sort of
responsibility. But what IRA does is tell the interoperability requirements
for a verifier outside the ecosystem to ask an ecosystem an authorization
question. Is this authorized to issue this credential? So is the DMV
authorized to issue for the US government is under the US governance
framework is the DMV authorized to issue driver's license as an example.
great name I'll pull back here.

Andor Kesselman: this is the link. we can send over the presentation deck.
we'll have to Darl, would you mind giving the link with an updated
permission set? Great question. Thanks, Z. so the first one is an
authorization question which IRA can't answer. The second one is a
recognition question which is this ecosystem recognized? And specifically
in the context of IRA, is this ecosystem recognized with IRA? So an
ecosystem joins the IRA trust network. They decide to participate with us.
We recognize him under the governance procedures. And now a member or
verifier outside the network can ask IRA, do you recognize this member? If
we say yes, then they can go and ask the authorization question. Is this
issuer authorized under this governance framework?

Andor Kesselman: So that's kind of the two main questions that we solve
through the verification profile. these are the technical requirements.
There's basically two pieces to this that are really important. The first
is the protocols and the establishment of how we actually make those
connections and' that red box. The second part is a description of how we
actually manage the identifiers for the ecosystem for the trust registry
for the clusters. so we'll go through the first piece and then we'll
eventually go to the second piece which is the identifier piece. So the
trust regarded query protocol recently went to public review and IRA is
using that and extending it to basically add in a few additional utility
functions on top of the existing query protocol work that has happened at
truster IP. So how does trusting query protocol work? If you have a system
of record which can be an open ID federation especially if you're in the EU
a lot of folks are rolling that out there.
00:35:00

Andor Kesselman: if you have an X509 PKI sort of system, if you have an
active directory or if you have any other system of record train, the idea
is that this is a bridging mechanism that allows you to have a uniform set
of APIs to connect with those systems. So it doesn't matter what sort of
methodology you use to manage your trust frameworks internally. this is an
exposing property that allows you to expose these APIs externally to
verifiers and it's standardizing that process. So it's relatively
lightweight. it's mostly just a few API calls, but using that you can
actually connect across ecosystems via your system of record. So that's the
basic structure of the TRQP and how it's going to work. and so we have
members today that are implementing it and bridging their ecosystems.

Andor Kesselman: even though they have very different systems of records
and very different ways of managing their trust relationships internally,
they can now expose them out to the rest of the network via the TRQP. I'll
pause here. Is there any questions on the protocol itself and how it will
work at a high level architecturally? Is this making sense to folks? I see
Philip's raised his hand.

Phillip Long: Yeah, I assume that you're going to be adding additional
bridges as time goes by.

Andor Kesselman: Go ahead, Great question. So we don't write the bridges
ourselves. This is for the ecosystem to write. So you have your own system
of record. You have your own ecosystem, but you want to be able to
participate in the network. You'll write your own bridge. And there might
be vendors eventually that write bridges to help you do this faster.

Andor Kesselman: But it's going to depend on how you've constructed your
own system of record. Demetri, go ahead. And I see Dr. in your head after.

Harrison Tang: Demetry, I think you're on mute.

Dmitri Zagidulin: Whoops. is it possible to see an example of the query or
is that later in the slides?

Andor Kesselman: Yeah, we can just go to the spec itself and we can show
you what that looks like. in the meantime, Dr.

Andor Kesselman: want to.

Drummond Reed: Yeah, that's actually coming up shortly.

Drummond Reed: All I was going to do was clarify or expand on. So we do
expect some call it bridges as for bridge code for common systems like the
ones shown here for there to be source code that gets developed. But then
adapting that bridge to a particular system of record will typically be an
integration job for that particular system. but the goal of the PRQP is
explicitly to be able to bridge across systems.

Drummond Reed: And that's why we'll get into the structure of the query
protocol coming up next.

Andor Kesselman: Yeah. So I think…

Andor Kesselman: what actually Demetri before we go to actual spec I have a
few slides that I think are going to answer that question a little more
succinctly than going through a spec but it will be referencing the spec
which has the actual content. So let me go through that those slides and
then hopefully that answers your question. so, I'm going to pull off. I'm
going to skip over here real quick. what? I'm going to go through these
slides and then it will get to your point, Demetri. Just give me a moment
here. So, …

Dmitri Zagidulin: No.

Andor Kesselman: the TRQP doesn't make opinionations identifiers.

Andor Kesselman: So even though you'll notice here that we have these
endpoints and connections, it's not going to describe for example to use
DID not X59 to use whatever URLs you want to for your identifiers. it's
agnostic to that. So IRA has opinionations on that. So there is a section
on this we'll go through it later but for now my point is there's no
opinionations on the tierp around this but it does provide a model for
ecosystems a set of abstract queries and an initial restful binding and
that distinction of how we've modeled it out is essentially we define the
base models for how we think about ecosystems and this is very important
we've then defined a few set of required sort of queries that are part to
be TRQP compliant and then an initial binding which is restful

Andor Kesselman: which actually defines the API endpoints that you'll
deploy on your system. and so if I pull off here, this in the spec itself,
we define something called an authority statement. And authority statements
are broken right now into four different types of authority statements. We
have recognition statements, delegation statements, and description
statements. And the difference between them is an authorization statement
is imposing suggesting a hierarchical relationship with the entity. So I'm
authorizing you for a recognition statement is assuming a peer
relationship. So this case IRA generally is doing a pure relationship
within the ecosystem. So it's recognition based. delegation is imposing a
relationship of it's on behalf of another entity.
00:40:00

Andor Kesselman: So I'm delegating to you, Dimmitri. you're doing something
on my behalf. And the description is a query that's about the information
on the ecosystem itself. So you'll notice here that we've separated out the
ecosystem governing authority and the trust registry operator. And there's
a very good reason for this in practice and also on a modeling basis.
There's often different folks that are running the trust registry and are
actually operators of trust registries. they're actually running the
services themselves and the ecosystem that is actually governing the
ecosystem requirements. And so they're two separate operating bodies they
can be together. So you can be an ecosystem that's also running your own
trust registry or you can outsource your trust registry operating work to
somebody else. But they do maintain separate authority statements because
they're separate beings.

Andor Kesselman: And it's important especially on a cryptographic basis if
you're signing something as an ecosystem that's different than if you're
signing something as a trust regry operator that's been delegated on behalf
of the ecosystem. So you'll see here the ecosystem governing authority
delegates to the trust registry operators on behalf of them to be able to
serve authority statements on their behalf. and so this is the baseline
model that desri describes most of the tier spec and this is how we kind of
view the world model around ecosystems and trust registries but this is
very important.

Andor Kesselman: Drummond, do you want to add anything to this?

Drummond Reed: No, I think you've done a good job. andor I think it's a
particularly important aspect to the TRQP architecture and protocol that
these roles are separate so that as you said andor ecosystem governing
authorities can use third party trust registry operators and they can use
more than one and trust registry operators can serve as many ecosystems as
they'd

Drummond Reed: some will operate their own for instance the Bhutan NDI
system is their ecosystem governor authority and they run their own trust
registry but others in the EU they'll have many different trust registries
so I think it's an important aspect of the design the one other

Drummond Reed: we point out in the spec is that this diagram clearly
separates there are authority statements from the trusty operator just
describing its own permissions and its own description of its trust
registry capabilities versus the ecosystem government authority and one of
the delegations they will make there delegation statements that will have
in there is to the trust royary operator what are they authorized to do on
behalf

Drummond Reed: of the ecosystem. So this gets down to questions around key
custodianship and stuff like that. So it's a pretty important distinction.
and that's also why the separation between ecosystem ids and trust registry
ids to enable that and…

Drummond Reed: that's probably as much commentary as anyone is interested
in right now. I see a couple questions coming up in chat andor

Andor Kesselman: Yep. Yeah.

Andor Kesselman: So Mick had a great question. trust is usually context and
it's usually associated with risk. Can I capture any of these ambiguities
in the protocol? So, you can ask and we'll actually go into what an
authority statement looks like, so we'll pull Mick. I'm going to answer
your question with another slide before that real quick. Dimmitri these
four que the bindings basically are HTTP restful queries that u map to
those statements right so essentially we define the patterns in the spec
around what are required to make these queries and then there's a restful
query that actually defines this is the endpoint you'll use these are the
parameters you'll use and yeah we can go through it but

Andor Kesselman: I want to get to answering Mick's question real quick and
then we can always pull off if we'd like to spend more time on the spec, we
can go through the actual spec and it will show you the details. yes. So
this is the slide. M to answer your question all four of them author
authorization recognition delegation and description basically follow this
pattern which is an authority ID an assertion and an entid entity ID. and
so within this model almost all the queries are constructed using this as a
baseline. and so for example for authorization query in context is the DMV
authorized in the context of the US government or California to issue
California driver's license right. That's different than is it issue
context to issue Nevada driver's license.
00:45:00

Andor Kesselman: So you can actually add that in the question itself.

Mic Bowman: is

Andor Kesselman: So, the assertion is the context that you're asking about.
Did that answer your question, Mick?

Darrell O'Donnell: I provided a different answer which is that you're
correct it is a boolean but you need to know what question to ask to get
more context which I think is what you're implying andor if the context you
can get more than your better non-bullan question that's not even English I
don't think you're always going to get a boolean is it or does it now hold
the authorization or not yes or no does it at a point in time did it hold
the authorization yes But depending on what question you're asking, you may
be able to get the resolution. But really, your trust decision is your
problem to make. This is a signal you're receiving.

Mic Bowman: So the authorization then is evidence the sequence becomes
evidence and then I make my own computation over that evidence in order to
make the determination.

Darrell O'Donnell: Yep. Correct.

Andor Kesselman: Awesome question,…

Darrell O'Donnell: Great words.

Mic Bowman: Perfect. Okay.

Darrell O'Donnell: Much better words than mine.

Mic Bowman: Thank you.

Andor Kesselman: M. any other questions on this before we move on? But
these are really good questions.

Drummond Reed: I'm going to say one thing andor…

Andor Kesselman: All right.

Drummond Reed: which is a lot of time went into trying to arrive at this as
simple a structure as possible because again if you think about what the
bridges are going to do into different systems of record they may have many
different ways of expressing and obviously it can get much more complex so
what the bridge is doing is both saying okay this is the question being
asked how do Okay, ask the native system of record and get an answer that
can then be returned in this world. So that's why we're aiming at the
greatest simplicity we could get

Andor Kesselman: And this took many months of discussion over trust IP's
working group on this. it was not easy to come at this diagram as well as
the previous diagram. That was a lot of debate back and forth about how
this should be structured and the breakout of trust registry operators from
ecosystems and this concept that an ecosystem in itself is kind of it's not
a service layer but it's an operating concept that matters pull off here.

Andor Kesselman: So now the identifier so we've talked about in the
authority verification pro profile we've talked about the TRQP and the
restful binding as being required and before we move on Demetri just so you
can see this is what that looks like on terms of how we define the baseline
requirements in terms of the ecosystem recognition query for example and
then if you look at the spec there's a swagger spec if you'd like to figure
out the API calls themselves. So that's just some information there.

Dmitri Zagidulin: Thanks. Yep. Makes sense.

Andor Kesselman: So now the identifiers, this is something that IRA has
made positions around and is working community around. but we have
perspective around how to make identifiers. So essentially it's the concept
here is that TRQP doesn't prescribe the identifier types but IRA does. The
ecosystem ids are ds.

Andor Kesselman: the trust res IDs or did and the entity ids we don't care
because that's within an ecosystem specific boundary but for a recognition
process ecosystems delegate to the trust registries and an ecosystem may
actually delegate to many trust registries right I might have 10 trust
registries that operate on my behalf that's fine that's your decision how
you want to delegate to your trust registries and a trust registry may also
serve multiple ecosystems you can think about trust registry providers
serving multiple ecosystems on behalf of them. So that's okay. That's kind
of in the model itself. but all the service routing, so the way that the
DISDs are constructed, the service routing is happening in DID itself. So
the way that the did is constructed,…

Darrell O'Donnell: That's a

Andor Kesselman: it has requirements around, how you define the service
endpoints. So essentially the ecosystem will have within it the DID for the
trust registries that are delegated on its behalf.
00:50:00

Andor Kesselman: those trust registries will have the service endpoints for
the actual service URLs that you can hit to get the API responses and make
the queries. So it's a two resolution sort of process but with that you can
basically build it however you want and you can control your own did. So
what's really cool about this is from a meta registry perspective and from
the perspective of what it takes to recognize an ecosystem within the IR u
network all you need is the ecosystem did and we let you run your did how
you want and it's just a registration of the ecosystem did that gives us
the power to actually do the recognition process.

Andor Kesselman: that's the minimum amount of information we need and
everything else happens in the DI itself and so you can update the
controllers you can manage it multiple controllers it's up to you how you
want to do it and that's really important it respects ecosystem sovereignty
and a number of other principles so that's the basic process and I'll pause
here any questions before I move on okay so I'm not going to go through
there is actually a live demo

Andor Kesselman: you can go check out there's a repo in let me pull up the
repo real quick and just send it over there's some resources here if
anybody wants to play with it there's a docker compose but this is docker
compose that allows you to spin up trust registry as a trust registry
provider also Ira as an ecosystem meta registry network spin it up this is
using dip pure in this case just because it's really easy to spin it up on
the fly but you can easily just spin those ds up and it will have all the
resolutions around how the divids are actually constructed and the process
for creating those ds. So that happens in that code. and what's really nice
is because all the routing is done on the DID layer and it's all encoded
into the recognition and authorization queries are really simple.

Andor Kesselman: You just have to have the authorization the three parts
essentially all the routing happens in those three parts. So you just have
to be able to give the did of the ecosystem the IRA in this case for
recognition and the scope that you're interested in quering IRA trust
network for and you get the response about whether this ecosystem is
recognized under the IRA trust framework. And similarly for authorization,
if you want to check the authorization status of a particular entity, you
would need the entity ID, the DID of the ecosystem that you're asking about
and the authorization string. So that's kind of the baseline requirements
you would need to actually check an or check authorization query or
recognition query which is either checking Irish trust network to see if
we've recognized an ecosystem or an authorization of a particular ecosystem
with respect to its entities that it's managing.

Andor Kesselman: Any questions there? And this is all in that resources
that I just sent over. The docker compos will also spin this up which is a
little code that can run this all. So if you have any questions you can
feel free to run in and ask questions after. it's really important to note
that IRA is not the exclusive governance body that can only run this
infrastructure. anybody can go and spin up a network. IRA is really well
positioned because of its neutrality and governance and its fact it's the
Swiss association and it's done all this governance work around it but we
made it very a conscious decision in this design process to allow for other
networks to make sure that we weren't the only network. So if anybody in
the future wants to go build a network they can. Obviously Iris put a lot
of work into make it a really good place to do this work but it's not an
exclusive network and we allow that by design.

Andor Kesselman: It allows for other networks to exist.

Darrell O'Donnell: I'll add a word that we encourage it.

Darrell O'Donnell: Allow is a pretty strong word. We're not the arbiter of
truth.

Andor Kesselman: Any questions on this before I move on? So clusters, we
talked about clusters and this concept that for example a financial cluster
or mobility cluster, there are clusters of business activity that need to
get together and do things that are aligned across a number of ecosystems.
And so we have two types of clusters. We have industry-ledd clusters and
Iled industryledd clusters are driven by organizations.

Andor Kesselman: and Iled clusters are things like the first person project
which are addressing things like network credentials. These are IRA
specific clusters that are focused on a more niche set of use cases. but
those two clusters technically use the same mechanics that the rest of the
network A cluster is just an ecosystem that supports multiple ecosystems.
So it's just a registry of registries. So in this case a cluster is simply
us recognizing the ecosystem d of the cluster which is a meta registry
network in itself that manages a list of of valid registries within the
cluster. So the mechanics stay the same if you're in a cluster or if you're
a single ecosystem.
00:55:00

Andor Kesselman: from an IRA perspective, we just register the DID and if
you comply with the authority verification profile, you're good to go. And
we can just recognize clusters as well pretty easily. additional tooling
required. So, that's a nice little feature of kind of what we've put
together. I'll pause here. We're off the authority verification profile
piece. Any questions before I move on about authority verification, how it
works, or anything that you like clarity on? I'm not sure if I'm
pronouncing right, Coyote.

Kayode Ezike: That was great. Thank you. so earlier Darl had mentioned that
you need to basically know the questions to ask to get the right
authorization statements. interested to know how a member participating in
this network would know the questions to answer. Is that defined by the
ecosystem like the assertions and the entity ids? Are those all things that
are defined ecosystem? Is there a way to kind of be able to get a sense of
all the possible authority statements that could be made in a given
ecosystem?

Kayode Ezike: Just a little bit clarity on that would be good. Thanks.

Darrell O'Donnell: Yeah. …

Darrell O'Donnell: great question. every ecosystem needs to be able to
assert, what are the things it is our data for as part of their governance
process. So, if we, for example, looked at AMVA I don't really know what it
stands for, association of motor vehicle associations or something. they
are authoritative for maintaining the list of keys that are used for mobile
driver's licenses. They would need to come up with some kind of terminology
that would say here's how you ask about that authority. There is guidance
in the specification itself on the vocabulary to use. So there'll be a
issue slash US driver's license or something like that. also might be a
verify slash US driver's license.

Darrell O'Donnell: you need to know what a little bit about that ecosystem
that should be in their governance framework. Additionally, what we're
doing the IRA side of things. So the TRQP is really two questions. We add a
few more that say, hey, here are the lookups for that particular ecosystem.
So you would be able to programmatically ask for what those are. It's still
on you to understand what those terms are because if it says issue slashdl,
you may not know what that is. You still have to go to the governance to
understand what's that lookup mean. But you'd quickly get through their
governance docs to say, this means they can issue a driver's license or
whatever those things are." Does that help?

Kayode Ezike: Got It does. Thanks.

Andor Kesselman: Drummond has his hand up real quick.

Andor Kesselman: There's also in the credentials themselves some
information that will get propagated depending on if it's a network
credential. So we'll have some things around what information gets
propagated in network credential which helps you guide through that
process. But Drummond, your hands Go ahead.

Drummond Reed: Yeah, I just…

Drummond Reed: because you folks are getting right into what we call a
vocabulary question and it's a really good one. I put a link in the chat to
the wiki page we have at Trust AP on query vocabulary and a bunch of
assertions I mean proposals there. We'd love your feedback and input about
this whether it becomes part of the spec or…

Drummond Reed: it's a separate spec. but obviously the more standardized
you have vocabulary for common queries across ecosystems the more
interoperability we'll have. So please do provide us feedback there. X

Andor Kesselman: And…

Andor Kesselman: I see another hand, Erica.

Erica Connell: Long time listener, first time caller, and maybe this is a
stupid question, but how is this not just using decentralized tech inside
of a centralized system that does a phone home thing? isn't that I'll just
leave that there.

Darrell O'Donnell: No, that's a question we get all the time. you don't
need to check a trust registry all the time. You can go and grab that. And
if you're part of an ecosystem, you may have other ways of grabbing that.
One of the capabilities of the trust require protocol had in the past, but
we're probably going to move it into one of our profiles, which is a
download the data so you can just do your checks on the fly. At some point,
you're going to be asking an authority, is this true or not? If you call
that phone home, great. That's fine. But if I need to know who are the
issuers of American driver's licenses and I'm not willing to ask AMVA, I
don't have an answer. Keep in mind, each ecosystem is its own place to go.
So, there's no one monitoring where You're asking for a driver's license
here and you're asking for a national ID over here.
01:00:00

Darrell O'Donnell: There's no one monitoring that kind of thing, but you're
going back to an authority at some point and…

Andor Kesselman: Drum your hands up.

Darrell O'Donnell: grabbing some data. That's definitely true. Does that
help, Erica?

Drummond Reed: Yeah, I put in my head I want to double down on the point
that trust registries are as centralized or decentralized as the ecosystems
they represent. And if you think about having a trust registry for school,
your company, your neighborhood, that's the way we're thinking. And TRQP, I
mean DNS is a hierarchical system. and therefore it's fairly efficient to
navigate and the performance is pretty good. Trust registries are not
hierarchical.

Drummond Reed: they can have hierarchy within a country or something like
that but otherwise we're designing TRQP to be able to navigate as
efficiently as we can across heterarchical trust registries and when you
get to what I hope will be happening millions and millions of trust
registries it'll be very hard to say yes every single one is centralized
and the whole system is decentralized that's what we're

Darrell O'Donnell: Yeah, the phrase we use not just internally but around
is there inappropriate centralization. So if I use my working example of
who are the authoritative American driver's license issuers, I know the
authority to go to. not easily I could maintain that myself by contacting
each of the DMVs on a regular basis and maintaining my own list and that's
my choice. I can do that absolutely or I could defer that to the Ava side
and decide if there's some phone home problem there that I'm constantly
doing that they may know I'm checking a lot of driver's licenses great
maybe I can cash that information check it daily there's strategies for
addressing what I would call inappropriate centralization I think what
we're seeing with the protocol to Drummond's point the protocol itself

Darrell O'Donnell: We don't right now believe it drives towards
inappropriate centralization. It may allow for someone to create a
canonical set of the mother of all trust registries, but I think the parts
of the community at least, would definitely push back against that.

Andor Kesselman: We are Harrison I don't know we are out of time so I don't
know how we want to handle it there's more slides but I think I'm happy to
call it here and…

Andor Kesselman: and this was the main point was the authority verification
profile so we got through most of the meat of the presentation Yeah.

Harrison Tang: I can follow up with you …

Harrison Tang: because I think some people might have to drop, but I can
follow up with you on these topics like network credentials and so on. Yeah.

Andor Kesselman: And feel free to ask us questions. we're around a lot of
really good questions on this call. So, thank you folks for listening. And
I hope this this makes sense. And if something's not making sense, feel
free to just ask and we'll, talk to you about it and we can work through it.

Harrison Tang: Sounds good. Thank you. Thanks, Andor.

Andor Kesselman: That's

Harrison Tang: Thanks, Drummond. And thanks, Daryl. Thanks a lot. Bye.
Meeting ended after 01:03:59 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*