[MINUTES] CCG Incubation and Promotion 2025-08-27

CCG Incubation and Promotion Meeting Summary - 2025/08/27

*Topics Covered:*

   1.

   *Decentralized Issuance/Accreditation Mechanism:* The group discussed
   modifications to the PR for a decentralized mechanism for publishing
   acceptable actions by issuers and verifiers. The primary focus was changing
   the language around "grants" to "accreditation" to emphasize the
   decentralized and permissionless nature of the system. Concerns were raised
   regarding the granularity of accreditation (too fine-grained vs. too
   coarse-grained). The need for a generalized, adaptable data model that can
   represent accreditations for issuers, verifiers, and policy holders was
   highlighted. Confusion around the term "issuer" in relation to the list
   owner and issuer of verifiable credentials was addressed.
   2.

   *Data Model for Trusted Entities:* The discussion clarified the
   decentralized nature of the proposed data model, emphasizing its
   flexibility and use across various entities. It was confirmed that the
   model allows for fully decentralized configurations, such as a list owner
   with a single entry.
   3.

   *Integration with Existing Systems:* The group explored the possibility
   of integrating with existing systems like OpenID Federation and ETSI's
   trust list specification. The main point of contention was whether to
   create a superset encompassing all systems or to create a mechanism for
   referencing existing systems (e.g., via pointers) without needing to
   incorporate their entire vocabularies. It was suggested that creating a
   superset data model and a mechanism to point to external lists would be the
   best approach. Concerns were raised about potential duplication of effort
   with the ETSI initiative updating its specifications.
   4.

   *Specification Title and Structure:* The group discussed revising the
   specification's title and restructuring sections 1, 2, and 3 to better
   reflect the decentralized nature and expanded scope of the proposed system,
   including the use of verifiable accreditation for all three roles (issuer,
   verifier, and policy holder).

*Key Points:*

   - The terminology shifted from a centralized "granting" model to a
   decentralized "accreditation" model.
   - The data model is intended to be decentralized and flexible, capable
   of representing various accreditation scenarios.
   - The data model should be a superset of current systems and include a
   method for linking to external systems and specifications to avoid
   redundancy.
   - Sections 1-3 of the specification require revision to align with the
   updated data model and decentralized approach.
   - A revised title for the specification is needed.

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

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

Alex Higuera, Benjamin Young, Dave Longley, David C, Dmitri Zagidulin,
John's Notetaker, Jonathan's Notetaker, Kayode Ezike, Manu Sporny, Parth
Bhatt, Phillip Long, Ted Thibodeau Jr, Tom Jones, Venu R
*Transcript*

Manu Sporny: All right, folks. Let's go ahead and get started. welcome
everyone to the CCG incubation and promotion call for this week. It is
August 27th, 2025. Year is going quickly. we do have an agenda today.
largely it's to talk about the PR that we had discussed modifications to
around the decentralized mechanism for publishing acceptable actions by
issuers and verifiers and roles there's some language changes that people
had asked for and we've gotten some feedback on that from David Chadwick
and a couple other folks so we'll be largely discussing that today

Manu Sporny: we are also probably going to talk at a little more depth
about deferring to complex policy languages through this mechanism. And so
maybe what we're looking to do is create a light version of the spec as it
exists rather than trying to move entirety of other languages over into the
current specification. and then of course ending is the name of the
specification now I think people are not super happy with the name of the
specification. So we're trying to kind of retarget what the specification
is about. so that's the proposed agenda for today. Are there any other
items that people would like to add or modify on the agenda?

Manu Sporny: If not, let's go ahead and jump into the first item which is
this first cut at a more decentralized approach. So one of the pieces of
feedback that we got from the current specification was that it's too
centralized. we want to be able to do things in ways that don't depend on
centralized authorities or centralized lists. it's fine to have that
mechanism but a number of folks said that they were concerned about kind of
recentralizing something that is also possible to do in a more
decentralized manner.

Manu Sporny: so in that vein I raised a R two weeks ago calling it and this
was imperfect at the time calling it things like decentralized issuance
grants in verifiable roles I think the feedback on that was people didn't
like the language around either one of those so went and did a modification
based on the discussion to date. Dimmitri raised issue. Joe raised an
issue. I incorporated those issues in the text to just be clear to people
that, what we have isn't done. We still need to, improve it.

