[MINUTES] CCG Incubation 2025-12-04

Here's a summary of the meeting:

*Meeting Summary*

The meeting focused on the "Verifiable Issuer Verifier" specification
within the CCG Incubation group. The discussion revolved around the data
model and the structure of the JSON representation. Key decisions and
action items included restructuring the spreadsheet to resemble a JSON
tree, clarifying the "recognized by" property, and aligning with existing
W3C DID core spec service sections.

*Topics Covered:*

   - *W3C TPAC Report Out:* Review of the decisions made at W3C TPAC
   regarding the incubation work. This included the adoption of specifications
   for the next rechartering proposal and prioritization of work items.
   - *Verifiable Issuer Verifier Specification:* Detailed discussion and
   restructuring of the spreadsheet to match the JSON representation. Key
   terms and properties, such as "recognized by" and "recognizer," were
   examined and refined.
   - *Data Modeling and JSON Structure:* Deep dive into the data model's
   structure, focusing on the hierarchy, and the relationships between various
   components (e.g., recognizer, list operator, service, etc.). The goal was
   to establish a clear JSON representation.
   - *Alignment with Existing Standards:* Exploration of using the W3C DID
   Core Spec service section to model the service object.

*Key Points:*

   - The incubation work was adopted for the next rechartering proposal at
   W3C TPAC.
   - The group aimed to reshape the spreadsheet to look like a JSON
   document, addressing the structure and relationships of the data model.
   - "Recognized by" terminology was clarified.
   - The list operator and issuer were defined as synonymous.
   - The meeting produced action items to address specific questions and
   align with existing standards.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2025-12-04.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2025-12-04.mp4
*CCG Incubation - 2025/12/04 10:01 EST - Transcript* *Attendees*

Benjamin Young, David C, Manu Sporny, Parth Bhatt, Phillip Long, Ted
Thibodeau Jr
*Transcript*

David C: Are you chairing the meeting? not.

Benjamin Young: Hey y'all.

David C: I wasn't sure whether there was going to be a meeting today or not.

Benjamin Young: Either I think it's who's going to show in the call that
you go over the spreadsheet of terms and that's probably what we'll review
here. I don't know that there's anything else that this group is working on
particularly links in the chat for anybody…

Manu Sporny: Yeah, I think that's a good idea. we could do a quick little
report out and then just keep going through that document. I think we're
just trying to drive towards a cohesive PR for all these things. So, yeah,
I think that sounds like a good plan for

Benjamin Young: who doesn't have it. And I'm sorry I didn't add that to
this meeting's agenda. I did last time. I think one of the dangers of
autoconfirmed meetings is in December anyway. People assume they're not
going to happen.

Manu Sporny: Yeah, I typically make it there. You can edit the event and
just add an agenda for it and it'll push out a reminder to everyone. And I
think everyone's used to getting those and that's why people might be don't
know if the meeting's happening. but regardless,…

Benjamin Young: Gotcha. Yeah.

Benjamin Young: Yeah. Yeah.

Manu Sporny: I mean, I think much, what's on the agenda today is kind of
the boring plumbing work of working through,…

Manu Sporny: bike shedding.

Benjamin Young: Not here,…

Benjamin Young: right? Yeah.

Manu Sporny: And we just have to get through it. And I don't know, I think
there's enough of us to do the boring plumbing work today, so we might as
well get on with it. Yep.

Benjamin Young: Yeah. Yeah. that Philip's here, right? we did annotate it a
bit last time, Monu. I walk you we added a new property field that ended up
mostly being notes in a way about what we take out in favor of other stuff
sometimes. And then there's some feedback that's been happening in the
column E as well.

Manu Sporny: Okay, it sounds good. Do you want to continue sharing this
meeting, Benjamin, since you're on the No,…

Benjamin Young: It's really up to you. I should have checked with you when
you got back sure.

Manu Sporny: it's totally fine. Yeah, I'm happy for you to you to do it and
I can just provide input if that works for you or…

Benjamin Young: Yeah, that's fine.

Manu Sporny: if you feel like you've got strong opinions on the data
modeling naming, I can share instead.

Benjamin Young: No, I really don't. I'm happy to share this one.

Manu Sporny: Okay.

Benjamin Young: Is this all essentially going to be about that now that the
other…

Manu Sporny: Thanks. Yeah. Yeah.

Benjamin Young: because it had been about the wider incubating specs, all
of which are now VCWG specs or to be okay.

Manu Sporny: Let's cover that maybe as the first agenda item is just like I
don't know if David or Phil have heard about what happened at TAC and then
we can then get into okay what do we need to finish up in this incubation
group and honestly it's just this spec right the verifiable issue verifier
thingy.

Benjamin Young: Okay, great.

Manu Sporny: …

Benjamin Young: We might also rename the series as well.

Manu Sporny: yep. Okay.

Benjamin Young:

Benjamin Young: Cool. But why don't you do that and then I can catch you up
on what we did while you were out.

Manu Sporny: Sounds all right. So, brief report out on W3CTPAC as it
relates to the incubation work that we've been doing in the W3C credentials
community group.

