[MINUTES] VC API 2025-08-05

VC API Community Group Meeting Summary - 2025/08/05

*Topics Covered:*

   1.

   *Community Updates:* Patrick St-Louis announced a pilot project with the
   Better Business Bureau and Katina X (Germany) to exchange verifiable
   credentials using VCDM 2.0, focusing on interoperability between UNP and
   non-UNP frameworks. Discussion also touched upon US federal government
   interest in similar initiatives and ongoing discussions regarding the UNP's
   role in digital identity and business registration in Canada.
   2.

   *Pull Request Review:* Parth Bhatt presented a pull request (PR)
   clarifying the verification process for verifiable presentations (VPs) in
   the VC API spec, allowing users to optionally skip verification for
   debugging. A related issue was identified regarding the JSON schema for the
   verifyPresentation response, requiring a separate PR to address the
   structure for reporting presentation and individual credential verification
   results.
   3.

   *High-Effort VC API Items:* The group briefly discussed several
   high-effort items in the VC API spec, including Joe Andrieu's work on use
   cases and sequence diagrams, and Patrick St-Louis's work on revocation
   lists and the status service (potentially aligning with Digital Bazaar's
   API).
   4.

   *Verifiable Presentation Request (VPR) Specification:* The group
   discussed the future of the VPR specification, considering merging it into
   the VC API spec to streamline the process. Key points included the
   intricate relationship between VPR and VC API, the potential for supporting
   multiple query languages (e.g., DCQL, query by example), and the need for
   clear examples demonstrating the flexibility of VPR to accommodate various
   query languages within a single exchange. The group reached a consensus to
   explore merging the VPR specification into the VC API spec, while ensuring
   clarity on supporting multiple query languages and addressing scalability
   concerns.

*Key Points:*

   - Significant progress on reducing the number of open issues in the VC
   API repository.
   - Successful pilot project showcasing verifiable credential exchange in
   a real-world setting.
   - Need for improved JSON schema in the VC API for clearer error
   reporting in presentation verification.
   - Ongoing discussion on the optimal structure and scope of the VPR
   specification, with a leaning towards merging it into the VC API spec for
   simplification and easier maintenance.
   - Emphasis on the importance of supporting multiple query languages and
   credential types within the VC API framework for broader interoperability.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-08-05.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-08-05.mp4
*VC API - 2025/08/05 14:58 EDT - Transcript* *Attendees*

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

Manu Sporny: All right, looks like we've got a good group of people here.
So, let's go ahead and get started and let other people trickle in as they
do. welcome to the VC API call for this week. our agenda today is
effectively to review community developments and we'll process one pull
request. We actually had seven before we headed into the weekend, but due
to a number of merge conflict resolutions and asynchronous discussion,
we've been able to merge a lot of those in. So that's so we'll only have
one pull request for VC API today. but we have not been paying a lot of
attention to the verifiable presentation request specification. there are a
number of ready for R issues there, but we haven't marked them as high
effort yet. So we'll be doing some categorization of that today.

Manu Sporny: and we may spend a little bit of time talking about the
higheffort items in VC API since Parth has started tackling at least one of
them to see if there are any other ones that we think we might want to get
done before we try to move the work into the VC working group once we exit
the vacation or summer break. any other updates or items for the agenda
rather? Is there anything else we want to discuss today? If not, let's go
ahead and jump into the nda. any community updates that we should know
about? anything of that sort that we need to discuss?

Manu Sporny: Go ahead, Patrick.

Patrick St-Louis: Yeah, just to there was a little publication for some
stuff that is happening in BC with the MZAC permit and UNP. So, we have a
letter of intent with the Better Business Bureau and the Katina X people
from Germany to do a NBC gov to do a pilot of exchanging data which is
verifiable credentials using the VCDM 2.0

Patrick St-Louis: VC Jose and some data integrity. and this would be a sort
of a first exchange of UNTP data with a framework that doesn't use UNP. So,
Catino X they're a data exchange platform for the automotive supply chain.
and they currently have members that are on boarded. the use did web some
membership credentials and we will be working at defining a model. I just
put a link to the news in the chat.

Patrick St-Louis: we're going to be working on a model that a non-member
could send some verifiable credential to a Katina X member and then the
Katina X member will be able to then relay this information to map it to
models that the Kina X framework understands. So we have a pretty small
scoped proof of concept but I'm hoping that the outcome of this will be
able to be shared with the UNP group and maybe help make some decisions
when it comes to interoperability on a larger scale and…
00:05:00

Patrick St-Louis: testing if there's value in the UNP

Manu Sporny: That is awesome news,…

Manu Sporny: Patrick. Congratulations. this looks really interesting.

Joe Andrieu: This is

