[MINUTES] VC API 2025-05-20

VC API Community Group Meeting Summary - 2025/05/20

*Topics Covered:*

   1.

   *W3C Standard Publications & Future Work:* Announcement of several
   specifications reaching W3C global standard status, including VC 2.0.
   Discussion focused on promoting additional specifications to the Verifiable
   Credentials Working Group (VCWG), prioritizing the VC API and identifying
   lead editors for various specifications. A key concern arose regarding the
   VCWG's interpretation of the charter's scope concerning rendering methods.
   A timeline targeting end-of-summer 2025 completion for all specifications
   (excluding VC API) was discussed.
   2.

   *VC API Status List Plugin Overview:* Patrick presented a status list
   plugin developed for acupress points, highlighting different API endpoints
   for managing status lists (creation, publication, update). The discussion
   centered on whether the VC API should include endpoints for status list
   creation and retrieval, beyond the existing update endpoint. Concerns were
   raised about the potential complexity and performance implications of
   managing multiple status lists for various use cases. The consensus was to
   open an issue to track this enhancement, but deferring a final decision
   until after core VC API features are complete. The concept of "index
   allocator" for managing status lists across multiple instances was
   explained.
   3.

   *Pull Request Review & Processing:*
   - *PR (Issue Credential):* Minor edits to the description of the
      /credential/issue endpoint were discussed and merged. A lingering
      language issue regarding "issuing instance" versus "issuer" was
identified
      for future discussion and clarification across the specification.
      - *PR (Get Credentials ID):* The PR was reviewed, clarifying the
      response structure for retrieving a specific credential by ID. This
      involved ensuring the verifiable credential is nested within a
      "verifiableCredential" property. Issues with JSON schema and OAS
      auto-generation were noted, requiring further investigation. Additional
      examples for media types (including VCB) were added.

*Key Points:*

   - Several W3C specifications reached global standard status, providing a
   solid foundation for future development.
   - The VC API needs further issue resolution before promotion to the VCWG.
   - The need for additional VC API endpoints for status list management
   was discussed, but a decision was deferred.
   - Two pull requests were reviewed and either merged or accepted with
   minor adjustments.
   - Several minor language and specification inconsistencies were
   identified for future review.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-05-20.md

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

Benjamin Young, Dave Longley, Eddie Dennis, Joe Andrieu, John's Notetaker,
Kayode Ezike, Manu Sporny, Parth Bhatt, Patrick St-Louis
*Transcript*

Manu Sporny: All right, welcome everyone. This is the VC API call. it May
is going by quickly. May 20th, 2025. we have an agenda for today. It's
basically just a review of community developments, processing some pull
requests, and then categorizing VC API issues. are there any other updates
or changes to the agenda? Anything else we need to discuss today? Go ahead,
Patrick. Mhm.

Patrick St-Louis: Yeah, I think I've volunteered a few meetings back to
give a quick overview of the status list plugin that was developed for
acupress points the VC API should support. I was unable to attend last week.

Patrick St-Louis: It was my birthday so I was away. but I still thank you.

Manu Sporny: Happy birthday.

Patrick St-Louis: But I'm ready to give a quick overview if we have time
for that today.

Manu Sporny: Okay, that sounds great. And happy belated birthday. we can
put that at the beginning of the agenda after the community announcements,
I think. anything else we need to discuss today or should cover? All right.
let's go ahead and jump into kind of community announcements really
quickly. I think me mentioned it last week but it was the day before two
days before verifiable credentials 20 was published as a global standard
along with six other specifications last week.

Manu Sporny: So, VC2O, Bitstring status list, all the data integrity stuff,
VC Hosy Cozy, the SID spec, controlled identifier spec, all published as
W3C global standards, which that gives us a good solid foundation to kind
of build other things on top as some of you have been attending the
incubation and promotion meetings let me find let's see 2025 AQ where is it
I can't seem to find let me see W3C CCCG

Manu Sporny: I should have had this link community. There we go. some of
you have been attending these meetings where we've been talking about all
of the items that we are going to promote as work items to the verifiable
credential working group. we have a list. I mean, it's a lot of
specifications. We are definitely looking for lead editors on each
specification for you to kind of help us take these things through the
standardization process. based on our discussion, we believe these three
are ready to go, meaning they're not finished clearly, but they're in good
enough shape for the community group to hand it over to the verifiable
credential working group. the rest of them need some work.
00:05:00