Manu Sporny: the high level takeaway is that everything we've been
incubating and wanted to put on the standards track was adopted as things
we would put in the next rechartering proposal. So that's the good news is
that we didn't get any push back on any of the work items. People were
concerned about the workload which we're all concerned about. but we said
that we would deal with that where, we would move specs forward that had
the most amount of editors doing work. And then the specs where people
aren't doing work or didn't have enough editors or is kind of lagging
behind or whatever, those would be secondary tertiary priority. So, we'll
just prioritize things and move them forward.
00:05:00

Manu Sporny: We had a little bit of that prioritization discussion at
W3CTPAC and again it was fairly standard benign stuff. There was fireworks
no one getting upset about any of the work. it was a good discussion so we
had a long list of specifications like this one verifiable issuers
verifiers which we're talking about today verifiable credential API render
method confidence refresh method postquantum signatures all of those things
are in scope and I think Avon's put together a charter update we just need

Manu Sporny: to kind of review it. so that's good news. the did methods
working group had some discussion. There's a charter proposal that's going
to go forward. We are expecting one formal objection on it but we've spent
months discuss trying to find a way through it and it just seems like
there's just going to be a formal objection on it. so so the outcome of TAC
was that we have a very good plan and consensus on what the next two years
of work is going to entail. Now it's just a matter of doing the work right
which is difficult in and of itself.

Manu Sporny: So what that means is that all of the specifications except
the postquantum suite and the verifiable issuers verifier spec are in a
state where we could hand it over to the working group and the working
group could take the verifiable issuers and verifiers and the postquantum
suite need a little more work and we can continue to incubate it here. So
that's kind of what the discussion today is but at some point when we feel
like the bones of the thing are fairly together well enough that we can
hand it over to the working group then we just hand it over to the working
group.

Manu Sporny: So, there's no big rush. It'll be included in the next
rechartering thing and our decision to transfer it to the working group
will be up to us and the working group to negotiate later on. so that
relieves some of the time pressure that we've kind of felt over the past
couple of weeks. that's kind of where we are. so it's good news, all
around. what we should probably focus on in the incubation group is just
verifiable issuer verifier. just the specification. there was a desire by
the chairs of the VC working group. So for those that haven't heard yet,
Brent Sundell has a new affiliation. He works for Ubico now.

Manu Sporny: he will continue on as a chair of the group with Ubico joining
the group. so that's good news. and then also Phil Archer who's XW3C but
now at GS1 is joining Brent as chair which will be excellent because Phil
is deeply involved in supply chain work using DIDs and Cs in that work. So
he'll be a part of that and the new rechartering and all that kind of
stuff. they suggested that we try and run as much work in parallel as we
can. So separate calls for render method and confidence method and
verifiable issuers verifiers and that sort of thing.

Manu Sporny: There's seven specs. I don't think we're going to have seven
parallel calls. So we're probably going to end up at three and we'll just
have three which are very focused. So verifiable credential API is one of
the calls. The other one is probably going to be render method and
confidence method. and then the other one is, going to be some other set of
Probably verifiable issuers and verifiers is going to be kind of high up on
that list. People want to see something happen with that spec. okay, so at
a high level, that's kind of what happened at W3CT. Any questions, concerns
about any of that?
00:10:00

Manu Sporny: Okay. then, back over to you, Benjamin.

Benjamin Young: Yeah, thank you,…

Benjamin Young: Yeah, let's look at this spreadsheet. the link is in chat.
Bill, I think you might have joined afterward. I'm not sure that Google
persists it, so I'll do it again. it's the same one we looked at last time.

Benjamin Young: Mostly I'm going to go over it just quickly to catch Manu
up. and then we can dig into Go ahead.

Phillip Long: I'll check.

Phillip Long: It's there. but wasn't there also a discussion about whether
approaching it this way versus approaching it from the perspective of the
JSON LD data model that it represents also part of the discussion last time?

Benjamin Young: Yes. Yes, it was. so just for some context, the group was
hacking at this spreadsheet for a while and many of us were confused about
what the JSON would ultimately look like.

Benjamin Young: So there was a discussion of someone and this is still
probably where it fell on the ground creating JSON objects that would
represent this language so that we were then looking at JSON and not a
spreadsheet. that didn't happen because of turkey day and whatever else
happened in between and we didn't really assign who was going to do that.
So consequently we still just have the spreadsheet. I think what we could
do though is live edit some JSON for some of this if we wanted and start an
issue space or…

Benjamin Young: something where we reshape some of this. does that sound
okay Phil

Phillip Long: That sounds reasonable. I think the concern arose that
depending the terms chosen and whether they're a class or a property and
the seemed to be somewhat dependent on the structure of the JSON.

Phillip Long: And therefore whether it would be included in a particular
way or not. and…

Benjamin Young: right? Yeah,…

Phillip Long: and that was why I was asking and I believe Dave was David
was in making contributions to that discussion and I think he's here isn't
he?

Benjamin Young: David's here,…

