[MINUTES] CCG VCALM 2026-01-20

*CCG VCALM Meeting Summary*

*Date:* 2026/01/20 *Time:* 14:50 EST

*Attendees:* Benjamin Young, Dave Longley, Dmitri Zagidulin, Elaine Wooton,
Joe Andrieu, John's Notetaker, Kayode Ezike, Manu Sporny, Nate Otto, Parth
Bhatt, Patrick St-Louis, Rodrigo, Ted Thibodeau Jr
------------------------------
*Topics Covered*

   - Updates to the KIVC Reporting Platform
   - Expressing Predicates in Presentation Requests

*Key Points*

*Updates to the KIVC Reporting Platform*

   - Benjamin Young provided an update on the KIVC reporting platform,
   which is transitioning to become a W3C project.
   - The platform aggregates test suites for verifiable credentials,
   providing insights into compliance and implementation status across
   different vendors.
   - Recent UI changes aim to simplify the presentation of test results and
   implementation categories (issuer, verifier, other).
   - Discussions were held regarding the future of existing CCG test
   suites, particularly the VC API issuer/verifier suites, with consideration
   for consolidating them into VCOM-specific tests.
   - The potential to leverage OpenAPI specification documents for
   generating test suites was raised as an acceleration strategy.
   - The platform is intended to be inclusive, allowing other standards
   bodies and communities (e.g., retail sector using VCOM) to showcase their
   work, provided they are based on W3C verifiable credentials.
   - A distinction was made between W3C specification-driven tests and
   use-case centric test suites, with the latter potentially offering a
   different browsing experience.

*Expressing Predicates in Presentation Requests*

   - Patrick St-Louis initiated a discussion on the critical need to
   express predicates in presentation requests, especially with the rise of
   zero-knowledge proofs (ZKPs).
   - This is a key requirement for BC Gov's planned API abstraction layer
   to enable ministries to leverage verifiable credentials with minimal
   changes.
   - The current challenge is that existing presentation request query
   languages, beyond anon creds, lack a robust way to express predicates.
   - Several options were discussed for incorporating predicate support:
      - Directly embedding the anon creds presentation request object.
      - Extending the "query by example" model.
      - Defining a new query type, potentially "query by zero knowledge."
   - The discussion highlighted that predicates are fundamental to ZKPs and
   a major selling point.
   - Dave Longley offered insights, suggesting a layered approach to
   queries to manage complexity and ensure compatibility with existing systems
   and wallet introspection capabilities.
   - The importance of ensuring non-anon cred VCs can still be consumed by
   non-anon cred verifiers was emphasized.
   - Concerns were raised about the complexity of some query mechanisms,
   referencing past issues with presentation exchange, and the need for clear
   user interfaces and warnings regarding data disclosure.
   - The conversation concluded with an agreement to continue exploring
   pragmatic solutions for predicate expression, with a focus on enabling anon
   creds while not hindering future developments.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-01-20.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-01-20.mp4
*CCG VCALM - 2026/01/20 14:50 EST - Transcript* *Attendees*

Benjamin Young, Dave Longley, Dmitri Zagidulin, Elaine Wooton, Joe Andrieu,
John's Notetaker, Kayode Ezike, Manu Sporny, Nate Otto, Parth Bhatt,
Patrick St-Louis, Rodrigo, Ted Thibodeau Jr
*Transcript*

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

Patrick St-Louis: Okay, let's get started. So, welcome everyone to the WTC
Credential Community Group VCON weekly meeting. today is the 20th of
January 2026 and we're going to be going through some PRs and progress on
the VCOM repository. as this is the W3C policies are into effect. So please
be aware of those on the agenda today.

Patrick St-Louis: we will go through the introduction, community updates,
PR reviews and do a part two of the topic we started last week about
expressing a predicate in a presentation request and I've been playing
around a little bit and I have some ideas to share and I'd like to further
discuss this how to create meaningful presentation and the context of zero
knowledge proofs and crypto suites. before we jump into the call, I would
like to invite anyone who would like to introduce themselves or reintroduce
themselves to just do so right now. And we'll leave you a couple minutes to
raise your hand and introduce yourself.
00:05:00

Patrick St-Louis: So, it looks like we're all familiar faces in the call
right now. if anyone has topics they would like to suggest that we can go
over, or any community updates to share, please go ahead. very good. I was
wondering if it's okay, Benjamin, if I put you on the spot.

Patrick St-Louis: I know you've been working a lot on Can I VC recently?
I'm wondering if it's worthwhile to take a 5 10 minute to go over the
recent changes. if we feel that's a good use of the time. I can foresee
maybe in the future that we'll be leveraging can IC for VCOM test suites.
so maybe it would be a good little segue like an update onto the features
that have added and…

Patrick St-Louis: discuss this further. Yes, Benjamin.

Benjamin Young: Yeah, I'd be happy to.

Benjamin Young: Do you want to do it now or later? Call.

