[MINUTES] CCG Incubation 2026-01-22

Meeting Summary: W3C CCG Incubation Call - 2026/01/22

*Date:* 2026/01/22 *Time:* 10:00 EST *Attendees:* Dave Longley, David C,
Manu Sporny, Parth Bhatt, Patrick St-Louis, Phillip Long, Ted Thibodeau Jr
Topics Covered

   - *Call Purpose and Scope:* Clarification of the call's focus, which has
   shifted from general incubation to specific work on verifiable issuers and
   verifiers, particularly the data model.
   - *Verifiable Recognition Credential Data Model:* In-depth discussion
   and review of a draft Pull Request (PR) for the verifiable recognition
   credential data model.
   - *Use Cases for Verifiable Issuers/Verifiers:* Discussion of three core
   use cases driving the data model: educational sector vetting, industry
   consortium recognition, and European trust list requirements.
   - *Data Model Design Considerations:* Exploration of issues such as data
   model size, portability, decentralization, extensibility, historical
   logging, and the concept of "recognized by."
   - *General Properties and Type Definitions:* Discussion on the inclusion
   and placement of general properties (like legalName, imageURL,
   digestMultibase) and type definitions within the data model.
   - *Recognized Action and Recognized By:* Significant discussion around
   how to best model the relationship between a recognized entity, the actions
   they are recognized for, and the entity that provides that recognition.

Key Points

   - *Call Focus:* The call is currently focused on refining the verifiable
   issuers and verifiers specification, specifically the data model, to
   achieve consensus before adoption by the VCWG.
   - *VC as a Foundation:* The work is being built upon Verifiable
   Credentials (VCs), allowing for individual VCs to be issued based on lists
   or registries, and enabling interoperability with other VC features.
   - *Use Case Driven Development:* The data model is being designed to
   accommodate a range of use cases, from simple organization lists to complex
   decentralized recognition systems and compliance with European data models.
   - *Addressing Size and Portability:* Concerns about large VC sizes are
   being addressed through potential mechanisms like external pointers to
   lists, selective disclosure, and the possibility of smaller subset VCs.
   - *Decentralization and Agnosticism:* The model aims for
   decentralization, allowing for recognition at various levels (local to
   global) and is not strictly government-centric.
   - *"Recognized By" Ambiguity:* A significant point of discussion was the
   placement and purpose of the "recognized by" field, particularly in
   relation to recognized actions, with several proposals made to integrate it
   more effectively.
   - *History and Logging:* The possibility of integrating history logs for
   credentials was mentioned, with a note that this might be addressed at a
   different architectural layer or through existing European work.
   - *Recursive Trust:* The data model supports recursive relationships for
   trust, where an issuer can be recognized by another entity, and so on,
   ultimately relying on individual root-of-trust configurations.
   - *Next Steps:* The team plans to iterate on the PR based on the
   feedback, particularly concerning the "recognized by" field and general
   properties, and will revisit these discussions in future calls. The
   inclusion of Dmitri in future discussions related to the "recognized by"
   property was suggested.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2026-01-22.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2026-01-22.mp4
*CCG Incubation - 2026/01/22 10:00 EST - Transcript* *Attendees*

Dave Longley, David C, Manu Sporny, Parth Bhatt, Patrick St-Louis, Phillip
Long, Ted Thibodeau Jr
*Transcript*

Phillip Long: Good morning.

Patrick St-Louis: Hey, good morning.

Manu Sporny: at morning.

Patrick St-Louis: I was asked to host the call yesterday. I'm happy to do
so and facilitates the conversation.

Patrick St-Louis: I'm not too familiar with the ongoing topic, but I can c
surely lead us into it.

Manu Sporny: Thank you,…

Manu Sporny: Patrick. much appreciated. I do have a PR for us to look at
today, which would probably, take up a decent chunk of the call. and I can
also kind of point out where we were on the last call once we start the
call.

Manu Sporny: So h have it as

Patrick St-Louis: Sounds good.

Patrick St-Louis: Could you clarify something? So on the call page it says
this is the incubation or is this the verifier initial recall or…

Patrick St-Louis: is it a bit of both or Perfect.

Manu Sporny: It's a bit of both.

Manu Sporny: So, it used to be the incubation call and we were incubating
all of the specifications that were going into the VC working group. A
large chunk of those were we finished incubation and we put it in this
specification, the verifiable issuers and verifiers thing has taken a lot
longer. we're still trying to get to consensus around the data model. we
are making finally some progress I think over the past month and a half.
and…

Patrick St-Louis:

Manu Sporny: so we need to get it into better shape before the VCWG adopts
So we've been renaming but then what to rename the calls to is in question
because we don't know if we like the name verifiable issuers and verifiers.
So we're trying to settle on a good name before we rename the call. But
yeah I think the only thing we're working on in these calls right now is
the verifiable issuers and…

Manu Sporny: verifiers list.

Patrick St-Louis: And…

Patrick St-Louis: how different is this from something like confidence
method?

Manu Sporny: You mean the purpose of the specification or how the call is
run?

