[MINUTES] VC API 2025-08-12

W3C VC API Community Group Meeting Summary - 2025/08/12

*Topics Covered:*

   1.

   *Community Updates:* The Verifiable Credentials Working Group (VCWG)
   will resume meetings (approximately monthly), and the W3C Technical Plenary
   in Kobe, Japan, necessitates determining the readiness of the VC API
   specification for handover to the VCWG.
   2.

   *Pull Request Review (PR #509, PR #510):* Discussion centered on
   enhancing the VP verification response schema. The group decided to remove
   the overall summary object and simplify the schema structure for clarity
   and security, aligning it with the verifyCredential response as much as
   possible. The confusing "valid" property in credentialStatus was flagged
   for renaming to reflect conformance checking rather than business rule
   validation. The value property type in credentialStatus was broadened to
   accommodate different status mechanisms.
   3.

   *Pull Request Review (PR #511):* This PR migrated the verifiable
   presentation request specification into the VC API document. The group
   acknowledged the need to clarify the examples, particularly regarding
   hybrid query requests, and improve the overall language.
   4.

   *Pull Request Review (PR #512):* A minor PR to uppercase oid4vp for
   consistency.
   5.

   *Specification Readiness for VCWG:* The group agreed to move the VC API
   specification to a status indicating readiness for promotion to the VCWG,
   with the understanding that active refinement will continue.
   6.

   *VC API Renaming:* Discussion on potentially renaming the "VC API"
   specification to better reflect its broader scope encompassing credential
   lifecycle management, beyond just verifiable credentials. Alternative names
   like "Credential Lifecycle Management API" or shorter variants were
   proposed, with a decision postponed to a future meeting.

*Key Points:*

   - The VC API specification is nearing readiness for handover to the
   VCWG, but refinement work will continue.
   - The VP verification response schema was significantly simplified for
   clarity and security.
   - The confusing "valid" property within credentialStatus requires
   renaming to better reflect its function (conformance check).
   - The examples in the verifiable presentation request section need
   improvement to avoid misinterpretations.
   - The group will consider renaming the VC API specification to better
   reflect its broader scope, focusing on credential lifecycle management.
   Several alternative names were suggested.

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

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

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

Manu Sporny: All right, let's go ahead and get started. let me go ahead and
share Our agenda today for the verifiable credential API call is to review
any community developments if they've happened discuss the design of the
VPN and VC verification call PR that Parth has put together. just kind of
talk through some of the design changes there.

Manu Sporny: ing the request spec into the VC API document and any other
PRs that might need attention. we'll probably also want to talk about how
ready we feel the document is to hand over to the VC working group. that
group is starting back up in maintenance mode. and so we want to talk about
how ready is the specification to migrate it over there. okay that's our
agenda for today. are there any other updates or changes to the agenda?
Anything else we want to discuss today? All right. if not let's go ahead
and jump into community developments or updates.

Manu Sporny: I think the only one I worth mentioning is that the verifiable
credential working group is going to start meeting again I think maybe once
a month don't know how regularly and TAC the W3C technical plenary is
coming up in Coobe Japan and so we are going to want to figure out when the
new charter and the discussion around that needs to happen. and that
requires us to kind of decide whether or not we are ready to kind of hand
this document over to the BC working group for further development. I think
that's it as far as community developments are concerned.

Manu Sporny: Any other community developments that folks wanted to report
in If not, let's go ahead and move on to, the poll requests. before I do
that, Coyote, we were, covering any community developments. I don't know if
you had anything you wanted to report out on, or I'll just move on if you
don't.
00:05:00

Kayode Ezike: …

Kayode Ezike: yeah. No.

Manu Sporny: Okay, thanks.

Manu Sporny: right, let's move into pull requests. we have three of them
active. u one to enhance the VP verification response schema.

Manu Sporny: This came about as a result of another PR that Parth emerged
to talk about, whether or not when you verify something, when you verify a
presentation, whether or not it applies to all the other credentials or
not. this is I guess to address issue 284.

Manu Sporny: I guess which got closed. Go ahead.

Parth Bhatt: Yeah. So this new PR was basically part of original issue 284
and…

Parth Bhatt: just for the schema only we created new issue which is 509.

Manu Sporny: Okay. So, it started on issue 284 with Joe wondering if a
verifying presentation included we answered the question and said yes, and
Parth did a bunch of PR work to get that into the spec. thank you, Parth.
And then we've got to update the schemas. And that's what issue 510 in this
PR is about. let's go ahead and roll through it because I know there's been
a little bit of discussion about it. and it looks like par you've applied
most of those suggestions and then there's some here that we want to
discuss.

Manu Sporny: Go ahead Par.

Parth Bhatt: Yeah, that is so I would start with the issue 284 and the last
comment in terms of what was the discussion or the decision made on terms
of what we want in the schema to be represent. I think that will help
answering some questions that you had regarding…

Parth Bhatt: why do we want to skip some proof check and all those
questions.

Manu Sporny: Let's see ready for this comment.

Parth Bhatt: Mhm. Yes.

Manu Sporny: Understand which proofs for each VC were checked, factors
verification were errors, detection, and we do say disable checking VCs. go
ahead, Dave.

Dave Longley: It looks like I was part of the conversation when we came up
with this statement here. I think there's two ways to interpret what we
were saying we want to return. One is like we want a comprehensive summary
of all the things that happened. And a different interpretation of this
would be we want results on the things that were checked so you can see
what was checked but that doesn't mean that we necessarily have a summary
format figured out. especially for people who want this additional feature
of not checking things. so I don't know anyone who's implemented such a
feature and we don't have any implementation experience.

Dave Longley: So as far as I know we don't have implementation experience
with that and I don't think we should propose some summary thing because
that is the sort of thing that just becomes an at risk feature and gets
removed if nobody's using it and so we can save ourselves the effort of
that. it is clear that people are already using the API and implementations
already do the default behavior of checking everything but it is important
that we have a standard way or we have said that we want a standard way to
express the results of those checks. So I think that's where we want to
focus. if people have custom behavior does this or that special thing
behind a configuration, I don't think we're ready to spec that out or…
00:10:00

Dave Longley: to tell people that we need two independent implementations
that agree.

Manu Sporny: Okay, plus one.

Manu Sporny: I think that was my read on what we were saying here. the
other thing that popped up during the review was I was concerned that
disabling checks or the implementation deciding it's not going to check
some things but still returning back like that it checked everything it
wanted to is a potential it sounds like that's like a security issue
waiting to happen. Right.

Manu Sporny: So all of a sudden you've got implementations that just decide
that they don't want to verify some VCs for whatever internal reason. even
communicating that they haven't done that is I think an issue. meaning we'd
have to put a lot more thought into even determining if that's a safe okay
thing to do. And even if we determine it is possible to do that, it feels
dangerous because you're basically saying you did a bunch of security
checks when you might decide not to. Go ahead, Dave.

Dave Longley: And we don't have anyone saying they're doing that. This is
sort of us sitting back imagining that someone might want to do this for
debugging purposes or whatever. And we don't need to put that in a spec and
tell people to all do it the right way. we need to spec out what's safe and
the default behavior. And only when two independent impleers come together
and say this is a really good powerful feature and we would implement to it
do we need to spec something

Manu Sporny: All right. So, with that as a baseline, let's go into the PR.
Parth, I don't know.

Manu Sporny: I think did you merge some things and some things are not
merged.

Parth Bhatt: Yeah I can walk through the changes.

Parth Bhatt: So on the summary object I agree with both of you that we can
remove. We don't need that overall summary object from the schema. So that
is pending but I just kept it to discuss here and then I also agree on the
index property

Parth Bhatt: which is already there in the schema results object index
property. So we can remove that.

Manu Sporny: Yeah.

Parth Bhatt: but there was one more comment from you that we should
probably remove the result object completely. So I think we should discuss
that. I'm not clear on that one.

Manu Sporny: What I meant there was we should move the result the
credentials checked up a level. because the result is weird because does it
sit right beside the presentation I think right that's the part that was
confusing to me but go ahead Dave

Dave Longley: It's unfortunately Patrick is not here. I think he did a
bunch of work on the credentials endpoint and we had a number of meetings
about how to express this. So that's another place we could look and see
what we did for the output on that endpoint and see if we can bring this
sort of in line with that one as much as possible. especially if we can
share some of the schema stuff there since if you verify a single
credential there's some set of results that presumably if you're an
implementer and you're doing the presentation endpoint you would want to
reuse that code and reuse the results for the individual credentials in
some nested result object for the whole presentation

Manu Sporny: Yes, exact exactly that's what I was that's one of the things.
So I don't how do we have results?

Parth Bhatt: Hit

Manu Sporny: Yeah, see how this result here has credentials at the same
level as presentation which actually results is underneath here. So
credentials results we should map here.

Dave Longley: There's two results. There's another one above that. So, I
think there's a results that make sense there.

Manu Sporny: Yeah. Yeah.

Dave Longley: And then there's, the information on what was checked.

Manu Sporny: And agree with Dave. We should just reuse what we did as much
as possible for the verify credential response.
00:15:00

Manu Sporny: Did you end up looking at that part before? Maybe it already
is that.

Parth Bhatt: No I have not looked at that…

Parth Bhatt: but I will cross check.

Manu Sporny: And so…

Parth Bhatt: I mean not with the context of this particular change…

Manu Sporny: what is Yeah.

Parth Bhatt: but I know the general response there

Manu Sporny: Here's what goes in a credential. We should be reusing this
schema,…

Dave Longley: Yeah, for the presentation I'd expect the top level to say
verified presentation problem details and…

Manu Sporny: right? That's Yep.

Dave Longley: results and then those results could have credential results
embedded in there that would reuse this schema. That seems like that makes
sense to me for the presentation endpoint.

Manu Sporny:

Manu Sporny: A agree. That's what I was hoping we'd go to. And Parth, I'm
seeing you like thumbs up.

Parth Bhatt: Yep, I understand that.

Manu Sporny: Yes.

Parth Bhatt: So if there are some fields are missing in here, probably we
would like to update this specific schema and then it would reflect in the
specifically proof verification schema. Yeah, got it.

Manu Sporny: That's right. Yep. And then with those changes in there, I
think that should align everything and that should make it a good nice
clean PR. okay.

Parth Bhatt: Right. …

Manu Sporny: Any questions on the changes that need to be made before we do
review pars Yeah,…

Parth Bhatt: no questions.

Parth Bhatt: I just want to highlight few more things that you pointed out
and I made those changes. So regarding credential status object you
mentioned about expected value that is something that we need to add.

Manu Sporny: let's talk about that because I'm not as sure about proposing
that. so we had this credential status thing and the result of it but you
don't know what the expected value was you don't know…

Manu Sporny: what credential status was checked because you can have
multiple of them I think on there. it is an array.

Dave Longley: I don't think there's going to be any expected val for
credential status.

Dave Longley: You're just going to get back what the status is.

Manu Sporny: We …

Dave Longley: It's some value.

Manu Sporny: except it's valid is what we get back and it's a boolean.

Dave Longley: Is that what's in the credential results today?

Joe Andrieu: We shouldn't get valid back.

Dave Longley: because yeah, that doesn't seem right to me.

Manu Sporny: Yeah, that's what I'm trying to say.

Dave Longley: Okay. …

Manu Sporny: Hold on.

Manu Sporny: …

Joe Andrieu: I mean it might be verified but valid.

Dave Longley: yeah, it's a bit value, so I'd expect it to say value and the
value is true or false or whether some bit is flipped and the
interpretation of that is up to the business rules of whoever's looking at
the result.

Manu Sporny: we have valid in the last time we talked about this, we came
up with this pattern for valid, whether or not the property was valid or
not. Yes.

Dave Longley: Is that for just valid from and valid until?

Manu Sporny: I think it got copied to everything.

Dave Longley: So if you scroll down, the schema one makes sense.

Manu Sporny: No, it's credential schema as well.

Dave Longley: No, it's value.

Manu Sporny: Credential status.

Dave Longley: There's value and…

Manu Sporny: No, it's valid.

Dave Longley: So it sounds like valid does not mean that it has nothing to
do with what the value of the bit is. It just has to do it was a valid
status in that Yeah,…

Michael Burchill (Credivera): I think the cential object status is valid.

Dave Longley: and that can be confusing, but that it's like you have a
well-formed credential status object and…

Dave Longley: you were able to check it and get up the value for it. what
you do with that value is unrelated to its valid status.

Manu Sporny: We should probably rename this thing …

Manu Sporny: because it's confusing.

Manu Sporny: I think all of us were confused by it.

Dave Longley: We should do something.

Dave Longley: It might be that is the right name.

Dave Longley: It's being used everywhere and we only see the confusion
under credential status. No,…

Manu Sporny: That's…

Manu Sporny: what I'm saying is maybe in credential status we rename it. It
seems these rules that determine whether or not it's valid are part of the
workflow, right?
00:20:00

Manu Sporny: part of the exchange,…

Dave Longley: I would expect it to be a part of the library that is the
valid from field Does it have the right date format and all those other
things?

Manu Sporny: but that doesn't help you determine the business rule check. I
mean,…

Dave Longley:

Dave Longley: Yeah, valid.

Manu Sporny: because we don't have a value here.

Dave Longley: I would not expect valid to do anything for your business
rule checks.

Dave Longley: So I don't know what's going on with valid from and valid
until since there's no valid no value there.

Manu Sporny: Yep. Yeah.

Manu Sporny: Because this is syntax checking,…

Dave Longley: No, it's there.

Manu Sporny: right? The verification is supposed to be …

Dave Longley: It says input. it's there.

Manu Sporny: there it is. Sorry, missed that.

Manu Sporny: Okay, so this is a syntax check and it's reporting back the
input value to so the business rules can actually check it at the business
rule layer.

Dave Longley: Yeah. Right.

Joe Andrieu: Isn't this more about conformity than validity?

Manu Sporny: And so yeah.

Dave Longley: Yeah, we could call it conformance or something or conformed
or…

Manu Sporny: Yeah. Conformant would probably I mean the whole validity
thing as Joe's suggesting is it's confusing…

Manu Sporny: because it seem like their validation check is being done here
when it's really a conformity check or a

Dave Longley: It has too many meanings.

Dave Longley: Yep. even in those words,…

Manu Sporny: syntactic validation.

Dave Longley: a validation check is Yeah, we don't know what kind of is
Validation is used too loosely. it has too many meanings.

Manu Sporny: Mhm. Okay.

Dave Longley: That con some kind of play on the word conformance might work.

Manu Sporny: We need to raise an issue hold on one second. let me raise
this issue so that we don't change valid to something else ination results
property valid is confusing.

Manu Sporny: overs because it is not clear if business is mis valid
validation or syntaxation or some other form of validation it's occurring
we should rename no I don't want to do that Stop. I just want to change the
There we should rename some other form validation. We should rename the
property to be more specific about the action that is being performed.

Manu Sporny: verification that the field value is conformance to what the
specification requires.

Dave Longley: spec specifications. Yeah.

Manu Sporny: And I'm going to say that this is ready for PR. I'm happy to
take this one and try some words. We'll want to bike shed this today
probably. so I'll leave this one all right. So, we're going to change what
this is called.

Manu Sporny: And then credential schema probably needs the bit value,
right? Sorry.

Dave Longley: I think you mean credential status. It does have that…

Manu Sporny: Okay.

Dave Longley: if you scroll down.

Manu Sporny: Value. Okay.

Dave Longley: Yeah, of course it says integer there.

Manu Sporny: Never mind. you remember the right that's the reason

Dave Longley: I think that's reported as a boolean in some cases, but it
can cover multiple bits. yeah, credential status is that value there. is
really specific to a particular status mechanism BSL with and that's bit
string status list with multiple bits and…
00:25:00

Dave Longley: we might want to loosen this because you might use a
different status method one that is not bitstring status list so we might
want the type it can be a multi-ype value.

Manu Sporny: like string.

Michael Burchill (Credivera): Mhm.

Dave Longley: We might have to support boolean integer string and it
depends on the type of status. Yeah.

Manu Sporny: So you're basically saying don't type it and just say it's
going to be the value and it's dependent on the status. All right. We can
do that. So that would also need to be kind of updated. par.

Manu Sporny: I think this is just kind of a general when you're updating
your feel free to update verify a credential result and match and we'll
just take a look at it again part. I think this is just going to take us
multiple iterations to get it right. Okay. what else did you want to cover?

Manu Sporny: Arth okay.

Parth Bhatt: I think that's pretty much it and…

Parth Bhatt: I already covered replacing pectic formatting with proper code
tags. and then I updated the URLs to VCDM 2.0 and I updated the problem
detail schema as well. yeah, that's pretty much it.

Manu Sporny: Thank you very much for working on that stuff. yep and again
thank you for your patience as we work through this. this one was a more
difficult one to get done because we're having to kind of figure out the
design as we go. that is that item. Anything else apart on 510 before we
move on?

Parth Bhatt: We can move on.

Manu Sporny: Pull request 511 is about migrating the verifiable
presentation request spec into over time the VC API spec has slowly
absorbed the verifiable presentation request spec to the point that the
only thing that it has not absorbed yet is just like some of the query
languages in there. it's 10 pages or so of content. so what this PR does is
I'm going to go to the rendered version of the spec. what this PR does is
it adds this section of the spec section 310 which is titled requesting a
presentation.

Manu Sporny: and so it kind of talks about when you're in an exchange for
credentials, do you want one part of that exchange is going to be someone's
going to ask the other side of the connection for a set of presentations or
a presentation and it basically explains the language that you use or the
mechanism that you use is a a verifiable presentation request is very
general it only has a query field, a domain and a challenge field. And then
it can embed one or more query languages that it asks for credentials with.
for example, it can use query by example. It could use a digital credential
query language. It could use anything, right? it's like a database query
language.

Manu Sporny: there are multiple different database query languages and each
language gets a type and then you put the details of the query in there. so
that's what a verifiable presentation request is and then it gives you
examples of what does this look like? What kind of fields go in it? so
that's for query by example which does need to be worked on a bit more.
This PR just moves the content over. We also have sections for how do you
do authentication. So the query language did authentication and then you
talk about which methods you allow to be used to authenticate challenge and
domain what we expect a presentation to look what the did authentication
query language is. It's basically just like the methods you accept and the
crypto suites you accept.

Manu Sporny: And then did authentication response format how do you respond
which is basically just a verifiable presentation. the next section is
around quering for a Zcap. which by the way I don't think this section is
going to survive just because Zcaps aren't far enough along yet. So even if
it gets into the VCWG I expect us to delete this section. but would be good
to kind of let people understand there multiple query languages that can be
used here. and then there's a section on logical operators for queries
which by the way I think is probably wrong and broken and we're need to
figure out how to fix it. because it doesn't allow you to mix and match an
MDO query with a DCQL query did off query.
00:30:00

Manu Sporny: And we might want to be able to do those things.

Dave Longley: So it does let you do that but it's done what is
underspecified here is a query type that is like combination query and…

Manu Sporny: Sure.

Dave Longley: then within that would just be Vision.

Manu Sporny: We could do that. this ecosystem is getting complicated
because of the multiple different types of credential formats and query
languages and all that kind of stuff. All right. So, a note to Dave, that's
good. And maybe we need to specify combo type and say that it's in there.

Dave Longley: That's in the next section gives one example of such a thing.

Manu Sporny: Isn't this a

Manu Sporny: That's an horn.

Dave Longley: Yeah, by example query language defines and we might want a
higher level or…

Manu Sporny: Yeah. Yep.

Dave Longley: that could be used for anything.

Manu Sporny: Yep. Yep. A highway hybrid query request that can ask for an
MDOC and a VC simultaneously.

Manu Sporny: okay. So, that's the content that's being added. It is largely
a copy and paste from the current BP request spec. and I think as Dave
you've already mentioned, we are going to need to clean up the language. I
think Ted has made a very thorough pass to clean up the language. I don't
know, Dave, Ted, if you'all want to speak to this. I haven't been able to
look through the change requests yet.

Ted Thibodeau Jr: No, all my comments are in it.

Dave Longley: I can say, yeah. my comment was, first Ted made a bunch of
good editorial comments that we could pull in. he mentioned a couple things
that I think warrant larger discussion that I don't think we should turn
that into an issue. otherwise, it's mostly a straight copy of the other
spec,…

Manu Sporny: All right.

Dave Longley:

Dave Longley: and I think that's good. the one intro section I left a
suggestion on because I think it was too specific around where you would
use a verifiable presentation request and so I made it less specific in my
suggestion.

Manu Sporny: Okay. is it fairly clear which ones are straight editorial and
which ones we might need to raise an issue on?

Dave Longley: I think every one that Ted did that has a suggestion was
editorial and otherwise it was a comment about work that needs to be done
to improve something and…

Ted Thibodeau Jr: Jesus.

Manu Sporny: Okay.

Dave Longley: that can become an issue.

Manu Sporny: All right. I'll process these and we'll pick it up at the next
meeting. go ahead. Kyote

Kayode Ezike: Yeah, one thought that came to me a few days ago, I'm just
remembering it now when it comes to the query stuff is that since you
clarified last week that by example we just want to many examples and we
can essentially combine and such one thought that came to mind is would it
be appropriate to do something similar to what we do with the protocols
endpoint where we disclose to clients that these are protocols that we have
such that it becomes clearer like what that query property is supposed to
be used for.

Kayode Ezike: So I think right now my interpretation of this you as a
client can choose any of these that you support but they're all equivalent
they're just different languages whereas it might be clear if say okay
these are these are all the queries that supported up front and…

Manu Sporny: You are saying should we advertise the query languages that
might be used.
00:35:00

Kayode Ezike: depending on which path you take that will determine what you
see in subsequent APR query properties which that makes sense I mean, if
it's even something that's impossible to do in a way that every language
can more or less be formatted, assuming that every language can represent
every type of word, right? That might be an assumption that's wrong.

Kayode Ezike: But generally what I'm saying is it seems to me here that
basically this array of multiple queries is supposed to mean that you can
respond to either of these and they will be acceptable for a particular DPR
and I guess simplication might be just like having one query that is
represented by that you may have selected in the beginning of the
interaction to determine Which one?

Manu Sporny: Gotcha. I think I know…

Manu Sporny: what you're asking, go ahead, Dave. I think

Dave Longley: Yeah, couple of things to respond to.

Dave Longley: First, I think we need to clean up this example, especially
the one on the page that makes it look like what you just described,
coyote, is happening, but it's not. this example, looking at it without
more context, makes it seem like a query's coming in and the wallet will
choose from one of these types and respond to that. But this query on the
screen as currently specified actually means you're getting a query by
example in that that you need to respond to and you're getting a DAL query
that you need to respond to and this would handle cases where there's some
kind of credential that only works with a certain query language there
might be some specification that says you have to use DAL to this DCQL
language to imple

Dave Longley: implement something. so that is different from what you're
saying and we need to improve the examples and maybe highlight an example
that shows here are multiple query languages to choose with all that being
said, I don't think it makes sense to advertise or say we're going to use
all these query languages and they all mean the same thing because first I
know that that's not possible for all things like my understanding is with
DCQL you can't request things that are in a set. You have to choose the
index into an array or something. the other bit about this is I don't think
it would be good for a wallet to read that list and then assume that if
they read any one of these queries they all mean the same thing.

Dave Longley: rather they should pick the query. if this is not the right
example on the page, but if we had a page that showed where they should
pick the one that works for them and then respond to that. And it's the
protocol that says and the overall verifiable presentation request
specification that says if you the feature, then you are signaling to the
wallet that they can choose whichever one of these they want.

Dave Longley: Problem is the thing on the screen right here kind of implies
feature, but this is and feature that's actually on the screen.

Manu Sporny: Yep. Go ahead.

Manu Sporny: Coyote All right.

Kayode Ezike: Yeah, I think your response actually reminded me why it came
up as a thought because this is in the spirit of being open to as many
wallets as possible who might support different combinations of queries.
But I guess what you're saying is that it's inevitable. There are certain
use cases where you must have support for a certain query language to be
able to retrieve that. Okay. Thanks.

Manu Sporny: What's the action here?

Manu Sporny: the action is this example's wrong and…

Manu Sporny: it probably needs to be shifted into a more complex use case
for the hybrid query thing like further down Right.

Dave Longley: Yeah, I think we want to leave.

Dave Longley: Yeah, at least early we want to have a hybrid query example
and the comments and everything and the text eventually should say, this
could be the one sending whoever that is responding to the request gets to
choose in that hybrid scenario which query language they want to work with.
yeah,…

Manu Sporny: But you're saying have that be the first example?

Dave Longley: that should probably be the first example just because it's
easy to think if you use the one that's on the screen here that's what's
happening, but it's not. So we should lead with the one that does that and
then follow that up with an example that says …
00:40:00

Dave Longley: if you have a situation where you must request using
different languages and you must have both of those results this is how you
do it and that's what this example is.

Manu Sporny: Yeah. the only thing I'm hesitating is leading with a complex
example versus just a here look…

Manu Sporny: how simple,…

Manu Sporny: right? Yep.

Dave Longley: Yeah, the very first example could just be there's one query.

Manu Sporny: And then I can move the hybrid thing down.

Dave Longley: I would do the or hybrid before the

Manu Sporny: Got Can do. All right. Is there anything else we need to
discuss on this particular one? I know how to make the next pass.

Manu Sporny: I can try integrating the hybrid stuff as just an example
placeholder.

Manu Sporny: Nothing final. sure.

Dave Longley: Yeah, I wouldn't call it hybrid.

Dave Longley: Maybe we could put the word choice in there somewhere. hybrid
again that sounds like you're using both.

Manu Sporny: Yep.

Dave Longley: Yeah.

Manu Sporny: I don't know if I might just raise an issue and move that on
to a separate because we'll have to bike shed the name and Anything else on
this PR511 migrating the VPR request back or VPR to VC API?

Manu Sporny: Go ahead Cody.

Kayode Ezike: Sorry, really quickly.

Kayode Ezike: I know block, but another thing that could help with that is
potentially using an object versus an it's an object to have the keys to
the closets and arrays but to be I guess a choice between them and then I
think that roughly might work but

Manu Sporny: Yeah, that's an interesting thought. anyone else want to
provide input on that?

Dave Longley: The only problem with that is query has already been used
with an object…

Dave Longley: but pipe is a required property. So you could do something it
might get messy. We could explore it but you would have to say if the query
is an object then the end type does not appear. Other options include
introducing a new property for this and so choice of query instead of query
and instead of making it a type of query itself you can use the query
property or you can use some other property name that we would bike shed
and when you use that the top level array of queries is a choice instead of
it all of them being required.

Dave Longley: Yeah, let's not do it on this PR. F.

Manu Sporny: I think that goes into another issue and…

Manu Sporny: we have to do another PR. I am trying to not add too much to
this R. Thumbs up from Cody as All right. Right. I'll try to make another
pass on this and get it into mergeable form for All the final one this is a
oneline five character whatever change. there's some croft in here because
of removing spaces but the only thing this PR does is just uppercase oid4vp.

Manu Sporny: That's it because we did it everywhere else in the spec at
this point. so this will probably go in is what I'm saying before the next
call because it's fairly straightforward. All right, that's okay, those are
the PRs for today. We have two things I wanted to also discuss. we were
going to bite shed Allad. there are other higher priority things I want to
discuss. VCWG is starting back up, And I'm looking at our promotion of work
items to VC API is still down here. we're saying another month of work. do
we want to say that the specs ready for promotion?

Manu Sporny: ready enough we feel comfortable in the form of it is fine and
it just really needs to be refined could be heavily refined right but all
we're going to end up doing is just continuing to process PRs we're not
going to be making any huge structural changes or anything so do we want to
move it up into this list and say it's ready for promotion or do we want to
keep working on it I mean we're going keep meeting here and…
00:45:00

Manu Sporny: working on it because it's going to be multiple months before
the groups rechartered to pick this work up. go ahead Dave

Dave Longley: Yeah, I would suggest we move it up in the parenthetical can
say…

Dave Longley: but active refinement work continues between now and when it
gets promoted but it could be promoted now. We will just continue this in
the working group.

Manu Sporny: so that's the posal. is anyone opposed to that? Thinks there
is a better way forward. So, I'm just going to move it up here. meaning
that whenever the group VCWG picks it up, they pick it up and we'll
continue working on it until then. okay. I'll note that the only thing here
that I think we were hoping to have further along, there a couple of
things. There's the new PR on verifiers. I think we do need to have a
discussion about that. Unfortunately, that call is happening at the same
time as VC working group call this week.

Manu Sporny: So, we won't be able to have that discussion. and then
credential refresh. we have not worked on. I think there's some significant
design changes that I think Dave you proposed a couple of weeks ago that
we'll need to do. Quantum Safe Crypto Suites is kind of sorted there, but
it would be nice if Andre and them got that a little further along. so I
think there's still work to be done here. That said, so as long as this is
put in scope in the next VCWG, I think that's good. But we've got plenty of
work that needs to be done. I mean, this is, easily two years of work
standardizing this stuff. so I don't think we're going to run out of stuff
to do in the BCWG.

Manu Sporny: the only concern is the rechartering not actually taking some
of these things into account which means it's going to bump it to a non
four years from now which is probably not good. okay that was that The
other thing that we wanted to briefly discuss and this was mentioned last
week was that VC API might not be the best name for this spec anymore. I
think it has much more to do with credential life cycle management.
especially because we support envelope credentials.

Manu Sporny: meaning that it's technically possible for you to do doc SDJ
whatever new credential formats come along this API is set up so that it
could potentially process all those different credential formats the thing
that differentiates this API from oid for VCI and OID forVP is that it does
deal with credential life cycle management. It's about the whole life
cycle, not just delivery. So, I and OID4 VP are largely about delivery.
They're not about managing status or the issuance process or the
verification process or setting up and operating workflows and exchanges or
initiating interactions.

Manu Sporny: Thoughts. …

Manu Sporny: go ahead, Dave. Mhm. Yep.

Dave Longley: Yeah, I also want to mention that it's importantly about
expressing multiple protocols and…

Dave Longley: and multiple ways of doing things and unifying those so that
you can build your system around this and then if you can provide multiple
mechanisms for delivery. and it tells you how to do that with interactions
and how to put that on top of an exchange that speaks multiple protocols
but does one thing.

Joe Andrieu: Okay.

Manu Sporny: So, do we want to rename this before we request it to be moved
over or do we want to keep the name, move it over and have that discussion
as a bigger part of the …
00:50:00

Dave Longley: I was going to say there's a subtitle there.

Manu Sporny: go Yep,…

Dave Longley: We don't have to. We could drop the HTTP part of that, but
the subtitle is a lot closer to what we just said. And we could just
promote some variant of the subtitle there to be the main title and
eliminate the subtitle.

Manu Sporny: that's an option. Joe, go ahead. Mhm.

Joe Andrieu: Yeah, I think we need to change it. I think there's been
interesting confusion in the marketplace about DC API versus VC API. So, I
think shifting to something that's credential life cycle API would help …

Manu Sporny: Okay. Mhm.

Joe Andrieu:

Joe Andrieu: because that is the distinction. plus one for a change and I
think the simpler the better.

Dave Longley: This is effectively the VCLM instead of the VCDM. It's
verifiable credential life cycle management spec.

Joe Andrieu: I want to push back about verifiable credentials because the
point manu raised we're not just limited to W3CVC's.

Dave Longley: That's true. We are. but in the way that you put a credential
into this in that has a different format is you express it as a verifiable
credential. And the way you do that is you express it as an enveloped
verifiable credential. So, we're still totally conformant to the VCDM. you
can't put any random format in here.

Dave Longley: If you have some other format, you can envelope it and then
it can move through this API.

Manu Sporny: thoughts on that,…

Manu Sporny: I think I mean, so what Joe is saying resonates with me a bit.
I could go either a cycle management API is fine. digital credential life
cycle management API is probably confusing with digital credential API. we
might also think about shortenings C credential life cycle management C
credential the A LM comm API.

Manu Sporny: I mean I think okay, so initial question I think has been
answered. Do we want to rename it? The answer is And then now we're in bike
shedding territory. What do we want to rename it to? And we can take, a
couple of weeks to talk that through. go ahead, Joe. Mhm.

Joe Andrieu: Yeah, I Dave had a good point.

Joe Andrieu: I didn't realize we were wrapping everything so that you
couldn't just have a raw m MD doc or whatever go through there. but I calm
It's a wonderful hack credential API for life cycle management fits that.

Manu Sporny: Mhm. …

Joe Andrieu: And it would be nice to say just use the column API like you
don't have to get worked up about it.

Manu Sporny: yep. Exactly.

Manu Sporny: okay. all right. we'll come back to this. We're not picking a
name today. We're just, throwing around ideas. okay. I think that's it for
the call today. I'm going to say let's push the bike shedding to the next
call. which will be good. I think that's it for the call today. Any last
minute items before we adjourn? We'll meet again next week. All right.
thanks everyone. I really appreciate all the focus on getting this wrapped
up so we can hand it over to the working group.

Manu Sporny: we will meet again next week. until then, have a great week.
see you next week. Take care.
Meeting ended after 00:54:31 👋

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