Patrick St-Louis: Let's do it now. Yeah. definitely.

Benjamin Young: Okay, sounds great.

Patrick St-Louis: So let's get the call started. Let's jump in the first
topic. updates to the KIVC reporting platform. Please go ahead.

Benjamin Young: All right. You mind if I screen share? I'll walk through
where things are at. So, the website project, can everybody see that? It's
probably a little small. Can resize it maybe.

Benjamin Young: Maybe that's better.

Patrick St-Louis: Yeah, it looks really good right now.

Patrick St-Louis: Thank you.

Benjamin Young: Okay, good.

Benjamin Young: Digital Bazaar started this a couple years ago under a NSF
POS grant and that helped fund the work of the VC working group test suites
and then part of the deliverables was a dashboard that could aggregate all
those disperate tests and present them collectively to the community to
help people understand more about what was possible and

Benjamin Young: compliance across different vendors and implementations. we
are prepping this codebase to go to the W3C and as you can see, it still
says across the top that it's an alpha site. I still haven't taken that
down. but because it's transitioning to become a W3C project within the
next probably three to six months, I'm cleaning the place up and getting it
ready for handoff.

Benjamin Young: so there have been a handful of interface changes and
there's more to come. you can see on the homepage there's a couple of
groupings of tests. the VCWG test suites and then the CCG ones. Notable for
this call are the two VC API ones. the titles here are from the test
suites. So with VCOM and I'll circle my way back to this after I show you
the rest of the site. vcoms obviously changed names and whatever, but these
two particular test suites haven't really been touched in two years. So
that's a conversation we'll come back to. the rest of this page lists
implementations that are configured to be either issuers or verifiers
distinctly. And then they configure which tests they're capable of running.

Benjamin Young: which is why you see these upper totals vary in size
because they may not do everything they may not test against all the
specifications and therefore they aren't collectively attempting to pass
203 tests. some of them are only attempting to pass 14 for example. So
these bars are reflective of how well they're doing against their own set
intention we'll say. so we go from the top. So if we look at Spruce's
implementation you can see they cover a whole lot of stuff and there's key
is in here.
00:10:00

Benjamin Young: they either haven't wired that up or I guess they have
wired it up. They've configured that they are testing against it. Yeah,
they're just not passing them. but this spider chart at the top previously
had a mess of stuff. I was trying to do presenting as issuers, verifiers,
and then just tests that were of generic implementations that were not
distinctly an issuer or a verifier. And it was just getting too crowded and
too confused.

Benjamin Young: So, in these changes over the last couple weeks, I've
simplified it down to just the test suites and then how you're doing on the
test suites, which hopefully makes it more obvious, and then grouped them
still in these issuer and verifier and then other category. so in the case
of key, if you had a DIT key implementation, you're not only a key
implementation. You're not an issuer or a verifier. You're a DIT key
implementer. and so I'll show you one of those in a little bit, but all the
spider charts look different, of course, related to what they're trying to
accomplish. And you can see, the breakdown of what's missing. you can go to
the specification page or the test report page.

Benjamin Young: So working on this left hand side and how best to present
how everyone's doing across all the different test sections which is where
these come from. you can drill into each one and then that there are tests
failing and then you can go to the whole test suite repo to look at the
code if you're failing and you want to know why. or you can go to the W3C
formal test suite results which is where all this data comes from. the left
side has links to the specific highlights in the specifications just like
the W3C test reports do. So it jumps down and highlights what the actual
must statement is.

Benjamin Young: And we tried when building the test suites to line up what
was tested with the specification requirements. So there's a easy one to
one match. on this side there's a list of implementations of BC 2.0. So who
said they want to pass it or want to be tested against it. by default it
it's in alphabetical order. You can sort it by how well everyone's doing.
and again you can browse through the implementations.

Benjamin Young: overall information and spider chart which this one's only
trying to pass one. Let's go back to reports and these are not grouped by a
group yet. Probably should be. So here There's a handful of people trying
to do those. And then if we go to the actual result page again, you'll see
what's happening in those things. I thought there was one more. yeah. I
have some changes that aren't up here yet. Let me see if I can show you
those. Oops. So, this is in a PR right now. This is the list of
implementations and they're tagged with what they are, whether they're an
issue or verifier or other category.

Benjamin Young: but I've added this filtering list over here. So, you can
say I'm only interested in EDSA implementers. And then you can browse into
those. there's still some more UI fiddling I want to do in here to try and
get that sectioning more understandable because we have the flip side. What
did I say? EDSA. So it's basically the inverse of this chart but across all
the specifications. it is a fast way to find out who's doing what. as I
mentioned these guys so come full circle the VCAPI tests are pretty anemic
at this point. They haven't been touched in two years and there wasn't much
there to begin with.
00:15:00

