[MINUTES] VC API 2025-04-29

VC API Community Group Meeting Summary - 2025/04/29

*Attendees:* Dave Longley, Eric Schuh, Joe Andrieu, John's Notetaker, Manu
Sporny, Parth Bhatt, Patrick St-Louis, Ted Thibodeau Jr

*Topics Covered and Key Points:*

   1.

   *Review of Open Issues and Identification of Easy PRs:* The meeting
   primarily focused on reviewing open issues tagged "ready for PR," aiming to
   identify and assign tasks requiring minimal effort (under an hour). Manu
   Sporny led this effort, categorizing issues by effort level (high/low).
   2.

   *Issue #XXX (Integration of OpenID4 with VC API):* This issue, deemed
   high-effort, discusses the integration of OpenID4 and its relationship to
   credential delivery protocols. The discussion clarified that the VC API
   should support various protocols for delivering credentials, separating
   issuance from delivery mechanisms.
   3.

   *Issue #YYY (Holder API Security):* This issue involved clarifying
   security mechanisms for various endpoints. The discussion centered on
   expected callers and appropriate security measures (OAuth, ZCaps,
   capability URLs). A new issue was created to address remaining questions on
   securing exchange endpoints using ZCaps, particularly in scenarios without
   pre-existing relationships.
   4.

   *Issue #ZZZ (Revocation Lists):* The group discussed whether the VC API
   should define how to host revocation lists. The conclusion was that the
   existing bitstring status list specification sufficiently addresses
   this, with the API pointing to this standard. A possible future enhancement
   was suggested: adding endpoints for creating and managing status lists.
   5.

   *Issue #AAA (Verification Methods):* This issue was quickly resolved.
   The group determined that the requirement for issuers to use consistent
   verification methods for credentials and revocation lists is already
   covered by the bitstring status list specification.
   6.

   *Issue #BBB (API External Design):* This issue involved clarifying which
   roles call each endpoint and on which components the endpoints are exposed.
   Eric Schuh confirmed that this work is underway, updating sequence diagrams
   and clarifying terminology. A minor point of discrepancy remained regarding
   endpoints called by two parties in different locations.
   7.

   *Issue #CCC (Verification of Presentations):* This high-effort issue
   concerns presentation verification, including verifying embedded VCs and
   providing detailed verification results.
   8.

   *Issue #DDD (Exchange Service):* This issue was deemed addressed, given
   the existing documentation on workflows and exchanges.
   9.

   *Issue #EEE (Get Credentials Endpoint):* The group decided to maintain
   the get credentials endpoint, despite earlier consideration of removal.
   10.

   *Various Other Issues:* Several other issues were discussed and
   categorized by effort level, some marked as low-effort and suitable for
   quick PRs. A few high-effort issues requiring significant design work were
   identified.

The meeting concluded with the agreement to skip the following week's
meeting due to unavailability of several participants.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-04-29.md

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

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

Manu Sporny: All right, let's go ahead and get started. This might be a
short call. I noted last week that if we didn't have any PRs, we would end
the call early. And I haven't had a chance to check to see if we have new
PRs. the other thing that we might do is take some time and identify easy
PRs for people to raise. I know that I was taking a look at it and my eyes
were glazing over around 40 issues with, ready for R on them. So maybe
going through them and noting which ones should take no more than an hour
to raise a PR on It'll certainly help me at least identify some PRs that
could be raised. so I think that's largely the agenda today.

Manu Sporny: are there any other items that we'd want to add to the agenda?
Anything else we want to discuss today? All right. I'm now noting that I
was not able to fix that bug in the last PR473 longly. I was on my list. I
just did not get around to it. So, I'll do that and merge that PR. But it
does look like we don't have any new PRs this week. so what I'm going to do
is share my screen and start going through PRs that might require less than
possibly an hour worth of work.

Manu Sporny: and I will just process these in oldest to newest order.
Getting any feedback on clarification we might need for a P Any other items
to about talk through before we start processing these? All right. I will
start at the oldest one then. we had a discussion around this in April last
year. and the next step here was to raise a PR that details how open ID4
can be integrated with VC API exchanges. This is not an easy PR to write.

Manu Sporny:

Patrick St-Louis: Is it me or it seems kind of unrelated to the title? I'm
just wondering how it got too like that. That's the result of the Yeah.

Dave Longley: I would guess that the original question was kind of poking
at why you would hand a credential to anyone other than the holder. And we
probably meandered through that you can have many different protocols for
actually getting the credential to the holder. And so it's important to
have an architecture that supports separation of concerns…

Dave Longley: where you issue the credential and then you put it into a VC
API exchange which then speaks whatever protocol is necessary to get it to
the holder.

Manu Sporny: Yeah. …

Manu Sporny: that's where we landed after lots and lots and lots of
discussion. this is not an easy PR. this one's going to take, hours to put
together. So, I'm going to skip to the next one. or I guess we could do
effort high label and give that a scary color.

Dave Longley: We don't want to discourage people from working on them.

Manu Sporny: And then how about a dark blue? Is that not Yeah.

Dave Longley: Yeah, that's better.

Manu Sporny: How about a purple?

Dave Longley: You're going to be rewarded. Yeah.

Manu Sporny: Purple. You might come out of it a little bruised, but you'll
be fine. How's that? It's not fire, but And then we'll do green here for
low. And I'm not going to try to it'll either be high or low. and I did not
label that. all right. So that's high effort and holder API security not
defined sufficiently is the next one.
00:05:00

Manu Sporny: I guess it's ready for PR, but let's see. Joe, you volunteered
to write a PR on Which endpoints need authorization by whom? You raised a
couple of questions. I feel like we got to this at some point,…

Manu Sporny: though. Yeah,…

Joe Andrieu: This may have evolved into the work Eric's been chewing on.

Joe Andrieu: I mean, we both have, but with the sequence diagrams and
specifically the callers because part of the question was resolved in the
direction of if we understand who is calling which component in the
architecture, then we can understand the security better. And that kicked
off a whole chunk of work. and…

Manu Sporny: I'm just wondering.

Manu Sporny: I thought Eric went through and No, this wasn't it. It was
maybe this Hold on one second. Sorry, I'm Yeah,…

Joe Andrieu: Eric isn't with us, I thought.

Manu Sporny: let me look at tags security.

Dave Longley: I would think we Yeah.

Manu Sporny: There we go. Yeah, we've got expected callers now and

Dave Longley: And I would expect we just more or less have two different
security categories. One is either ooth Zcaps or something equivalent and
then capability URL.

Joe Andrieu: I think we're missing

Dave Longley: I think all of the calls it were nothing at all,…

Dave Longley: open-ended.

Manu Sporny: Yeah. …

Manu Sporny: we've got this thing that says this is the type of security
mechanisms that can be used to what's the word secure the endpoint and then
this is the entity that's expected to call it and we did that or I think
yeah Eric Joe you did that for all of these …

Joe Andrieu: seen the component in this.

Manu Sporny: what component is it expected to be part of?

Joe Andrieu: I guess ml is the issuer component. Is that right? So maybe
it's just filebound.

Manu Sporny: Yeah,…

Joe Andrieu: Right. These are the endpoints on the issuer component.

Manu Sporny: I think there might be a couple where you're expected to be on
two different components or it can be on two different components. I can't
remember.

Manu Sporny: trying to figure out if this is addressed or not. And it looks
like we've addressed at least two of the items. let's go through this list
of questions. so we know who the expected callers are. So that kind of
answers these kind of who's the expected caller and what is the security
mechanism used and that is covered by what we have in there already.

Dave Longley: Something we could put in this issue is we could say we need
all of the components to have the endpoints checked for these three
properties.

Dave Longley: And so whoever's going to take this issue needs to check and
see that they're all set. And if they're not all set, the PR sets it for
the ones that aren't set. And then that's it. And maybe that's a loweffort
PR.

Manu Sporny: Yeah, I'm trying to make sure that all of Joe's questions are
answered before we do that.

Manu Sporny:

Manu Sporny: Plus one to that, Dave. I'm trying to see if the rest of Joe's
questions are answered if we do that.

Joe Andrieu: Yeah, I don't think we have an answer to number four.

Joe Andrieu: I

Dave Longley: I don't know that I understand for free I Bye.

