[MINUTES] CCG VCs for Recognition 2026-03-31

This meeting focused on logistical changes and technical details for the
VCs for Recognition specification. The attendees agreed to move the meeting
time to 4 PM Eastern starting next week to accommodate Steve Capell, and
discussed the formal transition of the call to an official Verifiable
Credential Working Group meeting. Significant discussion also occurred
around the specification's name, with a consensus to add "entity" to "VCs
for recognition." Several technical sections of the specification were
reviewed, including security considerations related to external resource
tampering and the handling of different list formats.

*Topics Covered:*

   - *Meeting Time Change:* The meeting time will be moved to 4 PM Eastern
   starting next week to accommodate attendees in later time zones.
   - *Working Group Formalization:* The call will transition into an
   official Verifiable Credential Working Group meeting starting next week,
   requiring membership for attendance.
   - *Specification Naming:* The group reached a consensus to change the
   specification name to "VCs for Entity Recognition" as an improvement over
   the current title.
   - *IPR Commitments:* There is a need to follow up with Isaac and David
   Chadwick to obtain their IPR commitments, which are critical for the
   specification's progress.
   - *Security Considerations (Output Validation):* The section on
   tampering with external resources was discussed, with the decision to
   remove it due to redundancy with the VC Data Model specification, though a
   test case for output validation digest checking will be considered.
   - *Security Considerations (Verifying Recognition Chains):* The section
   on verifying recognition chains and handling different list formats was
   reviewed, and the group agreed to keep the discussion broad without
   prescribing specific implementation details.

*Action Items:*

   - Benjamin Young will update the meeting schedule to reflect the new
   time of 4 PM Eastern starting next week and will also communicate the shift
   to an official working group call.
   - Benjamin Young will follow up individually with Isaac and David
   Chadwick to obtain their IPR commitments.
   - Manu Sporny will raise an issue in VC Data Integrity to suggest a
   normative statement about checking digest multibase for resources.
   - The group will consider adding a test case to the test suite for
   output validation that includes digest multibase checking.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcs-for-recognition-2026-03-31.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcs-for-recognition-2026-03-31.mp4
*VCs for Recognition - 2026/03/31 10:59 EDT - Transcript* *Attendees*

Benjamin Young, Dave Longley, Dmitri Zagidulin, Elaine Wooton, Kayode
Ezike, Manu Sporny, Parth Bhatt, steve capell, Ted Thibodeau Jr, Tom Jones
*Transcript*

Manu Sporny: Steve, good to see I'm sorry it's so late for you.

steve capell: Yes.

steve capell: Hello, my name it is pretty late here, but that's why my
video is off and I'm lying flat in bed.

Manu Sporny: No problem. What is it? 1:00 a.m. there. 2 a.m.

steve capell: Yeah. at 1:00 a.m.

Manu Sporny: If you're going to be a regular part of these calls, we need
to move them so that they're not as at such an obscene time for we should
talk about that today.

steve capell: I mean, if there's Europeans and Americans on the call there,
then it's very difficult. But if it's only Americans Yeah.

Manu Sporny: We don't have too many Europeans on the call. Isaac would be
the only one and he's here every now and then. Not very often.

steve capell: Okay, thank you.

Manu Sporny: So I think we can shift it to a better time for

Benjamin Young: and I'm happy to start us there if you want. I think almost
at five after.

Benjamin Young: So Steve, there's certainly a better time, but is there a
time on your calendar that feels like one you could hit?

steve capell: yeah.

steve capell: What time is it for you guys now?

Benjamin Young: For East Coasters, it's 11:00 a.m. and we've got at least
somebody on the West Coast. Elaine and Tom, I'm not sure what time zones
y'all are in.

steve capell: So the west coast even earlier wouldn't it in the morning. So
in any case usually the time that works well for American colleagues and me
is a bit later. So that I don't mind waking up at 6:00 in the morning or
something like this. So 5 hours from now would be what?
00:05:00

steve capell: 400 p.m. for you, and a bit earlier for West Coast.

Benjamin Young: Yeah, I think 400 p.m.

Benjamin Young: seems more reasonable. Moni, it's 3 3 p.m.

Manu Sporny: Yes. the VCOM call is no. Yeah.

steve capell: No.

Manu Sporny: No, we could do it.

Benjamin Young: Eastern. Yeah.

Manu Sporny: Yeah. So, let's say 4 p.m. same F 4 PM Eastern. Does that work
for everyone?

Benjamin Young: Anyone have objections? Seeing lots of plus ones.

Manu Sporny: And that's 10 10 p.m. which isn't too bad. Okay.

steve capell:

steve capell: What the f*** is Yeah, that we do occasionally in the UN
stuff, we have these three time zone calls sometimes and it early morning
for me is pretty much the only slot that works for all three.

