- From: <meetings@w3c-ccg.org>
- Date: Tue, 29 Apr 2025 15:16:52 -0700
- To: public-credentials@w3.org
- Message-ID: <CA+ChqYeQgggZnQo4FGYJqBkvJTUEnVj94Nb=3oK5VTLLZ18Yfw@mail.gmail.com>
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.*
Received on Tuesday, 29 April 2025 22:17:02 UTC