[MINUTES] CCG Incubation and Promotion 2025-09-03

CCG Incubation and Promotion Meeting Summary - 2025/09/03

*Topics Covered:*

   1.

   *Verifiable Credential Working Group Rechartering Poll:* A poll was
   conducted to gather community feedback on prioritizing specifications for
   the global standards track (confidence methods, verifiable credential
   barcodes, digital signatures, credential refreshing, and the verifiable
   issuers/verifiers spec). The poll also sought volunteers for working groups
   and editor roles.
   2.

   *Verifiable Issuers and Verifiers Specification:* The group discussed
   renaming and refining the specification, aiming for a data model adaptable
   to both centralized and decentralized approaches for expressing trust in
   credential issuers. The discussion centered on balancing flexibility with a
   minimal viable product (MVP). Significant disagreement arose regarding the
   inclusion of certain data model elements inherited from existing European
   standards (Eidas and Train), which were deemed overly centralizing by some
   participants.
   3.

   *Pull Request Discussion (PR29):* The major focus was on reviewing and
   revising PR29, aiming for a data model capable of representing both
   centralized and decentralized trust lists. Disagreement emerged about the
   level of detail and the inclusion of elements that implied a need for
   substantial infrastructure (e.g., DNS, TSPs). Participants debated whether
   the PR should focus on a minimal example or include more comprehensive
   features. Several alternative approaches to data modeling were proposed.
   4.

   *Minimum Viable Examples:* The discussion highlighted the existence of
   at least three distinct visions for a minimum viable example of the
   specification, leading to the conclusion that further work is needed to
   establish consensus on the MVP before progressing with PR29.
   5.

   *Next Steps:* The group decided to shift focus to resolving outstanding
   issues individually before revisiting PRs. The suggestion was made to
   remove existing examples from the specification due to lack of consensus
   and to consider creating separate PRs for different MVP approaches.

*Key Points:*

   - There's a need for a data model flexible enough to accommodate both
   highly centralized and highly decentralized approaches to managing trust in
   credential issuers.
   - Existing European standards (Eidas and Train) provided a starting
   point but introduced complexities and a bias towards centralized solutions.
   - Significant disagreement exists regarding the level of detail and
   required infrastructure for a minimum viable product. Different
   participants envisioned different MVPs.
   - The group agreed to address individual issues before revisiting pull
   requests.
   - The need for both a simple list of trusted entities and a more
   comprehensive, verifiable registry was acknowledged.

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

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

Benjamin Young, Dave Longley, David C, Dmitri Zagidulin, Elaine Wooton,
Hiroyuki Sano, John's Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt,
Phillip Long
*Transcript*

Manu Sporny: Hey everyone, let's go ahead and get started. we've got a
fairly full agenda today. welcome to the incubation and promotion call.
this is September 3rd 2025. we do have an agenda today. we are going to
cover some updates on the verifiable credential working group rechartering
poll. the state of the current verifiable issuers, verifiers, creditors,
whatever we're calling this specification. the recent PR that we've been
working on for the last couple of weeks. some new issues that were raised
as a result of kind of discussions on that and then any other business we
want to cover.

Manu Sporny: but largely the call today will focus on effectively how does
an accrediting body communicate that it has accredited a bunch of
organizations to issue certain types of credentials. So for example, how
does u a motor vehicle association in the US or Europe express that it has
authorized certain nation states or states their department of motor
vehicles to issue driver's licenses or how does a college board that is
consists of thousands of colleges and universities

Manu Sporny: ities accredit certain universities to issue bachelor's
degrees doctorate degrees or things of that nature. So that's what we're
going to be focusing on mostly today. are there any other updates or
changes to the agenda? Anything else folks would like to discuss today? All
right. If not, let's go ahead and jump into the agenda. we mentioned this
on the credentials community group call yesterday, but we have a poll out
to gather feedback on what the verifiable credential working group should
put on the global standards track next.

Manu Sporny: so the one we're in right now, is incubating and promoting a
number of open specifications to go standards track. I just put the link to
this email into the chat channel. in what this poll tries to do is gather
feedback from everyone on what are the priorities in your market vertical.
do you care more about confidence method? Do you want verifiable credential
barcodes? Do you want digital signatures? credential refreshing things of
that.

