[MINUTES] VC API 2025-09-16

VCALM Meeting Summary - 2025/09/16

*Topics Covered:*

   1.

   *Community Updates & Poll Results:* A poll regarding VCALM priorities
   was discussed. VCOM received the highest support, followed by confidence
   methods. Render methods, barcodes, and wireless received lower support. Key
   market verticals were underrepresented in the poll.
   2.

   *VCALM Spec Refactoring:* The VCALM specification was successfully
   refactored into a single YAML file, simplifying maintenance and deployment.
   This resolved previous issues regarding API endpoint placement. A
   suggestion was made to add an x-dash parameter to clarify component
   ownership for each endpoint within the YAML file.
   3.

   *Pull Requests:*
   - *PR 525 (API Component Overview):* Updates to the API component
      overview tables are underway, with a goal to finalize a PR by the next
      meeting.
      - *PR (Define Reserved Exchange Variables):* Discussion focused on
      clarifying the results field in exchanges, aiming to provide a
      mechanism for passing data between workflow steps. The errors field
      will be replaced with lastError, and the inputs field will be
      removed. A suggestion was made to standardize the name of the
last step in
      a workflow (e.g., "final").
      - *PR (Add YAML to Support Interaction Mechanism Endpoints):* Two new
      endpoints were added to support the interaction mechanism. Minor clean-up
      and review are needed.
   4.

   *VC Refresh Spec Update:* The Verifiable Credential Refresh
   specification was updated, leveraging the interaction endpoints. The
   distinction between manual and automatic refresh will likely be removed.
   5.

   *Renaming "VC API" to "VCOM" in the Protocols Object:* Discussion
   concluded that renaming "VC API" to "VCOM" in the protocols object is not a
   high priority given the minimal impact and potential for long-term
   coexistence with the older name.
   6.

   *Issue Requests (Needs Discussion):* A discussion began on handling
   self-issued credentials through issue requests, and alternatives using ZCAP
   were explored. Concerns were raised about security implications and user
   experience. This discussion will continue in the next meeting.

*Key Points:*

   - The VCALM spec refactoring significantly improved maintainability.
   - The results field in exchanges needs further clarification for data
   passing between workflow steps.
   - The renaming of "VC API" to "VCOM" in the protocols object was
   postponed.
   - A new use case for self-issued credentials was introduced, prompting
   discussion around security and user experience considerations with ZCAPs.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-09-16.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-09-16.mp4
*VCALM - 2025/09/16 14:58 EDT - Transcript* *Attendees*

Dave Longley, Dmitri Zagidulin, Eric Schuh, John's Notetaker, Kayode Ezike,
Manu Sporny, Parth Bhatt, Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right, Kale, let's go ahead and get started. this is the
VCOM call for what is this? September 16th, 2025. we do have an agenda
today. that's to cover any community updates. cover the result of the OAS
file refactoring that we talked about last week. process any open pull
requests and then process any issues needing further discussion. do we have
any other updates or changes to the agenda? Anything else we want to talk
about today?

Kayode Ezike: Just as a small item that I wanted to add on towards the end.
It's not super urgent, but have notifications for specifically I'll call it
out now because it's pretty small, but the current ET API field and
protocol whether or…

Manu Sporny: Yes, much Better.

Kayode Ezike: or if it's not worth the headache for backwards that I didn't
think it'd be necessarily the issue for that per se. if we can get a quick
answer to that. audio is not good at One second. Is this great. yeah. No,
just a tiny thing I was wondering about, which is whether or not we should
change the field in the protocols object to be VCOM now that we're using
that or if it's okay to just keep VC API. I don't know if we need a whole
issue for that, but just wanted to at least call it out.

Manu Sporny: We should change it to VCOM. I have tried to make that change
three times but for whatever reason it keeps getting overwritten by merges.
I don't know why plus one to making that change. go ahead Dave.

Dave Longley: I think we should at least briefly talk about why we should
change it at some point.

Manu Sporny: Okay, we can put that on the end of the I'm guessing you're
like,…

Manu Sporny: "No, we shouldn't change it." So, let's put that on the end of
the agenda.

Dave Longley: I just…

Dave Longley: if we're going to change something like that, I think we
should have a good

Manu Sporny: We can put that at the end. any other updates or changes to
the All right, that's our agenda for today. let's go over community updates
first.

Manu Sporny: we did cover the poll. let me go ahead and bring that up. one
second. All right. And then make sure that people's email addresses aren't
showing. all right. So, we've got a good set of responses back. we did talk
about it at the BCWG call last week. Brent wanted to make sure that
companies that had multiple people responding that we reduce that down to
one person per company responding to not, weigh it one way or the other.
00:05:00

