[MINUTES] VCWG VCALM 2026-04-28

The VCWG VCALM meeting on April 28, 2026, focused on improving meeting
scheduling, developing a threat model document, establishing test suites,
and resolving an IPR commitment issue. The group agreed to use a new poll
to determine a more suitable meeting time, with Manu Sporny creating a
"WhenIsGood" poll for this purpose. Significant progress was made on the
threat model document with Eric Schuh presenting a draft, which will be
further developed with Joe. The discussion on test suites led to an
agreement to break them down by conformance class, leverage JSON schemas,
and explore automated generation for efficiency, with Manu Sporny's company
offering to provide a reference implementation. The meeting concluded with
Patrick St-Louis highlighting an outstanding IPR commitment issue that will
be followed up with external support.

*Topics Covered:*

   - *Scheduling Discussion:* The group discussed the results of an initial
   meeting time poll and agreed to use a new poll with more options to better
   gauge participant availability. Manu Sporny created a "WhenIsGood" poll to
   facilitate this.
   - *Threat Model Document:* Eric Schuh presented a draft threat model
   document, outlining the usage, architecture, and stakeholders, and
   initiated a discussion on the use case and potential sub-diagrams. The
   document will be further refined with Joe and contributions are welcome
   from the group.
   - *Test Suites Discussion:* The need for a VCALM test suite was
   discussed, with Digital Bazaar offering to provide a reference
   implementation. The group agreed to break down the test suite by
   conformance class and leverage JSON schemas, while also exploring automated
   generation of tests and refreshing existing VC API issuer and verifier test
   suites.
   - *IPR Commitment Issue:* Patrick St-Louis raised an issue regarding his
   IPR commitment status, which appears to be incorrectly flagged despite his
   account being linked and updated. He will follow up with external support
   to resolve this configuration problem.

*Action Items:*

   - *Patrick St-Louis:* Review the specification for "must" statements and
   create a tally chart broken down by issuer service, verifier, and workflow
   sections.
   - *Patrick St-Louis:* Play around with the schemasis tool using the API
   definition to check for conformance.
   - *Patrick St-Louis:* Follow up with Evan Herman and support regarding
   his IPR commitment issue.
   - *Manu Sporny:* Share the "WhenIsGood" poll link with the group for
   them to vote on meeting times.
   - *Eric Schuh (and Joe):* Continue developing the threat model document,
   focusing on refining the DFD diagrams and use case.
   - *All Attendees:* Contribute threats to the threat model document or in
   the relevant GitHub issue.

HTML: https://meet.w3c-ccg.org/archives/w3c-vcwg-vcalm-2026-04-28.html

Video: https://meet.w3c-ccg.org/archives/w3c-vcwg-vcalm-2026-04-28.mp4

[image: W3C] <https://www.w3.org/>
VCWG VCALM 28 April 2026 Attendees

Present

Benjamin Young, Dave Longley, Eric Schuh, James Easter, John's Notetaker,
Kayode Ezike, Kevin Dean, Manu Sporny, Nate Otto, Parth Bhatt, Patrick
St-Louis, Ted Thibodeau Jr

Regrets

-

Chair

-

Scribe

transcriber
Contents

   1. Scheduling Discussion <#ffff>
   2. Threat Model Document <#97b2>
   3. Test Suites Discussion <#c91e>
   4. IPR Commitment Issue <#6027>

Meeting minutes

Patrick St-Louis: Welcome to the call. We'll get started in a couple
minutes.

Patrick St-Louis: Okay, let's get started with today's call. I'm sure more
people will keep trickling in as we go through the introduction. So,
welcome to the VCall meeting, the VC API for life cycle management. this is
a W3C meeting. So all W3C policies are into effect during this call and
this call is recorded. so if you make any contributions these contributions
will be towards the W3C. before we get started, so there's a few topics I
wanted to discuss. I think there's going to be other topics that people
will bring up.

Patrick St-Louis: Before we get started with our listed agenda items, I
will leave some room for anyone who would like to introduce themselves,
share any community updates, or suggest a new agenda item. So, I'm going to
leave a minute now. Just either raise your hand or take the microphone.
Scheduling Discussion

Patrick St-Louis: Okay, in that case, let's get started with the topic. So,
the first thing I wanted to loop back on was the question about schedule.
So a couple of groups sent out polls to query the broader W3C community if
what would their preferred cadence and time slot be for schedule. So I had
sent a very simple poll with survey monkey. it was just asking people to
pick a day and a time.

Patrick St-Louis: it was limited to one answer per person. and there's some
people that kind of thought that maybe wouldn't allow a accurate
representation of people's availability. U so I would like to look at these
results and review maybe if we want to send a new poll that provides more
options. so the poll was sent I think about two weeks ago now maybe a bit
less. there has been six response and there is a high response So Tuesday
was the preferred day and there are a couple of hours suggested in Tuesdays.