Patrick St-Louis: I mean conceptually because I thought the confidence
method was to add to be able to assert something.

Manu Sporny: It's quite different. Yeah, confidence method is about knowing…

Patrick St-Louis: Okay. Yeah.

Manu Sporny: knowing who the subject is can you do a proof of possession or
something like that. the verifiable issuers verifiers work is about someone
an entity out there publishing a list of recognized entities that takes
certain actions. So that's very generalized, but the idea is how does a
college board,

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: a university board publish a list of all of the universities
and…

David C: All right.

Manu Sporny: colleges that are accredited, or how does a province or a
state get on a list of approved issuing authorities for driver's licenses
or fishing licenses or whatever.

Phillip Long: Yeah.

Manu Sporny: So that's what this work is about.

Patrick St-Louis: So it's very adjacent to trust registries and…

Patrick St-Louis: those types of conversation.

Manu Sporny:

Manu Sporny: Yeah. Yes.

Patrick St-Louis: Overused.

Manu Sporny: I mean, and it is trust list and trust registries, but we
specifically don't want to use that language because we think it's the
wrong language to use. it's the wrong lang.

Patrick St-Louis: Okay.

Manu Sporny: Some subset of us think it's just completely the wrong
language to use. because trust is very much based on perspective and…

Patrick St-Louis: Sounds good.

Manu Sporny: just because somebody publishes a trust list doesn't mean that
everybody needs to trust it, so we focus on, an entity that recognizes
another entity to do a specific action,…

Phillip Long: Absolutely.

Manu Sporny: that's where we are today, that can change tomorrow or next
week or whatever, but

Patrick St-Louis: So, that answers my question. I'm sure I'll have more,
but for now I'm satiated. let's get started. So, yes, welcome to the call
everyone. I'll be hosting a call today. I've been asked to do this for
reasons. So, I'm happy to facilitate the conversation. As I mentioned, I've
been on this call previously. I've been once or twice. It's been a while.
so I'm not too aware of the latest work, but I'll definitely be able to
catch up fairly quick as I'm well aware of other initiatives at WTC,
including the CCG. so today is 22nd of January 2026.
00:05:00

Patrick St-Louis: This is the WTC credential community group incubation
call or for some from what I understood it became a verifiable verifier and
issuers call. so this is what the conversation will be around. this is a WC
meeting so all WC policies are into effect. so if you're not familiar with
those please do so. I'm not too familiar on the agenda today. I've heard
there's a significant PR we'll be reviewing. right before we do this, I'd
like to give some time for reintroduction. Maybe I can start really
quickly. Some people on the call might be familiar with me, other ones not
so much. so I'm a developer. I've been working with digital identity for
six years now.

Patrick St-Louis: I mostly work with the government of British Columbia.
However, I also work on other initiatives and also single project active
with the literary and the open wallet foundation this for the most part. so
yeah, I'm happy to be here and looking forward what the conversations will
be like. if anyone else wants to introduce themselves, I'll leave a couple
seconds of silence for you to do so.

Phillip Long: I think you'll find most of us each other in the call.

Patrick St-Louis: Okay, that's what I assume. you never know. next

Phillip Long: Yes, I think Adam had his hand up by the way.

Patrick St-Louis: Yes. that's the part now.

Manu Sporny: No.

Phillip Long: Okay.

Manu Sporny: That's okay. just for the next item on the agenda.

Patrick St-Louis: So if there's any suggested topic for the agenda or also
any community updates please let us know and I will let you manu introduce
probably your topic.

Manu Sporny: Thanks, Parick. yeah, I don't have any community updates or…

Manu Sporny: anything of that nature. I Let me go ahead and share my screen
here.

Patrick St-Louis: Yep. …

Patrick St-Louis: please take over.

Manu Sporny:

Manu Sporny: There over the past couple of weeks we have been talking about
the data model right we've been trying to unify the data model around and
I'll provide a link to the spreadsheet in the chat channel we've been
trying to unify the data model around three kind of core focal use cases
the first one is one that Dmitri raised kind of on behalf of the education
sector. they have a need to publish a list of just vetted entities they
know who these entities are and they just want to publish a list about the
name of a picture associated with the entity's web page, that sort of
thing. So that is just one use case.

Manu Sporny: It's kind of a your organization, use case. and that's
probably the simplest one that we have. the next use case is one that we
digital bazaar proposed which is focused on a kind of industry consortiums
that want to be able to publish information on who in the consortium or who
in a specific market vertical is allowed

Manu Sporny: to lish certain of ials or is recognized to publish certain
types of credentials. but the other strong requirement we have is it needs
to be fully decentralized meaning meaning that publishing this thing could
be just a local group in your town. or it could be a local government
listing, a set of, for example, building contractors or electricians in the
area. all the way up to, a national government, and then global, United
Nations, publishing these things. So it needs to be scalable from the very
very smallest thing all the way up to a big thing.
00:10:00

