[MINUTES] VC API 2025-09-09

VCOM Meeting Summary - 2025/09/09 14:58 EDT

*Topics Covered:*

   1.

   *Community Updates:*
   - Verifiable Credential Working Group (VCWG) work item priority poll
      results showed strong support for VCOM, with many expressing interest in
      being editors. Incubation and Data Integrity calls were
cancelled due to a
      W3C system bug. Final community group specifications and IPR commitment
      requests were sent out.
   2.

   *Updating Clients and Endpoints:*
   - Discussion focused on improving the clarity and organization of API
      endpoint definitions in YAML files. A Google Doc will be created to
      collaboratively update and annotate the endpoint tables. The group
      considered consolidating all OAS files into one, then
potentially splitting
      them later based on components (Holder, Issuer, Verifier, Exchange) while
      acknowledging potential semantic differences between components for the
      same endpoint (e.g., deleting credentials). The group also explored
      referencing other YAML files to improve modularity.
   3.

   *Pull Requests:*
   - *PR 525:* Update to component overview (requires broader YAML file
      revision).
      - *PR 529:* Added "Relationship to Other Specifications" section
      clarifying VCOM's differences from OID4 VP and ID4 VCI. This
also included
      an "Alternatives Considered" section for tag review.
      - *PR 531:* Renamed "Website Interaction Protocol" to "Invite
      Request" for improved clarity.
      - *PR 528:* Clarified the lack of standardized configuration
      endpoints, except for create workflow configuration.
      - *PR 532:* Reworked the administration component section to improve
      clarity on configuration.
      - *PR 535:* Added sections on general security considerations and
      best practices to the security considerations section. This PR needs
      further refinement to better address the distinction between backend and
      frontend coordinators.
      - Several PRs related to conformance classes were discussed, focusing
      on defining minimum implementation requirements for each
component (Issuer,
      Verifier, Holder, Service, Workflow). The group debated the necessity of
      defining conformance classes for every client type. It was suggested to
      prioritize defining conformance classes for exchange participants.
   4.

   *Open Issues:*
   - Issue 446: Underspecification of variables in the exchange flow
      requires further clarification to ensure interoperability
between different
      workflow services. The need for specific properties to save results and
      credential data was highlighted.
      - Several VP Request spec issues need to be migrated to VCOM.
      - A template example is needed to address several open issues.

*Key Points:*

   - Strong community support for VCOM is evident.
   - Endpoint YAML file organization needs significant improvement. A
   collaborative Google Doc will aid in this process.
   - The group is working towards clear and concise conformance class
   definitions.
   - Several open issues require further attention and action items.
   - The group is adopting a strategy of iteratively refining the
   specification and addressing issues.

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

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

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

Manu Sporny: All right, let's go ahead and get started. We've got a pretty
full call today on the agenda. welcome everyone. This is the VCOM call. I'm
just noticing I need to change the name of the meeting in Google Meet. but
we are now re renamed and the renaming went fine on the spec and the
repositories and all the appropriate redirects are set up now. so that's
done. we do have an agenda for today. largely community updates. we are
going to talk a bit about updating the expected clients for each endpoint.
and then process any pull requests. I had a fairly free day which allowed
me to get a lot of poll requests in today. So that was nice.

Manu Sporny: and I think that's it for the agenda today. Any other updates
or changes to the agenda? Anything else we'd like to discuss? If not, we
can get going. I will let's see. the only community updates are that the
poll is still out there for the verifiable credential working group work
item priority poll is still out there. we've gotten a good bit of feedback
in that poll. Let me try and bring it up.

Manu Sporny: I got to do it in a way that does not expose people's email
addresses. One second. All right, here we go. So, this is what we are
currently at. We've got 27 responses, which is a very healthy number of
responses. we've got good data at this point. 27 responses, 24 of those
people want to be a part of the new working group. which is looking pretty
Render methods the only one that got two people hating on the specification
saying that it's not necessary. which I thought was funny. but a fairly
strong support saying it's very important that people would implement it.

