[MINUTES] VCWG VCALM 2026-04-14

This meeting focused on advancing the VC API for lifecycle management
(VCALM) within the W3C. Discussions included establishing a regular meeting
schedule via a poll, outlining a strategy for threat modeling by creating a
dedicated directory within repositories, and updating the group on the
First Public Working Draft (FPWD) status. Several pull requests (PRs) were
reviewed, leading to the merging of a PR for the redirectUrl property and
discussions on PRs for selective disclosure pseudocode and workflow
processing algorithms, with further deliberation needed on their normative
status.

*Topics Covered:*

   - *Meeting Schedule Discussion:* The group discussed the need to poll
   participants to determine the preferred meeting time and day, aiming to
   accommodate new members as the group broadens.
   - *Horizontal Review & Threat Model:* A plan was established to create
   threat models within a model directory in each specification repository,
   avoiding individual W3C publication processes, with an initial focus on
   VCOM.
   - *FPWD Status Update:* The VCALM specification has successfully moved
   to the First Public Working Draft (FPWD) stage, with documents expected to
   be published in the W3C TR space on Thursday.
   - *Redirect URL Pull Request:* A PR adding the redirectUrl property and
   its description to the OpenAPI specification was merged, with a related PR
   for an example to be addressed separately.
   - *Selective Disclosure Pseudo Code:* A PR proposing pseudocode for
   selective disclosure was discussed, with feedback suggesting it should be
   converted into a normative algorithm similar to those in other W3C
   specifications.
   - *Index Allocator Definition:* A PR to define the "index allocator"
   term within the specification was approved, clarifying its purpose for
   readers and implementers.
   - *Workflow Processing Algorithm (Discussion):* A PR for a non-normative
   workflow processing algorithm was discussed, raising questions about
   whether it should be normative and concerns about the effort involved in
   converting it if it were to become normative.

*Action Items:*

   - Patrick St-Louis to send out a poll on the public credentials mailing
   list to determine preferred meeting times and days.
   - Patrick St-Louis to follow up with Ivon regarding the spec generation
   tool error preventing previews from appearing.
   - Patrick St-Louis to resolve their IPR issue with W3C account linking
   by contacting cisre at W3C.
   - Patrick St-Louis to review the PR for selective disclosure pseudocode
   and convert it into a normative algorithm based on feedback.
   - Patrick St-Louis to review the PR for workflow processing algorithms
   and address questions regarding its normative status, potentially deferring
   further discussion to the next meeting.
   - Joe Andrieu to make their signal or Slack contact available to Patrick
   St-Louis for assistance with understanding the threat model structure.

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

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

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

Present

Benjamin Young, Dmitri Zagidulin, Elaine Wooton, Eric Schuh, James Easter,
Joe Andrieu, 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. Meeting Schedule Discussion <#d800>
   2. Horizontal Review & Threat Model <#8f78>
   3. FPWD Status Update <#adb3>
   4. Redirect URL Pull Request <#9bfc>
   5. Selective Disclosure Pseudo Code <#ffff>
   6. Index Allocator Definition <#c43b>

Meeting minutes Meeting Schedule Discussion Horizontal Review & Threat
Model FPWD
Status Update Redirect URL Pull Request Selective Disclosure Pseudo Code Index
Allocator Definition

Patrick St-Louis: Welcome to the call everyone. We'll get started in about
two minutes. Just let people come in.

Patrick St-Louis: Okay, let's get started with the call and as people join
they will be able to catch up as we do the introduction. So, welcome
everyone to the VC API for life cycle management Today is the 14th of
April, 2026. This is a W3C meeting, so all W3C policies are into effect for
the duration of this call and this call is also recorded. If you have any
objections, please let us know. so today for the agenda, there's a few
topics I was proposing.

Patrick St-Louis: two of them are not on the list but I will introduce them
before we get started. but before proposing change to the agenda I would
like to leave some time for introductions and community updates. so if
anyone wants to reintroduce themselves or provide an update related to the
work that we do here now is the time. Please just raise your hand and take
the microphone.

Patrick St-Louis: As for the agenda today, I think we will have a quick
discussion about the meeting schedule. so, yeah, I'll get into more details
when we get into this. I wanted to also touch about the preview feature
which I'm not seeing anymore on poll request and we can address this when
we review the first PR. And another thing I'd like to discuss when we do PR
review I seem to be having an IPR issue although I don't think we'll be
able to do much on this call.

Patrick St-Louis: So that's the agenda. If anyone would like to propose an
additional topic, please let us know. Yes, Manu.

Manu Sporny: I want to briefly mention the horizontal review and threat
modeling stuff. We did talk about this on a previous call, but I want to
make sure we know what the plan timeline, all that kind of stuff is for
that item.

Patrick St-Louis: Perfect. do you mind if we just go over the meeting
schedule, get this out the way, and then address your topic? Perfect.
Coyote.

Kayode Ezike: And maybe also just a brief note on the status of the FPWD
for first public working draft which was put out last week as well.