Manu Sporny: and we don't want to overemphasize the authority of one of
these organizations. We're trying to keep it as peer and decentralized as
possible. it would be nice if governments, used it as well, but, we're not
building for government. if that makes sense or specifically for okay so
that's second set of use cases and then third set of use cases are ones
that David Chadwick and Isaac had raised around the train work and the
European work around trust list trust registries that sort of thing and
being able to fully express the data model in Europe is also a requirement

Manu Sporny: because they do have a data model for this and so we're trying
to make sure that that data model is fully expressible with what we're
doing. And so what we have here is everything that was in the spec and we
were trying to reconcile all of these things. We have refined it over the
last couple of weeks. So there are some general properties that can go on
each one of these entities, organizations, people whatever and then we are
trying to settle on what are the class names, what are the property names,
what can you have in each one.

Manu Sporny: last time we got far enough along for me to raise a PR. but we
were trying to figure out what are we talking about here? Recognized
entities or recognized issuers or recognized actions that are attached to
recognized, issuers or entities. So, we were bike shedding largely in
trying to figure out what the best data model is here. we also got to
talking about some of the list operators and trust service provider things
that were there. David made a very good suggestion that we were struggling
a bit going top down. So David suggested maybe we try going bottom up. So I
expect we'll try a bit of that today. But we got far enough last time for
me to raise a draft PR for us to take a look at.

Manu Sporny: So this is our verifiable issuers verifiers repository. We
have kind of two PRs that have been stuck, based on the discussion that
we're hap having. I opened a new PR for the verifiable recognition
credential. and this PR tries out some of the language that we had last
time. So I'm going to go and look at the preview for this. and it's
additive only. It doesn't try and remove anything from the spec just yet.
there's a data model section that we have and then the sections that were
added were sections 4.1 through 4.5. but let's focus on the verifiable
recognition credential because this is at the top.

Manu Sporny: And then there are examples here of what our current data
model looks like based on our conversation last week. and so what I'd like
to do is take a little bit of time to look through this and then look at
the examples and then see if the examples are working out in the way that
we thought they would. and then if we're happy with that, then go into
discussing our third use case, which is the European use cases and
representing that data model. Let me pause there for half a second to see
if there are any questions, concerns, anything of that nature. And let me
bring up this link here. Please go ahead, Patrick.

Patrick St-Louis: not to make sure just to point out so looking at this I'm
happy that this is a verifiable credential that was going to be my question
is there a possibility besides being in this list or registry to have the
member be issued a credential but since from what I understand the registry
itself is a credential I think that's very useful I'm thinking about linked
verifiable credential…

Patrick St-Louis: who is all these things all of a sudden it makes this
compatible with all these other features so yeah I'm just happy to see that
if I understood what it's going Oops.
00:15:00

Manu Sporny: Yes. Yes.

Manu Sporny: You're understanding is completely correct. Yes. That was
another driving reason for why the thing's a VC. and that's a good point. I
don't think we call it out as one of the focal things like that's one of
the goals is that an individual should be able to get one of these just for
the credential they have. So let's say that they have a university degree
they should be able to also get the recognition credential from the
university or from somewhere it doesn't matter where but using that they
should be able to present both their university degree and…

Manu Sporny: the recognition credential in a peer fashion so that the
verifier doesn't need to go out and fetch anything right I mean clearly
they'll have a root of trust or…

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: root of authority or something like that the verifier will But
as long as you are there in the credential then everything should work out.

Patrick St-Louis: Yeah, I'll put myself like you.

Dave Longley: And I was just going to say and if you have that rooe of
trust, when we're done with this, if we've modeled everything correctly,
you could get started building that route of trust building your tree of
trust from the first verifiable recognition credential you get in and using
that to verify other verifiable recognition credentials. So you can build
that tree from there and that' hopefully whatever I just said will all also
make sense with whenever we're ready for comments on this one. I've got a
few comments on what we have in the PR.

Patrick St-Louis: Can I go?

Manu Sporny: Absolutely.

Patrick St-Louis: It's I'm sorry. yes, I will go. my one maybe concern I
would have would be the size that this credential could take over time. and
I'm wondering if it's possible to have a sort of a partner credential,
which is a smaller version with just one of the subject, If one of the
subjects says, "Yeah, I want this list, but I'd like to have more portable
or a smaller version of this credential that just talks about me." And that
credential could, have a way to discover the full list or anything of the
sort.

Patrick St-Louis: That matter.

Manu Sporny: Yes. Yeah,…

Manu Sporny: that is supported today with what we have here. and that is a
concern what happens when you have 5,000 entities on this list and each
entity can do five or six different actions. all of a sudden you've got a
multiund kilobyte up to a megabyte, VC, which we don't really want. there's
no reason why you couldn't split it out into a separate thing. you could
split it into multiple different lists, but then the question is how do
people find these other lists? so that is work we still need to do and
okay, so the data model definitely supports that, but how do you signal it
so that So, we need to probably work on that a bit.

David C: I can come in there Manu because I think we've already done it. We
did it in one of the older versions actually that the verifiable credential
actually what it contains is a pointer to an external URL with because
we've already got that facility within verifiable credentials to have a
pointer and to have a hash of the pointer to make sure that it's not been
altered and then you go off to the web page and that web page can be as big
as you want and you can validate that it's not been changed because you've
got the hash

