[MINUTES] CCG Incubation and Promotion 2025-07-23

CCG Incubation and Promotion Meeting Summary - 2025/07/23

*Topics Covered:*

   -

   *Review of Issuer and Verifier Registries:* The meeting focused on
   harmonizing different specifications for issuer and verifier registries
   within the verifiable credentials ecosystem. Discussions centered around
   the Open ID Federation specification and the CCG's own verifiable issuer
   and verifier list.
   -

   *Comparison of Specifications:* Attendees compared the Open ID
   Federation specification with the CCG's specification, highlighting
   similarities and differences in functionality, data models, and
   implementation complexity. Key differences included support for DIDs, the
   use of JWT formats versus other formats, and handling of trust chains
   (e.g., X.509 vs. DID-based). The challenges of integrating different
   specifications and the burden on developers were discussed.
   -

   *Data Model Harmonization:* A significant portion of the meeting was
   dedicated to defining a common data model that could be used across
   different specifications and frameworks. The goal was to create a flexible
   model that would address various use cases and be easily integrated into
   existing systems, such as Open ID Federation and verifiable credential
   implementations.
   -

   *Addressing Centralization Concerns:* Concerns regarding the
   centralization of trust in existing specifications were raised. Discussions
   explored ways to mitigate this, particularly in scenarios with many
   dispersed issuers, such as in the first responder ecosystem.
   -

   *Next Steps and Action Items:* The group agreed to focus on harmonizing
   the data model in the next meeting. This will involve comparing existing
   data models from different specifications, identifying necessary fields,
   and addressing implementation concerns. The possibility of creating an Open
   ID Federation profile that incorporates DID support and addresses other
   relevant aspects was also considered.

*Key Points:*

   - Multiple specifications for issuer and verifier registries exist,
   leading to interoperability challenges.
   - The Open ID Federation specification has limitations, including lack
   of DID support and potential centralization concerns.
   - The CCG's verifiable issuer and verifier list aims for broader
   interoperability and decentralized approaches.
   - A harmonized data model is crucial for achieving interoperability
   across different frameworks.
   - A key challenge lies in balancing standardization with the needs of
   various ecosystems and avoiding excessive complexity.
   - The group will focus on data model harmonization in the following
   week's meeting.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-07-23.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-07-23.mp4
*CCG Incubation and Promotion - 2025/07/23 10:58 EDT - Transcript*
*Attendees*

Alex Higuera, Benjamin Young, Denken Chen, Dmitri Zagidulin, Isaac
Henderson, James Chartrand, Jesse Wright, John's Notetaker, Manu Sporny,
Parth Bhatt, Ted Thibodeau Jr, Tom Jones
*Transcript*

Manu Sporny: Hey, Thank you for being here today. hey, James, would you
mind? So, I don't know if Alex or Demetri has given you any heads up on
what we're discussing today, but I believe it's your work on the issuer
stuff that you did with MIT and DCC. there's Dimmitri. would you mind of
you and Dimmitri walking us through the work at a kind of basic level
today? Just what were you trying to achieve? what did you end up creating?
What were the lessons learned there?

Manu Sporny: I think what we're largely trying to do today is we are trying
to make sure that we have everyone that's done, trusted issuer verifier,
list some whatever variation of it that's in the verifiable credentials
ecosystem. We want to make sure that we know about that stuff and it goes
in as input into this specification so that when it gets to the working
group, we've got a good understanding of the work done in the space so that
once we standardize it, it works for everyone. that's the general what
we're trying to get to. we don't have to get through all of it today. but
it would be nice to get through the overview today.

Manu Sporny: And then my expectation is there going to be actions for us to
do after you go through it so that we kind of understand…

Manu Sporny: what updates we need to make to the list. Does that make
sense, James? Excellent.

James Chartrand: It does,…

James Chartrand: but I don't want to take credit for something I haven't
done. and so I didn't write the code for the issuer registry. it was
somebody else that did that. But maybe what's more relevant is I think the
design choices and the architecture choices that went into the registry.
And I think Dimmitri is the person to go over that. But, I'm happy if
things come up about the implementation, which is an AWS implementation of
it, talk about that, but I expect that's not really what people are
interested in here today.

James Chartrand: So, I pass it on to Dimmitri.

Manu Sporny: Okay, wonderful then.

Manu Sporny: Wonderful. There's Dimmitri. and so I guess then Dmitri, do
you mind taking us through kind of the general design and stuff like that?
Okay. All right.

Dmitri Zagidulin: Not at all.

Dmitri Zagidulin: Not at all.

Manu Sporny: Yep.

Dmitri Zagidulin: And thank you so much, context and how's my sound
quality? Can you hear me?

Manu Sporny: It's good. Yep.

Dmitri Zagidulin: Great. So project was essentially to advance the
state-of-the-art in issure and verify registries in the field of education.
in all of our project we were increasingly coming up against the fact that
in a open enough world use case, Instead of there's one major issuer that
everybody knows the government or whatever, No, we have a bunch of
different issuers, bunch of universities, even within a university,
multiple professors have their own issuing keys, multiple departments,
right?