Manu Sporny: I have gone through and deleted all of Digital Bizaar's
responses except for which, reduced the number of responses by three.
everyone else on there, is, from a separate organization. So, we've got a
cleaner one opinion thing going into so the downside there is that the
folks from Dig Bazar that volunteered for editorships on specifications are
not listed anymore.

Manu Sporny: And so we're going to have to figure out a different way for
those folks to volunteer to edit specs. the numbers at 31 responses is
pretty good. to put it in perspective, the new web apps working group
charter is up for review. They got 11 responses to the charter, right? And
they're the backbone of the web. So we're doing pretty good at 31
responses. we are definitely missing responses from key market verticals. I
have told them multiple times to fill the thing out. They keep not doing
it. I'm going to email them once again and tell them that the poll's
closing at the end of Friday. The unfortunate thing about that is that I
know that they have very strong opinions on this stuff and they're just not
going to get them recorded. can't you we've tried to ping them.

Manu Sporny: If you know of anyone that really should be filling this poll
out from the education sector for example is very much represented
governments very underreresent I can't say that word today under
represented vital records is non-existent on the poll retail sector is
largely underrepresented

Manu Sporny: they're just, people that should be putting up their hand but
that said, the people that show up and do the work and make their voices
heard is, that's how we prioritize things. okay, so running through this
real quick, render methods, is kind of secondary priority to folks.
confidence methods up kind of high. people find that important. VCOM is the
highest thing at 18 votes. barcodes not as that's probably towards the back
of Wireless is definitely refresh towards the back of the pack.

Manu Sporny: Quantum safe crypto suites. People are really interested in
them. People are not doing work to make it happen. So I don't know what
we're going to do about that. And the verifiable issuers list is towards
the back of the pack. so the things that have the highest support are VCOM
confidence method and then everything else is kind kind of far behind the
quantum save stuff and then everything else is kind of behind that. okay so
that's it for the responses.

Manu Sporny: please contact people and get them to fill this out if they
want their voices heard. okay, so that's it for that item. let's go ahead
and bring up the repo and let me share this. All right.

Manu Sporny: so the VCOM spec, last week we talked about, it's getting
difficult to figure out where to put certain API endpoints because
sometimes they're used in multiple places. And we're having debates over
that. And so last week we said, hey, let's just try and consolidate
everything, see I did that work over the weekend. Turns out it worked out
really well. meaning we were able to delete lots of old build Croft that
existed because we had so many different, specs and things. came across
multiple things that I remember us fighting about in the early days that
are now just, easy. So, we used to have this build process that used to
build specs and Red and Swagger and all that kind of stuff and it's just
never quite worked.
00:10:00

Manu Sporny: it turns out then when we bundle it on into one YAML file the
deployment into Rapid do and RedO becomes really easy like here you go
single file we just reference the OAS file and then pull in Rapid do via
unpackage and you get a fully rendered Rapid thing. So this is what the
rendering looks like in real time and you can click on different things and
if you don't like rapid do then you can do swagger right and if you don't
like swagger you can use redoc. So we have all these different renderings
they're all done real time whenever we push something new up. Don't need a
publication process anymore to do that.

Manu Sporny: just loads live files. it is one giant file at this point, and
I haven't gone through and tried to organize it, but this file is no bigger
than, a spec file. In fact, it's much smaller than many of our, spec files.
So, about 1,200 lines of YAML. and that's it. So I'd say it was a success
in that it's way easier to maintain this repo now and I think we don't have
to have a discussion about where the API endpoints go. The only problem is
sorry coyote PR got caught up in that reactoring. So hopefully you can kind
of copy and…

Kayode Ezike: Yeah. Yeah.

Manu Sporny: paste the bits you have.

Kayode Ezike: I was able to resolve that earlier

Manu Sporny: Awesome. okay.

Manu Sporny: So, I think we're done there and we can move on. any questions
about the refactoring or…

Manu Sporny: Go ahead, Eric.

Eric Schuh: Yeah,…

Eric Schuh: just a thought as I was submitting the PR I imagine we're about
to talk about. but I was thinking it might just for clarity sake now that
everything's in one file be nice to add another xdash parameter that is the
expected component that the endpoint lives on or components in a few cases.
I'm not sure if that's worth the overhead, but it was just a thought I had
just to increase the clarity of reading the one big file.

Manu Sporny: I thought we had that.

Eric Schuh: So that's who's expected to call the endpoint.

Manu Sporny: Okay.

Eric Schuh: I'm saying which component it is expected to live on.

Manu Sporny: Live on. Excellent. Yeah. Yeah, let's do that.

Eric Schuh: Okay, I can take that on.

Manu Sporny: Thank Yeah, it's much easier to do stuff like that. No, we
might need to update the other thing I did update respec OAS so that it
just took a config option now where you just list all the API files you
want to be pulled in. it's just this one line here. So now you can just
list any arbitrary number of OAS files and it will pull them in. But we
just are down to one now in this repo. so to use that somewhere Eric we may
want to update respspec OAS I don't know…