Manu Sporny: the verifiable issuers verifier spec that we're talking about
today. what are the priorities? What should do in What would help the most
number of market verticals and things of that nature. We also ask for
people to volunteer to participate in the working groups and volunteer to
be editors on the specifications. so the fill the poll out if you've got a
strong opinion. we're just trying to gather feedback from the community.
You do not need to be a member of the working group to provide your
opinion. that's out there. Just a heads up. And I think most of you here
have already filled that that's our first agenda item. Any questions on the
rechartering topic before we move on?
00:05:00

Manu Sporny: Okay, let's jump into our first agenda item. we do have this
specification called verifiable issuers and verifiers. We are currently
discussing renaming this specification to be more accurate about I think
what we all want it to be. currently we seem to have consensus on focusing
on the spec just being a data model that can be used to express things like
centralized lists like for example AMVA the American Association Motor
Vehicle Administrators has a list that they publish that includes all of
the public keys for the states.

Manu Sporny: in the United States that are doing driver's licenses. So,
that's an example of, an accrediting body that is publishing a list so that
other people can know which driver's license to trust and which ones to
not. Europe is going to probably have the same kind of thing for their
European digital identity wallet initiative stuff. Europe has had these
things in the past. David here, David Chadwick who's with us today and
Isaac Henderson who's with Frownhoffer have done some projects around
European versions of this list called train. and so that's one class of
things that we're trying to accomplish with this specification. The other
thing we're trying to accomplish with the specification is a more
decentralized way of doing this.

Manu Sporny: So we want individuals to be able to say and express these are
the people I trust to issue these certain types of credentials. So we're
trying to meet kind of mo both extremes of this spectrum of organizations
and individuals that can express who they trust to issue certain types of
credentials. okay and in that vein we had raised a pull request trying to
talk about something called this the decentralized version of this. So the
current specification has the centralized list I think the initial feedback
we got from the group was that folks would like to see a more decentralized
version of this list.

Manu Sporny: we raised a poll request and had some discussion over that. I
think we came to some agreement on what would change, but I think David,
you have since added a bunch of changes that I think we probably need to
discuss. removal of the word accredititor or accreditation with list
operator changing the data model so it uses the existing data model instead
of trying to get to kind of a minimal version of it. and I think we just
have some disagreement on the PR. So please go ahead David if you'd want to.

David C: Thank you. Yeah.

Manu Sporny: Go ahead, Dave.

Dave Longley: So if the question is it possible for us to craft a data
model such that we can cover the most decentralized cases through the most
centralized one. my opinion on that is I think we can craft such a data
model. I think it has to be very flexible to accomplish it and we don't
want the data model terms to sort of create implications about the
architecture on which it's to be used because that can cause it to trend in
much more obviously in one direction.
00:10:00

David C: So I'd like us to see…

Dave Longley: Even the framing around talking about accrediting bodies and…

David C: if we agree on this fundamental principle and…

Dave Longley: so on sort of implies that you can't have a single individual
accrediting or…

David C: that is that the same data model can be used from a decentralized
list that is run by a superior of a single entity and…

Dave Longley: or saying which issuers they would trust and so on. So we
want to make sure we can cover the full gamut.

David C: just contains one entry in it to the other extreme…

Dave Longley: We don't want to leave anyone or…

David C: where it's run by the European community and…

Dave Longley: any of those particular use cases out of it.

David C: contains all entries of all driving license issuers throughout the
whole of Europe and…

Dave Longley: And so we just need to be careful with how we craft it so
that we don't push …

David C: that the same data model can be used for both. So that's the first
point I'd like to make. Let's see…

Dave Longley: how it gets used in a particular

David C: if we've got consensus on that.

Manu Sporny: Yeah, a plus one to that, David. I think we do have consensus
and agreement on that. Meaning we have a data model that can support the
entire spectrum of, very strongly centralized accreditationbased,
approaches to very decentralized. I'm just saying that I trust a list of
people to issue certain types of credentials. let me ask does anyone object
to that statement? I'd be a bit surprised if anyone objected to it, but So,
David, I think that gives you the answer to your question.

David C: Okay, excellent. I think that is a real good concrete base on
which to build. So as to the existing data model, we took the Etsy standard
as the basic to work from and is a data model of list that's actually
operational throughout Europe and is well used. In fact, it's the most
successful component of EIS version one. Okay, it's about the only thing in
version one that's been really successful. and as you know, now I version
two, but they're enhancing the list from version one. So that's a really
good base. We took that model and we broadly kept the same terminology
because in their case they were only interested in large centralized list.
They never really thought about a decentralized entity of one issue holding
or one authority about one entity. but when the train was actually built
with the concept that anybody could be a trusted list provider. and all
they needed was a DNS entry. and there was a role model where in your DSN
entry you publish entities that you trust and the different DNS entries
could point to other DS entries.