Manu Sporny: I think we do.

Joe Andrieu: So the question is when a third party uses an exchange URL

Manu Sporny: I don't know if we've written it down. Maybe that's what you
mean.
00:10:00

Joe Andrieu: Because it was given to them, right, as the output of
something is that secured in any further way?

Dave Longley: Yeah. in terms of the communication channel itself,…

Joe Andrieu: That's the unknown,…

Dave Longley: no, there's no ooth or anything like that. It's provided by a
capability So only someone with the URL can access it. And then correct.

Joe Andrieu: but anyone with a URL can. There's no counter signing. There's
no other identity check.

Dave Longley: And if you want any additional authorization or identity
checks, you do it within that channel. So you could have your VP request
credentials and then they could reply with a VP that signs over a challenge
and whatever credentials you ask for.

Manu Sporny: Here we say that you can do,…

Dave Longley: There's no existing relationship is probably the way to think
about it.

Manu Sporny: But you can optionally set extra things on it…

Manu Sporny: if you want to, meaning ext extra authorization mechanisms on
it.

Dave Longley: You could do that anywhere at any time.

Dave Longley: So we need to be careful with that. I think what we want to
say is what are the requirements of EC API and for this there's no
expectation that you would need to add that…

Dave Longley: but of course you could always add that if you wanted to but
you're not going to get interoperability with someone bringing a random
digital wallet to your exchange you do not have any existing relationship
with them and they will not be able to use your thing. So you're really
creating a closed ecosystem if you do that in this particular place.

Manu Sporny: Yeah. …

Manu Sporny: what do we want to do about this part of OAS?

Joe Andrieu: Hold on,… Dave. Could you restate that? I did not follow the
logic because it seemed be the inverse to Okay.

Joe Andrieu:

Dave Longley: If you're handing someone Yeah.

Dave Longley: If I hand you an Exchange URL as a capability URL and you try
to use it and you need additional authorization, the question is how did
you get it? And so you must have a existing relationship with me by which
you could have gotten that authorization. How would you get an OOTH access
token for example?

Joe Andrieu: Sure, but I want to use the Zcap and…

Dave Longley: So you're going to just have to go through some other
protocol and establish a relationship with me in some other way to get that
token.

Joe Andrieu: it seems like that's allowed…

Dave Longley: If you want to use a Zcap, I also

Joe Andrieu: but there's nothing to do here about it.

Joe Andrieu: In other words,…

Dave Longley: Yeah. Yeah.

Joe Andrieu: the URL I'm going to give you, you won't know that you have to
do a Zcap until you ask for it and the interact tells you to. Is that what
you're saying?

Dave Longley: And I'm saying a little bit further, which is you won't know
what you need to use unless you have a existing relationship, and you won't
have the ZCAP to use it unless you have a pre-existing relationship where
it was delegated to you.

Joe Andrieu: So, I think what we need to be able to say somewhere in here,
I don't know what edits we might need in this YAML file, but I don't think
it's clear how I would use a Zcap to secure one of these channels.

Dave Longley: When we say one of these channels, are you being specific
about an exchange endpoint?

Joe Andrieu:

Joe Andrieu: Yes. I'm saying I want to post to a workflow exchange endpoint
and…

Dave Longley: So, if you wanted to secure an exchange endpoint using a
Zcap, I want to dig a little further into your question. I'm presuming
you're not saying how would you use G Zcaps generally. You're saying Right.

Joe Andrieu: I want it to be ZCAP enabled and the spec doesn't tell me how
to do that. I can believe your assertion that you can do it with the
current spec. It's just not detailed. And I'm making the case that I think
if we detailed that that would and maybe not just for Zcaps, but how would
you do any maybe that's an implementation guide kind of thing. but I feel
like I want to secure it and…

Dave Longley: Yeah. Yeah,…

Joe Andrieu: I'm not giving any affordances for how I might

Dave Longley: I think that's true.

Dave Longley: I don't know that we yet have an interoperability use case
where we would want that to happen because that seems to depend on having
this other relationship. It's this and I don't think that's different for
any of the other things where stuff is ZCAP or OOTH protected for the
internal endpoints. We don't say ken. Here's where you go to get your
delegated Zcap. that's left to sort of administrative space where you
assume you have a closed ecosystem and…