Patrick St-Louis: So my question would be do we want to create a new poll
and with more availability a little bit similar to the other polls that
were shared with I believe it was made with Doodle in the hopes that this
could maybe reflect a more data to make better decision. any comment
towards this?

Patrick St-Louis: Yes, Ted.

Ted Thibodeau Jr: I did not answer your poll.

Ted Thibodeau Jr: I haven't seen that message and that's no fault of yours.
I way behind on email. that said, six out of 15 participants, I'm not sure
if that includes chairs and editors, is not a very high participation. And
there are five days of the week and even if it's concentrated on Tuesday…

Ted Thibodeau Jr: which happens to be where the calls have currently been
more participation is better and…

Patrick St-Louis: Yes. Yes.

Ted Thibodeau Jr: a broader range of options is likely to get a better
participation rate at least in the answers. And even if we wind up back at
three, better to not lose people because of the timing if we can.

Patrick St-Louis: So to be clear, people could choose any day of the week
from 8:00 a.m. to 5:00 p.m. Eastern Standard. so there was still a choice,
but it was limited to one choice per person as I think something that was
preferred is that each person could enter any number of slots that they
want during the week.

Patrick St-Louis: it adds a little bit complexity to kind of pick something
that favors everyone. But I think could be argued that you do get a more
accurate representation of what would the best situation be. Manu

Manu Sporny: Yeah, just a plus one to run another poll. I'm creating one
right now if that would be helpful to you, meaning I can share screen.
Usually the only times that really work are 10:00 a.m.

Manu Sporny: 11:00 a.m. maybe 12:00 p.m. and then maybe 3 p.m. and 400 p.m.
Eastern. so I can, open a poll for those times and share if that would be
helpful.

Patrick St-Louis: Yes. that would be great.

Patrick St-Louis: So my question would be what if someone who's attending
the group has a conflict with the new suggested date?

Patrick St-Louis: They won't be able to attend anymore or what would be the
way forward in that situation?

Manu Sporny: if they're critical.

Manu Sporny: Typically, it's if they're critical, you don't want to miss
critical people.

Manu Sporny: And so, it automatically removes the time as a possibility.
for example, if the chair can't make it clearly like you can't, yeah,…

Patrick St-Louis: Okay.

Patrick St-Louis: So, yeah, I'm definitely happy to send a new poll. if you
want to show me, your poll, I can send this or kind of have a look after
the call. I Yeah.

Manu Sporny: Let's see. One, two, I am trying to create. Google has changed
what they allow you to do now. You can only pick eight times instead of 15.
It used to be 15, which is interesting.

Patrick St-Louis: So the reason why I went to Survey Monkey and reading the
other polls, I could have just said that, but it's because the poll is
structured a specific date instead of a weekly reoccurrence thing.

Patrick St-Louis: And I thought this was a little bit misleading. but now
that reading that they just explained that in the poll description. I'm
wondering if I should not have just done this, but this was the

Ted Thibodeau Jr: I don't remember it off the top of my head. There is
another recent entry into find a meeting time world which I don't think has
that same limit to eight options that doodle is doing…

Patrick St-Louis: Okay. Yep.

Kayode Ezike> WhenIsGood is one I used to use a lot

Ted Thibodeau Jr: which I think is dumb as hell but what are you going to
do and yeah that every one of these new task forces is trying to do the
same thing right so they're all going to be colliding and here are specific
dates and times. It's really easy for me to go through and say, "Okay, yes,
I'm blocked on this date and that date, but that doesn't necessarily apply
to the whole month." And it probably needs to be a twoe range at this point
to cover every two weeks cadence that some of the forces are setting up.
neither is answer helpful, but if that other polling tool can be found that
puts us in a better position.

Patrick St-Louis: Yeah, someone commented something. Let me pull up the
chat. My Hold on. so KOD said when is good or when to meet. so these are
definitely contenders we can look at…

Kayode Ezike> Or When2Meet

Patrick St-Louis: if Doodle it doesn't quite fit what we're trying to do.

Manu Sporny: I'm looking when is good site now and trying to create
something there. I see becom… Manu Sporny:

Patrick St-Louis: I've not looked at this one.

Patrick St-Louis: I can definitely look should we come back to this leave
maybe 10 minutes before the end of the meeting and go back to this topic is
Good.

Manu Sporny: although I've almost got it set up. send this link to. So it's
this one.

Patrick St-Louis: This is pretty nice.

Manu Sporny: And then the results are going to be there. Yep.

Patrick St-Louis: Like this.

Manu Sporny> WhenIsGood: W3C VCALM Meeting Time
<https://whenisgood.net/cibjb9s>

Patrick St-Louis: It's pretty straightforward. it doesn't seem complicated.
It still has the same issue that it's specific day. but I think we can just
explain that this should be seen as just a weekly reoccurrence type of
availability. just regarding Ted's comment about going over two weeks, how
do we feel about this? Is this something we want to cover or we want to
just keep going on the presumption that we'll be meeting weekly?