steve capell: Yeah, they call Thank you everyone.

Benjamin Young: …

Benjamin Young: not today, but starting next week, we will move the call to
400 PM Eastern and I'll make that happen after this call. Thank you
everybody.

steve capell: Appreciate it.

Benjamin Young: Yeah, just glad you're here, All with that I think we will
look at the issues in PRs. I will share my screen. It looks like we've got
a local couple PRs happening. Go ahead, Mon.

Manu Sporny: Could we cover some logistics stuff before we do that?

steve capell: First thing is the verif.

Manu Sporny: So the first thing is next week I think we are going to be
sorry tomorrow is the verifiable credential. sorry Steve I'm going to have
to mute you just because I'm getting some feedback from you. There we go. I
think you can unmute yourself. the verifiable credential working group
meetings are going to start up regularly tomorrow. and I think that means
that this call is going to shift into an official working group call
starting next week. unless anybody kind of objects to that, I think we're
going to propose that as the shift.

Manu Sporny: So we'll shift the time and then this will become an official
working group meeting and you have to be in the working group to attend
those meetings so on so forth. So, if you're not an invited expert or
you're not a working group member, you will have to be one. the end, right?
I think you can ask for invited expert status. I mean, multiple people in
here ask for invited expert status. or you can probably ask to be kind of
an attendee and listen in as long as you're not contributing any kind of
IPR or whatever to the meeting. So I think the proposal is next week we
shift into official working group calls.

Manu Sporny: we will move the time and then from here on out this will be
an official kind of working group meeting.

Manu Sporny: Let me stop there because that's a proposal. I'm not saying we
do that. go ahead Benjamin.

Benjamin Young: Yeah, not sure…

Benjamin Young: which part of that is al. but this is also meaning we hand
off the meeting scheduling and stuff to the chairs I would think of the
working group. Is that correct?

Manu Sporny: we have to suggest something to them they'll take our guidance
on they don't want to be disruptive to our group. We've been meeting on a
fairly regular basis. So we would suggest the meeting time. we have already
said we'll keep the exact same link. so I don't think there's much to do
there. I mean we say we are suggesting that we are going to officially
start the working group work item meetings for the VC recognition spec
starting next week. it's going to be 400 p.m. Eastern.

Manu Sporny: We'll meet weekly,…
00:10:00

Manu Sporny: same link as we're using today, I think would be the proposal.
And then we'll see what they say on Wednesday.

Benjamin Young: That is in tomorrow,…

Benjamin Young: right? Okay,…

Manu Sporny: Correct. Okay.

Benjamin Young: sounds good. I can write all that up.

Manu Sporny: And the other logistics thing, let me pause to see if there's
anyone objecting to that as what we kind of proposed to the PCWG.

Manu Sporny: The other thing is that we have to hand the spec over
officially to the verifiable credential working group. Benjamin, we looked
at where the IPR commitments are yet?

Benjamin Young: Not…

Benjamin Young: since this week began. No, but I can do that now.

Manu Sporny: Because Isaac and David Chadwick need to, submit their IPR
commitments and then ideally everyone that is listed as an author, even
though we've moved a lot of that content to the use cases, we'd want them
to submit. we can move the spec over in parallel. It's always a bit more
risky because somebody can always come back and say I never agreed to my,
IPR commitment. and in that case we need to make sure that's why Isaac and
David are critical. we have to get approval from them. but everyone else
since they just contributed to use cases are not as critical. so Benjamin I
think we're going to want to follow up individually with each one of those
people and…

Manu Sporny: say you really need to make the FSA commitment. yeah.

Benjamin Young: Yeah, we need to see…

Benjamin Young: where we're blocked because they're still not in the
credentials list as collecting IPR agreements. This was something that
broke with the chairs last week. So, I need to see if they were able to
solve that.

Manu Sporny: And just to be clear, we're not blocked. It's just not showing
up there. We are getting commitments. So, I'm looking at our FSA
commitments. This is not good. It's just as Lazar and Dmitri have signed.
So We need to get Isaac to move forward and we need to get David Chadwick
to sign. So Benjamin, I don't know if you can kind of take an action to
start chasing these people down. we're looking for the entire editors and
authors list at least to make the commitments.

Benjamin Young: Any other logistics you want to cover?

Manu Sporny: All right, seeing a thumbs up.

Manu Sporny: I don't know if we should spend too much time on this, but
some heartburn over the spec name that we picked. don't want to turn it
into an hourong bike shedding thing. we moved away from verifiable issuers
and verifiers. because I think we generally agreed that it wasn't a good
name. VCs for recognition is what we settled on. which and Rognition is the
spec name. we kind of did that in kind of a lastm minute push because we
did need to rename it. I've been making spec changes and updates.