Manu Sporny: Half of the respondents said that they're either interested in
being an editor. We've got five people that said that they would be editors
on it. So, that's good. confidence methods kind of high as same kind of
breakout. Not very many people want to be the editor of confidence method.
We've got a couple of may. VCOM very high. this is the number one most
supported specification. So that's what this group's working on. There is
very strong desire within the community to use it. fair number of people
want to be editors on it. So that's barcodes again a little less strong
support but still pretty strong. and I'm just going to go through the rest
of them.

Manu Sporny: wireless less less, strong people are "Yeah, it's important,
but not as much as, the other stuff." refresh kind of got the same
treatment. the quantum safe stuff is really up there as well. It's I think
the second most important one as far as people voting. unfortunately, it's
not ready. Not a lot of work has gone into it. So, we'll have to kind of
poke the authors and editors of that spec to do a bit more work on it.
nobody wants to be the editor on this spec for that one. So, that's
interesting. verifiable issuers and verifiers, same kind of outcome as
confidence method and wireless which I thought was interesting.
00:05:00

Manu Sporny: not a lot of interest in being the editor, but we do have a
couple and then there are a couple of, thoughts on other things that we
could do. so we're getting good feedback. We will go over these responses
in the VCWG call tomorrow. reminder that the incubation call tomorrow is
canceled. So is the data integrity call on Friday. Unfortunately, I do not
have the rights to cancel those calls. I can cancel all of them or update
every single one of them, but I do not have the rights. For whatever
reason, the W3C system has a bug in it. Can't cancel those meetings. So,
reminder that they're canceled. I think that's it for community updates. I
guess the other thing to mention is that the final community group
specifications went out.

Manu Sporny: The request for IPR commitments are out. If you participated
in the work at all, please do the R commitment. it helps The IPR commitment
basically says you do not intend to raise any patents on the content in the
specification. we need to get at least the people that contributed
significant content to it to provide those IPR agreements. Otherwise, the
sections that they contributed will be cut from the specification.

Manu Sporny: So, please pay attention to those two things both for
confidence method and render method. when in doubt, if you plan to not
raise any patent, things with it, please, make the patent commitment. let's
see. Okay, I think that's it for community updates. anything else we should
cover from a community updates perspective? All right. next item up is
updating the client's endpoint stuff. I think Eric, you were going to take
this on. if I remember correctly,…

Manu Sporny: how are we doing on this one?

Eric Schuh: I think there's still some discussion going on as far as …

Eric Schuh: what to do specifically with the credentials delete endpoint if
I'm not confusing my PRs. and the main issue there I mean I think it ties
into kind of the issue modu that we were just discussing on the new one I
raised which is that we have a number of endpoints that currently live in
particular YAML files that apply to multiple components and that is what's
currently not being disambiguated correctly by the code that is generating

Eric Schuh: those component tables. so I don't know if there's a bigger
discussion to be had about kind of that problem and the state of the YAML
files or…

Eric Schuh: if we just move ahead with the current state and fix the
disambiguation in the table generation code. …

Manu Sporny: Yeah. …

Manu Sporny: so I think what one of the thing and you might not have been
here on that call, but I think one of the things we said we wanted to do
was basically where is take these tables and put them in a Google doc so
that we can just annotate them and move them around in the Google doc. And
then once we do that, we'd come back in here and fix everything.

Eric Schuh: Yeah, I definitely missed that.

Eric Schuh: I do have the originating Excel spreadsheet that we used to
generate these initially or…

Manu Sporny: Okay. Yep.

Eric Schuh: not Excel but Google's sheets. so I can put that together with
I guess the current updated versions and then share that in probably the
issue I suppose.
00:10:00

Manu Sporny: Yeah. let's do a Google doc because we want people to be able
to comment on this stuff and…

Eric Schuh: Okay.

Manu Sporny: and I know the Google Sheets stuff is a little more difficult
the comments get kind of buried in little yellow arrow in the top arrow
thing. So let's try Google Docs and so multiple people can comment on
different parts of it.

Eric Schuh: Perfect. Then I will get that doc thrown together. maybe before
the end of this call, I'll start working on it now. so that we can share it
here.

Manu Sporny: Okay,…

Eric Schuh: And I'll try to update the doc with kind of the corrections
that are known to be needed.

Manu Sporny: great. Perfect.

Eric Schuh: Okay.