Manu Sporny: you mentioned so just to note that I've got another couple of
positive hits in kind of customs and…

Manu Sporny: business identity and things like that.

Patrick St-Louis: Mhm. Yeah,…

Manu Sporny: They're familiar with UNP and CFAC. I think there was some and
I don't know how much of this is public not.

Manu Sporny: So, you know what? I'm gonna not say anything further, but
just note that there's also interest, I think, within the US federal
government on these sorts of things. And my hope is that they'll be able to
engage at more depth as probably not in the time frame for the pilot or
anything like that, but I'll

Patrick St-Louis: I could see where it leads. if you want to have a chat
offline, I'm happy to have a chat. I know you mentioned for business
identity and stuff. So I know a part of the UNP was called the digital
identity

Manu Sporny: Mhm.

Patrick St-Louis: which was a credential issued about an organization from
an authority that can be used to that business can then share this with
their trading partners. For example, BC would issue a BC registration
business that used the organizations did as the subject and then this
company can then share this to say hey here's my credential from either the
Canadian federal business registration or my provincial business
registration. and that work item has been moved out to the UNP to I need to
find this work out. It's like the global trust registry. It's like a
separate entity and they're kind of taking over this part. so I'm
personally looking forward to what will be the outcome of this. I'm not
directly involved in this.

Patrick St-Louis: And we're currently talking a little bit seeing because
I'm trying to understand in Canada at least …

Patrick St-Louis: what is the relationship between provincial business
registar and federal business registar and from my understanding they are
equivalent so it's not like federal is more important than your provincial
they have a equality so in BC we're kind of just discussing …

Manu Sporny: Great.

Patrick St-Louis: who should be issuing these credentials and this kind of
thing. So yeah.

Manu Sporny: That's all great news. the other thing I heard and I don't
know if this is rumor, but with the UNP stuff, I thought some German
organization had an issue with it.

Patrick St-Louis: Yes. …

Manu Sporny: I don't know if that's public or not, but has that been
resolved? Because I was surprised when you said it was like Germany's
involved in this.

Manu Sporny: That's a good sign as well.

Patrick St-Louis: Katina X, right? …

Manu Sporny: Okay. Okay. Yep. Mhm.

Patrick St-Louis: so I know there was the big event in Geneva a couple
weeks ago and the goal was to pass I think which was called recommendation
49.

Manu Sporny: Mhm. What are you doing?

Patrick St-Louis: And there was a lot of push back mostly from Germany
about UNP. So they had to remove some UNTP text from that recommendation.
and now UNP is only a small annex to that as an example of something. Yeah.
I think the biggest concern was that it seemed to be like they want
everyone to use this but it's a misunderstanding about what the UNP is
because UNTP doesn't mandate how you can exchange stuff or anything like
this. they just want to try to create some data models that people can then
use to map to other system to use.

Patrick St-Louis: So yeah so we Nancy from BC she's been doing really good
work at trying to get people on board and the people in responsible for
Katina X we've been having some meetings with them and they are pretty
happy with this which led to this public announcement here last week. this
has been couple months of discussions and…
00:10:00

Patrick St-Louis: at least the small group of people developers and
managers that we talked to they're very excited for this because I think
it's unrealistic to expect everyone to be boarded on the platform and…

Manu Sporny: Mhm.

Manu Sporny: Mhm.

Patrick St-Louis: having the ability for a non-member to send so this is a
one-way communication Right? So it's a non-member to contact a member. So
they will look at drafting an API in their specification like a sort of
proxy connector component.

Manu Sporny: Mhm.

Patrick St-Louis: And I'm trying to suggest to use the VP request 2024 as
the sort of exchange endpoint that the member would provide to their
business partner. They say here you can send me your product passport here,…

Patrick St-Louis: and then they would spend it and then once they receive
this UNP product passport then they can start to discover other sort of
evidence credentials that it links to a minds act permit and so on that
initial exchange…

Manu Sporny: Okay,…

Manu Sporny: Mhm.

Patrick St-Louis: since UNP doesn't do any exchange right so that initial
sort of exchange is what we need to define so that's more the kina x people
to work on and then the non-member would just need to implement whether
it's like the query by example or whichever kind of workflow and exchange.
So yeah,…

Manu Sporny: Okay, cool. that's awesome. that's great. And so, is there any
other thing that you feel like this group could do to help or anything
related to that?

Patrick St-Louis: not for so we're still in the preparation phase for that.

Patrick St-Louis: We're drafting stuff. Maybe as we progress in the next
few months I might just have questions that I might just come mention
regarding workflows and things of the sort.

Manu Sporny: Mhm.

Patrick St-Louis: The main focus going to be with VC Jose that's what the
UNP ended up to settle on as the requirement. we will have a bit of data
integrity. I'm going to try to also leverage webv in this work item mostly
who is So that's a great way for an organization to share these digital
identity anchor and…