Patrick St-Louis: Manu Yeah.

Manu Sporny> WhenIsGood: W3C VCALM Meeting Time Event Results
<https://whenisgood.net/cibjb9s/results/pnxxfdw>

Manu Sporny: I think meeting weekly and…

Manu Sporny: Ted I guess people should just take into account is this going
to be an issue every other week or not because if it is then we don't pick
the time I guess.

Patrick St-Louis: And if someone has a conflict one week out of two, they
can just attend one week out of two even if the meeting is on a weekly
basis. okay is there any further comments towards this otherwise the
resolution here is that when is good poll that manu created. I will frame
it as a followup to the first poll making sure that people can enter their
vote and that it gives more availability more options. Any other comments
on that topic? thank you Kyote for the suggestion. this was resolved
quickly.

Ted Thibodeau Jr> rallly might be the one I was thinking of. There are a
few others -- Google Search
<https://www.google.com/search?q=best+doodle+replacement+for+finding+recurring+group+meeting+times>

Patrick St-Louis: Okay, so a second topic. speaking of the devil, so as
some have probably noticed, both Coyote and I are part of the organizers
along with Brent and Phil. Coyote reached out and we had a discussion
offline that we will be working more as a team when it comes to hosting the
call. So what we've decided is we will be alternating weekly who the host
is and we also will be available to cover in case that someone has a
conflict and cannot make it on one week. did you want to speak to this Kyod
or

Kayode Ezike: Yep, that's exactly Thanks, exactly So, we would like to
basically share the load of hosting. I understand there a lot that goes
into it and so figured it'd help to help with that. I've already kind of
committed to memory/documentation like all the front matter stuff that I'd
have to say at the beginning of calls and things like that. But, I was
prepared to start today. I think my computer's a little troublesome today.
So, I think maybe next week and I'll be back in my regular working station
at that point.

Kayode Ezike: But yeah, still going to be me, same just going to be
facilitating and supporting on this call. So, yeah.

Patrick St-Louis: Yeah, thank you.

Patrick St-Louis: Yeah, sorry we didn't really pick a start date. I just
figured that just let people know. so next week Coyote will be hosting and
then we will try to keep to alternating between a week or two but there
might be some times that I'll be hosting and Coyote will be hosting. thank
thanks a lot for proposing this coyote. and I think it will make this group
a little bit more dynamic even though we're already quite dynamic and we'll
provide some different insights into how the calls go.

Patrick St-Louis: Manual.

Manu Sporny: Yes, plus one. Thank you Coyote for stepping forward to do
that. I am adding you right now to the control for the call. It's going to
be your Gmail account. but if you are using your Gmail account, you'll be
able to start calls automatically now. So when you show up to the call and
you join, the call will be started. Patrick doesn't need to be here. The
I'm clicking through all the things. the only other person that can auto
start calls is Benjamin and myself. So right now to start this call,
Patrick has permissions.

Manu Sporny: Coyote, you now have Benjamin and I have permissions. that's

Patrick St-Louis: Perfect. I think that's very good.
Threat Model Document

Patrick St-Louis: And yes, like I mentioned, thank you a lot KOD. this will
help tremendously. So we had mentioned a couple weeks ago I say briefly we
had quite a bit of a discussion around it but that we would need some form
of threat model document to live somewhere in the specification.

Patrick St-Louis: Eric and there was an issue. Eric and I kind of assigned
ourselves there and we were going to come up with the initial proposal. so
I put this on the agenda item and parallel to this Eric shared in the
standards slack channel that he was going to comment a little bit on an
issue. so this fits right in with this discussion here.

Patrick St-Louis: Do you want to lead this topic Eric since you prepared
some discussion? do you want to share the screen or do you want me to share
the screen? I think there was like you mentioned some comments somewhere.

Eric Schuh: Sure.

Eric Schuh: Might be nice if I take over the screen share just to so I can
jump around a little bit.

Patrick St-Louis: Yes, please go ahead.

Patrick St-Louis: Going to stop presenting right now.

Eric Schuh: One second.

Eric Schuh: Hopefully that's sharing yeah, so I know Joe had originally
taken this on but since it was moving kind of slow, I jumped in yesterday
and started some work on a draft threat model. I'm following the new threat
modeling guide that's still being worked on at the W3C, but most of the at
least upfront content and kind of instructions are there for how to do
threat modeling. And I'm also patterning off of the did resolution threat
model I believe it's at least in a draft. so that's kind of where I started.

Eric Schuh: just because of kind of the nature of developing these threat
models to begin with, I thought a Google doc might be a better tool than
the GitHub issues for actually starting to collect threats and stakeholders
and feedback. So, currently everything's in this Google doc. if the group
would like to move that to issues more directly, I think we could make
something work, but I'll just go over what I've done so far and then we can
see how the group wants to take it from here. so basically what I've done
is started a threat model draft. I put together a draft usage section.