Manu Sporny: Okay, that sounds good. thank you for working on that. all
right. I think that basically covers PR 525. So, pull request 525 was to
update the component overview, but now we're kind of like, maybe we needed
to do a much bigger kind of pass. the other and we might as well talk since
you mentioned the issue. Eric, let's talk about this one.

Manu Sporny: this is basically which YAML file should the interaction
endpoint live in. the reason we have everything broken out in the way that
we do is because some folks very very long ago that were in this group
insisted that we separate them into different files and insisted that we
had to create it that way.

Manu Sporny: and had to create API files OAS files for the different
components and we are past kind of that level of thinking I think in the
group I don't see any reason why we shouldn't just consolidate it all into
one YAML file at this point we break it out in the specs I don't think it
hurts anything to put them all in one YAML file yes the AML file can get a
little big but it is not clear to me what keeping them in multiple files is
doing to help us. And in this case specifically, it's really hurting us.
Meaning, we've got duplicated API endpoints and we're having to create
components for them and all kinds kind of gross things.

Manu Sporny: So one thing we could do here is just consolidate all the OAS
into one file.

Manu Sporny: And what do folks think about that? Go ahead, Eric.

Eric Schuh: Yeah,…

Eric Schuh: I think The other way would be to update the files so they
actually reflect our current components, Because I think for the most part
we have holder, issuer, verifier and exchanges as far as YAML files go. But
right for the holder we have coordinator and service and such as the
pattern across all of the components. So I think personally either way
seems more reasonable than what we have now. But either breaking out into
the actual components which would be more files or consolidating into one.
I think I'd be okay with either option.

Manu Sporny: All right. good point. Ty, go ahead.

Kayode Ezike: Yeah, the point that I was going to make was a cautionary
note that kind of Eric alluded to a little bit in a way, which is that the
semantics of what seems to be the same endpoint for different components
might be different. For example, deleting credential with an ID is
different for a holder than it is for an issuer. And so if we just had one
definition of that which description would be used and that could become an
issue. That's just something to keep in mind one of them is deleting in the
wallet the other one is deleting from the set of credentials you've issued
in the past.

Kayode Ezike: So yeah, anyways, that's just one thing I wanted to make note

Manu Sporny: Yeah, that's a very good point.

Manu Sporny: Dave

Dave Longley: I will say though the counterpoint to that is if you just
think of the delete endpoint as an abstraction where you're deleting from
some storage that was previously populated somehow, they work the same way.
but I think one of the issues we run into here is how we decide to separate
the files. And if we have anything that's common, and we do in some cases,
then it becomes unclear where to put the common things. So I don't know how
much benefit we're getting. we're certainly not getting good benefit over
out of how they have currently been split up. And so what we might want to
do is consolidate and then see what a sane way to split it up would be.
00:15:00

Dave Longley: But I think they were split up too soon before and it's
caused more trouble. and so we need to figure out the right way in which to
split them up. If we are going to split them, but if we started with them
being consolidated, we wouldn't even have to worry about that. And maybe we
would discover that's a problem by having them all be together. But I mean,
the whole spec file is together and we work with that just fine. So maybe
there's not a whole lot of benefit to splitting it

Manu Sporny: Yeah, I'm right. I'm taking some notes here. the original
reason is that there were some implementers that again are not here anymore
that were insistent that having endpoints defined in a YAML file meant that
you had to implement the entire Yam

Dave Longley: I guess I should ask what do we hope to gain by having it be
split up other than us having to think about how we ought to split it up
and then make sure that keeps working. I don't know in this case that
there's a whole lot of maintenance benefit.

Manu Sporny: YAML file and they did not want to implement other YAML files
for the verifier or the other thing and so there was this assertion made
that I don't think is correct that when you have a YAML file that defines
what you as an issuer need to do and the normative statements around and
all that kind of stuff. I don't think the argument made any sense at the
time. It was just a compromise that we made. I don't think it's buying us
anything anymore. and if we wanted to split it out in the future, again,
putting it together doesn't hurt us from being able to do that. We could
use the component, a bit to share definitions between multiple YAML files.
So, if we did want to go back to what we have right now, we could do that.

Manu Sporny: But…

