[MINUTES] CCG Incubation 2026-02-24

Meeting Summary: Verifiable Issuers and Verifiers Focused Group (2026-02-24)

*Date:* 2026-02-24 *Time:* 10:59 GMT-5 *Attendees:* Benjamin Young, Dave
Longley, Elaine Wooton, Jori Lehtinen, Manu Sporny, Parth Bhatt
Topics Covered:

   - *Pull Request 42: EU ETS Trust Lists and Recognized In Property*
   - *Pull Request 44: Separating Use Cases from the Spec and Renaming the
   Specification*
   - *Addressing Outstanding Issues*

Key Points:

*Pull Request 42: EU ETS Trust Lists and Recognized In Property*

   - The PR aims to support the EU ETS trust list infrastructure by
   referencing it via a "recognized in" property.
   - Discussion centered on the precise meaning and utility of the
   "recognized in" property, particularly in the context of the EU's
   hierarchical trust list structure.
   - Dave Longley suggested the need for two properties: one to indicate
   where an entity is recognized ("recognized in") and another to indicate
   entities that the current entity recognizes.
   - Manu Sporny clarified that the EU ETS model uses a "list of lists"
   structure, and the PR intends to reference this structure rather than
   duplicate it.
   - Jori Lehtinen provided input, suggesting that "recognized in" is
   sufficient to express the intent of fetching verification material from a
   recognized list, as seen in the EU's trust chain.
   - The group ultimately agreed to proceed with the "recognized in"
   property, with plans to update the PR's text and examples to reflect the
   discussion.

*Pull Request 44: Separating Use Cases from the Spec and Renaming the
Specification*

   - This PR separates existing use cases and requirements into a new
   usecases.html file, cleaning up the main spec document.
   - A significant portion of the discussion focused on renaming the
   specification.
   - Manu Sporny proposed "Recognized Actions," emphasizing the atomic
   concept of recognizing an entity for a specific action.
   - Dave Longley suggested "Verifiable Recognition" as a broader title,
   encompassing the verifiability of recognition statements beyond just
   actions.
   - The group agreed to defer the final naming decision by creating an
   issue for community input and a subsequent poll, with Manu Sporny to
   initiate this process.

*Addressing Outstanding Issues*

   - The group discussed several outstanding issues that are likely to be
   closed once the discussed PRs are merged.
   - These issues were generally pre-dating the recent refactoring efforts
   and are expected to be resolved by the proposed changes.
   - Consensus was reached on PR 42, which will allow for the closure of
   related outstanding issues.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2026-02-24.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2026-02-24.mp4
*osb-nmyo-muh (2026-02-24 10:59 GMT-5) - Transcript* *Attendees*

Benjamin Young, Dave Longley, Elaine Wooton, Jori Lehtinen, Manu Sporny,
Parth Bhatt
*Transcript*

Benjamin Young: All we'll start in a few minutes after the hour once folks
get here. Jory, I think this is your first time. welcome. you're on mute.

Jori Lehtinen: Yeah. this is my first time. Yes. I have been reading the
transcripts earlier from the meetings, but I haven't calls yet.

Benjamin Young: Great.

Benjamin Young: Yeah, once we have some more folks here, I'll have you
introduce yourself if that's all right.

Jori Lehtinen: Yeah, that's all right. I haven't really prepared for that,
but it's all right.

Benjamin Young: It doesn't need to be more than hi, but It's great to have
you here.

Jori Lehtinen: Okay. Yeah, thank you.

Benjamin Young: Yeah, why don't we take some time to do some meet and greet
while we let other folks wander in. it's pretty consistent that we start
about 5 minutes after the hour. But Jory, why don't you say hi and we'll
pick up with issues after that.

Jori Lehtinen: Hi. So, my name is Yuri. I'm an independent developer from
Finland and I'm interested in decentralized technologies and implementing a
lot of the standards being produced in the B3C credentials community.

Benjamin Young: Awesome. We're glad you're here and…

Jori Lehtinen: So that's what I'm here for. I'm here to learn a lot. Thank
you.

Benjamin Young: I think we will probably push through a couple PRs and then
look at issues if that works for everyone. not sure if David Chadwick's
going to make it again or not, but suppose we'll find out. So, thanks for
coming everybody. This is the Verifiable issuers and verifiers focused
group. That is a hard phrase to say with the amperand but we are working
first on pull requests. There's a link in chat for that and I will share my
screen and we'll go from there.
00:05:00