Benjamin Young: I think there's a discussion the group can have around
whether or not we lean on the open API specification do or description
document contract some people call it to generate test suites or to use
that as part of a test suite. That would be an accelerated way to get to a
full testing of an implementation. so that could be considered. Right now,
the tests are a little silly, because they're doing the exact same action,
attempting a verification, but with a VC that has pieces of it missing to
fail. what this also means is that a lot of these folks that are passing
aren't actually passing because their implementation is down in 404,
because the correct answer is to fail, these tests are passing.

Benjamin Young: So this particular test suite has some issues that can be
fixed. and then this section is missing not because it's not there, there's
no tests in it. So there are things like that that these were pretty early
stage ones that didn't get as much focus because we're pre-esting
requirement on BC API. Now as the group heads towards becoming a VC working
group recommendation test suites become required which then means there's
much more motivation than time and money alignment on getting this done. So
that's it. Go ahead Patrick.

Patrick St-Louis: That's really nice. I think the issuer verifier API test
suite if I remember they were mostly used for integration with the VC
playground. I think that was one of the sort of idea behind them. can we
foresee so with the change of pacification of the spec and the promotion of
the spec can we consider removing the CCG test suite from this and instead
just focusing on the W3C1 and perhaps removing these VCPI issuer verifier
and… condense them into a VCOM implementation. Not sure what would happen
with did key. but yeah, is that kind of a potential idea? Yeah.

Patrick St-Louis:

Benjamin Young: Yeah. …

Benjamin Young: part of the road ahead is as this moves into the W3C and
becomes a W3C project, it's going to end up in some home, very probably the
VC working group. but it could also end up in the credentials community
group as the governing body or it could end up in a third group s just
about that group over time would make decisions around what test suites to
incorporate and how to work on the website and what they wanted to look
like.

Benjamin Young: there's no reason that we now could decide to take those
out add more dip methods if there are test suites for them or whatever
because it's intended to give the community a view into itself. So yeah
that can totally be discussed. VCOM…

Benjamin Young: though does need its own test suite and that's going to be
a requirement as it grows up and becomes a working group spoke.

Patrick St-Louis: Yeah. I'm also thinking …

Patrick St-Louis: because right now there's two different repos when you
can publish your implementation the CCG and the official one and having one
location would maybe simplify some of these things and you can manage all
your tags and all your things from this one place instead of having to
remember I need to edit this implementation file and so on. So that could
help. But yeah, this is really good. I like the direction here. yes manu.

Manu Sporny: Yeah, plus one to all that plus one to everything Benjamin
said about how this thing could evolve. on the specific question of
removing the CCG test suites and are there external things or is it only VC
working group only I think one of the things plus those VC API issuer
verifier interop reports are super old they've served their purpose they
got people to integrate with the VC playground but the VCOM tests are going
to have to be way more like
00:20:00

Manu Sporny: involved. the question of whether or not we have all of these
in one test suite or split them out I think is an interesting question. if
we look at the conformance section for the VCOM spec there are one two
three four five six different conformance classes there. So there are six
different things you could be if you decided to implement the specification
and you only need to be one of those things. or you could be three them all
six of them, plus one I think we're going to have to talk about what the
best way to structure the test suite would be.

Manu Sporny: a plus one to the question Benjamin raised which was like
should we power it off of the OAS spec because that would be a pretty easy
way to start. I do have concern I mean the spec is generated from the AOAS
but we also have some other statements in there so we can't purely just use
the OAS stuff. but I think those are all very good like things for us to
discuss and we will need to figure out concrete answers to those to do this
right plus one to doing all that work we don't have to wait right until the
VC working group has started to have those discussions even better if we
show up with a plan on what the test suite could look like because we do
expect the spec to advance

Manu Sporny: to pretty rapidly because we put so much work into it over the
last 5 years now. so that's about, test suite on VCOM specifically. The
other thing that I want to make sure we do not prevent is other standards
bodies leveraging the infrastructure and showing up in the reports. So some
of us are working with the retail sector that is working on their own set
of VCOM based things and their own sets of credentials and they want to
show up in the dashboard.

Manu Sporny: retail vehicles healthcare grocery all of these f payments all
of these folks are working on a variation they're looking at can IVC as
something that's a part of their future strategy so there's a question of
okay if the VCWG is going to be in charge of this how do they enable other
communities to leverage it in a positive way where those other communities
keep control of their own tests and test suites and things like that but
they still show up in the dashboard in this unified view. things to think
about but my hope is that these are not going to be just VC working group
only things. I think that would lead to almost instantaneous forking of the
thing…

Manu Sporny: which we wouldn't want to see. that's

Patrick St-Louis: That's interesting.

Patrick St-Louis: When you say not only VC things and you give these
example retail and so Are we still however on the same page that whatever
shows here would need to have a W3C specification assigned to it or are we
starting to think about the Wild West and having anything show up in there
or what would be the sort of vetting process that something would appear on
there or what's the scope here?

Manu Sporny: Yeah, great question. sorry, I'm jumping. Q. Go ahead,
Benjamin.

Benjamin Young: Yeah,…