David C: of it inside the verifiable credential. and I think there's an
example we did have an example in this document earlier on. I don't know if
it's still there or not but it was originally. So that's to do with the
size thing by having this external list that's pointed to

Patrick St-Louis: Go ahead, If you want to reply to that,

Manu Sporny: Yeah, I mean that's right, David. so that is one way of doing
it. I guess I was speaking to us exploring the space a bit more to make
sure that that is the way we want to do it. absolutely, we can do it that
way. however that might be slightly different from what Patrick was talking
about which is breaking off a subset of the list for keeping in your
wallet. and I don't know if we've really discussed at what point is it too
big right I mean clearly it's use case dependent and different market
verticals will have different opinions on it.
00:20:00

Manu Sporny: Another thing we haven't discussed is do we want to be able to
say that this list is a part of a bigger collection of lists and see also
these other lists. we don't necessarily have that in the specification
today. So I'm just noting that we can solve the problem in a multiple
different ways. we probably need to,…

Manu Sporny: provide some guidance in the specification on these are the
ways you could address the problem. Or if we want to just say, no, we
really want to be specific about there's one really good way of doing this.
that's

Patrick St-Louis: Yeah.

David C: I Yes.

David C: So I think that there could be certainly multiple ways and the way
we did it in the train project is different DNS entries had the lists and
the D and you could point to other DNS entries from different entries. So
you could actually have a web chain of entries in the DNS. so that's
another way of doing it. But instead of having DNS entries, you could have
verifiable credentials because a verifiable credential can be regarded as a
single DNS entry. I hope that didn't confuse you,…

David C: Patrick, talking about the DNS, but

Patrick St-Louis: I think I'm slowly yeah,…

Patrick St-Louis: I just need to put that into context. I think I
understand two things. So, another I'm going to say argument or reason for
smaller lists, You could have so I'm thinking about very link verifiable
presentation or more specifically something like who is use case in web
where it's just an issuer they put a bunch of credential about them in a
presentation and this is sort of a list of anyone can pick any credential
that pertains to their use case and if they're part of five list then we
have the size issue times five right

Patrick St-Louis: which can only grow. So I think having a way to express
in a smaller size with only one single subject would be very useful. My
other question or more comment has to do with a topic that's very popular
these days with sort of a history or log events and the sales
specification. I'm wondering if there was some thought about, having some
kind of log of this list that coexist with the list or if there was a
mechanism to do this. has this been considered when people are removed or
blacklisted? I don't know. yes man.

Manu Sporny: yes at a high level no it's not in the spec yet I think what
we're probably waiting on is for the verifiable history cell discussion to
get to closer consensus on what if there is going to be a common log format
which I think all of us hope there's going to be a common log format. I
think if that happens then all of a sudden you can basically take this
credential and shove it in the log and…

Patrick St-Louis: Yeah. All right.

Manu Sporny: every time it changes removing whatever you add it to the log
entry and then you can get a good nice verifiable witnessed log of how this
credential has changed over time. So my hope is that problem is solved at a
different architectural layer. certainly can be solved at a different
architectural layer. but again I think it's a good kind of future
discussion for us to have on okay how do you go back in time if you need to
yep it go ahead

David C: Yeah, the European original work has history logs in it.

Phillip Long: Oops.

David C: So it does actually have the history. So you can actually find out
which was the last list, when does the current list expire,… things like
that. but we didn't put that into this specific spec because it does
increase the complexity quite a lot.

David C:

Patrick St-Louis: Yes. Yes.

Patrick St-Louis: Dave

Dave Longley: Yeah, regarding size concerns and privacy concerns, I also
wanted to mention that selective disclosure could be very helpful with
these lists. this is actually one of the few use cases where just having
selective disclosure alone can be a good utility without necessarily
needing unlinkability. where you could have a large list of recognized
issuers for example and…
00:25:00

Dave Longley: you are looking to present a credential that has been issued
by one of those and you could just selectively disclose that single issuer
from the list and perhaps dramatically cut down on the size of it in your
presentation.

David C: The other way…

David C: which creates a lot of overhead potentially for the list issuer is
that instead of the list issuer issuing one list of everybody that it
recognizes. It could actually issue separate verifiable credentials to
every entity in that list, distribute them out to all those entities and
then those entities as Manuel said earlier on can present that verifiable
credential along with their own verifiable credentials to say look I'm a
recognized issuer of verifiable credentials and I have this other
recognized issuer credential from the big guy who says I am recognized.

David C: So in that way you've got it totally distributed that every
recognized recognized verifiable credentials only contains one subject

Patrick St-Louis: Yeah, I'm wondering if it would make sense instead of
having one credential with multiple credential subject to have a
presentation with multiple credential in it. Is that something because I
feel like in that case the credential would be individual but still bundled
together in one document. Is that make sense? Or menu. Okay.