Benjamin Young: Feel free to cue up as you want to talk and we'll just take
these in order of appearance. U Manu, as ever, these are both your
contributions. So, I'm expecting you can tell us all about them.

Manu Sporny: Happy to.

Benjamin Young: Go for it.

Manu Sporny: Let's take PR 42 as the first item. so this has to do with a
long-standing request from David Chadwick around the European Union's Etsy
trust services lists. we have talked about this at depth over the many
months trying to figure out a way to make sure that we support European
Union Etsy trust lists in a way that makes sure that we don't redo all of
the work that they're doing over in the EU and at Etsy.

Manu Sporny: Where we seem to have landed is to make it so that a
recognition credential can reference the SD Etsy trust list infrastructure.

Manu Sporny: So it's basically a pointer. if we go to example three
Benjamin, if you keep scrolling down, there's two and then keep going. What
happened?

Benjamin Young: I'm going to switch to the preview so surrounded by seas of
red.

Manu Sporny: Sorry. yeah, let's keep going.

Benjamin Young: Here we go.

Manu Sporny: Yeah, there we go. Example three. This is So, if we look at
the recognized in ID and type towards the middle bottom, that is what this
PR is about. So, we're basically saying there's a recognized entity and
typically in the European Union, it's like a European state. so we used the
state of utopia here in the example. you describe some things about the
state legal name, image, the URL for the authority. and then we say that
this organization is recognized in this particular list.

Manu Sporny: so yeah that I think about it Dave suggested a change to
change this from recognized list to recognized in. I don't think it works
because this is not the list that this entity is recognized in. This is the
list that the entity is publishing that recognizes other entities under its
purview. So the state of utopia recognizes these other organizations in
there. But fundamentally whatever we name we do need to pick a name for
this thing.

Manu Sporny: recognition list recognized in whatever. what we have replaced
this with is instead of creating 40 new properties and things like that,
we're just pointing to the list and saying, "Hey, look, it's a European
Etsy trust list and if you know how to read that thing, then this will help
you. If you don't, it won't be helpful to you." So, let me stop there. I
see Dave's on the queue.

Dave Longley: my first question is isn't the list that this party is
recognized in not that this party that okay that's the inverse of…

Manu Sporny: No. Yes.

Dave Longley: what I thought this was to begin with this issuer of this VC
is the recognized issuer which is the utopian commission. So they are
expressing the entities that they recognize and one of the entities that
they recognize in this example maybe it's not a good example I don't know
is the state of utopia and…

Dave Longley: Would say this is the list in which they are recognized.

Manu Sporny: Yes, you would think that,…

Manu Sporny: but that is not how the European Etsy trust list stuff works.
They have this massive list of the lists XML file then in that and that is
issued by the European Commission and then in that massive lists they
delegate to other known recognized entities and specify where those
entities sublists are. so it' be the European Commission and then they
would list every single European state Poland would be in there and then
here is where you go and look at the Poland's stateisssued list. So
Poland's not recognized in that list.
00:10:00

Manu Sporny: Poland is so the European Commission in the credential we're
looking at right now would assert the Polish list and basically delegate
everything under Poland to that list.

Dave Longley: It seems like we need two properties then. because I do think
we want to be able to express that the state of utopia is recognized in
some external list. If that's not how Etsy works, I could easily imagine
some other system working that way. So, it sounds like we need two new
properties. One to say this is where this thing this entity is recognized
and this other property you're talking about that doesn't quite seem right.
That seems like it would be at the top level of this list and you would
have Poland's list somewhere like that that there's something a little
inverted with that. Or maybe we're supposed to put the list of lists in the
recognized in property. Shot.

Manu Sporny: And the of So if we wanted to do a direct mapping here the
lists of the lists would be you could put it in the list of the lists and
let me go back. I'm trying not to duplicate what the European Union's
already publishing. I'm trying to just reference it, and the ructure of the
list stuff is just weird. it is hierarchical. It comes from the certificate
authority days. But it's like the European Commission issues a credential
that recognizes the European Commission as being authoritative for That's
the top level LOTL XML file that they publish.

Manu Sporny: In that they claim the European Commission says we are allowed
to issue this list of the list thing and in that list they say here are all
the known other lists of the lists in Europe and they include things that
are not only states but the banking system and it's just like a grabag of
here are all the other lists that we know about right it's not necessarily
just member states but it is this hierarchical thing the European
Commission is at the top. everyone else, all the member states and the
banks and everything else is kind of flat underneath the European
Commission. and so like that is the structure.