Manu Sporny: Mhm.

Patrick St-Louis: this uses some data integrity. yeah. So, that's clear
question in mind for now, but I'm sure I could have some eventually and…

Patrick St-Louis: if I can think of something, I'll reach out.

Manu Sporny: All right.

Manu Sporny: Sounds great news, Patrick. Thank you for letting us know
about this. any other esyem community development updates, that we should
know about. All right. let's go ahead and move into the next agenda item
which is processing pull requests. like I mentioned we had seven last week.
We've processed at least six of them. We have one that Parth has just
raised. I think this one was the high effort one …

Manu Sporny: if I remember correctly. Yes. okay.

Parth Bhatt: Yes, sure.

Manu Sporny: Parth, do you want to take us through the issue and then what
the PR does to try and address the issue?

Parth Bhatt: So this PR basically focuses on issue 284 that revolves around
bringing some clarity in the V verification process for VP and provide the
ability to allow users to either skip the verification process for contain
ained credentials in the VP request for debuging purpose things like that
and improve the API documentation for the same.

Parth Bhatt: so I basically made that change in the text mainly as of now
and I have one question as well which is basically do we need any change in
the schema for request option? Yep.

Patrick St-Louis: I thought we had sort of implement this does ring a bell
something we did spend some time looking at in the past. and I thought we
at least discuss fairly the JSON schema for the verification response the
verification results from the presentation verify endpoint although I could
be wrong but it does definitely seem to me like we had somewhat discuss
some of it in the past.
00:15:00

Patrick St-Louis: Am I the only one remembering this?

Manu Sporny: I'm confused about what you're saying Patrick because I think
we did and we came to a decision on the PR. I don't know if that's what
you're talking about or you're talking about something else. I'm confused
by what you're saying Patrick

Dave Longley: Patrick, are you talking about there was another PR that I
believe we've merged and everything that had to do with specifying how you
report the results that included errors and…

Patrick St-Louis: Yes. Yes. Okay.

Dave Longley: and matching things to different things that were checked. I
believe we did that R and it was merged. And then I looked over this R a
little while ago. This mostly adds text to help readers of the spec
understand that they can customize options if they want to do other
behavior. But it also clearly specifies that the default behavior for the
presentation's verify endpoint is to verify the presentation and any
credentials within.

Patrick St-Louis: So I think what I'm trying to say is that regarding the
JSON schema we should double check that the response from the verify
presentation verify how would the information about not the presentation
proof…

Patrick St-Louis: but the credential proof be returned if it raises an
error and…

Manu Sporny: Okay.

Patrick St-Louis: what should this look like? Yeah. Yeah.

Dave Longley: Yeah, if we haven't done that work,…

Dave Longley: then that's an additional issue that I agree we need to go
through.

Patrick St-Louis: Probably do it separately as a sort of followup to this.
good because I'm assuming of when you verify a percentage you would like to
know why exactly if there's three credential and one of them specifically
then verify you would like to know which one.

Manu Sporny: I'm trying to look at the JSON schema to see the request body.

Dave Longley: On line 72 there says verify presentation response.

Manu Sporny: So that's in verify presentation response and components.

Manu Sporny: verify present. Maybe that is in that file.

Patrick St-Louis: Maybe verify presentation result which was right at the
bottom.

Manu Sporny: Yeah, hold on one second. Let me make sure it's not in the
file itself. so what was it? verify presentation response. Yeah, it's down
here and it refs the verification result. Is that right? Yeah. So that's
the verification result.

Patrick St-Louis: Yeah. …

Manu Sporny: What just happened? Yeah. Verification. No.

Dave Longley: It's the last one. Verify presentation result. actually,
yeah, it just said verification result.

Manu Sporny: It's verify credential result.

Dave Longley: So, there might be something mis linked.

Patrick St-Louis: it seems like it. Yeah. Yeah. Okay.

Manu Sporny: Okay, so it is in verify credential result and then it's going
to be verification result. we need to refactor this a bit so it's easier to
follow. So, here it is. And then the problem details. Yeah.

Dave Longley: Yeah, the issue here is that result will be you'll need one
of those for each credential. And so there's some error here in the
presentation results should have the result for the presentation and then
also credential results. And each one of those would be a credential
verification

Patrick St-Louis: So the presentation verification result just needs to be
reworked a little bit to make sure that it clearly displays not only the
verification,…

Patrick St-Louis: the proof of the presentation but also each credential,
right? All right.

Dave Longley: Yeah, that sounds right.
00:20:00

Manu Sporny: Yeah. …

Manu Sporny: can someone please raise an issue so we don't lose track of
this?