Manu Sporny: it is possible with this data model. So that is another
deployment mechanism that is possible. here we might want to jump into
looking at the data model because we can point out kind of where all these
things are possible. But you correct I mean I'm not hearing anything that
is not supported by the current data model we have which is great because
one way to know whether or not we've actually got a useful data model is to
go through all these different variations and see if the data model as is
today supports those variations. that's

Patrick St-Louis: Very good. That's all from me personally. if there's not
any more questions, I'm happy to move forward. Dave.

Dave Longley: I did not know if I did have some comments on the specific
PR, but I didn't know if we were going to walk through it first and then I
would have Okay, I'll leave it to

Manu Sporny: Yeah. let me walk through it and…

Manu Sporny: the structure and then your comments as we go would be so the
entry point here and just I'm sharing the link in the chat channel to make
sure everyone can bring this up on screen. the kind of high top level entry
point is a verifiable recognition credential. so again we're not fully
settled on the name here. but it worked out fairly decently. it felt a
little awkward in places.

Manu Sporny: but overall the type names seem to be so you have a VC and the
top level object is a verifiable recognition credential. that thing is a
standard C data model 20 thing. it has ID type issuer valid from valid
until and credential subject. So it's a standard VC at the top level. and
each credential subject.

Manu Sporny: So one of the things we wanted to say about the issuer is that
it is a standard issuer as defined in the BC data model but there are some
other general properties that you can decorate the issuer with and I
haven't put in descriptions here but the general properties that you can
kind of decorate objects with are legal name image URL are they same as
some other identifier to description. and then, digest multibase is in
there. It doesn't apply to issuers, but it does apply to some other the
lists themselves.

Manu Sporny: Go ahead Dave.

Dave Longley: So, one other thing we might want to put in here is a type
like recognizing issuer or something along those lines. So that might be of
some value to have since we're talking about having a specific type of
issue with these other fields and it provides some additional information.

Phillip Long: What is that?

Manu Sporny: I think let's see it that's here in recognized entity.

Phillip Long: I want

Manu Sporny: I don't know if we've gotten to that yet.

Dave Longley: So that we haven't gotten there yet, but that's not
necessarily the same thing. that I'm talking about having an attribute on
the issuer entity itself as opposed to the reverse of that.
00:30:00

Manu Sporny: Okay. so on the issuer there would be a recognized I see…

Dave Longley: No, a type and I put in the chat here maybe recognizing
issuer. We can bike shed that. But you can type issuer fields and that
gives you useful type information but all I don't know that we have a type
in the V VCDM for just an issuer.

Manu Sporny: what you're saying. Got So, the issuer itself would be of type.

Manu Sporny: It would be a type of issuer, but it would also be a
recognizing issuer is what you're saying. That's true.

Dave Longley: It's implicit but this would be an explicit type. around

Manu Sporny: Yep. Yep. Yeah.

David C: So I wonder… if it suggests that that should actually go in 4.1
and be a generic property for The type I'm talking about Dave. Yeah.

David C:

Manu Sporny: Let's see.

Dave Longley: Yeah, I would expect a type could be on any entity that we
talk about.

Dave Longley: And I don't know if we need to repeat that here. I guess
we're repeating some VCDM has type built in.

David C: Yeah. …

Phillip Long: It's Get

Dave Longley: But I guess that might be worth talking about as a general
property.

Manu Sporny: One thing,…

Manu Sporny: one thing I don't like about this general property section is
it's kind of hard to reason through. I tried to do it because in the
JSONLDD context that is probably how we're going to do this. but you look
at things like digest multibase and you're like why in the world is that
like a general property? You have to really kind of understand …

David C:

David C: Remove it then. If you can't argue for it, remove it. All the
other ones are quite

Manu Sporny: no, but we have to allow it. No, it definitely is allowed, let
me put two alternatives here. So, we can have a general property section
and say all of these properties can be put on any object. The other
approach is that we can be very specific about what properties can exist
and we'll just do the magic of the JSON LD context behind the scenes but in
the spec it'll just very clearly lay out like you can have these properties

Manu Sporny:

Dave Longley: the argument for that property in particular is specifically
avoiding the HTTP range 14 discussion that has plagued people forever …

Dave Longley: which is what is the difference between the expression of
digital information about a particular entity and the entity themselves.
since you can only ever in a digital document be talking about the digital
information about an entity And so the digest multibase is related to the
URL property here. a person doesn't necessarily themselves as an entity
depending on how you conceptualize a person have a URL. Similarly they
don't have a digest multibase but those mechanically refer to digital
information that's being expressed about a person. which is all of this
information that's on the screen. So, we really needed to go down the
rabbit hole of explaining…

David C: And I don't think it's difficult manu to put the description in
there is it for each of these personally I prefer general properties. Taste.

Dave Longley: why those things are There's an argument for it.

Dave Longley: It's just highly technical.

Manu Sporny: No it's not.

Manu Sporny: I guess the question is what would people prefer? Do you want
a general property section or do you want me to repeat this in each object?
Okay.

Phillip Long: fire. Yeah,…

Phillip Long: I would agree with that as well. Yeah.