Dave Longley: that's going to happen. and maybe what you're talking about
Joe is a little bit different. I don't know what the sort of decentralized
component where you don't know who you're interacting with where that even
would come in.
00:15:00

Joe Andrieu: I'm not sure that's the right focus for…

Joe Andrieu: what it's worth, but maybe I'm just not processing as deeply
what you're talking about. And I don't want to take up too much of our call
today, although this is interesting. it doesn't seem to me that it's the
thing I'm trying to deal with is not about how did I get the Zcap or how
did I bootstrap the existing relationship. It's that I want to use the VC
API and…

Manu Sporny: Okay. Q Ted

Joe Andrieu: it says I exchange credentials over exchanges. I want to
secure that exchange with the VC API and it's not clear how to do it. Thank
you. Yeah.

Ted Thibodeau Jr: We decided a long time ago that we were designing for
crossing security boundaries.

Ted Thibodeau Jr: So everything should have a way to authenticate. because
it's usually relatively easy to turn that off when you're in a situation
that allows for that,…

Manu Sporny: instead Dave.

Ted Thibodeau Jr: but it's pretty hard to bolt it on after the fact. That's
it.

Dave Longley: Yeah, to respond to Joe's point, I think if you're asking how
you ended sort of with your question, you ended with a desire to secure an
exchange endpoint with a ZCAP and so you ended with that and my thought was
why do you want to do that? And if you want to do that, can you use an
unsecured exchange to obtain that ZCAP where you would have provided an
appropriate credential and receive the Zcap in response and then you can go
use that Zcap at another exchange. It seems to me like you can the maybe
puzzle you put these pieces together in that way to accomplish your goal.

Dave Longley: but ultimately you were asking it seemed to me like there was
an implication that there was an existing relationship but we'd have to dig
if we want to put this in the spec we'd have to dig out how you establish
that relationship in the first place. And one way to do that is with an
unauthorized exchange then in the exchange a credential, get a Zcap and
then you take that ZCAP somewhere else.

Joe Andrieu: Manny, were you on Q? I thought Yep.

Manu Sporny: Sorry, I was talking a lot.

Dave Longley: Yes.

Manu Sporny: Thanks, I put myself on the queue to say we've got to move on.
I'm going to try to figure out what was the resolution we came to. identify
which endpoints need authorization and by whom. I think we've done that.
the only endpoints that doesn't have odd Z is status checking and the
workflows and exchanges and that's definitely what we have in there but we
haven't answered your question we still have discussion on this so we did
this thing I think that's done overcome by times and PRs this part is the
part that we probably need to

Dave Longley: Can we just open a new issue, Joe, like to move to transition
this to the specific question you have and…

Dave Longley: so we can pick at it there? let's do

Joe Andrieu: Yes, I will do that.

Joe Andrieu: I'll put my comment here and then I'll go create a new one.

Manu Sporny: Okay, great.

Manu Sporny: Can I close this?

Manu Sporny: As you do that, I don't think it'll affect anything.

Joe Andrieu: You could or…

Joe Andrieu: I'll just close it with my comment. I mean

Manu Sporny: Yeah. Let's say the group discussed this. 20250429 call and
agreed that we had made the changes required in this one but more
discussion came up which will be p per pursued in a separate issue.

Manu Sporny: which Andrew will raise. Okay, Thank you, Da this one is All
closed one issue, open All right, one. at least we're closing issues,
Should this API define how to host revocation lists? let's see. Talk about
status verification in the VC API. Point to a normative status revocation
mechanism from the data models and protocols required to implement the
revocation mechanism as well as guidance to maximize privacy.
00:20:00

Manu Sporny: Verify should not contact the issuer to check status and
should get that information from the holder. we have a status changing
mechanism now don't we? This is really old. let me check real quick. status
server.

Dave Longley: There should be APIs for I think it's like something
slashstatus for changing a status. I don't know how out of date it is in
the spec.

Manu Sporny: So we do point to bitstring status list.

Manu Sporny: So we do Yeah,…

Patrick St-Louis: I think there's an end point …