Manu Sporny: I'm afraid we're going to drop it on the floor.

Patrick St-Louis: Yeah. yeah,…

Patrick St-Louis: can open an issue.

Manu Sporny: I think Thank you. yeah. And we might need to discuss this a
little more to figure out what structure we want.

Dave Longley: Yeah, the pieces of information that we need are the in the
presentation response. We need the presentation which covers the case if it
was an enveloped presentation and then any result about the verification of
the presentation and then all of the credential results…

Dave Longley: which would include individual credentials if those were
enveloped. and the credential verification

Manu Sporny: Yeah. And…

Manu Sporny: how to structure those feels like it's a little bit of a
discussion. go ahead, Parth.

Parth Bhatt: Yeah, I think what Dave is mentioning that is documented in
the issue 284 the last comment and I do have a rough draft of schema what
it would look like I will update that but I was just trying to understand
whether do we actually need that schema update or not that's why I
mentioned in the I have that question do we need that schema for this
specific issue or not. Okay.

Manu Sporny: Yes is the answer.

Dave Longley: Yeah, I think the answer is yes, but let's link whatever is
remaining in 284 to the new issue that Patrick's raising and…

Dave Longley: we'll take it on as a separate issue.

Manu Sporny: And I think that's one of the reasons this was marked as high…

Manu Sporny: because it requires somewhat of a restructuring of the APIs or…

Patrick St-Louis: So, are we saying we're not opening a new issue and…

Manu Sporny: the results.

Patrick St-Louis: we're using this one instead?

Manu Sporny: No, let's open a new issue…

Manu Sporny: because we're going to have to …

Patrick St-Louis: Maybe a new issue specifically about the schema because
this one is pretty old. and…

Manu Sporny: yeah. Yes.

Patrick St-Louis: I feel like this includes and maybe open issue
specifically about the response schema.

Manu Sporny: What should the response schema be for verifying a
presentation? And then we'll link these two together. And then part that
would allow us to merge this current one without doing the schema updates.
And then we'll do the schema updates in the next one.

Manu Sporny: But we should, do them fairly close together.

Dave Longley: I just had one minor suggestion on here that I did right
before the call. There's a section in here that says an implementation can
put restrictions on the requests and then return that response code 413 or
429 that is like payload too large or whatever the other one is. But the
text without my suggestion gave a really specific thing you could do which
was restricted to accepting a single credential.

Manu Sporny: Yep. That's one of that.

Dave Longley: And I changed the text to just restrict it as needed. I don't
think we have to say there's only one way you can put this restriction on.

Ted Thibodeau Jr: Of course, I treat yours in a couple of different ways,…

Ted Thibodeau Jr: There's a question in my head of whether those are the
only two error codes that would be appropriate or others might be. So,
there's two options for

Dave Longley: Yeah, certainly I would think other error codes might be
possible,…

Dave Longley: but we've found that if we don't list them all, people think
that they can't do other things.

Dave Longley: Maybe we need a general statement about things like that.
This is similar to questions keep coming up with the VC API where people
ask can if I have some new option or I want to do something different or if
I want to augment something in my implementation am I allowed to do that or
not? and the answer to that is the spec only says the things you must do
for interop and if you're going to use those features they have to look
this So, I don't know. Clearly, we're defining for interrupt.

Dave Longley: We're expecting people to know at least these two codes.
certainly you could use other ones. I don't know how we want to address
that.
00:25:00

Ted Thibodeau Jr: I think I covered that in the second of my tweaks,…

Ted Thibodeau Jr: which is the bottom of the screen.

Dave Longley: Yeah, I see that.

Ted Thibodeau Jr: Yeah. Right.

Dave Longley: That one looks fine to me.

Dave Longley: I do know that further on we only talk about in the schema I
think we specifically call out 413 and 429. I think this is fine for this
PR,…

Ted Thibodeau Jr: What my Yeah.

Dave Longley: but I just know that there's this lingering issue…

Dave Longley: where that people keep wondering if they can do other things
that the spec hasn't said. And we might want to find a way to clarify that
for

Manu Sporny: Yeah, we can put that in the conformance section and…

Manu Sporny: just say your thing, conforms as long as it does the mandatory
things in the specification. but you can do things extra to that and you
will still be conformant.

Manu Sporny: Okay. do you have at least what you need to make another
iteration on this?

Parth Bhatt: Yes, I do. I will resolve Dave's comment and for notify
everyone for previewing again and we can go from there.

Manu Sporny: Okay, And then Patrick just opened the other issue on updating
the presentation verification response schema. Thank you for doing that,
Patrick.