Eric Schuh: Obviously the language here is probably pretty rough at this
point but hopefully it gets the idea across. And then the architecture
section I also had a write up in currently this architecture section is
almost a reframing of the usage. but I mostly did this just to get a sense
of the use case I was trying to deal with in terms of creating the
architecture diagram which I started but haven't gotten too far involved
with pending I think some questions I had as I was doing this work for the
group.

Eric Schuh: So this architecture section eventually, just so people kind of
have an idea of where we're headed with it, should look something more like
this where you have your diagram and then the architecture section should
actually call out kind of and it should walk through a reader through the
diagram and the intended flow of the use case that is being kind of
highlighted in the threat model. so you'll see through here in the
descriptions there's callouts to all the different elements and components
and processes and all of that. so the architecture section right now is
very much a draft.

Eric Schuh: I started on the DFD diagram for the holder here in the same
vein as what you see in that did resolution and then I indexed a number of
stakeholders that come out of kind of that first DFD diagram where I copied
what I did for the holder here to match the issuer and the verifier as
well. so this was just a first pass at the stakeholders. and there's a lot
of them as you can see already. and I think I'm definitely missing some
because I don't have the workflow, services represented at all currently in
these diagrams. and then, a section for threats that I haven't started on,
but I was thinking that if anyone wanted, you could come in, copy this kind
of first index, and we could just start collecting a list of threats here
that people are interested in.

Eric Schuh: Eventually we do want to tie each of these threats to the
components that they are affecting but that needs the full diagram. and
since we don't have that I was thinking that if people wanted to they could
just come in give a threat name a brief description try to give a type of
threat which I gave a reference to here. this is directly from the threat
modeling and then if you could leave an identifier as well so that if we
eventually come back to one of these calls and want to talk about it, we
know who added and then some questions that came out of it. These questions
are copied in the issue here.

Eric Schuh: The first one is basically just a statement that as a group we
kind of need to decide on u some form of abstract use case that illustrates
the life cycle of a verifiable credential as it moves through the VCOM. So
I kind of highlighted in bullet points here kind of the outline of the use
case I was thinking of. I do have some specific questions is it worth
getting into the deletion and revocation of the VCs and how that affects
the interactions? I think that there might be some threats that deal with
these interactions in particularly, which is why I felt like I needed to
include it kind of in this brief use case outline.

Eric Schuh: But that's kind of where I would propose we start as a group is
to try to settle on kind of the flow that we want to highlight of a user
getting issued a verifiable credential taking it and using it someplace
else having it verified and then whatever else we decide should be included
kind of in that life cycle flow. the other couple questions were just some
other things that came up. this diagram was already getting fairly large
and had a lot of boxes on it. So I did have a thought that maybe because of
the complexity of our architecture might want to try to break the DFD into
a few different sub diagrams. maybe one like this one for the issuer and
one for the verifier.

Eric Schuh: and then have kind of a unifying more abstract diagram that
just leaves the holder, issuer, and verifier as kind of single boxes
instead of breaking down all of the components. and then this last question
is one that it kind of depends on the abstraction that we want to use, but
should our primary user be considered the holder? I know that depending on
the architectures that people choose to implement, the user may or may not
actually be considered the holder in every use case. So, that was just
another thing that got brought up as I was going through the work. so
that's what's here so far. happy to take feedback.

Eric Schuh: I guess my last comment would be that I imagine as Joe gets
back from IIW at the end of this week, he and I will probably sit down and
do a more extensive revision of this diagram. so I would be surprised if we
get a kind of complete draft by next week, but hopefully the week after
that we could have a more complete diagram going forward. so I'll open up
the floor questions, comments, concerns.

Dave Longley: Thanks This is great start to the work. I was thinking that a
way we might want to consider doing this is thinking about two I think
we're going to end up having essentially two sort of different views on
that on maybe just two big threat models. One for one that covers cross
trust boundaries and one that doesn't. So I think in each one of the
throughout this architecture there are situations where messages are
crossing trust boundaries and then situations where messages are within
trust boundaries and so that's true for all three participants issuer
verifier and holder and maybe we want to frame the threat models in that
way.

Dave Longley: So each one of them would have a threat model that's like
this is the threat model for sending messages within my trust boundary and
this is the threat model for when messages go across that. And so if you
were to look at an issuer, they would have the services and things and
interfaces they use in VCOM that are behind you could think of them as sort
of being behind a firewall. And then those that involve if we just take an
issuer as an example, the issuer is going to communicate with a holder, but
they're also going to communicate with their internal services. And so
those two things seem to diverge pretty significantly to me. And it seems
like we would have two different threat models or organize the threat model
such that there's two different pieces for that. And then that just repeats
for a verifier in their own services and a holder in their own services.

Patrick St-Louis: I'll let you a few minutes to write this. Manu, did you
have something to add here?

Manu Sporny: Yeah, I'm gonna wait until Eric's done typing.

Eric Schuh: Go ahead, Mono. I think I'm just trying to make sure I remember.

