[MINUTES] VC API 2025-06-03

W3C VC API Community Group Meeting Summary - 2025/06/03

*Topics Covered:*

   -

   *Community Developments & "No Phone Home" Discussion:* The group
   discussed the implications of the "No Phone Home" initiative on the VC API,
   specifically regarding status list retrieval and OATH. Consensus was that
   addressing this requires a broader discussion within the VCWG, focusing on
   the core VC spec and potentially exploring proof of non-revocation methods
   as an alternative to relying on URLs for revocation checks. The group
   agreed that revocation checks should be rare and authorization mechanisms
   should restrict access to revocation status. Short-lived credentials were
   highlighted as a way to mitigate concerns.
   -

   *Pull Request Review and Merging:* Two pull requests were reviewed and
   merged. PRs focused on clarifying the description of verifiable credentials
   and improving the overall text flow and consistency of the specification
   document.
   -

   *Uncategorized Issue Triage:* The group reviewed and categorized several
   open issues, assigning tasks and determining effort levels. Key issues
   included updating AML schemas, creating a use case for complex workflows
   (EMT card/incident badge flow), adding YAML for interaction endpoints, and
   adding a ZCAP example for securing exchanges. One issue regarding challenge
   verification metadata was deemed mostly resolved for credential
   verification but needing attention for presentation verification. Another
   issue concerning support for additional media types beyond application/json
   was marked as pending closure, acknowledging that while interoperability
   requires application/json, the spec does not prevent other types, but
   adding support for other types would likely need to happen in a future
   version.

*Key Points:*

   - The "No Phone Home" discussion highlighted the need for improved
   guidance on privacy-preserving revocation mechanisms within the broader VC
   ecosystem.
   - Several pull requests were successfully merged, improving the clarity
   and consistency of the VC API specification.
   - The group made significant progress in triaging and assigning
   outstanding issues, paving the way for the specification's handover to the
   VCWG.
   - The group decided to defer discussion of certain advanced features,
   such as ZCAP integration and additional media type support, to future
   iterations of the VC API specification.
   - The group agreed that the VC API should not explicitly mandate or
   prohibit the use of media types beyond application/json, leaving this to
   the discretion of implementations and emphasizing the importance of
   interoperability using application/json.

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

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

Benjamin Young, Dave Longley, Eric Schuh, Joe Andrieu, John's Notetaker,
Kayode Ezike, Manu Sporny, Parth Bhatt, Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right, let's go ahead and get started. our agenda, welcome
everyone. This is the verifiable credentials API call. the agenda today is
to go over some community developments, process some pull requests, and
classify any, remaining issues that we need to classify. I think we've gone
through and classified most of yeah, that's a good idea. We haven't done VP
requests yet. So, we'll add that to the agenda and go through classifying
any other updates or changes changes to the agenda? Anything else we should
discuss today?

Manu Sporny: we'll also add classifying the verifiable presentation request
items. then let's go ahead and go into community developments. as folks
saw, there's this new no phone home discussion that has opened on the
credentials community group mailing list. the link is, no phone.com.
there's some interesting stuff being discussed that may impact VC API and
some guidance we want to provide in the verifiable credential API namely
around status list retrieval and potentially OHTP.

Manu Sporny: we might want to provide some guidance in the spec or at least
point to other places where we provide guidance on how to keep your K
anonymity set high if you're an issuer. and then how to combat nefarious
issuers with it. statements there. I won't dwell on it too much, but lots
of really big privacy organizations signed on to it as long as a number of
people from the community including a number of people on this good to see
so many people caring about privacy. So I don't know if we raise issues now.

Manu Sporny: Actually, I guess let's have a quick discussion about this on
whether or not we need to raise issues or if it's kind of not really up to
the BC API. some thoughts on that what we could do is we could provide
stronger guidance on TP and status list publication but I think that's
largely largely most of the other stuff is kind of covered in the status
list mechanisms we could talk a bit more about static resources that VC API
00:05:00

Manu Sporny: I service provides and try to ensure that it's not or pushes
those out to CDNs…

Manu Sporny: but again it feels like that should probably go into the core
VC spec or a bit string or status list specification not necessarily VC
API. Joe, go ahead. You're on the queue.