Manu Sporny: Okay. those are all of our pull requests. if folks note, we
were at 35 issues three weeks ago and we're at 18 now. So, great job
everyone. Thank you for raising PRs. thank you especially to Parth who's
done a lot of you PRs to get these knocked down. We do have some floating
out there. I know, Eric, you're on break, soon. I don't know if you're
going to be able to get your PR in before that or thoughts. Okay.

Eric Schuh: Yeah, I was obviously hoping to get it in for this call and
then GitHub was down for a few hours this morning and that put a stopper to
some of that work. But I do plan on getting it in before I leave. at least
the one and…

Manu Sporny: All right. And then we'll

Eric Schuh: I might grab one of the other lowefforts as well and…

Eric Schuh: try to get another one out.

Manu Sporny: Okay, that sounds good.

Eric Schuh: But I won't be here to discuss next week.

Manu Sporny: Okay, that's fine.

Eric Schuh: So, yes,…

Manu Sporny: We can try and process it. can you raise it as a part of the
repo instead of in your private one? Do you know what I'm saying? the only
reason make sure to click the button that says that we can make updates to
your branch.

Eric Schuh: I will try to make sure I enable you guys to make changes. Yep.

Manu Sporny: Okay, Yeah, because otherwise we'll just be stuck and we won't
be able to, process it until you're back, which is fine. I mean, but it'll
lead to a delay in getting it in.

Manu Sporny: I think Joe, you've also got another one that's marked as high
effort. I don't know if you've been able to wait. Actually,…

Joe Andrieu: I have a high effort one.

Joe Andrieu: I think I have a low effort one.

Manu Sporny: never mind. This is this one you're assigned to, but this is
the one we were just talking about that Parth just took.

Manu Sporny: So, I think you're actively working on this. this is the one
that we just discussed. okay.

Joe Andrieu: Okay, cool.

Joe Andrieu: Yeah, I didn't even know I was on that one. I know I have the
use case one that we talked about last week that's still on my plate.

Manu Sporny: All I reassigned you to it part since you picked it up. And
great use case and sequence diagrams for complex flow. that's assigned to
you, Joe. And that's low effort.

Manu Sporny: Patrick, you've got one that is about revocation lists and…

Patrick St-Louis: Yeah. I don't think we wanted to have end points for
these.

Manu Sporny: then how does one follow actions on the status service?
getting a list, setting a status. Is this something we want to do? I can't
remember…

Patrick St-Louis: Or maybe we do.

Manu Sporny: because we have these APIs,…

Manu Sporny: I mean, meaning digital bizarre, I think we've got API
definitions for this

Patrick St-Louis: I remember that I did a presentation about the Yakapi
plugin that Ontario did and…

Patrick St-Louis: I remember we had a discussion about that. and I think
Dave made a third comment that it was fairly similar to what Digital Bazar
was doing, but I don't remember what we decided.
00:30:00

Dave Longley: Yeah, I think what we were looking at is if we're doing it
the same way or…

Dave Longley: we can get to agreement on doing it the same way, then it
made sense to specify it so that there was a common path for people to use.

Manu Sporny: …

Manu Sporny: this is assigned to you Patrick. I don't know if it would
definitely help Patrick if you're going to keep the assignment for Dig
Bazar to at least expose what our API and request responses are so that
Patrick can do a comparison to see how close they are. that might be the
next step. so who on the digital bazaar side can get that to Patrick? is it
public? I think it's public, isn't it?

Manu Sporny: Okay.

Dave Longley: It's in source available but I mean you got to read code to
do it. I Yeah,…

Patrick St-Louis: Is there some kind of schema or ation? Okay.

Dave Longley: that would be there too. I don't know when I can get to it,
but I can try to get to it or we can try to find someone else on the DB
side to fill that in.

Manu Sporny: It's just a matter of just pointing you at the code, I think,
Patrick. We just need to find the time and folks to do that. so that…

Manu Sporny: then you can make a determination that it's either close
enough and we can try and, define it or it's just kind of like, no, they're
totally different. So, let let's skip this for now and come back to it in a
year or two. okay. Yeah,…

Patrick St-Louis: We can definitely do the get list.

Patrick St-Louis: That's when you Okay.

Manu Sporny: that's true. Yeah, it's just an HTTP get, right?

Manu Sporny: Okay. do you want this to be continued to be assigned to you,
Patrick, or do you want Okay.

Patrick St-Louis: Sure.

Manu Sporny: And then I'm going to look at to see…

Patrick St-Louis: Yeah. Let's see how it goes.

Manu Sporny: if there's anything else here that we should Coyote, you have
a couple of items assigned to you, but I think you'll get to them when you
get to them. And then this one is Brian Richtor who hasn't been able to
make the call for a bit. What was the action on Raise a PR that details how
OID4 can be integrated with VC API exchanges. We do have it integrated at
this point, but yeah.