Phillip Long: Are you speaking, David? Because you're muted.

Benjamin Young: but on mute. Yeah.

David C: Sorry, I was on mute and I was actually on a different window. I
was actually looking at the list. So, I had to then go out of there and
come on to this to take the mute off. Yeah. No, we had some really good
discussions at the last meeting and I also explained to people the
rationale for why it was the way it was and that restructuring creates
quite a lot of simplification and as the red lining is showing a lot of the
properties can be replaced because the generic properties that Mando added
at the beginning they are relevant

David C: in the subsequent sections. And so the names can be removed and…

David C: replaced by their generic equivalents.

Benjamin Young: Yeah. …

Benjamin Young: one approach we could take is to duplicate this sheet and
then be more aggressive in how we reshape the spreadsheet so that it starts
to look like a JSON tree. that would maybe be a faster way forward than
starting new documents because I think one of the things that tripped me up
was the casing of the properties is atypical currently. go ahead

Manu Sporny: Yes. To what you just said, Going back, I think the plan was
to basically get through a rough cut of the spreadsheet and…

Manu Sporny: then we would just propose what the JSON objects would look
like in the issue that's tracking it. and then kind of go from there if
that makes sense. So, we were

Benjamin Young: Yeah, I think…

Benjamin Young: what we hit though was the group was having a really hard
time imagining…

Benjamin Young: what those JSON shapes would look like from the
spreadsheet. all classes can have section of these weren't clearly
filtering down in people's minds.

Manu Sporny: Yeah, gotcha.
00:15:00

Benjamin Young: And hence there's duplication list name which you can see
in column D or take it out and use name so it might be I mean we can try
this and see if it works duplicating the sheet and then trying to express a
hierarchy and being aggressive with stripping these out down to whatever
their more generic terms are

David C: Yeah, It's pretty small.

Benjamin Young: Does that sound like it would work?

Manu Sporny: I'm fine to go with whatever the group would be helpful for
the group.

Benjamin Young: Okay. Yeah,…

Manu Sporny: I mean, we could share an editor, right, in a …

Benjamin Young: I can do that.

Manu Sporny: HackMD or whatever. …

Benjamin Young: Yeah, I will share this window and then we can turn it into
real Jason if we want, but I was just going to stick with this hierarchical
approach. Is that painfully small for everyone? I can zoom in.

Manu Sporny: it's pretty.

Benjamin Young: That better? give it a second.

Manu Sporny: Maybe two more zooms.

Benjamin Young: Two more.

Manu Sporny: Yeah. Yep. Yeah. There we go.

Benjamin Young: That good. And I'll try and squish some of these columns
down. Big 4K monitor, so I have no idea how it comes across.

Phillip Long: Looks good on my 4K.

Benjamin Young: Thank you. cool. So, as mentioned, a lot of these are going
to be shared throughout. So, let me duplicate the sheet first.

Benjamin Young: I'll just call it reduced for now. so yeah, we ran into
lots of things early on like this recognized.

David C: Yeah, this is particularly contentious from my opinion …

Benjamin Young: Go ahead, Dave.

David C: because I don't really know what its purpose is and B. this is
supposed to be a trust list. So, whoever publishes the list, it's meant to
be trusted. and that's the whole point of a trust list. and you either
trust the list originator or you don't.

David C: they're recognized by is saying, " I actually think that Manu is
recognized by Path. So, you should trust Manu Manu because Path recognized
him." And that is really re really bad because first of all, how do I know
that Arth said that about what evidence is there that that person who is
supposed to be doing the recognizing is actually doing the recognizing? And
I'm just not making it up. I might say, Manu is recognized by President
Trump.

Benjamin Young: Go ahead.

David C: I don't think he is, but I could state that. So, I think this is a
really questionable property.

Manu Sporny: Yeah, it was an let's see this property and let me try to see
summarize this property the recognized buy thing was a result of the
conversation that we had a couple of weeks ago where people said we don't
want to publish trust lists.

David C: Okay.

Manu Sporny: So there remember I mean we had this whole conversation
started with there are multiple different use cases one of them is the use
case that you're highlighting David which is I do want to publish a trust
list and I want to do it in the EU way. that's one set of use cases.

Manu Sporny: The other set of use cases is I'm announcing to the world that
I recognize this entity to issue these types of credentials and I am saying
that they're good enough for me. I'm not making a statement beyond that.
I'm not saying that, I'm a government entity and I'm officially anointing
these groups. saying if this organization makes a statement about using
this type of credential then it's good enough for me right that's what it
was meant to be the language is I agree with you David problematic and we
need to bike shed the language but that's where this came from is that it
was the decentralized use
00:20:00

Manu Sporny: case, right? the non-European Union use case where you just
want and I am literally saying if Parth issues a credential about
programming practices, it's good enough for me, Meaning I trust him to make
those types of statements. that's what lines 13 through 15 are. I'll try to
find the link to the issue where we talk about it in a bit more depth.

David C: Yeah. Yeah. Okay.

Manu Sporny: That's it.

Benjamin Young: But before we dive back into that,…