Manu Sporny: how we can do that later once we have everything categorized
Yeah,…

Eric Schuh: Yeah, it's not clear to me…

Eric Schuh: if it needs to be exposed anywhere outside of the YML. we have
the main spec file obviously dismbiguates the endpoints itself. this was
mostly in my head for people that might come in and just open up the YML
file and start reading through it. Yeah.

Manu Sporny: I mean it'd be nice to have a summary table autogenerated in
the way we have some of the current is these tables are autogenerated right
okay…

Eric Schuh: Yeah. I could do a corlary table to these ones …

Manu Sporny: although this yeah…

Eric Schuh: where this might actually have the information.
00:15:00

Manu Sporny:

Manu Sporny: how does this have the information.

Eric Schuh: it's because of the way I explicitly built in each of the
service components and then listed the endpoints or…

Manu Sporny: Mhm.

Eric Schuh: the coordinators.

Manu Sporny: Meaning we list them explicitly.

Eric Schuh: Mhm. Yes.

Manu Sporny: That's how it's showing Got it. Yep. That makes sense. Thanks
for taking that on, if we had that then we could replace it with the
explicit we could remove the explicit thing and use some thing to
autogenerate these tables so we wouldn't have to remember to go back and
relist them if that makes sense. Mhm.

Eric Schuh: That should be the update, I would imagine, is getting rid of
the explicit call out in the index.html for each of those and having it be
autogenerated entirely.

Manu Sporny: Yep. Yep. Yep. That sounds like a good update to make at some
point. Not a high priority, but if we can get around to it, that'd be
great. All right. other things. I did go and clean this back up after doing
the merge so we do have a bunch of conformance statements. Now there's this
thing down here service client implementation instead of creating what is
it five more like so we have issuer service implementation it has a
corresponding issuer client implementation and rather than creating those
and adding those which would be five more conformance classes I just did
one service client implementation so if you're a status

Manu Sporny: service. If you're a status client implementation, it means
that you provide a means to communicate with all mandatory interfaces
exposed by the status service implementation. So there little things like
that where we might want to discuss are we okay with the conformance
classes or do we want to be more, explicit and fine grained. We don't need
to talk about that today, so the section is there. I wrapped the
conformance section up into the introduction, a terminology section. We're
now clean in that we just refer to VC data model 20. we do define new
definitions in the spec. but much of it we defer to verifiable credentials
for the BCDM 20 spec for things like defining verifiable credential and
issuer and verifier and things like that.

Manu Sporny: Still need to do a little bit of refactoring of the spec. but
we'll do that in time. That said, all editorial work. let's talk about pull
requests next. we do have three pull request 525 is to update the API
component overview.

Manu Sporny: I know, Eric, you've done some work on this, so please give us
an update.

Eric Schuh: Sure.

Eric Schuh: I will drop the Google doc link in a chat where we were having
discussions about this. so I got some feedback from Dave and made some
updates to the tables here in the wait a second. Yes. And it looks like
coyote's come through since then. so my plan with this was to give this
Google doc until the end of this week to kind of settle and then whatever
state this doc document is in I will then move forward with updating the
current API component tables to match what we have here.

Eric Schuh: so generally, give it the rest of this week and hopefully I can
get a PR in before our call next Tuesday to update these tables.

Manu Sporny: Awesome. that's great.

Manu Sporny: Thank you Eric for working on that. and next step is the PR
after talking with Coyote as well about this. But good, glad we're making
progress on that. Dimmitri, to answer the question that you asked in chat,
do we also process the VPR spec? Yes. we also made a decision to just fold
VPR into the VCOM spec. So there's a section in the spec now that talks
about requesting a presentation and it has the definition of VPR in it
because basically we had whittleled it down to such a small thing it's
there.

Manu Sporny: So VPR's there, by examples in here, query format did
authentication's in here. the ZCAP things in here for now. It might not
survive. just the first version 10 standardization logical operators are in
here. and we moved every single VPR issue into the VCOM repository. So, we
were doing so well. we were getting down to 15 potential issues, but then
we added the VC API or VPR issues back in. Now, we're up to 30. I did go
through and recategorize a bunch of stuff. I tried to put effort high on
them. and really we've got 19 effort low PRs that could be written.
00:20:00

Manu Sporny: So again if you have some spare time the effort low things
would take about an hour to write and process a PR for them. so if we have
enough people or if we can parallelize this a little more we'd be able to
knock out about 19 issues pretty quickly. hopefully that answers your
question, Okay.

Dmitri Zagidulin: It does. Yes, thank you. I opened a couple of issues on
the VPR spec including what's the format for returning a VCAP, etc. So,
it's great that it's folded into VCOM.