Joe Andrieu: Plus one to that last note it's not clear that we need to
solve this problem.

Joe Andrieu: Because I think we do need to bubble up. one of the positions
I'm taking is a bit counter to how you've been approaching it, Manu, which
is I think proof of non-revocation is the way you deal with status checks
without phone home. You have the wallet do the phone home and…

Joe Andrieu: so the verifier in my opinion I would like to see them not
even get the URL. I had raised that as issue in VC that you responded to
and I felt we weren't going to be able to get through it in the time frame
that made sense so I dropped it over there. But in light of phone home the
URL that you're asking verifiers to hit is sort of very trivially rewritten
so that it's a phone home mechanism. And so I think it'd be better…

Manu Sporny: Mhm.

Joe Andrieu: if we figured out a way to just say hey the right way to do it
is for the holder perhaps in real time before the VP go and get a proof of
non-revocation. And I think that cleans up the phone home thing rather
well. It's not well supported yet. we know that this is a possible way to
do it, but I think that's my advocacy for the next generation of VCs.

Manu Sporny: Interesting. go ahead, Dave.

Dave Longley: I don't know how much we want to dig into that but there are
additional measures and other considerations both with that approach and
what information is leaked to issuers if holders are doing that and with
future…

Joe Andrieu: Yep.

Dave Longley: because you ended your sentence with next generation of ECS
depends on which generation that one is but there's also discussion of
doing ZKPS around this instead so that There might be ways to do that that
sort of change the calculus as

Dave Longley:

Manu Sporny: So I guess so I think…

Manu Sporny: what we're saying is we don't think that this group's the
right place to land that discussion. almost certainly then it means that
it's going to land in the VCWG and then the question is on what
specification maybe it is in that the core data model needs to because it
is the thing that defines the status mechanism and so maybe that's where we
raised the issue.

Manu Sporny: Joe, I know that you raised an issue recently.

Manu Sporny: I can't recall if it was about this or something else. But we
ended up closing it or something. Is that all right? Mhm.

Joe Andrieu: There was one prior to candidate wreck for VCs.

Joe Andrieu: You said you can do this like it it's just we still have the
URL in the service endpoint for the status check.

Joe Andrieu: So we didn't get rid of the URL, but you said that's not
preventing the holder from doing this in practice. but we don't have a
standardized way that it's understood that along with the initial VC, I'm
giving a proof of non-revocation in the same VP it's technically possible
to do all that.

Manu Sporny: Mhm.

Manu Sporny: Mhm.

Joe Andrieu: We just haven't bootstrapped.

Manu Sporny: Mhm. Yeah.

Joe Andrieu: Hey, here's the normal standardized way that you can do it and
people should expect this ability …

Manu Sporny: I guess what I'm trying to ask, I think, is should we raise an
issue right now about that?

Joe Andrieu: I think we could. The reason I said next generation is because
I think I want changes that are class 4. I do not want that URL in there
and I want a way to have the URL that is communicated to the holder but not
to the verifier. and…

Joe Andrieu: so there are wrinkles in this layout and I think Dave probably
has some other good points about other wrinkles. So, it's going to take
time to work through those wrinkles. and I'm not sure we have the mandate
to do it in this cycle,…

Manu Sporny: Yeah. Yep.

Joe Andrieu: but I'm okay with, raising the issue and saying, hey, maybe we
can't address this now, but, the world is talking about this and maybe this
is where we start the conversation that will flow into our next
rechartering.
00:10:00

Manu Sporny: Yep. Yeah.

Joe Andrieu: I mean, it'd be better if we have the arguments when it's not
in the face of the charter so that when we get to the charter, we have some
consensus.

Manu Sporny: Yeah. I think what you're saying is start the discussion now.

Joe Andrieu:

Joe Andrieu: That's and knowing that we probably can't change it in this
particular chartering.

Manu Sporny: Yeah. Yeah. Yep. what happened? did I just

Manu Sporny: There we go. not our current maintenance.

Dave Longley: Yeah, another piece of this is with selective disclosure, you
can just leave out that whole section already. so there might not even need
to be a class 4 change and so we might just want to discuss that.

Joe Andrieu: Yeah, sure. If…

Joe Andrieu: if you have selective disclosure