Patrick St-Louis: if you it's in the issue. Yeah.

Manu Sporny: there's a status server. Yep. And update status. It's kind of
messy but needs to be updates the status. I don't know. I mean I feel like
we do talk about status and revocation the VC API we point to a normative
status revocation mechanism from the spec which is the bitstring status
list as a concrete example. we do have the endpoint on how you update the
status though it could always use more work. we do have all the data models
and protocols required to implement the mechanism.

Manu Sporny: And then the guidance around privacy is in the bitstring
status list spec as are these recommendations to not phone home and…

Manu Sporny: get the status information from the holder that's in bitstring
status list.

Patrick St-Louis: Wonder if the question is more about creating the list
and…

Patrick St-Louis: sort of managing it assigning indexes and…

Patrick St-Louis: stuff because right now there's an endpoint to update it.
there's no endpoint to return a status list. yeah.

Manu Sporny: Yeah, but I mean is that true?

Manu Sporny: I mean when you issue something through an instance, it gives
you a URL. The presumption is that the issuance service created that URL
and you if it's using the string status list. So I think that part Yep.

Patrick St-Louis: Yeah. the VC API is meant to manage credentials.

Patrick St-Louis: So the only thing I could see missing is maybe an
endpoint that creates a status list but even then this would depend on
which status specification you use statuses being only one. so I think just
the endpoint to update the status is the minimum that we would need here.
Yeah.

Manu Sporny: And we have that, Dave, you're on the queue.

Dave Longley: Yeah, I kind of agree with that.

Dave Longley: Because bitstring status list is a standard, we might want to
say here are the endpoints you can use to implement that. And we would want
one for getting a list,…

Dave Longley: and updating a bit on a list. And those things would all be
on the status service which is different from whatever is on the issuance
Service.

Manu Sporny: I am wondering if we need to define this at this point or if
we have something that's good enough me meaning we can always standardize
more and write more down. I'm wondering what the benefit of doing that at
this point would be other than a okay …

Dave Longley: So now I will get on the queue.
00:25:00

Manu Sporny: but if we need to do that fine it's just more work and more
time before we get this thing shipped. go ahead Patrick.

Patrick St-Louis: Yeah, I was just going to say I know they did a status
list plugin which is a set of API endpoints to do all these things but a
bit more extensively they go into assigning bits and all these things. if
it's relevant on the next VC API just have an insense and we can look at
these endpoint and decide if we want to include this or not. I would no
just …

Manu Sporny: Okay. I mean that Yeah. Sorry.

Patrick St-Louis: if there could be some similarity with that I think would
be good.

Patrick St-Louis: I'm mostly seeing I thinking a bit, this is just I don't
know if we need it, but creating it maybe. I mean, yeah, that's it. Sorry.

Manu Sporny: Okay, thanks Patrick. No problem. Dave

Dave Longley: So the benefit of writing it down would be interoperability,
the ability to swap out a different status list from a different provider.
And I think all we would need to do would be to document creating getting a
list, and setting a status. And all of these would be on a status service.
And if those were all defined, then presumably anyone providing those
interfaces could be a plugin to someone who needs a status service.

Manu Sporny: And if there was ever a medium effort I'm going to say this is
high effort just because it requires content to be written, endpoints to be
defined, that sort of thing. Patrick, you are welcome to present that
during the next call. I think that would be good. I don't know if we have
any other that'll be good. Let's lead off with a presentation, Patrick, on
it might not be next week because I'm not going to be here, but the week
after.

Manu Sporny: Yeah, let's lead off with the presentation that you do,
Patrick, on what Ontario did and then, we can hopefully get that down into
someone going, I know how to write this PR. Okay, that's that item. moving
on to the next one. Get P API. All right. So, this is an easy PR. It's add
this language. Issuers should use the same verification methods and crypto
suites to protect both the verifiable credential as well as the revocation
list.

Manu Sporny: Go ahead Dave.

Dave Longley: Is that not in the bitstring statusless spec already?

Dave Longley: Seems like it would be in that not in the BC API spec.

Manu Sporny: Yeah. Yeah,…

Dave Longley: And if not, it seems like it's a VC API. I mean, it's a bit
string status list bug, not a BC API bug.