Dave Longley: Yeah. If…

Dave Longley: if those can really appear on any of the things any entity we
talk about then let's just do it once. If we find that it cannot…

Dave Longley: if we find that it can only appear there are exceptions we
can talk about that in the spec as

Manu Sporny: And…

Manu Sporny: that's fine. I mean I don't have a strong opinion one way or
the other I guess question for the group is what was it? let's see there
are things like the other question for the group is do we want to restrict
it in the JSON LD context …

David C: Where?

Manu Sporny: where we a verifiable recognition credential is really going
to be fairly constrained in the type of information it has.

Manu Sporny: It's going to have stuff that's basically in our data model
and we're not really expecting it to be, greatly extended. If people want
to extend it, they can do that and they can provide their own context and
do the extension like that. so in the JSONLDD context do we want to
restrict these fields to digest multibase doesn't make sense on list
operator or recognized entity or a recognized action for example
00:35:00

Patrick St-Louis: Doesn't just a BCDM 2.0 context in itself already have
name,…

Patrick St-Louis: description, and digest multibase on every field.

Manu Sporny: Yeah, I think you're right.

Manu Sporny: Yeah.

Patrick St-Louis: ID for the body is kind of a separate thing. But I think
for these three Yeah.

Manu Sporny: So, we wouldn't even have to Yeah. You're right. Yeah. And I
think what we would be doing here is we would be adding legal name to be
able to be put on image and URL to be able to put on everything as well as
name as and…

David C: Okay.

Patrick St-Louis: same as maybe Yeah.

Manu Sporny: description. Yeah,…

Manu Sporny: I mean so some of these are already in the VCDM2 context.

Dave Longley: So yeah,…

Dave Longley: I wanted to jump in here. if we have a type on here, it gives
us more power to decide. So if there is a type for these entities in our
data model, wherever that type is present on a given object, you could
include these properties. So we have that option. I think we can sort that
out over time whether we want to make these global properties that you can
use to augment anything or if we want to have it be type based or some
combination. I don't think we have to make that decision on the PR today.

Manu Sporny: Okay, that is very helpful. Okay, thank you everyone for that
feedback. That gives us a very clear direction. So, we're going to keep the
general properties section. We'll add some descriptions here. Dave will add
the type and then we'll make another pass iteration. and we'll take a look
at it during the next call. That was very helpful for general properties.
Okay, so going back to the verifiable recognition credential we just talked
about the general properties on the issuer and then we've got standard from
valid until then the credential subject is meant to be a set of recognized
entities. so a recognized entity let me just show an example of what one of
these looks like.

Manu Sporny: So this is an example of a recognized entity. this is the
university example. so there's some kind of learning commission. There's a
board that decides who the accredited universities and colleges That's the
issue. I probably need to expand this a bit more. but the credential
subjects are recognized entities. And so this is a university and this is a
community college. and for each one of these recognized entities. It's got
a type recognized entity. It's got a name which is kind of a casual name
that you call that thing. And then it has their legal name. So the name is
example tech but the legal name is example polytechnic university. You have
an image like a logo for the university. You've got a URL.

Manu Sporny: So you go to the URL to learn more about the university
description and who this recognized entity is recognized by. So they're
recognized by the learning commission. keep in mind that this is your
organization KYO use case that Dmitri brought up and so this is all he
wanted to list. It's not recognized actions or anything like that. It's
just the learning commission knows about this university and this is the
information associated with that university. let me stop there. Go ahead,
Patrick.

Patrick St-Louis: So two question the first one. So this is a pattern I've
seen on some of the UNP credential as well. So you have the issuer and then
here recognized So in the UNPS have sometime they have the issuer and then
the credential subject they have a issued by which is the same ID as the
issuer and I see the kind of similar thing happening here is this really
required isn't this implied Hey,…

Phillip Long: f***** good.

Patrick St-Louis: this right.

Manu Sporny: I can answer real quick.

Dave Longley: Yeah, go ahead.

Manu Sporny: The issuer may not always be the recognizing entity. There may
be some kind of complex relationship there that needs to be expressed. So
we expect in most cases the issue and the recognized buy will be the same.
But that's not true for every use case.

Patrick St-Louis: And then re really quick my second point.

Patrick St-Louis: So one of the unanswered question I believe at the moment
with most trust registry is the sort of catch 22 of the issuer of the
registry which registry are they part of and how do you trust this issuer
and where does this end? Is this a issue that this will tackle or you're
going to just stop as this list and say yeah you just need to know the
issuer of this list or…
00:40:00

Patrick St-Louis: is there going to be a sort of recursive who's the issuer
of the issuer and so on.

David C: Yeah, the data model certainly caters for the recursion. So that
this learning commission could indeed be the subject in another credential
that's issued by the national government for example and because there may
be more than just the learning commission…

David C: who is an issuer.

Patrick St-Louis: Yeah. Yeah.

Patrick St-Louis: But then you get to that level up like So you mentioned
the government, right? So that's a special case.

David C: Yeah. …