Manu Sporny: Sure thing.

Eric Schuh: So, I think I have enough

Manu Sporny: Yeah. plus one. this is a great start. Thank you, Eric, for
working on a plus one for breaking the DFD down by holder issuer, verifier.
I'm concerned that people look at the threat model and they're whoa, this
is so complicated. other things that don't have this level of detail are
less complicated. I'm going to go with the other thing. So that's one of
the concerns I have.

Manu Sporny: And the other one is for any anyway so having a high level DFD
that's like this is the verifiable credential ecosystem issuer holder
verifier and having that as the top level would be a good thing and then
breaking it down as okay these are all the components that are associated
with the holder would be good as plus one to just focusing if we need a
primary user or actor or whatever. yes, let's make it the holder because
we're supposed to be a holder centric model and so looking at it from that
vantage point I think would be a good thing. that said issuers also care
about things like reputation as do verifiers.

Manu Sporny: So issuers, care about people trusting the statements that
they made. And if somebody can spoof the issuer, then their reputation's
damaged. Same thing for a Verifier's reputation is harmed if they accept
credentials that are revoked or invalid or whatever. And therefore, that's
an attack we should talk about and we should talk about the mitigation for
that digital signatures and revocation lists and things like that.

Manu Sporny: Plus one to helping people understand focus in on some parts
of the DFD and speak directly to those things in different sections of the
threat basically make the threat model more easily consumable. than the
diagram that we have in the VCOM spec which is complete but it's like you
look at it and it's like an eye chart, right? it's Lego. That thing's,
fairly complicated. So, there's that. I guess the other concern I have is,
we are on the standards Time's ticking and I want to make sure that we get
a first rev of the threat model. And I think Eric, you said maybe in two
weeks we'll have a first rev there.

Manu Sporny: And I think that would be great timing because I want to try
and raise horizontal review on the VCOM spec as soon as we can. Meaning
maybe we do it right after our face toface meeting at the beginning of
June. which is only about a monthish away a month and a week away. maybe we
have other things that we talk about there…

Manu Sporny: but it would be nice to kick off horizontal review by mid June
towards end of June. I think that's it. Go ahead, Ark.

Eric Schuh: Yeah,…

Eric Schuh: I just want to be a little bit careful with the draft. I think
my goal is going to be to a full draft of the threat model of course is
going to require us to actually index all the threats and everything on top
of that which can be done in parallel in many ways but also the work can't
be actually finished until you have the DFD because you have to be able to
tie the threats to the particular components in the DFD at least in terms
of currently how the guide is describing things right so it'll probably be
a week or two after

Eric Schuh: that I think we would probably feel safe saying we have a draft
threat model as a whole. But hopefully in two weeks if we actually do get
some other people to come in and list some threats and on top of what
myself and Joe do we'll have all the pieces to actually get a draft kind of
put together.

Manu Sporny: Plus one to that. Remember that when you put in a request for
a horizontal review, it doesn't happen for 3 to 6 months, so that's why I'm
kind of like the second we have a link to point to and it's got a DFD and
maybe a highle list of threats in it, that's the point at which we request
horizontal review and it'll take them months to get around to it typically.
So in theory, we'll have a very good solid draft, in that time frame. And
it also helps us put pressure on making sure that we get that in a decent
state before the reviewers get there.

Eric Schuh: Yeah, that all sounds good. yeah, I haven't been through that
process myself, I don't think. So, that's good to Thanks, Mono. I don't
know if there's much more we want to discuss today on this particular
topic. I think if people have thoughts on kind of this use case outline,
that's this number one in the comment I put. whether there's any
interactions that we should include or shouldn't include kind of in this
flow. or if not, I think Joe and I could also just take a stab. I know Joe,
he'll have opinions about what I put here.

Eric Schuh: So we could also just take that as work and work off…

Patrick St-Louis: Nothing.

Eric Schuh: what we think is best and present in either one or two weeks
and see where we're at.

Manu Sporny: Yeah, plus one of that. I think you said this before. we want
the entire life cycle. So everything that goes from the holder shows up at
an issuer the holder potentially does off or some kind of strong
cryptographic binding proof to the issuer. The issuer pulls information and
issues a verifiable credential that's revocable, gives that over to the
holder. The holder, does a variety of things with that, maybe just holding
on to it for right now and then delivering it to a verifier.

Manu Sporny: the verifier checking to make sure that it knows the issuer,
the signature is valid, the credential hasn't been re revoked as the
primary arc and then as a secondary arc the expiration of the revocation of
the credential. you should probably show those kinds of things as well.

Patrick St-Louis: Not

Manu Sporny: I guess as a secondary thing I'm wondering how much of this
can be pushed back into the verifiable credential threat model right
because we're going to talk about that at the face toface meeting. I don't
know, Eric, if you and Joe have been able to talk about what those
discussions are going to be like,…

Eric Schuh: Yes.