Manu Sporny: one of the concerns I have is VCs are about recognizing
things. it's a very generic name and aren't all VCs for recognition. and
that's kind of the thing that I keep coming back to when I, read the spec
title and keep working on the spec. So, I don't know if other people have
the same kind of concerns. if I'm the only one here, I'm fine with kind of
moving on. there is a subtitle that I added which is what is it? of course
now I can't see the subtitle.

Manu Sporny: I mean it's recognizing entities and the actions that they
perform. So it makes it a little clearer. it's right by the title, but I'm
concerned that if we say, VCs for recognition, not many people are going to
know what we're talking about. thoughts? Anyone else have the same issue or
00:15:00

Dave Longley: I thought something similarly while we were doing the bike***
thing, but I let it go and I didn't have a better alternative.

Benjamin Young: Go ahead.

Dave Longley: So, if we want to tweak it in some way,… I think that would
be fine. but we'd have to have a good alternative for

Dave Longley:

Ted Thibodeau Jr: Yeah, I'm in the same boat.

Ted Thibodeau Jr: I keep coming back to this and thinking about it each
time I'm doing another PR and it isn't the right title for sure, but it's
better than what we had. I am hopeful that somebody has an idea and just
hasn't voiced it and that they will voice it if we encourage them enough.
So all you people who are quiet

Manu Sporny: I think there's some good suggestions in the chat.

steve capell: suggestion in the chat.

Manu Sporny: Go ahead,

steve capell: Yeah, I was just going to say I share the minor concern and
don't have a great suggestion at the moment, but that you've cracked open
the door, I will have a think about it and see if I can offer some thoughts.

Manu Sporny: Thank yeah, and it would be really good to have your input
especially since because of where you're kind of coming from the UNC work
and UNTP work. I think there are a number of better suggestions in the chat
channel. VCs for entity recognition, recognized entities, recognizing
entities with recognition, I don't know about recognition of VCs. Sorry,
Elaine.

Ted Thibodeau Jr: challenge here is you said VCs are all about recognition
of something. every VC that's issued is some issuer saying that some entity
is recognized in X way or as being something.

Ted Thibodeau Jr: Yeah, I don't have any firm thoughts. Go ahead, Benjamin.

Benjamin Young: Yeah, just entity seems to be the trending addition.
doesn't mean it has to be that but as distinct from just the VCs itself
which are ostensibly about entities of some kind but these are more like
people in organizations create entities not ds and…

Benjamin Young: public and private key pairs and things like that. does
injecting entity in there somewhere kind of calm concerns at all.

Ted Thibodeau Jr: It's the challenge here,…

Ted Thibodeau Jr: right, is that this is me issuing a VC that says that I
will recognize VCs of these kinds when they come from those issuers. I will
recognize these attributes when they are claimed by those issuers. And it's
right back to the old signing parties in my mind which is both good and bad.

Ted Thibodeau Jr: They do let anybody have the authority to do but the base
thing that they're doing is granting more authority to the people they're
talking about u not people entities but yeah go ahead

Manu Sporny: I'm looking at the list. I'm just trying, seeing what
everyone's kind of chatting about. It does feel like entities is the key
thing. I think I like Benjamin's initial suggestion. meaning does this make
it better? So right now we have VCs for reco I think having saying VCs for
entity recognition would be better than Cs for recognition.

Manu Sporny: So does anyone think that doesn't make it better?

Dmitri Zagidulin: I agree.

Dmitri Zagidulin: I agree.

Manu Sporny: We're not looking for perfect. We're just better than what we
have right now. So we have if we change it to Cs for entity recognition,
that makes me feel much better about the title of the spec.
00:20:00

Dave Longley: I think maybe after sleeping on that we might think that it
didn't really address the problem because I could imagine thinking that's
what I did with other VCs already. someone put some claims in a VC and I
can now recognize the credential subject in there has these claims and I'm
recognizing all that once again I don't know that it's really getting at
the core problem.

Manu Sporny: So, a minus one like an objection. Don't do it or…

Dave Longley: No, I wouldn't object to it. I think we'd go through a name.
I think we changed to that name and I don't know that it would really get
too far on the core

Manu Sporny:

Manu Sporny: Yeah. Yeah. I'm looking if I were talking about this at a
conference, I would feel much better saying that on stage versus just VCs
for recognition.

Benjamin Young: Yeah.

Manu Sporny: Yeah,…

Dmitri Zagidulin: I agree.

Dmitri Zagidulin: It's strictly better even if it doesn't solve the core
problem.

Manu Sporny: and then coming back to the corporate and I'm not saying we
don't change it again. It's just kind of like maybe we iterate our way
towards something better. So then we'll have VCs for entity recognition.

steve capell: We're in good It's not too bad.

Manu Sporny: What's better than that?