Patrick St-Louis: Perfect. So, you want to take time to discuss about this?
Was that a suggestion for a topic or you just letting us know?

Kayode Ezike: Yeah. No. Yeah. just to let the group know, I don't think
everyone is a breast of the status of that. So it can just be added on at
some point. Can touch a little bit. It's

Patrick St-Louis: Yeah, we can touch on that quickly before we do the
reviews. Any other topics people would like to cover?

Patrick St-Louis: Very good. Then let's get started. If something comes to
your mind, don't hesitate to raise your hand suggest the first topic
meeting schedule. so we have been and when I say I'm talking here about the
previous umbrella that this call was under. So it was under the CCG. This
is our second meeting under the W3C. so this call has been running on a
weekly basis at the same time for probably ception. I know since I joined
which was about four years ago and we always had anywhere between 16 and 12
participants.

Patrick St-Louis: So I think it's a fairly good attendance rate. However,
now that the group is broadening, we might have new people who want to
participate. So, it would be probably advisable to send out a poll and see
if we can agree to keep the meeting at the same place or adapt if there's a
high amount of people that would prefer some other date. so that's what I
wanted to discuss.

Patrick St-Louis: I think we might even have to do it. I know there's been
some discussion about some emails about people inquiring for this. So my
proposal unless there's any objection is to send a poll on the public
credentials mailing list about a vote for when would the preferred time I
know myself I'll be voting for the same time. This is very convenient to me
and I invite anyone to put their thoughts as to when they would like the
meeting to be conducted. I've been on some calls before that they alternate
time zone from one week to the next. I'm not sure if we need to go on to
that level of adaptability.

Patrick St-Louis: So yeah, manual.

Manu Sporny: Plus all that. the way this is typically done is we send a
doodle poll out to the mailing list and ask people to weigh in there. we
usually do that because, we having a bunch of people respond to the mailing
list and then you having to then collate all of that stuff can be a pain,
Patrick. So, dual pole kind of gets rid of that. we can also do some
analysis on the data like we might get a fair number of people from the
Asia-Pacific region that want to participate.

Manu Sporny: Usually if you get more than two the chairs will ask us to
accommodate some alternate times. So that helps us collect data not spam
the list with a whole bunch of times people are available at and makes it
easier for you to kind of coate the stuff. We usually leave the polls open
for one to usually two weeks…

Manu Sporny: because sometimes people are in vacation. that's the typical
approach. we're free as the organizer to run it however you'd like, though.
That's it.

Patrick St-Louis: So a poll usually you want to give some option. So, could
it be something like a two question poll? One is a day of the week between
Monday and Friday and the other one is a time of day on the 24-hour clock.
Is that kind of a good approach here?

Patrick St-Louis: Yes, man.

Manu Sporny: Doodle has a pick a time for a meeting option and…

Patrick St-Louis: Okay. Okay.

Manu Sporny: when you go to set it up, you just select you do all of the
days Monday through Friday and then you can do, all of the times. typically
though, most meetings hover between 10:00 a.m. Eastern to 100 p.m. Eastern
and then 400 p.m. Eastern to 8:00 p.m. Eastern. you usually don't have to
provide options for 6:00 a.m. Eastern whatnot. So

Ted Thibodeau Jr> picking a day, and picking a time that might be on any of
those days, won't work so well. I will have conflicts, for instance,
Wednesday 10am, but not most other days at 10am… so time&day combination is
necessary

Patrick St-Louis: So, I've never made a doodle for myself, so I'll just see
what they have and then Probably going to send it out sometime this week.
And please put in your preferred time, may not be the current time. that
will be very helpful. So, any more questions on the next topic, horizontal
review threat model. do you want to lead this discussion manual or

Manu Sporny: Yeah. just we had an initial call this morning for the
barcodes and data integrity call where we talked with Ivon Herman who's the
staff contact for the verifiable credential working group on how to
structure the work around a threat model. so a heads up Joe and Eric, I
think we got to some kind of high level agreement on general approach for
documents that don't have a threat model yet. and this is going to be
talked about in the verifiable credential working group call tomorrow.

Manu Sporny: But the current proposal is in order to avoid having to
publish 20 threat models through the W3C process which means 20 shortname
approvals and 20 whatever and rather than do that we are just going to
create a directmodel in the current specification repository. in the future
we can choose to publish the files in that ory. So there will be a
directory called model in every one of the specifications. it will contain
an index.html which is a respspec file. It can have its own diagrams and
all that kind of stuff. It can be marked as a note so on and so forth. in
that directory will be autopublished for all the editor's drafts.

Patrick St-Louis> reading this I realize my proposal is problematic yes, It
needs to be a day + time

Patrick St-Louis> thank you

Manu Sporny: So you'll have the main spec and the main spec can refer to
that other file by linking to so that's kind of how we kind of get started
on and then in that index.html is where we put all the contents for the
threat model. if the thread model's small enough, we could probably include
it in the main spec, but maybe we just start with a separate threat model.

Manu Sporny: for all the documents. let me stop there.