Manu Sporny: Other people want to look at the same time.

Patrick St-Louis: I'm pretty sure I recall reading something similar. I
think it might be actually the BC data model like the verification steps.

Manu Sporny: Yeah, that sounds

Dave Longley: I think I found a link to it in the bitstring statusless spec
says a link to it in the chat. When securing a VC that contains a reference
to a bitstring statusless credential implementers should use the same
securing mechanism with the same cryptographic parameters and…

Manu Sporny: Excellent. Yep.

Dave Longley: the same media type.

Manu Sporny: Great. Thank you. All right. And that's in TR.

Dave Longley: There are of course minor exceptions to that.

Manu Sporny: Yeah. Which is why it's a should. All right. this has been
addressed to this text. I think All right, I'll close that. Hooray. This is
turning out to be more rewarding than I was expecting, so that's good.
00:30:00

Manu Sporny: We're actually closing issues because we addressed them. Why
don't we just say API external start designing us? Did we cover this
already?

Dave Longley: Not in this meeting.

Manu Sporny: No. Yeah. Raise a PR that notes two things. For each endpoint,
which roles are expected to call the endpoint and which components those
endpoints are expected to be exposed on? I think we've done this. Eric did
that. I think Joe, this is exactly what you said. I guess the component is
the,…

Manu Sporny: issue. The only concern I have is that some of these endpoints
might be on two different components, but I think we can just handwave
around that until someone complains. go ahead, Joe.

Joe Andrieu: Yeah, that didn't mean to be applause.

Joe Andrieu: I meant to raise my hand. I just wanted to cue to ask Eric, I
think all we're working on here is the sequence diagrams that have the new
names.

Joe Andrieu: But I want Eric to comment rather than me guess.

Eric Schuh: Sure.

Eric Schuh: Yeah, for the use cases update, we're definitely updating the
sequence diagrams and at the same time doing a general language pass
because the last major pass at the use case document used a bunch of terms
that we have since moved on from basically. So, it's mostly just updating
that as well as some diagram updates to include things such as the workflow
coordinator service or the workflow service that wasn't around in the last
pass of the use case document.

Joe Andrieu: Do we So maybe I misspoke,…

Manu Sporny: All right.

Joe Andrieu: I had thought we had in our queue a PR for the main spec here,
not just the use case document.

Eric Schuh: We had talked about it, I think. I don't know…

Manu Sporny: No, it's in here.

Eric Schuh: if Okay.

Manu Sporny: Hold on. So x expected caller is who's calling it right and…

Eric Schuh: Yep. Yeah,…

Manu Sporny: so which roles are expected to call the endpoint that's x
expected caller and…

Joe Andrieu: right that the YAML is the component. Yeah.

Manu Sporny: you did that across I think all the APIs and then which
components those endpoints are expected to be exposed on is what you said
at the beginning of the call Joe issuer. Yep. Yep.

Eric Schuh: I do remember something I think that fell off my plate, but I
think that in those tables, we had an endpoint that was expected to be
called by two different parties, at different, locations. and I think there
was just y, some conflicts as far as the tables looked identical, so there
were some clarity things that I think I did want to get in. I'd have to go
pull it up real quick. Yeah, I don't see any reason for…

Manu Sporny: But I'm wondering if we need to couple it to this one. So this
issue was just why don't we just say this API's external and start
designing? And it's like it's not just external, it's a combination. And we
I think stated that Okay.

Eric Schuh: what I'm talking about to be coupled to this issue.

Manu Sporny: That's all I was.

Dave Longley: Did you mean to mark that as PR exists and…

Dave Longley: leave it there since it's closed?

Manu Sporny: I thought I closed it. And I usually mark things with exists.
If we raise a PR to address the issue and then I close it.

Dave Longley: Okay. Yeah.

Manu Sporny:

Manu Sporny: Did that make sense? Basically going from ready to closing it
basically signals at least to me that we did nothing about it.

Dave Longley: Just Okay.

