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

Thanks for the minutes and reading about your interesting discussions.

Sorry I missed this meeting, but unfortunately all my Wednesdays for the 
next month are already booked up. My next free Wednesday is 27 August. 
Other days are much easier for me. So is it possible to consider another 
day of the week to discuss just trust lists, so that the incubation 
meetings can continue as planned on Wednesdays?

Kind regards

David

On 23/07/2025 23:18, meetings@w3c-ccg.org wrote:
>
>
>   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./
>