Manu Sporny: I would expect that the only usage of this thing for the Etsy
trust list thing would be the European Commission issuing just the top
level thing that points to the lists of the list thing and that's it right
I don't know if they would even issue the second level thing which is the
list of the list thing which lists all the other Poland and…

Manu Sporny: everything else. so what you're saying is they would, put all
the European member states in this top level credential. I don't think
they're going to do that because they already have the LOTL thing to do
that.

Dave Longley: Yeah,…

Dave Longley: that was a lot of lists to try and parse it. When I'm using
this credential, the example that's on the page here, what I'm looking for
is I see that the utopian commission recognizes the state of utopia and I'm
looking to see if anyone else does. That's what this recognized in
accomplishes.

Dave Longley: And if all that says is these are all the other parties that
the state of utopia recognizes, I might not be interested in that at all.
That seems like it's out of place. that seems like you're telling me the
other things that the state of utopia recognizes, but that's not really
what about. I care about what does the utopian commission recognize? And so
does the Utopian Commission recognize anything that the state of Utopia
also recognizes?

Manu Sporny: Yeah, I get what you're saying. Let's Benjamin, let's go to
the other examples because I want to make sure we've got all of this in our
head before we start making decisions. I'm trying to remember where this Go
to the recognized entity section section 42 and see that paragraph at the
very bottom are recognized in with a type property of blah blah blah. so we
have these three use cases. We have the Etsy trust list stuff. We have X509
certificate authorities and then we have hierarchical verifiable
recognition credentials which is the spec that we're creating right here.
So we want to be able to support all these things.
00:15:00

Manu Sporny: this used to say this entity publishes a recognized list of
type Etsy trust list or of type X59 certificate authority list or something
else. I get what you're saying, Dave. It's just like not I don't because of
the way the Etsy trust list stuff is set up I don't know if you can say
anything useful with this credential that we have other than the European
Commission saying that the European Commission is authoritative for all the
lists.

Manu Sporny: it's just completely self-issued thing that the European Union
issues but it is an anchor like that is the top level anchor of trust in
the EU.

Manu Sporny: Go ahead Benjamin.

Benjamin Young: No, I was just going to bike shed on recognized end,…

Benjamin Young: but we can keep going

Dave Longley: Yeah, I think we need two different properties. And it might
be that the Etsy stuff doesn't quite map to recognized in, but I would
expect there would be other structures that would be useful here. So, I'm
consuming this credential. I see that this entity is also recognized via
this other resource and that's useful to me. I think what we're saying here
is the recognized for the Etsy use case is the recognized entity has more
information about other entities it would recognize and it's just sort of a
tag along metadata attribute.

Dave Longley: so we should come up with a name for that that's different
from this which is this recognized entity also also recognizes or we need
to come up with another name and put the Etsy list there but we should keep
recognized in for systems that want to link to other recognition
authorities. authorities being a terrible word there. Other recognizers

Manu Sporny: Yeah, I don't know if we have a use case for recognized in I
don't think we'd use the use case that we're trying to do with the Etsy
trust list is that there is another format out there that exists that an
ecosystem supports and we're just trying to say you should boot if you want
to bootstrap into that ecosystem here's your pointer to bootstrap into the
ecosystem.

Manu Sporny: Yeah,…

Dave Longley: that doesn't make sense to me yet around…

Dave Longley: unless we reference the list of lists and if that's okay.

Manu Sporny: we would reference a list of lists. That's what I'm saying. We
would recognize a list of lists.

Dave Longley: Let's just do that because that's the list in which they're
recognized, right? Okay.

Manu Sporny: Yeah, recognizing themselves. This is all self-referential.

Dave Longley: That's not really relevant to this data model in this spec.

Manu Sporny: Okay, let's go on to the X509 case…

Dave Longley: If that's the Done.

Manu Sporny: because I think hopefully that gives us some clarity here
because the X509 certificate authority list, these are things that browsers
use. they are usually internal to the browser, and there's, an RFC. I
forget which RFC it is, but there's an RFC for that. and what you want to
do potentially in this thing is say hey, if you care about certificate
authorities, there's this huge published X509 certificate authority list
that you can go and read. Yeah.