Manu Sporny: Patrick, specifically the OCA stuff. I think you're going to
present for VC render method at some point. We wanted to make sure that you
were able to kind of get some thoughts in there before we finish this off.
So, while this is marked as ready for promotion, it doesn't mean you can't
add the OCA stuff before we hand it over. And preferably, I think we would
add that before we handed it over to the working group so they know what
the scope of the work is. again, doesn't mean that things can't change or
be added or removed during the working group process, but we just want to
make sure that it's, as close as we can get

Patrick St-Louis: Yeah. Yeah. We had a lot of internal discussion for OC
render method. I know the Swiss government was working on this a lot. They
have their specification of it that they've published on their u GitHub. I
don't have the link at hand,…

Patrick St-Louis: but it was really aligned with our approach with OCA, but
it would be nice to have a small section in there.

Manu Sporny: All right.

Manu Sporny: Sounds good. so I leave that to you, Patrick, to, let us know
how you want to proceed there. The rest of the specifications, we've done a
rough order of, magnitude work on it. we think, if we were working on all
of these things in parallel, maybe we can get these specifications all of
them ready by the end of summer 2025. the thing we think will take the
longest time is the one this group is working on the BC API. we want to
clear out a lot more of the issues before we hand it over to the working
group.

Manu Sporny: The rest of the specifications are not as involved as the VC
API. they're more modular additions on top of VC2O. So we're currently
targeting end of summer 2025. But if folks can see here this is five to
eight months of work. Let's say if we did it in serial which we're not
doing. Other groups are the data integrity groups working on the quantum
safe stuff while we are working in parallel on the BC API MVP request
stuff. and then these ones aren't really being worked on and really need to
clean those up. okay.

Joe Andrieu: Yeah, I thought the rendering method was in scope for the
current VCWG. Yes.

Manu Sporny: That is just a heads up on the list.

Manu Sporny: go ahead Joe. It is and let's see what was it is I'm trying to
not dive into the details but it is currently we are also supposed to be in
ma this is what I heard the current charter says we're supposed to be in
maintenance mode with the V v21 specification we're not supposed to make
class 4 changes VC

Manu Sporny: PC render method has class 4 changes in it. So now there's
confusion around it is definitely in scope but it might need to be a
totally different specification and wouldn't it be nice if somebody meaning
the CCG would put the specification in? does that make sense?

Joe Andrieu: So yeah,…

Joe Andrieu: but I disagree with your reading. I mean, I think it was very
clear.

Manu Sporny: Not my reading.

Joe Andrieu: And …

Manu Sporny: Yeah, I know.

Joe Andrieu: there's no problem with getting this in here. I'm just
surprised that people are saying what we explicitly negotiated is not…

Manu Sporny: I know.

Joe Andrieu: what we negotiated.

Manu Sporny: Yeah. I know.

Joe Andrieu: And they're going to set me off. And you may as well tell them
that because I will* formally object to this crap. It's not okay to
negotiate something that painfully and…

Manu Sporny: Yeah. Yeah.

Joe Andrieu: then say, "Nope, that's not…

Manu Sporny: Yeah. Yeah.

Joe Andrieu: how it actually went.

Manu Sporny: I think it's more of a technical.

Manu Sporny: Again, I don't want to, discuss it here. I don't think
there'll be any issue moving this over. yeah. I agree with you,…

Joe Andrieu: Yeah, agreed.
00:10:00

Manu Sporny: Joe. just Yes.

Dave Longley: I wanted to set some minds at ease.

Dave Longley: I'm pretty sure the only push back is whether or not the
credential rendering method can go in a separate document or if it has to
be wedged into the VC data model document, which of course it could then be
separated out during maintenance. So, it's kind of a process nafu that is
kind of silly, but I think the actual work, regardless of whether it has to
be done in a less than optimal way, could still be

Manu Sporny: Yeah. Yeah. Exactly. it's a question of W3C process. Are we
allowed to, add any anyway,…

Manu Sporny: I don't want to get into details. I think we'll work it out.
It's just, details that have to be worked out. there's no doubt that it is
in scope. I think Joe the only question is can we actually add it to the
VC21 specification because of…

Joe Andrieu: Yes. Yes,…

Manu Sporny: what the charter said.

Joe Andrieu:

Joe Andrieu: it's in there.

Manu Sporny: I know.

Joe Andrieu: We need to stop talking about this, but I am pissed that the
language restricting the spec was put in there after it was negotiated…

Manu Sporny: Yeah. Yeah.

Joe Andrieu: how this was going to work. So, I believe staff is acting
inappropriately to limit this work and…

Manu Sporny: Okay.