Manu Sporny: Those are and then we've got some needs discussion things like
this is like that one that you're talking about, right?

Manu Sporny: So we've got that queued up for discussion today.

Dmitri Zagidulin: And the issue of EC1. Yeah. Excellent. Right on.

Manu Sporny: Yeah. Yeah. Yeah. They should all have come over. I did not
close any of them yet unless it was clear that the spec covered it. So,
everything survived. Back to pull requests. Thanks for moving issue next
one is define reserved exchange variables raised by Coyote, would you like
to take us through this PR?

Kayode Ezike: So this PR was actually based off of an issue that I created
in the past that was basically to better specify the variables field in
exchanges and since made a PR that brought it closer to the truth but then
I recently realized that there's a need to further specify it and so
basically thinking of what all should we kind of require sluggest for the
fields to go in there. I think it was a long discussion that was happening
there that I' been processing that the most part of I agree with where it's
heading.

Kayode Ezike: I think the results field probably can be discussed a little
further in terms of what exactly should be in that under my intention for
that when I put it there was for it to be the field that would receive
responses from holders basically for example like a response to VPR. So,
the VP, with the holder and the challenge and things of that sort that
would be pertinent to the service. maybe I'm not sure what's the next step.
Maybe it's just like I mean there's some things that I know I'll need to
change. For example, I think we decided that we don't need the errors
field. which I'm okay with. It wasn't a huge need for me.

Kayode Ezike: I think one discussion Dave had was to just put an optional
last error field at the exchange level. and that's really all you wouldn't
need to have one for every step because if one step fails and the whole
workflow will fail anyway. That was one thing that came out of that. And
then what I originally intended inputs to be which was to be credential
data that would map to the issue requests which is basically just something
in the workflow that specifies the templates and that each step would
generate as far as issue credentials.

Kayode Ezike: originally was thinking that we would need a specific field
to save that data to, but then I think there's a different recommendation
that Dave had, which I agree with, which would keep everything in a config
and wouldn't require the need to specify a field name for interoperability
purposes. So, I guess I said I guess next step would be for me to continue
processing. Maybe we can discuss some of these if necessary, but I think
the results one maybe could be a place where we can start as far as making
sure that we're on the same page. I think that's probably the one that's
least clear because there was mentioned for example, this just came to
mind. Sorry, another me thing that Dave mentioned was that results could
also be used to pass data to the next step.
00:25:00

Kayode Ezike: and I'm not sure that that's something that is specified
anywhere in terms of because there was mention of pulling out certain
pieces of data and putting it and using that as input for example to
credentials for the next step and so I don't know that that's something
that is clearly specified as in the current state. sh. Yeah.

Manu Sporny: All right. so to summarize real quick, Coyote, we're replacing
errors with last error. We don't need inputs. So, let's focus the
discussion on results and what we want to achieve with that. Is that fair?
All right. Dave, do you want to provide some feedback on results? I don't
know.

Dave Longley: So when you're saying Iote that we need more information or
more guidance indicating that a step could read from results. I want to
figure out where that comes from. So, I wonder if we need to talk more
generally about the design of how the variables work with templates or I'm
not sure what we need to clarify there. So, the variables in an exchange
are passed to the template processing engine. And so, anything that's in
the variables field can be used in a template.

Dave Longley: And so whenever a step completes, if we're going to take the
result of that step and put it in to a variable called results, then it's
necessarily true that any subsequent step template when it is evaluated
will be able to see those results and it can use those in the template if
it wants to. And so the main use case the main reason why results were put
into variables instead of some other property on an exchange is so if you
had a complex workflow where you received some piece of information let's
just say from a holder where they submitted a credential that had some
fields in it, you might want a subsequent step or just another credential
that you're issuing in the same step to be

Dave Longley: able to reference that information. So, to try and give a
concrete example, I might provide a employee credential in step one and
then part of step two might be gathering some other information and
including my name from the employee credential in a gym membership
credential that is then issued to me. And so that information would be
pulled from the results. though there's no need to create some complex
callback mechanism to talk to a coordinator to get extra data because the
data is provided in the exchange.

Dave Longley: So the whole workflow would say hey holder first give me
these credentials and then I will use some of the information from those
credentials once they've been verified within the workflow and sprinkle
that into some other later step or some other credential in the workflow
and that can go into a schema that you need to check against. It could go
into a credential whatever it is you want. And because it's useful to be
able to access those results in future step templates, it makes sense to
put the results into the variables since they're already there. There's no
reason to put them anywhere else. especially given that there are certain
size constraints on exchanges.

Kayode Ezike: Right. Right.

Dave Longley: You don't want to have to duplicate information. So that's
where that reasoning came from.