Dave Longley: But that match is recognized that because you're going to say
there's a list of X509 authorities out there. If you go look in there, you
will find this entity with, maybe a certificate somewhere with a subject
alternative name or…

Dave Longley: whatever it is that match is recognized in. What do you mean
duplicating it?

Manu Sporny: But you would end up duplicating that list,…

Manu Sporny: you're going to end up in this credential, you have a huge
long list of you you have every certificate authority. you would end up
basically duplicating that the recognized in list cuz you would basically
say is Komodo in business anymore? Aren't they the ones that got shut down?
Mozilla is a recognized certificate authority. and sorry, Let's encrypt is
a recognized certificate authority by just about every browser.
00:20:00

Manu Sporny: they do exist in some kind of certificate authority list but
if I'm publishing this credential which is a verifiable recognition
credential what I want to do is I just want to point to the list and say
hey there's a big list out there go and read it what I don't want to do is
duplicate the entirety of the contents of that list every ce express every
certificate authority in the verifiable recognition credential and say hey,
they exist in this list out there because you're just duplicating what's
already in the list out there.

Dave Longley: I think you're talking Yeah,…

Manu Sporny: Does that make sense?

Dave Longley: it does. I think you're talking about a specific case the use
case for this credential is there's an issue out there who wants to list
specific entities that they recognize that there are many different
instances of that use case. in reality. One of those many is I want to
duplicate every recognized entity on Let's Encrypt. I don't know what that
use case is or why anyone would do that use case, but you could do that.
And I don't think we should use that use case to drive the action here. I
don't know why anyone would do that.

Dave Longley: It does make sense to me that you might say there are these
10 or 20 entities that I recognize. Here's a list. if for these 10 or 20,
some of them might have recognized in properties that link to other systems
that of use. I don't know what this other use case you're talking about
where somebody might want to just model all of let's rypt. more power to
them, but I don't think that's a significant use case.

Manu Sporny: That's an antitern. I'm saying we don't want to support that
use case. I agree with you. I don't think we want to support that.

Dave Longley: I don't think we have to go out of our way to stop someone
from doing that. That's an open world model. they can do that…

Manu Sporny: Let's talk about your second I'm hoping your second property
is the one we actually want.

Dave Longley: if they want to.

Manu Sporny: I can't see much value in recognized in other than it's
basically a C also, right?

Dave Longley: You're publishing a list where there people are going to find
your list and they're going to say, "Okay, I accept that you recognize
these entities, but you haven't said what you recognize them for or that's
a recognized to property. and I don't think Let's Encrypt case there's
probably a better case, like MDOC issuers, for example, where you're going
to list, I recognize these five states and these five states are also
recognized to issue MDOC credentials and you need to have the link to

Dave Longley: that because one of the credentials that might be issued is a
MDOC mobile driver's license. Does that make sense?

Manu Sporny: kind of I can't put my finger on where we're miscommunicating.
I'm going to think for a

Manu Sporny: You said we needed two properties. What's the other property?

Dave Longley: The other use case is going in the other direction.

Dave Longley: It's like you've created a list of entities you recognize,
but you also want to say those entities recognize other entities. And it's
also a C also, but it's sort of like if I were to make a list of five
entities that I recognize and on any one of them or maybe on all of them, I
might reference that they themselves have their own recognition list.
00:25:00

Manu Sporny: Yeah, I think that's the …

Dave Longley: And here it is.

Manu Sporny: that's what this PR was trying to achieve because that is the
Etsy trust model use case. So, what's the name of that other property?

Dave Longley: I don't think we want to call it a list because that imposes
too much data structure. But I mean we could start with recognizes and bike
shed from there because you're saying this is a recognized entity that if
we said recognize that I would expect that to be another list of recognized
entities. so we do need to bike shed it, but it is a different property.

Manu Sporny: Okay, let's go with recognizes. I think that property
addresses the Etsy use case and the X509 use case and probably the
verifiable recognition credential use case.

Dave Longley: We could also be vague and…

Dave Longley: use recognition resource. I don't think we should be vague,
but it would cover both use cases at once. Just saying there's this other
recognition re resource over there, and you need to go understand that to
figure out what it is.

Manu Sporny: Yeah. Yep.

Manu Sporny: And that's why I suggested also or related resource, but those
are too generic. anyone else want to weigh in on what we could call this
thing? So, what does this property do? it lets an entity say that there is
a list there's this thing out there that effect has equivalence to what
this specification does but it uses a totally different data format.

