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

CCG Incubation and Promotion Meeting Summary - September 24, 2025

*Attendees:* Benjamin Young, Dave Longley, David Chadwick, Dmitri
Zagidulin, Hiroyuki Sano, Kayode Ezike, Manu Sporny, Parth Bhatt, Phillip
Long, Ted Thibodeaux

*Topics Covered:*

   1.

   *Poll Results Review:* The meeting began with a review of the results of
   a recent poll regarding community priorities for W3C specifications. High
   support was shown for verifiable credential APIs, barcodes, and verifiable
   issuers, while verifiable credential wireless received less support. The
   results will inform a proposed charter, which is anticipated to face
   objections.
   2.

   *Verifiable Issuers and Verifiers Spec Use Cases:* The core focus was
   refining use cases for the verifiable issuers and verifiers specification.
   Three main use cases were discussed:
   - *Directory of Known Entities:* A list of KYC-verified entities, useful
      for displaying information and allowing users to make their own trust
      decisions. Discussion centered on whether this is a standalone
use case or
      a subset of a broader trusted list. It was ultimately decided to
include it
      as a legitimate use case, clarifying that it represents a minimal viable
      usage of KYC data.
      - *Fully Decentralized Use Case:* This use case focuses on
      verification without a centralized published list. Verifiers