Manu Sporny: but I think we've got a good chunk of a day focused purely on
threat model for verifiable credentials. And if we could go into that
meeting with this I don't know I don't know what the main differences are
going to be between the verifiable credential threat model and this threat
model. my guess is verifiable credential is going to focus way more on data
modely things and this threat model is going to focus way more on the API
and…

Manu Sporny: movement of data things.

Patrick St-Louis: Yes. This Yeah.

Eric Schuh: Yeah, that sorry. Go ahead,…

Patrick St-Louis: Go ahead.

Eric Schuh: Patrick. Yeah,…

Patrick St-Louis: No, You go here.

Eric Schuh: that sounds right to me. I definitely so far in what I've been
thinking about here, I'm trying to leave the verifiable credential kind of
as a black box, So, it's referenced, but I don't get into any details about
what's inside of it or how it's structured or anything like that. and I
think that's a good dividing line in terms of this threat model and the
verifiable credential threat model, but Joe and I haven't had a chance to
discuss that in detail. So, I'll try to bring that up with him as he gets
back from IW next week and, maybe we'll have more thoughts. I think Joe is
planning on going to that face to face. I'm fairly certain.

Eric Schuh: So any work we do here he should have a very good idea of kind
of what we did here and what's happening in the VC world over there. yeah
that sounds good.

Patrick St-Louis: …

Eric Schuh: And thanks for the feedback on kind of the use case and flow.
Yeah,…

Patrick St-Louis: it sounds like you have enough information to from what
understood, you're going to, try to connect with Joe to review a couple of
items in there. Mhm. Yes.

Eric Schuh: review with Joe and he has a lot more experience with these
DFDs than I do. So, work with him to get kind of a first draft of I think
maybe what's going to be four different DFD agram one for each the holder,
issuer and verifier and then a highle kind of unification diagram as well.

Patrick St-Louis: Is there any other comments to this?

Patrick St-Louis: I think this sums up at least this satisfies the kind of
discussion I was hoping to have around this item which was just to keep a
pulse on it and make sure it's moving forward. So thank you a lot Eric to
put this together. I will have a look at the issue after the call and…

Patrick St-Louis: put some comments too. U but nothing really came to mind
right now. yes, Eric.

Eric Schuh: So I think good to move on. My last I guess repeat of the call
to action is if people do want to come into this document and just start
adding threats feel free or if you prefer I think we have this issue here
and you could just leave a comment with threat ideas if you have any and at
some point this I'll aggregate across both this issue and this document and…

Eric Schuh: I imagine we'll have a number of calls debating which threat
threats to include or not include or priorities and all of that. but please
if you have time and interest start adding threats that you can think of

Patrick St-Louis: Very good.
Test Suites Discussion

Patrick St-Louis: Any other comments on this topic of threat models? In
that case, I'm going to take over the share and we will move on to the next
topic. So this was the same idea just wanted to loop back in the discussion
around test suites.

Patrick St-Louis: we will need a VCOM test suite that will be probably
focused around workflows and completing workflows and making sure that all
the components are called and respond properly within the scope of a
workflow. so The first thing I think we will need at some point and I put
air quotes here reference implementation that someone can build this
usually test suite you have the test suite you have a client and then you
test open implementation.

Patrick St-Louis: But it would be good to have one reference implementation
somewhere that we can use to build this test suite.

Kevin Dean: It is okay.

Patrick St-Louis: My gut feeling is this type of test suite, is very
different than testing the VC data model, right? it's going to be very
dynamic. There's going to be different moving parts, especially if we want
to test the workflows. so I think it'd be important to have at least a
initial reference implementation, someone that's brave enough to provide
this. Manuel, I'll stop there.

Manu Sporny: brave or foolish enough, digital bazar is happy to provide a
reference implementation for this.

Patrick St-Louis: Yeah, I want to do

Manu Sporny: I think we've tried to be as close to the VC API becom spec
and implementing across our entire product line. and I think we have
successfully implemented and have deployed in production all the endpoints
we're also happy to configure things in ways that would be friendly to
writing a test suite so yeah I mean we're happy to be one of those
implementations I'll note…

Manu Sporny: though what was it at last count Benjamin it was some
ridiculously high number. There are other people that have implementations
as but we're happy to be the guinea pig basically is what I'm saying.

Patrick St-Louis: Yeah, because I think when it comes to confirm and…

Patrick St-Louis: center up it's like I

Patrick St-Louis: I think there's two side the first one are you
interroperable with yourself right if your implementation assumes all the
role can we have a success at the end of this and then once people confirm
that their implementation is conformant then we can move on to cross
implementation testing which hopefully is kind of a seamless transition but
I know my experience, there's always things to discover when this starts.
okay. So, this could be an action item. I can open an issue for this.

Kayode Ezike> Can we reuse the test suite that we had pre-VCWG?