Kayode Ezike: So, if I can just reflect back really quickly. So, basically
this makes it such that all the references to results will be contained
within the exchange record. Basically you can use it wherever you want
within exchange. there's not going to really be much you have to do as far
as a protocol process standpoint from within the work source service. You
just need to basically know how to package I guess the variables inside of
the issue requests object in order to actually know where the different
values will go.
00:30:00

Kayode Ezike: Yeah, go ahead. Mhm.

Dave Longley: Yeah. and…

Dave Longley: when you're using the word you need to know, I actually want
to tease that apart a little bit because I think that's relevant to where
we had originally had a disagreement that I think we've resolved on inputs.
So whoever's running the coordinator or if we look at the party that runs
the coordinator as different from whoever designs and creates the workflow
which I think we should look at it that way. They might end up being the
same party, but it's designed so that It's important to understand that the
implementation details of the workflow, what the issue requests array looks
like, all that stuff does not have to be relevant at all to the
coordinator. those are implementation details behind an interface. As far
as the coordinator is concerned, all the coordinator needs to know is
where's the workflow endpoint and what variables do do I have to pass when
I create an exchange.

Dave Longley: It doesn't have to know any of the details of how the steps
are organized, where the issuer requests are, what order they're in, none
of that. And that's why I was looking at that inputs thing that was being
provided is sort of like a leaky abstraction. it was like as a coordinator,
you need to know what these requests issue requests array looks like, what
the steps look like. you need to reference all that information and that I
think is unnecessary or super superfluous information for a lot in maybe
all coordinator instances they don't need to know that information and so
we want to try and keep that interface clean. It also allows for later if
you wanted to change if you wanted to make another workflow that was more
advantageous in some way, you might keep the same variables and then just
tell the coordinator, here's a new endpoint with a new workflow. Just keep
sending me the same variables. Here's the new place to go.

Dave Longley: and everything would still work.

Kayode Ezike: Okay. All right.

Kayode Ezike: So, it just needs to know the variable names and the data to
send to that. I could put in those variable names basically and it's good
enough for it. Okay. Yes.

Dave Longley: And I don't know if we want to have any text like this, but I
would recommend that the variable names be semantic in nature so that
you're less likely as a coordinator to make mistakes. I don't think it
would be good to have here's an array and position three in the array has
the variables for the third credential which happens to be the employee
one. It would be better to just be like here are the employee variable
credentials and that's the name of the variable and here are the membership
credentials. That's the name of the variable. and you don't care as a
coordinator what step that's in or what order it might be in an issue
requests array. That's a detail you don't care about.

Kayode Ezike: Right. Okay. Okay.

Kayode Ezike: I think that makes sense. Thank you for clarifying that.

Manu Sporny: All right.

Manu Sporny: So I guess based on that conversation, what are the next steps?

Dave Longley: The one thing I would recommend is I think it would be a good
idea for us to at least suggest that the step name for the last step in a
workflow be something consistent like finish final. I don't know. We should
probably give it a name and say if this should probably be the name of the
last step because it is extremely common. maybe final step. but I think
it's extremely common for a coordinator to use some workflow and then want
to read the results of the final step. And so it would be good to give it a
consistent name and say this is the name you should use for the last step
in your workflow.

Dave Longley: I've been using finish for this. We can use something else.

Manu Sporny: That sounds like a good invitation to bike shed.

Manu Sporny: Which we may not want to do today. particular I guess, Coyote,
do you have a good idea on kind of what to update change with the PR based
on all of this?

Kayode Ezike: So yeah, effectively like you said, putting less error into
removing inputs, and that's really the main thing outside of that. I mean,
we could add some extra. And then adding the final step. although I don't
know if we want to put that in this PR or another P but then I don't know
if we should vocalize any of the things that we have in some of the
comments that were put here. Dave had a lot of good points in there if it's
necessary maybe to add some of that to index as well. this. All right,…
00:35:00

Manu Sporny: Why don't you make the call on that, ote? if you want to wrap
it into this PR, we can. And if not, we can raise an issue for a future PR,
but might as well, take care of all this stuff while we're in here.

Kayode Ezike: sounds good.

Manu Sporny: Okay, thanks, Coyote. all right,…

Manu Sporny: that was define reserved exchange variables. the next one is
add YAML to support the interaction mechanism endpoints. Eric, do you want
to take us through this one?

Eric Schuh: Sure.

Eric Schuh: It's pretty straightforward. I'm adding those two endpoints
listed there. I saw as I joined this call that there are some bugs in the
YAML that all get cleaned up either this afternoon or tomorrow. most
likely. yeah, effectively it adds those two endpoints that support the
interaction mechanism as well as the components specifically the protocols
component and…

Manu Sporny: All right.