Manu Sporny: based on those I went and updated the PR. Joe wanted to call
it something more along the lines of accreditation. So instead of
verifiable accreditation so that it was clear that anyone can accredit
anybody else. There's no implied it has to be a government or something
like that. the previous language had had a more permissionbased approach.
So retargeted the language away from roles to accreditation which still
allows you to have big governments accrediting smaller bodies or
individuals but it also allows individuals to accredit each other.
00:05:00

Manu Sporny: The examples were updated away from grants to accreditation.
So this is effectively an acitation This is an issuer of some kind
accrediting an issuer they're providing them an accreditation to issue. So
this is an issuance accreditation and then it follows the same kind of
schema that we had last time. Dimmitri, I think your desire to have more
fine grained accreditations would go here, in …

Manu Sporny: approach. I couldn't think of, other type.

Dmitri Zagidulin: If I could…

Dmitri Zagidulin: if I could jump in, I think my concern is in the other
direction. Less of fine grain accreditation and more coarse grained. Is
this a recognized entity or not?

Manu Sporny: Yeah, the KYC credentials. But I thought at the end of the
discussion last time we said that, organizations could be filled with
schema.org organization.

Dmitri Zagidulin: Yes, schema.org organization is fine. It's how to put it
together in a list, right? It's composing that into a list. that's my
primary concern.

Manu Sporny: Okay, let's I guess discuss that, in a bit more depth. I see a
queue forming. Let me make sure I get through this stuff. yeah, so here
Dimmitri, there's an issue that I opened. I didn't see one that you had
opened, so I opened one and linked to it.

Dmitri Zagidulin: No problem.

Manu Sporny: So we should talk about that in more detail. And then the
accreditation thing I linked to up here in the abstract. So this was Joe's
request that he didn't want to focus on grants and allowances and it had
more to do with accreditations. So that's how it was modified. I know David
you have feedback. Dimmitri sounds like you have feedback. so let's go
ahead and start a queue and start getting feedback on the PR. David, you're
up. Yes.

David C: Okay, thank you. Can everybody hear me? Yeah. so the document is
in fact a data model for trusted entities or accredited entities and I've
actually put an issue in where I suggested to change the title to that and
why people thought it was a centralized list is actually a misunder this is
a data model that can be used by anyone for any number of entities.

Manu Sporny: We can make you out, but your audio is being rushed and it's a
bit garbled. but keep going, David. I don't know if there's Yeah.

David C: So the list owner could have indeed just one single entry in the
list and it could be totally distributed totally in line with the original
intention and in fact the train system had that it had many entities in the
DNS which had lists and as I say the list could be from one entity which
could be one subordinate of yours or just somebody to a country that's
listing all the trusted issues creation of the country. So I think that
sorry is people can I hear me properly? Okay. Yeah. so that's why when you
added the bit about decentralized list that perfectly line with the data
model. I don't think it needs to alter the context of the data model at all
really because what we did was said this is everything you actually need to
know about who the list owner is and who the list entities are. Okay.

David C: so that's the first point I wanted to make that having a
decentralized totally in line with what we planned from the beginning and I
don't think that message got through to people. The second thing is this is
meant to be about trusting all three roles within the current VCDM. So it's
meant to be about issuers, verifiers and policy or holders. and in fact all
are needed and changing it in your text that you've got now where you talk
about an issuer that is very confusing because an issuer is in VCDM model
it's the issuer of VC. whereas we've called it the list owner to
differentiate from the issue of a VC. if you got fully decentralized model
where the list owner has a list of just one then and it issues a VC then of
course it's the issue of the VC but we still think you ought to give it a
different name issuer because it's confusing to have the issuer of a right
and then the issue of a verifiable credential even though in history model
they are the same. Did that make sense to people?
00:10:00

Manu Sporny: Let me try and reflect back what you said, David. I think
everyone's having trouble hearing you because of your audio. so if I can
try and summarize, you're saying, the initial intent was for this to be
decentralized. so there seems to have been a misunderstanding of the
specification. meaning if you're fully decentralized, you are a list owner
and you have an entry that's one deep and that sort of thing was supported
previously. so I think that was one of the points that you were making.

Manu Sporny: I think the second point that you were making is that it's
important to have additional kind of metadata about the list owner meaning
everything that was in train thing effectively this data model so the data
model is meant to be decentralized it's only a data model