rely on a set
      of trusted roots, with issuers providing verifiable credentials
      demonstrating their authority to issue specific credentials. The group
      agreed on using the language "willing to accept" or "willing to share"
      instead of "authority to".
      - *Trusted List Use Case (David Chadwick's contribution):* This use
      case involves a trusted list where entities are validated, allowing users
      to either rely on the validator's trust or conduct their own
verification.
      This use case requires a more comprehensive data model to encompass all
      necessary information.
   3.

   *Data Model Discussion:* A significant portion of the meeting involved
   discussion about the minimum viable data model needed to support the use
   cases. The group aims for a cohesive, additive model rather than using
   profiles for different use cases to avoid complexity. The group agreed to
   first define a superset of data fields encompassing all use cases and then
   minimize as needed.

*Key Points:*

   - There's a need to balance a comprehensive data model with minimal
   viable subsets for specific use cases.
   - The "directory of known entities" use case, initially debated, was
   accepted as a valid, minimal use case.
   - The fully decentralized use case will use "willing to accept" or
   "willing to share" language.
   - The data model will be developed iteratively, starting with a superset
   and refining through use-case alignment, rather than pre-defining profiles
   for each use case.
   - Next steps involve writing up the detailed use cases and then focusing
   on the minimum viable data model to support them.

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

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-09-24.mp4
📖 Transcript

Sep 24, 2025
CCG Incubation and Promotion - Transcript *Attendees*

Benjamin Young, Dave Longley, David Chadwick, Dmitri Zagidulin, Hiroyuki
Sano, Kayode Ezike, Manu Sporny, Parth Bhatt, Phillip Long, Ted Thibodeaux
00:00:00


*Manu Sporny:* All right. Hey everyone, let's go ahead and get started.
We've got a good number of people on the call and the people that we need
to have the discussion on the verifiable issuers and verifiers list. Uh so
that's good. Um I forgot to add to the agenda for this week that we're also
going to cover the results of the poll um and just you know get cover any
questions people have about it. Um since that's uh completed uh and this is
the incubation and promotion call. Um and then we'll quickly go into the
core set of use cases that we've identified for the verifiable insurance
verifier spec. ensure that we have uh alignment from uh both Dimmitri and
David uh on those and then we will probably talk about uh what um we'll
probably talk about uh what uh sorry the recording stopped. Why did the
recording stop? One second. Let me see what's going on here. Can folks hear
me?
*Dave Longley:* Yes.
*Manu Sporny:* All right. Uh let's try this again.


00:02:47


*Manu Sporny:* Looks like Google crashed. Um all right. Uh sorry. So go
going back to the agenda. Sorry. Now Gemini's also stop taking notes with
Gemini. Don't do that. All right, we're we're just gonna see what happens.
Unfortunately, this probably means that we're going to lose all of the
transcription in the entire recording for today. Uh, which is very
unfortunate. Um, but good to know that it's not just Jitsi that has these
issues. Trillion dollar companies have these issues as well. Um, all right.
So uh going back uh sorry the agenda for today is to cover the um uh the
results of the poll um to uh go over the use cases for the verifiable
issuers verifier specification uh and then talk about what the minimum
viable data model is to address each one of those use cases. So largely
today we're going to spend time on use case discussion and minimal viable
uh data model to do that. Um okay uh any other updates or changes to the
agenda?


00:04:08


*Manu Sporny:* Anything else folks would like to cover? All right. Uh if
not, let's uh go ahead and talk about the results of the uh poll. Um I did
uh uh uh publish some thoughts about uh you know analysis on what the poll
results might mean. Uh of course please there many perspectives. So if
other folks have a different perspective on the poll results please let us
know. Um, in general, uh, we got really good turnout, a good number of
responses, 40 most of those people, if not all of them, uh, have been with
the community for a long time and understand kind of what the poll was
asking and, uh, probably have a very good feeling about, you know, where
things stand uh, in their particular market verticals. We did get, uh, you
know, engagement from multiple market verticals, which was also good. um
not as much as I would have liked to have seen but you know uh still good
uh healthy feedback nonetheless. Um uh what uh Christopher mentioned was
that he looked at you know the level of interest in most of these
specifications and they were pretty they all of them had fairly high
support.


00:05:29


*Manu Sporny:* Um uh yesterday on the uh VCOM call uh Dave Longley you
mentioned that it's kind of expected because these are CCG work items and
we have been incubating them for quite a while and so people do know about
them and there was support to incubate them in the first place. So that
that part of it not surprising. Um I think uh there's some other feedback
that was you know really interesting. I'm not going to go over it here. Set
those thoughts to the mailing list. Um uh but uh what what this means is
that we have a lot of work ahead of us. Um uh there were some things that
were very, you know, strongly supported like the the verifiable credential
API for life cycle management was high on the list. Um uh uh uh barcodes is
kind of high. verifiable issuers. Wireless wasn't as high like you know if
we want to look at specs that you know the community didn't prioritize as
high as other ones the VC's you know verifiable credential of wireless uh
didn't have as much support as the other ones.


00:06:40


*Manu Sporny:* Um uh refresh was you know people want it but you know it's
not going to be the end of the world if it doesn't get delivered within you
know a couple of months. um quantum safe data integrity crypto suites.
Everyone seemed to really want to see it happen, but we have zero editors
for it. So, it's not going to happen unless we have editors step forward.
Um we'll see what the current editors uh uh who who volunteered for the
work. We'll see if they have anything to say about that. They didn't fill
out the poll, which means they might not have seen it happen. Um uh and
just a variety of other things. So, so we've got good feedback. We're going
to send this on to, we've already sent the results on to the VCWG chair uh
and the W3C staff. Uh it will uh result in a a proposed uh charter uh with
these items in there and then uh almost certainly that charter is going to
be formally objected to um just based on some rumblings we've we've heard
about.


00:07:48


*Manu Sporny:* Um, and you know, we'll deal with the formal objections and
then, uh, we'll we'll continue the work here, uh, regardless, right? Um,
uh, okay. Uh, let me stop there and see if there are any additional
thoughts or questions on the results of the poll. Okay. Hopefully that
means the results are fairly straightforward. Nothing too surprising in
there. Okay, so that's it for that one. Uh, next up, uh, are our use cases
for the verifiable issuers and verifiers spec again, which we're going to
rename at some point probably, uh, but just not right now. Um during the
last call uh we um we discussed kind of three core use cases uh with the
specification um and it's effectively you know the the train set of use
cases or the train use case um it was uh the use case that Dmitri mentioned
kind of the directory of known issuers uh or known entities s uh and then
the uh fully decentralized use case where you don't have a list and it's
not published um but it is you know uh delivered in a way that uh gives the
verifier or whoever's receiving the list or or the the claim that you have
the authority to or whoever issued this this thing you are holding had the
authority to issue it.


00:09:30


*Manu Sporny:* Um that's um uh in a in a decentralized way. That's the the
third kind of use case. Um let me pause there to see if there are any
questions. David, I know that you weren't able to make the call last week.
I'll ask if there any questions that you have or Dmitri, I don't know if we
were able to cover everything uh uh last week to kind of anchor those three
core use cases.
*David Chadwick:* Yeah. Um, first of all, on on Dimmitri's use case, I I
don't see that as a full use case, but a subset of a trusted list use case.
In in other words, just a list of here's everybody in the world seems to me
to be not that useful because you don't know anything about them. So, but
it is a precursor to a trusted list. So it's you say here are the people we
know about and this is what we know about them. So I think his use case
should not be included because it doesn't say and here's what we know about
them.


00:10:42


*David Chadwick:* It's just here's a bunch of entities. So that's that
comment on on the second one. You the the the decentralized use case. Um I
understand that there was a slight if you like um conflict in what you
said. You said nobody knows there is no list but then uh I want to know if
this guy is trusted and someone tells me that he is. So I don't quite
understand how that uh sort of works. If you could give some more
explanation that would be useful.
*Manu Sporny:* Sure.
*David Chadwick:* Thank you.
*Manu Sporny:* Yeah, I can go into that. Um, I'm putting myself on the
queue that the, you know, I think Dimmitri had a very, and Demetri, maybe
you want to, you know, speak to this, but Dimmitri had a pretty solid
reason for this. I mean they they use this mechanism of there being a list
out there with uh a list of effectively known entities to some organization
um in using that for example just to display stuff on a screen like you
know we know who this identifier is it's you know the university of so and
so here's the their logo and and that kind of stuff so I agree that it's
could be viewed as a subset but you know the whole reason we have use cases
is because we have concrete create things, you know, problems that people
want to solve.


00:12:01


*Manu Sporny:* And so not putting that in as a use case is probably it's
not an option, David. I we can't we can't, you know, I I I think there was
consensus last week to put it in there. If you think it's a subset, I mean,
that's fine. Um but, you know, I think we're beyond the point now where
we're just going to say no, that use case. we're not going to do it because
um well anyway I'm I'm trying to say like we need to establish some core
use cases. This use case is important to Dimmitri. I think everybody else
in the group has accepted it as an acceptable use case. It should go in the
document. Um uh go ahead Demetri. He might be muted.
*Dmitri Zagidulin:* Yeah, I just wanted to clarify uh that it's not that
it's not just here's a list of entities. Uh it's specifically here's a list
of KYC entities. Here's a list of uh uh entities whose identity was
verified by the list host and in a lot of cases that's the key information
uh for the verifier to make their decision.


00:13:15


*Dmitri Zagidulin:* So that's it.
*Manu Sporny:* Yeah.
*David Chadwick:* Yeah. So you see there is there is some trust coming in
there. So it's not just a list of here's a list of people that I have
verified their details and I know who they are. Right. So so the use case
is not fully specified unless it says that. So there is some trust there.
There's trust in the publisher of the list to do KYC on on people. Okay. Um
and and that needs to be added to the um to to the use case if it's not
already there.
*Dmitri Zagidulin:* Do you mind do you mind repeating the the first part uh
that you said uh your your voice The carpal.
*David Chadwick:* Well, having having a list is having a list is is
necessary but not sufficient. That's what I'm saying. Having just a simple
list is it's necessary. It's not sufficient because you have to say
something about the list for it to be a trusted list. And what you're
saying now is that yes, we've done a full KYC on these entities and we know
they're not bots and we know they're not um you know fake fake Russian
whatever.


00:14:36


*David Chadwick:* Yeah. So, so there is some trust there. So, that is that
is what your trusted list is. It's a list of trusted known bonafide
entities.
*Dmitri Zagidulin:* I think we caught most of that, but it's
*Manu Sporny:* Yeah. Yeah. Yeah. Um, David, would it be possible for you to
dial in or use some other audio source? Your your audio starts out okay and
then it starts dropping and speeding up and slowing down and becomes
garbled. I think we're we're kind of getting most of what you're saying,
but this has been, I think, the third time in a row where it's, you know,
hit that hit that kind of state. I don't know if it's possible for you to
use a local dialin No, it's a it seems like it's a network or compute issue.
*David Chadwick:* Yeah, I don't I don't know why I don't know why that's
the case. I I don't know if it's the fact that I've got the speaker on full
volume. Let me If I mute the speaker.


00:15:32


*David Chadwick:* Okay. Um does this make it better now because I've muted
the speaker. did or is it still just as garbled and you still can only hear
half of what I'm saying?
*Manu Sporny:* Uh, we can we can No, we we can hear you. We we can hear you
now. I think there's a little bit of a delay, but look.
*David Chadwick:* Let me put the Right. So, I've put the speaker back on
now so I I can hear your answers.
*Manu Sporny:* No, it's it's fine still. It's it's just goes goes in and
out. Anyway, let's let's go to Dave Lonley.
*Dave Longley:* Yeah, I wanted to highlight that I think we have two uh
different use cases for uh the the two different or for the variety of
different features we're considering here. Uh the the sort of known
directory I think is for or it can be very clearly used for a use case
where the user is making trust decisions. So there is no additional trusted
list. But if you know who these entities are, that can be displayed to a
user in a trusted interface with w with well-known information and the user
can make a choice as to whether or not they want to interact with that
entity because they they trust the information that's being displayed to
them.


00:16:43


*Dave Longley:* And so their their trust list is just in their head uh or
you know what however it is that end user wants to make this choice. So,
this would be something that might be displayed in a digital wallet as
someone surfs the internet and they're not looking for someone else on the
internet to tell them whether or not they should trust some piece of
information. They're finding out exactly who it is they're interacting with
and then they're making their own trust decision. And I think that's a
different use case from I would like to know whether someone else would
accept these credentials or whether someone else thinks this other party
should be able to ask for this information. Those are two different one is
sort of like a delegate. I'm delegating to someone else uh trusting that
they will have a useful or safe opinion on some matter. And the other one
is I would like to make these decisions myself but I need to be sure I want
to make sure I have good factual information on which I'm making those
decisions.


00:17:46


*Manu Sporny:* All right. So, where are we with this particular discussion?
Uh, you know, it's it does sound to me like we've got two different use
cases. Um, go ahead No, you just you your audio just kind of got corrupted
again.
*David C:* Um, yeah, I've switched browsers. So, I don't know if this is
better for you or not. Um, whether it was So, it's got to be do to do with
the Wi-Fi then, hasn't it?
*Manu Sporny:* Mhm.
*David C:* Um, what I'll do what I'll do is I'll see if I can plug plug in
um internet in or something, an Ethernet cable or something like that, but
I've got to find an adapter for the Apple. Okay. So what I wanted to say
was um to answer Dave, the the purpose of the trusted list data model is
indeed to say this guy uh who you trust has validated these entities and
here is the information about them. So you can also do your own validation
if you want. So the data model has all those facts that you need.


00:19:01


*David C:* So they were put into the data model Dave to allow people to
make their own decisions if they want. Uh if not, they can just say, "Okay,
this guy's put them there. Um I'll go along with it. Did people get that?
*Dave Longley:* I I think I I think I made that out. Um, sure. But I I my
read on your your brief conversation with Dimmitri, if I got that right,
just a couple of minutes ago, was that if you don't use if you don't say
anything other than who an entity is in like you choose the fields from the
data model that are available and you just say uh all I'm saying about
entity X is is who they are. Then that's uh necessary. but insufficient.
But I think that it might be sufficient for some people to make certain
trust decisions. So I I would disagree that it's not that it isn't
sufficient for that use case. Um I'm sure there it's certainly insufficient
for use cases where you want to uh where your trust decision is going to
depend on hearing more about you know you know you don't know who this
entity is and you need other pieces of information to be said about them.


00:20:14


*Dave Longley:* for example, the such and such government or such and such
other party would accept a credential that says X Y and Z from this party.
Like you might need more fields. Um but I I I think what how many fields
you need is is uh depends on the use
*Manu Sporny:* Yeah, I mean plus one to that and I I think Dmitri that's
you know effectively what Dimmitri's use case is is we can have a whole
data model and it can be a very big rich data model that lets you get very
specific about every aspect of whether or not you should trust a particular
entity or not. Um however we we are talking about use cases here and use
cases use subsets of that data model. Uh and you know if if all I'm trying
to do is display information um on you know I've I've got like an issue ID
and I just want to display some information their logo and their name uh
and I want to depend on somebody else's KYC process to do that. Um, and I
don't really care about what credentials they can issue and and that kind
of stuff.


00:21:30


*Manu Sporny:* I'm going to use a subset of the the data model to do that.
Like that's a legitimate what we're saying that is a legitimate use of the
data model. Um, however, if I want to be a little more specific, maybe I
also would like that to express the credentials that they're allowed to
issue and the date ranges they were allowed to issue those credentials in.
um that's a that's you know I would have to add more to the the published
data to to do that and then if I wanted to further you know talk about I am
a part of this trust network or you know this this entity is a part of a
certain trust network and these are the legal implications and their KYC
processes and all of that that's yet more information I can add to the data
model but that doesn't invalidate Ditri's use case right Dmitri's use case
is a minimum viable usage of, you know, KYC information where he may not
need anything beyond that. And I think that's that's a legitimate use of
the the the data model.


00:22:32


*Manu Sporny:* Uh, go ahead, David.
*David C:* Yeah. I think I I think what what Dimmitri is implicitly stating
is that there's implicit knowledge. Okay. Um which has not been explicitly
stated either in the list uh or by the participants, but they've got this
implicit knowledge and they're using that to determine because I know now
who this person is, I'll use my implicit knowledge to determine whether to
trust them or not. I think that is is what is underlying Dimmitri's
Demetri's use case. And and the way we address that then is we we make
certain fields mandatory and we make other fields optional. So the name or
the identity of the entity must be a mandatory component of the trusted
list. um the credentials they're trusted to issue and their schemas etc.
*Manu Sporny:* Sure. I uh Demetri, you're going to have to speak up on
whether or not you you're implicitly or you know trusting something
implicitly. I I don't and regardless of what Demetri says, I don't think
there's implicit knowledge there. Like what if I just want to display, you
know, I I can say, "Hey, I I am using so and so to do the KYC on these
things and I'm showing you logos and in pictures, but I have no idea
whether or not they're allowed to, you know, issue this credential." But


00:24:09


*Manu Sporny:* for the purposes of this, you know, online open- source, you
know, uh, credential viewer, it doesn't really matter, right? So, so
there's no implicit knowledge there. It is a legitimate use to to not care
about that information, right? Um, um, and and and state that I do agree
that, you know, they're probably going to be mandatory fields and
everything, but we need to actually get to a data model that everyone
agrees on to figure out what the mandatory fields are. So I think we'll get
there. But again going back to the use case reiterating Dimmitri's use case
is legitimate. It is using a subset of the uh data model and maybe there's
a minimum viable set of properties that need to be used. And that's you
know why Dimmitri's use case is useful to to put in the spec. Uh, that's
Okay.
*Dmitri Zagidulin:* agreed on and all gaps.
*Manu Sporny:* Um, go ahead, Dave.
*Dave Longley:* uh I typed this in their our chat just a list of statements
that I think it would be useful for this data model to be able to to make
um and and separated that from how that information might be used.


00:25:19


*Dave Longley:* So it would to to cover Dimmitri's case and David's case
and I I think all the cases I think we're interested in here. We want to be
able to say entities have certain properties or certain attributes. We just
lost David. Uh I can wait or I can repeat when he returns. Um I'll I'll Oh,
he's back. So, we want to be able to say entities have certain attributes
or properties. I should have kept the same language there in the text, just
said attributes. Uh, we also want to be able to say things like entity A
says that they would accept a credential or a claim from entity B or entity
A says they would be willing to share a credential or a claim with some
other entity C. And I think if we're able to say all those things and then
say them in greater detail based on whatever is in the data model, I think
that covers the cases.
*Manu Sporny:* All right. So, where do we want to go from here? Um, I think
Dimmitri's use case is useful to establishing the minimum viable data model.


00:26:45


*Manu Sporny:* Um, I think David Chadwick in Isaac's cases are useful for
establishing the uh, you know, the the does the data model cover everything
that the EU needs. Um, though I think, you know, we'll have to break that
down a bit bit more when we get there. Um and then the decentralized one is
you know what's the minimum viable way of achieving this use case but not
requiring the use of a single published location uh on the internet. I
think that's the that's the difference with the third use case is that uh
while you could publish it in a centralized place um we are saying you
don't have to um uh and and you know and it should still work um okay so
have we established that we're going to put the use case Dmitri pointed out
for the reasons we've discussed today Um, David, I know you're jumping in
and out, but um are are you still objected to mere's use
*David C:* Now, what I'm what I'm doing, I'm I'm trying to uh connect with
the wire with the land with an actual cable to see if that improves the
audio.


00:28:06


*David C:* Has it made any difference because I'm using a a LAN cable now?
*Manu Sporny:* No, no, unfortunately it has not.
*David C:* Oh, that's really weird, isn't it? So, I've tried different
browsers. I've tried different methods of uh connecting to the network and
um and every time I messed up.
*Manu Sporny:* Yeah, it's probably your upstream, you know, data provider.
It's there's some kind of weird packet shaping that's that's happening on
um or dropping that's happening on your connection. Anyway, let's David, we
need to move on.
*David C:* Yeah.
*Manu Sporny:* Um do you object to Dimmitri's use case still or you
understand why the group feels it's a legitimate use case?
*David C:* Yeah. Sorry. Yeah. Well, no. I I I understand it understand it
better. Um, and there has been some some information provided. So, it's not
just uh dragging information from anywhere. And I think in his actual real
life use case anyway, where they're all universities, there's a lot of
implicit knowledge there because they're probably only adding people that
they know about in their particular, you know, particular realm anyway.


00:29:21


*David C:* And he's maybe not factoring that in when he's saying, you know,
it's just a list, but it's not.
*Dmitri Zagidulin:* Exactly.
*David C:* It's a list of universities that are known about and been
validated. Yeah. So that's implicit knowledge, you see.
*Manu Sporny:* Okay. But how does that change what we're going to do,
David? Or we're we have to write up a use case. Are we writing this use
case?
*David C:* Yeah. Um well, there's still trust there. That's the point. It's
not just, you know, a random list of people from the internet which you
get, you know, when you when when you go on to um Instagram or Facebook or
anything, you know, anybody's anybody, you've got no really idea who they
are. And it's not that that Demetri is doing these are genuine bonafide
universities. Um but he's not saying anything about them other than the
university, but there's implicit knowledge there that a university is
already something special that's been got a charter and is allowed to give
degrees and da da da da.


00:30:24


*David C:* So I don't I think that ought to be put into the use case
somehow. to show that it's not it's not just a list of any entities, but
they're entities that have been validated in some way.
*Manu Sporny:* Okay, sounds good. So, Dimmitri, does that give you enough
to write up the use case paragraph on it?
*Dmitri Zagidulin:* I think so.
*Manu Sporny:* Okay. All right. Great. All right. So, so next step here
then, Dimmitri, is for you to raise a PR on the spec, adding it to the use
cases section. Does that work?
*Dmitri Zagidulin:* Yeah, I think so. Mhm.
*Manu Sporny:* Okay. Um or I mean, we might already have it in there, but I
I don't think we do. Um Uh Okay. All right. Um second use case. Um uh
David, we're going to cover yours last because it has the most most
complexity uh to it. Like there's, you know, there are lots to the the data
model. Um the the the second use case uh is the fully decentralized one.


00:31:22


*Manu Sporny:* Um where uh the uh where let's say it's an it's a verifier
verifying something. Um the verifier does have a set of roots of trust that
it supports. Uh meaning it it would um you know it it defers on whether or
not the credential has been issued by a valid issuer um uh to another
authority to a root of trust of some kind. um and that route of trust has
provided a verifiable credential uh to the issuer um uh of something. So
again we can look look at a university uh you know as an example uh maybe
there's some kind of uh board of colleges in a uh in a nation state. um uh
that board of colleges approves what the legitimate colleges um that the
accredited colleges are um in that nation state. Uh and it would issue a
you know u one of the credentials we're talking about in this spec uh to
that entity. Um that would establish it as uh allowed to uh or or or you
know they they not allowed they they we need to figure this language out.


00:32:50


*Manu Sporny:* We they they are they would trust them uh to issue a
credential of a certain type. Um uh meaning that a university is uh you
know a computer science university and they are allowed to issue uh or they
would trust uh you know degrees uh in computer science that uh that
university uh were to issue. Um uh and they would issue that credential and
hand it over to that university. So that when the university issues uh such
a credential to um a student that has graduated um that they would also
provide could also provide uh that um uh accreditation uh credential uh to
the student. So when the student goes and presents their diploma uh to a
verifier, they would present the diploma uh sorry the verifier would say
here are the roots of trust that I uh accept. The presumption is that board
of colleges would be in that root of trust. The digital wallet software
would then say ah I I have a credential uh issued by that route of trust
that says that this issuer is allowed to you know is is you know trusted to
issue um uh university degrees for computer science.


00:34:16


*Manu Sporny:* And then the wallet when it presented the uh the uh the
diploma would also present the credential that says that you know the
college board approves the university to issue computer science uh degrees
at which point the verifier receives it sees the path up to the root of
trust uh and also uh sees uh that the individual has a diplom diploma. Um,
so the third that that use case uh needs to be kind of detailed um uh in
and talked about. Uh, go ahead Dave.
*Dave Longley:* Um, I just want to propose at least some temporary language
so we can avoid saying uh authority to um and I was going to propose again
we can improve this in the future but willing to accept or willing to share
being the main things that uh main statements that these parties would be
making. So again if people are okay with that I think we should embrace
that for now and we can change it up but willing to accept or willing to
share. I think that covers the issue case and the verification


00:35:33


*Manu Sporny:* Sounds good. Um, okay.
*David C:* Well, yeah, this is spot on. I mean, all you've done there is
said rather than having a centralized list of a thousand entries, we've
created a thousand individual line items and given them out to the thousand
people uh who are in the list. So, it's just absolutely totally in
agreement with the kind of data model. I see nothing wrong with that use
case at all.
*Manu Sporny:* You know that's good. I think the the we we so we tried to
raise that PR David and it got blocked. So there is some disagreement there
that we need to work through. Otherwise the PR would have gone in. Right.
So that the PR that we raised um you know that was discussed for weeks. We
got to the end of it and it was clear that we did not have consensus to
merge it. If you think we now have consensus to merge it, that's good. Uh
maybe we can you know rework it and and pull it in. Um, so,


00:36:37


*David C:* Ah, yes. But man M man, the reason it was blocked is because you
didn't use the data model. I just said your use case is fully in line with
the data model, but your PR didn't use any fields from the data model. You
invented your own fields. That's why it was blocked. If you want to go away
and write the PR using existing fields from the data model, it'll go
straight in. Well, well, you can't write an example then.
*Manu Sporny:* Yeah, we don't have agreement on the data model, David. The
the properties in the data model, there were multiple issues raised about
it. So, I I don't think, you know, we can look at the specific Well,
*David C:* You you can't write an example of a data model that doesn't
exist. So, you can put the use case in, but you can't have a PR with actual
JSON statements because you'll be making JSON statements from a data model
that doesn't exist. So you can certainly have the use case that's
absolutely fine but the actual examples in terms of JSON cannot be written
until the data model's agreed because those examples will be using fields
from the data model.


00:37:39


*Manu Sporny:* We can do that by putting in an issue saying that we're
still aligning the core data model. That's sometimes how it happens. Uh but
the other way that we can go about it is we can talk fundamentally about
the core data model and things that you know we agree on and and don't
agree on. and I've raised a bunch of issues and again you know it it the
faster way would have been to just kind of you know pull that in but since
it's the PR is blocked we are going to have to go by line by line in the
data model and um talk about you know what the minimum viable set of data
model items would be to achieve Dimmitri's use case the decentralized use
case uh and the use cases that you put forward
*David C:* Yeah. No, that's that's exactly what I wanted the VC working
group to do. And there was an issue of we put a note in there that it's the
role of the VC working group to determine which fields are mandatory, which
fields are optional.


00:38:39


*David C:* So that's been our intention from day one. We didn't want to
because we're just a small group. I think there about five of us maximum A1
time in working in that group. We didn't want to say these are the fields
you must have and these are the fields you may have. We wanted the VC
working group to do that.
*Manu Sporny:* We have to get to some kind of consensus that we're
generally in the right direction before we hand the spec over to the VC
working group. It will not be handed over to the VC working group until we
figure this stuff out in the CG. Brent does not want Brent and they don't
they don't want us to work this out in the working group.
*David C:* Okay.
*Manu Sporny:* They want us to incubate the work here, figure out what the
proper data model is and then once we have much stronger alignment, move it
to the working group. we can't move it to the working group until until we
have that. Which is why I said we've got to we've got to come to some sort
of consensus on the core set of use cases and the core data model at least
to the point where we think we're able to


00:39:34


*David C:* Yeah.
*Manu Sporny:* achieve the the use cases that that you know folks want to
achieve here.
*David C:* Okay.
*Manu Sporny:* Um okay.
*David C:* Yeah. No, that's fine. That's fine. Yeah, that I'm happy with
that.
*Manu Sporny:* All right. So so we Okay. So what are the next steps here?
um we are going to document these use cases. So David uh I don't know if
you feel the the the thing that you are attempting to achieve with the data
model if it's got if the current use cases cover that or if you would like
to write up a different kind of use case. Um okay the the use cases that we
currently have in the specification uh came out of rebooting the web of
trust I
*David C:* Um, yeah. I mean, it's a long time since uh we looked at that
text. So, Isaac and I can go over that and and see if it's it's it's
sufficient.
*Manu Sporny:* think they have almost no connection to the the current data
model um meaning train was you know I don't think train was a part of the
conversation at reboot including um it was it predated um uh that work.


00:40:48


*Manu Sporny:* So yeah, it take a look through and make sure that the you
know the training use cases are covered and then um I can take an action to
write up the use case for the fully decentralized case.
*David C:* Yeah. Yeah. Sure.
*Manu Sporny:* But it is good to hear David that you believe that you know
it's a subset of the use case that you're talking about that it's it's
*David C:* Yeah. Oh yeah. Yeah. Absolutely. I mean it it's the difference
between if you like as an analogy having an LDAP directory that people can
go to look up information or giving every entity in the LDAP directory a
verifiable credential which is their information that they can prove is
genuine.
*Manu Sporny:* Yep.
*David C:* Yeah.
*Manu Sporny:* Yep. Yep. Agreed. Agreed. Okay. Good. All right. So, it
sounds like we have alignment on the use cases and documenting them. Um,
the next step here is for us to do that. So, so Dimmitri, you need to raise
a PR.


00:41:40


*Manu Sporny:* Uh, David, you and Isaac, you take a look and raise a PR um
for for use cases and then um I'll raise a PR for the uh the fully
decentralized case. Uh once we have those in there and we have agreement,
you know, on those use cases, I'm sure it'll take some words smithing. Uh
after that um the step after that is going to be establishing a minimum uh
minimum set of data fields uh that we need uh to accomplish each use use
case. Um in doing that I think we should be we we should be flexible
meaning that the people that have the use cases should use the data models
that they want to ignoring the current data model unless you want to reuse
it. Um and then we can align uh those through the use cases and then apply
the changes to the the core data model if if needed. Um does that sound
like an okay way to proceed?
*David C:* Um I think a an alternative way is to um have a data model which
is um a superset of all the data that people choose for their use cases and
then to make those use cases profiles.


00:42:59


*David C:* So this the sort of the international standards way of doing it
is to specify a data model and have a profile and what the profile does is
it eliminates duplications and things that are not needed. It says the
profile will just have these these and these fields and and that's a
different way of doing it. So you'd have a profile for the for Demetri's
use case and you'd have a a profile for the fully decentralized case.
*Manu Sporny:* Yeah, I I I get what you're saying, David. I'm hoping that
we can avoid profiles. I I it it depends on how strict we're going to be,
but you know, there's a data model and you can use the data model for
different use cases. You know, I don't when you say profile, I I'm I'm
concerned about like OID, you know, OIDC profiles, which tend to be very
complex things. um uh that you know frankly lead to failures to interrupt
uh in a lot of cases. Um so I' I'd ra I'd rather make sure that we've got a
cohesive purely additive data model where you know you use certain fields
to accomplish certain things and we don't start talking about every single
different use case has a different profile.


00:44:18


*Manu Sporny:* Um I I think we we we might be overengineering it at at that
point. Um but that I think that conversation is very much in the future. I
think fundamentally you know we need a data model that holds properties
that can achieve the use cases and and yeah David maybe we work on a
superset that just has all of those and then we'll figure out
*David C:* Yeah.
*Manu Sporny:* how to minimize um and and align over time.
*David C:* Mhm. Okay. Okay.
*Manu Sporny:* All right, that sounds good as a path forward. Um uh does
anybody else u uh object to that path forward? Um meaning we will start
executing on that starting as early as next week. Okay. Uh that sounds
good. Um and I think that's it for uh the call this week. that was the the
bulk of the uh discussion that we wanted to have. I will note that uh if
folks want to start providing input on um the issues raised on the data
model and the examples and uh you know this stuff.


00:45:33


*Manu Sporny:* Uh please do try to jump in and provide some thoughts uh
especially on uh you know 30 the new ones right um uh 30 through 36 that
will help us kind of have some of this discussion asynchronously before we
get um uh to to bringing up each one of these issues in the call and trying
to discuss them. Um okay uh that's it for the call this week. Are there any
other things that uh folks wanted to discuss this week?
*David C:* I I' I'd like to just Sorry, not not just between me and you,
man. How can I resolve my um problem with the network? Because I I make
Zoom calls to people and they have no problem. And the video calls, I mean,
this isn't even video. I'm I'm I'm I've got no camera on. I make Zoom
calls. I have WhatsApp uh calls with people. Um, I have Microsoft, the
horrible software. Um, and I've had some calls in the past. I don't
understand why why Google Meet is messing up my voice.


00:46:45


*Manu Sporny:* Yeah, I don't I don't know either, David. There's so many,
as you know, there's so many things that could be going uh on. Uh there we
do have dialin numbers. You could try that. You know, that dial in tends to
not uh I think there's a option to call in uh not using computer audio. Um
and then you know tethering to the mobile networks might work.
*David C:* So, so I mean you mean put the telephone number to WhatsApp and
then make a call on WhatsApp or do you mean or when you say dial in?
*Manu Sporny:* Um okay. No, don't do it. You know that'll just I I mean
like use the cellular network to call in. Um no, no, no.
*David C:* Oh, right. Okay. Well, if Yeah. If I'm going to make an
international call to America, it's probably going to cost huge bucks.
*Manu Sporny:* They're local numbers. Google Meet has local numbers.
*David C:* Oh, okay.
*Manu Sporny:* They'll have a local number that you can call.
*David C:* Oh, that.
*Manu Sporny:* Yep.
*David C:* All right. So, I'm actually then on my mobile phone, so I'm not
using my laptop at all.
*Manu Sporny:* Um Okay.
*David C:* Is that that's what you're suggesting?
*Manu Sporny:* Um don't use the Wi-Fi.
*David C:* Yeah. Yeah.
*Manu Sporny:* Use use the LTE network um or the 5G network. Uh okay, we've
got to uh close the call out. Uh thank you everyone uh for the discussion
today. Um uh we will meet again next week and continue this discussion.
Thanks all.


Transcription ended after 00:48:13

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