Benjamin Young: you just described why we're trying to get a governance
model put together at the W3C. it is going to be a W3C project, so
obviously there will be a bias and a foundation towards that stack. But it
would really be up to the group what it includes. one of the reasons for
the credentials community group to be the home of it is twofold versus the
working groups are often lived and go through these sort of identity crises
when they come out of their little two-year spec focused timeline and then
go into maintenance mode and then they switch back and it can be a little
jarring if you're trying to run software. whereas the credentials community
group ostensibly could have wider participation and could have more people
focused on maintaining it.
00:25:00

Benjamin Young: but you still want the thing because it's W3C owned
ultimately to be driven by the interests of the W3C and its membership. So
that's a small minus zero for putting it in the credentials group where you
could have a much wider audience that wants the thing to live and grow
appendages that are maybe not great for the W3C. that doesn't mean that
shouldn't happen. It doesn't mean that couldn't happen in consultation and
the W3C sometime down the road says, you guys are doing great. We're just
going to send this out of the building. But for the foreseeable future,
it's really focused on the really VC data model and then all the orbiting
specifications around that. Now, how you define the size of that solar
system depends on who you are.

Benjamin Young: but I also wanted to come back to something Manu mentioned
about a lot of different players implementing these specs. it was kind of
envisioned from the beginning that eventually there would be profiles of
these specifications that different groups like California or DHS or any of
the groups mentioned in frequent calls that use these specs but usually
subset them ratchet down what they care about. might also have pages on
here in support of the community that says at wherever our DMV and whatever
state use VC 2.0

Benjamin Young: but we only use ECDSA and we wrap them in hosy cozy
packages. And so we want, a filtered view that links to our documentation
in our space, but then it shows charts for who's passing those three specs.
and whether or not that then grows arms and legs and becomes other test
suites from those groups, I don't know. It's, hopefully going to happen in
conversation with the group. That's it.

Patrick St-Louis: Thank you, Manuel.

Manu Sporny: Yeah, plus one to that. Patrick you mentioned kind of two ends
of the spectrum. One of them it's W3C only stuff and the other end is it's
wild west. I think of course the reality is going to probably be more in
the middle. so specifically at least one thing we can talk about is the
national association of convenience stores has a standardization body an
SDO called can access and they work on retail standards and they built
their retail standards on W3C verifiable credentials and they have an age
credential right so that is an example of they would like a test suite
around age credentials they're going to work on it and put it together
because it's their specification

Manu Sporny: but they would like it to show up on this dashboard as an
example. And that's just, one that we can talk about publicly. Yes,
exactly. for education, there's open badges and having open badges, show up
here so who can issue open badges and then of course there's discussion
about, less and CLRV2 and those sorts of things. So we have a really good
infrastructure here, thanks a ton to the work, Benjamin's put into it and
Andrew put into it, before Benjamin and all the people that contributed to
test suite. It is a very useful thing. And so, if somebody is working on a
specific type of VC for supply chain or education or whatever, we have
definitely heard that they want to be, in here.

Manu Sporny: So it the ones that I know of are very focused on know they're
using W3C verifiable credentials.

Manu Sporny: They're not just saying they're using potentially some
variation of VCOM to issue and verify. And so we believe integrating them
into this should be a fairly easy thing. versus somebody's working on some
new protocol that has absolutely nothing to do with W3C verifiable
credentials or VCOM or anything like sorry it doesn't make sense for you to
show up in the ecosystem report. hope that helped clarify. Yep.

Patrick St-Louis: Perfect. Yeah,…

Patrick St-Louis: that's interesting. And obviously QNTP would probably be
another one of those example that they have their spec and they have their
test suites and they want somewhere to be. I'm wondering if it would make
sense that there's the W3C specification because what's nice of having all
the test suite based on a specification is they can be reported
consistently right whether it's one testuite or the other since we design
these test suites in a similar way it's probably easier to show them in a
more consistent way.
00:30:00

Patrick St-Louis: I'm wondering if it would make sense to have I see a
couple tabs at the top more of a use casecentric pluggable test suite
reporting thing because we can't expect UNP will design their test the same
way as the retail maybe they will be similar maybe not but to differentiate
these kind because these test are starting to be very specific in what they
want to issue it's not so much about the features anymore about do you
understand this ecosystem and can you be a participant in it and I'm
wondering if it would make sense to have this sort of use casebased test
suites that people could browse kind of separate than the purely lower
level specification based test suites.

Patrick St-Louis: yes, Benjamin.

Benjamin Young: Yeah, that's been desired throughout.

Benjamin Young: I think the tension here is that the requirements around
test suites at the W3C you're not actually implementations. You're testing
the specs and you're using implementations to do that. I mean it's kind of
the premise of W3C test suites.