Manu Sporny: doesn't need to be at any particular location because it's a
data model it can be published through any means necessary and then I think
that your third point was that this issuer section here is confusing I
didn't quite understand why I think from what it sounded like I think you
are reading this issuer as

Manu Sporny: as the issuer of the list when it's not meant to be this is
the accredititor that you said use a different word that I think the
accredititor is providing a verifiable credential that speaks about the
issuer and the accreditation that the accredititor is giving to the issuer
but I think you're saying that there's confusion around that did I fairly
summarize your points, David?

David C: Yeah, I think basically yeah the list operator in this particular
6.1 section the verifiable credit should be provided by a list operator
right because is it not the list operator that's accrediting someone right
so that's…

Manu Sporny: Yeah, it's the list operator. Yeah, to be clear,…

David C: why I'm saying don't exactly so don't call it the issuer there…

Manu Sporny: the list operator. Go ahead.

David C: because that's confusing because the issuer is the issue of a
verifiable credential that you are trusting. I know we've got a bit of
recursion here because that when the list operator issues a list as a
verifiable credential which only contains one entity in it, that itself is
a verifiable credential and therefore the list operator becomes an issuer
of that verifiable credential.

David C: But it's not the verifiable credential in the VCDM meaning because
in that meaning we're thinking about a driving license or a degree
certificate or…

David C: something like that not a verifiable credential about the issue of
one of those things. Does that make sense to people?

Manu Sporny: I'll pause to see… if anyone's got questions. go ahead Dave.

Manu Sporny:

Dave Longley: I think I understand your meaning, David, but just from my
perspective, I consider each of these things to be a verifiable credential.
I accept that recursion, but I agree that it can be confusing in the
language of the spec. And so we should call out more clearly which issuer
we're talking about or use different language to talk about the issuer of
this list credential as opposed to the issuers that they talk about in the
list credential.

Dave Longley: But I take your point.
00:15:00

David C: Correct. Thank you very much.

David C: That's the point I was trying to make.

Manu Sporny: So, as far as a concrete change, David, should we change this
type to accredited entity or something like that? what concrete changes
should we make to this data model to Yes,…

David C: It was in the text Where a verified credential can be provided. to
an issuer is that the issuer of a verifiable credential in the conventional
meaning of the sense?

Manu Sporny: correct. …

David C: But again it's not generic enough because accreditation can be
provided to a verifier or a wallet. And so to put issue in there
immediately gets people thinking we're only talking about one entity within
the VCDM model. So I think that right

Manu Sporny: I see what this section is only about issuing accreditation. I
was taking a cut on something very specific and very concrete and there was
going to be a section on verifying accreditation and all different other
types of accreditation.

Manu Sporny: The challenge there of course being how many different types
of accreditation could there be. again as Dave said I take your point.

David C: All right.

David C: And yeah,…

Manu Sporny: I'm trying to figure out how we say if you want to accredit an
issuer this is how you do it. okay.

David C: So I would call that issuer accreditation rather than issuing
because issuing accreditation is again ambiguous because it could mean the
issuing of an accreditation right or…

Manu Sporny: Yep.

David C: it could mean the accredititation of an issuer.

Manu Sporny: Change this title and language to issuer accreditation or…

David C: Yes. Of an issuer.

Manu Sporny: accreditation of an issuer and that would All right.

David C: Right. Exactly.

Manu Sporny: I can do that and…

David C: But I didn't understand that this was going to be one of three.

Manu Sporny: then I can update the language gear,…

David C: I read it as this is the only one.

Manu Sporny: right? Yep. Yep. Yep.

David C: Right. Okay.

Manu Sporny: So, maybe adding an issue marker to say we I might just add
the other sections in here. I wanted to try to start with some smaller text
instead of, Okay.

David C: Probably you could try and make it generic straight away and just
put the issuing of accreditations as the title and then it becomes generic
because that's how I read The issuing of accreditations.

Manu Sporny: And then maybe have three examples or…

David C: Yeah. Yes. Yeah.

Manu Sporny: at least two, I can try to make it generalized and see how
that goes. Dimmitri, you've got your hand

Dmitri Zagidulin: So, here can you scroll down? I just want to see the
example two accredititation. I see. Credential subject. And so, yeah, the
bit I'm trying to get a sense for is how does this compose into a list?
Would the idea be that the registry is a list of these verifiable
credentials?