Eric Schuh: the invite response component. not sure if there's too much to
discuss.

Eric Schuh: I guess my one note would be that Dave, I did try to
incorporate in the invite response endpoint description the note that the
ID that starts that endpoint would be the same as the exchange ID if you
had implemented the entire T of the VC ALM. since I do think that's a
important thing to call out. but since we also want to leave things open so
that people can just implement this interactions mechanism without the rest
of the spec if they so choose. I tried to leave the name more generic than
to reuse the exchange ID.

Dave Longley: Yep, that makes sense.

Manu Sporny: All So, next steps on this, Eric, is there's a little more
cleanup that you're going to do,…

Manu Sporny: and then other people should do a closer review. okay.

Eric Schuh: Yeah, I think I just had a couple of patterns from my Googling
that aren't quite right.

Eric Schuh: So, I'll just come through and clean those up. should be pretty
easy, I expect.

Manu Sporny: Sounds good. All right. So, that's the third PR and that's
going to be processed a bit more. I will based on this one though issue 550
the YAML to support interaction mechanisms. I did also make a pass at the
credential refresh spec this past weekend with a lot of guidance from Dave
Longley here.

Manu Sporny: VC refresh the refresh service uses the interaction endpoint
stuff. So there's an example this is wrong, this one's wrong, but there are
other ones where we use kind of protocols and interactions and things like
that in here. that made it a lot simpler meaning meaning this specification
verifiable credential refresh because it's building on top of the VC API
and using interactions just became way simpler the data model is way
simpler there's really no distinction between a manual and automatic
refresh now you can make that decision dynamically

Manu Sporny: I'm probably going to remove the sections on manual versus
automatic refresh or show how one is basically the same as the other one.
It's just a different URL endpoint choice is made at so just a heads up
that there's an update there and I think this spec is now finally up to
date. I need to make another pass to make it fully up to date, but once
that's done, it should be ready to be promoted once folks have a chance to
review it. all right. So, going back to the poll requests, I think we're
done with poll requests, which is almost the end. we had that other item
that we wanted to chat about, the renaming B VCOM or BC API thing.

Manu Sporny: So let's do that discussion and then that's going to be the
end of our call for today. go ahead Demetri.
00:40:00

Dmitri Zagidulin: Just super quick for those of us who made previous calls,
what was the impetus behind the rename? what prompted that?

Manu Sporny: People were getting it confused with DC API and they didn't
understand how it was different from OID4 VCI.

Dmitri Zagidulin:

Dmitri Zagidulin: Got it. You got

Manu Sporny: It was just too many VC, things in the ecosystem or, people
are getting confused between DC API oid for VCI and VC API. it was sounding
like the same thing to people that did.

Dmitri Zagidulin: Yeah, makes sense.

Manu Sporny: So, we just renamed it to BCOM. because the differentiator
here is that it does full life cycle management. It's not just a delivery
protocol like OID4VP, 4 VCI. You can run OID4VP and OID4 VCI through the
workflows and exchanges. it's fully compatible with DC API, but not, one
letter off. …

Dmitri Zagidulin: Got it. Yep.

Manu Sporny: for all those reasons were kind of the name, but Deiter, you
reminded me that we do have other things that we need to discuss today. So,
I was thinking it was going to be a short call, but we have Two of them
being items that you raised on verifiable presentation requests. So,

Manu Sporny: so let's go back do we want to replace VC API? it's already
replaced here. so the thinking for this and Dave, please queue up. the
thinking for this is if we had legacy uses of VC API, we can just modify
the library so it uses this thing. we did make a conscious decision to
change the name because it was confusing and so that's another reason, to
do it here. It didn't seem like it would have a serious amount of impact.

Manu Sporny: And the reason we're renaming it is for all the other reasons
we renamed the specification. Demetra, you still have your hand up. I don't
know if that was an old hand or…

Dmitri Zagidulin: Hold hands.

Manu Sporny: this …

Dmitri Zagidulin: I keep forgetting that it doesn't automatically lower it.

Manu Sporny: strange. it always automatically lowers it for me and…

Dave Longley: Dimmitri is in here twice and…

Manu Sporny: I don't want it to.

Dave Longley: that might be why.

Dmitri Zagidulin: Yeah. different. Yep, I get user error. story.

Manu Sporny: Okay. go ahead Dave.

Dave Longley: So I think the actual practical effects of changing it are
that VC API and VCOM are going to appear all the time because at least for
some period of time because there are implementations in the wild that use
VC API. So what will end up happening is we'll just see both. and then
every implementation is going to have to be able to accept both. And I
would expect that to just not go away for a really long time since it's in
a decentralized ecosystem. It'll be hard to know when it's safe to
deprecate them. And I don't think we have the same confusion in the
protocols object that we have in other places. I don't think DC API ever
appears in the protocols.