Joe Andrieu: it's a hot topic for me and it's going to set me off. So, I
agree we really shouldn't talk about it more here. So, let me give you the
meeting back, but

Manu Sporny: All Thanks, All right. we're going to be working on this and
getting the spec into shape and then, I'm confident something positive will
happen eventually. and then the rest of the stuff, these are the things
that we really need to kind of work on to get into better shape.

Manu Sporny: we just want them in better shape before we hand it over to
the working group so it's much more clear when the new charter goes up for
a vote what is the scope of the work that we're talking about. sorry that
was supposed to be a quick announcement. noting that VCAPI and VPR is in
the list and that is what this group is working on. any other announcements
or things we need to discuss?

Manu Sporny: All right, let's then move over to Patrick your item. and then
after that we will pick up pull request processing and…

Manu Sporny: issue categorization. over to you Patrick.

Patrick St-Louis: Yeah,…

Patrick St-Louis: thank I think the broader topic or issue here was which
endpoints should the VCPI list for the status service. So currently there's
only one endpoint and it's the endpoint to update the status of a
credential or an entry that already been issued. I think there was the one
precise question was first and foremost should the VC API list an endpoint
to retrieve the status list credential and other endpoints that could be
considered is maybe an endpoint to create a publish a status list and so on.

Patrick St-Louis: So I wanted to show a little bit. So the work that I'm
going to show has been made by has been contributed to the AUPI plugins. I
didn't make this plugin. however, it's an example of how someone
implemented API endpoints to manage status list. caveat here. their plug-in
is meant to be to work to manage both bitstring status list and IETF status
list. So it's probably a bit heavier on the configuration side that it
needs to be for what we want to discuss but I mean at the end of the day I
think the VC API itself also wants to support multiple different formats.
So maybe it is actually pretty relevant.

Patrick St-Louis: I know we had discussion before about supporting
different credential data model and different credential types formats. I'm
assuming this also goes for status. so I'm just going to share my screen
and it's not so much a demo I'm going to do. It's more just going over the
endpoints and kind of seeing how this relates to the I specification. so
the way it's been implemented here is you create A definition of a status
list.
00:15:00

Patrick St-Louis: So you would include things like the revocation your list
shard size, other information and then this would sort of manage different
instance of those status. So your current status list is going to create
the next one in advance and once the current one fills up it's going to
then rotate the active status list from which it's going to assign status
entries. so this is not so much about creating a status list credential
itself but more creating the definition of the status purpose you want to
make.

Patrick St-Louis: from that point you decide to publish your different
status list from that. so you give the definition ID and it's going to
publish the first instance of status list credential from that definition.
It's going to sign it and return it to you. And with this plugin it's like
your responsibility to then ensure it's hosted somewhere else. So this API
doesn't actually host the status list. It just creates the sort of internal
management for that list.

Patrick St-Louis: and then they have another endpoint that you specify so
you specify which definition ID and the credential ID that you've bound to
an entry or an index in that list. so currently on the VC API there's only
the endpoint for updating a status right so there's no endpoint at all for
the creation of the status list at the moment I believe it's something
that's considered that's been managed outside of the VC API meaning the
software itself already has these issued statusless management

Patrick St-Louis: So we do define a status service and I think the creation
of a status list would be something important. when we talk about a status
service it seems like only an endpoint to update the status might be a bit
too short. and maybe there could be an endpoint to create the status or not
sure about the endpoint to retrieve the status list. but that could also be
worthwhile. so that's pretty much what I wanted to kick off the discussion
for. is there any opinions?

Manu Sporny: Go ahead, Dave.

Dave Longley: So there's a lot in common with digital bazaar's
implementation of status service here. we use slashstatus lists with an s
plural as a collection of status lists and if you post to that endpoint
when you post to it directly you do so to create a new status list…

Patrick St-Louis: Yes.

Dave Longley: which it's is always bundled with a status list credential
for it. so when you post to slashstatus lists on a status instance you
include the type of list this property called an index allocator the length
of the list the status purpose and the credential ID for the status list VC
itself so we don't have a separate slashdefs for that we just do a post to
status list and then that will create the after after status lists slash
the list identifier.

Dave Longley: We have an additional API for something called TUR bitstring
status list which is a more compressible expression of a bitstring status
list that is in the VCB spec…

Dave Longley: where you can post to status list slash and then you have to
put the status purpose in the URL and that has to do with the compression
characteristics. but it…

Patrick St-Louis: So the biggest difference I'm seeing between…
00:20:00

Dave Longley: what we do is very similar to what you're doing here. And so
there's probably some common ground.