Benjamin Young: and David, I know you luckily got a response. I wanted to
see if and we can finish up this conversation and then address what I'm
about to say. one of the things I wanted to do was try to make this whole
thing look like a JSON document. And so I think we need to circle back to
what is the top level type for this thing that we're doing. And then I'll
reshape the structure into a more tree JSON thing. Remove the headings and
start moving stuff around. But I didn't want to spook everyone when I
started deleting stuff. but let's go ahead and…

Benjamin Young: wrap the conversation about the recognized thing and then
I'll do some restructuring but we will have to come back to what is the
type of the top level document All right.

David C: Yeah, the top level.

David C: Got you. so what I would say to Mano is first of all, who signs
the list? because it needs to be cryptographically protected or otherwise,
no one can trust it. that even you said that the person you're recognized
by, we don't even know if that's true. So if you are signing the list,
okay, and you say I recognize this other entity, then in fact what you're
saying is This other entity is a trusted entity. and they have published
the following information.

David C: So that's more reasonable because then we know that our trust is
in you because you've signed it and you're saying I trust this other entity
and in my opinion this other entity has stated the following. Okay, I think
that's the semantics you were meaning Manu. and then someone should be able
to follow a list a link and they should be able to go to the other entity…

Benjamin Young: Go ahead, man.

David C: who you might not recognize and then they should be able to find
out that indeed that other entity is making the same statements that you
were asserting that they made.

Manu Sporny: Let me share my screen. I don't disagree with much that you
said, David. I'm part of me is struggling because I'm trying to also
represent Joe Andrews viewpoint on all this stuff. who felt very strongly
that we shouldn't be publishing trust lists and we shouldn't be calling it
trust stuff that we should find a different word for it and that's kind of
where this stuff is coming from. So, I think what you're saying is valid,
David. I think we tried that before and we got objections and the people
that are objecting aren't here today. And so I'm hesitant to try and have
the conversation without them here, I guess, is going back to what do these
look like? this is what I was trying to get at.

Manu Sporny: Benjamin issue 37 we have this rec and even here this
recognize but thing like my comment here is don't really like this term I
don't think anyone does right now but the recognition criteria and things
like that we reworked this based on Joe objecting to the language that we
were using but if we want to look at what do these things actually look
like and map them to the spreadsheet that This is where the spreadsheet
items came from is we have examples in these different use cases. this is a
It's a verifiable credential noting that recognition and recognized by are
problematic and we probably need to bite shed those terms. so we're trying
to iterate towards something that worked but The VC is issued by some
entity.

Manu Sporny: So this is a recognizer for lack of a better term. and the
credential subject is you are identifying an issuer. You're saying they're
recognized issuer. They're recognized by this other entity which is the
entity that issues the recognition credential. So how this did web
recognizer example thing signed the VC and they're also in the recognized
by entry. that's what it's being kind of used for right now. Again I'm not
strongly defending it. I'm just saying that's where we got to in the group.
00:25:00

Manu Sporny: And then the recognition criteria is issuance of a certain
type of credential that matches a credential schema for a certain period of
time and then you can run the schema against a VC and see if that entity is
recognized for issuing that particular VC. so that's this use case. This is
a fully decentralized verifiable issure use case. This is what the JSON was
expected to look like. And then the terms from here, the new ones were
moved into the spreadsheet. and this is just me giving background for kind
of where we got those things in the spreadsheet from and how these things
end up being realized in an actual VC.

David C: Okay, that's helpful.

David C: So basically the recognized by is the issue field.

Manu Sporny: It the issuer can be misconstrued in this way …

Manu Sporny: which issue are you talking about are you talking about the
issuer right yeah Yep.

David C: Yeah, I understand there's a problem in semantics there. Yeah. but
I mean essentially it's the issue of the verifiable credential as you said.

Manu Sporny: Yep.

David C: Right.

Phillip Long: Good job.

David C: So what you don't actually So if you got some crypto protecting
something somewhere, you have to give the name of the entity that's
producing the crypto. So the issuer of the credential needs to be mentioned
somewhere within it…

David C: because you can't just have a signature without an identifier of…

Manu Sporny: Mh we do so…

David C: who signed it, But unless it could be just a public key, I guess
we could go down the fact that you have to find out who's got the public
key and it's the public key that's issued it. So you're not saying who
issued it, in which case you'd remove it alto together, but normally we
would put the identity of the signer,…

Manu Sporny: if you look…

David C: right? Yeah.

Manu Sporny: if you look on the screen the issuer is this recognizer entity
right so here's the VC we do specify…

David C: Right. Yeah.

Manu Sporny: who the issuer is and then we restate it here and again this
is a modeling question like if it's here do we really need to me mention it
here and I forget who but

David C: You don't need it. No.

Manu Sporny: felt strongly that the argument for needing it and again I'm
arguing for somebody else that's not on the call that the argument for
needing it is you want this object from a data modeling perspect
perspective to kind of exist on its own right this object in here exists
independently of the verifiable credial potential that wraps it and it may
be useful to have a recognized by property for the recognized issuer. So
this is a recognized issuer. Who are they recognized by? it's this entity
and in the graph of data you've got everything that you kind of need right
here. Right?