Manu Sporny: it uses, Etsy trust list format or it uses X509 certificate
author authority format or it reuses the format that we defined in this
specification. it's like it is pretty I mean it is I mean maybe a type C
also is maybe you get the context back by the type…

Dave Longley: It loses all of its context when you're just thinking about
this. Yeah. Yeah.

Benjamin Young: No, I know that that was a joke.

Benjamin Young: But it is essentially recognized entity X says you should
also look over here. Go ahead, Mark.

Manu Sporny: because the type does tell you this is another Etsy trust
service list in Your client is either going to understand…

Manu Sporny: how to process Etsy trust service lists or not.

Dave Longley: Related resource accomplishes the same goal.

Dave Longley: And you could still use a type there, but you could also use
a media type.

Manu Sporny: So, it feels like we have the concept.

Manu Sporny: We just need to name the thing.

Benjamin Young: Yeah, functionally I agree with Longley that it is a
recognized resource,…

Benjamin Young: but I think the wording is going to maybe confuse people.
Maybe not.

Manu Sporny: Having list in there is bad because it's really a set of
information. but I think it's better than ce. Hey, while that's percolating
in the back of our minds, let's go back to recognized in. Do we really need
recognized in? I get that it has value. I don't know if we as an
organization find value in it and would implement it or suggest any of our
customers implement it.

Manu Sporny: it's nice but it's not necessary. It won't drive some kind of
business process. I don't think we let's look at the global certificate
authority list. you have the certificate authorities in there. let's
encrypt is one of them. We specify that we know who Let's Encrypt is. And
then we're like, " by the way, they're also in the big certificate
authority list." does that have value? Probably not because someone's
either trusting the list that they're reading right now or they're going to
use the other one. The only value is to understand that there's some kind
of cross relationship between these two lists.
00:30:00

Manu Sporny: But I don't think that's going to drive any kind of business
logic…

Manu Sporny: unless you also have your software configured to understand
that global certificate authority list. And then if you have that
configured why aren't you just using that thing versus this thing. So I'm
saying it has not enough value for us to put it in a PR right now.

Dave Longley: It might be true that you would always have a separate list
from that other system.

Dave Longley: So in the MD doc use case that I was mentioning before, I
could imagine that you have some list that you like to use in your software
where you decide to accept certain credentials that we'll just say driver's
license credentials from five different issuers.

Dave Longley: you don't know for any given process you're going to receive
a driver's license credential from one of those issuers but it might arrive
in verifiable credential format or it might arrive as an MMDL and if you
have a single recognition list for this process then when it arrives you
can check to see what it is and you can see if it's a verifiable credential
you're

Dave Longley: run after you verify and check everything there's no
additional checks that might be needed and if it's an MDOC you might want
to look and see and follow the chain get this additional information from
an MDOC X509 list but in saying that I think when you do the MDO
verification process you're going to do that check as well but when you go
to do that check you need to specy

Dave Longley: speify which MDOC certificates you're willing to trust if I
remember how that works. so those have to be provided from somewhere. So
either those are going to come from this recognition list and you follow
your notes to get that information or you have it in a separate list. I
think there is some utility in being able to link to it all from one place.
is that a hard requirement to implement something? No. But it might be a
value. I don't know if that made sense. It got twisty there.

Manu Sporny: Jory, do you mind vocalizing what you typed out? ma mainly
because the chat isn't saved in the record and it would be good to hear
your thoughts on

Jori Lehtinen: So, what I'm thinking in my message is that let's say I'm a
Finnish citizen and I'm going to another country and I'm showing a
verifiable credential. they read and they are kind of expecting there to be
the link the rec recognized in field or could be expecting there to be a
link to the Etsy list and then fetch that list and already know how to
parse it specifically because that's

Jori Lehtinen: that's the context of their own implementation. So I think
those four properties there provide enough information for the implement to
do their own kind of processing there.

Manu Sporny: So based on that, what would you suggest? Do you have an
opinion on the one property versus two properties thing or what would you
suggest we call each property

Jori Lehtinen: I think the recognized in is good enough because as I'm
understanding this data model here is that there is subject for this VC
that is recogn recognized in some outside certificate authorities list and
they're recognized to do something and they need to fetch the list where
they are recognized in and find the verification material to verify that
they're recognized to issue the presented BC verified credential there.