Dave Longley: and the oid4 ones are clearly delineated with very different
expression. So I don't know that this little protocols blob is probably
only seen by a very few that group set of developers. I don't know that
there's a whole lot of value in changing the name here but I do think it'll
result in just seeing both of them for quite a while. So, I don't know that
it's super valuable.

Manu Sporny: I mean the other approach is we can say to throw an error if
it's not VCOM don't do the support boat things because we're preworking
group on this right I mean that stuff like that's not supposed to stick
around I guess what implementations are we worried about that's just ours I
for protocols object.

Dave Longley: It's every existing one that's out there now. All the ones
that work with test suites. no, there are plenty of Yeah,…

Manu Sporny: Nobody's using that,…

Dave Longley: I disagree.

Manu Sporny: are they?

Dave Longley: There are implementations that are using this for sure beyond
digital bazaar's implementation. I don't know. It does not seem like we
have a whole lot to gain by changing the name. if we kept it as VC API, I
don't know why that's a terrible thing to do.
00:45:00

Manu Sporny: Other opinions? I think Demetri, you're saying you guys are
using VC API for the protocols object and then Nate's implementation is
also using Okay.

Dmitri Zagidulin: And then Yeah. Yep. Both. Mhm.

Manu Sporny: I'm happy to do whatever. I just, didn't think we had deployed
this as broadly as

Dmitri Zagidulin: I mean, that's still potentially, three or half a dozen.
it's doable. But I think I agree with Dave that it's not that big of a deal
if we just leave it.

Manu Sporny: Okay.

Dave Longley: Yeah, if we're not really being pushed to change it, it feels
like it's a small thing that's in a small corner that few people see. it's
still part of the actual name of the specification. I don't think we need
to change it and save the effort.

Manu Sporny: Okay, I can change it back. It's easy enough.

Manu Sporny: Let me open an issue.

Ted Thibodeau Jr: Yeah, it won't be a problem…

Ted Thibodeau Jr: until decom comes out.

Manu Sporny: Didn't that come out in the 90s? and we see API in protocols
change the name of protocol identifier back to the CAP API and the protocol
object per the discussion on 916.

Manu Sporny: I can take this one for low ready for PR.

Dave Longley: Yeah, I think this way if we ever do need to switch it to
VCOM, we can do that in the future and just expect the same outcome that we
were going to get right now anyway.

Manu Sporny: Yep. …

Ted Thibodeau Jr: We can just make it a little longer and…

Ted Thibodeau Jr: make it Victor Charlie API.

Manu Sporny:

Manu Sporny: that's longer name solve all okay all right that's that item
we do have five minutes we have three needs discussion issues we don't need
to talk about this one Dmitri which one would you like to talk about this
one 548.

Dmitri Zagidulin: Let's start with issue requests.

Manu Sporny: All right. Please take us through it.

Dmitri Zagidulin:

Dmitri Zagidulin: So we have VCOM protocols for a number of operations such
as institutional ing a zcap requesting did off there's another operation
that we're running into the need for that we don't have clary syntax for
and that is asking that is if you're in front of let's say a web
application that is helping you either create a verifiable credential
compose their type of credential into a story into a resume specifically or
a transcript and then it needs to be signed by you. Right?

Dmitri Zagidulin: So there's a world of self-issued use cases that we're
running into in the employment world in the world that basically the app
doesn't have keys right or shouldn't it's just a client side app but it
needs to say hey user and user's wallet please sign this verifiable
credential that the user has composed. hence the sal. So this is what we're
using right now. an issue request. So it's very similar to the issue our
existing thing that you're going to the issuer service except the issuer
service is a selfissuer service. It's essentially the wallet. So it needs a
way

Dmitri Zagidulin: yeah. Dave have hand up.

Dave Longley: Yeah, this is an excellent use case, but there are so many
ways to do it. another way that comes to mind, for example, would be this
application. If the user trusts this application, the application could do
a Zcap request for a key to perform the signing.
00:50:00

Dave Longley: And then go ahead.

Dmitri Zagidulin: So it could and…

Dmitri Zagidulin: and that actually gets into another issue that's has to
discuss and so we are also doing Zcap for signing except no sorry not for
signing because it has three implications on the issuer registry right it's
the person that needs to appear in the issuer not the.

Dave Longley: No, sorry, miscommunication. the user is so the end result of
whatever this use case is that there's going to be a credential that was
signed by the user's key. Is that right?

Dmitri Zagidulin: Yeah. Yeah. That's right.

Dave Longley: So this web app would say, "Hey user, please give me a Zcap
to use a key that you generate for this purpose." And then everything else
happens inside of that web application.

Dave Longley: Does that make sense, Demetri? and…

Dmitri Zagidulin: that it does.