Manu Sporny: Yes. Yep. I think so.

Manu Sporny: You would just take these and there would be a giant list of
these things and you could piece them together from all kinds of different,
you could take one, if there are four accrediting bodies,…

Dmitri Zagidulin: Got it. Okay.

Manu Sporny: you could take all of their published things of this nature
and put it together in a higher level list.

Dmitri Zagidulin: And I see I see.

Manu Sporny: I don't think we've proposed what that higher level list looks
like yet Dimmitri we still need to do that. So this is the primitive that
would be Y.

Dmitri Zagidulin: And So if the entity is let's say both an issue and a
verifier do you foresee having the credential subject type be an array or
would there be a multiple credential subjects?

Manu Sporny: Yes it would. let's see. if it's the same subject, there would
be an array of accreditations. One for issuance, one for verification, one
for KYC,…

Dmitri Zagidulin: It's just it's the credential subject type that not the
issuance…

Manu Sporny: one for And I see you right.

Dmitri Zagidulin: but the type issuer. Yeah, that's the thing that worries
me.

Manu Sporny: Yeah. I agree. That would become a problem at that point.

Dmitri Zagidulin: That's enough.

Manu Sporny: So I guess we could do an array of credential subjects and I'm
unsure about this type here.

Dmitri Zagidulin: Yeah, I don't think we even need that one because the
accredititations will speak for themselves.

Manu Sporny: Yeah. Yeah.

Manu Sporny: The only reason the type's there is to kind of kick in the
JSON LD scoped, stuff, but we don't sure.

Dmitri Zagidulin: If that's the case,…

Dmitri Zagidulin: then we could type it as known entity.
00:20:00

Manu Sporny: So we could go shift to a se separate type that's more
generalized. plus one. We could do that. I guess I'm just trying to
highlight I don't know how I feel about this and…

Dmitri Zagidulin: Gotcha. Okay.

Manu Sporny: it's probably wrong.

Dmitri Zagidulin: Got it.

Manu Sporny: But other than that, did that answer your question? Demetri,
does structurally it makes sense?

Dmitri Zagidulin: Yes. Yes. I think it makes sense.

Manu Sporny: Okay. All Sounds good. go ahead, Dave. Mhm.

Dave Longley: Yeah, I wanted to talk about something else,…

Dave Longley: but just quickly on this point, I think a type is really
useful, but maybe it should just be the credited entity or, something
generic like you were saying. so that what you're talking about is
something that has some kind of accreditation. Then you would go look at
those accreditations. the point I wanted to make was to be responsive to
David's comments about people's view of this specification previously as
being more centralized than we would like. And I think a lot of that had to
do with the language that was being used about in some of the places around
authorities and granting permissions in spaces.

Dave Longley: So it gave the impression that for some set of types of
credentials that there would be an authoritative body or an authority that
you would choose and you would choose that one authority and that authority
would then grant these permissions for people to make claims. And it was
mostly just in that languaging that we wanted to change to shift to say
that we're really talking about accreditations or just that someone might
recognize various issuers verifiers in certain ways to make certain claims
or to issue certain credentials or to be able to request them in certain
ecosystems. and so we just wanted to shift that language because that makes
it more obvious that it's decentralized. You could use many of these lists.
You could use them at once. Anyone can make these lists. And it could work
for individuals all the way up to, government institutions and so on.

David C: Can I respond to that, Dave? Yeah, I totally take your point. what
I wanted to say was that sections one, two, and three were mostly inherited
from version one of this document that was written by the previous editors,
and we hardly edited that. Our main work was on the data model. and I
accept the fact that we really need to go back and re reward the holes of
section one, two, and three.

Manu Sporny: Okay, good.

Dave Longley: Yep, sounds good.

Manu Sporny: I think we're all in agreement on that. Dave. Go ahead.

Dave Longley: Yeah, I was just agreeing that that sounds good. there was no
judgment over, where the text came from. It was just going forward kind of
giving feedback on where we wanted to go and make sure that this fits in
with the three-party model and the decentralized ecosystem that all this
technology is for.

Manu Sporny:

Manu Sporny: Plus one to So, I think we have general agreement that we
definitely need to make a pass over sections 1, two, and three to make sure
it still is aligned with what the group thinks is the right thing to do
here. that includes, the title of the specification probably not being
right. We've got to pick a new title, which we'll talk about today. and it
includes us making these adjustments as David was trying to make it clear
that this is accreditation for all types of different roles not just
issuers and then Dimmitri's suggestion to change this to what something
like Dave said which is accredited entity or something like that.