Dave Longley: Yeah, there's an additional piece of this in a number of
other groups…

Dave Longley: where discussion has been done where generally speaking
checking revocation should be rare. It's not needed almost for most use
cases. and so there's a whole discussion around that and it might just be
we're having a lot of discussions around people doing revocation when maybe
they just shouldn't be doing revocation in order to do revocation well.

Joe Andrieu: tight.

Dave Longley: With longived credentials there are a lot of updates that
need to happen and that might be problematic and maybe credentials should
be more short-lived in those cases. we need to have a discussion over where
this matrix falls where it makes sense for a lot of revocation checks to
even be happening and maybe it doesn't. It's like I feel like whenever we
talk about this issue we talk about it in isolation too much for each of
the individual properties. When you put it all together,…

Dave Longley: I suspect you end up with a very limited set of use cases and
maybe even it goes to zero where any of this actually matters because you
shouldn't have been checking revocation in the first place.

Joe Andrieu: Yeah, I think there's a lot of truth to that.

Joe Andrieu: There's both the short-lived pattern that could get around a
whole bunch of it. but also one of the shifts I'm trying to establish in
our conversations at large is to move away from the expectation that
revocation is a publicly accessible endpoint. when I go to the grocery
store and I give them my driver's license, they do not have the right to
find out if that license is revoked or not. police officers do and law
enforcement and the courts do.

Joe Andrieu: And so I think there is a conversation about hey revocation
isn't this thing that anybody can just check.

Dave Longley: Yeah. Yeah.

Joe Andrieu: And so design your system so that the right parties who should
have access to that potentially private information are appropriately
restricted.

Dave Longley: And that might not require class 4 changes either. It just me
might mean more statements that say you should put authorization in front
of fetching these status credentials and…

Manu Sporny: Mhm.

Dave Longley: only authorized parties can get them.

Joe Andrieu: I agreed. Yep. But I think most people get into these debates
at IW about privacy rights and whatever and it's because of this
presumption that revocation isn't public. And I think we can address a lot
of problems by just making it not public.

Dave Longley: And I think that'll cut down on the problems, but I think
some of that gap will be filled in with fears of special authorized parties
doing all these extra checks. and so I think there's a number of places
where we can cut down on this and it just becomes a very rare pattern.
generally I think it should be a surprise to in the future. I think it
should be maybe not a surprise but unexpected if most of the credentials or
common credentials that you're getting come with revocation status that
should probably be an uncommon thing that happens especi…

Dave Longley: unless the credential is very long live longived and unless
it's some kind of super high value thing again I think we need this matrix
so we can understand where it even makes sense for this thing to show up.
And then digital wallets can even flag things like, hey, this doesn't seem
like it should have revocation on it.

Joe Andrieu: And I just want to know at the same time I remember
conversations and…

Joe Andrieu: I think it was a Neil who was we're the federal government we
will have revocation and it was hard to get him to realize that hey a
short-term credential is actually more useful to you in many use cases when
I'm checking in at CBP at the border I have a window in which that check-in
is allowed to go from my mobile to actually my physical person going
through right in that 4hour window you don't need a revocation
00:15:00

Joe Andrieu: But it was hard to get Anneil to sort of grasp that.

Joe Andrieu: Yet another challenge in the conversation.

Manu Sporny: Right. okay.

Manu Sporny: I've raised the issue on VC data model. I think that's good
enough for now and we can kind of explore that in that group and then agree
that this group is probably not the right group to explore all those
things. given that and thank you that was a great discussion. exactly what
I was trying to figure out. next item on the agenda is processing open pull
requests. we have two of them for the verifiable credential API. the first
one was waiting on me to make some changes which I did earlier today.

Manu Sporny: Dave, you had requested that we list the VCB potentials and
you also said that we would want to say something for verification and Ted,
it looks like you have made some other changes. which is fine. we can merge
those in as so let me do that now. And then if folks can Okay.

Dave Longley: Ed's changes just invert the order in…

Ted Thibodeau Jr: Right.

Dave Longley: which you talk about it.

Manu Sporny: Yep. That is great as always.

Manu Sporny: GitHub has a UI bug where sometimes you can zoom fix So, all
of those are in. Okay.