Patrick St-Louis: what you explained and this is the concept of these
definition meaning when I create a post request here it's not just going to
create one status list I'm going to create this definition that's going to
have a different list of status credentials right that can be used until
the first one they've used all the index and then you need to create a new
one but you want it still to be associated with the same group of
credential you will issue if that makes sense.

Patrick St-Louis: so I'm wondering how do you see this concept fitting in
the VC API and what you are doing at digital bazaar Okay.

Dave Longley: So I think the difference here is in our implementation, we
don't require the status service to necessarily know about the connection
between multiple lists for the same use case. it's just disconnected from
that. So whenever you need to make a new list, it's the issuer's
responsibility to do that. The only connection we have and that it could
use potentially is this So the index allocator field is I guess if we
wanted to have the status service have some feature linking a similar use
case that's how it would work is through that property. Okay.

Patrick St-Louis: maybe use case is a bad term here so let's say I create a
definition with a status length of X and status purpose of revocation. all
the status credential from that definition are going to have these same
properties right so I don't have to redefine my length every time or my
purpose. when I want to reissue against that definition, it just means the
previous one was filled or there's no more index allocator allocatable or I
believe they have the concept of a threshold that has to be met here.

Patrick St-Louis: go ahead.

Dave Longley: So my comment was going to be our implementation experience
thus far is that not considering the use case when generating lists or if
you're trying to share lists or so on can be very challenging to both
produce the right privacy characteristics and to ensure good performance
characteristics. So the size of your list, whether or not you share a list,
how frequently verifiers will have to request those lists perhaps on a
daily or more frequent basis has a very significant impact on the
performance characteristics of the system. generating a single definition
that says I have some list here that for revocation. It's this length. Use
it for whatever credentials you want. We have not found works very well.

Dave Longley: Instead, we found that you need to say we've well defined
this use case for there might be only one red There might be many types of
credentials,…

Patrick St-Louis: Very good.

Dave Longley: but we've done an analysis on it and we said for this use
case use this index allocator and that is what binds these together and
then make as many lists as are required for that use case based on all the
properties I just said and based on expiry period for the credentials and
the issuance rate for the credentials. We found that if you don't consider
all of those variables in how you're generating your lists, you could
easily either have a privacy problem or you could have a performance
problem.

Patrick St-Louis: Okay, that's interesting. So they put this supported
credit ID value which is optional and it's a random you provide just a
string and I think that's what's used to you could bind it to a use case if
you want. you mentioned a few times index allocator.

Patrick St-Louis: can you explain a little bit more what that is? Okay.

Dave Longley: Yeah, that's just an identifier that if you have multiple
issuing instances that are using the same total space for allocating status
lists and allocating indexes for those lists. You can have an identifier
that identifies that sort of abstract set of state. So you've got a bunch
of state that you need to keep track of to make sure that in a horizontally
scaling system you can appropriately randomly allocate indexes for a list
so you give that all of that state information an identifier so that it all
belongs to the same thing.
00:25:00

Dave Longley: So if you wanted to onboard additional issuing instances or
do whatever and you wanted them to slot in and use the same state and issue
into the same sort of set of lists, you use index allocator as an
identifier for that. Yes.

Patrick St-Louis: So could one index allocator ID because you just said
it's an identifier, so one allocator ID could govern multiple status list
credentials.

Dave Longley: Yes. Yeah.

Patrick St-Louis: Okay, it sounds to me like this is what it is. but I'd
have to That's not the same thing.

Dave Longley: I will say that one that does say supported credit ID because
we also have a field for the credential ID. Okay.

Patrick St-Louis: That's what I thought at first, but it's different. and I
have a gut feeling it's used in a similar way as this allocator ID because
they don't have status list credential. Yeah. No. Okay.

Patrick St-Louis: the allocator would be the definition ID maybe. but
regardless that that wasn't a point. another question I would have is so
semantically the credential status endpoint. I would argue this belongs
more on the issuer service and revoking a credential and revoking a status
entry are two separate thing.

Patrick St-Louis: I'm wondering if it would be worthwhile to have another
endpoint that's more specifically about revoking the index in a status list
itself or so when I want to revoke a redential would the issuer call its
own credential status endpoint and then that would call the status service
or is this endpoint

Patrick St-Louis: point really meant to be on the status service itself? is
that distinction something we should highlight in the VC API meaning
updating the status of a credential versus the actual entry being updated
or is that too much details? Okay.

Dave Longley: It's a good question. the current design is that endpoint is
on the status service and it is only at the status service that information
ends up getting tracked. putting it al yeah I think I would prefer to leave
it that way. There are a lot of implications if it becomes part of the
issuing service. and I think we start to couple things that are
intentionally decoupled and that are important to decouple