Manu Sporny: what I've also noticed is Sure. Yeah,…

Dave Longley: Can I make a quick suggestion that might solve all of this?

Dave Longley: My understanding is we could reference another AML file
without having to have those definitions at all. So is it possible for us
to have one big YAML file with all the stuff in it and then if we want to
have separate profiles or this is what you would need to do for a
conformant issuer you could have a YAML file for that just reference what's
in the main file. If we're able to set it up like that, then we can make as
many of those separate files as we wanted to.

Manu Sporny: we would have to rewrite all the AML to do that because the
way you do references is not the way we have it set up right now. So, it'd
be a pretty considerable rewrite of everything to restructure it…

Dave Longley: Okay.

Manu Sporny: because OAS sucks.

Manu Sporny: it was kind of slapped together over time and it's not very
modular when it comes to things like that. You have to write it in a way
that that's not always true but it's certainly anyway. So my concrete
suggestion is we just put everything together for now and then we can do
the thing that Dave that you're saying that we could do in the future or we
could reframe it in the way that we could plit it up in the way that Eric
was suggesting and I think Coyote your concern is valid. but I think Dave
kind of u mentioned how we could try and address it.

Manu Sporny: and of course if this stuff doesn't work out we can always try
to come back to what we have right now. so how about this next step here is
to try and put everything together. We'll merge all the YAML changes that
we have outstanding and we'll try to put everything together. I guess one
last question on that is anyone using the red do generated autogenerated
files that was another thing that people were like again previous
implementers said were absolutely required whereas I don't know I mean
they're nice to look at but I tend to look at the spec and not the red do
files and we can always generate redoc a more comprehensive

Manu Sporny: Red in the future. Go ahead, Coyote.

Kayode Ezike: So this is not an answer to that question. It's more so just
before we leave this issue. I think it is an instructive endpoint to talk
about though because I per my comment just above what you're writing like
that endpoint technically the format of it is not super specified and you
can kind of be anything and I think outside of it being a valid URL
obviously and having IV equals to one but the thing that I came to learn is
that it actually is something that's supposed to live on
00:20:00

Kayode Ezike: the coordinator technically because that's the origin of
trust that the user is inter interfacing with when they're interacting with
the coordinator and so it's basically those two points which is that one it
doesn't have to have the interaction ID format although that's the example
that we have in the examples whether or not we want to specify that's a
different discussion but the other thing is that it most appropriately
belongs in a coordinator

Kayode Ezike: because of the fact that that's what the wallet is is told is
the origin that they should trust given…

Kayode Ezike: what they're interfacing with on the web.

Manu Sporny: Plus one to that.

Manu Sporny: I'm not making the connection between how does that impact the
decision we're making.

Kayode Ezike: No. It doesn't impact the decision we're making. I guess it's
just a clarification because that question was technically part of the
question that was in the issue. Yeah.

Manu Sporny: I I got it. A plus one. Yeah, you were addressing the initial
question that was plus one to that.

Manu Sporny: So we discussed creating a categories by component. It's just
creating ML snippets. We decided to merge all the OAS files into a single
file. and see if it works.

Manu Sporny: In the future, we might split the files back. So the
specification should All right. So I'm gonna say this is ready for PR.

Manu Sporny: …

Manu Sporny: Eric, does that address your concern?

Eric Schuh: Yeah,…

Eric Schuh: I believe so.

Manu Sporny: Okay, sounds good. all right. And, do you want to We lose the
chat, so let's vocalize that.

Kayode Ezike: Yeah. I guess again directly answering the question again
what I was saying is that technically since for the definition of these
endpoints you have to put the actual format of the path and things like
that. I'm not sure that there's actually a way to capture the requirements
of the interaction in YAML that way. we may not even need to add a
definition at all and maybe just call it out in some way.

Kayode Ezike: But that's just

Manu Sporny: Yeah, we can always make normative statements in the
specification without having to have a OAS definition for it.

Manu Sporny: This I haven't thought deeply about this particular one.

Dave Longley: And I'm guessing on the queue and…

Manu Sporny: God.

Dave Longley: then I the other option there is to put it in the ammo, but
in the spec say this URL is treated as opaque so you can do whatever you
want. The YAML's there as an example. so there's multiple approaches to