Manu Sporny: So I can make at least the passes on this PR and then the
other things are future changes that we might need to make. So if we made
those changes to this section are there any other items that people are
concerned about or the general direction that we're headed in? Is the
accrediting language better than the grant language and…

Manu Sporny: the authorized language we were using before? Are there any
other concerns about the PR Mhm.

David C: Can I just on that type issue?

David C: Maybe that type should be tightly controlled by this specification
and is defined in this specification. It's the only type that we're going
to issue at the moment. It's the only type we're going to say we're going
to define. So the type could be something around the title of this document.

Manu Sporny: Yeah, agreed. I think we end up defining that type in this
specification. All right, that sounds good. if there are no other comments
on the PR itself, let's go to some of other discussion. one of the things
that came up in the discussion of the data model is that this is fair this
is train it came kind of from the train specification.
00:25:00

Manu Sporny: there was also a point made about open ID federation basically
it's got a different vocabulary right let's say arbit picking an arbitrary
number there's 60% overlap with the open ID federation specification and so
we had talked about mapping one of these things to another of these things
but the other concern here is that there are probably other list mechanisms
out there, And the danger that we run here is that we create something just
for these two list types and then for the other list types we leave them
out.

Manu Sporny: One suggestion is to try and figure out a way to point to
other lists and vocabularies without having to pull them in their entirety
into this specification. So what that would look like is something like
this, Where we would say, there exists and this is all wrong. don't take
the example at face value. the concept it's trying to get to is that there
is this list out there defined by a completely different data model all
that kind of stuff but it is in the format that whatever other trust list
specification is in.

Manu Sporny: So this could be an open ID federation, It could be a train
description. It could be something of that nature. And so instead of trying
to create yet what we make this data model do is just point to other lists
very simply so that people can use this credential to point to whatever set
of lists that they want to and provide cryptographic assurances over let's
say the state of the list and things like that through things like related
resource.

Manu Sporny: Let me stop there and see what people's thoughts are on that.
what that would mean is that our data model would be drastically
simplified. meaning the data model would just be able to point to external
lists and it would be able to express accreditations of this form. and the
data model would not have these properties in here.

David C: What's

Manu Sporny: it would just point to a list and another specification that
would wholly define these properties. so let's hear some feedback on that.
what are folks thoughts? go ahead, David.

David C: So, while you said train itself was taken from an exi standard.
the Etsy standard is actually in wide use in Europe. it was built to
specify trust in X509 entities. and there's a European list of lists and
then every country has a list of its trusted X509 issuers certification
authorities. Yeah. So the vocabulary the trainers was taken exactly from
that but it had limitations because it didn't have the ids and it didn't
nothing was in JSON either it was all in XML. So what we did we've modified
the exit standard to include the decentralized issues and things like the
schema of the issue.
00:30:00

David C: what's happening in parallel with this work at this as we speak is
there the Etsy people are updating their documentation because they realize
that the standard that's used at the moment only was designed for X9 and
not for verifiable credentials and wallets and so they're revising their
spec and I've had some discussion with them and they're hoping to get the
first version of their spec out in September which might be out for review.
Now the other point to note is they will increase their existing vocabulary
to include probably DIDs and decentralized roles etc. But they also have a
lot more in their data model than we've incorporated in this. So not only
did we add bits to it but we took a lot out as well. So this data model is
an intersection of the Etsy one in a way. for example Etsy has a whole
chunk on the history of lists. So not only can you find out what the list
is now but you can also find out what the list was last year or whenever.

David C: So there's a whole history of the trusted lists as well. We've not
put that into model, but I realize that some people may want that. They may
want to be able to know, okay, I'm not interested in what's trusted today.
I'm interested in what was trusted last year when I did ABLC. So that's
just some further background information onto the gallery.

Manu Sporny: Yeah, and that's helpful background, David. I guess, and
that's good new information. I guess that increases my concern that we may
be duplicating effort with the other initiative. I know the delta here is
that some things have been removed. some things are, ahead of what the
previous Etsy model is. but it feels like if there's another group out
there that is defining that thing and what we are doing is subsetting it in
this specification, it feels like it may be better for us to just be able
to point directly to whatever they end up creating in the future.