Manu Sporny: So, I'm gonna take Brian off of this because he hasn't been on
it for a bit. And then we'll leave an effort high because it probably is
just to dig up all the documentation examples and this is from two years
ago. I'm wondering if something like this should go in an implementation
guide versus going in the core spec just because of how fantastically
verbose ID4 VP or VCI is and it changing though it should be settling over
the next six months or so.

Manu Sporny: Okay, we can just Leave this for now, I think. so I think
that's largely I'm going to put this as effort, slow, and ready for which
it is. I think that's it for that item. We're going to switch over to VPR
Verifiable presentation request unless anybody has any other things they
want to discuss on VC API. All right. So, me get I want to save these. So,
here's VPR.

Manu Sporny: or the verifiable presentation request spec is effectively a
pretty thin lightweight specification. It has one definition of a query
language that you can use to the other query languages being presentation
exchange which is used in the old OID4 VC stuff that has been deprecated
and replaced with DCQL which could just be another type in here. B it also
defines things like did authentication talks about how you do logical and
ors in queries and then has a very outdated section on interaction types on
how you can and I don't know if this is overtaken by the protocols
00:35:00

Manu Sporny: the interaction type stuff.

Dave Longley: I suspect this isn't even used anymore.

Manu Sporny: Okay.

Dave Longley: We can Yeah, I think it's been overtaken by what's in the VC
API spec.

Manu Sporny: So, what that means then is that the vast majority of this
specification say for one, two, there's a question on do we want to keep
the seven pages in a separate spec or do we want to merge them into the VC
API spec. I think every time we've asked this question, it's come back like
no, we really should just keep it separate because the query languages are
supposed to be separable from C API. but of course you do need a query
language to run VC API at all.

Manu Sporny: so the first highle question is do we want to keep these
separate or do we want to merge at this point? Go ahead coyote

Kayode Ezike: Yeah, so I mean it seems to me that the way that the schema
has evolved in VC API request and responses is that it does expect it to be
a VPR anyways because most of the time the property will have to have
either a verified representation or verified representation request and so
unless we're thinking that eventually we'll continue to expand that
property space then it feels to me like these are intricately tied together
and so that's just a thought that I'm just realizing just the way this game
has evolved.

Kayode Ezike: So, I don't know what the upshot of that is, but it's just
something that I've noticed that could determine which direction we would
be taking this.

Manu Sporny: Yep, that's good input.

Manu Sporny: Go ahead, Dave.

Dave Longley: Yeah, the VC API spec clearly has this spec as a dependency.
it's just a question of whether it's easier to move these things through
the process keeping them separate and easier for developers to find and use
these specs as separate items or if they would be better served in a single
document. I think that's all there that really matters.

Manu Sporny: Is it easier to move it through two specs or one spec through
the process? It's definitely easier to move one spec through the process.
it's just gotten so painful and we felt this pain with, seven simultaneous
specs in parallel in the VCWG. There was just a lot of process overhead
that the editors and the chair have had to kind of churn through and a lot
of it just feels like busy work when you're doing it. so I think there's a
clear answer there which is merging it would be easier. I do want to point
out I think based on it we do support different credential types as what
are they called envelope presentations and envelope credentials. Right.

Manu Sporny: So it is possible and verify doc whatever things that are
enveloped credentials in the API so it's not VC only and then my
expectation is that for the query by example stuff this is just one
language there's no reason why this couldn't say DCQL either

Manu Sporny: I do I mean noting that I don't think we've worked through all
the details of that but I would be hesitant to say VC API only works with
query by example and that's it right I think VC API is supposed to work
with verifiable presentations and verifiable credentials and arbitrary
query formats but yeah just my two cents it feels like we're at a point now
where we could just merge and be fine and it would simplify things. But we
are concerned I think about also sending the wrong message to say that this
only works with your VCs and that's it. I see a lot of hands up. go ahead,…
00:40:00

Manu Sporny: Dave.

Dave Longley: Yeah, I think there's some conflation there.

Dave Longley: The VC format whether enveloped is unrelated to the query
language and so The dependency on VPR is in the choice of VC API for the
exchange protocol. That's where the dependency is. When you have a VC API
exchange there, you can choose from any number of protocols. whether that's
just the VC API exchange protocol or you can use OID for VC. that includes
O VCI or OID for VP, you could implement DIDCOM, you could implement
whatever other flavor of protocol you want to use to speak to the wallet.

Dave Longley: But if you're going to use the VC API protocol to speak to
the wallet, then VPR becomes a dependency in that particular set of
messages. That's where the dependency is on the spec. Otherwise, you can
make a VC API exchange that only speaks oid 4 and never use a VPR.

Manu Sporny: Yep. Good point. Patrick