Manu Sporny: Whereas if it's marked with PR exists it means hey we raised a
PR and I guess we say that here and then we close it. I do that because
sometimes I go and I search based on closed issues to make sure, see if we
had any issues that we closed without raising a PR for them because those
always come up when you go to defend it in front of the W3C management. Why
did you not raise a PR for this specific, issue. Anyway, that's over
explaining. all right. Let's see.

Manu Sporny: Next one. Does verifying a presentation include verifying its
ready for when verifying a presentation verify all of the VCs in the
presentation as well. There's a return ensure it's possible to understand
Which proofs for each VC was checked? Factors verifications for valid until
it's a little changed a bit since then. Errors related to each one.
Implementers can checking options disable highlight APIs compositional Okay.
00:35:00

Dave Longley: I would recommend just marking this high and going to the
next one.

Manu Sporny: I guess we didn't. Okay, just move What does the exchange
service do and who uses it? I think we wrote a lot about this. we talked a
lot about this 2023.

Dave Longley: Yeah, I definitely think we have raised PRs.

Manu Sporny: Go ahead.

Dave Longley: We have a whole section in spec on workflows and exchanges
now.

Manu Sporny: Yeah. I'm just seeing if we say what we were going to do. we
discuss this some of the content above is going to have to find its way
into specification ready for PR so it could be incorporated when we
document exchangers and exchanges so we've definitely documented it we
changed the language so these are I think I don't know Corator.

Manu Sporny: Where the hell is this? I'm not seeing anything that's jumping
out as we did not document it. We Exchangers got changed to workflows,
right? Yeah.

Dave Longley: That's right.

Manu Sporny: Yeah, don't we? We have this giant section on workflows and we
explain a lot in here. mean all of this. I think we're good on this one
unless somebody disagrees. All right.

Manu Sporny: So Where is this? Okay, that one's getting closed.

Manu Sporny: clarification of get credentials endpoint. We should be open
to remove get endpoint from the specification until there's more implement
interest in the functionality. I'm just going to have to keep this C API
spec open here because keep closing it. I think we still have this in the
spec. isn't there Get credentials. There's this endpoint. Yep. And think we
said we're going to remove it until somebody says So, this is no, not light.
00:40:00

Manu Sporny: Low.

Dave Longley: Low B.

Manu Sporny: There we go. All right. Let's effort can issue credential
proof property. Add text says multiple proofs are required. An instance
will add multiple proofs in one go. showing it's attached proofs VCs that
contain existing proofs instance can be configured to reject default
behavior already contains okay all right so I don't think we have this in
here but this is kind of a effort low thing I think does anyone disagree
okay then let's

Manu Sporny: We'll raise a PR that does the following in the workflow
section. We did the concept of workflows. We said that you can configure a
vote workflow. Those APIs are out of scope. We did the exchange URL thing.
We documented what you get back and clarified that you read all of these
and…

Dave Longley: I read that bullet point. I think we did all of those things.
I read all seven of those.

Manu Sporny: you think…

Dave Longley: I think we did all of those.

Manu Sporny: what if we don't trust you and we want to check ourselves.

Dave Longley: That's fine. I'm just offering one opinion.

Manu Sporny: All right. Looks like wait. Also consider multiple PRs have
been raised that resulted in this section which achieves the PR listed by
this issue and let's see okay all right and that exists

Manu Sporny: And then we're going to close that issue verify how VC API is
different from OID4. I don't think we've done this yet. And agnostic. let's
say this is a effort high one because we want to be careful of what's said
and that will take quite a bit of word smithing.

Manu Sporny: Add call back URL to exchanges.

Dave Longley: Equation market

Manu Sporny: All right. That's that item. And then how the structure
response metadata

Manu Sporny: H. This isn't even ready for PR. What do we want to do with
this? Not talk about it today. But okay, I'm just going to move on since
that one actually is not ready. Update OAS to latest version. This I do not
have the same belief that it is going to be low.

Dave Longley: It should be low, but it's probably high.

Manu Sporny: I agree with your statement completely. let's see. Should we
have Okay. what's this typo?
00:45:00

Dave Longley: This should be low maybe.

Manu Sporny: Yeah. Did we already do it anywhere work under the property ID?

Dave Longley: And I mean if it's low that we'll find out. We can delegate
to whoever's checking it.