Ted Thibodeau Jr> manu - can you provide a link to the recording and/or
minutes for this morning's call? (My local calendar hadn't updated until
too late for me to attend.)

Joe Andrieu: Yeah, that sounds great.

Joe Andrieu: I mean that there are two nuances I just want you to be
considering. One is I think what we are expecting to do is in the security
consideration sections to have the table of contents for the threat model.
and I think talking with Simone, that seemed like the right level of detail
between, just putting a link to the threat model or having some paragraph
that's explaining, but I think that the list of threats as a TOC it is
probably right idea. And then the other thing is that long term Simone and
I think that these threat models should be registries so that they can be
updated over the lifetime of the spec even though the working group's not
still and creating a registry is still a blackbox question. so that's just
a architectural note. I don't think it changes anything that you just said.

Joe Andrieu: I think deploying initially in the way that you said we could
also if we care to upgrade to a registry.

Patrick St-Louis: Yes, m

Manu Sporny: Yeah, plus one to all that, Sounds good. the registry thing I
clear you were not implying this, but I definitely don't want us to take
that on in addition to everything else we're taking on just yet, but in the
future that sounds fine. the other things for the future are things like it
would be nice to have the components easily importable into a threat model.
meaning I think for the VCOM's let me know what you were thinking Joe on
the verifiable credential data model but to do the barcode work and the
VCOM work it feels like we need a fairly complete set of components in a
verifiable credential threat model something or another thing right because
we don't want to have to repeat a ton of stuff in the barcode spec the VCOM
spec is probably going

Manu Sporny: have quite a number of components that we need to identify and
kind of talk about that we have already pretty much identified in the
architecture section for the BCOM spec. So I don't know what the proper
ordering of operations are to get to an initial horizontal review. I think
if we had all the time in the world, we would create a generalized
verifiable digital credential, threat model and then maybe the VCOM spec
would build on top of that and add all the coordinator components and those
sorts of things.

Manu Sporny: While the barcodes thing, focused on a different part of the
threat model like the issuers and the verifiers, ideally the components
would be able to be pulled into the spec without us having to recreate all
the diagrams. So that's a thought. One is what is the most efficient way
for us to do this without putting an enormous timeline in front of us to
build everything up. let me stop there.

Patrick St-Louis: Yeah,

Joe Andrieu: Yeah,…

Joe Andrieu: I wanted to I think the right order of operations is actually
pick any one of them and make the DFD that works for the hard but necessary
work is going to be synchronizing the different DFDs so that the components
that have the same identifier and description. but for example, render
method has a very different attack surface than confidence method. And so
we both have components that aren't in the other diagram. so the way I'm
approaching with it did work is hey let's look at resolution as a threat
model and then that will teach us something that hopefully we can reuse
elsewhere but the tension is in hey I've got these different diagrams how
do I reuse them and it's a refactoring computer science Tell them.

Manu Sporny: Okay, that makes sense to me. I mean it's basically how we do
terminology between the multiple specs, At some point we realize that we've
defined the same term multiple times and then we pick one spec to put the
actual definition in, export it and then reimpport it from the other spec.
So maybe there's something there that we can build into respect to because
respspec has the auto terminology linking between specs thing and maybe we
do an extension to it to do DFD style linking. okay so that's good. And
then the other thing solves the problem of not having to wait forever for
the other base specs to get a threat model. I think what that means for us
here is we're going to build a threat model for VCOM.

Manu Sporny: it's going to have a tremendous number of components in it
just because this is the first, we have to do it for this spec.

Joe Andrieu: Yep, that sounds right.

Manu Sporny: And then probably the expectation is a good chunk of that is
going to be factored out in the future and put in another spec, but we
don't have to let that hold us up to get started. That's

Ted Thibodeau Jr: Just quickly, I threw this in the chat, but Manu, can you
provide a link to the recording and our minutes for this morning? My local
calendar hadn't updated until after the meeting was over.

Manu Sporny: It will autopublish at 8:00 p.m. Eastern tonight to the
mailing list.

Ted Thibodeau Jr: Okay, I think I'll find Fair enough. Okay.

Manu Sporny: I don't have it yet because, it hasn't done its thing.

Patrick St-Louis: So, is there any action item I should write down out of
this horizontal review? Do we want to make sure we track this with an
issue? I heard something about creating a directory and the VCOM repo I
think to start storing artifacts there. manual.

Manu Sporny: I have raised two issues right when the call was starting. One
of them is to do a horizontal review. So if you go to issues Patrick are
just open issues the two top ones horizontal review for VCOM points to all
the horizontal reviews that we need to request and then the threat model
for VCOM is there as well and I'm using the blocking on the right the
blocked by syntax to say which one needs to happen first and…

Manu Sporny: which one happens second. But basically, we're blocked to do a
horizontal review until we get the threat model done.

Patrick St-Louis: Okay, perfect.

