[MINUTES] VC API 2025-06-17

VC API Community Group Meeting Summary - 2025/06/17

*Topics Covered:*

   - *Community Updates:* Good progress on closing low-effort issues (13+
   in last two months). Focus shifting towards PRs for these issues, aiming
   for a new working group charter in August. Increased interest in education
   and first responder use cases.
   - *Poll Request 487: Accept 2011 Status Response:* Discussion centered
   on accepting both 2011 and 204 status responses for exchange and workflow
   creation. A compromise was reached to accept both, with the addition of
   always including a location header regardless of the status code (2011 or
   204). Further discussion is needed on whether the ID field in the
   exchange object should be the full exchange URL or a shorter identifier.
   - *Exchange Response Schema:* Debate on whether to include the workflowID
   within the exchange response schema to facilitate interaction with the
   interactions API, which currently lacks workflow and exchange identifiers.
   The primary concern is how to obtain the necessary workflow ID when only
   the interactions URL is available. A new PR will be created to address this
   point separately.

*Key Points:*

   - The group is making good progress on resolving low-effort issues.
   - The use of both 2011 and 204 status codes for exchange/workflow
   creation, along with always returning a location header, was agreed upon.
   - The question of whether to include the full URL or a shorter ID in the
   exchange object requires further discussion and will be addressed in a
   future PR.
   - A separate PR will address the inclusion of workflowID in the exchange
   response schema to improve interactions API functionality. The opacity of
   the URL and potential layering violations are concerns in this discussion.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-06-17.md

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

Eric Phillips, Joe Andrieu, John's Notetaker, Kayode Ezike, Manu Sporny,
Parth Bhatt, Patrick St-Louis, Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right. Hey folks. it is a very small group today. I think
what's happening is I got back so was not able to send out the meeting
updates or agenda. and I know we've also got multiple people out on
vacation. but I did re see that we have a poll request. So we'll go ahead
and process that. I know you just opened that. and then if we don't have
anything else we'll definitely end early because we've got a small turnout.
Although as I'm saying that people are trickling in. let's go ahead and
start out with community updates or anything of that nature.

Manu Sporny: just a quick kind of review of what we're trying to do here is
we are trying to process all the loweffort issues and raise PRs for those.
we'll continue to do that. we've been making good progress. I think we've
closed 13 or some odd issues in the last two months which is good. if we
can just find a little bit more time to do PRs, I think we'd be able to
knock the rest of them out. and then once we get to kind of all the
loweffort things, then I think we are going to try and propose a new
verifiable credential working group charter when August rolls around. So I
think that's kind of where we are.

Manu Sporny: and so yeah, I think in general we are going to try to
continue to keep pushing forward on PRs. I know that there is not renewed
interest there's interest in using in a number of education use cases. so
that has been kind of raised as an thing that people want to use the VC API
so that's good. and it is certainly being used in some of the first
responder work as okay so I think that's it from the community.

Manu Sporny: any other updates commentary anything else that we should
discuss community related. If not let's go ahead and focus on the poll
request which this is the accept 2011 status response for exchange and
workflow creation PR poll request 487. Coyote, do you want to take us
through this one? Okay.
00:05:00

Kayode Ezike: So, this originated from a Slack channel that has a few
implementers in it. And I think ultimately there's some confusion around
why we decided to use the status response when creating exchanges and
workflows. So I think what we thought was a good compromise is to still
accept 2011 as well which is I think the standard for creating entities and
then 204 is another alternative that implementers can return as well.

Kayode Ezike: I think I just remembering this now but around still
returning location even if you return 2011 which I mean I don't have a
strong feeling I don't know if I agree with that but I think something that
was also being discussed in that thread too I wish Dave was here to sort of
make his case for that but just put this up for now just because felt like
it was causing some confusion and it's it wasn't the original focus of that
issue but it ended up being related to it in many ways and so just because
that's where the 204 was introduced was from this issue that's what I feel
like

Manu Sporny: Okay, got it. let's see.

Manu Sporny: Did this one get Let's see here. Should be raised. So, you
raised 468 that fixed this. Is that okay?

Kayode Ezike: Yeah, exactly.

Kayode Ezike: So, it was already and I made a comment if you could scroll
to the bottom, you see my last comment I made about half an hour ago where
I think I missed a meeting where you guys said to add it or to remove it,
but I already approved it a while ago with that PR. So, …

Manu Sporny: Okay.

Kayode Ezike: and then this is just the 2011 status.

Manu Sporny: Excellent. All right. that's …

Kayode Ezike: So, last thing I'll say,…