Benjamin Young: so this is kind of flipping the model to promote, I mean,
it's always been two wheels on the same chariot, but they're written about
the specifications because that the requirement that drives them into
existence is that the specifications must have all their musts tested in
order to get all the way to technical recommendation status. what that
doesn't really give us out of the box is what you were describing of a use
case test of in the words of can I do a open badge credential like you
could spend all day clicking around in here and not really get that answer.

Benjamin Young: so there are other tests sort of approaches that the group
that manages this in the future can and should consider that that could
really start answering the can I blank sort of phrasing throughout some of
which is here in these spec texts but rarely is is it everything like some
we can answer now can I do selective disclosure. I could make a dedicated
page for that and pick the specs and handfuls of tests that would prove
that out from those spec tests and then show you a list of implementers
that check those boxes and then you have a better guess anyway that that's
possible. So ECDSA crypto suite has an selective disclosure section and
that coupled with BC 2.0

Benjamin Young: no data model, you get the idea. but if you were to go
farther to say support this specific credential type or…

Benjamin Young: this coupled with this DI method over this protocol, that's
where you start to get into the profile space or use case tests or all of
which are, possible for whatever group does this. but they don't making
those has a different motivator than those fact tests if that's clear.

Patrick St-Louis: Yeah. Yeah.

Patrick St-Louis: This is really cool.

Benjamin Young: Thanks for the chance to show it off.

Patrick St-Louis: No, no problem. I see you've been adding some stuff for
the last couple of weeks.

Benjamin Young: Yeah. sort of. Yeah.

Patrick St-Louis: So, I figured it'd be nice to have a sort of summary.
it's also very fun to see that some of the design decision we made in the
test suite you can see them now, I'm thinking about when you had the view
about the VCDM 2.0 know test suite we have on the left all the different
section is very consistent with the spec and this idea of highlighting the
text in the page I think it's all like this is new right this page that we
just saw the can I see sort of
00:35:00

Benjamin Young: So what we did from the beginning not the beginning towards
the end actually of getting these ready for the final days of the BCWG's
publication process was adding selection text for each of these so that the
W3C test reports would link across.

Patrick St-Louis: Yeah. Yeah.

Benjamin Young: What's new in the last week is that these links now show up
on Can IBC, but the data has been there for about six months. I just hadn't
put the little icons

Patrick St-Louis:

Patrick St-Louis: That's what I was trying to say. It's nice that these
things can now be surfaced and from what I can see it makes sense, It's
consistent and great. it's a great sort of reporting was there any other
questions or topic of discussion around reporting testing and VCOM? we can
probably have a more detailed discussion about BCOM testing in another
call. it's a broad topic. but is there any quick comments anyone would like
to share around this right now?

Patrick St-Louis: Yes, Benjamin.

Benjamin Young: Just to say that,…

Benjamin Young: we should take a really hard look at testing with the open
API description since we have it.

Patrick St-Louis: Yes, I think that's in leveraging this to definitely add
some kind of validation right to what's going and…

Benjamin Young: Not everything fits that mold, but it's an 80% sort of jump
forward.

Patrick St-Louis: mostly what's coming back from the API will help a lot
some test case will need some more specific things to verify, but at least
to make sure that the responses are all consistent and conforming with the
spec. I think leveraging the open API is a really good idea. I don't see
why we wouldn't. So, okay, let's move on.

Patrick St-Louis: I will go ahead and take over the share if that's So I
would like to go back over this issue of expressing predicates in a
presentation request. I still think it's very important and it will become
more and more important as zero knowledge proofbased credentials become
more popular I open and so we talked about it quickly the last time and
I've opened two issues since then one of them being about expressing
predicates and a presentation request

Patrick St-Louis: We had another outstanding discussion topic about the
interaction scheme registration which was about making an official decision
if we want to register this as a scheme or not. however we can discuss this
if we want but I would like to talk a little bit more about this predicates
and presentation request. the reason why so in BCG gov we're thinking about
introucing we call it an API abstraction layer that would enable different
ministries and anyone who wants to start to leverage verifiable credentials
and their service offering to not have to learn every single different
specification they want

Patrick St-Louis: adapt and in the future if the BCG gov was to change from
one to another it could be done in a way that's a bit more controlled and
that different ministries or services would have minimal change to
implement so right now we are using acup that's what services are
interacting with that's the API people are interacting with I added a bit
of leg work for VC API and API. however they're not using that at the
moment in VC gov it's very focused around anon creds and the VC API is not
quite there to allow this at the moment for a few reasons.
00:40:00

Patrick St-Louis: one of them obviously this issue is related to this but
yeah so we want to design an abstraction layer an abstraction API and we
are trying to figure out what would this look like goes without saying that
a strong proponent of using VCOM I think it could serve that purpose fairly
well it's

Patrick St-Louis: one of the design goal of VCON that you can use different
credential format and that it's going to be dynamic for new specification
that are introduced. but it's a bit difficult at the moment to convince
someone who's not that familiar with the VCOM. and then if there's things
that it cannot do you cannot request a zero knowledge proof then that kind
of throws it out of the consideration right away. yeah so that's a bit of
context why I think this particular thing is important. a lot of use case
in BC they rely on being able to request not only predicates but also do
selective disclosure.