steve capell: I wouldn't mind going and having a look at the use cases
you've written to see first of all is our most common use case in there and
if it is then the name ought to have some relationship to that I mean a
typical scenario that we'd come across is a long linked chain of verifiable
credentials that take you to a trust anchor. So for example, a certifying
authority issues a product conformity certificate, but then you need an
accreditation authority to say that certifying authority is an accredited
certifier. And then you need the IAC to say that national accredititation
authority is a national accredititation authority. Right?

steve capell: So there's three separate VCs issued at different times and
basically the subject of one is the issue of the other one and you get a
chain up to a pattern repeats I don't know 50 different ways in most use
cases that come across right so we're verifying a chain of trust added
central comment

Manu Sporny: Yep. Yeah. I mean at least that is central to a set of use
cases definitely. we have a peer aspect of it as well. And then we also
have something where you're not actually saying what actions they perform.
just like we know that this set of entities exist out there. we recognize
them but not necessarily what they do.

steve capell: denominator in our use case is that all of these entities are
go through some sort of governance and registration process. They're in a
directory somewhere, right? The list of IAC members or the list of
accredited cabs. So, it's really a registry operator declaring that XY Z is
a member of that register.

Manu Sporny: Yes, that is certainly one class of use cases we wanted to
address.

steve capell: address. Well understood.

Manu Sporny: However, we did not want to overoptimize for that use case
even though it's probably the most common use case, we wanted to make sure
that…

steve capell: Absolutely. Yeah. Yeah.

Manu Sporny: if you had a peer a small community of a hundred people that
they would be able to self-publish directories of people that they
recognize or…

steve capell: people that Yeah,…

Manu Sporny:

Manu Sporny: things of that nature. So we wanted to make sure that we
didn't add trust into the name, we didn't add registry into the name, we
didn't add a creditor into the name because there that might give a bit too
much power to issuers and authorities and not enough power to people I
think in a peer capacity. Mhm.

steve capell: that's good. there is a patent like that as well, what's
interesting is who recognizes who in a community.

Manu Sporny: Yep. Exactly.

steve capell: Yeah. Or even Yeah.

Manu Sporny: And we wanted to make sure that the name of the spec reflected
that.

steve capell: Yeah. Industry associations is another one, right? It's
useful to know if you're selling Monica honey that you are a member of the
Monika Honey Association because that Anyway,…
00:25:00

Manu Sporny: Mhm. Association is something that we haven't really explored…

steve capell: I've said enough.

Manu Sporny: which is very interesting I think.

steve capell: It's the same concept that I've gone through some process to
join a club effectively.

steve capell: Could be the club of registered Australian businesses run by
the tax office or it could be the club of Monica honey producers run by the
Monica Honey Association. They're all there, thousands and thousands of
these. And having evidence, given that there's more Monica honey sold
around the world, about two or three times more than actual produced
membership of these kind of clubs or registers or associations or whatever
it is that have some integrity or proof or governance or membership rules
around them.

steve capell: is useful, right? the Monica honey farmer can use it to help
with anticipating and…

steve capell: things like that. supportable. Yeah.

Manu Sporny: Yeah, I'm seeing a lot of support for verifiable associations.

Manu Sporny: Except Dimmitri and Ted are minus one. it's not an association
as a type of organization. It's the other sense of the word which is I'm
associated with this entity or I am saying that I've have some association
with this entity. I am in association is the way I was reading it. Yeah.
Yeah. We are all associated with Dimmitri because he's on this call.

Manu Sporny: It's not the I don't no

Dmitri Zagidulin: association is incredibly vague though. the whole point
with these credentials is that they're KYC was performed.

Benjamin Young: I don't think it's exclusively customer.

Benjamin Young: Steve,…

Dmitri Zagidulin:

Dmitri Zagidulin: Sure.

Benjamin Young: is your hand up for something?

Dmitri Zagidulin: not customer I'm using jargon but some kind of
verification was performed.

Dmitri Zagidulin: Association is way too vague. I'm strongest on it.

Benjamin Young: Can you elaborate on the strong minus one…

Benjamin Young: because lowercase I think it's not less committal than a
relationship which is going to have all kinds of other vagueness.

Benjamin Young: But I think it's also the point at…

Dmitri Zagidulin: Association does not imply knowledge of something. I'm
associated with a lot of entities I don't know anything about.

Benjamin Young: which that's expressed to other people that it matters,
right? CVS doesn't care about me and for the most part I don't care about
CVS but we have an association that is my loyalty card and…

Dmitri Zagidulin: You do see I disagree.

Benjamin Young: I care then go ahead

Dmitri Zagidulin: You do care about CVS because you care that it's CVS and
not some other drugstore. You care that it's an accredited drugstore and
not something else. You do care about it.

Benjamin Young: money.