Patrick St-Louis: So we will take a look at this and see how this can fit
in our issue processing schedule. we will probably want to start at least
adding a bit of comments and ideas here to move this forward. this sounds
like it's something we'll want to be done at some point which is sooner
than later. because I have a feeling this review process can take some
time. So perfect. Yes, man.

Manu Sporny: Sorry, one last question. Joe, is Sing working on any respect
extensions to auto extract the table of contents from the threat model? I'm
just trying to figure out a way to just not have to keep the two things in
sync and just add some respect markup that'll just the auto construct the
privacy and…

Manu Sporny: security consideration sections.

Joe Andrieu: Yes, there is.

Joe Andrieu: And the did resolution threat model. I'll drop you a URL. I
think in fact the current main demonstrates it. we have a schema that both
generates the threat model and a TOC and it would probably need to be
teased out to do that separately because I just do it in one render call.
if that makes sense. but there is a way we can get to a data driven thing
that is pulling in the TOC from somewhere else. but we should talk about it.

Joe Andrieu> DID Resolution Threat Model
<https://w3c.github.io/did-resolution-threat-model/>

Joe Andrieu: I think it's not well supported in how I've factored the
library, but one of the things I'm still trying to do is get that library
into a repo so it's standalone so that people like you and others in W3C
can use it. So I would love input as to how we can make it more useful.

Patrick St-Louis: very Any further comments in that case? yes, man.

Manu Sporny: Sorry, I'm asking a bazillion questions because I'm planning
on trying to do something in the next couple of weeks. Joe, I'm looking at
the details in the did resolution threat model and…

Manu Sporny: there's the DFD for all participants or whatever. I'm looking
at have you considered using mermaid to build something there? It can't do
what you currently have in there, but I'm trying to figure out a way to use
mermaid to do the diagram.

Joe Andrieu: Yeah.

Joe Andrieu: Mermaid doesn't do very good DFDs. for a different diagram, we
have done mermaid integration. We've made a custom mermaid handler. that
may be in my future, but it's nowhere near term so right now I am just
importing this thing that part of the challenge is I have a strong
motivation to follow Adam Shawstack's lead in that in your DFD you want a
very limited set of different component types like you care that it's a
processor you don't care that it's a database or a server or a laptop and
so having the simplified view of DFD is we don't have a good tool

Joe Andrieu: that links in the mermaid with that. the other thing I want to
point out as you're looking at that is so these threads are kind of still
just really examples of the functionality. and one of the things you'll see
that is weird because they just reuse the same image and the T1 has the DFD
in it again. That is just to demonstrate that you can put an image in a
threat and it will show up after the description. you're looking at 2.1,
but if you go down to 4.2 threat details, each threat can have its own
diagram if that's useful. And if you don't have it, then we just don't show
that real estate.

Patrick St-Louis: So, do we need to output a document like this or this is
what we're kind of discussing trying to figure it out? do we need a VCOM
threat model spec or repo? Yes. Yes. Yes.

Patrick St-Louis: We need one or yes, we're trying to figure it out.

Manu Sporny: directory. Sorry,…

Manu Sporny: I was agreeing to the first thing and then you said something
else that I disagreed with.

Manu Sporny: I think we should start out with a directory and do all the
development in there until it becomes clear that we need a I'm hoping we
will not need a separate repo. that's

Patrick St-Louis: Okay. Mhm.

Patrick St-Louis: So, different directory with a new index HTML file, maybe
some components and kind of mimic these sections here. yeah I think
probably some decisions to be made what are the stakeholders probably going
to be related to the coordinators and the different components. I think we
already have a security consideration so we could pull out some threads
from there and just expand on it a little bit.

Patrick St-Louis: Okay. It's

Joe Andrieu: Yeah. One of the things this architecture does,…

Joe Andrieu: by the way, if you go to the files, if that's easy to click
over to is there's a directory of threats and each threat is a JavaScript
file. and it's JavaScript, not JSON, so that we can load in a file URL. So
JS common modules and data include do not work for local files. so if you
clone it and open index.html those features Data include fails. but this
sort of JavaScript swizzle lets you get the JSON in as a script tag.

Joe Andrieu: But you just put the different threats in here and then you
update your outline to say where in the document structure do those threats
go. So you can categorize different kinds of threats.

Patrick St-Louis: Something I can definitely do is start to have a look at
this and…

Patrick St-Louis: the layout how it works to have a proposal. probably can
reply here with my findings and…

Patrick St-Louis: try to get this issue in a ready for PR state at some
point. we will probably need some peer review before we do this.

Joe Andrieu: Patrick, if you have me on signal,…

Joe Andrieu: I would be happy to be available if you bump into questions as
you're parsing through that because we implemented this. It's gone through
one refactoring. I'm sure it's not well documented, but I'm happy to help.

Patrick St-Louis: Okay. Yeah,…

Patrick St-Louis: I can definitely look into that. Can add you on Signal,
Slack, whichever is the best.

Joe Andrieu: Yeah, either would work. I prefer signal, but as long as we
have a channel, I'm happy to help.

Patrick St-Louis: Sounds good. I use both on a daily basis. It's not an
issue. perfect. Any other comments, follow-ups on this? I think we are
clear.