Manu Sporny: Yep. we also say that you can put the endpoint wherever you
want to.
00:25:00

Manu Sporny: the leading bit can be whatever you want. So I think we have a
lot of latitude to do it either way and we'll just have to a pick one and
see if any implementers complain about it. Okay, that is ready for but
really should just be a direct restructuring. I can do this because know
hopefully. all right. Let's go to pull requests. we already talked about
525. Eric's going to put together that Google doc so that we can take a
look at that. I added it's not alternatives considered. I named it
something else. how do I name it?

Manu Sporny: So, we had an issue. Relationship to other specifications.
relationship. All right. So we had an issue where people were like what is
the difference between this and OID4 VP or ID4 VCI.

Manu Sporny: there is now a section called relationship to other
specifications in the spec as a PR and it basically talks about DC API and
ID for VCI and no ID4 VP and how this specification is different from that
the core thing being that the specification verifiable credential API for
life cycle management is fully focused on the entirety of life cycle
management whereas things like oid4 are just focused on delivery credential
delivery whereas the VCOM specification focuses on issuance verification
status modification

Manu Sporny: things like that and it is also agnostic to credential query
language and credential protocol. so that there's no other specification
out there that I think we know of that does all of those things. and it is
compatible with OID4 VCI ID4 VP. So, that's this PR. It's just raised. I
don't know if Do we need any conversation over it? Does anyone have any
strong feelings one way or another on the PR?

Manu Sporny: The other thing this does is as a part of the tag review which
it's not going to happen for months 6 months plus they have an alternatives
considered section and either you have to write that in a separate document
or you write it in your spec this is an experiment to see if they accept
this which they

Manu Sporny: I think they said that you can point to a section and this is
the alternatives considered and why we went with this one. So there's that.
we should probably follow the same format in all the other working groups
we're in dead working group that sort of thing. Okay so there's okay so
that PR 529. The next PR is an update to the website interaction protocol
issue 531. this is sorry PR 531.

Manu Sporny: It's to deal with issue 530 which is that when we picked the
name website protocol, it was a little awkward at the time and more
recently we think that invite request is probably a better thing because
what you do with this protocol is you tell somebody else to send you an
invite to a website

Manu Sporny: or just a URL. So, it's really an invite request. You're
saying, "I want you to post an invite this invite request URL." So, that's
the PR effectively does that.
00:30:00

Manu Sporny: That means that let's see this is Yeah. Sorry.

Eric Schuh: Sorry.

Eric Schuh: I meant to do that as a suggestion,…

Eric Schuh: but I think I might have accidentally did a commit. but yeah,
so this just gives two different examples of what the response would be or
what the submitted response to that invite might look like.

Manu Sporny: That's fine.

Manu Sporny: Yep. …

Manu Sporny: guess this one's Go ahead, Dave.

Dave Longley: I was going to recommend for the second one that instead of
putting interaction in there,…

Dave Longley: we put forms or something. I think it's good to have multiple
examples so that you can see that you can pretty much be taken anywhere.
and what I want to avoid is overusing the terminology interaction too much.
we talk about what an interaction URL is and how you use it to get
protocols to do something else and if we put the word interaction in too
many places it becomes really generic in the spec and kind of hard to
follow and so I think it's good to have multiple examples that show this is
a URL that's going to take the user somewhere and…

Dave Longley: generically they're going to interact but it would probably
be good to not use it in URL itself in the example

Manu Sporny: Plus one to that.

Manu Sporny: But this used to say website everywhere you see an orange
invite request used to say website. So, we'll continue to, work on that and
get it ed. anything on on the website to invite request change. All right.

Manu Sporny: If not, the next one had to do with an issue that Joe raised,
issue 528. And Joe wanted us to clarify why we don't provide endpoints for
doing configuration except for the create workflow configuration thing. I
noted that we already had a part of the specification where we talk about
that where we're like hey we don't the administrative interface let me
bring this up on the screen. the admin interface basically says that we
don't prescribe interfaces or means to configure things.