Manu Sporny: meaning if they're doing the work to include DIDs and digital
wallets and VCs and things like that then I see that as a strong argument
for they will publish some set of lists in the future and this
specification should be able to express pointers to those lists…

Manu Sporny: which have a much richer vocabulary that's aligned with
European standards for doing trust lists I feel like we would be
duplicating effort if we tried to even take a subset of that.

David C: Can I just go?

David C: Yeah, because when I talk to them about that, you have to bear in
mind that their work is focused totally on Europe and European digital
identity wallet and it's not interested in anything else outside of Europe.
and therefore we thought that this work should be a superet of that and be
global in scope because we didn't want to be limited to just what was valid
for Europe. So things that were valid outside of Europe should be within
this model.

Manu Sporny: Okay, Under understood. do we have any other kind of input on
what direction we should go here?

Manu Sporny: Go ahead, Dave.

Dave Longley: That was a little hard for me to follow,…

Dave Longley: but if there's going to be a specification that's coming out
in September that is been modified to work with VCs and digital wallets, it
seems that it would be ideal if this spec can link to those in the same way
that this spec could express different lists and different ecosystems that
already exist, including what Tom has mentioned in chat. here about open ID
federation systems. those systems that are working for people that don't,
create privacy harms or whatever and nobody's looking to transition from
those could be linked via the work in this spec without having to change
those. But the spec should also enable newer ecosystems that can try to
avoid some of the privacy harms that existing systems have brought.

Dave Longley: And that's not necessarily going to apply to organizational
identity and so on where existing ecosystems and data models are out there.
So ideally this spec can link and find commonality to bring those different
pieces together and enable more decentralized and privacy preserving
mechanisms going forward for trust.

Manu Sporny: And Dave, I didn't quite understand what that was an argument
for.

Dave Longley: I don't know enough about the eco David has said that he has
looked at this existing stuff from Etsy that's in an XML format there and
currently Etsy is updating all of that and he's taken some data model
elements from that space and removed others based on some constraints that
I don't know all about and the question is do we need to do that or at this
point since we know that they're producing another spec, we don't know
what's going to be in or out of that. will we be able to simply reference
what they do since they are modernizing their own specification and data
model. So maybe that's not something we need to do here.
00:35:00

Dave Longley: And so maybe we can focus on gluing these ecosystems together
and putting in the pieces that will allow people to create and express
accreditation, recognition and so on in a decentralized way and then
potentially all also talk about how you can share those kinds of
credentials in a more privacy preserving way without leaking information as
you have ver if you presented a credential to a verifier, you don't
necessarily want them to go traverse a big list and…

Dave Longley: and hit a bunch of endpoints and set off signals that you're
sharing that credential. And so this spec could enable protocols that don't
do that.

Manu Sporny: Okay, got it.

Manu Sporny: Phil, you're up.

Phillip Long: Yeah, I think I agree with the spirit of Dave what you're
saying, but I think David has already indicated that the thing that the EU
is doing is very EU centric. It will work entirely within that context. It
might work other places as well, but they're not really paying attention to
that and it's not their concern. so it sounds to me like we're talking
about a superset and that we can have a generic way of referencing any
number of other mechanisms, OIDC, the EUs or whatever. but that our focus
should be on the decentralized JSONLDD world that is not yet part of those
things specifically and whatever uniquenesses that they provide. Thanks.

Manu Sporny: Thanks, all right. what concrete thing are we doing as a
result of this discussion? It sounds like people are arguing that we should
do a superset. I don't know if people are arguing that we should be able to
point to other list types like Open ID Federation or the Etsy one or I
think I'm hearing no, we shouldn't do that. is that what I'm hearing? I
mean, I'm hearing we should define a superset and we shouldn't point to
Open ID federation and we shouldn't defi point to Etsy.

Dave Longley: So I'm not arguing that we have to do one the other that
they're mutually exclusive. It seems to me like if we have found that we
need to do more because it's not going to be European specific. It's more
global. That makes sense. But we shouldn't preclude being able to reference
existing things that are in the ecosystem or entities that might be in the
EU and they already have a bunch of stuff. It would be good to be able to
have our data model talk about this entity and say and by the way they have
this Etsy thing that we can link to and you can follow that and if you're
in that ecosystem you can just follow and use that.