David C: So you can say not only do I trust these people but I also trust
this issuer over here and all the people he trusts as well. so that's what
we had as a running system. So I'm not stuck with the names the names of
the properties were just the ones we inherited from the the semantics of a
particular name may not give the meaning that Dave Wley wants it to have
which it can be anybody who's publishing this list and so we can change the
names. So I'm not bound into that at all.

David C: The other thing that the document says is that we haven't said…

Manu Sporny: Sure.

Manu Sporny: I think the part where I'm seeing the disagreement here and…

David C: which properties are mandatory which are optional because we
thought that's up to this group and the working group. So we just listed
all the properties…

Manu Sporny: again I took issue with…

David C: if you like that we thought that could be conceivably useful.

Manu Sporny: what anything that you were saying,…

David C: And when you see it think that's a massive data we don't need half
of that.

Manu Sporny: I think the challenge that has been created here is this was
meant to be a minimum viable example an example of a decentralized
mechanism.

David C: We agree you might not need half of that but some people might
want other components. So we just list them all and then it would be a
worker up to say these are all optional apart from A B and C which are
mandatory. So that's the next thing.

Manu Sporny: in your most recent PRs pull in way more than I think we were
trying to do in the example and…

David C: Don't get hooked on or bound up with the fact that there are
dozens of different properties there and I don't want that in my model.

Manu Sporny: it uses concepts that are strongly centralizing right so we've
got a PR for a decentralized thing and…

David C: you don't have to have it because we can mark them all optional if
you want. so I'll stop there and let you know people ask questions and…

Manu Sporny: then all of a sudden we start talking about TSP service the
trust service provider in the service definition URLs in all these things
that immediately mandate you have to have DNS,…
00:15:00

David C: we can move on to another point later.

Manu Sporny: you have to have infrastructure and that sort of thing. So
that's why I'm concerned about this it was intended to be something very
different and I think your most recent suggestions take it in a totally
different direction which is to a far more centralizing approach. the other
thing I'll mention is that because the base vocabulary was taken from Eidis
in Europe because it is a very strongly nationstate centralizing approach
by just the fact that that's kind of where the EU was coming from that is
what the data model expresses and when it ends up expressing

Manu Sporny: things like that then it becomes centralizing right so I think
there is work here that we need to do to make sure that just reusing train
and reusing the Eatis stuff it just automatically puts us into a very
strongly centralizing solution and we need to be a bit more careful here so
I would like to understand and I think I've raised a number of issues now
that we can talk about towards the end of this call. but raised concerns
about this given that we have I think fairly strong disagreement on where
this PR is going at this point. So let me pause there. I know Dave's got
his hand up. David, I'm very interested in hearing kind of your thoughts on
that.

Manu Sporny: and suggestions on how we can resolve what we're trying to

Dave Longley: Okay, I'll try to be quick. I thought there was also a level
of indirection that we had introduced where the accreditation part of the
data model allowed you to just talk about issuers that you would trust and
list credentials JSON schemas that could match credentials. the credentials
that might end up being issued or that you might trust could include all of
these other properties. But I thought that a layer of interaction we put in
there that enabled us to both talk about these other properties if you want
to use them to express other credentials. but in the core accreditation
space, you just say, these are the issuers I would trust to issue these
types of claims or the verifiers I would trust to request this type of
information. and it was a simpler baseline with that level of indirection.

David C: Yeah, I'll let Dave Longley state speak first. Yeah.

David C: No, no, I agree. In fact, when I made those changes, it was to
show how you actually do it. So, the bit on the screen that has been
highlighted at the moment where it says issue version identify, sequence
number, etc., List name. you could remove a lot of those if you're not
interested in them. except for things like the sequence number and The
version identifier is there because there may be different standard
versions of the list. whilst it's true that the type contains the version
number it says TLSV1, there is no definition that the type should be the
type of the list and the version number.

David C: So the original concept was the version says the version of the
type. so that's a minor point for discussion but it shows why the fields
are there that you've got a type and you might have a version of the type.
So we could combine them into TLS type and version and get rid of the TLS
version identif separate and remove the version number from the type. these
are minor details but all of the fields that are in the parent data model
do have a of some form. Whether you want to use them or not is up to you.
If you want to do a minimalist version I didn't make mine a minimalist.
00:20:00