David C: got it. Yeah.

Manu Sporny: you use the outermost wrapper to determine if you believe the
internal stuff is valid. And if the internal stuff is valid, you probably
just end up storing the internal stuff in your database that you use to
make business decisions. So that's the argument for recognized by being
here. it's not a cut and dry, There are arguments against putting it in
there, but that's where we got to with the data modeling.

David C: Yeah. Yeah.

Manu Sporny: And again,…

Phillip Long: That's right.

Manu Sporny: I mean, I think we spent all of 15 minutes talking about this.
It hasn't been analyzed to any depth.

David C: What one thing I find quite weird is we've got a working party. I
wouldn't call working group. We've got a working party working on trusted
issuers and…

David C: then some guys come along and say we don't want you to call it
that. In fact we don't want you to be working on trusted issuers. I think
that's a bit weird actually.

Manu Sporny: It's a centralization concern and…

Manu Sporny: and this is something that I agree with. the way the European
Union is addressing this concern I think is deeply problematic from a
governance standpoint. I get that the EU is really government-ledd,
regulationled, centralization when it comes to these trusted lists, but
that being the basis of the design leads to deeply centralized systems.
00:30:00

Manu Sporny: So I do think that is a very strong argument for we don't want
to use that model for a decentralized identifier system. That's not to say
that the use case isn it is valid. The EU has decided that that's the way
that they want to model this stuff, but from an self-s sovereign identity
and SSI principles perspective, it's kind of antitheical to the kind of the
ecosystem. And so the question is, all right, if we're not going to
centralize it in the way the EU has decided to do,…

Manu Sporny: what does that look like? And can we use the same kind of spec
to achieve that fully decentralized use case? And I think the result there
is of course It's just a different vari we can use some of the same
terminology but the data model is different because the data model is not
centralized right

David C: I disagree with your premise…

Manu Sporny: I think the difference here is the presumption that there is
an authority.

David C: because a list of one is just a subset of a list of a thousand. So
your decentralized model is a list of one. Therefore you can use exactly
the same data model of a list of a thousand or you just have one entity in
the list.

Manu Sporny: the presumption that there is a governmental authority that I
get the point that you're making David and…

Manu Sporny: and meaning from a technical perspective you're just listing
something an entity that you recognize to issue something right…

David C: Correct.

Manu Sporny: but right so at the base level that's fine but that's not what
the EU model does right that the EU model is not saying that the EU model

Manu Sporny: is saying there are special entities that are anointed by
government that have a legal authority above and beyond anyone else. and
it's that level of

David C: Yeah,…

David C: but we don't have to have that in Our spec is a data model spec.
And this fully decentralized entity that's publishing a list of one, he is
the list operator, He's a list operator and he chooses to put one entity in
his list. So we can use exactly the same data model. We just alter your
misconception that this list operator has to be government recognized.

David C: I don't think that's stated in the current document and we should
remove any notion of that from the data model but say that the list
operator can be an individual it can be a company it can be a state or
whatever and we leave it at that and that's what the data model Right.

Manu Sporny: I agree with that,…

Manu Sporny: David, but if we look at the data model that's in the spec,

Manu Sporny: for the EU stuff. It has properties in there like policy or
legal notice in PSP certifications, right? that's massively heavy weight.

David C: Right. Good. Yep. Yeah.

Manu Sporny: As these are things that go well above and…

David C: But They can be optional fields. And also in your data model,
you've got the criteria for the recognition. The criteria is the policy,
right? No,…

Manu Sporny: beyond what the fully decentralized case is trying to get at,
Governance URI contract type policy sets. I mean these are very heavyweight
government process things, right? so I

David C: no, no. Look, I mean, forget I'm talking about a semant at the
semantic level, When you say the criteria that I've recognized someone by,
that's that is my policy. It's the criteria I've used to recognize.

David C: So let's use the same term and let's put the definition of the
term sufficiently broad so it covers both the fully decentralized case and
the national case and any shade in between.

Manu Sporny: Yeah, sure.

Manu Sporny: That sounds good to me. my only concern at that point is that
we are now deviating from the trust tsp stuff that the train work like we
are deviating from that…
00:35:00

Manu Sporny: if we do it that way which I'm fine I totally agree with

David C: …

David C: we're going to deviate massively. Yeah, we have to deviate…

Manu Sporny: Mhm.

David C: because as in our early discussions, Manu, we recognized that in
the EU, the top level object was of multiple classes, which is why it led
to TSP name and list operator name because the class was a multiple class.
And we agreed early on that it would be sensible to have individual object
classes and then they could all have name. Right? So,…

Manu Sporny: Mhm. Okay.

David C: so we've already deviated substantially from the EC model by doing
that.

Manu Sporny: I mean, if that's fine, if we don't have objection to doing
that, then I totally agree with you.

David C:

David C: I thought we Yeah,…

Manu Sporny: What's good?

David C:

David C: I'm sure we agreed more than a month ago, a couple of months ago,
that modeling way was more akin to the way the W3C verified credential
group had done its modeling that they're a single object with a type,
right? So, I thought we'd already agreed on that, which is why we can Yeah.

Phillip Long: So does that mean we need to remove those properties manu
that you were just highlighting in terms of I can't scroll the spreadsheet
but

David C: Which is why we can simplify the names significantly,…

Manu Sporny: Mhm. Okay. Yep.

David C: which We started to do that as you can see last week. No, they're
at the bottom that the service business URI and all that stuff. No, they
shouldn't be removed. that they're there for a purpose. The thing is if you
have a complex model, you can always simplify and…

David C: refine it down for something simpler. If you have a simple model,
there's just no opportunity to put the complexity in that other people need.

Manu Sporny: Yeah. …

Manu Sporny: what I…

Manu Sporny: what we have to ensure here to agree with…

David C: We Right.

Manu Sporny: what David's saying is that there is a EU version of this and…

Manu Sporny: we have to ensure that it maps to the data model that we have…

Phillip Long: is there.

Manu Sporny: which means that we cannot get rid of these things because the
EU model has these things in them and…

Manu Sporny: if we can't do a full round trip that's lossless then we won't
be supporting

Phillip Long: So right and…

Manu Sporny: the EU use case,…

Phillip Long: so that's…

David C: I think that's right.

Phillip Long: where the comment but those become optional or they have a
new definition.

David C: Yeah. Yeah.

Manu Sporny: right? Yep.

David C: Probably the definition is broadened to cater for the fully
decentralized case and they become optional.

Manu Sporny: Yep.

Phillip Long: Okay, that helps. So,

Manu Sporny: Okay. …

Manu Sporny: that Sounds like we have alignment there. Thanks. I was just
kind of sharing to provide the background on that. Benjamin, I don't know
where we go from here, though. What we want to do

David C: I don't know.

Benjamin Young: So, I've been hacking a bit on the reduce tab also screen
share. and trying to reshape it to something like a JSON file. There we go.
so based on the example you were showing,…

David C: All right.

Benjamin Young: Monu, I pulled out the verifiable recognition credential as
the top level type of this object we're inside of. These are a little in
the way at the moment. and then credential subject would be of type issuer,
recognized verifier. Currently with these properties, recognition criteria
would contain just these two as I understand. plus the typical ID type and
more uniquely the credential schema. I don't know if we're still confused
about this, but I was trying to pull the notes up. yeah,…

David C: In terms of terminology,…

Benjamin Young: go ahead.

David C: we've got the typical re well-known term trust or…

David C: We can have recognize etc. Okay.

David C: Because it's a pretty common generic structure in English. We
could recognize by becomes recognizer doesn't it?

Benjamin Young: for line 14.

David C: That's the recognizer.

Benjamin Young: Yeah.

David C: Or recognize or I'm not quite sure what they said or right but…

Benjamin Young: Yeah. two countries divided by a common language,…

David C: but yeah.

Benjamin Young: I don't know which one it is either. I think it's prettier
with an O. Anyway, I think it's probably an E in the US.

Benjamin Young: Not that it matters. yeah,…
00:40:00

David C: And then that becomes the policy.

David C: The recognized criteria is the policy.

Benjamin Young: that might be clearer in that I don't know it feels less
passive maybe thoughts rec recognizer versus recognized by Okay.

Manu Sporny: What feels less passive? Yeah. Yeah. Yeah. Yeah. I'm totally
fine to change it to recognize her. I don't think we were the current
language needed to be bike shed

Benjamin Young: Yeah, that's kind of the goal here, I will leave that
there. I'm pulling up some of these other rows so that we can look at them
in the object we were just looking at…

Benjamin Young: since we're trying to JSONify this table. where would these
guys appear? They are not well formatted.

David C: This is the recognizer.

David C: These are the properties of the recognizer. So, if you want to put
in the column by list of call recognizer.

Benjamin Young: Okay.

David C: Okay. Yeah.

Benjamin Young: I'm going to go ahead and change these things.

Benjamin Young: So list operator information would be or…

David C: This is the recognizer.

Benjamin Young: list operator.

David C: Yeah, it's the recognizer because these are all properties of the
recognizer.

Benjamin Young: Okay.

David C: So it's the recognizer's name, recognizes email address, website,
etc.

Benjamin Young: Okay. Sure.

David C: All optional, right? In most cases. Yeah.

Benjamin Young: Yeah. Philip, I think you were saying something.

David C: I don't think you need list operator there actually…

David C: because recognize there is an object isn't it so you don't need
that level of nesting just delete all right okay got you right right yeah
Yeah.

Benjamin Young: This is the type. Sorry, I'm trying to truncate it because
we're in a spreadsheet, but you can imagine these are all type the bold
things.

David C: Yeah. Yeah.

Benjamin Young: The bold things are type values. yeah, sorry that's
unclear. Yes, I can rework it…

Phillip Long: You can put a key up on the side.

David C: Actually those other properties…

Benjamin Young: if you want. I was just trying to make it…

