[MINUTES] VC API 2025-08-19

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

*Topics Covered:*

   1.

   *Community Updates:* Discussion of the transition of the incubated
   specification to the Verifiable Credential Working Group (VCWG), including
   the need for priority input from the CCG and VCWG on work items.
   2.

   *Pull Request Review:*
   -

      *Fixing Credential Query Examples (PR #515):* Improvements to clarity
      and consistency of query language examples were discussed. The use of the
      "required" property was debated, with a consensus emerging to replace it
      with a mechanism for identifying choices and sets of required queries,
      improving user privacy. This will involve adding IDs to queries and an
      "options" or "choices" property to group related queries.
      -

      *Replacing Incorrect "valid" with "verified" (PR #514):* The
      inconsistent use of "valid" and "verified" was addressed. The
group agreed
      that "verified" more accurately reflects the cryptographic verification
      process, while validation involves higher-level business rule checks. The
      terminology around credential status and proof verification was refined.
      3.

   *Specification Name Change:* The current name ("VC API") was deemed
   misleading and potentially confusing with other APIs. The group explored
   various options, ultimately favoring "VCOM" (Verifiable Credential API for
   Lifecycle Management) as a clearer and more comprehensive name. Concerns
   about pronunciation similarity to "Didcomm" were noted but deemed
   acceptable. The group will finalize the name after a trial period.
   4.

   *New Issues:* Several new issues were logged, including clarifications
   needed on workflow controller/authorization relationships, OAuth scope, API
   component overview, and role/authority distinctions. These will be
   addressed in a future meeting.

*Key Points:*

   - The transition of the VC API specification from the CCG to the VCWG is
   underway, requiring prioritization of work items.
   - The "required" property in query examples is problematic regarding
   user privacy; a revised approach focusing on choice and query sets is
   preferred.
   - Replacing "valid" with "verified" clarifies the distinction between
   cryptographic verification and higher-level validation.
   - "VCOM" (Verifiable Credential API for Lifecycle Management) was chosen
   as the new specification name, aiming for greater clarity and
   differentiation from other APIs.
   - Several new issues requiring clarification were identified and will be
   discussed in future meetings.

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

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

Benjamin Young, Dave Longley, Joe Andrieu, John's Notetaker, Kayode Ezike,
Manu Sporny, Michael Burchill (Credivera), Parth Bhatt, Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right, let's go ahead and get started. We've got a decent
number of people here. we welcome to the VC API call for this week. we have
an agenda and that is largely to process pull requests. we have some query
examples that got updated to finish off a PR we did the previous week based
on Ted's issues that he raised. so we will be looking through that the
valid versus verified language and renaming specifications specifically
renaming the VC API specification to something else.

Manu Sporny: there's an issue that was raised on that rather a PR that was
raised on that for us to just start having that discussion. we can also
cover any relevant community developments though I don't know if there's
much there other than the BC working group starting back up. are there any
updates or changes to the agenda or anything else that we would like to
cover on the agenda today? Okay. If not, let's get into community
developments and review. are there any community updates? I think the only
one that we may need to pay a little more attention to is the incubation
and promotion.

Manu Sporny: at some point we are going to need to cut a final version of
the community group incubated specification for handover to the verifiable
credential working group. we will also need to provide input on priorities.
so at some point we're going to need to collect input from CCG VCWG on what
people feel are more important like prioritize the work items that we're
transitioning over and where does VC API fit in that where does render
method fit in all that kind of stuff.

Manu Sporny: So get a priority order just from the CCG and VCWG as input
into the working group. so I don't know when those things are going to
happen but I expect them to happen in the next couple of weeks. any other
community things that we need to talk about? if not, let's go ahead and
jump into our main agenda, which is processing poll requests. I'm going to
go in reverse order because I'm hoping that Coyote and speaking of Coyote,
hey, I was hoping that you were going to be here for the discussion on the,
spec change. same for Patrick St. Louis.
00:05:00

Manu Sporny: hopefully he'll be able to make it but if not we'll have it
anyway but I'll push that towards the end of the call. so we'll start with
fixing credential query examples. so this is an attempt to fix 515. the
other thing I should mention is that Ted, I tried to address your issue 516
with just a commit. it was a single commit and you were right the thing was
not easy to read.

Manu Sporny: So, I took the examples and put them into bulleted lists so
that they were very clearly separated and marked up and hopefully that
addressed your thoughts on that high level? Thumbs up. Yeah, it did look
much better afterwards. thank you for pointing that out. but the next issue
was issue 515 which noted that our examples were a bit weird in the query
language section. the commentary was inconsistent on what the comment was
applied to the current line, that sort of thing.

Manu Sporny: in an attempt to clean that up, I raised a PR that, does a
couple of things. And let me get down to requesting a presentation section.
So now the examples that the commentary the comment applies to the next set
of lines. although now I'm looking at this and this applies to a set of
lines that doesn't necessarily exist but hopefully it's clear that it's
meant to have query details specific to the query example. usually the
lines comment on the very next line.

Manu Sporny: we try to put a space if there's some, where it might be
easier to read and so on so forth. So that's been changed there. And then
on this one, example two is where the biggest set of changes need to be
made. this one again tried to make it consistent. The comment line is for
the next following line.

Manu Sporny: And I think the next set of following lines. So hopefully
that's unified and makes more sense now. So that's go ahead.

Ted Thibodeau Jr: That looks a lot better.

Ted Thibodeau Jr: If it's poss I don't know if blank lines are okay in this
language. then adding some blank lines in there just like the other ones.

Manu Sporny: They are okay.

Ted Thibodeau Jr: before each of the optional are mandatory. it just makes
it much clearer.

Ted Thibodeau Jr: This is a block.

Manu Sporny: Yep.

Manu Sporny: Plus one to that. and I agree. And I don't know if we can do
change suggestions, but if not, I'll try to make that in a second pass.
Ted, I agree. I did also note, Dave, you did comment on the required
property. You've got some other things in here. Do you want to comment on
those? Please go ahead.

Dave Longley: So I think in this correct me if I'm wrong, the intent was to
use the required property to try and address the conversation we had last
week or the week before around…

Dave Longley: how we would express that a particular query was part of
statement as opposed to and statement or were you just using what was in
the existing VC API spec that was specifically for query by example?

Manu Sporny: the first thing you said…

Manu Sporny: which was try and I think it's wrong. as I was making the
changes I was like I don't know if this actually works. let me find it's
for the ant

Dave Longley: Okay. Yeah,…

Dave Longley: it looked like you had and maybe I hallucinated this, but it
looked like you were pulling it up to the higher. And so I think there's
two things that are going on here and we should separate them, understand
them to be different concepts and figure out what to do. So there's the
idea that you can send a query to the other party. and just for this
conversation, we'll say that there's a website that's requesting something
from a wallet. It could go the other direction too. But if a website is
requesting something from a wallet, I think what we should do is make it so
whatever is requested is always what is required based on however the user
triggered the flow. So the user will be doing something on a website. It's
totally up to that website to render whatever they want.
00:10:00

Dave Longley: And the request that comes in should only say this is what I
require from you to continue going in the flow which is different from
saying here are a couple of different query languages I offer you choose
the one you want and presumably they all do about the same thing you pick
one of these and it allows you to continue in the flow. that's different
from saying, "I'm going to ask you for example, your age and your name, but
then optionally I'm going to ask you for your email address. You don't have
to give it to me." I think those sorts of optional flows have a tendency to
cause most people to just click and accept it because they know that
there's going to be greater friction when they don't want to share that
information. There's going to be greater friction.

Dave Longley: And what we might want to do is say the required property
however or engineer this so that the required property only applies to
choosing different query languages. It's not and that there is no feature
to say hey and I'd also kind of like this other information. If you want
that other information I think we should flip the script on that so that
when you're on the site the site can say hey we'd also like this stuff. you
can click here if you want and the users that want to provide that extra
information go through that extra friction. We don't want to force or coers
people to give up more information than is strictly necessary. and I think
having a required property that does that particular feature is not a good
design. Did that make sense?

Manu Sporny: Yes, I think I was following all of that.

Manu Sporny: And I agree. there might be a third option there.

Dave Longley: So I think we need to separate in two different things and…

Dave Longley: and I think required is probably a bad name, but the features
we want are hey, you can have many different query or at least more than
one different query language that a wallet might support and we want to be
able to support that. But that's a very different feature from this other
thing that I don't think we want to support.

Manu Sporny: M multiple comments. So the first one is I get philosophically
what you're saying.

Manu Sporny: I am concerned about that going into us telling people how to
design their websites being used as a reason to use you should pick open ID
because it allows you to do that kind of optional over gathering of
information whereas this API doesn't allow you to do that right I'm
wondering Not I get doing the multi-stage thing. I think I'm concerned
about making the flows more like you said. I mean it's adding friction to
the flow which some organizations are just not going to like and so as a
result of that because we don't allow them to do that they're just going to
default to the language that allows them to do that.

Manu Sporny: And I totally understand the problem with that, right? I mean,
we'd be knowingly implementing something that we think is a bad thing in
general to do, but that presumes that, we've got a lot of experience with
how these interfaces are going to be built. And, we don't necessarily have
that right now. So I'm very conflicted about taking the feature away and
then making it and then making it so that people just reject the query
language because it doesn't allow them to do the thing we think is a bad
practice. but other people will disagree with that. go ahead Dave. I've got
two other things I wanted to mention.

Dave Longley: Yeah, I want to first say maybe that's okay. if this results
in competition which, there's already multiple different career languages
that are out there, if it results in a competition of some kind where
people make these different choices and everyone gets to go forward with
those choices, I think that's okay. If it results in de facto everyone
making a worse choice overall, then we shouldn't do that.

Manu Sporny: Yeah, that's fine. I mean, I find that convincing. Me, meaning
if people want to do the privacy invasive thing, they're just going to
switch to the other language to do it anyway. And so, we shouldn't support
the privacy invasive thing. We should make it a point that we don't support
the privacy invasive thing and people shouldn't be using the privacy
invasive thing. But I, fully expect the same folks that are deploying some
of the, not so great features of MDOC and MDL are just marching forward
anyway and don't necessarily seem to care about some of the privacy
implications of that stuff. All right. So, Okay, that's fine. and then two
other comments.
00:15:00

Manu Sporny: one of them was, "Yeah, we should probably change required to
be something else." this example, I think is probably misleading. Maybe it
is. yeah, I'm trying to figure out if the optional one just ends up
becoming mandatory because there are two ways this can be interpreted. One
of them is I want to use two totally different query languages and I want
you to match on both of them. So for example, I want an MD MDL and I want a
verifiable credential with an education credential in it. I want both and I
need to get both of those at the same time for my minimum, business
process, which is, I don't know, signing up for a class. and demonstrating
you have the prerequisite.

Manu Sporny: so I'm wondering are there three different cases here? go
ahead Dave.

Dave Longley: I was going to let you finish that thought. We do have the
case where you want to request both and both are required and for whatever
reason a particular query language must be used for a particular type of
credential or presentation. So It is a use case where you would provide two
different queries where they could just be a choice. That's what's on the
screen there. and then I don't know what the third use case would be hard
to understand.

Dave Longley: It would be you have to provide this I think the third use
case would fall into that other bucket I was just talking about where you
have to respond to this particular query language and the other one is
optional meaning you could give me this data but I don't really need it and
I think that again falls into the bucket of things that isn't so it results
in behavior that is less good for p good privacy outcomes So I made a
suggestion and…

Manu Sporny: Yeah, I'm wondering how we actually

Dave Longley: we can analyze that instead of saying required we could
identify that there's a choice and give it an identifier for the choice and
whether or not we use that identifier for the choice later in a response is
something we consider. We might not need to do that. But if you mark these
as being a choice, then we can indicate, if a query is marked as a choice,
then you don't have to use that query. That's not necessarily going to
cover the privacy harm I was worried about. But it is different from
required,…

Dave Longley: which is I think we ought to just remove that everywhere.

Manu Sporny: Okay, so these would change effectively to choice A,…

Manu Sporny: choice A and this So that would convey that you have to meet
both of these for the verifier to be happy the result.

Dave Longley: Yeah.

Dave Longley: Yeah, I think that's right.

Manu Sporny: Case and this would be choice B. And you have to make at least
one of those choices. You have to respond to every query that's associated
with one of those choices.

Manu Sporny: for the verifier to be happy. This would say choice A.

Dave Longley: That's not the way you described it.

Dave Longley: Yeah, you have to respond to one choice in a query,…

Manu Sporny: This would be choice one set of queries associated with a
single choice.

Dave Longley: I think, is what so we'd have to talk about how you would go
about doing because what you just described, I don't think would
consistently work. I mean you ended your statement with you have to respond
to at least one choice. okay so this one would be choice and…
00:20:00

Manu Sporny: So if no don't we need a required…

Dave Longley: choice in that situation and you have to pick one choice A
and in the other case choice might be the wrong word for that and…

Manu Sporny: then for hand choice A choice A let's see this would be choice
A

Dave Longley: and situation based on how you finished your statement would
require choice and choice B in the statement that you have to respond to
every choice.

Manu Sporny: here. Okay.

Dave Longley: Choice is probably a bad name for this clearly at this point,
but the mechanic I think makes sense. So some term name with some
identifier and you have to give a response for each one of those
identifiers.

Manu Sporny: You have to respond to every marked identifier.

Dave Longley: You have to respond To a single query for every unique
identifier that shows up or…

Manu Sporny: Yeah. And…

Dave Longley: whatever this is.

Manu Sporny: and then what happens if you've got two query by examples? So
yeah.

Dave Longley: That shouldn't be an issue.

Manu Sporny: I think maybe what we do here is we need to pick a name.

Manu Sporny: I'll go and update this so that it's got that in there and
then we can come back and kind of try to reanalyze and I'll try to get
every variation. The thing I'm not sure about is what happens when you've
got combined and ands and ors through that mechanism. do you see what I'm
wondering if you do need a required at some point if you've got two queries
I want your driver's license and I want your proof of I mean I want your
driver's license and I want your vehicle registration. those are two
different queries.

Manu Sporny: Right. And…

Dave Longley: And they would get two different identifiers…

Dave Longley: because you have to respond to both whenever an identifier.

Manu Sporny: or I'll take your what are those people that can get away with
anything?

Dave Longley: What's that?

Manu Sporny: What are those people that can get away with anything? You
have diplomatic immunity. I'll take your diplomatic immunity…

Manu Sporny: where you don't have to give me any of those things. Yeah.
Yeah, that's a third option where it's like you need to do the two you need
to give me a driver's license and a vehicle registration or show me your
diplomatic immunity.

Dave Longley: That's the third option.

Dave Longley: Yeah, it's the grouping of the first two under that we have
to work out. I don't think…

Manu Sporny: Yeah. Yep. Yeah.

Dave Longley: what we've described covers that case.

Manu Sporny: That's the one where I was thinking through this and I was I
don't think the thing on screen doesn't work either. So yeah and…

Dave Longley: I think we might just need some kind of set terminology or
something that describes how this query relates to other queries. And you
can put that on each query.

Manu Sporny: I'll note that OID4VP has something like this in DCQL,…

Dave Longley: They do the required flag I think is a bad idea.

Manu Sporny: the required thing, but I think you're saying that's a bad
idea. Yep.

Dave Longley: I think asking for a nice to have that right there. I don't
think is a good idea.

Manu Sporny: Yeah and they do provide ids for each thing right so these are
all credential queries with formats so that matches the kind of ID thing
but then they also have the All right.

Dave Longley: they have some kind of credential sets thing there. That's
kind of what I just described. You'd say these go together and then you
choose. So you have a set of options and you could say for each of these
options you have to provide everything matching these identifiers.

Manu Sporny: Mhm. Okay.

Dave Longley: It'll be pretty similar to this feature I think. And then if
you're using DCQL, it should map nicely.

Manu Sporny: All right. Okay.

Manu Sporny: So we can work through those things there. all right. Anything
else on this particular PR? I think there was something else that mentioned
00:25:00

Dave Longley: Yeah, just make a quick comment. We could just add ids to
that query and then have a field that says options and then you can list
the options and put the IDs either together in a group in an array or
independently. And that not only would that probably map nicely to DAL, so
if people want to use it, it works cleanly, it gives you the feature
overall for any other query language.

Manu Sporny: Got it.

Manu Sporny: Meaning that the query language doesn't actually have to have
those things in it. Okay. Mhm.

Dave Longley: So it's an addition.

Dave Longley: So give the queries IDs and then there's an additional
property called either options or cho choices might be better.

Manu Sporny: All is there anything else we need to talk about for this?
I'll go through and kind of do another pass. and then P I'll try to put the
extra spacing in there and then make this update. I think that's it
largely. All right. That was the fixed credential query examples. anything
else in that item before we move on?

Manu Sporny: Okay, next item up is replacing incorrect. so in the YAML we
were using valid in a bunch of places. and I went and I looked again to see
what we were using elsewhere and we were using the word verified where we
were using valid. So I don't know when valid snuck in, but it did and then
it started being copied and pasted all over the place. So, this PR tries to
fix issue 514. which means that, we were confused about what the word valid
actually meant when you did a verification. what's supposed to happen, I
think, is syntactic verification or at least providing information to a
validation process which can then do business rule validation.

Manu Sporny: so for example whether or not a date's verified will provide
syntactic val validation on the date but it won't tell you the date range
is valid or invalid that is a part for validation process higher level I
think to do that and so everywhere that was using valid that was with a
verify credential result or a verifiable presentation result has been
switched is saying verified instead of valid and we say it's the result of
verifying the security challenge or the result of verifying the security
domain or things like that. so that's largely what this PR does. now the
question to the group is is this correct? Is this the right word to use?

Manu Sporny: The places where it felt a little off to me is for credential
schema. I think verification makes sense. You're verifying that it matches
the schema. For credential status, it's a bit weird in that you pull out
the status entry bit. you say whether or not it's verified, but that really
means that you've verified the proof I think on the associated status
credential. Is that correct?

Dave Longley: That's right.

Manu Sporny: And then you say what the thing is.

Manu Sporny: So this thing would say verified false if the signature didn't
match or there was some other kind of syntactic error in the revocation
list in the status list but otherwise it would say yep I checked it status
list was good this is the value of the status entry bit but I have no idea
what that means meaning that validation needs to determine if that's the
right right value for the status entry and this is probably wrong because
there can be a status entry bit set not necessarily a single bit.

Manu Sporny: And…

Dave Longley: Yeah,…

Dave Longley: we discussed that further. The value should probably be a
string or a number. because we don't want to design this API so that it
only works with bitstring status list.

Manu Sporny: Okay.

Manu Sporny: So the value is any type I guess.
00:30:00

Dave Longley: And if it's a bit string status list, I guess it could be an
integer. We could decide if we want to allow it to be a boolean, that sort
of

Manu Sporny: And then this should probably be value of The specific status
field. entry. Yeah.

Dave Longley: It could be the specific status associated with it gets
pretty wordy.

Manu Sporny: specific status value associated with the status entry.

Dave Longley: Yeah, it's with the status entry. Good enough for now, I
guess.

Manu Sporny: All right.

Manu Sporny: Proof I think. Go ahead.

Dave Longley: I just want to say my answer to your original question is
this correct now?

Dave Longley: I think it's more correct than ballot was in most of the
cases. and…

Manu Sporny: Okay.

Dave Longley: that's good enough for

Manu Sporny: For proof, I think it is just verifying the proof is it a
valid proof or not? Did the cryptography work out?

Manu Sporny: There are other things where proofs have created dates I think
if I remember correctly but that would verify to false if wouldn't it so
the proof would verify you just and…

Dave Longley: No, I don't think it would verify to false. No, I think it
would just be Yeah.

Manu Sporny: you'd get the input okay so

Dave Longley: Whether or not you want to accept a proof based on its date
is up to your business rules and you could be verifying. Yep.

Manu Sporny: Yes, the crypto worked. But again, here's the value. You need
to figure out if this created date is good for you or not. let's see. Is
there anything else that was weird for holder verified. I think that makes
sense.

Manu Sporny: where holder verification means that the holder matches the
proof on the presentation.

Manu Sporny: Is that what it means?

Dave Longley: Yeah, I don't know.

Dave Longley: I'm guessing that has to do with proof of possession.

Manu Sporny: So you Mhm.

Dave Longley: So, yeah, all of it you kind of have to squint at when you're
talking about validation versus verification. because there's multiple
different meanings for each of those words.

Manu Sporny: music. Mhm.

Dave Longley: But I think verified is safer to return because it has a
weaker implication that you should just accept anything that's verified.
Instead, you need that there's a separate decision you have to make.

Manu Sporny: Yep. Okay. Okay. So, that's that PR.

Manu Sporny: Does anybody else have Comments confirmed is what Ted is
suggesting.

Ted Thibodeau Jr: I'm not sure I'm suggesting it, but it does have the
advantage of not being another Word.

Manu Sporny: Yeah. I guess the initial thought is we have not defined what
confirm means in VC data model or…

Ted Thibodeau Jr: Yeah, there's definely that

Manu Sporny: anything. Yeah. I mean, we went to great lengths to try to
specify what verified versus valid validation was,…

Manu Sporny: and I still don't think we've got a good section on that.

Dave Longley: Confirmed. Also,…

Dave Longley: yeah, conf confirmed to me also implies I've compared this
against something I'm expecting,…

Manu Sporny: Go ahead, Dave.

Dave Longley: which sounds more like validation to me than verification
does. I would almost rather go with, …

Dave Longley: authenticated, but I don't know that it matches as well as
it's not as loose as verification.

Manu Sporny: Yeah, I looked at the definitions for verified versus
validation and…

Manu Sporny: validate and validating and all that kind of stuff and it did
match what we have how we're using it in the C data model. The thing I was
concerned about is I went back to the whole I forget if verified or
validated mean the same thing in the English language. and luckily there's
a slight difference between not all definitions make the distinction, but
there were a couple that did make the distinction between, verifying and
validating. Of course, I forget what the distinction is, but one of them
requires more effort.
00:35:00

Manu Sporny: validation requires more effort, more thought, more due
diligence than verification does. that's that item. any other comments
before we move to the next one, which is the spec name change, which is a
bike shedding discussion that might take the entire rest of the call. So
let's talk about the name of the specification. API it can get easily
confused with DC API and it's not just DC API Open ID for VCI sorry VP is
really about delivery.

Manu Sporny: neither DC API nor u oid4 whatever is about life cycle
management nor does it say how to set up interactions or workflows or any
of that stuff. so this spec that we're working on is more encompassing I
mean clearly because you can run ID4 VCI and VP over it. and so we need to
kind of think about the name carefully because the current name we have for
the specification is misleading some people to think that it's a direct
competitor replacement of a DC API or ID4.

Manu Sporny: So I just took a shot at the name which was just the
credential life cycle management specification an HP API for doing digital
credential life cycle management or com CM. I think Coyote you had
suggested that we should put verifiable in front of it and maybe that
becomes VCOM. there were other things suggested. So I think Patrick said
what about the credential interaction specification though I think there
are a number of minus ones or I don't know associated with that one.

Manu Sporny: I don't think Patrick was, blocking the name change, but was
just trying to provide other examples. Coyote, you provided some input on,
the rationale behind VCOM. and so yeah, so I think folks seem to be fine
with VCOM. thoughts. to just go forward with this? Do we want to sit on it
and think for a little bit longer? go ahead Dave and…

Manu Sporny: then Michael, you're after him. Okay.

Dave Longley: Since I didn't say so in the issue,…

Dave Longley: I thought VCOM sounded fine to me. verifiable credential API
for life cycle management being the full name.

Manu Sporny: Michael

Michael Burchill (Credivera): I'm also fine with the VCOM. I see in the AM
space a lot of people are now using VDC to refer to verifiable credentials
as a blanket term. So it sort of lines up with that. I just don't like the
hyphen.

Manu Sporny: Yeah, I mean we can remove the hyphen. I think that'd be fine.
I guess the other thing is to try it out in conversations. I was trying it
out in conversations and it felt a little awkward. because it doesn't
really VC API you're verifiable credential API and VCOM it's a mouthful.
you're just like, " yeah, the verifiable credential API for life cycle
management." I'm wondering if it's too long or if it's just, and again,
it's a name change, so the name changes always sound weird at the beginning
and then everyone gets used to it. go ahead, Michael.

Michael Burchill (Credivera): Just to your point, I think most of the
conversations I have with people about this topic over the last four or
five years have been awkward anyway.
00:40:00

Manu Sporny: Excellent point. Yep. go ahead, CH. Okay,…

Joe Andrieu: Yeah,…

Joe Andrieu: I just want to support when you first mentioned it today, I
didn't like it. Manu, but I think comm is sometimes just a word. VCOM is
not. So I think it's immediately differentiable from just the normal use of
an English word with the VCOM. So

Manu Sporny: sounds good. I'm not hearing any objections to VCOM. No
hyphen. do we want to sit on this for another week or two or do we want to
make the change? go ahead, Benjamin.

Benjamin Young: Yeah, nothing major. But when Joe just said VCOM, it
sounded a lot like Vitcom, which is, more punctuated, more pllosives and
didcom than VCOM, but that would be a near phone conflict. So, I don't know
if there's anything else that could be added or some other way make those
more distinct audio wise, but that's a pretty small risk.

Benjamin Young: Although it is in the same space,…

Manu Sporny: Yeah, that's a good point. Wasn't even thinking of didcom and…

Manu Sporny: yeah, the similarity.

Dave Longley: I heard the same thing actually and…

Dave Longley: I was thinking about that but you can use didcom on vcom or
with vcom and so that's something to consider.

Benjamin Young: I'm pretty thrilled with Kyod's suggestion. Do you want to
say what it is?

Kayode Ezike: Yeah, I mean it just came to mind because it's funny because
I guess but it's also from verify credentials and so calling it very calm
could be a way to distinguish that. but it was kind of as a joke but if
y'all think it's actually a good one…

Kayode Ezike: then we can at least talk about it.

Manu Sporny: I do like it.

Manu Sporny: I'm trying to think if I like it because it's clever or if I
like it because it's ticks all the other boxes, too. Go ahead, Dave.

Dave Longley: I think I only like it because it's clever because it brings
back the problem and that Joe brought up that I also had the same thought.
very calm is again two words that can just be those two individual words
and so we lose that differentiation.

Manu Sporny: Yep. yeah, good point. Go ahead, Benjamin.

Benjamin Young: Yeah, that's a fair point.

Benjamin Young: I was just going to point to all the things that come out
of the US Congress that have stupid names. we're not going to be the first
ones to have weird backronyms like the card act or the safe act or the
Patriot Act or they're all painful backy

Manu Sporny: Yeah, I think but on that point I mean I think that's right
and true. on that point one concern I have about just comm or vcom or all
these variations very calm is that they don't anchor back to verifiable
credentials unless you explain it or spell it out. and I'm wondering and we
haven't had a chance to use the word in discussion enough to figure out if
this is going to be awkward to say or do or whatever. meaning when about
I'm trying if you talk about DC API or VC API you're like digital
credentials verifiable credentials. But when you talk about, the V VCOM
stuff, it's like, verifiable credential API, although you could, I guess,
say that's VC API.

Manu Sporny: Maybe it's VC API for life cycle management or yeah, I mean,
I'm trying to figure out are we going to go back into calling it like VC
API shorthand because that's kind of the first little bits and we kind of
drop the LM but when we want to be specific about what we're talking about,
we say VCOM u, but in the everyday kind of discussion, we say VC API for
shortening …

Manu Sporny: and then VCOM if we want to make sure that we're not confusing
people about the thing that anyway I don't know if that makes sense but go
ahead Dave

Dave Longley: No, it does make sense.

Dave Longley: And I think we have the advantage of VCOM letting us do both
of those things, especially when you want to put it in writing and people
are just reading it, you can have a clear differentiator. And if you're
speaking about it or you're continuing to use terminology with that's
already in the ecosystem, you can say VC API. And if you need to
distinguish like, we mean VCOM.
00:45:00

Dave Longley: But the whole it is part of the name.

Manu Sporny: So maybe we can claim both…

Dave Longley: And VC API is just the first part of VCOM.

Manu Sporny: which has kind of a marketing upside there. go ahead Ted.

Ted Thibodeau Jr: Yeah, VC API retains the confusion potential with DC API.
So, I would guide against that. I've been putting into the chat, various
kinds of permutations like VCA4 blah, right? because presumably there's
going to be other APIs for things besides life cycle management and this
lends itself for an easy prefix to whatever those are. Probably they're not
all going to give us something nice like com, but maybe We can always play
with that. That's just thoughts.

Manu Sporny: No, good idle thoughts. there is the whole I don't know if you
meant the lead replacement of A with a four. So, it's verifiable credential
API for …

Manu Sporny: but I don't think we should do the whole lead thing. I think
just be calm by itself is fine. yeah.

Ted Thibodeau Jr: Yeah, it depends on…

Ted Thibodeau Jr: how many others we anticipate there being over time. And
there's already right open ID for whatever.

Manu Sporny: Yep. Yep. Okay.

Manu Sporny: do we feel like we've had enough discussion where we're okay
with just committing the text to VCOM for now and we can do a editorial PR
pass to just change it, see what we think about it. and then, if we read it
and settle for, 3 weeks and are still okay with it, then we rename the
repository and make the final kind of commitment. does that seem like a
good path forward? Okay, we will do that. so I'll need to update the PR to
add verifiable in the beginning of the name and kind of go from all right.
I think that is our entire agenda for today. Is there anything else we want
to discuss?

Kayode Ezike: I don't think it needs to be for today per se,…

Kayode Ezike: but I did create a few new issues in the issue category.
There's a heads up.

Manu Sporny: Okay.

Manu Sporny: Let's do a real quick kind of look at that. clarify
relationship between workflow controller and authorization. Add
clarification of oath scope where fix expected callers in API component
overview and clarify distinction role authority. okay, that sounds good. I
think and I think as Yeah, it sounds like we're going to need to talk a bit
more in depth with each one of those things. We'll put that on the next
agenda and categorize those and figure out how we do PRs on each of them.
Okay.

Manu Sporny: And thank you for logging the issues. that is it for the call
today. thank you all very much for the great discussion. we are not going
to meet next week unless somebody else wants to run the call. I will be on
the road traveling. So we'll meet the following week unless somebody else
wants to run the call. that's it for today. Thanks everyone. Have a
wonderful rest of your week and we'll chat again soon. Take care. Bye.
Meeting ended after 00:49:10 👋

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