Manu Sporny: so I think we already kind of said it there, but I tried to
just rework the entire paragraph to make it a little more Rename the
section to said the administration component is I mean this is mostly the
previous text but we point out where we specify some configuration but we
say that we don't standardize many of the configuration things. So that's
meant to address Joe's issue that he raised. So issue 528 and then we've
got 532 to rework that any questions, concerns, comments on this particular
change. Probably just needs some editorial work.

Manu Sporny: All right. If not, we can move on. next one wasn't an issue,
but I noticed that we had not, defined our conformance classes yet. And I
think it was really difficult to do in the early days. I took a pass at it
to see how it would work out. And it's wasn't that terrible. it probably
needs quite a bit of adjustment. So right now we talk about
implementations. This is what we did in the VC data model and data
integrity and all those other specifications. We talked about
implementations. and so we've got a implementation. Same thing for verifier
holder service data service and workflow service.

Manu Sporny: And then I took a guess because we don't require you to
implement everything right I took a look at what the minimal thing that you
must implement to be a conforming issuer service and that is basically the
issue issue credential like endpoint and then we say you may do other
things in the issuing section if you want to you don't have to but that's
so that's the pattern and that seemed to work for most everything. The
holder service was a little dicey in that there were a number of things
where you're like you don't have to implement the whole thing but you
really should pay attention. let's see.
00:35:00

Manu Sporny: And then this is a may. So there's must and may statements
here. go ahead, Dave.

Dave Longley: Yeah, I didn't mean to interrupt in the middle of that. but I
was just going to say I looked over that PR and I pretty much agreed with
the choices made there with the exception of hold their service
implementation. I think it would be advantageous for us to say the minimal
that you must do is the exchange piece. I think there will probably be a
number of digital wallets that will just do presentation creation locally
maybe in a local app and not call out to HTTP to do it. but if you're un
unable to participate in any exchanges,…

Dave Longley: you don't get very far.

Manu Sporny: Got it.

Manu Sporny: So not this one. Yeah, that makes sense. I was why did I do it
this way? I think I was presuming that this was a wallet and that they
would end up doing But I get what you're saying. We don't need this last
one, right? Is what you're saying.

Dave Longley: Yeah, I don't think that's strictly a requirement.

Manu Sporny: And the other thing that I was on the fence about is the get
exchange protocols and participate. I don't know if we really get exchange
protocols. It feels like we do though.

Dave Longley: I didn't chase that down. I mean, if you're going to
implement like a digital wallet, you're going to need to be able to resolve
interaction if I'm not sure that that the right section. What you need to
be able to do is resolve an interaction URL and…

Dave Longley: then participate in an exchange based on the protocol epic. I
think that's the bare minimum.

Manu Sporny: Okay.

Manu Sporny: So, maybe we put a little more focus and thought into this
part of it. the other thing that I was struggling with was what was it?
Yeah, it's this like I didn't want to mandate that people had to implement
VPR did authentication or things like that. So I made all of that a may the
problem there of course is that it doesn't mandate any query language or
protocol data format which means that there's no minimum implementation
requirement.

Manu Sporny: So that's the other thing here is what do we say that a
minimal implementation needs to implement go ahead Dave Okay.

Dave Longley: So if you want to minimally implement participating in an
exchange,…

Dave Longley: you have to implement this protocol. We could say you'd have
to implement the VC API protocol. And by doing so, you would minimally have
to understand that protocol and the query language associated with it.
That's as far as we would, really need to take it. I think we might even
want a separate conformance class for that.

Manu Sporny: And is that I see what you're saying. Yeah. I'm trying to get
to what's the minimum viable, for each of these things.

Manu Sporny: And I don't know if M do oid4 folks are going to be cranky if
we pick we don't pick.

Dave Longley: Yeah, I think whole service itself even that as a conformance
class is problematic…

Manu Sporny: Although you can't. Yeah. Mhm.

Dave Longley: since maybe we want some kind of exchange participant
conformance class because getting exchange protocols and participating in
an exchange doesn't have to be driven by a service and it's not part of the
holder service. So it's already confusing. So maybe we need a exchange
conformance class or something like that. and then the holder service
implementation the minimum I guess would create a presentation you don't
something like
00:40:00

Manu Sporny: Mh Yep. the other thing I didn't Yeah. Plus one of that. this
is the server side of that.