Manu Sporny: So changes made here are making sure that this object includes
it verifiable credential and then Dave you wanted to make sure that we
mentioned BCBs and alternate formats and Ted you fixed up the grammar and
flow there which is great and I added something for verify credential here

Dave Longley: I did see one change. If you scroll up with versus during.
I'm trying to look over that and see if that still makes sense when we
change that.

Dave Longley: Yeah, that's is confusing because it's not the issuer
instance that is making the call, but it implements the call. So, we might
want to put that back to during Yeah,…

Ted Thibodeau Jr: Maybe that's in reply, too. If we leave it open,…

Dave Longley: that there could be better language than during using some
kind of reply or something, but I don't know how much more we want to shut
Then…

Ted Thibodeau Jr: I'll get back to it in a little bit.

Manu Sporny: I would like to merge this today mo mostly…

Manu Sporny: because it's been hanging out there for a couple of weeks now.

Dave Longley: then let's use Ted's text in reply to a single call.

Manu Sporny: groups in reply to a single call. Must I don't think we
usually use this language.

Dave Longley: Do we want to say response not reply? What do we usually say?
00:20:00

Joe Andrieu: I like response for…

Joe Andrieu: what it's worth.

Manu Sporny: Yeah, I think I favor that slightly as well.

Manu Sporny: Okay. then I will change

Manu Sporny: All right. we have that there. And if there are no objections,
I'm going to merge this. It's been out, I guess, two weeks now. I think we
got everything. And if we didn't, we can always go back and do another PR.
All right, that is done. All right, next PR is in Coyote. I merged yours
earlier today because it was straightforward. just say

Kayode Ezike: Yeah, I was gonna make a comment though. like it was
prematurely merged.

Kayode Ezike: It was a text that I put in there that I needed feedback on
where to put it and so it was actually never included anywhere in that…

Manu Sporny: No. Whoops.

Manu Sporny: It was the oath 2 thing,…

Kayode Ezike: but yes we might have there was an EP to address that.

Manu Sporny: right?

Kayode Ezike: Yes. yes up there comment …

Manu Sporny: Sorry. I totally missed that. Yeah.

Kayode Ezike: but even before the actual quote which is just asking what
location to actually put this in because there's a few places where it
could make sense but this understanding that it wouldn't necessarily be in
the general authorization location because it's closer to the end point
than it is to a general common authorization. Yeah.

Dave Longley: Is there any reason since we're going to put it in pros as
shoulds just put that into make optional properties in the schema for those
two things?

Dave Longley: Any reason we shouldn't just do that?

Kayode Ezike: Yeah. …

Kayode Ezike: so we do have the optional properties. So, you're saying just
add this at that point. yeah.

Dave Longley: So, in this change that just happened, did we put
specifically an OOTH 2 object and a …

Kayode Ezike: Configure earlier.

Dave Longley: we did do that. Yeah. Okay.

Kayode Ezike: Yeah. it was mostly that's just…

Dave Longley: Yeah. Do we need the additional pros?

Manu Sporny: I don't think we do,…

Manu Sporny: but

Kayode Ezike: that's the decision we came to I think when we created the
issue but I don't have a strong feeling about it.

Kayode Ezike: Yeah, I'm finding it out there.

Manu Sporny: Yeah, I don't read this the same way,…

Manu Sporny: Coyote. I think I mean, I could go either way. I don't have
strong feelings about this. I mean, basically, if somebody comes back and
they're I don't understand what I need to do with this. then we could, add
more pros. That's typically what we do. But here it's kind of like if I
were implementing some if I were implementing this and I was doing OOTH too
I'd do find in the spec for OOTH and look at all the places it pops up and
basically be like okay I guess this is where I put the issue config URL.

Manu Sporny: I don't know if I'd need anything more than just where does it
go in the object.

Kayode Ezike: Fair enough.

Kayode Ezike: Yeah, I think this came from the discussion about the fact
that it started off nonsp specified and…

Manu Sporny: Specify …
00:25:00

Kayode Ezike: then we had patient that implemented that. So we figured okay
then to fit those implementation we should add this. I think that led to a
discussion about okay maybe we should make it clear that we can't extend we
eventually might want to expand the space of options and call that out a
little bit but yeah either way I'm fine leaving it out for now though Just
Yeah.