Dave Longley: I don't think we're trying to intentionally create
incompatibilities in what we're saying here. But I think we should try to
facilitate more interoperability even if this spec is the glue that helps
make that happen.

Manu Sporny: So then that is an argument for doing both of the things.
Meaning we should be able to point to external trust lists and trust list
specifications and we should define a superset. Is that what folks are
saying?

Phillip Long: I'll jump in and say I thought that's what we were actually
trying to do. Focus on the one that we care about, but allow a generic way
to point to others that could be added to over time as others emerge or as
changes to the others ex are made. but allowing this to be the skeleton
that includes those and…
00:40:00

Phillip Long: very specifically highlights the unique valuable
characteristics of the JasonLD world that we're in.

Manu Sporny: Okay. …

Manu Sporny: I think I understand, Phil, just to be clear, we're going to
have three different mechanisms by the time we're done with the
specification. That's the path that it seems like we're on. So we have this
verifiable accreditation thing which is a very tight mechanism. So this is
Mechanism two is the Etsy derived thing the superset which does not have
any overlap with this data model down here. So these are two kind of
distinct ways of doing things. So this is a superset data model and then we
are going to create yet a third data model to point to things that are
outside of the specification like open ID federation and the Etsy stuff. Go
ahead Dave.

Dave Longley: it says it in the title there that it's just about the list
operator and that seems like these are extra bits of information about
whomever is making an accreditation list which is not the same thing as
listing the accreditations that they're offering to issuers, verifiers,
whoever else. and if our list of attributes is fairly small, I don't know
if my memory of this is that there was a lot more to it, but maybe it does
fit on a single screen there. I don't know. yeah, there's some more stuff
there.

Dave Longley: these attributes are closer to what Demetri was talking about
in making statements about a particular entity or in this case maybe
statements about a particular entity that is publishing such a list and
those things are different from the list itself and so I wouldn't say that
those are two different mechanisms they have two wholly different purposes
now when we get to linking to Those other ecosystems, each one might have
its own different set of features that it offers, including some that might
make statements about entities, some that might make statements that are
approximating accreditations or grants or permissions, and other ones won't.

Dave Longley: But it seems to me like what we would have in this spec is
the list which is one thing and then some kind of credential. it looks to
be about the list creator and that we need to figure out where this linkage
to other ecosystems would come in.

Manu Sporny: Okay, good. That's Yes.

David C: Can I respond to that because Yeah.

Manu Sporny: Real quick, David, I forgot I need to go in five minutes. so,…

David C: Okay. Yeah.

Manu Sporny: please go ahead and then we're going to need to handle it

David C: the intention was that if you're going to issue a verifiable
credential as a list operator, then all the properties in the verifiable
credential would come from either 4.11 which are attributes about myself or
would come from 4.2.1 which are attributes about the entity that I'm
talking about.

David C: So that's why I made my comment into I don't know whether it was
the issue or the PR. I said we need to make sure that the properties in the
verifiable credential that you've specified are included in 411 and 421
because the verifiable credential should be using that data model. That's

Manu Sporny: Noted. we are going to have to continue this discussion next
time. sorry, forgot that I had to be on another call very soon. okay but I
think the core of the discussion here is that for the use cases that we
have what part of the list operator what part of the TSP and then what part
of the accreditation we need to define and to be clear we can create a
vocabulary that defines each one of these things like they're talking about
effectively different entities and they have different purposes as Dave
longly mentioned

Manu Sporny: mentioned I guess the question is who needs what to achieve
which use case. So maybe next time we can focus on the use cases that are
achieved where you need each one of these data models to kind of achieve
the use case. I know that would help me understand a bit better about why
you need to express a TSP and why you need to express a list operator. for
next week I'll go ahead and update the PR to align with what folks said.
and then that may get merged over the weekend if we get good feedback on
it. If we don't then we'll discuss again next week.
00:45:00

Manu Sporny: And then next week it sounds like we're going to be focusing
on, what data model are we act, what's the core data model? what use cases
really are we trying to support with the data model? and then, at some
point we're going to want to rewrite the first three sections to align with
whatever we end up with in the data model in, sections four, five, and six.
But we're making progress. I think we're, coming to an understanding on…

Manu Sporny: where each person's coming from. So, that's good. I think
that's it for the call today. thank you again very much. really it was I'll
have to leave.

David C: Could I ask that…