Phillip Long: No, you're doing well.

Benjamin Young: if you think more of a given it's a spreadsheet.

Phillip Long: You're doing well.

David C: though the properties version ident the first two properties
they're a property of a list not of a list operator the name address email
URL are properties of the list operator…

Benjamin Young: Okay.

David C: but those two are properties of a particular list right Yeah.

Benjamin Young: So, are we going to then have a Oops, wrong thing. Are we
going to then have a And it's probably already down here. There's list name
and whatever. So,…

David C: Exactly. Yeah.

Benjamin Young: is there going to…

David C: Yeah. A list…

Benjamin Young: then be a list property right underneath it.

David C: because the list operator could have several lists. Yeah.

Benjamin Young: So, then we're going to have, type list or something. Do we
have lots of types of lists like these guys?

David C: I think we had three we had three…

Benjamin Young: Trust service provider list and…

David C: which was the trusted issuer and the wallet provider…

Benjamin Young: they would each be a list type.

David C: but It's a type. Yeah, exactly. So, …

Benjamin Young: Are those types of the items in the list or are they the
type of the list? I don't know if that's clear. cuz we're going to first
call out that we're inside of a list and…

David C: right. Yeah. Got you. Got Yeah.

Benjamin Young: then we're going to say what each item in the list is and
I'm guessing it right.

David C: So this is a modeling thing, isn't it?

David C: is to whether you can mix up within one list both trusted issuers
and trusted verifiers. I think it's probably better if you have a list of
one type all your issuers in one list and all your verifiers in another
list.

Benjamin Young: So then we'd end up with something like issuers.

David C: I mean it's going to be quicker to pause as well, isn't it?
Because you go down and say I'm only interested in the issuers that this
guy's publishing. I'm not interested in any of his verifiers.

Manu Sporny: If we look at line 14,…

Manu Sporny: it is already a recognized issue or recognized verifier and
then I guess you link back to the list,…

Benjamin Young: Okay. That's just about…

David C: All right. Yeah. Yeah.

Manu Sporny: so you kind of already Yeah.
00:45:00

David C: Yeah. Yeah. Exactly.

Benjamin Young: where we're going to signal that. So, this is a list or a
collection or whatever it's going to be.

David C: Yeah. Yeah,…

Benjamin Young: And the items within this have the version identifier and
sequence number or the list itself.

David C: The idea I think from memory is that certainly the sequence number
is easy that is as you update your list you increment the secret the
sequence number and…

Benjamin Young: So it's like okay And…

David C: they also have facility for keeping back copies of them.

David C: So if you want to go and look back at some historical list, you
could actually do that. And I think the version identifier is if the list
changes its contents because the standard evolves, then the version of the
list you'd need to know that this is the first version of the list or this
is the second version of list because they've got different properties. I
think that's the idea for that for those.

Benjamin Young: then the items in the list are going to be of what type?

David C: So then you've got the trusted service providers. the other
feature that it's got is that a trusted service provider can actually
provide different types of trust service.

Benjamin Young: These guys.

David C: So, if you think of a university can be a trust service provider.

David C: It can issue verifiable credentials, but it can also be a website
where they accept verifiable credentials from pupils or from people who are
applying for courses and they say, "Okay, give me your verifiable
credential to show that you've already got an undergraduate degree…

David C: if you're applying for a master's degree." so university can be
both a trusted issue and a trusted verifier, So that's…

Phillip Long: And…

Phillip Long: it has employees,…

David C: why Yeah.

Phillip Long: I mean, they're employers as well.

David C: Yeah. Yeah.

Phillip Long: And so they have to be treated in the same way that any
business would be treated.

David C: So that's why that the trusted service provider can offer
different types of service.

Benjamin Young: Okay, I'm bringing up those fields into this space.

Benjamin Young: Is this looking right where this list? So the Okay.

David C: Trust the services would be at a level above the ones below…

David C: because as I said trusted service provider can provide many
different services.

Benjamin Young: I didn't quite follow that.

Benjamin Young: I mean, it's just

David C: No.

David C: I gave it the example of a university who's a trust service
provider.

Phillip Long: Yeah. But…

Phillip Long: but it give me an example…

David C: It can issue verifiable credentials.

Phillip Long: those two things where any entity couldn't be both or…

David C: Couldn't be both.

Phillip Long: or shouldn't be Because from my perspective,…

David C: That's an interesting observation.

Phillip Long: an entity would all could and…

Phillip Long: should be able to be both at any point in time.

David C: Yeah. Yeah.

David C: Because these are roles of course, aren't they?

Phillip Long: Right. Exactly.

David C: We've always said that verify and issue are roles.

Phillip Long: So I don't think so the difference isn't really necessary.

David C: Yeah. Yeah. So sorry the difference in the services is necessary…

Phillip Long: The question is whether that particular thing is included.
Right. Okay.

David C: but I agree what you're saying now is that there is no difference
in a trust service provider because all trust service providers should be
able to do everything right but I think they did differentiate them but

Phillip Long: Right. Right.