Patrick St-Louis: Next step we got review I'm going to link this here out
and create a subdirector for Okay, I will put my face there,…

Joe Andrieu: Yes, that's fine.

Patrick St-Louis: but for now until maybe if someone wants to help at some
point, I'm going to put you as well, Joe. Is that okay? Perfect.

Patrick St-Louis: So this is good big item. so I had two other topics. the
best way to show them will probably be to open a PR. I don't know if these
are related. so this one is a bit more of a pro of a me problem. So I have
a situation with my IPR where my GitHub account was linked to a previous
W3C account. So when I first got introduced to W3C, I was working for
another company and since this was sort of a work related task, I had used
my other company's email. this was many years ago. KDR. The GitHub account
is linked to that email.

Patrick St-Louis: All the emails are linked to the GitHub account. So this
is something I'll probably have to resolve with someone. I will take this
offline. It's really just about linking my W3C account with GitHub. yes,
Manu. No,…

Manu Sporny: Do you still have access to your current GitHub login is not
tied to that old email address. Patrick St-Louis:

Patrick St-Louis: no, no.

Manu Sporny: Is that correct?

Patrick St-Louis: The GitHub my personal is the one I used.

Manu Sporny: Yeah. can you log into your w3.org account?

Patrick St-Louis: That employer at a GitHub organization the W3C is an
email password login and I used my employers at the time email to create my
account since this was my introduction. It seemed like the right thing to
do at the time. in retrospective, I think using my personal email would
have been a better move. but we're my new one. So, I have another one,…

Manu Sporny: All right.

Patrick St-Louis: the one that I have the IPR.

Benjamin Young> There is only Patrick. There is no past-employer.

Manu Sporny: So you need to contact cisre and they will be able to probably
help you.

Manu Sporny: Benjamin, I don't know if there's any other way. So, contact
Avon and…

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: explain what the situation is. He will probably ask you to
contact a system request cis at W3 and…

Manu Sporny: they will manually get your accounts sorted.

Patrick St-Louis: And I mean both email got my full name in them.

Patrick St-Louis: So it's not like the other email with some random name.
So it should be, fairly easy to demonstrate this.

Manu Sporny: You are not the first person this has happened to.

Patrick St-Louis: I'm assuming it seems to Yeah.

Manu Sporny: Yep. Yep.

Patrick St-Louis: So this is that and then my second question. So we used
to have a thing the preview that showed up here on CCG. At least I used to
see it. I'm not seeing it anymore. Is this CCG versus W3C thing or it's
related to my permission? Yes, Manu. Okay.

Manu Sporny: probably not related to your permission. I looked at the
error. It looks like the spec generation tool is having a bad day. you will
want to point Avon at it to see what the issue is. I did look the all W3C
repositories have preview enabled on them automatically.

Manu Sporny: So it is hitting an error with the spec generator service and
so you'll want to point Avon to it. Avon will probably bring up the issue
with CISRE and CISRE will deal with it.

Patrick St-Louis: Okay.

Patrick St-Louis: I can do a followup with this. yes, Joe.

Joe Andrieu: Yeah, I have to flag there are some challenges with the PR
preview in particular.

Joe Andrieu: It doesn't upload other local files. so it actually breaks
sort of this did resolution threat model architecture. I don't know how we
fix it. we've been round and round. We've looked at converting to GitHub
pages. it's a weird thing that Toby set up and it's magical, but it's also
kind of limited. so that's all. Go ahead, man.

Manu Sporny: Yeah, agree. we can always ping Toby like he's around and ask
him what he suggests. I know that I struggled with this for respec oas and
some of the other things and I think you have to put it in the processing
chain …

Manu Sporny: if you do it as a post-processing step it doesn't work but if
you do it as a pre-processing step it does the right thing if I recall
correctly. but you're right it is very brittle. that's

Patrick St-Louis: Okay. …

Kevin Dean: Yeah, Joe and I have had Toby involved with his distortion.
It's not a trivial

Patrick St-Louis: very So, unless there's any objection, we can go through
these PRs. So, the first one was open last week. So, we let it a week to,
get some feedback. So, we should be able to close this today unless there's
objection. These ones we can quickly go over them. But obviously, first
I'll have to fix my IPR situation and we'll probably want to leave them
open at least a week. this is a decision We want to not close PR that have
been open a couple minutes before unless it's a very small sort of typo
type of If it's some kind of substantive change, we want to let people
review them. so let's start by having a look at this one. Yes, Coyote.

Kayode Ezike: Just wanted to remind about the FPWD really quickly before we
continue.

Patrick St-Louis: I'm so sorry, Coyote. I got carried away.

Kayode Ezike: Yeah, no worries.

Patrick St-Louis: Yes, please. talk about the Yeah,…

Kayode Ezike: I'll just be a few minutes. Won't be that long at all.

Patrick St-Louis: thank you for reminding