Manu Sporny: I mean, you open this issue, Cody, if you feel like there's
more text that would have helped you initially or at least, would have been
made it much clearer, let's definitely add that.

Manu Sporny: But again, I'm not hearing you say this isn't good enough. we
need to do more or whatever. …

Kayode Ezike: No, I think this is fine. yeah, if folks eventually want to
add other types, they can I guess that'll lead to changes in spec, but for
now, I think this is fine.

Manu Sporny: All So we merge that and have discussion around that. And I
think this one's closed. PR. All right.

Manu Sporny: That one closes all right. So, that was that one. And then
this one is PR483. and a couple of changes. Okay.

Dave Longley: We can go with Ted's suggestion.

Manu Sporny: All So, here we are. Okay, I think this achieves what we were
trying to achieve in 6. any objections on merging? I think we got
everything.

Manu Sporny: I'm going to delete the branch. And then access. Yeah, that
one's closed. All right, we have 31 issues left. So, we are making some
progress on those.

Manu Sporny: and in theory we can knock out 14 more issues and then the
spec will be more or less ready to be handed over to the BCWG. So in those
loweffort ones so hopefully that happens over the next two months. I think
that's a reasonable number of PRs to address in two months. okay, let's
look at uncatategorized issues and let's take some of these. update the AML
schemas for verifiable credential 20. I think that's totally fine. it is
ready for R and effort low. so I think we're good there.

Manu Sporny: next issue is 480. Create a use case in SQL diagrams for a
complex workflow. I think Joe, you said you'd take this
00:30:00

Joe Andrieu: Yeah, let me speak to Eric and I kicked around what would make
a good use case. and I think the one we want to use is the first responder
flow if that works with DB. in particular, we've got the stateisssued EMT
card,…

Joe Andrieu: which is separate from the way that we're issuing incident
badges. And so that feels like the kind of dependency we were talking about
where you wanted to include potentially using the same workflow server to
handle both that hey I need to give you my evidence i.e. my EMT
certification credential as part of an issuance flow to get my incident
response badge.

Manu Sporny: Yeah, that sounds Yeah,…

Joe Andrieu: Yeah. And

Manu Sporny: That sounds like a good use case. what do you plus What any
objections to that from anyone else?

Manu Sporny: We could always use a different flow but Yep.

Dave Longley: No, that's totally fine. another one not to make it too
complicated, would be a Present the refresh VC and then receive some other
VCs in response.

Joe Andrieu: Yep. Yeah.

Manu Sporny: Yeah, I mean that would be kind of like you present one
refresh VC and get three other VCs in return or something like that. I
provide a precursor VC to get I guess that is kind of the same for refresh
isn't it?

Manu Sporny: It's like you're providing a precursor VC to get another VC.

Manu Sporny: Okay.

Joe Andrieu: That's right.

Joe Andrieu: I think they're both interesting use cases in the real world
that people are like, " how should I do that?" So, I'll start with the EMT
one. and if that doesn't feel like it's sexy after I write it as it does
now, then we'll try the VC refresh one.

Manu Sporny: I'm going to say effort low even though I know it's going to
be a decent chunk of work. meaning it's a fairly mechanical thing I think
for you Joe.

Joe Andrieu:

Joe Andrieu: Yeah, I think it's just I'm on task. I need to sit down and
write something up.

Manu Sporny: All right. So that one. next issue is issue 479. Add YAML for
interaction endpoints. we have not done this. That's true. I think we just
need to do this. I think Eric you took a task for this. I think this is a
loweffort thing maybe.

Manu Sporny: Go ahead, I think we don't have any open PRs,…

Eric Schuh: Yeah,…

Eric Schuh: it should be pretty low effort. Feel free to assign it to me. I
think my biggest question with this issue is if it would be better to make
sure or just let all of the YAML files for all the endpoints settle and
then do another pass to make sure the tables are all accurate because I
know there's been a fair amount of changes to the different endpoints since
I put the interaction tables together originally. Okay. Yeah,…

Manu Sporny: so I think you should be good to go here.

Eric Schuh: if there's nothing expected,…

Manu Sporny: Yeah,…

Eric Schuh: then I'll start in on this