Dmitri Zagidulin: So we have full-on open world ecosystem and basically we
can't really do anything with verifiable credentials without some sort of
issue of registry. otherwise right I can pass off diploma from Dimmitri's
legitimate college and pass it off as MIT so that was our goal. let's push
the education corner of the world to recognize the problem and offer some
solutions. So the scope of the project was review existing issue and
verifier registry specs, write a report on it. or rather no review pick one
or more, but we ended up picking one just because of the time pressure and
budget and things like that.

Dmitri Zagidulin: pick one, implement a sample issue registry and operate
it for a number of months, right? So that was the deal. Review the specs,
pick one, implement the MVP, barebones version of it and operate it and
write a report about it. And it's actually a paper. It's going to be
published in some journal or other, I forget. Alex, if you remember, please
of the blog post that the links to the report on medium. so that was the
deal, right?
00:05:00

Dmitri Zagidulin: So we formed a long list of issuer specs and it's all the
things that you're familiar with including our CCG verified issuers and
verifiers open ID federation draft diffs I always forget the name it's like
verifiable credential trust establishment right but again it's same spec
dealing with not just issuers but which types of credentials they're
authorized to issue, and then all the other external specs like train the
various trust over IP properties I always forget the name of the
organization that does international passports and keeps those keys. So
basically we did a fairly wide search.

Dmitri Zagidulin: I can't say yeah so we took a look at all of the specs.
they're all largely trying to do the same with some variations of this spec
has affordances for listing which types of credentials an issuer is allowed
to issue and this one doesn't but this one has key history and this one
doesn't right so they're all trying to do the same thing which have an
identifier look it up get back some sort of JSON or seabore object that
says here's what we know about this issuer and that's it.

Dmitri Zagidulin: So all the specs fairly equivalent. we decided to go with
open ID federation just due to ease of implementation and momentum
recognition of the brand name and momentum of there was Italy and Sweden
that did issue registry pilots with it. so we wanted to sort of learn from
those lessons. we had one of our developers implement a very bare bones
JavaScript express type of server that implements one or two of the
endpoints in the spec and the data model and the key signing and the did
signing.

Dmitri Zagidulin: We did a little bit of sort of advocacy work with the
open federation because one of the sort of shortcomings of the spec is that
it is ex of the open federation spec is that it explicitly anti-ID
literally says identifiers have to be HTTPS URLs period. and when we're did
the usual elements are like DS just https but we basically said listen we
have this giant ecosystem we need ds there's nothing right like we're just
going to fork your spec if you don't add it. which is essentially what it
ends up being a profile of here's how you a did is share registry on top of
the foundation of open federation.

Dmitri Zagidulin: So that there was also a lot of user and developer
education in the sense that some of the partners in the project like
credential engine weren't really familiar with the world of verifiable
credentials with issuers with digital signatures. And so that there's a lot
of outreach and a lot of education on this is what it means to have a did
here is how you would ask your members to generate a did so that it can go
into the registry so that they can issue credentials with it so that they
can later be recognized by the verifiers all of that kind of stuff.

Dmitri Zagidulin: so I think there's a couple of instances running. There's
a dcc registry and the credential engine registry built on top of this
server. the back end is very bare bones. It's a JSON object in a GitHub and
the server powers the API endpoints off of that. We also recognized that
the main point of the project, at least from my perspective, was to just
start to get things started because the various specifications are pretty
much feature equivalent.

Dmitri Zagidulin: Once we implemented one and once we had our database of
whatever 10 issuers served in the open federation trustmark data model it
would be trivial to also publish the CCG verified shares and verifiers
version the diff version if we needed for some reason and so on. Okay, I'll
stop there. give me questions.
00:10:00

Dmitri Zagidulin: Yeah. Mhm.

Manu Sporny: I think thank you Dmitri for the background on it.

Manu Sporny: I think the big challenge we have right now is that there all
these different mechanisms. and when it comes to kind of implementation
burden as the more mechanisms that exist out there the chances that we fail
to interop because some things are published in one format versus another
format and there's only so much money and developer effort that that can go
into implementing these things.

Manu Sporny: So, looking at what we have in the CCG thing and looking
what's in Open ID Federation, they seem very different things I think Isaac
and David have largely put together what's in train into the CCG spec. and
looking at Open ID Federation, there are a few fields that overlap, but by
and large a lot of it, doesn't. I think the federation spec defines HTTP
endpoints that you have to implement. The CCG spec does not do that. how I
know that you said the goal here was to just start and you can always
convert the database into different formats.

Manu Sporny: I'm trying to figure out what we would need to specify in the
CCG spec, I guess, to make that process easier.

Dmitri Zagidulin: Yeah. …

Dmitri Zagidulin: I have a couple thoughts on this. So, one thing and again
this is probably to be expected but one thing that we've learned is that
the really difficult parts about implementing an issue registry is not
particular pe the difficult parts are shared among all of the specs. For
example, the hardest part is to explain to issuer members that they needs,
how to manage them, and how to manage keys, and how to prove control DID to
the registry, So that's a hard lift that every single spec of issuers will
need to do, right?