David C: It was just to show how extra feels fitted in. So I'm quite happy
to alter my changes to the to make it minimalist.

Dave Longley: So I do think we should try to do less in this PR.

David C: Because Manu wants it to be minimalist.

Dave Longley: Since we were introducing that level of indirection at …

David C: My intention wasn't to be minimalist. My intention was to say to
Manu,…

Dave Longley: and if we do have consensus on doing that,…

David C: you're inventing fields that not in the data model,…

Dave Longley: then maybe we should focus on that in this PR.

David C: but we can do the same thing and more using the existing data
model. So if I change my PR to just we can do exactly the same thing using
the same fields and…

Dave Longley: I worry a little bit about introducing a bunch more of these
terms,…

David C: and forget it and…

Dave Longley: even a few of them in this particular PR…

David C: more, then I think we'll be honing in on the right solution.

Dave Longley: because I think we're going to have a lot of discussions
about them. I'm just looking at how these terms were put onto where my
understanding of this issuer object is it's either an individual an
organization and organizations do not have TSL version identifiers. They
also do not have list operator names. So the attributes don't match the
object what the object is intended to represent which is an organization or
a person. I wouldn't ask you, David, what's your list name? And so if you
were an accredititor in this model and you were issuing one of these lists
or a list of accreditations or however we end up doing that, it would be
very odd for you, David, to have a TSL type.

Dave Longley: So there's some other layer that's missing here where this in
these fields would be about like a list or something and that object we
don't have a property here that says this issuer has a list and here's what
the list is with this version and all these properties. So we're a little
bit off in this PR and I think we could split what we're working on here.
PR1 is about getting that level of indirection in there. PR2 is if you want
to express a list with these properties, here's how you do it.

Dave Longley: That's right. Yep. No,…

Dave Longley: that's that then you have a problem because the open and
curly brace declares that this is a new object and the object is intended
to represent some entity and…

David C: Okay, I mean looking at this particular example,…

David C: we could change list operator name to just name.

Dave Longley: if the object represents an individual or…

David C: So it's issuer open curly bracket and…

Dave Longley: or an organization it does not represent a list.

David C: then there's a name and that obviously implies it's the name of
the issuer, right? Okay.

Dave Longley: So putting list name in there is a little bit awkward.

David C: and then we have list name because this is the name of the list
that the issuer is issuing.

Dave Longley: I think what would happen?

David C: Okay. you may say right.

Dave Longley: It goes somewhere. And we just have to figure out where to
put that list. And I think we're going to want to discuss all that.

David C: Okay. Okay.

Dave Longley: And hopefully we don't have to do it in this PR.

David C: so I think what you would like to do then is to create a new high
level object at the same level of issuer. So you have issuer and then you
have the name of the issuer and then you have list list. And then open
curly brackets and then all the properties of the list. Yeah. Yeah. Yeah.
Yeah. whereas at the moment the high level object in the data model we
specify as properties of the issuer and of it gives properties of the list
operator on this and this was a confusion that Manu had he thought it was
putting properties of one on the other but it was that the top level object
was properties of the list operator and of the list that it was publishing.

David C: So both sets of attributes were together and that threw manu
because he thought they were only properties of one thing,…

Dave Longley: Yeah. …

Dave Longley: So, I think we should those that feels like there's a
interesting…

David C: Man thought they were just a copies of the list operator, but They
were properties of the list operator and…

Dave Longley: but maybe not good idea there of a conflated object that
feels unusual that we could disentangle.

David C: the list and they were together. Yeah. Right.

Dave Longley: And I think we should probably disentangle that.

David C: So yes, I mean it's an object of two types,…

Dave Longley:

Dave Longley: I think it'll confuse a lot of people. But mono's on the
queue.

David C: isn't it? it's an object. of two different types, right? It's just
that the Etsy model has that concept of a multiype object just model.

Manu Sporny: Yeah, that's the issue though. I think not there's a better
way to do the data modeling here and…

David C: Okay. M

Manu Sporny: and shoving both of those concepts into a single object is the
thing that was creating a problem because people don't have lists have
versions right so those things need to be separated and if we mix them with
each other here the data model tends to be far more confusing than we need
to. So, it was having to have that entire discussion in this PR that I'm
hoping we can avoid because that is just one of the, issues that I found
when I looked at the Eidis, way of modeling. which is why I was trying to
get to a minimal example here because a minimal example avoids us having to
open up that can of worms until a little later on.
00:25:00

Manu Sporny: where we have issues to kind of address them. that's f Yeah.