Kayode Ezike: No worries. so if you recall last week, we made a res
proposal to vote on whether we should move the VCOM to FPW first public
working draft. which is essentially one of the earlier steps in W3C hosting
the VCOM spec. And so after that the following day at the BCWG weekly call
we ran the same vote and everybody agreed that it should move forward. And
so from there basically VCOM and a number of other specs went through the
process of pushing that through. so there's a bunch of process things that
we don't have to get into but the upshot is that Ivon has taken it forward.

Kayode Ezike: So we've produced a link for him which contains the first
draft of the working document which is still hosted on pages but whenever
the right buttons have been pressed behind the scenes it will be moved to I
think a technical report in W3C space and at that point we'll have a public
working draft that folks that is stable for folks to access throughout this
incubation period while we have our own editor's draft that will continue
to host post on the GitHub pages. So I think I'm hoping to hear more about
it in the call tomorrow, but that's just I fight off for everybody who's in
case you weren't in the loop with that.

Patrick St-Louis: So, nothing to be done. We're just waiting on a
confirmation probably tomorrow and we should have a final update next week
if all goes Okay.

Kayode Ezike: Yeah, hopefully I want to

Manu Sporny: To everything Coyote said. what happens next is Avon moves the
documents into place and when Thursday this Thursday hits the bunch of
automation will kick in and the documents will appear in TR space at W3C.
So, the update we'll hear tomorrow is probably just what Coyote said for
all the specs that,…

Manu Sporny: went to FWD and then on Thursday is when they'll appear in TR
space and in all the indexes and all that kind of stuff.

Patrick St-Louis: Very good.

Patrick St-Louis: Thanks a lot for giving us an insight on the timeline
here. Any other comments for the FP WD document? So, let's go over the PRs.
So, we'll have a look at this one which I believe we had talked about
briefly last time. However, we were a bit tight on the schedule last time.
do you want to tell us a part if there's any change has been done since
last week and where are we at for this?

Parth Bhatt: No changes has been done last since last week and yeah it was
just adding redirect URL to the step definitions in the OS file and
similarly adding the text or pros for that in the index html file. That's
it.

Ted Thibodeau Jr> Pull requests · w3c/vcalm · GitHub
<https://github.com/w3c/vcalm/pulls>

Patrick St-Louis: Very good. So it adds a bit a description to redirect Add
the actual property with the type and the string. Looks good to me. it's
been approved. Is there any objection to merging this today? Yes. part.

Parth Bhatt: there is a new PR which basically relates to this I need to
add a not diagram sorry I need to add an example with the actual redirect
URL and walk through the exchange pattern just which explains the use of
redirect URL as an example in the specification. So that there is a
separate issue. I guess 619 I can get the link in here.

Parth Bhatt: But this pair should be ready to go for merge.

Patrick St-Louis: Okay. Yeah,…

Patrick St-Louis: I think we can probably merge this and just treat any
outstanding work as another PR. so we don't drag this one around. if
everyone is okay and there's no objection with this we can merge this and
the related issue which is 619 will be addressed in a separate par. So to
keep the small so we can move them forward and close issues. I see the
description was already talking about IV but we want an actual example
here. So I think this will be very useful. so I see thumbs up from Manu
Dave and Ted. might as well join the gang that will also approve. any
objections to merging this

Patrick St-Louis: Good commit history is clean. So let's rebase and merge
this. We will add a comment here. This has been addressed quick 620 the
script x or indirect URL was added.

Parth Bhatt> Provide example of using `redirectUrl` with an interaction URL
(`?iuv=1`) to demonstrate exchange "chaining" · Issue #619 · w3c/vcalm ·
GitHub <https://github.com/w3c/vcalm/issues/619>

Patrick St-Louis: that with a entry put this in quote close with the
comment. So we have a clean documentation of how this was addressed with
the link to the code. so these three PRs so the selective disclosure I had
to open a new PR. So this used to be the PR before. So I captured the PR
here. all these comments has been addressed. They are included. I had a bit
of a weird situation. this was dating from 2025.

Patrick St-Louis: I tried to rebase and then since the location of the repo
changed, it was a bit of an issue. so I decided to close this one and just
open this new one. It was not a very large PR. this is really to add a sort
of pseudo code for selective disclosure. there's a issue that it reference
so we don't really have pseudo codes. sorry that's not what I wanted to do.
I think this is the one. Yes, sorry. I open the so at I've not seen many
pseudo code in specs, but this is something we decided would be useful.
this is a non-normative pseudo code to give an example that people could
follow.

Patrick St-Louis: So the goal of this PR is just to add this pseudo code in
the relevant section. so this is the converting query example to JSON
pointers section. so I preserve the text that was in the other R. improved
it based on the feedback. what I would like to have is a review from Dave
as if possible since you Dave had raised the issue to see if this meets the
requirement or if we want a separate approach for this. we had discussed
maybe adding a respspec feature to have to support pseudo code bits maybe
collapsible section.

Patrick St-Louis: I did not do that. if we still think this is worthwhile
we can look at this otherwise I think this captures the idea pretty well.
is there any questions any feedback? there's been some things added by Manu
here. yes, man.