Patrick St-Louis: there and I think it's something we discussed earlier but
we could rename the VC API spec for the VC interactions spec and that spec
would define an API and define queries and how to use them. don't know and…

Manu Sporny: Wait, was a proposal to take the VC API spec so this one Got
it.

Patrick St-Louis: rename it to a VC interaction And the VC interaction
specification would define API endpoints for internal interactions and it
would define queries for exchange.

Manu Sporny: All right. Yep. there's a discussion then on, what is this is,
renaming the spec making the name align more with kind of what it's
becoming or has become. go ahead, Coyote.

Kayode Ezike: So I guess my question I just want to make sure I clarify
something because you mentioned something that stood out to me which is
that for example the same place we have the type where we currently mostly
use query by example we have DQL what would have been exchange in the past
I guess that's a bit to what I was originally thinking is I guess I was
thinking that it was more so that those languages exist and if
implementations want to implement translations between those languages and
VPR then they can do that. I think I've seen examples of things like that.
But the idea that a query language could then be used as a type in another
query language is not entirely clear to me. but yeah, I don't know.

Manu Sporny: All right.

Dave Longley: it you sorry I was going to go on that is a strong indication
that we need more examples in the demonstrating that you can put whatever
other query languages you want to inside of VPR spec.

Dave Longley: The VPR spec is a wrapper around query languages and it
defines just one query type which is query by example but you could insert
DALE in here. You could put SQL as you were saying in here. and that is
different from doing a translation. the translation is done because other
protocols don't have the same flexibility and don't let you put other
things in there. so if you wanted to do DACA or presentation exchange over
oid for VP, there's a place where you have to put it just precisely that
query language. You can't put a VPR in there and then choose your type.
it's not wrapped up in its own layer and abstraction. and so you can do
these translations or you can just carry those things in a VPR.
00:45:00

Dave Longley: You both options are possible with this design approach.

Manu Sporny: Yep.

Patrick St-Louis: I was just going to say …

Patrick St-Louis: if we look at the CQL from the open ID for verifiable
presentations, but it seems like this could just be in the credential
query, maybe a bit of figuring out what array is what, but they really just
define here a redentry. if you go just above they define the credentials
and credential sets. but there's no reason why this block can just be
included in the credential query parameter and the type be set to digital
credential query language.

Patrick St-Louis: I think that would work.

Dave Longley: Yeah.

Patrick St-Louis: They've said, it's not about mapping it, but it's just
about saying in your verifiable presentation request, here's a type digital
credential query language and then, just f as you would process this
specification.

Dave Longley: Yeah, that's right. but what VPR does is it puts sort of a
wrapper around that so that it can travel and live as its own independent
message and you can put that into different specs while maintaining the
ability to have those different languages within that wrapper. the oid
forvp spec allows different query languages to be used but how you specify
it is as you said in the protocol layer not in the message layer if that
makes sense.

Manu Sporny: Yeah, which means you're locked into DCQL,…

Patrick St-Louis: because it's …

Manu Sporny: Effectively, you don't have the ability to switch out the
query language later without changing the protocol itself.

Patrick St-Louis: because is this the DCQL spec or is there an external
specification I think this is it here.

Manu Sporny: It's definitely defined here.

Manu Sporny: They've moved it in and out of the spec. This is in theory the
final version, but that's been said multiple times and yeah, it's like
today it's here, right? And I

Patrick St-Louis: Okay. PBD.

Patrick St-Louis: But, it's interesting because that's kind of related to
what we're discussing now, should we move the query stuff inside the VC
API, which this is kind of what they seem to have landed on in their own
model. not saying that the open ID for VP and the VC API are the same thing
but they definitely decided to merge the query stuff with the rest of the
exchange things going on.

Manu Sporny: Yeah, I think and agree it's not necessarily the same thing,
but at the open ID specs tend to shove a lot of stuff into a single spec.
usually the thing driving that is developer focused, what does the
developer need to see and what do they need to see all at the same time. I
think the design with the VC API or the verifiable presentation request
thing was just an assertion that look there are going to be many different
digital credential types out there and each one might have its own
different language and people might request multiple different credential
types at the same time using different languages which is

Manu Sporny: really terrible and bonkers and insane, but that is definitely
what we're seeing happen right now. Now, we're seeing, customers request
hey, I want to be able to query for an MDOC and a verifiable credential at
the same time in the same exchange. And it's just kind of like,…

Patrick St-Louis: Yeah, I've seen some wild stuff.

Manu Sporny: okay, I guess we'll, support that for you. Yeah. …

Manu Sporny: it's not necess I mean it is wild and it is also turning into
the default ask from these customers of I want to get an MDL and…

Dave Longley: Yeah. Yeah.