David C: I don't think you can do that Manu because the issuer has a set c
set certain set of properties that need to be in the verifiable credential
and…

Manu Sporny: And I'm not saying I completely agree, but where in the
verifiable credential those things exist matters.

David C: the list has a certain set of properties verifiable credential so
you do need both sets of attributes

Manu Sporny: And if we're trying to nail this down so that for example I'm
going to put my company hat on we want to implement this and we want to
implement it once and we want the implementation to be correct and we are
looking at implementing this and we're looking at this PR and we're going
we absolutely will not implement this because the data model is wrong. So
we do need to express the data that you're expressing but it needs to exist
in different parts of the VC. Now we can propose something in a different
PR or we can have weeks of discussion that will hopefully help us tease
these things apart. So the hope here was that this PR would just be the
minimum thing where we don't have to have all those other conversations and
we just get some base thing in that's useful to us on its own. and then we
talk about how do we model this?

Manu Sporny: So for example I would imagine the proposal to express all
this information would be we would express the issuer as an issuer. The
issuer would have a name and a whole bunch of issuer properties and then
maybe in the credential subject there would be a list and that list would
have a sequence number and a type and a list name and things like that
right but where that list goes is not on the issuer object. It's probably
within the credential subject somewhere where the credential subject is the
list and the description of the list.

David C: Yeah. No,…

David C: it makes perfect sense. but I don't see how we can do an example
of a verifiable credential…

Manu Sporny: This example would be self-contained and…

Manu Sporny: usable just with itself. So the minimum viable example that we
have here we know that we can implement without any of the other
information and…

David C: until we've actually nailed those things down because the example
is going to be wrong because we've not nailed it down.

Manu Sporny: it would lead to a useful ecosystem. So you're right the rest
of the data model would be wrong and we have to discuss it. But for this
example, this very focused PR we're trying to do, we don't need any of that
extra data. Like you said, a lot of that stuff's optional in we don't need
that any of that extra optional information to build a system that's
immediately useful. that just says, just uses identifiers for the issuing
authorities. and then just specifies JSON schema for the types of
credentials they can issue. Those properties did not exist in the current
data model, right?

Manu Sporny:

Manu Sporny: And they were and so we couldn't reuse them.

David C: They do.

David C: No, the schema does that. if you look in the example that we've
done, there is a schema there. not only does it publish the schema of the
issued credentials, but it also allows to publish the metadata of the
issuer as well.

David C: So because if the open ID federation model, they publish the
metadata of the issuer.

Manu Sporny: Yeah, but…

David C: And…

Manu Sporny: but we have no idea…

David C: so our data model allows both.

Manu Sporny: what type the schema is.

David C: You can…

Manu Sporny: We don't know

David C: if you look you'll find there's right there you've got the schema
and…

Manu Sporny: if it's JSON schema. We've got no normative statements around
it.

David C: the metadata All right. Right.

Manu Sporny: We can't do anything with this information. we see that
there's a service definition We have one of them schema. We don't know what
format the metadata is in and we don't know what format the schema is in
and that needs to go into the data model. Melted.
00:30:00

Dave Longley: we have additional problems …

David C: Right. But I mean…

Dave Longley: which I don't know

David C: if you go there if you go to that actual pointer…

Dave Longley: if you have to define a trusted service provider service to
be able to express this information about someone and…

David C: then the data will be there won't it

Dave Longley: what other if we go a little further and we say if you define
a TSP service you have to define these other properties and now we're
starting to get into the sort of framing I was concerned earlier about how
you have to build a lot of infrastructure just to today you would trust
someone else to issue something that's a certain set of claims. So we have
to be careful with whether or not we're creating a lot of framework and a
lot of infrastructure that you have to take on just to make these lists.

Dave Longley: And I think if we instead had an example that we start with
this existing example this simple one we might end up saying hey we can
reuse bits of this or tweak it with whatever else is in the rest of the
data model. That's fine if we find that out and then we can have a second
example that says here's how you describe a list that uses these properties
that are here on the screen if you want to model TSP services and so on.
And it seems to me like we could have both of those. And then if there's a
way to reconcile them, then that's great.

David C: Yeah, I don't understand the first one. I mean, let's take a fully
decentralized case where one entity is saying I trust this other entity to
publish verifiable credentials with the following schema.

Dave Longley: Imagine in the first case it's just me.

David C: Then you need to say what the schema is and what the type of
credential is,…

Dave Longley: I just want to publish a list that says I trust David to
issue claim credentials with these particular claims.