Manu Sporny: Yeah, sorry. I was trying to see if we could clear your IPR
things. but ignore those. for typically algorithms written in W3C
specifications are pretty prescriptive in that they're like this is exactly
what you do but as long as you get the same result you can use any other
algorithm you want right this is I think a little different in that it kind

Manu Sporny: tries to suggest that something's an algorithm, but it doesn't
have the specificity that you would normally expect. And then it has pseudo
code under there that is very very specific. the thing at the bottom might
be looks strange to people that are used to reading W3C specs. and the
thing at the top is not specific enough and I think people are going to
raise issues on it. I'm wondering, I mean, this is something that you could
probably point an LLM at and tell them "Hey, convert this stuff into
something that looks like this algorithm in this other spec over here."

Manu Sporny: and it would probably do a pretty decent job as long as you,
really read the algorithm to make sure it's actually doing the right thing.
if we did that for the bottom portion, which is very explicit in what the
algorithm is, then I think we could convert the top algorithm into just a
highle description of what it's doing and not use class equals algorithm
means there are some concrete steps here. Typically there are normative
steps that you want to define.

Manu Sporny: So normally when you define things like this, you want to use
normative language in the algorithm. because otherwise it's kind of like
why are you defining an algorithm that people aren't required to implement
other than get an idea and then it's kind of like if people just get an
idea from that and they implement something differently you can't tell them
that they implemented the wrong thing which is why I use normative language
typically in an algorithm. So the suggestion here is to convert the bottom
thing into an actual algorithm with normative statements on what the
convert query by example to JSON pointer algorithm is and…

Manu Sporny: then go from there. I guess we don't have this somewhere.
Okay, that's it. Sorry, that was a

Patrick St-Louis: …

Patrick St-Louis: I'm just going to review my own PR based on your
comments. this and do we want to transform this into a class algorithm
section?

Manu Sporny: Yeah, let's look at the data integrity spec I think has one
second let me try and find an algorithm in there I'm not saying follow this
exactly but like that there's an algorithm there where it says …

Patrick St-Louis: This is

Manu Sporny: inputs what the expected outputs are and then it runs through
the algorithm has must and should statements.

Manu Sporny: And then all the way at the top there it does say if you go to
this section the algorithm section it says implementers may implement
reasonable defaults and safeguards where's the thing where it says I get
that you're trying to do pseudo code,…

Patrick St-Louis: more like a spec algorithm rather than pseudo code. So I
was trying really to yeah so maybe not Okay.

Manu Sporny: but I like this is gonna sound strong. Yeah, don't do that
because it's not normative and so people can do whatever they want. and
come up with different implementations that are non-interoperable. So I
think we're trying to get something interoperable here.

Manu Sporny: And so we have to very much say if you implement this
algorithm exactly as it is written you will get the right result. yeah.

Manu Sporny> Verifiable Credential Data Integrity 1.1
<https://w3c.github.io/vc-data-integrity/#add-proof>

Patrick St-Louis: Kind of describe this but more in a way that we see on
these algorithms here whether it's the EDDDSA or so on. So, okay.

Manu Sporny: Yeah, exactly.

Manu Sporny> Verifiable Credential Data Integrity 1.1
<https://w3c.github.io/vc-data-integrity/#algorithms>

Patrick St-Louis: Yeah, I can do this. definitely this makes a lot of sense
actually.

Manu Sporny: And you could probably just take that JavaScript.

Patrick St-Louis: Let's see code.

Manu Sporny: I've done this on a couple of other algorithms just to see if
it actually works. just take the JavaScript code, feed it into an LLM, tell
it I want you to generate algorithms that look like this. And it does a
pretty decent job at it. you clearly have to check to make sure it actually
did the right thing, but since you've already written the pseudo code, you
should be able to

Patrick St-Louis: Okay, it's a bit repeating what I've just said. Oops.
Repetition, but I think it covers it pretty good. And then for the top
part, all right. So, kind of remove update this so that it reflects what's
in this code. and then this can probably stay in here. Okay.

Manu Sporny: Yeah. And in fact, the thing that you wrote there at the top,…

Manu Sporny: the just high level, what's the algorithm doing? that's
useful, continue to talk about that. You probably don't want to list it as
class algorithm unless you're very clear that this is just kind of like
what this algorithm does at a high level and then detail this is exactly
what it does. that makes sense.

Patrick St-Louis: Okay, I'm actually going to link to this review for
example with existing I'll go in and…

Patrick St-Louis: So I'm just going to put this here. Perfect. I think
we'll get there. it's going to be on what we're trying to do here? Any
other comments related to selective disclosure? JSON pointers otherwise
let's try to get the time is flying by. So this is probably what you were
mentioning. So there's a bit an error.