Dmitri Zagidulin: That's also potentially an approach. Mono

Dave Longley: that has the advantage of the web application is going to be
able to display this information better than a web than a wallet is
presumably. if in order to make this work the way that this request is
coming in, there are a lot of things to consider.

Dave Longley: You have to consider that if we design it this way then at
any time on the internet you could receive a request from a website that
says sign this thing for me and…

Dave Longley: you have to hope that your wallet does a good job of
surfacing the information that you're going to effectively put your stamp
of approval on. right.

Dmitri Zagidulin: that's correct and…

Dmitri Zagidulin: and we already have a number of precedents but man is on
the queue.

Dave Longley: And just to finish up it also means that every person's
wallet is going to be expected to be able to display that kind of
information really so that users can make good choices as opposed to
pushing this all to the web app and making it just a capability that you
give the web app on the basis that you trust it. You could even generate a
key just for that web app and then you could revoke it later if you didn't
approve of whatever it was doing.

Manu Sporny: Yeah, I mean plus one to that approach. my biggest concern
though is the website basically lying about what they're going to use your
key for, and…

Manu Sporny: they basic I don't know how to attenuate the Zcap to the point
that it's a safe thing to give a website. it's just like I'm gonna hey,
self-sign this. You took a basket weaving class. just kidding. I'm going to
countersign a payment credential to transfer $1,000 to me using the key you
gave me. Right.

Dmitri Zagidulin: Whereas here exactly.

Dmitri Zagidulin: So that's the downside of the Zcap approach. Whereas the
downside to this approach is exactly what you're signing because you're
holding it and signing it in your trusted app.

Manu Sporny: Yeah, with all the downsides that Dave mentioned, which is now
all of a sudden your trusted app needs to be able to render potentially
arbitrary content, to sign.

Dmitri Zagidulin: But that's the case already for wallet. They're there to
render potentially arbitrary content.

Manu Sporny: Yeah.

Dave Longley: Yeah, it's a little different when you're releasing
information that you've been given signed by someone else as opposed to
render this arbitrary content…

Dave Longley: which I don't think a render arbitrary content where you
might have to click on some JSON fields would ever work in this use case
because there would no user could ever be expected to trust it is the same
concern in reverse I send you a VC it's got these fields that look good,
but embedded in it are some claims that let me say I should be giving you a
bunch of money, whatever that attack was.

Dmitri Zagidulin: That's what schema validation is for…

Dave Longley: You could do that attack and…

Dmitri Zagidulin: though on the wallet side.

Dave Longley: yeah, what I'm saying is the wallet's going to end up having
to really deeply understand that the very specific types of credentials
that could be signed for this use This

Dmitri Zagidulin: Yeah. Yeah. Agreed. And the other thing,…

Manu Sporny: I mean, I think this is just another trusted app problem, if
you're going to delegate a Zcap to this app, you have to 100% trust it to
not abuse the right that you have given it. you can time limit it, but even
then it's one signature is all it takes to transfer $1,000 or more, between
people. so they both have positives and downsides.

Dmitri Zagidulin: the other caveat is that the signed credential stays in
the use as well. It doesn't go back to the app.
00:55:00

Dave Longley: I also want to note you can mitigate a bunch of these
problems by generating a did and…

Manu Sporny: Go ahead.

Dave Longley: a key that are specific to this app for that specific use
case. There's nothing that anyone else could do with it. You could just
have your wallet you could instruct your wallet to make you something and
say, make this thing and then hand over a Zcap for it to this site and then
you can be and then I think that solves the danger problem.

Dave Longley: I don't know if it fully solves the use case. I don't know
what other problems that might introduce.

Dmitri Zagidulin: I don't think it's fully philosophical use case.

Dmitri Zagidulin: I think it's way more steps and requires the Zcap
infrastructure whereas just the signing request does not.

Dave Longley: …

Dave Longley: Didn't mean to jump Q. I'll get on Q.

Manu Sporny: I'm just noting we're out of time for today.

Dmitri Zagidulin: We're out of time.

Manu Sporny: So, we'll come back to this next call and continue the
discussion.

Dmitri Zagidulin: Let's come back. Yeah. start thinking about it.

Manu Sporny: Awesome. thank you Dmitri.

Dmitri Zagidulin: Thanks, Paul. Thanks,

Manu Sporny: It's a very interesting use case. So, we'll talk about it next
week as well. Yes, this is unfortunately not a super easy decision one way
or the other. all right, that's it for the call today. Thank you everyone
again for all your time and attention. I really appreciate it. we'll do
some poll request processing, maybe raise some new poll requests before
next meeting and continue discussing on discussion on these need to discuss
issues. Thanks all.

Manu Sporny: Have a great Chat with you all next week. Bye.
Meeting ended after 00:56:52 👋

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