David C: right? Yeah. Yeah. …

Dave Longley: There's no trusted service providers this at all. We're in a
decentralized system. Maybe I'm modeling something in a social media
system. And yeah, this is…

David C: David is the customer service provider.

Dave Longley: what we…

David C: He is you're saying you trust him to

Dave Longley: if we find out that modeling actually makes sense for
individuals and…

Dave Longley: there isn't a bunch of infrastructure and other things you
have to do have a service digital identity with an X509 certificate as an
examp dont this is the reconciling right that's the reconciling thing I
think we need to get

David C: No, you don't have to have that.

David C: No, you don't have to have that you can remove that and just have
a dig. Yeah. obviously the service has to have some ID and it's just put in
there to show you what you can do. but you can remove one of them.

Dave Longley: I don't even provide a service.

David C: Okay. You No,…

Dave Longley: You don't provide a service. We're just entities on a Sure.

David C: no, D. No, no, no. Sorry. you were saying David is providing a
service. you said that I trust David to provide a service of issuing
credentials of the following.

Dave Longley: No. you just issue some credentials on social media. you
don't have a service. I don't have a service. We don't have any
infrastructure. And that's…

David C: The social media is the service,…

Dave Longley: why it gets a little bit awkward.

David C: isn't it? I mean, publishing. Yeah.

Dmitri Zagidulin: To me,…

Dmitri Zagidulin: to me, this gets into the topic of identifying entities
rather than having required to specify…

Dave Longley: This is the conversation I think once we have the two
examples so we can see…

David C: Go on. Yeah.

Dave Longley: how to reconcile

Dmitri Zagidulin: which things they're authorized to issue. just starting
with identified entities as a building block is useful and would address
your concerns.

David C: All right.

Dave Longley: I Monu's on the queue. we're kind of all going off queue
here, so I could respond to that.

Dave Longley: I'll just put myself on the keyboard.

Manu Sporny: And I guess just a reminder to everyone,…

Manu Sporny: please cue because sometimes when conversations start going
back and forth really quickly this, other people don't feel like there's
space for them to join and add to the conversation. So please do cue and it
would be good to hear from other people in the group on their thoughts here
and what we should do. again, remember that what we're trying to do is get
to a concrete decision on how we move this pull request along or we just
come to the conclusion that we're not going to be able to move it along
until we, solve all these other concerns.

Manu Sporny: the thing I put myself on the queue for was to point out I
think Dimmitri that the fundamental issue here is this idea that you have
to set up a centralized service based on DNS and publish stuff online. it's
very high bar it's a much higher barrier than I think some of the folks
that are saying hey we would like to see a more decentralized way of doing
this happen. I do agree that in identifying issuers specifically is
something that would help but I thought that we had agreed to some degree
on a previous call that we're just going to use schema.org
00:35:00

Manu Sporny: or organization or person object to do that like that just
that gets to all of the issuer identification and that's basically a your
customer know your business credential this specific concern around service
types the whole concept that you have to set up effectively a storefront on
the internet to publish one of these lists is antitheical to the
decentralized approach of doing this. Right? so saying we're going to just
reuse service definition URI, they're technical issues that have been
highlighted, but they're more deep-seated decentralization issues.

Manu Sporny: with that the PR29 shows a way where you do not have to be a
TSP provider or specify a list or do any of that in order to achieve the
decentralized use case. And so, every argument where we're like, " but
let's just include a service definition URI." that doesn't live on its own.
It lives in this object, Which lives in this object. And before you know
you've pulled in a fairly heavyweight, infrastructure that was meant for
largely governments that are trying to issue accreditations versus
individuals, issuing accreditations. back to, David Chadwick, the original
thing, you were like, " you could have just used this." No, we can't just
reuse this because it does not have the technical information necessary to
do it.

Manu Sporny: And it also pulls in all this other requirement which is what
we're trying to get away from. Dave Longley, you're on the queue

Dave Longley: Yeah, I'll try to be brief. I wanted to respond to Dmitri. I
think it's absolutely necessary to have these organizational or entity
identity sort of VCs in the ecosystem, but I do think it's orthogonal to my
concern around how to make sure we can express in a full spectrum of a
decentralized ecosystem. what other issuers or verifiers you would trust to
do A or B. And so I want to make sure I'm not ruling out any way of
expressing that information. I just want to make sure that we actually
accomplish that goal and that we don't create a data model that tilts it in
a direction which has been the historical direction which is that signed
information is only for large institutions.