Patrick St-Louis: the query by example has a way to enable selective
disclosure but it doesn't have a way currently to request a predicate and
not only this but I haven't found a single query presentation request query
language I can enable this besides the anon specification so I just want to
show very quickly what our current presentation requests look like that so
this is the presentation request object itself. so we have a name a version
a nons these are not that critical. what is important is the requested
attributes.

Patrick St-Louis: we tested predicates and the nonrevoked here. so when we
get into zero knowledge and selected disclosure yes we're still dealing
about credentials but we're mostly dealing about individual claims and
credentials. when you have a proof that you cannot select a disclose, you
always share the credential. So we are really querying about a credential.
I want to see this credential. Please show me this credential.

Patrick St-Louis: but when we talk about being able to query individual
claims on the credential then all of a sudden your presentation request
becomes very specific about wanting to verify very specific claims from an
individual I say individual because in most cases that we see it's person
centric but this could cover any other kind of entities and the way so
obviously this data model here there's a lot of logical operations that
happen there's a bit of if and so on we also have some of this in the query
by example right so for example the authority is an array so you must have
one of these issuers that's an example

Patrick St-Louis: of a bit of a logical meaning that's embedded in here.
the one thing that can see here is my attributes and my predicates they're
totally separate right they're two different objects that are bound by a
different set of restrictions and I am trying my best to see this inferred
logic can be represented in that would work in this example in something
like a query by example.

Patrick St-Louis: so where I would see this object fit in if I was to
express in this kind of model I would just define something like anon creds
presentation request and then just put that object in here. however, that's
the layer one that I could do, I could just say, I'm going to be done with
it. we're just going to take the unknown creds presentation request spec,
put it in there. that would be the easy way. I'm not sure how well it would
transfer to something else than anon creds. I mean, yes, it says anon creds
here, but here we're requesting predicates or attributes and so on.
00:45:00

Patrick St-Louis: the second option would be extend query by example. I
thought this was a good idea. with some reflection, I'm thinking maybe it's
not the best idea. It could still be but it would overload a little bit
this query by example object. the easiest way would be to besides example
add another field that's called predicates and define a way to express you
need to meet these pred or you need to prove me that you meet these
predicates in your response and how the wallet would do this would depend
on the crypto suite that's used the securing mechanism whatever the issuer
has allowed them to do.

Patrick St-Louis: which brings me to my third option which is to define a
new query type. I know last time there was the query by predicate. since
came so I did a few examples here of what I've just explained here an
presentation request. I just blot this in there and we're done with it. but
there are some anon specific thing in there. for attributes we have
restriction that we can put different elements on that we restrict on
there's a limited amount so we can restrict on an issuer which is very
similar to this authority right with functions the same thing except I'm
lost in my specifications.

Patrick St-Louis: we have a cred ID which what I observed from the work
that was done to do addon credits with data integrity. The cred ID would
correspond to a verification method. so this would go a step higher than
restricting on an issuer. we would restrict not only on the issuer but also
the key that was used to sign the credential. so this is the kind of level
that cred ID kind of applies. So cred ID is the sort of public key
information associated with the specific credential I want to issue.
obviously with unknown credit there's a series of key pairs for every
single claim in the credential.

Patrick St-Louis: So this is a very rich object but this ID value and the
issue credential v2 sort of translation work that was done is displayed as
the verification method of the proof. other things is we can restrict on a
schema id right so this could be expressed as the chema id of a credential
for example these are the three main things we restrict on we can also have
some restriction on I don't know if I can find an example here so they list
all the restriction here so schema ID right ID

Patrick St-Louis: the ID of the schema that's used. in our case, this is a
non-cred schema ID, but this ID value could very well be a JSON schema L,
For example, we allow the issuer of the schema to be different than the
issuer of the credential. So an issuer can browse a list of schemas that
have been published and then start to issue their own credential based on
that schema. So in this case we can restrict on making sure that the
credential comes from a specific issuer of a schema.

Patrick St-Louis: I'm sure this model exists elsewhere especially it's
probably done a bit differently in the context of W3C credential right I'm
thinking here when you have a credential type with a context right and then
many issuers will issue that credential type right this is kind of what is
happening here but in a slightly different way name schema
00:50:00

Patrick St-Louis: version very non-cred specific issuer did so issuer ID
that's a very common thing that we can express and then the cred ID which
is like I mentioned would be more akin to a verification method ID these
are the one I don't have much experience with them but you can put a
restriction that I want this specific attribute to exist in the credential
but I don't want to know what it is Right? I just want this attribute to
exist. but don't re reveal it to me. Just prove me that you have this
attribute somewhere in your credential. So this wouldn't really work with
our current idea to just include a value with an empty field because in the
query by example I believe this was dedicated to reveal me this value right
I want to see this value.

