[MINUTES] CCG VCALM 2025-12-16

CCG VCALM Meeting Summary - 2025/12/16

*Date:* 2025/12/16 *Time:* 14:58 EST *Attendees:* Benjamin Young, Dave
Longley, Elaine Wooton, Eric Schuh, Joe Andrieu, John's Notetaker, Kayode
Ezike, Manu Sporny, Patrick St-Louis, Ted Thibodeau Jr
Meeting Summary

This was the last VCALM meeting of 2025, with a focus on reviewing open
Pull Requests (PRs) related to verifiable presentation requests, selective
disclosure, and revocation lists. The meeting also included a community
update regarding the Verifiable Credential Working Group charter.
Topics Covered:

   - *VC WG Charter Public Review:* Manu Sporny provided an update on the
   Verifiable Credential Working Group charter being under public review. VCOM
   is explicitly listed as a deliverable. The charter is expected to be
   approved by mid-February 2026.
   - *Selective Disclosure with Query by Example (PR #570):* This PR adds
   descriptive text to the VCOM specification explaining how selective
   disclosure works with Query by Example (QBE). It clarifies that QBE
   requests all fields, and the requestor should only request fields they are
   interested in. The PR also addresses requesting a field without caring
   about the value by using an empty string.
   - *Query by Example as an Object (PR #573):* This PR addresses an issue
   where QBE was incorrectly described as an array. It clarifies that QBE is
   an object and adds text to explain logical operations.
   - *Normative Algorithm for Query by Example:* Discussions arose around
   defining a normative algorithm for QBE. This includes considering how to
   map QBE to JSON pointers and whether to express the algorithm in a specific
   language like JavaScript, or using a more traditional W3C specification
   style with algorithm steps. The need for "must" and "should" statements was
   highlighted.
   - *Hosting Revocation Lists (Issue #555):* The discussion focused on
   providing guidance for hosting revocation lists. The approach taken in the
   current PR is to offer non-normative endpoints and recommendations,
   acknowledging that revocation management can vary. There was a discussion
   about potentially making this guidance normative with a "should" statement,
   especially if implementations of bitstring status lists emerge.

Key Points Made:

   - The VCOM specification is a deliverable within the Verifiable
   Credential Working Group charter, which is currently under public review.
   - When using Query by Example for selective disclosure, requestors
   should only request the fields they need.
   - There is a need for a normative algorithm to define how to process
   Query by Example requests, including potential mapping to JSON pointers.
   - The format for expressing algorithms in W3C specifications was
   debated, with considerations for clarity, implementer ease of use, and the
   ability to include normative "must" and "should" statements.
   - Providing non-normative guidance on hosting revocation lists within
   the VCOM specification can be beneficial for implementers, even if not all
   aspects are mandated.
   - The next three VCALM meetings (Dec 30th, Jan 6th, Jan 13th) will be
   cancelled due to the holidays. The next meeting will be on January 13th,
   2026.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-12-16.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-12-16.mp4
*CCG VCALM - 2025/12/16 14:58 EST - Transcript* *Attendees*

Benjamin Young, Dave Longley, Elaine Wooton, Eric Schuh, Joe Andrieu,
John's Notetaker, Kayode Ezike, Manu Sporny, Patrick St-Louis, Ted
Thibodeau Jr
*Transcript*

Patrick St-Louis: Hey, Drew.

Joe Andrieu: Hey, how's it going, Patrick? Yeah.

Patrick St-Louis: Pretty good. Feeling, getting into the holiday spirit.

Joe Andrieu: You have a Christmas tree up?

Patrick St-Louis: I actually bought a very tiny one yesterday at the
grocery store. They saw these little kits two feet tall and…

Joe Andrieu: Uh-huh. Sure.

Patrick St-Louis: a few lights, a little kit, put it on and…

Joe Andrieu: I had one like that for a while when I was just out of college.

Patrick St-Louis: it survived my cat so far. So yeah,…

Joe Andrieu: It's always a challenge. Yeah, we got ours up this weekend.

Patrick St-Louis: nice. Hello.

Joe Andrieu: How Ted

Ted Thibodeau Jr: Good day, folks.

Patrick St-Louis: Just wait a couple minutes before we get started.

Patrick St-Louis: welcome Eric Manuf I'll give it one more minute and
People are starting to trickle in.

Patrick St-Louis: All right, let me set up my Windows. Going to start
sharing and then get going. Okay, hopefully everyone can see my screen. If
you want the fonts to be a bit larger, please just let me know. So, welcome
everybody to this weekly VCOM meeting at the CCG. This will be the last
meeting of 2025.

Patrick St-Louis: So we can maybe take a few minute at the end if we want
to sort of do a sum up of everything we've added in the specification this
year. There's been quite a bit of movement across various specification
that all apply to the VCOM. So the meeting is recorded and transcribed.
this is a W3C credential community group meeting. So all policies are in
effect. we have a fairly straightforward agenda today. I see there are a
few PRs open. So hopefully we'll be able to go through most of them.
00:05:00

Patrick St-Louis: before we get started would like to open the floor if
anyone wants to reintroduction, provide a community update or a new item
they want to propose for the agenda. yes, Manu

Manu Sporny: Just a community update. the verifiable credential working
group charter is now officially under public review. let me go ahead and
kind of share that charter here. so it's an official W3C the verifiable
credential working group agreed to send it out for official review. it will
remain in review until mid January I think and then it goes out for an
official vote. the vote typically takes 30 days. and it's everything that
we expect to be in there is in there.

Manu Sporny: no surprises and then VCOM is listed here as a deliverable in
the charter. And so if everything goes according to plan, what typically
happens at this point is here's the charter repository. you can raise
issues and pull requests against the charter. Anybody I forget. I mean then
they basically listen to everybody's input whether you're a W3C member or
not. and then there might be a cycle of fixing charter issues and then once
all the review stuff is done it'll go out for an official vote. and then
members can have a kind of a input on it a vote and say yes they agree with
the charter. Yes, they agree with it as long as these changes are made.

Manu Sporny: yes, they agree with it and suggest some changes or they can
formally object unless changes are made or just formally object entirely to
the charter. So that would happen towards the end of January. but we've
circulated this charter pretty extensively already. So we're not expecting
a bunch of changes and the working group's already in favor of moving
forward with this. so it's out there. Just wanted everyone to know that
VCOM's in scope as well. If everything goes according to plan by
midFebruary the charter would be approved and then the charter start date
is April April 2026 and then the charter is for two years.

Manu Sporny: And it has a ton of other deliverables. not just VCOM,…

Manu Sporny: but a ton of other stuff is in scope. And so, as much will get
done as we have volunteers and editors to get things done. That's it. Back
over to you, Patrick.

Patrick St-Louis: yeah just a small question.

Patrick St-Louis: So I see there's different expected completion. I'm
assuming the completion date took into account other of these work item
like we want to work on all of these together so they're seen as one work
stream.

Patrick St-Louis: Is that why we see different completion date or is just
because it was assumed that the VCOM is a bit more complicated and would
take more time or it's more to prioritize the order of the ones we want to
finish first.

Manu Sporny: It's a kind of a mix of all those.

Manu Sporny: So the shorter dates are for the things that the working
group's already working on and expects to finish up sooner than later
render method and confidence method. and then VCOM and the rest of the
specifications are set to the very end of the charter. it doesn't mean we
could finish those early. There's nothing to prevent us from doing that.
But they're basically saying at the very least these specifications will be
completed, by the dates they specify.

Manu Sporny: But really the dates are just like an expectation to set
expectations with the membership and not what it might take longer it might
take shorter and…

Manu Sporny: there's no penalty for either one of those things unless we go
beyond the end of the charter at which point we kind of get in trouble.
00:10:00

Patrick St-Louis: interesting. And…

Patrick St-Louis: what about the maintenance specification? Are these as
high as priorities?

Manu Sporny: No, those are lower priority. that basically is verifiable
credential 21. these are these specifications we're expected to not really
add new features to unless there are security issues or privacy issues or
we need to add a new feature to support some of the other more active
specifications.

Patrick St-Louis: Yeah.

Manu Sporny: So it's a usually groups do that to make sure a new group of
people can't come in and delete half the specification, that's not the
expectation, the whole reason to have global standards and to ensure this
kind of stability is so that people can build on it over years. And so the
maintenance specifications are basically communicating to the broader world
that we are going to keep maintaining these things and making sure that
they continue to be secure and privacy aware and…

Manu Sporny: all that kind of stuff but we do not expect any major changes
to these specifications. They'll be point releases basically.

Patrick St-Louis: And final question around this.

Patrick St-Louis: So let's say completion 20 or the end of the charter
comes around and there was no change whatsoever that were made. I is 2.1
going to become the new recommendation that will be encouraged to upgrade
or…

Patrick St-Louis: will 2.0 know still be a Right.

Manu Sporny: I…

Manu Sporny: if they're literally zero changes or the editorial changes are
so minor we just don't want to deal with it then we would not publish a
point release we just basically say what 20 was good enough as it was and
that's fine like that said there will be passive editorial changes for data
integrity in the crypto suites I think we're trying to consolidate the
selective disclosure algorithms into the core data integrity spec and…

Manu Sporny: that'll require a bunch of moving around of text and that will
result in data integrity and…

Patrick St-Louis: Yeah, because I'm thinking for the 1.1 that was very much…

Manu Sporny: probably all the crypto suites needing an update I didn't
quite follow that the basically yes…

Patrick St-Louis: what was recommended and in my experience 1. I've never
seen it mentioned anywhere. So I was just wondering if this will be a
similar outcome. Yeah.

Manu Sporny: what you're saying is if we publish dot versions like 2.1 or
1.1 are we going to tell people to upgrade and I think the answer is yes
we're going to tell people to upgrade primarily because If it is a
maintenance specification,

Manu Sporny: we should not have made any major changes. it should be easy
for people to just effectively do nothing and upgrade or the biggest thing
they should probably have to do is just add a 21 context, right? It's
instead of a v2 context,…

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: it's a v2.1 context and that's kind of it. There might be some
details where impleers have to pass a couple more tests. but it shouldn't
be a huge amount of work.

Patrick St-Louis: Very good. Okay, that answers my question. was there any
more questions from the group on that topic?

Manu Sporny: Nope. It's just interview.

Patrick St-Louis: If not, then we can return to the agenda. any other
community updates or introduction that people would like to share?

Patrick St-Louis: In that case, we're going to get started with PR reviews.
let me open the VCOM spec. So there were four ERS that were open. I've
opened a few of them. Two of them are fairly small. the one about status
loose. I'm expecting it to require a little bit more peer review and
discussion. so let's start with the first one here which is about detailing
how selective disclosure works with query by example.

Patrick St-Louis: Let's quickly have a look at the issue and then I can
maybe let you Eric talk us through this PR and…

Patrick St-Louis: maybe refresh us a little bit on the issue. Please go
ahead.

Eric Schuh: Sure.

Eric Schuh: Did you want me to yeah. So this was a discussion that we had I
guess quite a long time ago but this issue was discussed and effectively it
resulted in this note that a PR should be raised at a note about how by
example enables selective disclosure which Dave kind of gave a couple of
different examples of and primarily this note just adds the language to
explain that in query by example there are no optional values that are
requested. All values that you see are required to be responded to. the
language ended up being I think fairly simple and Dave had a good
improvement I think already added in.
00:15:00

Eric Schuh: yeah it effectively I guess just says that to make use of
selective disclosure as the requesttor you should simply request only the
fields that you are interested in and nothing more and then it is up to the
wallet to respect that request and then also inform the user of any data
that is going to be sent beyond what is requested or effectively just to
make clear to the user what data they are sending.

Eric Schuh: so the note tries to add a recommendation that anyone using
bird by example as a requesttor should just be careful and only request the
fields that they require for their use case. And I think that's it.

Eric Schuh: I did forget one thing. as part of this note, I also included
part of the conversation between Patrick and Dave that was in the comment
on the issue about how you request a field when you don't care about the
value that is returned. so you'll see this second paragraph here gives an
example that we use that to request a first name without a value you can
just submit an empty string in the query by example. and then that this
indicates that any value can be returned and you're not looking for
anything in particular.

Patrick St-Louis: Sorry, I was talking with my mic turned off. I've been
responding this whole time. yes, Dave, please go ahead.

Dave Longley: I was going to mention that I think this is a good start for
explaining the details of query by example, but probably insufficient for
an implementer to know how to construct a query. And I don't know if we
wanted that in this or if we're just trying to respond to the required
versus optional fields. And if that's true, I think this is sufficient to
respond to that. But we probably want to say a little bit more in…

Dave Longley: how to craft queries and so on.

Patrick St-Louis: I would suggest to merge this and…

Patrick St-Louis: I don't know if we want to add more to this issue or open
a new issue to say that more concrete example and guidance for implementers
could be useful. okay.

Manu Sporny: That's fine. God.

Dave Longley: We do have some other issues.

Dave Longley: Sorry. I thought I got in the queue before Monu. I'll just be
quick. We do have some other issues around mapping things to JSON pointers
and mapping things to other query languages. And we might just fold that
into those other places and provide examples and some pseudo code there to
help people understand the processing.

Manu Sporny: Yeah, I agree let's merge this we will need a full algorithm
definition for…

Patrick St-Louis: Okay. Come on.

Manu Sporny: how you do query by that's where I think all the normative
text. So if folks are saying what's the algorithm I don't think it's
defined yet and we'll need to define an algorithm for it to be complete
which means that then this would be kind of a note to people which is
totally fine to just kind of help people understand in the pros this is
effectively how you do it and then the algorithm is very explicit about
that said I don't know if we have anything tracking the matching algorithm
for query by example. I'm Look at issues.
00:20:00

Manu Sporny:

Patrick St-Louis: Yeah, we could I know I open a PR for this question of
mapping.

Patrick St-Louis: So we can have a look at that and then decide if we want
I would just open an issue about specifically requiring a normative
algorithm. seems to be what we want here.

Manu Sporny: Yep. Do you want me to open that issue or are you gonna I'm
happy to do

Patrick St-Louis: Yeah. Yeah, Go ahead. Yeah.

Patrick St-Louis: I will link the new issue here and close this with that.
okay, let's merge this. it's just going to go through D means that when
using a query. Yes, this looks right. Look here. Yeah.

Ted Thibodeau Jr: Yeah, sorry. I just review it now.

Patrick St-Louis: That's fine.

Patrick St-Louis: Do you mind Eric going through these comments and
connecting them while we look at another PR and we'll come close it once
it's done.

Eric Schuh: Can't do

Patrick St-Louis: Thank you. All Let's have a look next one. So we'll make
sure to close this merge this before the end of the call. okay, this one is
going to be very simple. So the issue was just really about query by
example needing to be an object, not an array.

Patrick St-Louis: itself which is does that and adds a little bit of text
just to explain the logical operations. we'll probably need a second pair
of eyes to read this and see if this is clear enough or if we want to add
more to this text. Otherwise the example change was very simple. It's
removing an array to an object. Is there a comment? Someone can provide
feedback on I don't see the text here.

Patrick St-Louis: David added a section. Yes, Mario Okay,…

Manu Sporny: Yeah, I mean the base of the PR looks fine to me. I'm making
some editorial suggestions. I think it's fine to have the pros in there. I
think that's good. but we need to define the normative algorithm and we now
have an issue to do that which is issue 574 and I'll link to that but
that's it as far as my input so Of course.

Dave Longley: I'm just on the queue to say that I approved the PR. It
looked like it did what we wanted it to do.

Patrick St-Louis: thank you for mentioning so

Patrick St-Louis: Let's come this so all these PR seems to be really
related to creating a verifiable presentation request and we just want to
add a more normative algorithm for this which probably the next few hours
we'll review which is about mapping and things of the sort will provide a
lot of things to consider in
00:25:00

Patrick St-Louis: there thinking when we talk about an algorithm to create
these do we have a specific query language in mind we is query by example
the one we want to include in the spec and then instruct have a sort of a
mapping part of this normative algorithm or how will this mapping kind of
fit in the picture Yes, Dave.

Dave Longley: Yeah, on that new issue that Monu just filed 574, I put some
links to some open source code that includes matching against a map of JSON
pointers. And that map of JSON pointers can be generated from a query by
example. I also put a link in there for that. It can also be generated from
DAWL. So it's sort of like a common abstract representation of a query that
you can use and then you can run matching on that abstraction. And we might
want to define it that way in the spec so people can see that you can
translate between query languages.

Patrick St-Louis: I'm wondering this translation is it something that we
absolutely want people to implement? I feel if someone doesn't have use
case for black hole for example should this still be a requirement of the
spec that implementations are able to do this? Yeah. Yeah. Okay.

Dave Longley: So I think the way that we'll probably want to express this
in an algorithm is the query by example is going to be expressed in JSON.
We're going to want to consume that and turn it into common standard
tooling anyway like JSON pointer. So just naturally the way that we would
write up how to process a query by example lends itself to this translation.

Dave Longley: People don't have to do that translation but the processing
is consume the JSON create a map of JSON pointers and then use those JSON
pointers to find your data. So it just sort of naturally lends itself to

Patrick St-Louis: Okay.

Patrick St-Louis: Thank you for adding that comment. I'm going to go ahead
and merge unless there's any objections. It's been merged. Let's delete the
branch. Perfect. so this was a very simple issue. I think we can also close
this issue.

Patrick St-Louis: Okay, let's just review the first PR

Manu Sporny: Hey Patrick, one thing. I think when we close issues and there
was a PR, what I like to do is say PR exists. because usually way down the
line when W3C asks us "Hey, did people write in and did you actually
address their concerns?" I scan by R exists. to see if we actually
addressed, the concern and so that we can basically be like, "Yeah, we did
listen to public commentary and we did respond to it and that sort of
thing." So just a little minor process thing.

Manu Sporny: If we're going to Yeah,…

Patrick St-Louis: Okay, this …

Manu Sporny: And I usually do that when the PR is raised to say there's a
PR exists so we can close it later. Yeah, That's correct. Exactly. Yep.
Yeah.

Dave Longley: Yeah. So it looks like Mono,…

Dave Longley: you already added a tag for it. So when you say PR exists,
you're referring to a label and you just added that now and so it's there
now. So that's the process.

Patrick St-Louis: this is what we're talking about. not linking the PR here.

Manu Sporny: Sorry. Yeah.

Patrick St-Louis: Okay. Yeah.

Manu Sporny: I mean, I guess both I don't know how to query for the other
one, I mean, I know how to just search for all PR exists ones and basically
say, "Yep, these are the changes that we made as a result of public input.
I don't know how to search for the closed as completed things." Anyway,…

Patrick St-Louis: We can see it here. and we can see Yeah.

Manu Sporny: yeah, but you as an editor will need to generate a report to
W3C management saying here is the disposition of comments. and we have to
very clearly say these are the comments that we did not respond to and
these are the comments that we did respond to. that sort of thing.
00:30:00

Patrick St-Louis: So to conclude adding this label exists is sufficient.

Manu Sporny: Yes, Benjamin also said there's this other way that we can do
it,…

Manu Sporny: but we need to be consistent, Because if we're not consistent,
we all of a sudden make the editor's lives more difficult. This is what
we've been doing in other working groups. So, we can do something
different, but it would change the way we're doing it mid-flight, which I
would suggest is not something we want to do.

Patrick St-Louis: Cool.

Manu Sporny: And the reason we don't autolink to PRs is because sometimes
then it autoc closes issues when we merge PRs and sometimes when we process
PRs we don't fully address the issue.

Manu Sporny: And so we've had it in the past where we've autoclosed issues
and gone all the way to candidate wreck and then the people complain that
their issue was closed without it being addressed. So we try to Mhm.

Patrick St-Louis: Yeah, it was halfway addressed and…

Patrick St-Louis: then it got lost. Yeah, I could see that happening.

Manu Sporny: Exactly. Yep.

Patrick St-Louis: Okay, so I'll make sure to put the appropriate labels
when a PR is raised. or the person who's assigned can put a label on the
issue as long as we ensure there's a label is there. Thank you. I want to
review this to see if it's ready to be merged. R exists. The label is
there. Very good.

Patrick St-Louis: All the edits have been Any objection to merging 570
which adds descriptive text about selective disclosure. what I will do is
I'm going to link the new issue created here about the algorithms later to
normally

Patrick St-Louis: Do it and I will close this issue. So, this one that's on
the Okay, we'll need to have a look how this looks. So, the issue for this
one

Patrick St-Louis: PR exists. So we wanted some pseudo code with some
instructions of what mapping would look like or at least expressing a query
by example as a set of JSON pointers. So this seems like it's a start to
the algorithm discussion we were talking about. maybe this PR could just be
about providing examples and some pseudo code and have a normative
algorithm if we decide need be in a subsequent PR and then there was this
library that was pointed

Patrick St-Louis: there's a converting to JSON pointers. Let's just have a
quick look how this got rendered out. I'm not sure how to display pseudo
code on here. this may not be ideal. we might want to remove this example
instead favor a normative algorithm and follow examples of other
specification. Yes, Manu
00:35:00

Manu Sporny: Yeah, there's a way to do this in W3C spec land that some
subset of people really don't like, but has gotten us all the way through
Rex. So, we should try to figure out…

Manu Sporny: what style we're going to use in the specification. to Let me
try and Yeah. Mhm.

Patrick St-Louis: Is there another specification we can think of that has …

Patrick St-Louis: because there's definitely algorithms like the most
extensive one I can think of is the ECDSA crypto suite with the selective
disclosure section.

Manu Sporny: Definitely. But there's also data integrity has simpler
sections. Let me share the kind of link there in chat channel if you want
to pull that up. and this is an example of one way to do it. I think
collectively we don't love this. we have gotten through wreck it this
approach. Basically the intro paragraph says this is what the algorithm
does. Here are the inputs.

Manu Sporny: here are the outputs and…

Manu Sporny: then here's the algorithm and then you use very specific
respspec markup you should be able to click on crypto suite there or create
proof or something and it'll highlight …

Patrick St-Louis: Yep. Yeah.

Manu Sporny: if you go above the italicized things you should be able to
click on and then it'll highlight except there's a bug in that paragraph if
you click it it won't highlight below but in the algorithm it'll if you
click proof up a bit up one sentence let yeah click that. See there that
will show you…

Patrick St-Louis: Interesting.

Manu Sporny: where that variable is used throughout the entire algorithm.
so that is how you're quote unquote supposed to do it. But I think Dave
you're like this is a pain.

Manu Sporny: It would be better if we went at this a different way. Mhm.

Patrick St-Louis: I can say as an implementtor I found these little
algorithms very useful.

Patrick St-Louis: You can comment to them in your code link and it can help
you give names to your variables and make sure that it's easy for someone
new coming in to understand what's going on and read the specs side by
side. but that's just my experience. So yes, save.

Dave Longley: So, to be clear, the suggestion isn't to remove linkable
things and items in order to try and improve this. It's to make it be a
little bit more functional seeming. So, it's a little more clear and pseudo
code what's happening. we'll have to figure out exactly how to do that in a
clean way,…

Dave Longley: but it also makes it easier for you to compositionally put
different things together. So, it's more obvious versus a line that says
now call the algorithm with these parameters and these inputs and these
options and get the output of that and do this that's a little harder to
read. so the goal is to …

Patrick St-Louis: So this seems like maybe information that we could add to
that new issue about algorithm to also include that we want to think about
just a better way to express these algorithm and…

Dave Longley: if you take some of the newest IETF specs that have may do a
better job with this for HP K hybrid public key encryption. They've tried
to come up with better ways to express this stuff for implementers. and I
think we're looking for something like

Patrick St-Louis: use that issue to put that into practice. not sure if it
was captured already.

Patrick St-Louis: Yes, mate.

Manu Sporny: I'm wondering if we can get away with just defining it in
JavaScript, which is what just about any developer can read JavaScript
these days. and I'm wondering if we can basically, be like, here's the
exact algorithm that you need to implement. it's a function. you look at
the JavaScript and you're like, yep, that's JavaScript. And then we could
comment, the code lines and in theory, you should be able to copy and paste
it and run it and it's fine, right?

Manu Sporny: I think maybe other people in other languages might get
annoyed if you're implementing in Java or Python and you end up using some
JavaScript feature that is idiomatic to JavaScript and not easily to the
other languages maybe people get concerned.
00:40:00

Manu Sporny: But I'm wondering…

Patrick St-Louis: Okay. …

Manu Sporny: if we can make the normative implementation literally copy
paste out of the source code.

Patrick St-Louis: I would go out on a limb like I've seen in a lot of
documentation. And I don't know if respect support this but you have
different little tabs with different language and I think translating from
one language to another I think in this day and age can be done very easily
with online tooling. I just don't know if the spec text here supports this
right so's your JavaScript algorithm here's the same in Python and so on.

Patrick St-Louis: I don't know if that would add too much work or I'm not
support every single language under the sun but the more popular one I'm
thinking like Python or maybe even Rust in some cases go Yeah,…

Manu Sporny: Yeah, I mean what Benjamin said, I mean this is a job for AI.
the big concern though is that you have to define a normative algorithm
there has to be a source of truth and then the question is what is the
source of truth?

Patrick St-Louis: this is

Manu Sporny: So the source of truth to date has been what we're looking at
on the screen. And I'm suggesting maybe we switch the source of truth to
the JavaScript implementation. We can always add a respspec feature that
will rewrite the code for each one of the tabs or just something like that.
so that's possible.

Patrick St-Louis: Yeah.

Manu Sporny: I just don't know because I don't know of any spec that has
done this right. So we would be wandering into we are now the experiment
which we can do I just don't know if I don't and I don't know if that is
going to be more useful to people than documenting in the way that it
currently is because the way it's currently documented it's pretty handwavy
and…

Manu Sporny: it gives implementers pretty broad ability to kind of
interpret the statements as long as they get the right output. and really
what impleers test against are the implementations. And that's,…

Patrick St-Louis: But yeah,…

Manu Sporny: that can be clear that ends up being super clear because we'll
have bugs in the spec algorithms for years that nobody catches because all
the implementers were just running against the test suite to see if they
pass, right?

Patrick St-Louis: what one thing I can say having it it's better than just
a copy and paste I kind of don't like this idea that you just copy and
paste it and you're done with it. I think having this text at least you
need to read it and understand a little bit what it does. but I'm also not
that opposed to just having a JavaScript snippet.

Patrick St-Louis: Is this something we want to maybe do a discussion a
decision right now and document that decision on the issue? Yeah, man. I
know.

Manu Sporny: we would need to clear it with the verifiable credential
working group because they're the ones that are eventually going to have to
deal with our decision here, I do think that maybe I mean I can imagine a
respspec extension that shows this algorithm that we're looking at right
now and then you click on the tab and see the JavaScript translation of it.

Patrick St-Louis: That would be a very nice feature. Yeah.

Manu Sporny: Yeah I mean it's more work for the editors is the only
problem. All right. and it is possible. I have tried this experiment where
you look at JavaScript code and you tell some AI LLM that's good with code
to write it like a W3C algorithm.

Manu Sporny: What it produces is I mean yeah there's plenty of problems
with what it produces but then the editor can go through and kind of work
on it.

Patrick St-Louis: Is it good?

Patrick St-Louis: Yeah, it's good. Yeah.

Manu Sporny: So again if we go that route it is just more pain for the
editors. we might be better off in the long run. I'm on the fence about,…

Patrick St-Louis: and I'm also thinking about this other thing we have big
requirement for normative statement right and…

Manu Sporny:

Patrick St-Louis: this can allow to put some of these right you can put
some must and some should as if we just have a JavaScript snippet then it's
implement this and that's it like there's no u it hard to show what's
optional and what not so that could be something to consider Yes.
00:45:00

Manu Sporny: Yeah, I think that's an excellent point and that is pushing me
towards not specifying the JavaScript code because we will not have any of
the shoot statements in there. Yep.

Patrick St-Louis: You can put it as common but it's not the same as having
these

Manu Sporny:

Manu Sporny: Yep. Yep.

Patrick St-Louis: Okay.

Patrick St-Louis: So let's do a thing like this and maybe we can have of an
of an enhancement feature of having a code snippet generator feature if we
ever get to it. But at the same time I feel like that's not really a VCOM
thing. That's more a spec tool thing. all right.

Patrick St-Louis: So, I think we can settle to have a little algorithm very
similar to the one that exists and have been working so far. Yeah, manu

Manu Sporny: Yeah, I mean plus one to that.

Manu Sporny: Dave, can you think of I mean this doesn't address the concern
that you have is my only remaining concern and I'm trying to figure out
what we could change with the current approach that would be closer to the
ITF specs that you're saying are doing a better

Patrick St-Louis: What?

Dave Longley: If we're going to decide to at some point maybe do JavaScript
pseudo code instead, then it's not helpful to do yet another being mi sort
of in between that we already did in the data integrity specs I think we
defined a functional interface to it's not a normative functional interface
you can do whatever you want…

Patrick St-Louis: Yeah.

Dave Longley: but there needed to be a way to express that you're calling
another algorithm from when you want to combine things together. So I just
want this to be easier for impleers. and I want it to be easier to reuse
things. And a big part of what went on with the data integrity work was
there were a lot of algorithms and sort of subutilities that could be
reused across specs and…

Dave Longley: with this approach it was hard to accomplish that. So, …

Patrick St-Louis: another yeah to add to…

Dave Longley: maybe we'll see how shakes out in the data integrity work.

Patrick St-Louis: what I was saying earlier that as an implementator this
was useful I also want to add it was not only useful for me but also for
people that reviewed the PR I'm attending these calls I know data integrity
but some of my colleagues

Patrick St-Louis: colleagues they are devops they are working on other
thing and they know what a verifiable credential is but they don't have a
deep understanding of all the different algorithms and if in the code and
the PR I can link to this proof here and they can really read this line by
line it make their lives a lot easier as opposed to if we're just a snippet
of code it's a bit more like a different implementation, especially if it's
a different language. but I'll just to say this is in my experience
definitely useful. it's not a disaster. Okay.

Patrick St-Louis: with that being said, I think I will rework this. even
wondering if this should just be solved by putting an algorithm. this talks
about an example, but this example could just be joined with the algorithm.
so what I'm probably going to end up doing is reworking this PR to provide
a clear algorithm with at least this conversion step and we can then go
from there. because not that great. there's a few comments.

Patrick St-Louis: Yeah. does that sound like a reasonable solution? So,
just wait, not merge this PR, but try to implement a more streamlined
algorithm that's similar to the other ones. The last one I'd like us to
discuss. So I'll put this L Discuss this crawl. We'll need to review the
00:50:00

Patrick St-Louis: I'm going to also link the other issue here. Oops. 574.
we have four minutes left. I wanted to discuss this one.

Patrick St-Louis: so this was an issue that was open a while ago and we
have discussed this many times and it was about the API defining how to
host revocation list which was then changed into providing instruction in
how to create a revocation list. So there was a lot of discussions. the
last state or status update was to have documentation on how to get a list
and get a status. So the way I've approached this and this PR was to
provide non-normative endpoints and recommendation on how could someone
create status lists.

Patrick St-Louis: so there is a little bit of spec text and there was some
endpoints and some objects that were added in the schema. So I would like
us to discuss this. Do we like this idea of having non-normative guidance
when it comes to managing status list but acknowledging that status can
depend on other factors. people might use different solution for creating
status lists. They might use different specifications that will need
different specific things. so it's difficult to make one size fit all.

Patrick St-Louis: yes, man.

Manu Sporny: Yeah. I think it is useful to document things at this level.
if we had an implementation guide, this is something that could go in the
implementation guide. And I will note that just about every single
implementation guide that we have written over the past decade has slowly
rotted in that we just don't update it that much. at least in the VC
working group. so keeping it in the spec could potentially keep it fresh.
Plus one for not making it normative because there are multiple different
ways to do it unless we're h there's some pretty clear patterns after a
couple of years.

Manu Sporny: I'm on the fence is what I'm saying. It feels like there's a
lot of good text here that I would not want to lose. but it's not a clear
yes,…

Patrick St-Louis: Okay. Dave

Manu Sporny: we should definitely put this in the specification. I'll need
to read through the details here though. That's it.

Dave Longley: So two comments. First I have not looked at the PR yet so I
can't say if it sort of matches what our implementation is doing. If it
does, we might have two implementations and it might be worth saying if the
mechanism is bitstring status list which is a standard then here is a way
to do it and…
00:55:00

Patrick St-Louis: one thing I just want to add quickly when we were writing
the bitstring status list test the fact that there were no such endpoints
defined made it kind of difficult to test implementations.

Dave Longley: make it normative. We could always mark it at risk if we
think we might not end up with at least two implementers. but if we want it
to be non-normative, I would suggest that we maybe keep it in the spec, but
put it in an appendix so it doesn't get mixed up with the same sort of a
way we express everything else.

Patrick St-Louis: so having this in there even if it's not normative could
then provide a way to test someone who has a bit string status list
implementation like these test suites are done but moving forward if
there's other status list these provide a interaction endpoint that a test
client can interact with which made string status list a bit more
complicated because there was aware that described these end points. so
when people submitted an implementation to the test suite, it was tricky to
test this. they needed to provide a credential that already had a status
issued and it was not dynamic and yeah it was not as easy to test as other
features that had clear endpoints such as verifying credentials and so on.

Patrick St-Louis: manual.

Manu Sporny: So thinking about yeah I mean plus one that was an issue that
you mentioned Patrick we can make this normative but make it optional. So
it should like if we're going to have this in the spec and if you know what
Dave was mentioning turns out to be true it turns out we do have two
implementations for this. but we don't want to force this on people. we
could just make it a should if you're using status and you're using
bitstring status list then you should implement it in this way.

Manu Sporny: and hear the end points and all that kind of stuff that will h
improve interop, so that's good. we should try to do that. so I think
that's how we could potentially pull this into the spec having a normative
appendix is a bit weird. I know there are people that have strong opinions
on it one way or the other, but we could be a section, in the spec and…

Manu Sporny: we could say, if you're using bitstring status list, and it's
a fairly straightforward implementation of it, we can list a bunch of
criteria, then, you should do it this way. We don't say must, but should.
just a thought. That's it.

Patrick St-Louis: Okay, let me try to capture this and…

Patrick St-Louis: then we'll let's wrap up the call now. I will add a
little comment here that speaks a little bit to this that we might consider
having an appendex with a should on these endpoint for implementers who do
want to implement bitstring status list provide these examples and then we
can review this so just a reminder so for the holidays the next three
meetings have been cancelled.

Patrick St-Louis: so the next meeting that we will have will be on the 13th
of January. So that means that the 30th and the 6th are all cancelled. that
note, I wish some good times during the holidays and hope that you are warm
and safe and that you have food on your table and that you have a good
time. with this being said, let's join the meeting. Thank you very much for
attending.

Manu Sporny: Thanks, Patrick. Thanks all. Happy holidays.

Joe Andrieu: Happy holidays everyone.
Meeting ended after 00:59:27 👋

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