Dave Longley: We want it to be for everyone but both in small and large it
should work for everybody.

Manu Sporny: Thank you, Dave.

David C: So, sorry guys. I've just burnt my evening meal left. I'm cooking
and just smell the burning. couple points. One is you talked about pulling
extra infrastructure. If you start to pull in schema.org, That's a massive
infrastructure want to pull in, isn't it? I mean, it's bigger than anything
here. and also to respond to Dimmitri, I don't see how just a bunch of IDs
can be sufficient. You've got to have more than a bunch of IDs. Otherwise,
you're using the IDs as indirection to go and retrieve all the IDs to find
all the other stuff that you need. Anyway, I'll stop there.

Manu Sporny: Yeah, when I say pullins scheme.org, I don't mean just the
vocabulary terms that are useful here. existing vocabulary terms is what
I'm suggesting. And that means reusing five or six things, So we don't have
to pull in the whole thing. we can just reuse the vocabulary terms. the
other I guess comment about ids and Dimmitri this is I think that you said
IDs and names. I disagree.
00:40:00

Manu Sporny: I think it's only ids fundamentally the thing that we care
about here are the ids we do care the way you decide whether or not to use
an ID is based on a KYC credential or a known entity credential or that
kind of stuff but at some point in time you configure your system to say
this is the ID of the trust service provider or did I trust or whatever and
then all you're looking for is one of the credentials we're talking about
in the accreditation credential to be issued by that ID. Everything else is
superolous, when you get to the actual mechanics of what the software does,
it just cares about keys and IDs and that's purely what it makes its
decision off of.

Manu Sporny: the people configuring the system will care about the human
readable stuff and the legal terms and all that kind of stuff, but that is
all very much secondary to the minimum viable example we were trying to put
together in PR29. go ahead Demetri.

David C: Excuse me.

Dmitri Zagidulin: So I think we're talking about a very different worlds
and use cases. I'm talking about the open world use case of there is an
unknown and open-ended amount of issuers versus what you're talking about
is there is one ID that you trust to issue. and names there are absolutely
crucial you cannot have let me give you an example. So this is an example
of a minimal viable registry right here. So this is what we use here it is
in chat. This is what we use in our wallets and verifiers right now. and
it's sufficient for our purposes. We want to do better. That's why I'm in
this group because I would love to instead switch this for something else.

Dmitri Zagidulin: But notice the important bit here. It's the names of the
entity that are critical. And these are KYCed, what this structure doesn't
have is the verifiable credential infrastructure that says each one of
these is signed by the list keeper. that there's no links to the governance
of what sort of KYC was done.

Dmitri Zagidulin: All of that stuff is implicit into essentially approving
the PR making it into this list. But to me just having a list of known dids
essentially mapped to KYC organizations is the MVP rather than the
additional step of KYC organization plus what they're authorized to issue.
That's it.

Manu Sporny: All right, thanks Just a quick time check. I'm going to need
to end the call early today for the same reason as last another back call.
David, you're up and then I want to see what our next concrete steps are
here. So, go ahead, David.

Manu Sporny: Go ahead,…

David C: Yeah. I mean,…

Manu Sporny: Demetri, if you want to clarify.

David C: Demetri's put an example up here of these are the duds I trust.
for what?

Dmitri Zagidulin: Yeah, the critical part is not I trust.

Dmitri Zagidulin: These are the entities I know of.

David C: It's not clear to me…

Dmitri Zagidulin: I know…

David C: what it means by these are the ds that I trust.

Dmitri Zagidulin: who these bids belong to. And then the verifier this is
what appears in the UI when in your wallet it says this entity is
requesting your credentials. That's in the known verifier case. And in the
known issuer case, this is what appears in the UI on the verifier website
that says this diploma was issued by the CF50 demo issuer. That's the
important bit.

Dmitri Zagidulin: It's not that I trust. The verifier makes that
determination. we haven't gotten to the trust layer yet. my argument here
is that the known entity layer is more basic than which sort of credentials
you trust them with.

Manu Sporny: Hold on one second, David. Dave Longley's in the queue in
front of you. and a reminder, we need to get the concrete next steps here.
go ahead then.
00:45:00

Dave Longley: Yeah. …

Dave Longley: just real quick, I want to say, Demetri, I see what you're
talking about. this thing is really useful. We have a similar thing. I
consider this to be more of like a verified registry or…

David C: …

David C: so I would say that that really is Thank you Dave.