Dmitri Zagidulin: so I do want to reiterate that most of the effort of
implementation is not going to be which format spec yes there's going to be
a tiny bit of difference in effort in teaching people about data integrity
versus JWT signing but all of that stuff is minimal. Okay, so putting that
aside, the open federation spec as is insufficient to operate a proper
issue registry. It needs in my mind three different additions which would
also incidentally make it pretty much isomorphic to

Dmitri Zagidulin: it to CCG issuers and verifiers. In terms of fields, the
open federation spec is often with OIDF type specs is open-ended, right?
here's a couple of required or recommended fields and then you can put
everything else. So, we ended up adding a lot of fields to the right for
example with universities there's the name and the legal name of the
institution, right? And it's got to be those two and a lot of the facts
don't really differentiate between those two different right so it's like
name Harvard University legal name the August Association of Howard Deans
or something like that Harvard deans so okay but back to your questions so
in my mind I think what we should do or what this group can

Dmitri Zagidulin: do and I would love to help out with it is to do a zoom
in comparison of basically whenever you're doing an initial registry
regardless of which spec you're going to do these are the concepts and
these are the fields you're going to need but back to what will need to be
added and changed to the open ID federation spec to bring it to feature par
with let's say issuers and verifiers. obviously support fors but that's It
just ignore the line that says identifiers must be it only requires to
implement two endpoints.
00:15:00

Dmitri Zagidulin: one is a static metadata discovery like a well-known file
and the other one is the actual endpoint where you look up the information
about an issuer. So it's very lightweight implementation. so we'll need to
list the fields that other specs verified is verifiers list and how they
would translate to federation. We would need to show an example of because
essentially there's three different ways to consume an issue registry.

Dmitri Zagidulin: one did and get some information. There is look up all of
the issuers in the registry in a big detailed list, So that you can cach it
so that you can mitigate phone home concerns. So that's a second way to
consume it. And then the third way is for the receiver to receive a
verifiable credential that our issuer is in that registry and then hand it
over with the credential. Right? so the offline kind of usage the phone
home protected usage of I'm going to carry the proof of inclusion in the
registry with me and present it alongside my verifiable credential to the
verifier. Right? So there's those three different modes.

Dmitri Zagidulin: and OB federation does the first mode like look up one
identifier here it is and all the caching mitigation strategies apply there
it does the second mode get the list of everything halfway what do I mean
by halfway it has an endpoint that says give me the list of all of the
divids in your registry but it's not a detail list it is literally a list
of strings that is like dids here's and then the caching verifier would
need to request each individual did get the detail entry and then cach
those.

Dmitri Zagidulin: So I think to match the convenience of verified issues
and verifiers which does if I understood the spec correctly does have the
notion of here's a detailed list of all of the issues in a recommendation
so that you can download it and c it. And then the third way of the offline
the proof of inclusion method the open federation also supports but it
needs to be illustrated and encouraged and recommended. I'll pause there
and unfortunately wait not going to pause.

Dmitri Zagidulin: Unfortunately, as with everything in engineering and
identity, everything is a trade-off. So, we will need to surface to
developers the trade-off of here's the advantage of downloading the
detailed list of all of the issuers. Advantage eminently cachable. You
don't have to phone home when you're the verifier when looking up an
individual entity. Good disadvantage.

Dmitri Zagidulin: what happens if the issue registry is thousands or
millions of entries at minimum downloading and parsing that JSON is going
to overflow the memory of your parser on your mobile verifier or even on
your serverbased verifier right once the list gets big enough you either
need to deal with pageionation

Dmitri Zagidulin: or you take a page from the event log spec and do it in
JSON lines format so that it's streamable so that it's not one giant JSON
document that you have to load into parser memory right so we need to
surface that advantage more cachable disadvantage if it's big enough it's
going to be awkward to download and it's going to overflow your memory and
parsing similarly Advantage in looking up oneoff advantage it's just in
time you need to cash anything disadvantage there's the phone home concern
and then third the proof of inclusion advantage that it's all capable but
also it's much more complicated on the part of the wallet the presenter the
verifier and all that stuff okay now I'm going to pause there for questions
and
00:20:00

Manu Sporny: All right, Isaac, I guess as one of the editors for the
verifiable issuer and…

Manu Sporny: verifier spec, what are your thoughts

Isaac Henderson: Yeah. Yeah.

Isaac Henderson: So I also saw the thanks Dimmitri for the presentation or…

Dmitri Zagidulin: Yeah. Yeah.

Isaac Henderson: the overview so I see quite your specification or the
issue and verifier list is specific to the open ID federation first of all
and also you are having a didbased identifier to do this approach right so
these are some of the things which I see so I see it's a kind of one of the
implementation of trust registry right whereas how I see the difference of
our implementation or our spec is towards so it's also a little bit
different

Isaac Henderson: from train because so we are not proposing any a component
for doing discovery and validation but rather we are trying to propose a
meta data model which can be integrated into any issuer or registries
existing one or even to open ID federation metadatas because currently not
all the specification consider this because they just take the public key
and log it in a JSON file and then publish it which is easy but especially
with this current new techn technologies coming up depending upon the level
of asurances you might need more parameters to validate some
trustworthiness of the transaction.