Patrick St-Louis: So I'll try to see if there's anything I can do with
this. but for the PR itself, so this one was to define this term called
index allocator, which we sort of had in the spec, but it's not in the
bitstring status list specification. It's not really something that's
defined. It's just something that's been appearing in different codes and
it's the important component. So this PR is to provide a small description
for this field and just make it so that when someone reads the spec and
they see index allocator they can understand a little bit more what it's
used for. so when they actually implement it they know what to do with it.

Patrick St-Louis: So it adds a small bit of descriptive text and a OAS
field with small description field. So I will go approve this. is there any
questions relating to this reminder I will be let it open for the whole
week so people can have a look and make sure that this matches their
implementation. Very good. the last one did I

Patrick St-Louis: put it quickly before two. So, yeah. Okay, I'll need to
see what's happening here. so the same thing, we wanted a non-normative
workflow processing algorithm. So, I'm going to go out on a limb and assume
a lot of the feedback that was just given to me regarding the other PR will
also apply here. so I will probably need to review this. but the general
idea is to define an algorithm to process a step in a workflow and to
process a workflow as a whole. So we define the workflows, we define the
endpoints to create them and we explain a little bit how to implement them.
However, there's no actual normative algorithm for them. so this is an
attempt to do this.

Patrick St-Louis: So I will take the time to review this based on the
feedback that was received on the other PR and try to make both this
algorithm and the other one for the selector disclosure a bit consistent.
any other comments I should keep in mind while reviewing this? Yes, Manu.

Manu Sporny: Yeah, a plus one. this is a question. do we want this to be a
normative algorithm? is that what the issue was about? if it's informative,
it's kind of different, right? Okay.

Patrick St-Louis: It says non-normative. So, I think we probably need to
Let's see if there was a bit of any experience to give people non-normative.

Manu Sporny: Yeah, this one's a little different…

Manu Sporny: because it's non-normative. Do we expect the other one to be
normative? what was the other issue?

Patrick St-Louis: …

Manu Sporny: mountain. Yeah.

Patrick St-Louis: and I'm going to go hunt it down Here. What do we say? We
want to add it. I feel like these are nonnormative. especially with
workflows people might do proprietary operations like a step in a workflow
might trigger some business action on their side. so not too sure. Yes.

Manu Sporny: I guess here's my concern, Patrick. I'm concerned that you're
going to put in all this work to write a very complete, concrete normative
algorithm and then somebody's going to come along later and basically be
like, "That shouldn't be normative." I'm not going to do that in my
implementation. I'm going to do something else significantly different. And
then they're going to argue that both of the algorithms should be
non-normative and then we have to go and update all the language to go from
musts and shoulds to saying it in a different way.

Manu Sporny: I don't have enough of this in my head to suggest whether or
not what we should do here. but I am concerned about the amount of time
that you're going to spend converting it into, this new language only for
us to then throw it out later. potentially.

Patrick St-Louis: Yes, I think it's a valid concern. I'm not too sure. It
seems if we still want to address these issues, we'll need to put something
in. unless we say we decide we don't want this, we'll need to put something
else. It seemed like the most guaranteed way to avoid work later is to make
it non-normative. then this raised the question if there's a purpose for
this. Patrick St-Louis:

Manu Sporny: Yeah, because I mean…

Manu Sporny: if it's like why are we spending all the time to write down
what somebody might do in the specification when it has nothing to do with
interoperability. It's just like trying to give people an idea of how they
might implement it. It's language that typically goes in an implementation
guide. if it is non-normative, the thing that would Yeah,…

Patrick St-Louis: Mhm. Yes.

Manu Sporny: We need to see if other people in the group have strong
opinions on whether or not they should be normative or non-normative before
you put in the work. I think Patrick, because otherwise

Patrick St-Louis: Let me put this in a draft and…

Patrick St-Louis: we can so we're coming at the hour but we can review this
next week and decide how we want to move forward with this. I'm also
thinking I know speaking about Nate was showing an actual implementers
guide for these workflows. I forgot what was the name of the organization
but they had specific profile and maybe these kind of algorithms they
belong more in these sort of secondary artifact. yes, Nate.

Nate Otto: Yeah, sorry I didn't realize the time was so short. just
briefly, we did mention as you're saying the possibility of having
different performance profiles where workflow processing would be normative
but would be a different layer. that is optional and that the test suites
would measure them independently and…

Nate Otto: I'm fine with that option. I would certainly shy away from
making them normative and required for implementers of the sort of any base
certification

Patrick St-Louis: I think we can be normative and…

Patrick St-Louis: what should be the outcome of a workflow whether it's
completed or failed but processing the workflow maybe makes a bit less
sense and if we are normative about the outcomes and we can test that two
implementation they can go through a workflow and both implementation are
in a happy state at the end. that might be sufficient to say we have
interoperability.

Patrick St-Louis: for the selective disclosure one. I put the wrong one out
of the draft. For the selective disclosure one, this is a bit different. I
think we can discuss this a bit more. so with that being said, I think
we'll have more discussion for this next time. We are at the hour, so I
will end the meeting now in case people have other places to go. thank you
for your time on this call and we'll see each other in a week. Meeting
ended after 01:00:40 👋 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).