Patrick St-Louis: Don't only prove me that you have it but actually receive
reveal the value. and then the last thing is prove me that this value is
equal to this. I don't really see the difference between this and revealing
the attribute. So these are things that are possible. but I'm not sure that
this is something at this point prove me that this value is the same thing
as just revealing the attribute but I digress this one can be interesting
in some use cases.

Patrick St-Louis: So yeah so these are restriction that you can apply on
where does the credential can come from some of these are implemented like
the issuer did right we have the authority here which you can put the
issuer did but this is limited to only issuers right however this is a
dictionary so there could be other things and authority But currently, this
is what I've seen. Dave, can I know you raised your hand. Please take the
mic.

Dave Longley: I can wait. Yeah. Good.

Patrick St-Louis: Just in case it was specific to something there. so these
are the restriction and you can apply a different set of restriction on any
claim, any attributes you want revealed or any predicate. Right?

Patrick St-Louis: In this case, I believe you would need to include two
query by example. if I have two if I want to see two different claims but
each come from a different credential, Then I would just request two
different query by example, which is fine. it's just the logical and if
they're just at a slightly different level which I think it's fine right as
long as your software understand how to put them together.

Patrick St-Louis: so this leads with how can we express mostly a predicate?
I think the predicate is the number one thing that's in there right now
that should be addressed. I think predicates are also fundamental to zero
knowledge cryptography. That's one of at least the main selling point. so
what I came up with was something called query by zero knowledge. the
reason I settled on this so when we think about query by example by nature
this sort of assumes that the issuer knows things about the credential. it
can have in the example values in these fields.

Patrick St-Louis: so I think having something that's called query by zero
knowledge kind of puts the framing that here's a query that I want you to
prove things that I have no previous knowledge before. I have three section
or four sections right now. the real one that we're missing is the
predicates. So it could only be however I also included an array of claims
and these I think using JSON path makes sense. you could very well express
a verifiable credential in there or any other data model that is sort of
JSON based. So I could very well put credential subjectgiven name. if I was
using a W3C credential.
00:55:00

Patrick St-Louis: so the idea is that you have an array of claims these are
things to be revealed right so these are a series of path then predicate
you have the same thing your path and then you have so here I took the
simpler approach it's a list truly a tupole that the first element is the
equation and the second element is the value against which you're equating
This is in the very limited frame that the only thing that's possible right
now in unknown creds is to compare and figure values. that's possible. with
other method there might be other things that you can compare.

Patrick St-Louis: so perhaps an object would make more sense here and we
could start so if you see here the way we currently express the predicate
we have the name which is the attribute name we have the type of the
predicate which is the equation and then we have the value which is what
we're comparing the equation to predicate value. So maybe we want to bring
something similar in the predicate that I kind of still like this idea that
you have as the key the JSON path and then the value could be an object or
an array representing your equation that has to be met.

Patrick St-Louis: for the restrictions, I've also used path here to put
this, but this could very well be just our authority object here. we could
reuse the authority object to express that it needs to come from this
something else that could be interesting in the authority is to put a
verification method. instead of issue I could have verification method here
and that mean you need to give me something that has been signed with this
verification method for the schema ID I'm not really sure if that would
make sense to express as an authority I'll stop here I would like some
feedback on what I said so far Dave

Dave Longley: This is all super interesting. really good there was a lot
here. I had little thoughts as you were going.

Patrick St-Louis: Yeah. Heat.

Dave Longley: I tried to jot those down to try and come back to it. I first
raised my hand when you were mentioning how the blank value approach or the
wildcard approach in query by example might not translate well to the anon
approach. but I wanted to say I think it could if you took sort of a
multi-tered layered approach where you did your query by example and then
you ran your restrictions where you're applying those to whatever results
you happen to get. So you would find everything that would match any field
indicating that the field was present and the restrictions would ensure
that that field was not revealed but just that the field does exist or
doesn't exist whatever other restrictions you wanted after you had filtered
this down.

Patrick St-Louis: Yeah.

Dave Longley: And that sort of comes from me thinking about these operating
as filters generally. these queries that you send in even when you go and
implement them they're not database queries and most wallets are going to
have some kind of database on the other side of this and they're going to
do some initial query on their own end maybe just for context and just as
an example or just type of the VC to get some partial query and then we'll
further filter that based on the query by example and…

Dave Longley: then you could further filter that based on restrictions of
whatever kind with all that in mind, I was also thinking about two things
while you were talking about I think it's important to ensure that a
nonredit VCs can still be consumed by non noncred verifiers because the
nonreds are still VC compliant. And I think with all the approaches.

Patrick St-Louis: Yeah,…

Dave Longley: Go ahead.

Patrick St-Louis: but they will still need to implement the cryptography,
they will need to be able to verify the proof. so I'm not 100% sure I agree
that a nonred cred regardless when I say an credential it can be expressed
as a VCDM 2.0
01:00:00