Manu Sporny: Okay, just to time box this because we can definitely take up
the rest of the hour on this, but we've got PRs to get to. I just wanted
to, see if other people were a little concerned about the name we picked
and then, what the appetite was for, trying to pick a different name. It
gets locked in. The only time this gets locked in is when we do the first
public working draft. We have to pick a short name. And when we pick a
short name, it is really difficult, unfortunately, through because of W3C
process to change the short name. So, we still have a couple more weeks.

Manu Sporny: to pick something that we're comfortable with. but once we
pick that name and the short name, changing it after that point becomes a
monthlong endeavor so we may want to spend a little bit of time,…

Manu Sporny: 15 minutes each call from now on out until we come up with
something that we are find better than otherwise the current name's going
to stick and that probably will not be a good thing. okay. That's so go
ahead Ted, but let's get the PRs at some

Ted Thibodeau Jr: Yeah. …

Ted Thibodeau Jr: I just want to quickly push back on Dimmitri's the point
of these VCs is not that their subjects believe in them. It is that their
issuers believe in them and that they are hoping that the verifiers who
process them will also then believe in them.

Dmitri Zagidulin: Yes. the key word there is believe…

Ted Thibodeau Jr: This has been a

Dmitri Zagidulin: though not associated with or connected with.
00:30:00

Ted Thibodeau Jr: Something like reliability is a piece.

Ted Thibodeau Jr: It's not trust per se because that has all kinds of other
connotations. but if six people say that they will rely on your assertion
that somebody else is a good credit risk that is valuable to those six
people. as long as…

Dmitri Zagidulin: Wait, that's not…

Ted Thibodeau Jr: what you're saying about the Sorry.

Dmitri Zagidulin: what this spec is about, though. this spec is not about
credit lists, though. this spec is just about entity recognition.

Ted Thibodeau Jr: I disagree.

Dmitri Zagidulin: That'd be bigger problems.

Ted Thibodeau Jr: The spec is about anybody who wants to issue a VC that
says that they are attesting that that claims made by some other entity are
valid to them. And that might be something that others would care to know
because it would impact their belief in those same kinds of statements.
it's not about credit relationships per se, but it is a use that it could
be put to.

Ted Thibodeau Jr: I'll leave it at that. We can talk about it later.

Benjamin Young: Yeah. …

Benjamin Young: I kind of want to get a sense from folks. I know we don't
want to keep bike shedding this,…

Benjamin Young: but we did just sort of open Pandora's box unexpectedly
because naming does that. so Steve, go ahead and share your thoughts, but we

steve capell: Yeah. I just wanted to ask are there any use cases you have
that don't involve at least two credentials…

steve capell: because the beginning of this was about I've got a VP for
that matter let's say my high school certificate and the verifier wants to
know yes but is a real high school which means some governing authority
that registers high schools has issued a separate VC and so we're where the
verification is across two VCs. Now you can come up with two or more VCs.
You can come up with a 100 different combinations use cases around that
concept. But what I'm really trying to verify is not a single VC…

Benjamin Young: Go ahead, D.

steve capell: but a relationship between VCs. Do you have any use cases
that don't have that pattern? Yeah, but…

Dave Longley: The one use case that might not have that pattern is the
simple directory use case where maybe there's not an original VC that
causes you to go look in a directory, but maybe it's a web origin or
something else or just a decentralized identifier and you want to go book
in your directory of known entities, which is what Dimmitri is talking
about. So that might not involve two VCs.

steve capell: if

steve capell: It's let's say a business registration certificate right
there's a directory you're a member they give you a certificate here's your
business registry that is indistinguishable from just any VC right so yes
any VC can be either a self assess thing or something given to you by
somebody is your driver's license and we're the registar of driver's
licenses That applies to anything, But specifically the challenge we come
across is I want to consistently assess some relationship between claims
across more than one VC. I've got an invoice, but I want to know who really
issued this invoice. the company's register was a separate VC.

steve capell: It says the controller of that is also known as this company.
I don't have any use cases that aren't about more than one VC and verifying
some relationship between them. left.

Benjamin Young: Go ahead, Mon. Yeah,…

Manu Sporny: I just wanted a time box.

Benjamin Young: I'm happy to move on to issues. I think we are going to
have to come back, but Steve, did you want to have a closing remark there?

steve capell: No, it's just putting my hand down.

Benjamin Young: 1:00 am. All right. to meet you.

Dmitri Zagidulin: So I do want to say that Mana's proposed change is
strictly better than the current name and then we can continue discussing
it afterwards.
00:35:00

Benjamin Young: Add the word entity to what's there now and…

Dmitri Zagidulin: Yes. Yes.

Benjamin Young: then keep going. Yeah, I do think we had consensus that 15
minutes ago. man, is that okay with me?