Dave Longley: but also for vendor lock in purposes since status can
sometimes perhaps outlive different parties different vendors and the
solutions they provide.

Patrick St-Louis: Okay. …

Patrick St-Louis: so is there something we want to add a post status list
endpoint which is an endpoint that creates a status list or do we want to
keep it as it is that it's sort of outside of the VC API

Patrick St-Louis: Yeah.

Dave Longley: It's a good question. Given the fact that you went and built
something that was almost identical to what Digital Bazaar built, maybe we
do want to offer something there. that would be but if we don't agree on
the approach, maybe we don't want to do it. it's up to implementers. We
might even if we don't want to definitively say this is…

Patrick St-Louis: Yeah. Yeah. Yeah.

Dave Longley: how you're supposed to do it, we could say a way we could
give non-normative advice. go ahead on it.

Manu Sporny: Yeah, my only concern would be adding even more work to our
current backlog, if we can agree on a design for this I think there's a lot
of benefit there because I don't think for example this is about credential
life cycle management part of managing the life cycle the credential is
also managing the status information associated with the credential and
there is no other API out there that does that and as Dave said it's a
really good signal when to you developers go off and build, something
that's supposed to do more or less the same thing. And I mean, there's a
lot of overlap as we just saw. So, I think the answer eventually is yeah,
absolutely.
00:30:00

Manu Sporny: the question and I think Patrick at the very least we should
raise an issue in the issue tracker to track this and we probably may maybe
make the decision in the working group on whether or not we want to support
this and it's kind of like a once we get all the other core features down
then we can talk about how to do this because the danger in the working
group is all of a sudden we get in a giant debate about the status list
service and it eats up six months of the working group's time,…

Patrick St-Louis: Yeah. Yeah.

Patrick St-Louis: Okay.

Manu Sporny: right? yeah. Mhm.

Patrick St-Louis: I would say there's probably already an issue relating to
this. Maybe we can look later in the call if we can just use one of the
existing issue or we want to open a new issue closing the other one to kind
of realigning the issue based on the discussion. So it's fair to say that
for now I think just this endpoint is probably enough from the V API.

Patrick St-Louis: Maybe review a little bit the options make sure that this
is okay.

Manu Sporny: Mhm.

Patrick St-Louis: I think specifically the index allocator could I don't
know if it's described already like what it does. that's the only component
that and…

Manu Sporny: It's not

Patrick St-Louis: is the index allocator makes sense to have it here when
you want to update the status of a credential because you already have the
index. So, I'm not sure what this does on the update.

Dave Longley: by providing that you guarantee that. So there's a lot the
risk to privacy if software bugs exist in this particular system is very
high. And so by requiring the client to include the index allocator to get
to ensure that it matches the target system that they're talking to is a
reason why this is here.

Dave Longley: If you just pick an endpoint and talk to it and…

Dave Longley: don't include this piece of information, it's one more place
where a single field if misconfigured could cause you to create a
catastrophic privacy problem for the holders of credentials. And so we
decided that it would be a good idea to require this to be here so that it
can be checked against the target system.

Patrick St-Louis: so the only problem I have with that is This would make
sense…

Patrick St-Louis: if the sort of creation endpoint was already there. So
there could be a bit of context as to what this is. currently I wouldn't
have an idea…

Dave Longley: Yeah.

Patrick St-Louis: what to do with so either this Yeah.

Patrick St-Louis: so I would say either define it somewhere make it
optional or remove it for now and revisit this field when if we want to
tackle the sort of status management because this is about status list
management itself. and on its own it's feels a bit lonely.

Dave Longley: I agree with all that.

Manu Sporny: Yeah, I'm raising an issue define index allocator in the
specification.

Manu Sporny: The specification currently does not define the index
allocator property on what's the endpoint status. Okay.

Patrick St-Louis: Credentials update credential status.

Patrick St-Louis: Yeah. Is index allocator in the bitst string status list
or it's a purely management term. Okay. Yeah,…

Dave Longley: No, purely a management term.

Dave Longley: So I think our options here are to say when the list was
created, the index allocator could be included there and then you could
match it when updating the status. that wouldn't require us to add any
additional API service or we could do something else.

Patrick St-Louis: maybe in this status service,…

Patrick St-Louis: this section is pretty small. We could add a note about
that the manage status lists with index allocators and that could help.

Manu Sporny: All right,…

Patrick St-Louis: All right.