Manu Sporny: Didn't we change this to local ID or something like that?
Local workflow ID. Simple as f***.

Dave Longley: This is probably for the full URL.

Manu Sporny: All right, I'll just mark it as support for advanced BBS like
synonyms.

Dave Longley: Just yeah, if we just mark it low, someone will come in and
figure it out.

Manu Sporny: I'm going to skip that one. All right. Date credential to PR
should be raised to make the credential ID endpoint return verifiable
credential to be consistent with other APIs. Didn't we fix this?

Dave Longley: Seems like we would have.

Manu Sporny: Wait here. isn't this the get thing that we said we were not
going to fix?

Dave Longley: I don't think so.

Manu Sporny: credentials ID. Can't you get based on that? hold on. So, is
Get credentials. Is it? No, it's not this one. Get a specific credential.
We're not getting rid of this one, right? Yep.

Dave Longley: Yeah, we're not getting rid of it, but it looks like it has
not been updated to do…

Manu Sporny: So, this is Yeah,…

Dave Longley: what was requested.

Joe Andrieu: Which component is that on?

Dave Longley: That's on the issue. That one is on the issuing one. I wonder
if that one is duplicated to the holder service. I don't know.

Manu Sporny: these are not really split up by component, are they?

Joe Andrieu: No, I think the yaml are but I don't think this is…

Manu Sporny: Mhm. Yeah,…

Joe Andrieu: although this section is generated by that YAML Okay.

Manu Sporny: it is. I mean the issuing section uses issuer.l. The verifying
section use verifier.l and presenting I think uses holder.l and this one
doesn't have a get. Yeah, this is weird.

Manu Sporny: the schedule specific presentation is that I think we did that
for the trace folks and I don't know if they ever ended up using so is that
the one that we're that one's effort low. needs to be looked into that
example.

Manu Sporny: This one's effort high. It's an example, but it's going to
take a while. It'll take work to figure out what that example should
challenge and domain. PR should be raised to create two JSON schemas for
the proof field. One that is used in BCS and one that is used in BPs. The
domain and challenge properties must only be used on proofs that are found
in VPs.

Dave Longley: I feel like we did this.

Manu Sporny: And yeah, me too. great. Only 44 instances. That is in VC,
which is wrong.

Dave Longley: I feel like we didn't do this.

Manu Sporny:

Manu Sporny: That is correct. this is getting a specific credential. This
one's wrong too, right? Because it's not nested in verifiable credential.
00:50:00

Dave Longley: Yeah, just it's probably reasonably low effort to do. You
just got to split the things and then like them properly.

Manu Sporny: Because yes, it will just be a slow add presentation schema
option to workflow step. We don't have this effort.

Dave Longley: In

Manu Sporny: What is the presentation schema? this might know. Yes, it's
slow. That I have to keep refreshing because I don't trust GitHub to save
the label. Should issuer service be directly called? Eric, you should have
something by last July.

Manu Sporny: We're August. what is this? PR needs to be fixed to fix the
code that autogenerates the table.

Eric Schuh: Yeah, this was the thing I was talking about earlier.

Eric Schuh: That the table had some ambiguity I believe that I completely
forgot about…

Manu Sporny: Okay.

Eric Schuh: until I was looking through the issues a few minutes ago. So,
it's as far as effort probably I'd say it should be low effort for the most
part…

Manu Sporny: Low or high. Let's go. Okay. Got it.

Eric Schuh: unless there's something unexpected. it's more about me
remembering to do it. So now that it's back on my plate. hopefully by the
next call I can get something in. If not the one after that because I am
out on vacation next week.

Manu Sporny: Sounds good. and I think we will probably cancel the call for
next week. I'll be out as well. Okay.

Manu Sporny: I think that is all we're going to get to today. We're at
time. thank you everyone for going through and processing them. hopefully
the effort low things now people know what to look for if they want to
pluck off something that should only take, an hour at most to raise a PR.
Okay, that's it for the call this week. Thank you everyone. Appreciate the
time. And, we are not going to have a call next but we'll start up the week
after that. okay, that's it. thanks everyone. have a wonderful rest of your
week and we will chat again in two weeks. Take care. Right.
Meeting ended after 00:53:02 👋

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