Patrick St-Louis: It's like a pretty strong authority. But if we try to
move away from government and be very agnostic, where does this end? Right?
It never ends.

David C: no, it ends with you.

Patrick St-Louis: Gets through. Yes.

David C: In other words, everybody is their own root of trust and
configured into their system has to be their root of trust. So if I trust
Learning Commission, I don't need anyone else.

Phillip Long: Oops.

David C: But if I only trust my government, then I'd expect my government
to say that the learning commission was a subject of a credential issued by
my government.

Patrick St-Louis: Okay.

Dave Longley: So, I'm on the queue for something else. but yes to what
David just said. You've always got a Even if your root of trust is to trust
some awesome new magic graph of trust in the future, that would still be a
root of trust to trust that thing. So, it's got to end somewhere where
you've got a thumbs up and then you can grow from there. I'm just on the
queue to make a note that I want to talk more about recognized by when we
get to the next section.

Manu Sporny: Okay, sounds good. I think that's it for recognize entry
entity. I want to make sure that I capture everything. keep general
properties section as is.

Manu Sporny: This Okay, there we go.

David C: add definitions and…

David C: and add type.

Manu Sporny: Yeah, and that's up here. okay.

David C: Sorry. Yes.

Manu Sporny: All right. that's good. let me All right. All right.

Manu Sporny: So this is effectively what a recognized entity looks like in
the KYC use case. And then in the other kind of decentralized what are they
recognized to do. we keep everything else the same and we just add this
field recognized to and a recognized action. we don't need to go into depth
there, but I just wanted to point out we will eventually go into depth
later on, but I wanted to point out that the data model is additive, which
is I think what we wanted and it worked out really well. So that was nice
to go ahead Dave.

Dave Longley: So this is where I don't need to dig into the details of
recognize action. But when analyzing any one of these data models, I like
to think about the case where I've set up my own trust system. I'm
consuming these credentials. I've decided, as they come into the system, I
check to make sure they're all wellformed. they meet my trust rules and so
on. And then I might merge that information to do something with it. So at
the end of this I might have a list of a bunch of recognized entities that
were recognized by a variety of different parties to do a variety of
different actions. And if I go down and I've merged all this in a big graph
of information and I go to look to see whether an entity is recognized to
do a particular action, I might still want to know recognized by by which
recognizing entity to do that action. And so that field will not be there
when you merge all this.

Dave Longley: it will be there when you merge all the information, but it's
just going to be a huge list of everybody that recognized that particular
entity, but not what And so I was expecting recognized by to be part of the
recognized action because then it keeps that information together. So if I
have a list of actions, I know who recognizes those particular actions.
Right now in the model, I can't do that. And I understand why recognized by
was up there for the directory use case, but I'm not and I hear the
argument the issuer might be different from who did the recognition. but
we're going to want to sort that out. It feels like we want that
information inside of the recognized action. And then the question is
whether it needs to be somewhere else or if there's a better way to handle
the question Patrick raised.
00:45:00

Manu Sporny: Yeah, that's a good point. so the options are duplicate it or
move it into here. But if we move it into here, then make it an either or…

Dave Longley: There might be some other kind of recognized action that
covers the directory case as well…

Manu Sporny: thing. …

Dave Longley: but I don't know…

Manu Sporny: I didn't follow that last statement. Okay.

Dave Longley: what that action would be to be convoluted right now the
recognized action is to appear on a registry if he did that then it would
just fit into the recognized action section. But there might be a more
natural way to express that. But Patrick's on the queue.

Patrick St-Louis: Is it reasonable to just be one or the other like you
just mentioned? you can either have the recognize by as a string or you do
a recognize to object and…

Dave Longley: Yeah, the answer to that is no.

Patrick St-Louis: you have recognized by in there.

Dave Longley: I can answer that quickly. The answer to that is no is
because when I merge this, I will have one or the other depend from all
these different sources. So I want to have my big graph of information…

Dave Longley: where I can go to any given recognized entity based on their
ID and find out in the merge of everything who has what the actions are and
by whom and

David C: Yeah, Dave,…

David C: I understand what you're saying there. You're assuming that a
single entity can perform multiple actions, multiple different actions, but
that each of those actions are actually recognized by different superior
authorities.

Dave Longley: And in fact when we say different actions they might all be
issuance actions but for different credentials is probably the most common
case. So it A recognizes these three credentials from this university and…

Dave Longley: recognizer B recognizes these other four. There may or may
not be overlap but if I trust both of those recognizers I would accept all
six let's say with the overlap but I don't want to get that confused. Yep.

David C: Mhm. Got you.

David C: Yeah. Yeah. Got you.

Manu Sporny: All good points. how should I change the clearly recognized by
needs to be possible to put in recognized action.

Manu Sporny: Okay.

Dave Longley: Yeah, that minimally put it in the recognized action and…

Dave Longley: then we can see if we can dduplicate in some way. That's what
I would say.

Manu Sporny: right. let's see. So that would be add.

Dave Longley: It might be the recognizer property at that point. because
maybe the action is recognized by it it doesn't matter it's a bike shedding
exercise it'll either be recognized by under the action or recognizer of
the action.