Manu Sporny: that's Okay, so let me say this is ready for PR. This is
effort low. and that issue has been created as issue 485. good catch. okay,
anything else that you wanted to cover on that particular item, Patrick?
00:35:00

Manu Sporny: the status list management stuff.

Patrick St-Louis: No, no, I think it's good. I can sort of review the open
issues about this and see how this conversation relates to them and move
them along if some can be.

Manu Sporny: Okay, sounds great. Thank you very much, Patrick. That was a
great discussion. really nice to see that stuff being implemented elsewhere
in a way that's aligned with at least one other implementation.

Manu Sporny: So that's good to see.

Patrick St-Louis: Yeah, I can maybe share.

Patrick St-Louis: I'm just going to put in the chat. So, they have a little
flow diagram of how this is meant to be used. So, I can just show this and
then could further see if it makes sense with what is happening at digital
bazaar. So, I'll just leave this here. This is their sort of documentation.
and they kind of list the internal records that are created and so on. So
that's it.

Manu Sporny: interesting things. who's the implement on this? Do you know?
I mean,…

Patrick St-Louis: I believe that's the government of Ontario and…

Manu Sporny: this is okay.

Patrick St-Louis: yeah they had one of their dev to have a look at this. So
they kind of look at the bitst string status list and the IETF stuff. They
mostly use this and I think with SDJ VC that's mostly…

Manu Sporny: Mhm. Okay.

Patrick St-Louis: what they've been testing with but it's really decoupled
right eventually when I get to it. so far my implementation was like I
still use occupy for credential, but I've had a separate controller kind of
manage the status list and I didn't have time to make it into a plug-in.
They kind of tackled that first. but I would like to eventually look at
kind of hooking these functionalities up with the VC API endpoints that
there is in aapy to assigning a status entry at issuance time leverage this
work instead of being done sort of externally. Go.

Manu Sporny: Got All right. that was that item. let's then go on to the
next agenda item which is processing poll requests. we've got a couple of
new ones I was able to raise earlier today. share these pull requests.
Another one by Coyote. I Thank you.'s let's start with the one we talked
about last week. I think all of the, comments were addressed, but once I
did that, I was unsure if this is where we actually ended up landing. So,
issue credential, we just shortened the phrase the sentence to this
endpoint is used to issue a verifiable credential.

Manu Sporny: Of course, this got changed slightly. I think the content just
got refflowed. the thing that really changed was this down here. If folks
could just do a quick read to make sure that this is actually what we
decided we wanted last week after applying all of the changes.

Manu Sporny: Okay.

Dave Longley: The only potential problem there is with the English in the
first sentence.

Dave Longley: It seems like it applies you to the use case, not the
instance. So you might want to change it to the instance. And now it reads
as though the instance is making a call to itself. now might be confused
with the role of issuer.
00:40:00

Patrick St-Louis: And can we just change issuing instance for issuer?

Dave Longley: So I think issuing instance is probably the right do we say
issuing instance or…

Patrick St-Louis: Okay. Yeah,…

Dave Longley: issuer instance in the spec.

Patrick St-Louis: I think it's issuer. I think

Dave Longley: Yeah, I think it's issuer instance and then we can say during
a call instead to a call or something like instead of with a call it would
be during a single call.

Joe Andrieu: It probably should be a coordinator or…

Joe Andrieu: service instance.

Manu Sporny: issue instance.

Manu Sporny: We only use the term once. and I missed the change that you
mentioned.

Dave Longley: There I think that resolves Go ahead, Joe. It is.

Joe Andrieu: Yeah,…

Joe Andrieu: I just wanted to make a case that I believe it's an issuer
service instance.

Dave Longley: I don't know if we want to change that everywhere. and I also
don't know if that actually creates a separate confusion because it's not a
issuer service instance might make someone think there are multiple issuer
services as opposed to a abstract bit of state on a single issuer service.

Dave Longley: I think we have a naming thing we need to solve in the spec a
little better.

Joe Andrieu: I think aren't the instances all of the components in our
component diagram?

Joe Andrieu: It is an instance of that component.

Dave Longley: No. in an abstract way,…

Dave Longley: you in an implementation, this could be done with a single
service that is itself divided into instances.

Dave Longley: So there would be one component for which there are many
instances. But if you think about it in the abstract, it could fit into
that diagram.

Joe Andrieu: That seems like a weird abstraction in that it's the instance
that have that publishes the endpoint.

Joe Andrieu: The fact that you have multiple instances doesn't mean it's
not an issuer service instance. It's just that you are conceptually
combining a bunch of server instances to think of them as a server. But it
is not a coordinator instance, right? that's a different endpoint.