Dave Longley: verifiable registry if you could connect it to something
else. a verifiable directory is the term I would use. And that's useful,
but it's a little different from this other stuff. and we need both of
these things.

Manu Sporny: Plus one I do think agree we need both of these things. It is
becoming more apparent to me that I think we have a fundamental
disagreement on what the minimum viable example is.

David C: You answered my question very nicely.

Manu Sporny: Dimmitri you've got a minimum viable example I think in your
head that looks something like this.

David C: Thank you.

Manu Sporny: David Chadwick has a minimum viable example in his head for
kind what exists in the spec right now. and Dave Longley and I have a
different minimum viable example in our heads that has to do with,
implementing a verifier that could utilize one of these lists. So, we are
still talking past each other, but I think we've at least identified three
minimum viable examples that we would like to see in the specification.

Manu Sporny: And I don't think anyone's saying any one of these things is
something we don't want to support. but again, concretely, what do we want
to do with this PR I could suggest that, we can at least get a minimum
viable example in that represents, at least what Dave Longley and I are
talking to. Dimmitri, we might want another one. minimum viable example.
Maybe you could raise a PR that does what you want it to. And then maybe
David, I think your example is already in the spec, but maybe a minimum
viable example is as you see it as a PR. I'm just throwing that out there
and trying to figure out, what work we can do between now and next call
that moves us forward.

Manu Sporny:

David C: I mean I would like to say that I don't think that Dimmitri's
model should be in the scope of this particular spec because it's not about
trusted lists at all. said that This model is the next layer. So if you
want to have a directory then Demetri you should have a specification for
directories. to have a list of entities that are you not saying anything
about the trustworthy.

Manu Sporny: And again to try to more concretely focus us sometimes you
have to put all of these things into a spec and…

David C: What are they doing in a data model for trusted lists?

Manu Sporny: be able to see all of them and point to them and talk about
them before you decide to remove one or the other. So, I think we're not at
the point right now where we have consensus. I don't think we have
consensus on what's in the spec right now. I don't think we have consensus
on what the MVPs are. we really probably need to, put something down there.
So, either we're going to go back into a mode where we're just going to
process issues and talk about this in issues and try to figure out what the
PRs are. That's one Or the other approach is people that want to see
different things in the spec raise PRs so that we can discuss them to
figure out how we can, get those into the spec. Maybe we put giant warnings
on them going, "Hey, there's no consensus over this concept. We're just
trying it out so we can talk about it." how do folks want to proceed on the
next call?

Manu Sporny: Do we want to just focus on the issues and…

Manu Sporny: just start going through the issues or do we want to try and
keep working this through PRs?

David C: But personally,…

David C: I would prefer issues and resolving issues so that when we have
examples,…

Manu Sporny: Okay.

David C: they're examples that are agreed upon. But can I just say to
Dimmitri actually that the information you're holding about names I think
you'll probably find in the existing data model anyway because it has lots
of properties of entities. So I'm sure that if you look at your three
properties or what properties you have per entity you could map those into
the properties that already exist in data It's just a data model says
that's not sufficient on its own. You need to also say additional things
about these entities.
00:50:00

Manu Sporny: All right, let me try again on concrete next steps. So, we are
going to shift over into processing issues because it's pretty clear at
this point that we're just not going to get agreement on PRs until we
process these baseline issues. I will also food for thought for next call.
We should probably strip all of the examples out of the existing
specification because I don't think we have consensus on them. that's a
separate issue. what we can do is maybe we can talk about each issue, where
we get to there. but I think it's becoming more and more clear that there's
a decent bit of work to do here before we get to some minimum viable
examples. The good news here is that I think there is consensus on the set
of use cases we all want to solve. I think we're just debating how we want
to solve them. Right?

Manu Sporny: I haven't. next call will be diving into the new issues,
trying to get some resolution on them so that we can raise poll requests
that have a chance of making it into the spec. Anything else that we need
to mention or talk about before we go today? We've got about 2 minutes left
on the call. Okay.

Manu Sporny: if not again really appreciate everyone's engagement on the
call in keeping it civil and all that kind of stuff. of course we expect no
less from the people that are here. These things can be frustrating to get
through but I think we've got some baseline consensus on the problems we're
trying to solve. So it's really a matter of how we go about solving them.

David C: Bye. Thank you.

Manu Sporny: We will meet again next week to continue this discussion with
a focus on issues. In the meantime, have a great rest of your week and
we'll chat again next week. Thanks all.
Meeting ended after 00:52:10 👋

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