Manu Sporny: go ahead. Go ahead.

Kayode Ezike: maybe what I'll say is I should probably tag Dave because he
may want to also basically make a case for why we should also include the
location header even if we return to one. And I think that's what I recall
that he was recommending.

Kayode Ezike: So, You can probably tag him in a comment or something. Okay.

Manu Sporny: He is out for the next two weeks and…

Manu Sporny: so often in 2011 often includes location try not to use the AI
summary. did you look into kind of…

Manu Sporny: what the HP semantic spec says about 2011 versus 204.

Kayode Ezike: We discussed it briefly.

Kayode Ezike: I think the main thing is that you have to because four
usually doesn't have any body in there and then 2011 does and so the
implementers will have the choice to do one or the other right either put
the body response directly there or to give a location.

Kayode Ezike: And…

Kayode Ezike: I can, look through that thread again, but I believe there
was also a case to be made to always put the location there as well. But I
can Yeah.

Manu Sporny: Trying to see…

Manu Sporny: if 204 says anything about location. I mean I can see the
argument for it. Guess there's now a content location field as well.

Kayode Ezike: Thank you.

Manu Sporny: It doesn't say that you can't
00:10:00

Manu Sporny: Yeah, I mean it looks like I can't see…

Manu Sporny: what it would hurt to put the location header onto for no
content. I mean, it doesn't forbid it. so you're saying it's the 2011 that
we're wondering…

Kayode Ezike: Yeah. …

Kayode Ezike: so 2041 currently does have a location in the schema for it's
a 20 right…

Manu Sporny: if we should put the location header in. that would make a lot
more sense to put location than the 204,…

Kayode Ezike: because it already has …

Manu Sporny: least to me. plus one from me to putting it in.

Kayode Ezike: wait. But the 2011 would already have the data inside of the
body usually I thought.

Manu Sporny: Yeah. Right.

Kayode Ezike: So yes.

Manu Sporny: But I mean I think you can So if you did a get on where the
location header is, would it effectively give you the body back? Yeah. So,
I think that's fine because Let's see. mean, it doesn't say if 2011 has
body or not here.

Kayode Ezike: Can I just pick that up?

Kayode Ezike: Yeah, I guess in that case…

Kayode Ezike: then we should just always have the location.

Manu Sporny: Yeah, that's…

Manu Sporny: what I was thinking is that no matter if it's 2011 or 204, we
always have the location.

Kayode Ezike: I'll make a slight modification to that. Basically, I'll just
add the location piece that's in 204 under 2011 as well.

Manu Sporny: Unless anybody else has stronger feelings about that. So,
yeah, Coyote, let's go ahead and change it so that we always return a
location and then we can Yep, that's right. and…

Manu Sporny: that should do it for that poll request. okay. Okay.

Kayode Ezike: There's another thing I guess related to this issue.

Kayode Ezike: There was a few comments that I made just before your last
comment on this issue that again I think be great for Dave to chime in on
here but basically he was making the case that the ID field in the exchange
object should be the full exchange ID which didn't entirely agree with it
to make more sense for it to be just like the U ID skip or the bid whatever
is using

Kayode Ezike: for the ID schema, but I think he made a comment that it
should be the full exchange ID.

Manu Sporny: Let's see.

Manu Sporny: So, you the full URL, right? Not just the local Exchange ID.

Kayode Ezike: That's what he was recommending.

Manu Sporny: Yeah. …

Kayode Ezike: Yeah. All right.

Manu Sporny: yeah, I think that sounds right. Cuz otherwise you'd have to
hack together URLs to figure out what's going on. Or I mean, if you wanted
the full URL, you would have to figure out what your get request was to and
then you'd get a response back and then you'd have to wait this forget
exchange state. We're talking for create, right? Let's see.

Kayode Ezike: Yeah, this is for the create one.

Manu Sporny: It's for create exchange. Yeah. Yeah.

Kayode Ezike: Yeah, which would now have the location in there too.
00:15:00

Manu Sporny: I mean, I think I agree with that. why not put the full URL?
What's the concern about putting a full URL?

Kayode Ezike: And…

Kayode Ezike: so it relates a little bit to another issue that I wanted to
talk about, but I can see how we can get around it, but basically it has to
do I don't think is an issue per se.

Kayode Ezike: I was thinking more in terms of what would be in for example
the entry for the database that someone needed locally or within their
system. The VC API base URL can change. and so I guess the way to answer
that question would just be to always make sure that you provide the right
VC API whenever you return the response to the API. But it was just
thinking about matching it more closely to the underlying structure in the
database. But I guess it's not a big deal. You can still to work.