Jori Lehtinen: So I think these and recognized in are good enough to
express that intent.
00:35:00

Manu Sporny: All So, we've got you and Dave suggesting that there's value
in it. I can see it. So, I'm thinking of the so, California issues both
verifiable credentials and MDL MD docs. the MDOC in the United States their
trust list is something called the AMvical it's the verify or it's the
issuers list the states that are allowed to issue a driver's license in the
US.

Manu Sporny: So we could utilize this credential to basically say so AMVA
who is the authority for publishing these lists could issue a verifiable
recognition credential. They could list every single US state that can
issue a driver's license in it. And they could also say that this entity is
recognized in the MDOC VCAL formatted list as well. So it's effectively an
equivalency statement. I don't know if we'd bootstrap a system using that
mechanism. I guess you could because it's like Amber's publishing both
lists and so it doesn't matter what your entry point is.

Manu Sporny: If your entry point is this verifiable recognition credential,
you've got two trust anchors lists that you can process and your software
can choose to process one or the other. so that's the use case for
recognized in it's effectively you can find out more if you go over here.
so I'll update the PR to just, fine-tune. With that in mind, what do we
want to name the other thing? Because the other thing is the Etsy lists of
the lists use case. It's where the European Commission is issuing a
credential saying that we recognize the European Commission.

Manu Sporny: So the European Commission issues a verifiable recognition
credential. In that they say there's only one entity that we recognize and
that's the European Commission. That's They're going to self-sign that and
everyone's going to trust that because it's the European Commission. And
then they're going to put their lists of the lists thing there and tell
everybody else to bootstrap from that list. And that other list is the one
that lists all the states,…

Benjamin Young: Go ahead.

Manu Sporny: all the banks, what they're allowed to issue and verify and
that sort of thing. So what do we call that property?

Jori Lehtinen: So I think recognized in works for that as well because the
way I'm understanding that e use cases there's a chain of certificates You
have to start from the one that the EU commiss or issues to themselves. You
read that, verify that and from that I guess you find the next list where
you find the next thing and you verify all these otherwise what is the
whole point of having all these three things in the EU if you don't always
go through the whole trust chain.

Jori Lehtinen: So when you are verifying something in the EU, you would
always expect the recognized in to have the very top level certificate
which tells you what you need to see next and go down the certificate chain.

Dave Longley: So what you just described, Jory, is how I thought it worked
originally. I'm not sure now if it works that way. If it does work that
way, then I think we're good. If it doesn't work that way, then I think we
need a different property that provides a different direction to go in the
hierarchy. So if recognized in allows us to have that top level list that
would also include the entity we're talking about and then you can follow
that all the way down, I think that works fine. If it doesn't quite work
that way, then I think we need something like recognized entity resource,
which is just a more verbose name than recognition list, but it doesn't
force us to have a list structure.
00:40:00

Dave Longley: And it clearly says that it's a resource about recognized
entities. And so if a recognized entity has another recognized entity
resource, that is a resource that describes the entities it recognizes. And
you're going directionally down in the hierarchy versus up and then back
down. hopefully that made sense.

Manu Sporny: Yes, it made sense. I think Jory's right. I think all we need
is recognized in because that is how it works. It's not the second thing as
far as I understand it. And again, I'm not an expert on the EU Etsy trust
list stuff, but the top level file does have the European Commission as the
top level, thing. so all that to say, I think we're good. We can use
recognized in I will have to modify some of the text about what it actually
means. but I think we can let's run through all the use cases now to make
sure that actually works.

Manu Sporny: it works for the Etsy trust list use case for X509 certificate
authority list you are basically going to say someone's publishing that
list right it's the browser vendors right so let's take Mozilla publishes
an X5 or9 certificate authority list that is the list that is used in
Firefox when you go to any website the publisher of that list is Mozilla

Manu Sporny: they will publish something they will self-sign it as Mozilla
they will say we recognize Mozilla to publish the top level X509
certificate authority list Mozilla is recognized in this other X509
certificate authority list so I think it works for that use case as well
and then for okay so it works for the first two use cases does it work for
the verifiable recognition credential how do we make it hierarchical?

Dave Longley: You can always recognize yourself in your own verifiable
recognition credential if you wanted to.

Manu Sporny: Yeah, I guess you would Yeah,…

Dave Longley: I mean you just described that in the Mozilla use case.