Dave Longley: Yeah. Yep. I agree with all of that. I just think that there
are a lot of different ways for people to think about this in the spec and
we probably want to help guide them in a more clear direction. go ahead,
Patrick.

Patrick St-Louis: I would suggest to make this must a should. I know we had
identified many occasion that VC API is meant to be a sort of per issuer
preconfigured model. However, we did leave the options open. If you want to
put options about what type of proof you want to attach and if we leave
that an option then it should be reflected in this statement that you
should really attach all the proof in a single call. but it's possible that
they can also be attached in subsequent calls.

Dave Longley: So during the call last week, we actually addressed that
point directly. we wanted to help make it clear that suance endpoint, the
credential/issue endpoint was to issue a credential. It's not a simple sign
endpoint that adds a proof to an object. And that means that the act of
issuing a credential should happen only once. And if you want to have an
endpoint that can do multiple proofs, that seems like that would be a
detail of your particular implementation that would call out to an endpoint
for example a webks endpoint that puts a proof on does generates a
signature for you,…

Patrick St-Louis: So this endpoint should reject

Dave Longley: a cryptographic signature. and so that seems like that's at a
different layer from this endpoint and we wanted to make that clear. And
that's also why we changed the text up at the top to say this endpoint is
for issuing a credential which potentially includes many other things like
upda creating a status list, giving it an index, all that stuff. And if you
called that twice that would be a real problem. But no,…
00:45:00

Patrick St-Louis: Reject a credential that has a proof on it.

Dave Longley: it shouldn't do that because it's also legitimate to issue a
credential that has some other proof on it it might be completely unrelated
to it. It doesn't matter what that proof is. You could have a proof for any
number of different reasons on a credential that has nothing to do with the
issuer or it could have to do with the issuer. again it doesn't

Patrick St-Louis: Yeah, it's not clear to me. So, you have the issue ending
point. Let's say you have a credential that has a proof from some other
issuer and there's a issuer field in that credential. You're not issuing
that credential. You're just adding a proof to it. So, I'm having a hard
time understand a use case where you would have a credential that has a
proof, meaning it's a verifiable credential and it's been already issued
and has an issuer. you're not issuing that credential as far as I know.

Dave Longley: So the presence of a proof does not determine whether or not
something is a credential. But if someone handed you a credential with a
different issuer field on it to your issue and handed that to your issuer
instance,…

Dave Longley: that should result in a failure but for a totally different
reason which is that the issuer field does not match what is expected. So
that's a different problem I don't know…

Patrick St-Louis: Okay. Yeah,…

Dave Longley: if that covers all of the questions you raised.

Patrick St-Louis: I think I Yeah. Yeah, that's Okay.

Manu Sporny: All So for this I think we've identified that we are
uncomfortable with this language but need to probably fix it across the
entire spec keep it the same. We're going to have to have that discussion
ideally separately from just this PR. we are going to keep the must. Are
there any other changes that I feel like we still didn't fix this concern.
or is the language right now okay or…

Manu Sporny: do we need to make more changes right now.

Dave Longley: I think the language we have in here is okay for today,…

Dave Longley: but we might need other changes in the spec that might change
this language or that might clarify it.

Manu Sporny: This is and then we don't need to make any changes to this
down here. Okay.

Manu Sporny: So this is clarify maybe I don't know. so that means that this
PR is ready to go. Is that where we are? Any objections to merging this
which I can't right okay I am going to then merge this because it's been
hanging out for more than a week.

Manu Sporny: let me make sure. All And then base and merge. And then that I
delete the branch. No. maybe. Yes. And that will close this All right,
that's that item. One more issue closed. Let me go ahead and go to the next
PR which is PR481. ensure that the get credentials ID thing includes an
object that contains verifiable credential.

Manu Sporny: previously we weren't when you do a get credential and give it
the ID, we were returning back the raw verifiable credential instead of
putting it underneath a verifiable credential property. we do that now.
it's very difficult to see through the PR as Dave mentioned here. Let me
see if we can look at a preview. Does the preview work? where is get a
specific no, that does not work.
00:50:00

Manu Sporny: give me a second and I can maybe check out which is this C
response. All right. So in theory now I can look get specific credential.
Before we weren't putting it under a verifiable credential. now we are. So
it used to just be this content. Now it's the verifiable credential.

Manu Sporny: and then either an object of the following form verifiable
credential an object of this form. I wanted to check with the group. trying
to means you still have to put it under a verifiable credential. I think
that's the way the indentation works. but there might be a bug in the code
that says something. So if this were at the top level it would be wrong.
what is that everyone's understanding?

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