Kayode Ezike: But I think the one thing which is a leading comment for
another issue that I wanted to discuss for 21 is that I do feel that we
should be including workflow ID inside of the exchange response schema and
I'm jumping around a bit but the reason for that is because the
interactions API that we added recently it doesn't have the same components
that most of the endpoints do where you have workflow ID and exchange ID.
It's just like interactions without any other identifier and they're aside
from the interaction ID.

Kayode Ezike: And so it has to do with being able to make sure we were able
to actually construct DRL with the right workflow ID in there, which to me
sounds like the easiest way to do that would just be to include workflow ID
inside of the response schema.

Kayode Ezike: And yeah, I think it should be exchange.

Manu Sporny: Okay, let me pull up the response schema…

Manu Sporny: because I'm getting a little lost, Coyote. so it's an API and…

Kayode Ezike: Wait, this is the components but the main exchange is going
to show lowerase exchange. Yeah, I think it's on API maybe.

Manu Sporny: then exchanges.

Kayode Ezike: That's something.

Manu Sporny: Hamill and…

Kayode Ezike: So create exchange for example, I would have expected it to
have workflow ID as one of the properties in it. could exchange response…

Manu Sporny: you could create exchange request response.

Kayode Ezike: if it's there should be good.

Manu Sporny: Maybe get exchange response.

Kayode Ezike: Okay. Yeah.

Kayode Ezike: Yeah, currently it does not include that which so for example
somebody were to try to get the first thing before I go further right
doesn't have a workflow ID in there which to me sounds like a natural thing
to have…

Kayode Ezike: because it's very obvious piece of the exchange but then
going back to the interactions …

Manu Sporny: I guess…

Manu Sporny: what would you use the work? What would you use that URL for?
So, what you're arguing for is I think what Dave's arguing for is this
great. I just changed the layout. this ID would be a full URL to the
exchange, And what you're saying is that it would also be nice to have a
workflow ID in here that would be a full URL but to the workflow.

Kayode Ezike: so I guess the way that I was thinking about it

Kayode Ezike: was that it would have a workflow ID that's just the local
workflow ID that could then be used at the very least internally for the
implementer to be able to construct the URL that they would need to return
for example when they receive an interactions when they receive an
interactions request…

Kayode Ezike: which does not have workflow ID in there and does not have
extreme ID they would need to know which workflow is associated with that
interaction that No,…
00:20:00

Manu Sporny: what's…

Manu Sporny: what's the use case and I apologize coyote I have not
implemented any of this stuff which is why I'm a little lost

Kayode Ezike: All good. so you recall, if you go to the spec text,…

Manu Sporny: That's Yeah.

Kayode Ezike: if you recall the interactions endpoint, Yeah. So there's
Exactly.

Kayode Ezike: So right right there in the red it says example interaction
SLZ8 and so on and so forth. so there's no mo I think most implementations
will probably end up treating interaction IDs as exchange IDs. but if
that's the case, ultimately part of what needs to happen is for when you
receive a request for a particular interaction, at some point the
implementation needs to return a exchange URL that the client can interact
with,…

Kayode Ezike: right? and…

Manu Sporny: Yeah, you're saying this needs to be like this URL.

Kayode Ezike: part and

Manu Sporny: When you get this URL, you will need to provide in a very
specific exchange ID for both open ID for VP if it's, layered on top of VC
API and VC API at least, but I'm still not getting the whole you're making
some connection between this interactions URL to

Kayode Ezike: Right. Right.

Kayode Ezike: So I guess my thing is in order for you to go from…

Kayode Ezike: what you're highlighting right now, interactions URL to, for
example, the VC API, I would think that you'd have to know the workflow ID
that you would need to include in there. that associated with that
Interaction ID.

Manu Sporny: My understanding is when this interactions URL is created,…

Manu Sporny: there's some kind of backend call that makes all of The
backing exchange ids. let's see. and in doing that it will have internally
in its state it will have a bunch of those but they won't be workflow ids
they'll be just full-blown exchange IDs both I no ID for VP so in my mind
it's kind of stored out of band when this interactions is created in the

Manu Sporny: It will make all the other kind of protocol endpoint things.

Manu Sporny: It'll make all the other calls that it needs to create all the
other endpoints for the protocols or…

Kayode Ezike: Right. But…

Kayode Ezike: so part of Yeah.

Manu Sporny: they'll be there already, I guess. is that right?

Kayode Ezike: So I guess referring to the comment that Dave made in issue
421, there was something about should we store the proto I asked if we
would need to add protocols property to the exchange schema or if we can
just use the metadata within there to create it instead.