Isaac Henderson: So that's where our approach comes in where we also
inspire from the Etsy trust list although Etsy didn't cover the
decentralized aspect still at where they are trying to do their own part
but we in forehand we already took it out and…

Dmitri Zagidulin: Excellent.

Isaac Henderson: we have adapted the list to accommodate the decentralized
identity aspects and also even the policy and contract aspect also into it
actually so that's why I see this

Isaac Henderson: This is not only just for user credentials or end user
oriented but also it can be also applied to mission credentials or supply
chain aspects so they can also get inspiration and apply this metadata over
there actually to their implementation and the verifiable credential format
or the encapsulation what we provided is also kind of in order to prevent
this XML or JSON format list can be in any type because sometimes

Isaac Henderson: The C is in XML but we proposed in JSON so it can be
easily integrable in different existing trust registries and also the
provenence proof can also make sure that the lightweight approach not
rather than having different kinds of signature suits XML zades or jers and
different other SIBO based one rather we say okay but that is something out
of scope we just propose or consider as a recommendation but the main idea
what we propose is to give a meta datas which can be leveraged by other
trust registries and also used by other ecosystems So that is our aim to
specify as a part of this spec and till now we just proposed a generalized
one.

Isaac Henderson: So when we are part of a working group, we thought to
undergo different use cases and standardize for example or create profiles
telling which fields are optional or…

Isaac Henderson: which fields are mandatory based on the use cases so that
it will be also lightweight actually and also it can be easily integrable
with the existing system. So that's our approach for the next plan or the
next months ahead.

Dmitri Zagidulin: I like that. I think that's a really good approach. I
really do think that we can show okay if you've got a verified issues and
verified registry and you've got these rich fields of a metadata here's
like literally you can plot them into the trust mark entity detail from
open federation and…

Dmitri Zagidulin:

Isaac Henderson: Yeah. Yeah.

Dmitri Zagidulin: vice versa right so I do think we can make them
intermappable interesting that Tom mentions in chat that primary problem I
see is that user experience is intolerable.

Isaac Henderson: Yeah. Exactly.

Dmitri Zagidulin: I would strongly disagree with that. The user experience
is absolutely convenient and invisible. because how are these things
consumed? for example, so we built in clients for these registries into our
wallet and into our verifier plus both open source. And what it does is
presents the credential in the background. The wallet contacts all of the
issue registries that it knows about queries or looks up in a cached list
the details about the entity and presents it to the user says this is an
unrecognized this did corresponds to MIT in this registry some other entry
in another registry right and flags conflicts and stuff like that.
00:25:00

Dmitri Zagidulin: So, I would disagree about the I think user experience is
excellent unless I'm missing something. Unless you're talking about some
other user experience.

Manu Sporny: So I'm trying to understand Dimmitri if you're saying we
should stop working on the verifiable issuers and verifiers specification
and just use open ID federation.

Dmitri Zagidulin: I think we should define a profile of openity federation
usable for purposes of did issure registries basically or I do think we
will gain more so even then in the various drama between JSON deverable
credentials versus JWT based and how some people think okay yeah we'll have
an advantage in developer recognition if we go the JWT route.

Dmitri Zagidulin: I think the advantage of open federation is more momentum
and recognition wise just because of existing entities in common and
internet 2 that already issue registries but in XML sample format they are
much more receptive to be like we know we're going to have to migrate to
open federation soon rather than an unknown format relatively unknown a
W3C1. So do I basically think that regardless what happens we need to merge
these specs. We need to merge these specs.

Dmitri Zagidulin: We need to merge the good security properties of issuer
and verifiers and bring them to open federation and we need to merge some
of the fields that open federation has that verified right we need to make
them equivalent basically it's one way or…

Dmitri Zagidulin: another whether that's focusing on a profile open
federation or focusing on verified issues and verifiers and then having a
side document a note that says here's how you translate from one to the
other that I don't know strategically

Isaac Henderson: Yeah. So from my understanding or…

Isaac Henderson: or for example especially at least in the context of
European Union and also way how the wallets are being currently addressed
open ID federation is suggested as a implement it's suggested or as a
recommendation for implementation or as a trust framework for example
because still I think the EU they will be using the HC based trust list
with an updated version so

Isaac Henderson: because we also contacted the chair who is also working on
this one they said they are planning to also make it more global. So the
Etsy list where they will also be able to take the updates from the
research whatever we did as part of this one the implementations in the
verifiable issuer and verifier they'll be taking as a recommendation into
their spec before applying for ESO standard. So because they are also
planning for a ESO standard in a different way but they are not open source
right so they have their own organization and to do that but rather I think
they see also the value because the feedback what we got from them was
there is a lot of potential and the feedback and they said only by October
they can decide there will be an open draft available for public review and
we are planning to address our comments as part of that actually so that's
also

Dmitri Zagidulin: Wait, wait.

Dmitri Zagidulin: Which specification is going to have a open draft by Got
it. Understood.

Isaac Henderson: let's see let's see one yeah…