Manu Sporny: I don't think we're expecting anything. yeah, I think we're
good to go for that one. Thank you, And then securing exchanges with ZCAPS.

Manu Sporny: I think Joe, you would like to see an example on how this is
done. Joe, could you speak more to this? I'm trying to figure out what's
the level of effort here? I can think of ways that this could be effort
high.

Joe Andrieu: Mainly we have this notion of an exchange giving you a URL
that you hand off to someone. and it seems to me a ZCAP is a reasonable way
to secure that URL. And I think I've heard that that's straightforward, but
we don't really talk about it. so I'm happy to talk about it in the
lightest way possible. it just seems like a natural question of…

Joe Andrieu: if you know about ZCAPS and you're looking at the VC API and
exchanges, sort of begs the question of shouldn't these play nicely
together.

Manu Sporny: Dave, thoughts on I mean my concern about this is us having to
potentially go and…

Manu Sporny: update the ZCAP spec and then update the HTTP signatures,
thing and then we can finally get around to cuz
00:35:00

Manu Sporny: because I know we've certainly implemented securing this stuff
using Zcaps but I guess the question I'm loathed to put something in the
specification where we're kind of like this is what the current
implementation does but there's absolutely no specification to back it up.
Yeah.

Joe Andrieu: Right. I mean,…

Joe Andrieu: my immediate reaction that had me laughing it's a feature, not
a bug. I would love for you to update the Zcaps so that it has this
information. So if this is how I get you to do it, I'm happy to have that
motivation,…

Manu Sporny: Yeah. I think it's a time issue,…

Joe Andrieu: but I appreciate what you're saying about workload and we got
to pick our battles, but they're ready for some more investment. Yeah.

Manu Sporny: not a desire issue. so I'm going to put this as effort high
because I think if we do this, we should probably do it right.

Manu Sporny: And I think it's not even ready for because I think we'd want
to how about this? We could say it's ready for PR and you could do the
latest everything. but the second we do that, all of a sudden we're,
expressing things that don't exist in other specs that only exist in exist
implementations. so we might not get around to this in,…

Manu Sporny: version 10 if we can't also update the Zcap spec and that sort
of thing, which I think is fine. I mean, it's not the end of the world if
we can't get that in there. okay.

Joe Andrieu: Yeah. Yeah.

Joe Andrieu: Plus one of that set of prioritizations would work.

Manu Sporny: All okay. I think we've got everything except for hold on.

Manu Sporny: what's this? These two more than I thought that we had not
those are Response metadata for credentials verify and presentations verify
to include challenge verification metadata. I thought How should the
current response format for checks, warnings, errors be restructured to
contain some variant of challenge verification metadata uses first
verified? we talked about this a year ago.

Manu Sporny: Yeah, I don't. So verified credential verification results
returns verified the credential that was verified an array of problem
details and a result wait and the verification results valid from whether
or not it was The input value valid until

Manu Sporny: Results of validating the credential schema. Results for the
credential status object including the entry bit, Credential status object
and the proof and whether or not it was valid and the input that was
provided.

Dave Longley: I think all that might be missing at this point is…

Dave Longley: how the challenge is handled. But that's not a verify
credential result. The challenge would be on verifying a presentation…

Manu Sporny: Mhm. Okay.

Dave Longley: because I know we did a bunch of work probably between now,
after a year ago on updating problem details, but I imagine we still have
not done something with how to report information on challenges.

Manu Sporny: Go ahead.

Joe Andrieu: Yeah, I was going to say one thing you could add here,…

Manu Sporny: Go now,…

Joe Andrieu: Manny, is that this doesn't apply to credentials It's
presentation verify, which helps us a little bit.

Manu Sporny: right? But I think we fixed it for I think that's…
00:40:00

Manu Sporny: because we fixed it for credentials addressed the issue for
verify…

Dave Longley: Yeah, it seems like we've probably addressed the first part
of the issue and…

Dave Longley: not the second

Manu Sporny: but have not done so for presentations verify.

Manu Sporny: PR should be raised to clarify what the return value is for
presentations verify endpoint. It should be similar the I include result
use for challenge main nons.

Dave Longley: No, I don't think there's any thing to check for Non is a
client side value that just gets set.

Manu Sporny: Okay.