Manu Sporny: I'm looking at the LA there's another issue out there that I
was hoping to address with this PR that basically says, hey, you guys
should support chained lists and hierarchical lists. We're really worried
about the size of one of these things getting out of hand. what happens
when you have 10,000 issuers, which is what you have in the United States
when it comes to who can issue an education certificate, So if you have you
so people are like we don't want this one credential to have 10,000 entries
in it. I think the way you break it up into a hierarchy is you at the top
level we recognize again all these states we know about all these states
that can issue verifiable credentials or these education councils in each
state.

Manu Sporny: and we're going to list 50 of them at least in the United
States we're going to list 50 of them and say that each one of these is
recognized in this other list and then I guess the presumption is those
other lists also recognize sub ones like things within the state that are
recognized all the colleges and universities in the state it's kind of like
I think the issue is what's the word I'm looking for? It is implied that
there's more information at these other lists. that.

Dave Longley: I think we should just go forward with recognized den and
make some examples and when we hit the reality there. We'll find out if it
works well for those use cases or not because it sounds like it might work
and we might not need anything else.

Manu Sporny: Yeah, I think the worst case is it's just implied and not
explicit that these other lists contain more data that you should probably
pull into your list of recognized entities thing. All right. so changes to
this PR. I will update the language around recognized in and what it means.
I think that's the only thing that we need to do. I will update the
examples to try and include the things we talked about today and then we
can review it again next week. I might just pull it in because I think
we're fine. Everything else would be an editorial change. Okay.
00:45:00

Manu Sporny: I think that's it for this one. unless others have any kind of
changes they'd want to see in this PR.

Benjamin Young: Nice and short. do you need me to write any of that down or
do you in the followup?

Manu Sporny: It'll be in the minutes. I can pull it from the transcription.

Benjamin Young: Okay.

Manu Sporny: Next one. okay. That's great. that addresses, one of the last
standing issues. next poll request. Hopefully fairly straightforward. I
missed the call last week, but I think you guys talked about all just
separating the use cases from the spec. it contains work that we did very
long time ago. around use cases and things like that. I have just cut all
of that. I didn't delete anything. I cut all of the content and put it in a
document called cases.html which contains the use cases and requirements.
So, you'll see everything being deleted from the index.html.

Manu Sporny: want to come back to the title here in a second, but this is
all deleted and it's just keep scrolling down. there's the use cases.html,
which is just a new respec file that moves everything over to that
document. So, that results not tiny, it's a nice clean spec. The main spec
is just pretty straightforward at this point. we will have to update the
use cases document there. we'll have to change the images and that sort of
thing, but I think it cleaned it up pretty nicely. And that's all this PR
is largely editorial. I do want to point out that I am trying to also
rename the specification in this PR. I should not have done that.

Manu Sporny: should have gone in another PR, but I would love feedback from
everyone on so, for the longest time, this started out as trust lists and
we really didn't want to use the word trust because trust is a very loaded
term. It's overused. People, imply different things when they say we then
went to authorized or authorities and people didn't like that language
because it was too heavy-handed. we want this system to be peer and
decentralized. So, we don't want to use the words trust or authority or
make it seem like any particular entity has more power over another entity.
issuers shouldn't have a huge amount of power over holders over verifiers.

Manu Sporny: we didn't want the whole trust list based mechanism some in
the community feel is like an anti-attern so we went to verifiable issuers
and verifiers like an individual can publish that list of your friends who
you trust or that you recognize to do things. So we changed the language.
We went from verifiable issuers and verifiers which we still don't like to
things like recognized actions like I recognize Jory to post to a mailing
list and I recognize that this is Jory's email address. So I'm recognizing
I'm not giving Jory authority. I'm not saying what he can or can't do. I'm
just saying I recognize him. I know him and he's posted the mailing list
and I know that right so that's what the current spec does.

Manu Sporny: and I think in the most atomic thing that we have to do that
is this recognized action I recognize a particular entity to perform a
particular action that is what this spec is about and an individual can do
that an organization can do that a nation state can do that everyone can do
that no one's above the other in a technical sense so the suggestion is to
rename the specification to recognized actions. but would love to hear
feedback from others on
00:50:00

Dave Longley: If you refresh the page there, Benjamin, I put in a different
suggestion. So, recognize actions I think is okay, but I think it does
hyperfocus on just one thing the spec is doing. And we might find you we
already are saying more than just actions and we have these directory use
cases and linkage to other systems and all of that could be some stretched
to say we're always talking about actions but we could also just be a
little more generic in the title. And what we're looking for here is
verifiable recognition.