Manu Sporny: Okay.

David C: Yeah, that feels wrong to me.

David C: I mean to me at the same level of the model you've recognized to
do X that they should be at the same level in my opinion.

Dave Longley: Yeah, but the question is about a property of the action
itself.

David C: …

Manu Sporny: ears and other

David C: maybe the act maybe then it's a question of define the action
better rather than just say issue the action is issue VC with this schema
yeah.

Dave Longley: We do have that. That's what output validation is,…

David C: But I don't like the output validation.

Dave Longley: I believe. monu

David C: I wanted to raise that but Mano said we're going to go into depth
for that later. I mean you could have action as an object, where you've got
the issue and the schema are all parts of the action. I mean, I don't like
the output validation anyway. s the way it is, it's not intuitive to me.

Manu Sporny: Going back. Yeah. And we'll get to that discussion. Maybe not
today because we're running out of time, but So, for recognize by I'll do
something there and…

David C: I don't agree with that one.

Manu Sporny: we can review it. okay …

David C: Then if you make a note, I don't agree with that one. Yeah. I no
actually manu we did discuss this a week or…

Manu Sporny: then I won't make the change. wait for consensus on the one
point I wanted to highlight here is that this recognized by is important in
the previous use case because this recognizing entity is the one that is
saying that these properties are what they are.
00:50:00

Manu Sporny: There's some kind of weird modeling thing.

David C: two ago and we said that it wasn't necessary there but you wanted
to add it there because there's some data modeling property which I can't
remember what it was but that if the credential subject gets separated off
it's got the issuer there right that was…

Manu Sporny: Yeah, that's right.

David C:

David C: why it's put in But that…

Manu Sporny: And it could be different from the issuer, The issuer could
have the authority to list a multiple different recognizing authorities.

David C: but because I brought this up at the time then you would need that
authority to say I'm giving the authority to this issuer to issue on my
behalf…

Manu Sporny: Yeah, that's right.

David C: because otherwise anybody could issue on behalf of anyone.

Manu Sporny: Yep. yeah. I absolutely agree.

Manu Sporny: Yeah, there's something out of band that allows that kind of
association to happen.

David C: or…

Manu Sporny: Either by policy, right?

David C: another or…

Dave Longley: It's in the schema about Yeah,…

David C: another recognized credential. Yeah. So I mean

Dave Longley: that field would be in the schema about another verifiable
recognition credential. It's either in your root of trust to be able to say
whatever you want or you have one of these credentials that has an issue a
action for a verifiable recognition credential that has the recognize by
field that either says star you can put whatever you want or…

Dave Longley: you could put a list in there. Hopefully people followed that.

Manu Sporny: Yep. Okay.

Manu Sporny: So, let's come back to this, right? Because we need to figure
out I mean certainly I guess we don't have consensus on what to do here. I
think we wanted to let people go earlyish 5 to the hour. So, I think we
might be done for today. are there any quick we're just going to have to
come back to this, right? …

Dave Longley: Yeah, I think one action to consider is…

Manu Sporny: discuss the recognized by thing. I can add I'm not falling.

Dave Longley: if there's a recognition action for just getting into a
directory is…

David C: Yeah, I agree with that, Dave.

Dave Longley: if there's a way to do that then it could all be in one
place. So you're recognized to do something always and…

Manu Sporny: You mean there's a …

Dave Longley: then underneath that if there's a way to model the directory
use case then everything would be unified.

Manu Sporny: got it.

Dave Longley: So you're recognized to this is a little awkward…

Phillip Long: Yeah. Yeah.

Dave Longley: but if it was just you're recognized to appear in a directory
then you would consume this credential and put them in a directory and
based on who the recognizer was under the action. So the you'd be
recognized to do an action.

Manu Sporny: Yeah. Yeah.

Dave Longley: You'd have a recognizer of the action. One of the actions
would appear in a directory. Yeah.

Manu Sporny: So the action is to exist. okay.

Phillip Long: Right. Right. So, this is a good example of a use cases would
help us here.

Manu Sporny: All right.

Phillip Long: Just really short ones to clarify these things because really
help me.

David C: Yeah, so when we talked to Dimmitri, it became obvious that there
was a lot of implicit knowledge in his model and…

Phillip Long: Yep. Thank you.

David C: what we're wanting to do is really explicitly put it there.

Manu Sporny: All right.

Manu Sporny: I think that'll do it for today. back over to you, Patrick, to
wrap up the call.

Patrick St-Louis: Yeah. …

Patrick St-Louis: thank you very much. And yeah, I think it would be
interesting to include Dimmitri in this conversation. At least if this
property was important for their use case, I feel like it would be
worthwhile to have this discussion with him. thank you all for attending.
we will adjoin the meeting. it's been great.

David C: Okay, thank you very much.

Patrick St-Louis: Very interesting stuff happening here. so yeah, I will
close the meeting. I hope you all have a good rest of your week and we'll
maybe see each other in the upcoming meetings. Thank you.
Meeting ended after 00:54:59 👋

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