Manu Sporny: I'm fine with that as long as no one's objecting.

Benjamin Young: I think that gets us to better. So, there we go. All
righty. With that, we will look at some PRs. Mono, these are both from you.
Do you have a order you'd like them looked at? I think these are the same
ones we looked at last time.

Benjamin Young: They are just okay.

Manu Sporny: Yeah, let's look at them in reverse order 62 and then we can
have a discussion about the remaining items in 61. So 62 just needs another
review by at least one other person. Ted made a bunch of suggested changes.
thank you very much Ted. the rest I just need another review.

Benjamin Young: Sounds straightforward enough. That's the link to 62 for
anyone who wants to review that. 61 and then issues monitor.

Manu Sporny: Yeah in 61 we have to keep going through. So I applied all the
changes that were suggested last week. so in the issue itself let me find
the link in chat here is the notes I took last week about changes to
sections and things like that. I have applied all of those changes to the
specification.

Manu Sporny: just as a reminder this pull request is to add a whole bunch
of security and privacy considerations into the specification as issue
markers to say these are things we have identified as being security and
privacy issues. we are going to write some text about it. It is not the
actual text we're going to write. So that's kind of what the PR is about.
We ended on section 43 last time. we should keep going through the
sections. I think we have two more sections to go through and unfortunately
everything's kind of been reumbered a bit. so we need to do section 44,45
and 46 today.

Manu Sporny: And really what we're looking for is for people to see if the
thing that is written is an appropriate security consideration and to
provide their thoughts on what else we would want to say for so we could
probably start with section 44. and this has to do with tampering with
external resources in one of these recognition credentials you can list I
know of this university and this university can issue a bachelor's degree
in something or another and the way that you put a strong constraint on
what they issue is there's a field called output validation and you can use
a JSON schema

Manu Sporny: to say their credential should look exactly like the only
thing they should be able to issue a bachelor's for is bachelors of arts
and sciences or something like that. and so you can constrain it in the
output schema but if you don't provide a cryptographic hash of that schema
there's a chance that it can be attacked and changed on the server right so
this is basically saying hey remember to put a digest multibase on it so
that even if an attacker changes the schema you can detect that the schema
was modified and therefore

Manu Sporny: stop the verification process. we already tell people this in
the main VC data model spec. and maybe we should delete this section
because it's just repeating what we've already said before. So, thoughts on
that?

Dave Longley: So yeah, that seems like it falls into the category of things
we kind of discussed last time where we're going to mention the same
considerations apply for the VC data model as these other things. I don't
know if it needs any specific call out. I'm trying to think of it as a
reader of the spec. Whenever you find any link that calls out to other
data, yeah, you should have it in your mind that if there's no message
digest associated with it, then when you go to get that data, it could have
changed from what was originally signed.
00:40:00

Dave Longley: and if there's no method of checking authenticity for what
you fetch over at that other place it could have changed in a way that is
unacceptable to whoever issued the original VC. I struggle with the are
people going to have that in their minds or do we need to call it out for
every place that it happens? and if we do need to call it out for every
place that it happens, is it sufficient to I don't know if the VC data
model does it that way where they say for any external links, these are the
security considerations if there's a place to link to or if we need to call
that out in this spec. But it seems like we would be repeating ourselves
throughout all specs that do this similar thing. And it would be nice to
not have to do that.

Dave Longley: But I also simply think about all the security considerations
in the VC data model when exploring the spec will probably not result in
people doing that.

Manu Sporny: We have this section content integrity protection in the VC
data model spec that talks about this. I agree with you Dave. I think
there's some content integrity protecting an image is slightly different
than content integrity protecting the schema that you use to figure out if
that issuer should have issued that credential in the first place or not.
those are very different classes of security Latter one being way more of
concern than probably the picture. that said we state it in the VC data
model.

Manu Sporny: I don't know if stating it again for every attribute is one
thing we might think of doing is if there's an algorithm on how to use
these things in that we can say you must fail if the digest doesn't match…

Benjamin Young: Thank you.

Manu Sporny: but I don't know if we're even planning on doing

Dave Longley: would we want in the leadin section that says all of the
considerations from VCDM apply should we make any additional statements
like pay particular attention to content integrity protection for any
external links that this spec defines or slots that the spec defines for
putting external links. Do we want to or feel the need to say things like
that or is the make sure you read all those good Enough.

Manu Sporny: I would like to hear from others. I don't think we need to say
anything. I feel like we're just repeating ourselves over and over again. I
think if implementers get this wrong, I don't know if there's a test we can
put in I think a test in a test suite would be far more effective than any
kind of warning security language.

Manu Sporny: It's a

Benjamin Young: Are we able to link between the two formally enough for
writing a test or…