David C: But yeah, you're right. You don't need to.

Phillip Long: It just simplifies it, I think.

David C: Yeah. Yeah. Yeah. So the service tells whether what you're doing.
So the actual service is So it's service type, isn't it? Yeah.

Benjamin Young: So on here.

Phillip Long: That's right. That's right.

Benjamin Young: New property like that.

David C: And again s services has to be an outer it has to be a level in
the hierarchy above the following above 28 onwards doesn't it…

David C: because it's a set of services right so that's got to be no I'm
saying under trust service provider there will be another level of
indentation called services and…

Benjamin Young: Is this…

Benjamin Young: what you're saying? And then we've got …
00:50:00

David C: then under services will be current status starting time etc.

David C: So we need Yeah,…

Benjamin Young: so all of this stuff is inside of another list is…

David C: it's inside services.

Benjamin Young: what I got.

David C: They're all properties of a service,…

Benjamin Young: Right. Oops. I always hate pasting in spreadsheets. That
back the way it was. There we go. And then these guys.

David C: right? And then those want to move in then they to move in the
square. That's right. Yeah. Exactly.

Benjamin Young: And then does this thing the services do have a type. It's
whatever that is.

David C: I don't have a time. Yeah. Exactly. Yeah.

Benjamin Young: We don't work.

David C: Isn't that same level of current status?

David C: Why does that have to be a level above All right.

Benjamin Young: It doesn't have to be.

Benjamin Young: It's the way again all of these are I type colon whatever.

Phillip Long: times. Listen.

Benjamin Young: I'm just structuring it this way so we can see a tree in
the JSON LD. It would be type and…

David C: Yeah. Yeah.

Benjamin Young: and then these would come over here.

David C: Right. Okay. Okay.

Benjamin Young: So, I can restructure it. That's more helpful than my nifty
bold and whatever. why don't I do that since it keeps confusing David?

Phillip Long: Yeah, as long as you're doing it with such facility that do
it with whatever way is easiest for you and…

Phillip Long: we'll figure it out.

Benjamin Young: Yeah, I don't want people to keep getting confused.

Benjamin Young: So, just have to move everything over one Is it should
still be in the same spot,

David C: Actually, that outer type is now wrong,…

David C: isn't it? because the because this is something being published by
me.

Benjamin Young: All right.

David C: Whereas I can be a totally decentralized individual or…

Phillip Long: How do you mean it's right up there?

David C: I can be a country.

David C: So the recognized issue recognized verifier that's not there is it
basically yeah…

Benjamin Young: So that the overall structure didn't change. I just
reabeled things so that they were more like the JSON LD in the end.

David C: but I think All right.

Benjamin Young: I mean that the meaning should be identical to what we just
were looking not of the list operator or…

David C: Yeah, maybe we had a debate about whether we should have an issue
property. but these are all properties of the issuer. The list operator is
the issuer. Right?

David C: So type name, address, email. These are all properties of the
issuer and we already have that in our verifiable credentials.

Benjamin Young: is list operator.

David C: The list operator is the issuer of the verifiable credential. so
the type name address in other words list operator and issuer are Verible
credential issuer and list operator are synonymous.

Phillip Long: the quotes around it.

Benjamin Young: I know you're a spreadsheet. You don't like the equal sign.
Leave me alone.

Benjamin Young: Yeah. I just put a space in front of that. So that's all
possible that you can have those in issuer…

David C: So you can move all those properties type name address you can put
them within issue…

David C: because we already did that in some of our VC trials. we put
things like name address and URLs in there. Yeah. …

Benjamin Young: but wasn't there some reason why we had list operator
expressed inside recognizer I thought that was the whole discussion earlier
with you and monu that there was deliberate redundancy yeah we are down to
time I think we're going to have to come back to this in particular I had
fun playing with spreadsheets as I always do.

David C: ask manu to comment on that.

Phillip Long: So there's an action item for Manu to address that difference.

David C: We made good progress today anyway. I think u Yeah. Yeah.
00:55:00

Benjamin Young: Resolve all the problems. Manu get rebase reality.

Manu Sporny: Thank you.

Benjamin Young: Go ahead.

Parth Bhatt: Yeah, I was for the services bject. I was thinking about what
if we just follow the W3C did code spec service section or the list of
attributes there.

Parth Bhatt: I can drop the link in here. It's more or…

Manu Sporny: Yeah, I think that's a good idea.

Parth Bhatt: less similar analogy.

Parth Bhatt: That's what I'm getting.

Benjamin Young: Yeah, I wondered about services too.

Benjamin Young: Okay, I'm going to leave a note for that.

Benjamin Young: And let's come back to that. make it not read. All right.

Parth Bhatt: Sounds good.

Benjamin Young: So, in a week,…

David C: Great.

Benjamin Young:

Benjamin Young: let's do this again.

David C: Good progress.

Benjamin Young: All right.

David C: Yeah. Thank you. Bye-bye.

Benjamin Young: Thanks everybody. Bye.

Manu Sporny: I think all but
Meeting ended after 00:56:32 👋

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