Patrick St-Louis: Something I could have a look at is to, do a tally of the
normative statements from the specification and bring maybe a short
analysis or summary. and we can review the spec on the next call from we're
about to create a test point of view. and what's the scope of this test. So
I think having this kind of highle tally of how many normative sections we
have how specific are the normative statements that we want to test it'd be
a useful pointer to know the scope of this test suite and then we can
discuss how to tackle it.

Patrick St-Louis: I think it's probably going to be a sort of an
incremental testing. Maybe we'll start by scaffolding from a very high
level and then add very specific test statements as we move forward along.
any comments regarding to this? So I heard the chat. Yes, Manu. Yes.

Manu Sporny: I'm going to do a screen share real quick. So this is the
current test suite that we have for just issuing credentials. So we do I
think have a very old issuance thing and we've got what is it 1 2 3 4 5 6 7
eight implementations already that can just do basic issuance. clearly
we're going to have to do much more. I think Benjamin's sharing the
verifier one as well.

Benjamin Young> GitHub - w3c-ccg/vc-api-issuer-test-suite: Test Suite for
Issuers that implement the VC HTTP API · GitHub
<https://github.com/w3c-ccg/vc-api-issuer-test-suite>

Manu Sporny: I'm so a couple of thoughts on the test suite. I think we
should certainly break it up into spec sections like you said. Patrick by
conformance class. So there's an issue service conformance class I think
and then there's a workflow service conformance class and so on so forth.
Break it into those things. And then we've done a pretty tremendous amount
of work trying to make sure that the JSON schemas are appropriate for all
of the data going to and from.

Benjamin Young> also for verification GitHub -
w3c-ccg/vc-api-verifier-test-suite: Test Suite for Verifiers that implement
the VC HTTP API · GitHub
<https://github.com/w3c-ccg/vc-api-verifier-test-suite>

Manu Sporny: And so rather than if we can get away with it, I would like us
to focus on the JSON schemas being the thing that tests the inputs and the
outputs just to see if the syntax is valid rather than every single
normative statement within the autogenerated, JSON schema in the
whatchamacallit. what you're pointing at might be a great way to go about
it.

Manu Sporny: The other highlevel point I'd love to get people's reaction on
is leaning heavily into using something like cloud code to extract and
generate the tests potentially on a kind of a CI process meaning that it
would look at very specific sections. It would extract, all of the
mandatory statements. It would try to align it with, the JSON schema and
see if we have a good coverage. I only say that because we are going to
revise the spec and managing the test suite stuff is incredibly labor
intensive.

Manu Sporny: So to give people an idea of the costs, we have spent anywhere
from, $75,000 to $380,000 on test suites. That's how much it actually costs
in labor to put one of these things together. I would love for us to find a
way to, reduce that cost and make it easier to kind of generate and keep
test suites in line with the specs. and we might use this as an opportunity
to experiment with that. and that's a very big handwave. I don't know what
the best approach to that would be, but maybe that is an approach we could
take.

Patrick St-Louis: Yeah, I think this is good. we're getting a bit technical
discussion. So, I'm sure many people have been using things like cloud cod.
I think in the recent month the price and the token cost has been very
unstable and increasing a lot, right? And I think Copilot just recently
announced they're no longer taking any more pro subscription and any
existing pro subscription is on a pay as you go basis. so we're getting
into the situation that while AI was a tool that could be casually used I
think a lot of people will start to be a little bit more cautious around
their token usage.

Patrick St-Louis: So that's the only thing that comes to mind as someone
who heavily use claude to do development task. I've noticed a tremendous
change in how this is handled in the last two months and I'm trying to be a
bit more conscientious about my token usage which is probably for the best
right I think there was definitely a overspend issue that happened because
it was just so readily available. This being said, I think it's a fantastic
tool, right? Especially for these kind of things, like if you point it to
the open API document is going to be able to extract a lot of information.
so I've been kind of using Shima thesis a little bit to do conformance
testing with an implementation. I don't have a and I just started using
this this weekend. I did not know it existed before that.

Patrick St-Louis: So I don't have a very strong how to say review of this
yet, but it seems like because we spend a lot of time defining this open
API file. so this can read a JSON or YAML. So it could be a great way to
start. This can output reports and do all these things. It's open source.
So this could be a great way to do it. the last thing will be like to
interop right when you have two implementation that they want to go through
this journey of presenting credentials.

Patrick St-Louis: But for these part as pointed out so that the VC API
verifier test suite maybe this would be a good opportunity to bring these
two test suite outside of the CCG and repolish them and make sure that they
are up to date with the VCOM spec because a lot of code there can be reused
but this just covers the issuer and verifier service endpoints it doesn't
cover any kind of exchange like state exchange. yeah. Okay.

Patrick St-Louis: So I think starting with a open API schema based
reporting is a very lowhanging fruit and could give a solid foundation to
this is what you need to do first like you need to properly implement the
API and…

Patrick St-Louis: then we could see how the existing VC API issuer test e a
workflow test suite would look like. yes, Benjamin. Yes.