Isaac Henderson: because still in the current implementation of wallets
what's currently going on EU for pit users and stuff they are planning to
use the existing trust framework theas version one so the version two might
take more years so I think the base metadata …
00:30:00

Isaac Henderson: which they'll be trusting is the EAS version one. So
that's how it looks like at this point of time. Yeah.

Dmitri Zagidulin: easy. Okay.

Dmitri Zagidulin: Just out of curiosity for testing and comparison. so
we're running a couple so DC is running a ODF based registry and credential
engine. Is anybody running a verified issued and…

Dmitri Zagidulin: verifier registry of known issuers that we can interact
with?

Isaac Henderson: So currently it was already piloted as a part of the Gaia
X federation services …

Isaac Henderson: but we are also hosting one of the trust list actually in
our infrastructure. So currently it is you can definitely add and…

Dmitri Zagidulin: And would we be able to add our DS to it for testing?

Isaac Henderson: also you could add and…

Isaac Henderson: then we could also provide the details for it. down. That
should be also possib

Dmitri Zagidulin: Great.

Dmitri Zagidulin: That sounds wonderful.

Manu Sporny: And we are triing stuff with some of our customers based on
the verifiable issues and verifiers. Just kind of a general it's not an
implementation yet. but we had looked at open id federation and…

Manu Sporny: had decided not to use it because of the level of complexity
that comes along with it and…

Dmitri Zagidulin: Wait, wait,…

Dmitri Zagidulin: I would push back on the complexity.

Manu Sporny: and the non-sup support of DIDs, right? I mean ds were kind of
a

Dmitri Zagidulin: It is extremely simple to implement. It is literally one
endpoint with one query parameter that says did equals this get back some
JSON expl explaining it.

Dmitri Zagidulin: I would say the level of complexity is very minimal. Now
the phone home concerns definitely valid. but complexity wise I would push
back on that.

Manu Sporny: meaning you do have to use the JWT format.

Manu Sporny: You have to use the …

Dmitri Zagidulin: Yes, you do need Yes.

Manu Sporny: there are number of mandatory to implement requirements in the
spec that were kind of non-starters for the ecosystems that we were in.

Dmitri Zagidulin: Yes. Right,…

Manu Sporny: meaning we would end up violating many things that are in the
spec. doesn't support data integrity. It doesn't support DIDs all that kind
of stuff requires the use of VEX509 in some chaining use cases.

Dmitri Zagidulin: right, right,…

Manu Sporny: there are a number of things there…

Dmitri Zagidulin:

Dmitri Zagidulin: right, right, right, right, right. Yeah.

Manu Sporny: where it's kind of like it's more centralized than we were
able to do the other I guess concern here was that there's a presumption
here that there would be and I know there can be many trust providers but
it kind of goes outside of the specification the presumption here is that
you've got these big associations that kind of put these things together.
whereas some of the places that we're deploying this stuff in such as the
first responder ecosystem, they don't have that, And so there are going to
be many disperate issuers of these credentials and real, central authority
that ends up publishing these things.

Manu Sporny: And so what you end up with is more the vendors getting
together in the space and…

Dmitri Zagidulin: Here's

Manu Sporny: trying to put together a list of known good actors in the
ecosystem. download the whole list is typically and…

Dmitri Zagidulin: Question. in the pilots that you've done so far, are they
focusing on the download the whole list use case or standalone VC proof of
inclusion use case? Okay. Okay.

Manu Sporny: and the number of entities that exist.

Manu Sporny: For example, in the first responder ecosystem, there are
22,000 entities. right? And so, putting those all in one list is an
reasonable thing to do. And downloading it is a fairly easy, reasonable
thing to do. meaning that downloading a gzipped, file that's effectively a
megabyte in size has not been too much an issue. I mean, that's at scale,
right? Mhm.

Dmitri Zagidulin: Uh-huh. …

Dmitri Zagidulin: my concern is more the parsing rather than The
downloading is not a problem. It's the JSON parsing that we've literally
seen run out of memory on some devices. So worth thinking about and…

Manu Sporny: Yep. Yeah.

Dmitri Zagidulin: worth offering a JSON L alternative for really big lists
or pagionation, one of the two.

Manu Sporny: I mean, the approach we've looked at is just publishing
multiple lists and limiting the list, meaning you can compose multiple
lists together.

Manu Sporny: it effectively ends up being like JSON lines only. They're
held at different URLs.

Dmitri Zagidulin: I see.

Manu Sporny: It's effectively patching.

Dmitri Zagidulin: I see. Got it.
00:35:00

Manu Sporny: So you issue multiple VCs of fixed sizes so that seems
addressable without needing to add too much more technology primarily…

Dmitri Zagidulin: Got it. Right. Yeah.

Manu Sporny: because these lists are well-known lists right I mean you
don't end up having thousands of the lists you have maybe five or…

Dmitri Zagidulin: Yeah. Yeah.

Manu Sporny: six providers maybe in a particular ecosystem okay I said …

Isaac Henderson: and…

Manu Sporny: yeah. Please go ahead, Isaac.

Isaac Henderson: so one more comment…

Dmitri Zagidulin: Yeah.