David C: if other people have got 10 minutes, we could discuss the issue I
put about the change of title and perhaps discuss that for the next 10
minutes because that was in your original agenda, wasn't it? I see.

Manu Sporny: I don't know what happens when I drop off the call. I'll try
to leave the call running and hopefully the Scribbot will do the right
thing.

David C: Cuz you started it.

Manu Sporny: Yeah, I think it'll be fine…

David C: Okay. Yeah.

Manu Sporny: if I'm you're welcome to stay around and kind of chat about
that. I'll try to make sure that the call continues to thanks everyone.
over to you, David. Take care.

David C: Okay. yeah, it's working.

David C: So there is an issue where I proposed a change of title.
unfortunately I don't have that issue number directly to hand. I don't know
if anybody else does let me just see if I can find it. and I could then
share my screen and show it to you. yeah, it's issue number 30. Okay.

David C: do people want me to share my screen and show that if I can do
that? Let's share screen. I've never done this before, so tell me if that's
working. let me go to here.

David C: Hello.

Dave Longley: Yep.

Ted Thibodeau Jr: Yes.

Kayode Ezike: Yeah.

Phillip Long: It's fine.

David C: Can people see Yeah. This is So was the discussion with data model
for verifiable lists of verifiable potential length is very long but it
gets across the three things that it's two it's only data model for
verifiable lists and the verifiable lists are for entities that are in the
verification data model my wife just taken a phone call in the same room as
me right okay she's gone now that so I don't know what people think about
that verifiable accreditation list Dave has put in

Dave Longley: Yeah, I thought that title seemed a little bit long as you
were saying. it may be a little hard to understand. because It's a data
model for some kind of lists that are about verifiable credential entities,
which could be more or less anything. And so we might want to make it a
little more specific to our work and reuse that accreditation language that
we just recently adopted. so I made that other proposal for verifiable
accreditation lists and if we need a subtitle about data model or something
we could do

Dave Longley:

David C: Yeah. the…
00:50:00

David C: what it doesn't say is that it's verified crediation of what and I
wanted to get in it was for the VC data model which was the last three
words in my title were meant to say that it's for the verifiable credential
data model.

Dave Longley: Yeah, we might be able to do that with a subtitle and that
way we keep the main title

David C: Yeah. Yeah.

David C: So in other words, we want to say I don't mind that as a main
title, but we need to say it's a data model and b it's for entities within
the VCDM. Yeah. Seems to all right.

Dave Longley: Yeah, I was just trying to edit my thing with a little
subtitle. let's see.

David C: Because I think the world seems to have agreed that verifiable
credentials is the W3C term now,…

Dave Longley: A data model for verifiable credential and crediting Yes,…

David C: haven't because the other people are not using that now, are
They're using think digital credentials or Yeah.

Dave Longley: that's right.

Dave Longley: I'm just going to edit my comment. I don't quite like that
subtitle,…

David C: It's crazy.

Dave Longley: but I think the subtitle needs more work. so other people
could make other proposals there.

David C: I quite like it myself. Okay. I think that's good. So that was a
valuable five minutes and it's at least got something for people to work on
now. and we can do that in our own time. So I just want to point to people
to say taking on board it is a data model and we want that to be somewhere
in the title even if it's only in the subtitle. Again does what's the VTDM
one?

David C: Just remind me is that verify potential data model is that in the
full title yeah me let me look yeah so that's…

Dave Longley: Yeah, I would have to look. I think that's right.

Phillip Long: I think that's correct.

David C: why I think we maybe ought to put data model into the title rather
than in the subtitle.

Dave Longley: I don't know that there's a hard rule. if we can have a
shorter title that accomplishes the same thing, I think that's fine. we
could, of course, have it verifiable creditation list data model. It's kind
of a mouthful then. but the issue is open,…

David C: Yeah. Yeah.

Dave Longley: so people could put some more suggestions in there and then
see what other people think.

David C: Okay, I'm happy to close the meeting now if nobody else wants to
say anything. Okay. Okay.

David C: Thank you everybody and thank you Manuel for chairing it so
successfully and hope speak is it are we meeting weekly or fortnightly? All
right, because I was away every Wednesday I had something on all day, so I
couldn't come in. So, you next week then hopefully. Thank you guys. Bye.

Dave Longley: I believe it is weekly same time input.

Dave Longley: Thanks everyone.
Meeting ended after 00:53:59 👋

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