Manu Sporny: But I think we need the other thing I was not sure of is do we
have a conforming client for every single one of these?

Manu Sporny: So, five more conformance classes for the clients that speak
to these. or do we just say Yeah.

Dave Longley: Yeah, that's a little of…

Dave Longley: what I'm getting at. But maybe we just only wanted to find
the exchange one. the rest are fairly straightforward.

Manu Sporny: And it's just kind of like does it I don't know what the
benefit in defining all of those classes would be. I mean, plus one for the
exchange, client, whatever.

Manu Sporny: the coordinators also didn't seem like something that I mean
the interaction URL I guess is something that the coordinator would need to
do so we can definitely do that would be

Dave Longley: Yeah, you would expect a coordinator to do that and then
potentially it would also be a client for these other services. So maybe
that it fits in there. I don't know.

Manu Sporny: what another 11 to 12 we'd have a total of 11 to 12
conformance classes but they would be very precise and then there's a big
question around is it useful or not anyway we can noodle on that in this
and we can make multiple passes at the conformance classes the good news is
that it was fairly easy to be very

Manu Sporny: specific about you must implement this endpoint you may
implement these other end points in the section that worked out really
nicely it kind of didn't work out nicely for holder service that's the only
one where it was a little more difficult to figure out what to do okay we
can iterate on that one as we go as well okay so those were the conformance
classes and then finally coyote you had in issue 523 which was clarify the
distinction of authority between backend and frontend coordinators. I
raised PR535 to address that with two new sections in the security
considerations section. The first one was to just say hey there are other
security considerations be aware this is part of a bigger ecosystem.

Manu Sporny: go and look at the verifiable credentials data model Go and
look at the, data integrity spec to just get more in your head about the
types of security and p security concerns you should be thinking of. And
then I added a section on best practices to point to the secure coding
practices checklist and the testing guide and basically say that even
deeply experienced software developers can make mistakes and using
checklists and vulnerability scanning software can catch errors. it's a
little too generic I think at this point.

Manu Sporny: it doesn't necessarily clarify the distinction between backend
and front end. Coyote, so if you've got any thoughts on what we could do
to, adjust this to address your concern would be much appreciated in the PR
if you provided any changes. Okay, I think that is it for all the PRs day
and I think we did also talk about ic your issue that you raised. and for
the rest of it we just need PRs to be raised for them. we are doing a good
job of reducing these issues by quite a bit.

Manu Sporny: real before I g get to you there is one thing Dave Longley or
Coyote one of you if we got a template example somewhere in the spec that
would address for the issues that we have open right now so I think we're
just waiting on a template example to be provided and we may need a, fairly
involved section on, what a template, could look like and how it works and
all that kind of stuff. but, all I need is for someone to provide that and
then I can get moving on those PRs. coyote up Europe.
00:45:00

Kayode Ezike: So, I recently reopened an issue. I know not the direction we
want to be moving in, so we had a PR created for it in the past and I
realized that we probably should open a new one to properly address it. So,
let me give a link to it. It's the 446 issue. Hold on. Yeah. So originally
the issue here was that variables is underspecified at the time. It was
like all the way messed up array. It was supposed to be an object. But we
resolved that we would just allow you to put anything there that's an
object.

Kayode Ezike: But then what I found is that I don't think that that is
sufficient if we want to enable interoperability and the ability to
implementations of I guess exchange flow services because from what I found
there's a need to use specific properties to be able to for example save
the results or credential data and things of that sort and unless the
coordinator knows what the workflow service used for certain properties, it
wouldn't really be able to be interoperable with any workflow service. And
so that's the general note that I was making. This last comment that I made
was that I think there's a need for us to at least define maybe one
property in there that would address that concern.

Manu Sporny: All right. Yes. Thank you for noting that. Dave, you're up.

Dave Longley: So I got on the queue for something else but just briefly I
think it might be of value to talk about storing results from steps in the
variables that might help address coyote's concern. I do think we have to
be a little bit careful with I mean even if all your results were going
into that space as a coordinator you still need to know what workflow
you're working against what the steps were and that sort of thing to read
the results out of specific steps.