Isaac Henderson: which I would also like to give as part of our list the
flexibility is not only just for the end user credentials or the end user
issuers which we also discussed the use case with who on Regitrust you also
where a meta registry kind of so when there's a country is hosting a list

Isaac Henderson: which contains a link to another list which contains a
list of trusted issuers so that can also be applied with a data model which
we have so use in different levels actually so that one also we
successfully piloted with the UNP project which we also have the code open
source actually so we also have a UI developed so how this

Dmitri Zagidulin: Excellent.

Isaac Henderson: and leverage this list and also update the issuers so we
also had this use of this auditability like having versioning and…

Isaac Henderson: stuff so implemented but not based on W3VC format but it's
in a different format actually but we also worked on the auditability of
the list so the provenence aspect we also worked on it actually multi level.

Dmitri Zagidulin: Yeah. Yeah.

Dmitri Zagidulin: And I agree the auditability is important and the multi
level, right? The registry of registries is super important and…

Isaac Henderson: Yeah, exactly.

Dmitri Zagidulin: and again we should compare and…

Isaac Henderson: Yeah. Yeah,…

Dmitri Zagidulin: contrast how the prefide issuer approach does it and how
the open federation does it which also has the multi-level approach Yeah.

Isaac Henderson: that's true. But it's quite restricted to the X509
certificate as of moment.

Isaac Henderson: No, but you're using the did approach which I also heard
from Rob which I also met him in the conference. but I see that currently
the other the Sweden approach and also the sparion approach where they are
using the X509 approach I guess right at this point of time or…

Dmitri Zagidulin: And they're limited by their corner of the ecosystem
unfamiliarity with DIDs. Yeah. Absolutely.

Isaac Henderson: yeah because the problem what I see also when we are
trying to bring both the things together the trust chain how it is
specified in the open ID federation it's kind of like a DNS

Isaac Henderson: SEC chain at the end of the day kind of having validating
all the trust x509 certificates so that's where I see how the ds did will
play a role so whether we need to also have the subordinate certificates
embedded into the tid or how do you see that aspect actually when you
implement with because that's something the trust chain aspect…

Isaac Henderson: how they claim you need to have your own adapted verifier
to implement this stuff right because that's something which I'm not
completely sure How do you foresee that? Yeah. Yeah. No problem.

Dmitri Zagidulin: Yeah. I mean I'd have to dive into the question and…

Dmitri Zagidulin: and do some research.

Isaac Henderson: Yeah. Yeah.

Dmitri Zagidulin: Yeah. Yeah.

Manu Sporny: Yeah, on the trust chain thing, the other issue we had with
the X509 stuff is the trust train chain verification and we have experience
with this now in production with a number of verifiable credential
deployments in the United States especially among state governments where
we found out that implementers were very frequently misimplementing the
trust chain verification.

Manu Sporny: stuff in X509 to the point that there were security issues u
meaning they thought they were verifying the trust chain and they weren't
in fact verifying it and then there's this kind of requirement this
potential deplatforming that can happen where the entity maintaining the
trust list ends up potentially able to deplatform, people on that list.
clearly that's the whole danger with trust lists is, you've said some
authority has authority over the trust list and then that authority then of
course has the ability to deplatform entities if it deems that those
entities aren't implementing things correctly.

Manu Sporny: But the way that the trust chain stuff is typically done is
through X509. and the problem that we've seen there is that a lot of the
people that are implementing this stuff don't do the trust chain
verification appropriately.
00:40:00

Isaac Henderson: Mhm.

Manu Sporny: the way simpler thing for them to do is to just use a leaf
x509 certificate and have that leaf x509 certificate provided in the core
registry but again that sometimes is not the way that these registries are
run.

Manu Sporny: and this goes back to Dimmitri's point is there's a tremendous
amount of education that needs to happen around these trust chains and I
think one of the things we're trying to stay away from at least in the
verifiable issuers verifiers list stuff is those X509 certificate based
trust chains for example that's how passports are done today right

Manu Sporny: IKO has kind of a route and they put people on that but as we
also know not every country participates in that list only 104 countries
participate in kind of the IKO passport trust chain a lot of people think
it's a global thing and every country participates that's definitely not
the case right only 104 do that issue passport so there are complexities
like this that I think we're trying to keep out

Manu Sporny: of the verifiable issuers list and if one of the foundational
things is kind of like a dependence on X5 or9erts has a base thing and I
know Demetri you're saying you can do DIDs but the only way we can do DIDs
now is in willfully violating the specification right and it feels like a
bit of an uphill battle right based on kind of the position that Open ID
Foundation has taken against DIDs.

Manu Sporny: How would you see us navigating that Demetri? we're basically
talking about a profile of Open ID Federation that would willfully violate
the specification in a different standard setting body. Right?

Dmitri Zagidulin: We're talking about a profile.

Dmitri Zagidulin: Yeah. Yeah. Yes. I am So,…

Manu Sporny: So the options here are either go into open ID Foundation and
try to convince them that DIDs are a good thing and we know that there are
a number of people in Open ID Foundation that are very hostile to DIDs or
profile the specification add C willfully violating the specification in a
number of places don't use X49 509 certificate chaining do use DDS don't
allow phone home how do you see us navigating that. I mean, it's just, …