Dave Longley: If you want to max, right? Yeah.

Manu Sporny: and a VC at the same time

Dave Longley: If you want to maximize interoperability and allow more
wallets to show up and be able to use whatever they bring to the table, you
need to have that as a feature in your protocol. So you can say, yeah, I'll
accept MDO or I'll accept this or I'll accept that. And ideally that
happens in a single channel and then the wallet can make a choice. if it
gets complicated if you have to set up several different places for all
those different interactions to happen and then hand over all those
different options to the wallet and throw out, all but one of them when the
wallet makes their choice.
00:50:00

Dave Longley: So it's a multipplexing problem that is exists because there
are different formats and different query languages and ideally you can put
them together in one place because it's easier to manage the state for that
and…

Dave Longley: easier for developers to work with.

Manu Sporny: All right.

Manu Sporny: So, what I mean plus one to that. I guess my question is where
are we landing on this? Are we going to try to move it into the VC API spec
but make it very clear that just because the VC API spec is defining a
query language here's an example with DCQL as well to show you that it's
fine if you want to use that here's an example where you are requesting a
whatever M MOC and a VC at the same time

Manu Sporny: an on creds thing at the same time I guess the first question
is what do we think about moving I guess the first step would be minimizing
the spec and just deleting all the stuff that is defined elsewhere
duplicated elsewhere and that'll take us down to a seven-page spec and then
we can decide do we keep it separate or do we move it into the API spec go
ahead Dave

Dave Longley: It doesn't seem to me we've clearly articulated very many
negatives for combining the specs. it sort of architecturally makes sense
to clearly show that these are different primitives. And I think
architecturally if you looked at the oid for VP spec you would want to see
that DALE could be reused in other places and so it's sort of its own
self-contained bit. But if it's self-contained within another
specification, that's not really the end of the world. And it makes it
easier if you're going to use it in its sort of native place where it came
from to have it all in one spec. And if it helps get it through the
process, I think all that's fine.

Dave Longley: It does not seem to me like it's going to make too much of a
difference other than in the overhead to combine the things.

Dave Longley: And unless people can offer some really strong reasons not to
do that, then it seems okay to me to combine them.

Manu Sporny: Okay. …

Manu Sporny: go ahead, Patrick. Okay.

Patrick St-Louis: Yeah, I think I'm starting to think it would make sense
to combine them because it's true that if we decide to combine them, we
pretty much just need section two here. maybe rephrase a little bit and I
think that's kind of the natural succession of where we were at with
defining the workflows because you're going to use this in the workflows
and currently if someone reads the VC API spec and they want to define a
workflow to verify a presentation they'll need this sort of information so
I think it would make sense to have it

Manu Sporny: Cody

Kayode Ezike: Yeah, not to say add too much, but I think the only thing
I'll add to that is to be at a cautionary note is if we are positioning it
as expect that would be able to encompass multiple different query
languages like how does the scaling of that look like basically each time
that we add support for a new query language. I imagine it's not going to
just be like query and then point to the spec. there might actually need to
be some other things that need to be added to it to actually accommodate
the other query languages. And so that's the only thing I'll say if we do
go that direction is what does it look like to actually scale it out or if
that's even a concern if we don't really think there's going to be that
many query languages in the long run. She's a dot.

Manu Sporny: Yep. Yeah. all good input. Patrick, last word and then we'll
have to wrap the call.

Patrick St-Louis: Yeah, I was just going to mention here we don't need to
list every single query language. we can give some example and then say
that other ones can be used as probably as long as they have a JSON sort of
format and…

Patrick St-Louis: I don't know personally how many query language there's
going to be but I would not think there would be more than 10 realistically
but maybe I can be proven wrong.

Manu Sporny: Yeah, let's hope that they're not more than 10.
00:55:00

Manu Sporny: Ideally, there's so, sounds like we've got consensus to merge,
for now and then we can always split it out later on if it becomes an issue.

Manu Sporny: I think we can address coyote your concern and Patrick's
concerns by basically saying look this is an extension point we could
establish a registry or whatever for the different query languages that you
can put in here and we can give examples of DCQL and query by example and
say others are more than possible and kind of that hopefully would be
enough to let people know that we're only suggesting people

Manu Sporny: use query by example. We're saying others are possible and
we're designing for that. that is it for the call today. Thank you everyone
very much for the input. I think the next action on the VP request spec is
to try the merge see how it looks for section two and then we'll go from
there. Either it'll work out well or it won't and we'll just go back to
what we have right now. if the merge goes we'll transfer all the issues to
the BC API spec. and if not, we'll keep them separate. Okay, I think that's
thank you everyone again. have a wonderful rest of your week and we will
meet again next week. Take care. Bye.
Meeting ended after 00:56:35 👋

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