Manu Sporny: Yes. Yeah.

Dave Longley: The nesting works the way you just said where in both cases
it'll be nested.

Manu Sporny: And I was looking at I'll go back and check but I don't know
if that is true. no I think that's true.

Dave Longley: We've got Patrick and…

Manu Sporny: I think this is the thing that's wrong.

Dave Longley: Coyote on the queue.

Manu Sporny: Sorry. Yep. Go ahead Patrick.

Patrick St-Louis: Yeah, I just wanted to put a note maybe something I could
take on.

Patrick St-Louis: I don't know if you want to update to VCDM 2.0. I know
the expiration date. since it's now published, it could be nice to just, go
through the YAML schemas and just update these fields.

Manu Sporny: Yep. Yes.

Manu Sporny: Plus one. Let's please do that. if you don't mind raising an
issue to track it and then Also doing the update. That would be awesome.
Thank you. Ky

Manu Sporny: Ready?

Kayode Ezike: Yeah, maybe this is part of what you were talking about with
nesting everything, but I think the way it reads currently doesn't seem
right because if for correct probably be just to repeat all these fields
again and then at the point where it has a context and everything
underneath that that would be different. But here it seems to me like it
does kind of read a little bit more like they're two distinct things. and
so I don't know if it's something where you would maybe define what the
common pieces are and…

Kayode Ezike: say you can either just have this or you can have this with
something else changed. But yeah, currently I'm not sure what the best way
to solve this is. Thank you.

Manu Sporny: So this is the part that flows into this statement down here.

Manu Sporny: This is wrong. So, I think the code generates this
incorrectly. It says that you need to have a verifiable credential at the
top level and that object is either this right or this but both things are
under verifiable credential it is very difficult to parse I don't know if
coyote you saw this specific

Manu Sporny: text or are you saying we should do something different this
thing this one's wrong.

Kayode Ezike: So yeah,…

Kayode Ezike: I guess what I'm saying is where it says either an object of
the following form, maybe like that that needs to be placed a little bit
lower. Yes. yeah.

Manu Sporny: So this one is also saying either an object of the following
form.

Kayode Ezike: Okay. Yeah.

Manu Sporny: They're two statements. This one is the correct one and is the
one that matches up to this. This thing is totally wrong.

Dave Longley: Yeah, I think ideally the value for verifiable credential
would say it's either a verifiable credential or an enveloped verifiable
credential. And then you could expand either one. But that sounds like work
to make it do
00:55:00

Manu Sporny: I don't know how to do that with JSON schema and OAS.

Manu Sporny: they're limitations kind of there that we're absolutely
totally agree that that's what it should say, but because all of this has
to be autogenerated because it has to work the same for everything, it is
very difficult to introspect with the OS API stuff that we have. so yeah
may maybe and so there are usability bug type things happening here that we
need to fix but can't fix that. that's a much kind of broader problem I
think. So all that to say I think the PR is correct. The respect v the
respspec oas stuff probably needs some work.

Manu Sporny: Okay. So, to get back to this one,…

Manu Sporny: so that's what this PR does. it adds a component and then,
does the appropriate things with the appropriate fields. go ahead, Dave. …

Dave Longley: I think there was also a minor change in this PR that gave
more examples.

Dave Longley: Does it do that? Give more examples of media types.

Manu Sporny: let me recall that this PR does apply the intended change.
that I think this is the other change that needs to be made. do you want to
highlight this Dave? We've got one minute left.

Dave Longley: Yeah, we added examples here for the other media types you
could use with an envelope verifiable credential, including MDO, I guess,
was the only one that was added. We have other ones. we might so that
people know how to use this with VCB,…

Dave Longley: we might want to also talk about BCB media types here and
know that people can issue an envelope verifiable credential that has a VCB
in it.

Manu Sporny: Yeah, absolutely.

Manu Sporny: And this thing doesn't exist. I don't think there's a media
type for MDOCK or MDL right now. so it might be better to use the PCB. I
was trying to, provide more than one example, but the VCB thing is probably
a good one. so we'll make that update. we are at the end of our call. we
will get to the other PRs next week, I believe. if there are any other PRs
that folks want to raise between now and next week, please do.

Manu Sporny: thank you everyone for the great call today. Appreciate all
the input and discussion. we will meet again next week and keep processing
PRs and issues and that sort of thing. Thanks everyone. Have a good one.
shop.
Meeting ended after 00:58:32 👋

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