Dmitri Zagidulin: so I don't think it's that big of a problem in the sense
that for example internet 2 and…

Manu Sporny: difficult, I think.

Dmitri Zagidulin:

Dmitri Zagidulin: and what are they called? edugain in common have their
own standards body currently that has a working group called poor WG and I
forget what it stands for but it's basically a working group on federation
and issuer registries and they literally published a markdown kind of spec
that says open ID federation profile for education for use as

Dmitri Zagidulin: as they share registries where they do do exactly these
things. It's like here's how we're different. Here's how we're going
against the open federation spec and there's a lot of potential
implementers of this stuff. So I genuinely think that if we come to OBD
Federation says guys thousands of registries have been implementing it that
use these two more fields that are in your spec why don't you just adopt
them? I don't think we'll have much problem there. Or if they do say no
never, then the profile will be its own spec. I think at some point it's
like either accept that the rest of the world is doing this not. Here's the
link to the repo to the profile by the way.

Dmitri Zagidulin: Hopefully I can find it. But yeah. Yeah. Please while I
feel free to ask questions.

Dmitri Zagidulin: Yeah. I don't know.

Manu Sporny: Right. Yeah.

Manu Sporny: So I guess fundamentally we have to decide what is going to go
into the verifiable issuers and verifiers list to go into the VCWG. and…
00:45:00

Dmitri Zagidulin: And is that…

Manu Sporny: right it's being incubated here right in the CCG and…

Dmitri Zagidulin: where it's headed? It's going to be incubated in the
working group.

Manu Sporny: then the expectation is that it goes into I mean…

Dmitri Zagidulin: Mhm.

Manu Sporny: if its it goes into the verifiable credential working group if
it's not then it goes into kind of open ID foundation.

Manu Sporny: But I think what you're hearing is that a number of us are not
thinking of using the open ID federation thing and so that creates an
issue. The additional issue is what Isaac mentioned which the EU is going
in this train direction. and…

Manu Sporny: and I guess you're suggesting that in the US education is
going in the open ID federation but in a way that's I think Right.

Dmitri Zagidulin: I think it's still early enough …

Dmitri Zagidulin: but very likely just because of their familiarity with
the open federation spec and the open brand name.

Manu Sporny: And then there are a number of us that have centralization
concerns about,…

Manu Sporny: that direction. So I think there are some

Dmitri Zagidulin: And we should surface those concerns in the profile be
like look off the shelf of federation too many centralization concerns
here's the only safe way to do it to do

Manu Sporny: Yeah. and then timeline of course is the issue because in
theory we're trying to get this stuff onto the standards track in the next
month or two and these conversations seem like they're going to take much
longer than a month or two to resolve. so I'm trying to figure out kind of
what we do at this, step. what's the, …

Dmitri Zagidulin: Yeah.

Manu Sporny: what are the and we have to have people that are willing to
work on, this. So what are the concrete things that, we can do over the
next month or two to get the spec into a shape that we feel is like the
general shape that it's in.

Manu Sporny: Because right now it feels like, there is a general shape for
it fitting into train and the EU. There's a general shape for it fitting
into kind of the stuff that your group has done in the education space. and…

Dmitri Zagidulin: It's beautiful.

Manu Sporny: then there's a general shape that it aligns with kind of what
the verifiable credential working group could work on meaning data model
and it's expressable as a VC and that sort of thing and speaking out loud
about it maybe that's the only thing that we can really do at this point is
what Isaac said which is maybe we just define the data model and just say
you can express the data model through open ID

Manu Sporny: federation or through a verifiable credential and we don't get
into any of the publication or…

Isaac Henderson: Yes. Yeah.

Manu Sporny: APIs that sort of thing. thoughts from the group group I mean
we could go ahead Yeah,…

Dmitri Zagidulin: Do we want to schedule a couple of special topic calls on
this and…

Dmitri Zagidulin: just do some side comparison basically do some active
work on a call or

Manu Sporny: I mean we can repurpose these calls to do that as long as it
doesn't slow down any of the other work. We can always branch out into, yet
more calls. so how about this?

Manu Sporny: Why don't we repurpose this call to kind of try to get some
kind of cuz this work item I think is the one that is the least sure in its
design. meaning based on your input Demetri and Isaac and the conversation
that's been happening here most of the other specifications I think are
fairly set in the architecture and…

Manu Sporny: approach. but this one has a number of kind of big questions
that need to be answered. …

Dmitri Zagidulin: Yeah. Yeah.

Dmitri Zagidulin: And very valid concerns.

Isaac Henderson: Yeah. …

Manu Sporny: let's do that. I don't know if this is a okay time for you to
meet weekly because we need to make sure you or David are here as well.

Isaac Henderson: yeah, I can ask him and…

Isaac Henderson: write you an email regarding that. but I think fight this
time should be fine Yeah. Mhm.

Manu Sporny: All right.

Isaac Henderson: But I think I can also check with him.

Manu Sporny: Okay.