Benjamin Young: because I'd rather not say we're going to depend on a test
without spec language that requires the test would be my concern. Demetri.
Yeah. Dream. Go ahead.

Dmitri Zagidulin: I was just going to ask why the model you're suggesting
we take out that language but then I noticed that the language was on the
VC data model not on recognized entity spec.

Dave Longley: I think we should have at least one test for output
validation that would cover the use case of you've got some VC make sure
that it matches some schema from that issuer and…
00:45:00

Benjamin Young: Honey. Jesus.

Dave Longley: we could easily put the digest multibase in there and I think
that would cover So, I do think that's a good suggestion.

Manu Sporny: Yeah, to answer your initial question, Benjamin, and Demetri's
followup, I don't think we have normative spec language that would let us
write a direct test for it. in Dimmitri, we are talking about just removing
just deleting this action. but if you scroll up to the top, Benjamin, the
security, if we just click on section four, security considerations, we do
say here readers are urged to familiarize themselves with general security
advice provided in the security consideration section of the VC spec. So,
we do point to it and we're like, please go read that thing because you
need to know about those things.

Manu Sporny: Yeah and…

Dmitri Zagidulin: All right,…

Dmitri Zagidulin: seems sufficient.

Manu Sporny: that's the only reason I'm saying telling people to check
content integrity we make a general statement in BC data model that applies
to all subspecs so I think that covers it plus one to what Dave said I do
think we can do a test that uses output

Manu Sporny: validation or what was it output valid I'm totally forgetting
yeah that uses output validation we can put a test in there to check the
digest multibbase value and…

Dave Longley: Output validation.

Manu Sporny: put a wrong value in there and you're supposed to fail that
test or you're supposed to basically say that validation failed because the
digest multibase is wrong and if impleers want to argue that they don't
want to implement that we can have that discussion If any implementers I
don't want to, implement a digest checking, I think we're fine there, It's
kind of a gray area, but I think we'll be fine. I don't think any imple's
going to argue against checking a digest.

Benjamin Young: yeah, I just wanted to clarify that I don't currently see
anything that is requiring it though in that and that the section
referenced in the VC data model is non-normative and certainly not tied to
specific term use. But go ahead.

Manu Sporny: Yeah, you're right. I'm saying we can add any test to the test
suite we want to, it doesn't have to be just about must statements. and
this would be one of those gregars where we're going to add it because we
think it's good for the ecosystem and there are no normative statements
here, I mean, we could add a normative statement that says if a digest
multibase is associated with a whatchamacallit, it must be checked. But I
think that repeats. I don't know. I have to go look at what digest
multibase says in the main spec. where's the integrity protection part?

Manu Sporny: No,…

Benjamin Young: I think it's all the way over in data integrity.

Manu Sporny: there's a section in BC data model. there's a one about
related resource. yeah, this isn't good. I think you're right, Benjamin.
It's probably the data integrity one that we care about.

Manu Sporny:

Benjamin Young: Yeah, it shows up in here,…

Benjamin Young: but if it's within a key a very specific term space and…

Benjamin Young: then this section for digest multibase goes to data
integrity.

Manu Sporny: Yeah, we don't have any normative statements that say you have
to check it.

Benjamin Young: Yeah. Right.

Manu Sporny: And we did that on purpose, I mean, you don't have to check
SRRI in a browser…

Dave Longley: conforming verifier implementations. There are two statements
there.

Manu Sporny: where

Dave Longley: It was on the screen,…

Benjamin Young: Where was he?

Dave Longley: now you go back to wherever that was and scroll down. with
the one that has the link, it says a conforming verifier implementation. it
says you must compute that first sentence is very long,…
00:50:00

Dave Longley: but at the end of it says must compute the digest of the
retrieved resource. And then the second sentence says if the digest
provided by the issuer does not match, you must produce an error.

Benjamin Young: Hey there.

Manu Sporny: Yeah, it's only for related resource.

Dave Longley: That's right.

Manu Sporny: So that's the problem.

Dave Longley: That's right.

Manu Sporny: So maybe what we should do here is no We would,…

Dave Longley: If we want this for output validation for schemas, we would
have a similar statement.

Manu Sporny: but then we're just kind of like, I mean, I think the problem
is we're just picking special things to have the must statement with them.
yeah.

Benjamin Young: Rather than a blanket.

Manu Sporny: And we don't want a blanket because if the image is wrong, do
you want to kick out a verification failure if you're not going to use the
image at all to display anything? Right? that's why we don't have a must on
this. think we need So Benjamin, I don't think we need a must statement to
put a test in the test suite. We can do it and then see if an implementer
is going to complain about it.

Dave Longley: So we tried that I remember this came up in the previous
working group that's why the text here says a verifier implementation that
makes use of a resource must do this. it would have been nice to say …

Dave Longley: if you make use of data in the data model that has a digest
then you must do this then it would be more general and not apply to just
related resource.