Dave Longley: challenges what the verification site is tracking.

Manu Sporny: All So, I'm going to say this is preferred blow ready for PR.
and then I'm sure we'll discover things when the PR is raised. good. That
one is Add support for advanced BBS features like pseudonyms. we need to
continue to talk about that one. I don't think we can classify it.

Manu Sporny: issue 433 consider to introduce a manifest describing entry
point static endpoints. don't have marked pending close. We asked Philillip
to document use cases and join us for a call and that has not been done.
all right. So, we can't do that one. It's not ready for PR. allow generic
unwrap ECVP and specific media types where appropriate.

Manu Sporny:

Dave Longley: So I think the resolution here was the spec says you
interoperability you need to implement application/json. That doesn't say
you can't do something else. I don't know that we need to say that you need
to be able to do something else either.

Joe Andrieu: Yeah, I would be hesitant to say that it is an optional
feature that you could also have these other types,…

Joe Andrieu: but we also shouldn't say you can't do it. I think the same
way you are Dave. It's an interoperability nightmare waiting to happen.

Manu Sporny: Mh All right.

Manu Sporny: So, are there any objections to marking this as pending close?
00:45:00

Manu Sporny: Go ahead, Joe. No,…

Joe Andrieu: I'm wondering do we have a way maybe we don't have a lot of
optionality like this,…

Joe Andrieu: but do we have a way to sort of discover what a given service
does support? if someone supported a seabboard representation instead of
JSON?

Manu Sporny: no, we don't. we had, Mike Farley raised that kind of question
fairly early on and we basically said, " we might get around to doing
that." But then, probably said what Dave's going to say. Go ahead, Dave.

Dave Longley: Yeah, I was going to mention most of the discoverability
options when we discussed them. They didn't make sense for the use cases
where you're building coordinators to talk to systems how they work and
they've been some administrator set up something for you to run against.
the discoverability options made more sense at the delivery layer where
you're talking about like a wallet or a piece of holder software choosing a
protocol to speak to receive a credential and to choose the format for the
credential and all so all of those sorts of things got pushed to those
layers in the delivery protocol.

Joe Andrieu: Cool.

Dave Longley: I don't think it made any sense and we couldn't defend it
putting that stuff at the life cycle API.

Manu Sporny: Any objections for marking All that is marked as pending note
in appendex. yeah, I mean it's up to Patrick if he wants to say something
that he can always do other things on top of the core spec as long as you
don't violate the core spec. it's like a perennial discussion in working
groups where we don't need to say that because that's always true.

Manu Sporny: Okay.

Joe Andrieu: What…

Joe Andrieu: what we might be able to say, not that we need to now, but
just in terms of future conversations if he comes back, is we encourage
experiments in the field and if there are things that make sense and get
adoption, we can add it in a future.

Manu Sporny: Mhm. Okay. Yep, that sounds good. yeah.

Joe Andrieu: It's kind of trying to future proof and be able to do all the
things and let's just get one thing out.

Manu Sporny: You're saying add that as a note in the spec.

Joe Andrieu: I'm saying if Pat comes back and wants to do more,…

Manu Sporny: Okay.

Joe Andrieu: we can say great. And we think that's a good candidate for VC
API 2.0.

Manu Sporny: Mhm.

Joe Andrieu: We can defer those innovations. Yep.

Dave Longley: Yeah, in some sense that's the same process anything goes
through.

Dave Longley: You bring enough people who want to interoperate on X and
then it can get in the spec.

Manu Sporny: Okay, that is everything for VC API. We're going to try to do
VP request spec, but we're at time more or less today. Let me see how many
issues we've got. These are all ready for PR, but we don't have a level of
effort marker on them. we'll come back and categorize these. We'll make
another pass over the next couple of weeks. okay. I think that's it for the
call today. we will not have a call next week. in fact, all of our CCG
calls are cancelled next week.

Manu Sporny: I will be traveling and so we will meet the week after and
even that meeting that might not be true. we'll see. so definitely no
meeting next week. we will have potentially meeting the following week. and
in the meantime, if you can, pick off some of those loweffort, PRs, please
do. and, thank you for the wonderful discussion today, and we will see you
again, in about two weeks. Thanks all. My
Meeting ended after 00:49:55 👋

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