Kayode Ezike: You should be able to create it just on the metadata,…

Manu Sporny: I see…

Manu Sporny: what You're saying, yeah, so you're saying for this thing, how
would you know the local exchange ID if you've got the full URL?

Kayode Ezike: right? Right.

Manu Sporny: And one way to do that is to break apart the URL that you get.
but if you're trying to treat that as opaque,

Kayode Ezike: It's one of the few endpoints where, there's not as much
information. all you get is the interactions and so in order for you to
actually return back for example that VC API protocol property you would
need to know which workflow associated exchange was created from basically
which to me means that we should probably store workflow ids inside of
exchange exchanges which feels like a simple small update but also a

Kayode Ezike: important one as well that some implementations might already
be doing. I don't know but imagine that that would just make sense.

Manu Sporny: Yeah. Yeah.

Manu Sporny: I don't have a strong feeling about it. anyone else with kind
of a strong feeling one way or the There.

Patrick St-Louis: Not sure if I have a feeling, but I'm definitely looking
at this exchange endpoint for some didcom interaction. how I was planning
to implement it is that you create the didcom invitation like you normally
do and then you just kind of associate it with this local exchange ID. So
then when you provide that URL to someone they will get the actual as a
didcom property and…
00:25:00

Manu Sporny: All right.

Patrick St-Louis: the exchange item back. but I've not really looked at a
scenario when I want to create multiple different exchanges like diff
multiple different protocols. So

Kayode Ezike: Yeah. Yeah.

Manu Sporny: So maybe coyote the next thing might be to do that in a
separate poll request. and then maybe they will have strong feelings one
way or the other. I don't I don't necessarily see the harm in doing it. My
only concern is like that of a kind of a layering it feels mildly close to
a layering violation. the local ID is kind of arbitrary and you could pick
any other ID potentially.

Kayode Ezike: Oops.

Manu Sporny: So I'm trying to or should we really treat the URL as
completely opaque because it really does have a structure that's
established by the specification. So you could actually parse the URL if
you wanted to. So, us saying the URL is opaque is not really true because
the spec itself defines the URL as having a very specific structure. and
exactly how to parse that structure at least to get to the local exchange
ID. So, why is that not, good enough? I'm having a hard time kind of
rationalizing it in only one Meaning, it sounds like we've got some more
kind of work to do around

Manu Sporny: questions to answer is the URL actually opaque or not? If the
answer to it's not opaque then parsing the local exchange ID out of the URL
should be just fine thing to do, but then by doing that that feels also
somewhat like a bit of a layering violation. maybe all the information
should be in the URL. and there's a very good chance that might be over we
might be overthinking this and going one way or the other doesn't really
help or harm things, to any significant degree. okay.

Manu Sporny: Coyote, if you don't mind raising another PR on that one,…

Kayode Ezike: Yeah. Yeah.

Manu Sporny: keeping it separate from the current one, because I think the
current one should be fairly easy to merge down. once we get more views on
it.

Kayode Ezike: Yeah. Yeah. I'll try to make a case for why I think it makes
sense too so that folks have context.

Manu Sporny: Okay, that sounds good.

Manu Sporny: All right, and then we'll wait until you make those
modifications to this one. let's Let me go ahead and add group discussed
256 17 Okay.

Kayode Ezike: I should also say sorry.

Kayode Ezike: so it certainly won't be in this PR because it was referenced
here but also I think maybe the comment also came from PR421 where we were
discussing the full exchange ID. So yeah, I'll just create a PR that
references that issue and then we take it from there.

Manu Sporny: Okay, that sounds good. okay. I any other comments on this
poll request before I move on? All right. I think that's it for pull
request Q. We still do need to process these effort low or we need PRs for
the loweffort things. hopefully I will be able to get some time over this
weekend to add a couple of those.

Manu Sporny: and then of course if anybody else has some spare cycles
please feel free to pick off any of these effort low items. we normally do
introductions at the beginning. Eric, I don't know if you want to introduce
yourself or not. It's totally voluntary. but we'd love to know a bit more
of your background and what your interest is in the verifiable credentials
API call. but also fine for you to stay on ute. Any we want to cover Any
other business that we should discuss before we end? Okay. If not, that's
the call for today.
00:30:00

Manu Sporny: Thank you everyone for your time and attention and we will go
ahead and meet next week hopefully to process more pull requests. thank you
Coyote for raising that PR and raising the future one that you noted. Okay,
that's it. Thanks everyone. Have a great rest of your week. Ciao.
Meeting ended after 00:30:51 👋

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