Benjamin Young: Yeah, I think the biggest thing we'll need to be cautious
of with any of these approaches is making sure that the musts are covered
somewhere.

Benjamin Young: The vast majority of them are in the schemas already but
there will be certainly other ones as you're mentioning around workflows
and then others just tucks tucked away in the pros someplace. and…

Benjamin Young: we will need to audit those because that's ultimately the
thing required that these test suites must do

Patrick St-Louis: Yeah. …

Patrick St-Louis: what I can do I'll give this a try to do this by next
week is I'll review the spec and try to come up with some kind of tally of
all the must statements and try to maybe break down in a chart of which how
many are in the issuer service verifier workflow section to get a good idea
of because it should be equally spread out right if we have a very high
concentration of mus somewhere maybe we

Patrick St-Louis: and revisit this and see why it's justified but that's
something I can do and then once we have that we can have a look at this
API verifier outputs if they are still relevant because these were from the
VC API but from a few years ago I think most of the concept are the same
but maybe the wording changed a little

Patrick St-Louis: bit so this is what I can start to have a look at if
there is a reference implementation available I can start playing around
with this tool here schemasis to see if our sort of API definition makes
sense does that make sense everyone is there any comment any objection very
good. Can I choose? Yes. I've read this article in part. I think the
company database does a lot

Ted Thibodeau Jr: The part that got me was that they had a number of checks
in the prompt and…

Ted Thibodeau Jr: Claude totally rolled over them. And when they asked him,
"What did you do?" Claude's response was, " I did this. I was told not to,
but I did it anyway. And I was told not to do that, and I did it anyway."
So,

Patrick St-Louis: Oops. Yeah,…

Patrick St-Louis: I'm so I've been spending a lot of time learning how to
use tools like cloud as a team, and we're spending a lot of time looking at
these rule sets what you can prevent claude from doing. I've personally
never had disastrous events to happen.

Patrick St-Louis: also just due to the nature of this being test suite I
don't think it's that we should make it obvious that if someone submits an
implementation for conformance testing it should not have access to a
production instance but yeah I've definitely noticed a lot of odd behavior
also a lot inconsistent behavior. But this is something I'm trying to look
at right now just how you can set up your cloud environment. But this goes
for any kind of AI. a big problem I'm facing now is token usage as
explained I find it very inconsistent.

Patrick St-Louis: Sometime a very small task can deplete my tokens and
sometimes a large tax will use a very minimal amount of token and it's very
hard to get a good grasp of…

Ted Thibodeau Jr: Yep.

Ted Thibodeau Jr> Worth noting, re current use of LLM tools --
"Claude-powered AI coding agent deletes entire company database in 9
seconds — backups zapped, after Cursor tool powered by Anthropic's Claude
goes rogue" -- Claude-powered AI coding agent deletes entire company
database in 9 seconds — backups zapped, after Cursor tool powered by
Anthropic
<https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue>s
Claude goes rogue | Tom's Hardware'
IPR Commitment Issue

Patrick St-Louis: what uses a lot of token versus because you're not always
in control of what tools it's going to call and all these things. okay so I
can yeah thank you saying there's one last thing I wanted to discuss. I see
we're almost at the end. I was in touch with the people. They deleted my
old account. I linked my new account. but it's still not happy. And it
still says here that I didn't make IPR commitment and that I need to join
the verify claims working group. However, here it says that I'm already in
the group. so I'm not too sure what is happening here.

Manu Sporny: We will want to ping Avon Herman and…

Patrick St-Louis: Yeah,…

Manu Sporny: ask him what's going on.

Patrick St-Louis: I can follow up I had a thread with him he's the one I
resolved this and…

Manu Sporny: Yeah.

Patrick St-Louis: he kind of looped in someone from support. So I can do a
followup here. so I was like my GitHub account is linked. That's fine. but
there's something going here.

Manu Sporny: Yeah. I mean, I can always override that, Patrick, but it's a
deeper config issue,…

Patrick St-Louis: I yeah and…

Manu Sporny: I think, that they need to figure out what's going on.

Patrick St-Louis: not I feel like I want to get to the bottom of this here.

Manu Sporny: Yeah. Yeah.

Patrick St-Louis: So that's what I wanted to discuss. didn't get a chance
to get into PR, but there were a few PRs open. We will if you have time
this week, review them and we'll make sure to allocate more time to this
next week. yeah.

Patrick St-Louis: So that is thank you very much for attending everyone. we
will reconvene again next week. Coyote should be the host if all goes so
have a good rest of your week. Meeting ended after 01:00:38 👋 This
editable transcript was computer generated and might contain errors. People
can also change the text after it was created.

This transcription was generated by a large language model (LLM) and might
contain errors. When in doubt, check the audio recording. This page was
formatted by scribe.perl <https://w3c.github.io/scribe2/scribedoc.html>
version 248 (Mon Oct 27 20:04:16 2025 UTC).