Patrick St-Louis: I know that work has been done. It can work but to verify
the proof the verifier will need to understand it could put that that's why
you have the Yes. Yes.

Dave Longley: Yeah, there's two bits to that,…

Dave Longley: right? The first bit is I don't know. it might be simpler for
someone for a consumer just being able to verify a simple proof. And the
second one would be if you are issuing a non-cred VCs that use proof sets,
you can have your non-cred VC and some other standard proof along with it.
And so those are the options that are available to people and you get a
wider use of the credential if you do the one or both of those things. I
just want to make sure I don't think anything that you were presenting
would prevent that from happening. You could always have your query I'll
use a query by example and…

Patrick St-Louis: Yeah.

Dave Longley: I'll use this other mechanism and then the digital wallet can
choose and that might still be able to select the same credential with the
proof that's going to work with that. the other thing I was thinking about
was that we have seen this happen in the DC I the original pres
presentation exchange stuff that they were looking at. the open ID group
decided to stop using presentation exchange because of the JSON path work
and some other stuff that was too complicated to have lots of different
filters and different ways to ask questions about things.

Dave Longley: and one of it came up for a number of reasons, but the one I
wanted to highlight was that browsers were looking for ways to be able to
introspect on the query that comes across before handing it off to a wallet
so that the browser itself could if it had some understanding of some basic
credential basic types of information that the browser is aware of, it
could highlight that in some user interface. they wanted to be able to do
that. And I want to note that if queries are coming across for a noncreds
that the requested predicates or whatever are essentially opaque claim
values or things that are hard to understand or have complexity attached to
them that might end up getting those things blocked or get big warning
signs.

Dave Longley: But if you go through the layered approach, you might be able
to avoid that. So that's another reason to consider trying to find a way to
sort of layer it so that there's a mechanism by which someone introspecting
it that might not be the end system this system might know nothing about
doing all the anon or predicates or other specialty stuff. It could say,
you're looking for these fields." And it might be looking for that to
decide whether or not to show a box that says we have no idea what's going
on. this is a dangerous request. so it would be good to be able to fit into
that to streamline it and prevent dropping not being able to get to end
users when you go through DC API or…

Dave Longley: similar systems.

Patrick St-Louis: It's hard for me to have an opinion like you mentioned a
lot about history and…

Patrick St-Louis: trials they did in DCI. I'm not sure I understand exactly
100% the issues that happened there. However, definitely one thing that you
said was to make sure that the question about proof sets obviously if an
issuer issues something with a proof set and the verifier use a query by
zero knowledge right I can meet this predicate by revealing the value right
if the predicate is the random number is higher than 1,00 I

Patrick St-Louis: revealing the value will meet that It doesn't have to be
a proof that gives zero knowledge. That's the intent. but if the verifier
doesn't understand any, crypto suite that does zero knowledge. I would
wonder why they would use zero knowledge. But okay, let's say the verifier
only understands BBS, the user has an on creds. And again, these are we're
talking about edge case that I'm not really considering right now, I'm more
in the pragmatic phase of I just want to be able to express this, I just
want to be able to make anon creds work with this without preventing other
things from emerging from this down the line.
01:05:00

Patrick St-Louis: But let's say we have a verifier that only understand EBS
and they also understand ECDSA RDF whatever and the credential in the
wallet has first of all the user needs to be aware that if they use the
second proof they will be revealing some information so they're no longer
protected between quotes by this ZKP crypto suite.

Patrick St-Louis: so that's something else that the wallet should be aware
of that if you answer this presentation request with this proof you will
actually be revealing your information right I think that's important for
the user to be aware of but technically I don't see why it wouldn't work
right for the restrictions what's really important

Patrick St-Louis: for me is these predicates right just this I want to know
what's the best way forward that we can implement this and the workflows
here that we've defined that could enable this with the least amount of
work an idea be maybe we just take query by example and add predicates and
find something that happens here

Patrick St-Louis: we could even do the same thing give another kind of
example based on this but have a way that we could sort of convey a
predicate equation in the value of the property whether that's a small
dictionary that has the equation and the value but we know that when we
take in the example this should be treated as an example but if we take in
the predicates and we have a credential

Patrick St-Louis: potential subject attestation We know that this can be
proved with zero knowledge proof. It doesn't have to be revealed. That's
the kind of the difference that I would do here. keep the example as these
are the things I want you to reveal to me one way or another. yeah, yeah,
yeah. We're past the hour, but So, there's still discussions to be out of
this. I'm going to have to abruptly end the conversation here because it's
taking a bit too much time. but it seems like we will be able to find a
solution sooner than later. for stealing a bit more of your time. we will
surely resume this conversation as well address some PR in the So next
meeting will be next Tuesday.

Patrick St-Louis: Thank you all for attending the call and participating
and I'll see you all in a week.

Patrick St-Louis: Thank you.

Dave Longley: Thanks, Patrick.

Dave Longley: Very interesting.
Meeting ended after 01:08:39 👋

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