Dave Longley: We're looking to see that some entity has said that they
recognize some party for this that to do these actions whatever it is and
that is verifiable information because they put it in a credential and we
have a common data model for how to express that.

Benjamin Young: Any thoughts on that?

Dave Longley: So it seems like something that covers that more broadly is
verifiable recognition as a title.

Benjamin Young: I do wonder if we should pull it out as a separate issue
though, so we can get this merged and keep discussing. But maybe we'll
solve it now. Go ahead, L.

Manu Sporny: Yeah, plus one.

Manu Sporny: I shouldn't have put it into this PR. I'll pull it out into a
separate issue and do a separate PR just for it. because everything else
just moving content around should be editorial and non-controversial. I
think I'm fine with the title verifiable recognition. I am wondering but
I'm concerned that that's only because I know what the specification is
about already. I am cons I'm wondering if people new to the specification
are going to be confused by it people that really don't like the work are
going to use it as an attack against the group like a dog whistle against
the spec RDF data set canonicalization and the way RDF is used right as

Manu Sporny: as a dog hi do we think people are going to read the title
verifiable recognition and understand what the spec is actually about.

Benjamin Young: I would say that recognized actions was clearer to me than
verifiable recognition. Go ahead.

Dave Longley: I felt that recognized actions sounds like we're blessing a
set of actions in a specification that people will be recognized to do. And
I found that more confusing than we're just trying to make it possible for
anyone's recognition to become verifiable. So I kind of felt the opposite
way. as to dog whistles and so on. I think that could be done with any spec
name. I don't find that argument compelling. so that I could see this going
either way. we've got a data set of two, three, four people here. I don't
know which way it goes. that's my feedback.

Manu Sporny: All So, the way that we normally settle this stuff is we just
send a poll out to the community group and get as many people, get as much
data as we can on it. Usually, when we run polls like that, we want to have
a good set of selections. So, usually then what we do is we're like, "Hey,
we're trying to name the spec. This is what the spec does today." We feel
pretty confident in what the spec is going to do and is we feel confident
in that this is what the spec is about. Here's a paragraph describing it.
give us a bunch of what would you name the spec is the first pass. We
collect stuff from the community and then we run a poll to get people to
pick the real name of the spec. So I can kick that process off. so I'll
pull this out.

Manu Sporny: I'll create an issue. We'll get to a nice concise definition
of what the spec's about. Send it out to the mailing list, get ideas, and
then we'll run a rank choice poll to depict the final name. Does that work
for everyone? All right, seeing lots of thumbs ups. I will do that. and
that I think takes us through this last PR.
00:55:00

Benjamin Young: Okay, I'm not sure we have time to uncort the model on an
issue. So, I think you addressed 45 and maybe there's another small one
here. yeah, there is. You can probably kill this one off quickly, which
maybe it looks like you've already done.

Manu Sporny: I just noted that I didn't remove the imagery yet,…

Benjamin Young: Okay,…

Manu Sporny: but will do it in a future PR.

Benjamin Young: Any thoughts on trying to tackle one of these in four
minutes?

Manu Sporny: I did a pass Benjamin through everything and…

Manu Sporny: noted all the PRs that address things. Everything that's got a
comment by it is probably going to be closed off once both of these PRs are
merged.

Benjamin Young: Okay. Sure.

Benjamin Young: Because a lot of these were issued ahead of the great
refactoring.

Manu Sporny: Yep.

Benjamin Young: That's fabulous. do we need any sort of group consent on
that? because the PR was already approved. So, I think these can probably
just be closed.

Benjamin Young: Okay.

Manu Sporny: They're waiting on PR42,…

Manu Sporny: the Etsy trust list one to be and I think we have consensus
right now today.

Benjamin Young: Right. Okay.

Manu Sporny: And so I'll apply that to the PR. I'rge Once the PR is merged,
I'll close all the issues.

Benjamin Young: Yeah, I was just confirming that was clear steps. That
sounds great. Okay, I think we'll call it here as many of us have another
call right after this. So, thanks everybody. Thanks for coming, Jory. It's
great to have your input and hope to see you again.

Elaine Wooton: I

Jori Lehtinen: there. I think I'll come back. Bye.

Benjamin Young: Take care all. Bye.
Meeting ended after 00:57:23 👋

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