Dave Longley: but I think it's certainly a value to at least reserve
results and then maybe also to talk about how implementations can maybe
must put the results from steps in there. that but I got on the queue to
say we need to remember figure out what we're doing with the remaining
issues on the VP request spec whether we're transferring them to VCOM or
whatever we're doing.

Manu Sporny: We should probably migrate them. I'm just going to migrate
them.

Manu Sporny: Does anyone object to that?

Ted Thibodeau Jr: related to that.

Ted Thibodeau Jr: I just threw into the chat. the old URI for that issue
446 does not redirect the new repo BC API to VCOM.

Manu Sporny: which but yeah it won't do that those get broken all the old
links to the spec will redirect nothing else will unfortunately we can have
one or…

Ted Thibodeau Jr: That's weird.

Manu Sporny: the other we can't have both we can either break every
previous link to the specification that was put in all the issues. that's
one. Option two is break previous links to issues that were made in
comments. and I don't know which one's better or worse.

Manu Sporny: Historically we have chosen to break the issue links and…

Manu Sporny: not break the spec links because we want people that point to
the specification to be able for it to resolve to the new specification.
That makes sense.
00:50:00

Ted Thibodeau Jr: Yeah, it does.

Ted Thibodeau Jr: It's just surprising.

Manu Sporny: Yeah. GitHub does not have that level of configurability for
us to Yeah.

Ted Thibodeau Jr: The first time I've hit this, lots of other repos have
been changed names and I don't think change donors, but definitely change
names and everything automatically by…

Manu Sporny: the reason for that is they break their old links to the old
specifications. Every link that pointed to a specification everywhere just
breaks.

Ted Thibodeau Jr: what you mean the GitHub IO,…

Manu Sporny: Yes, correct.

Manu Sporny: all of those links would just break across the internet.

Ted Thibodeau Jr: right? Okay.

Manu Sporny: Yeah,…

Ted Thibodeau Jr: All right.

Manu Sporny: that's free lunch there. go ahead, Okay,…

Eric Schuh: Yes.

Eric Schuh: So, I got the Google doc put together. Just wanted to share
that. I'll put the link in chat. It's in the com the last comment on the PR
525 as well.

Manu Sporny: I am going to have to remember to do this later because it
doesn't look like mass reassign issues. Might need to do it one by one,…

Manu Sporny: which makes me sad, so they've only please help me remember.
Okay. let me pull up

Ted Thibodeau Jr: You might be able to use when you're looking at an issue
without a text box being selected.

Ted Thibodeau Jr: So just click on the background and then hit your period
key. that other interface let you do all kinds of things that you can't in
the more friendly web space.

Manu Sporny: One second.

Manu Sporny: Hold Let me see if I can I have to select that. you're saying
dot.

Ted Thibodeau Jr: You'd have to reperform that search. Do you know I'm
referencing?

Manu Sporny: I No, I mean I'm hitting dot, but it's not giving me a …

Ted Thibodeau Jr: Yeah, it's basically their web interface that fakes being
in Visual Studio.

Manu Sporny: I don't know where that is.

Manu Sporny: I mean, I know if I go here, I think it probably just doesn't
let you mass transfer. I'll come back to it. I'll just do it manually if I
need to. So, that's in this issue. And here we go. Great. Thank you, we
should all take some time to go through this and think about where these
things should go or what it should be changed to.

Manu Sporny: I will try to do a pass this coming weekend on this. Okay,
thanks for putting that together, I think that is it for our call today. Is
there anything else we need to pay attention to before next week's call?
And then reminder that there is a verifiable credential working group call
this week tomorrow at sometime 10:0 11:00 a.m. Eastern where we'll be
discussing how the prioritization and voting and everything's going. okay,
that's it for the call today. Thank you everyone very much. I appreciate
all the engagement.

Manu Sporny: let's get some more thoughts into those PRs so we can get them
processed by this weekend and then hopefully we'll see a new batch. I will
try to migrate all the verifiable presentation request issues Coyote, don't
worry about raising new issues. We'll raise as many issues as we have to
until we run out of time. So, it's the way it goes. all right. Thanks
everyone. have a great week. see you next week.
Meeting ended after 00:54:43 👋

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