Benjamin Young: Good morning.

Manu Sporny: We can just upgrade data integrity to say that if you make use
of a resource that has a digest multibase associated with it and the digest
multibase does not match, you must throw an error. I think that works right
and it's general and works across every spec.

Benjamin Young: Yeah, that feels much more likely to rightly be tripped
over than a test that is somehow not pointed to by the specs clearly
because it will just fall out if they're not directly taken out by somebody
who doesn't want to have to do it.

Benjamin Young: So, I like what you just described. any more to be said on
the …

Manu Sporny: I'm raising an issue.

Benjamin Young: wait. I think we Okay. Okay.

Manu Sporny: I'm raising an issue in VC data integrity. would be good to
hear others thoughts on whether or not we keep this section just going back
up the stack or section 44. Are we getting rid of this section or keeping
it?

Dmitri Zagidulin: I don't mind either I've

Manu Sporny: I guess let me suggest strongly that we delete it. I think
it's duplicative. would anybody object to us just deleting this and just
referring people to the data model section or…

Manu Sporny: sorry the VC data model security considerations?

Benjamin Young: Okay, I think you're good to go.

Benjamin Young: With that, let's move on to verifying recognition chains.
Yeah, I know you're good.

Manu Sporny: Sorry, I'm currently typing up the issue for BC data integrity.

Benjamin Young: I can read what it's here, so can everyone

Benjamin Young: So this mostly seems to raise cautions around the potential
unbounded nature and the transmorphing of lists as you traverse those
related lists. anyone have thoughts about this?
00:55:00

Benjamin Young: Good morning.

Manu Sporny: I think this basically has to do with when you jump list
formats or…

Manu Sporny: one of the issues here is when you jump list formats. So let's
say what a verifiable recognition credential can have in it is a reference
to another list format like an Etsy trust list in the European Union. It
could also refer to an X509 certificate chain and say you should trust
everything listed in here.

Benjamin Young: Damn it.

Manu Sporny: When you make that jump, the way that you do the evaluations
change dramatically. So, the way that you interpret an Etsy trust list is
very different from the way that you interpret an X509 certificate chain,
which is very different from the way that you interpret a verifiable
credential sorry,…

Benjamin Young: Yes. Thanks.

Manu Sporny: a verifiable recognition credential, so this is basically
saying you can't just blindly trust the entries in there. It has its own
way of establishing trust. So you need to pay attention to that. and this
is largely a handwave because we don't know if anybody's going to use this
particular feature. we did this to make sure that we were compatible with
everybody else in the world that wants to run their own kind of different
trust list things. We wanted to do it so we'd be backwards compatible with
X509 certificate authority lists. but it's really like an exercise to the
implementer to do a good job here. plus one.

Manu Sporny: I think we should talk about this.

Manu Sporny: I think we should speak about it in fairly broad terms, but we
shouldn't suggest what they should be doing because it's way too
complicated.

Dmitri Zagidulin: Agree.

Benjamin Young: I think the fraud terms are helping.

Benjamin Young: Good idea.

Dave Longley: Yeah, at any point if you're using any tool, there's some
entry point into that tool and then you follow that tool's rules. So, I
think this section is just going to say you have to use the rules of
whatever the list is that you're trying to use and…

Dave Longley: you have to know what those are. if those tools work
properly, it shouldn't matter that the entry point happens to be X or Y.

Manu Sporny: Yep. Okay.

Manu Sporny: Hopefully that's pretty straightforward. if anybody else has
thoughts on this, we can move to the next one.

Manu Sporny: If not, we're out of time.

Benjamin Young: There we are.

Benjamin Young: I don't think we can sneak one in two minutes, but this
will come back to next week. Mono, you're blocked essentially on merging
this, Okay. Right.

Manu Sporny: Yes, I'm blocked on both of them. I don't have enough reviews
for 62 and then for 61. It's just that last one. I don't know if does
anyone have severe objections to this? This is basically saying hey, you
need strict governance around allowable actions and we need to talk about
it. if this text go went in verbatim, would anybody object to it? We still
need to write the text associated with it, but I think it's worth saying
something about it.

Manu Sporny: What are the actions your ecosystem understands? Issue verify
and…

Benjamin Young: here. Yeah,…

Manu Sporny: you need to be specific about what those things, mean. Okay.

Benjamin Young: I think unblocking the PR is higher priority.

Manu Sporny: And we can always change it later. With that, I have enough to
merge this one.

Benjamin Young: Okay, great.

Manu Sporny: Thank you everyone.

Benjamin Young: Thanks And we will be at a different time next week. not
yet sure if it'll be an official working group call or not, but we'll keep
you posted. Thanks all. Bye.
Meeting ended after 00:59:54 👋

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