Isaac Henderson: So maybe next week whether he's able to join or not. Yeah.
Mhm. How do you see…

Manu Sporny: right. And then Dimmitri.
00:50:00

Isaac Henderson: how do you see for example I just have a question So
because currently the spec was focused on the registries for example so
currently there is not much work being done because the data model what we
proposed is currently a summary of analysis of different other models
existing so we try to bring up all these things together and one approach
what I can see of is either we are bringing our data model to the decrease
registry because I'm not sure how far it

Isaac Henderson: is interoperable or one thing could be because in our end
of the chapter we have the security consideration so where we could also
implement different other so the idea one is to show it as a VC but we can
also show other forms like open ID federation or any other chains or
provenence chains or something like that so that's why we kept it as open
so where you can bring in other implementations of profiles in future to
plug in and so validate it actually so that solve the idea of what we had
actually so maybe is also looking in that direction but I think we need to
agree on the data model first I guess right because that is whether we are
going to go with this whether we all agree on this model which is already
the attributes what we have selected or should we also need to rework on
that because that's something which is also important I guess

Dmitri Zagidulin: Yeah, let's definitely do a first pass on the data model
recognizing that people will come along and…

Isaac Henderson: Yeah. Yeah,…

Dmitri Zagidulin: need to add new fields and so on. Yeah.

Isaac Henderson: that's true.

Manu Sporny: Yeah, I agree with that approach as well.

Manu Sporny: Me meaning let's just focus on the data model because if we
try to pull in the entirety of open ID federation, I think we're just going
to go off the rails.

Isaac Henderson: Yeah, exactly. Yeah.

Manu Sporny: And so if we can create a data model that is use usable in
open ID federation and verifiable credential working group and whatever
else then there's a chance of the core data model being used in multiple
places and at least we will have standardized on that u and then demitry
that if we do that and it's expressable as a verifiable credential then
that have to use ability to use

Manu Sporny: ability to issue it and not phone home and provide the
presentation as proof of inclusion when you present the credential.

Manu Sporny: It kind of addresses those I think challenges as well. okay so…

Isaac Henderson: Yeah. Yeah.

Manu Sporny: how about this? Let's make the next call if everyone can make
it at the same time next week. Let's dive into the data model. and I don't
want to say we'll do a complete side comparison that I think is going to
take a long time, but at least figure out …

Dmitri Zagidulin: Yeah. Yes,…

Dmitri Zagidulin: I agree. I agree.

Manu Sporny: here are all the fields that we're trying to, deal with and
let's see if we have some use cases that we can try and apply the data
model and then the folks that are interested in making it work in open ID
Federation can focus on that.

Manu Sporny: the folks that are interested in work making it work as a
standalone VC can work on that and as long as it meets everyone's use cases
then hopefully it can be used in other frameworks. okay. So,…

Isaac Henderson: Perfect. unfortunately next week I will not be able to
join…

Isaac Henderson: but I'll make sure whether David is available. If not I'll
just write you an email manual. Is it fine actually? So we can postpone
this call one week later. So, if that's not a problem for you.

Manu Sporny: yeah, we can if folks are okay with that.

Isaac Henderson: Okay. Yeah,…

Manu Sporny: So not next week, but the following week. Isaac is when you
can make Okay.

Isaac Henderson: that should work Yeah. Mhm.

Manu Sporny: And Dimmitri, can you make that call as well? Okay.

Dmitri Zagidulin: Not next week,…

Dmitri Zagidulin: but the following week, I believe. So, let me just double
check. Yes. Yes, I can make that call.

Manu Sporny: All That sounds Okay. So, let's plan on that. what we will do
is we will go through kind of a data model review of what we have in the
verifiable issuers and…

Manu Sporny: verifier spec. and ideally someone would do some pre-work
before then to compare.

Dmitri Zagidulin: Yeah, I'll do some pre-work.

Manu Sporny: So comparing the data model that we have in verifiable issuers
verifiers against the data model that's in open ID federation and just
making sure that we've got every single field covered. and if we have every
single field covered

Isaac Henderson: That's good. Yeah.

Manu Sporny: then we know that the data model can at least express what's
in Etsy and what's in open ID Federation. All right. Sounds like a plan.
thank you everyone.

Dmitri Zagidulin: Sounds good.

Manu Sporny: Thank you very much, Dimmitri, for joining us today. as well
as James and…

Dmitri Zagidulin: Thank you so much for doing this.

Manu Sporny: Alex, of course. really appreciate the input. and we will keep
working on this until we can figure out a way to structure the work so that
it's beneficial to multiple communities. I think that's it for today. Are
there any other items that folks were hoping to discuss next week for our
agenda? Otherwise, we'll just have a standard kind of review of work items
agenda. anything folks wanted to cover next week that's higher priority?
Okay. If not,…
00:55:00

Dmitri Zagidulin: Thanks

Manu Sporny: we'll just go through our work item agenda based on that.

Isaac Henderson: Thank you. Bye-bye.

Manu Sporny: Thanks Really appreciate everyone's time today. have a great
weekend and we will chat again next week. Take care. Bye.
Meeting ended after 00:55:44 👋

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