[MINUTES] CCG VCALM 2026-02-24

W3C CCG VCALM Meeting Summary - 2026/02/24

*Meeting Date:* 2026/02/24 *Meeting Time:* 14:57 EST *Attendees:* Benjamin
Young, Dave Longley, Dmitri Zagidulin, Eric Schuh, James Easter, Joe
Andrieu, John's Notetaker, Jori Lehtinen, Kayode Ezike, Manu Sporny, Nate
Otto, Parth Bhatt, Patrick St-Louis, Ted Thibodeau Jr
Topics Covered:

   - *Introductions:* Jori Lehtinen introduced himself as an independent
   developer from Finland, new to verifiable credentials and attending his
   first call.
   - *Community Updates:*
      - *VC Working Group Recharter:* Manu Sporny reported positive
      progress on the VC Working Group recharter, moving the VC API towards the
      official global standards track. He encouraged W3C members to vote.
      - *Open Badges Interoperability Profiles:* Nate Otto presented draft
      interoperability profiles for moving open badges, developed in
      collaboration with the Strata Education Foundation. These profiles
      incorporate the VCOM API and provide step-by-step guides for
developers. A
      more detailed presentation is tentatively scheduled for the next meeting.
   - *Spec Rendering Issue:* Patrick St-Louis addressed an issue where the
   VCOM spec was not rendering correctly due to an out-of-sync respec OAS
   component. Eric Schuh explained the cause and confirmed a process is being
   implemented to prevent future occurrences. Manu Sporny elaborated on the
   respec tool and the need for better release processes for its plugins,
   suggesting automation via GitHub actions. An issue will be created to track
   this.
   - *PR Reviews:*
      - *PR #595 (Query by Example Pseudocode):* This PR, providing
      pseudocode for handling "query by example" presentation requests, remains
      open. Discussions touched on potential link staleness and the utility of
      converting queries to a map of JSON pointers for transformation.
      - *PR #596 (Accepted Issuers/Crypto Suites):* This PR focuses on
      refining the definition of accepted issuers and accepted crypto suites.
      Consensus favored the "accepted" prefix for consistency with Verifiable
      Presentation Requests. Discussions explored the relationship between
      "accepted" and "recognized" issuers, the potential for "accepted issuers"
      to be an object referencing external trust registries, and the complexity
      of handling large lists. Issue #598 was created to track further
discussion
      on expanding the accepted issuers list. The naming of accepted crypto
      suite was also discussed to ensure specificity for presentation
      requests.
      - *PR #597 (Delete Presentations ID Link):* This PR adds a link for
      the "delete presentations ID" endpoint to the component table. It was
      approved and merged.
   - *New Issue Discussion:*
      - *Issue #602 (Normative Processing Algorithms for Workflows):* Dave
      Longley presented this issue, proposing the inclusion of processing
      algorithms for workflows to aid implementers. The discussion centered on
      whether these algorithms should be normative, the challenges of testing
      workflows, and the potential for a client-driven approach to
processing and
      interoperability testing.

Key Points:

   - The VC API's progression towards the W3C standards track is
   progressing well.
   - The VCOM API is being actively integrated into interoperability
   profiles, such as those for open badges.
   - Maintaining the integrity and correct rendering of the W3C
   specification is crucial, and processes are being improved to prevent
   rendering issues.
   - The VCOM specification is evolving to handle more complex scenarios,
   including referencing external trust registries for accepted issuers.
   - The inclusion of normative processing algorithms for workflows is
   considered valuable for implementers, with ongoing discussion on the best
   approach for testing and defining conformance.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-02-24.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-02-24.mp4
*CCG VCALM - 2026/02/24 14:57 EST - Transcript* *Attendees*

Benjamin Young, Dave Longley, Dmitri Zagidulin, Eric Schuh, James Easter,
Joe Andrieu, John's Notetaker, Jori Lehtinen, Kayode Ezike, Manu Sporny,
Nate Otto, Parth Bhatt, Patrick St-Louis, Ted Thibodeau Jr
*Transcript*

Patrick St-Louis: Hey part,…

Parth Bhatt: Hey, Patrick.

Patrick St-Louis: how you doing today?

Parth Bhatt: It's kind of good weather today.

Patrick St-Louis: Yeah. Where are you? I feel I asked you many times, but
where do you live?

Parth Bhatt: San Francisco.

Patrick St-Louis: Very nice. It's close to Mountain View, right? Yeah.

Parth Bhatt: Yes. a half an hour drive.

Patrick St-Louis: I went a couple of times to the IW event.

Parth Bhatt: Mhm. Yep. Yeah.

Patrick St-Louis: Yeah, I went a few years ago. I went two or three times.
And every single time I'm I'm going to go visit San Francisco And I only go
for a couple hours before my flight. And I'm like, next time I should, plan
a few more days. because it's very nice. I remember the thing that they
have the pier on the side there and…

Parth Bhatt: Mhm. P39. Yep. Yep.

Patrick St-Louis: yeah and they have these cups of fruits that you can buy
they have these stands and they sell you fruits in a cup and yeah that's a
great memory I have there.

Parth Bhatt: That's good.

Patrick St-Louis: Hey, welcome.

Jori Lehtinen: Hey, thanks.

Patrick St-Louis: This is the first time you're on this call or…

Jori Lehtinen: Yes, it's my first time on this call.

Patrick St-Louis: Okay. …

Jori Lehtinen: There was just another call a couple hours ago and that was
my first call overall overall ever. So, yeah.

Patrick St-Louis: exciting. we usually leave when everyone comes,…

Patrick St-Louis: we usually leave some time for people to introduce you
don't have to, but if you want to, you'll have the opportunity to introduce
yourself to the group where usually around 10 people on this call.

Jori Lehtinen: Yeah, I can introduce myself a bit.

Patrick St-Louis: Yeah, we'll just wait till the people come in there and…

Patrick St-Louis: usually I wait two three minutes for people to come in.
so you're new with verifiable credentials and this kind of stuff or

Jori Lehtinen: Yep. …

Jori Lehtinen: I've been in the community group for a few months at this
point and lately in the last month I guess I have been really diving deep
into the verifiable credentials stuff.

Patrick St-Louis: Yeah. Hey, ic. Welcome.

Patrick St-Louis: Just going to wait one more minute and then we'll get
started.

Patrick St-Louis: Okay, let's get started and people will keep joining in
the next couple minutes and they'll be able to Welcome everyone to the WTC
Credential Community Group VCOM meeting. today is the 24th of February
2026. this is a W3C credential committee group meeting. So all W3C policies
are into effect. The call will be transcribed and shared the publicly over
mailing list. So just be aware that any contributions you make will be
publicly available. so the goal of this call is really to incubate the
verifiable credential API.
00:05:00

Patrick St-Louis: this is an item that's been working a long time. The goal
is to have some kind of standard API definition for managing credentials
through their life cycle on all of the three parties including issuers,
verifiers, and holders. so today we're going to just do some quick
introduction community update. There's one topic I want to talk about. So
we had a event. There was a little error in the spec rendering. So maybe we
can just touch on that, see what happened and how we could try to avoid
this in the future. I believe it's been solved. If it's not been solved,
we'll be looking at that during the call. We're going to do R reviews and
issue assignments. so let's start with introduction. So if anyone's new on
the call or would like to reintroduce themselves, please just raise your
hand and take the microphone now. I'll give a couple minutes. Yeah.

Patrick St-Louis: Go ahead, Dory.

Jori Lehtinen: Yeah. …

Jori Lehtinen: my name is I'm a independent Dell developer from Finland and
I'm looking to implement a lot of the standards being specified by the V3C.
So, I'm mainly here to learn and give my input where I see it can
contribute to the community.

Jori Lehtinen: Thank you.

Patrick St-Louis: Thank you very much Jory for the introduction.

Patrick St-Louis: Welcome to the group. yeah we discuss a lot of very
interesting stuff here. it is the verifiable credential API but this touchs
many other aspects of verifiable credentials. So yeah depending on the call
we usually touch on specific topics here and there from anything from
presentation requests to status updates and workflows and So yeah I think
it's a great call to be in. is there anyone else that would like to
introduce themselves or do reintroductions?

Patrick St-Louis: Very good. is there any community updates that anyone
would like to share? Yes, Manu.

Manu Sporny: Just a couple the verifiable credential working group
recharter is closes at the end of this week. So this is the vote for this
thing that we're working on VC API to be pulled into the official global
standards track. we have very good responses to the charter. Looks like
it's going to go through. No formal objections yet. if you know of a W3C
member company that has not voted yet, please push them to vote. This is
the last week that they can do it. and then, at the beginning of March,
we'll see, what the final vote tally is, but it's looking really good,
right now. That's it.

Patrick St-Louis: That's great not really news because it was a long time
coming, but I'm happy to hear that things are looking good and we are still
on trajectory. any other community updates that people would like to share?
Yes. Nate.

Nate Otto: Last week, as part of a collaboration with the Strata Education
Foundation, we released a draft version of a few interoperability profiles
for, moving open badges between issuers, holder systems, and verifiers, and
we mentioned the VCOM API in one of those. Again, these are draft
interoperability profiles. but it would be great to have impleers of VCOM
take a look at them. you can go to learningmobility collabororg and select
the digital credentiing guidebook section and there's one of the guide
books there has the VCOM profile in it. I've already gotten a couple good
points of feedback back. The idea here is to be if you click the one on the
right, that one. Yep. you'll get to it.
00:10:00

Nate Otto: The idea is to have very step-by-step guides for developers who
are trying to implement open badges so that they can be assured that
they're making a lot of the same technical choices as others in the
ecosystem. And so we've put together one of the profiles using VCOM.

Nate Otto: And it gives you this little step-by-step guide of if you're
issuing credentials, here's what you do. You interaction L first, then
participation endpoint, then accepted did authentication, etc. So contact
me if you've got any questions or there's a GitHub repository that you can
open issues

Patrick St-Louis: That's super interesting.

Patrick St-Louis: I like to see this. do you mind if I ask a question? so
when you set up these entropy profile is this based on any current
implementation or this is just really some brain work to lay the ground for
an implementation to come in and implement this.

Nate Otto: the VCOM profile is very close to some real existing
implementations including those used by the digital credentials consortium
led by MIT. They've got some open source software that I've been
contributing to and at least in the draft the version that I'm working on
that I forked. we've got VCOM support that does all this. There's one tiny
gap between this and what their wallet supports which is in the interaction
URLs.

Patrick St-Louis: Very nice.

Nate Otto: As that approach is really just beginning to gel. So if their
wallet starts supporting interaction protocol URLs, then this is pretty
much representative of what you would need to do in order to get open badge
credentials in and out of the DCC's learner credential wallet.

Patrick St-Louis: Manual

Manu Sporny: I'm wondering if we should is it worth Nate spending a call
going through this? it feels very relevant to the work that we're doing
here. thoughts.

Nate Otto: I would be happy to coord presenting it in a little bit more
detail.

Patrick St-Louis: Yeah, I think this sounds great. Is next week a good
time? Can we put on the agenda next week a tentative for a sort of
presentation on this?

Nate Otto: Yes, that works for

Patrick St-Louis: Okay, let's do it tentatively, I'll just put it as a
agenda suggestion and if it's not ready, we'll just do regular call. So
it's a very low pressure but 100% this is very closely related to what
we're doing and it's a good way to see how the work we're doing can make an
appearance in other work, right?

Patrick St-Louis: How can people use that as a sort of foundation or
scaffolding to build? because as you get something like this, you move
closer and closer to an actual use case as what we're doing is trying to be
very agnostic. And I think it's nice to see what the work we're doing can
enable.

Patrick St-Louis: Nate

Nate Otto: Yep.

Nate Otto: So, I'll look forward to doing that next week. And then this
work leads into the next phase which will be to build some developer tools
for release at the badge summit in Boulder, Colorado this uly. where we
will prov turn these interoperability profiles into interactive checklists
that will test a live system for whether it is doing all the things that
the profile says it should do. So, as you're developing a tool, you suppose
you're building an issuer system, the testing tool will act as the holder
wallet, and you'll work through the checklist top to bottom until you get
an error and then fix that error and then try again and until you get all
the way through all of the interoperability profiles and workflows that
you're trying to implement. So, I'm looking forward to diving into that
work as

Patrick St-Louis: super exciting. Love it. Is that it? Can we Okay. anyone
else has any community updates?

Manu Sporny: On the last thing, Nate, we're interested as the No,…

Patrick St-Louis: Sorry. Yeah. Awesome.

Manu Sporny: it's totally fine. Nate, we're interested in our organization
working our software through that checklist if it would be useful to you.
That's it.

Nate Otto: Great. Thanks.

Patrick St-Louis: Any other community updates before we get into or any
other topics people would like to discuss during the call?
00:15:00

Patrick St-Louis: so let's take a quick moment. I just wanted so I'm the
one who proposed this. So in the last call we merged I think three or four
PRs and during the call there were some rebasing and then we merged some
things. someone pointed out over the weekend the spec was available. I
think it was missing the navigation menu, table of content and it just
wasn't rendering properly. so I just wanted maybe us to take a second just
to acknowledge this on the call here. maybe try to see if we found the root
cause of what happened and discuss if there's some things that we could try
to put in place to try as much as possible to avoid these kind of issues
being there.

Patrick St-Louis: I have a few suggestions of things we could do myself,…

Patrick St-Louis: but I'd be happy to hear from other people. yes, Eric

Eric Schuh: Yeah,…

Eric Schuh: I just wanted to speak to this a little bit because I believe
this was mostly entirely due to the respspec OAS getting out of sync with
the version that was being called in the repo. so I believe this was
because we pushed the merge for the component table updates and I had moved
some of the calls from post-processing to pre-processing and I had
forgotten. so Monu has provided me with instructions for how to the proper
process for updating that respec OAS in the future.

Eric Schuh: And I'll be adding those instructions to the respect OAS readme
on that repo. so anyone else that comes through in the future hopefully
won't cause this type of out of sync problem. so yeah, just wanted to speak
to that and…

Eric Schuh: I believe that that is what was the root cause and we have a
process in place that should fix it for the future.

Patrick St-Louis: Okay, thank you for that…

Patrick St-Louis: because it's true that one of the PR had a unusual
dependency on a update to the spec. I remember that very clearly. We kind
of held up for a couple of calls. So, that's just a pattern different than
the types of PR we do usually. thank you for highlighting that menu.

Manu Sporny: Yeah, plus and I mean this was not a big deal, this happens
from time to time. I do think it's good for us to kind of talk about what
better would look like. the current so we use this tool called respspec. in
here. Let me go ahead and grab the screen real quick.

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: So we let me respspec so we use this tool called respspec to
do all of our spec editing and it's a super useful tool and it has plugins
and one of the plugins that we're using for the VCOM spec is something
called respspec OAS. So OAS standing for the open API specification. It
will read in and this is experimental like we are the first group that's
doing this at W3C as far as I know. and so we get to work through the pain
of trying to actually make all of this stuff work. So, respspec OAS is a
plugin that goes into respec and it will read our API YAML file and then it
will inject portions of that YAML file rendered as HTML into the
specification. Right?

Manu Sporny: So let me see so when we look at the live rendered spec
respect is running and processing a bunch of stuff to generate the table of
contents and all the markup and the cross links and all that kind of stuff.
And when we look at something like issue credential all of this is respspec
OAS generated. So 80% of our spec is autogenerated from the OAS file I
think. right so this is all autogenerated. which is good it's a helpful
thing. It's helped us write the spec to the point that it is. So what's the
problem? When we add a new feature to respspec OAS we have to go through a
release process for respspec OAS before we put it in the spec.

Manu Sporny: and it's a manual process and it sucks it's not a good process
right you have to check out this repo you have to do an npm build you have
to branch you have to add the distribution file you have to tag that and
then you have to destroy the branch and that is the thing that creates a
new release and as you can see we have only done five releases the first
release took us four years and it's taken us 5 years to get to version 10,
right? We need to get better about how we release this stuff. it is
possible for us to use GitHub actions to automate the tagging and release
process. We just haven't done that because we haven't had anyone have the
spare time to do that.
00:20:00

Manu Sporny: So I think we can use GitHub releases in the build process and
automate all of this stuff so that neither Eric nor I need to go and do
manual releases from now on. it's rare that we need to add a new feature or
we rework stuff but we do and when we do things like this can happen. So I
think it would be nice if anybody has any haha spare time to figure out a
way to get any all respec plugins because we have quite a few re there's
respect-vc there's as if someone can figure out the best practice way to do
release builds for this kind of tool I think that would be helpful if people

Manu Sporny: can't get around to it, that's fine. but it would kind of help
us, not fall into this mode. and honestly, we don't really fall into this
mode, but once a year, maybe. So, it's not a huge pain point right now.
I'll stop there.

Patrick St-Louis: Okay. that makes sense. So I think it's mostly about the
term git ops come to mind right having some kind of operational deployment
with it seems like this is mostly about specifically the respect plugins
that they can be updated without too much headache. should we have an issue
for that on respec? Is there an issue to track this?

Manu Sporny: It should probably be on the respect oas repo.

Patrick St-Louis: Yeah. But it sounds like this is also for not only OAS…

Manu Sporny: We do not have an issue. I will raise one right now. So
they're each in their own repository and…

Patrick St-Louis: but the other respect plugins.

Manu Sporny: maybe…

Patrick St-Louis: Okay.

Manu Sporny: what we should do is figure out the right way to do it in one
of the repositories and…

Manu Sporny: then basically copy and paste the approach in the other repo.

Patrick St-Louis: Yeah. Yeah.

Patrick St-Louis: Ideally, it'd be like one sizefits-all approach like
consistent plugin methodology.

Manu Sporny:

Manu Sporny: Yeah. Yep. I don't remember…

Patrick St-Louis: Any reason why these plugins are in a different
repository and we couldn't have respect plugins and then have them there?
Not much.

Manu Sporny: how respect does their plugins. it is all plug-in based.

Patrick St-Louis: Okay.

Manu Sporny: So even respspec the core of it has its own set of plugins.
it's really welldesigned. it's something for someone to take a look at.
Marcos Casares from Apple is the main person that works on respec with,
other people supporting

Patrick St-Louis: I didn't know That's a interesting tidbit of information.
okay.

Patrick St-Louis: So, my question was there anything we could have done,
while the PR was open to detect this? I know there's the preview feature. I
did not check the preview on Engle's every single PR. was there something
we think on the call, a little extra check we could have done to prevent
this?

Manu Sporny: No, you just kind of have to know.

Patrick St-Louis: Manu, no. Okay. Okay.

Manu Sporny: It's tribal knowledge. You just kind of have to know how these
things fit together. So unfortunately, I don't think there's anything

Patrick St-Louis: I think given the fact that PR was dependent on a
respspec update, right?

Patrick St-Louis: this creates a unusual combination. I think it's okay if
we just keep in mind that if this happens again in the future that we need
to update the respect to do a sort of double check and due diligence and
until then I don't think we need to consider this a problem. very good.
Okay. So let's get in the best part of the call the PR reviews. So, we will
go in incremental order from the old SPR to the new one. this one again I
didn't have time to get back to it. So, this will stay in a PR state. There
were a few comments. we can still go over it maybe just to refresh our
brains over what this was about.
00:25:00

Patrick St-Louis: So this was really about providing pseudo code and the
spec to say how could someone take a query by example. So we had defined a
way in query by example to represent selective disclosure fields we want to
be selectively disclosed by and the goal of this was to provide an example
of how a holder software could take this query by example presentation
request and transformed it into JSON pointers that can then be used by the
proof and the crypto suite to access which field they want to reveal.

Patrick St-Louis: so this is a bit unusual in what we do in the spec I
don't think we currently really have pseudo code but we figured this would
be a good thing to have so I had started there were some comments and then
I didn't have time to get back to it but it's been a while so I'll try to
see if I have time to do this. I think most of the comment were about how
it looks in the spec, how it gets rendered with comments and whatnot. So I
still need to just kind of play around with it. not much today. Yes, Dave.

Dave Longley: Yeah, I just wanted to mention there's some link in there to
open source software library.

Dave Longley: I don't remember if that link might have gotten a little out
of date at some point or at least there was a link in one of these issues
around that. yeah,…

Patrick St-Louis: the ide.

Dave Longley: theres that link will stay up to date. I wanted to comment
that in that library one of the approaches that we found that was useful
with different query languages was to convert from each of the query
languages sort of this is similar to the abstract data model concept in the
dspec.

Patrick St-Louis: So you

Dave Longley: It's convert from one of the query languages into a map of
groups of JSON pointers and you can take one of the query languages and
convert to that and then you can convert back from that to a different
query language. So it allows for that sort of transformation and that
worked pretty well between query by example and DALE and presentation
exchange not perfectly…

Patrick St-Louis: mean so it's sort of a flattening of the query.

Dave Longley:

Dave Longley: but pretty well. you could think of it like that…

Patrick St-Louis: Is that what you mean by converting to data pointers? You
just flatten the query and…

Dave Longley: because they're a way to express a pointer into a nested
object and the pointer itself the pointers are all sort of flattened out
but the pointers contain the information into the nesting if that's what
you mean. Yes. So it might lend itself well in that section for and…

Patrick St-Louis: Interesting. Okay. I'll keep that in mind. yep.

Dave Longley: here's how you can translate between queries. you take any
one of these queries we'll have at least two examples in our spec which
will be dack and query by example. You can convert that into this map of
JSON pointers and then you can go back the other direction with mostly
being lossy.

Dave Longley: There are some edge cases. Yep.

Patrick St-Louis: Yeah, you still need some code to understand it and…

Patrick St-Louis: be able to know what does it mean in this other language.
that's an interesting approach. I did not think about it. So let's go into
the other PR. so this one we did have a look at the last call. I forgot
where we need to take into account. So I think there were some change that
Dave mentioned accepted issuers was an array of object or strings.

Patrick St-Louis: we made this change and the same thing for crypto suites.
Call this I don't remember this being here last time, but yeah. So, man.

Manu Sporny: Yeah, I didn't see the comments but I do now. So, I'll update
the PR to align. I did have a question around is it accepted issuer or is
it recognized issuer? the reason I'm asking is we have another call the
verifiable issuers verifiers call and we have switched to language that
says recognized instead of accepted or whatever. Do we want to use that
same language here? Do we want to use different language? I
00:30:00

Dave Longley: I don't go ahead.

Patrick St-Louis: So my quick response was that we settled that it's going
to be accepted XYZ and…

Patrick St-Louis: keep this accepted prefix consistent. that's what I
understood was the last made decision around this here. now that being
said, maybe Dave have something else to say.

Dave Longley: I was just going to say I don't know that it's a perfect
mapping to a verifiable presentation request. So, as a party that could
send a V VPR somewhere, I imagine you might have recognized issuers that
you would take and put into if you had a list of a bunch of recognized
issuers, you might only accept some of them for a given use case.

Dave Longley: So it's not always necessarily direct translation and it
might get confusing if we use that terminology. The accepted terminology is
already in a VPR. So I don't know if it benefits us to deviate from that
and put recognized issuers here because it would be different from accepted
crypto suites and accepted envelopes. So I don't know if we're gaining a
lot by doing that. and there might be different mild semantic differences
and…

Dave Longley: different layers at play, but the queue is filling up.

Patrick St-Louis: Thank Joe.

Joe Andrieu: Yeah,…

Joe Andrieu: I'm more a fan of the accepted pattern. I would go with
acceptable except that I don't think we want accepted and acceptable in to
be meaning similar things. So that would be problematic. but I like
accepted or acceptable because we're saying for this request, this is
what's acceptable. We may recognize all sorts of other issuers for all
sorts of things, but for this presentation, what is acceptable is, I think,
the semantics that we're trying to capture.

Patrick St-Louis: Yeah, I would tend to agree with that because let's not
forget, we had trusted issuers at first and then we moved it to accepted
and we said, let's just have all these different accepted fields that
represent some

Patrick St-Louis: kind of restrictions you're putting on something about
the presentation, or the credential here. You put a restriction on your
issuers, you put a restriction on the crypto suites, you put a restriction
on envelope, and there might be other things we might want to put
restrictions on. And having this clear pattern makes it easier to
understand, I think, and easier to explain. And it's just kind of self
evident, when I see accepted issuers and accepted crystal suites, I can
sort of derive from this that these are used for the same kind of purpose.
if we start to have all these different terms that are used the same way
but the terms are different. I think it would just make this a little bit
complicated for nothing.

Patrick St-Louis: one question I would have is would we consider accepted
issuers a subset of rec of a recognized issuers list or is there just no
relation at all? I think that's kind of a discussion we could have what's
would be the relationship between trusted issuers and recognized issuers if
there are any. because as Dave or even Joe mentioned, there's not really a
semantic alignment between both. this for me is to the point technical list
here's the accepted issuers that you can use to query your credentials in
your wallet, right?

Patrick St-Louis: It doesn't mean much other than these are the issuers
that as a verifier I want to restrict you on. It doesn't tell the holder
anything. It doesn't say these are issuers I trust. it's just a list of
right. so that's what I'll have to say. menu.

Manu Sporny: Yeah, plus one to that. Okay. I'm hearing consensus. Yeah, I'm
happy with, keeping it and what I gather the reasoning is there's this
other group that's working on verifiable issuers verifiers that publishes
lists of recognized entities that can be used to bootstrap the ecosystem
for a verifier for example so it understands kind of what the set that it
might trust are but this thing we're looking at right now is for a very
specific transaction and in those
00:35:00

Manu Sporny: transactions, you may want to use a subset of that recognized
list. And this really is about what you will expect accept for the given
workflow, instance, right? So, you might combine lists, all that kind of
stuff. So, accepted is fine for all of these things. I'll keep it at and
Patrick if we had to explain which I think that we would explain that as
the relationship here is that the set of accepted issuers might be a subset
of recognized entities but this is for a very specific exchange. That's it.

Patrick St-Louis: Dave.

Dave Longley: So to speak to that a little bit more…

Dave Longley: where the recognized issuers list or credential might come
into play here is as one of these objects of accepted issuers. I would
accept anyone that is recognized by this recognized entity credential. So
we want these fields to be a string of identifiers for issuers or an object
that could describe properties about an issuer that you'd be willing to
accept. And that's where you could put this here's a link to a recognize
entity credential that you could dreference and I'll accept anybody from
that's on there.

Dave Longley: according to whatever that credential says. And so that
allows you to do these more powerful things where you might be saying, I'll
accept this credential. you might not have one from a specific issuer that
I can list or…

Dave Longley: that I know about, but you might be able to present, your
degree from this accredited university and I accept things from this
accredited university, etc.

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

Patrick St-Louis: Because it's true that it's a list of object and right
now we only have the ID but we maybe accepted issuers could be an ID and a
link to some kind of registry. I think what you just explained a lot of
this was a bit ambiguous would need to be defined if we really want to put
this into I see the idea that you could say either from that issuer or
someone that's been approved by another but I think that that idea would
need to be fleshed out a little bit more.

Patrick St-Louis: what I really wanted to say is I don't even know if we
need a relationship between this and recognize issuers I don't see a reason
why a verifier software wouldn't just plot their recognized issuer list in
there right if they feel like that's what they want to trust and the
recognized list of issuers that's just what they want to use as accepted
issuers up to them I don't think it needs to be a subset I don't think we
need to even explain relationship. Nate

Nate Otto: I want to speak up in favor of allowing pointing to some kind of
registry list that is external to this thing. especially with the
educational ecosystem most of the use cases are really about I want to see
what's in your credential and I want it to come from an authentic
organization but I'm not necessarily saying that I'm going to only accept
your bachelor's degree from one of these 18 colleges that happen to be in
the consortium in my state. It's more like I want to accept a bachelor's
degree from any accredited institution. And so it would be more likely that
I could point to a very large list that might change after the credential
the configuration for this exchange has been set rather than pointing to
some static list and really exploding that list locally.

Nate Otto: I'm also potentially a little bit concerned if we only have
strings as the pointers because it might be useful to be able to understand
whether the string identifier is an identifier of an issuer individually or
if it's a list of a certain type or the registered resource of a certain
type. I'm not sure if what people were talking about was to leave this as a
list of strings or if we were allowing a list of kind of like objects that
had types as
00:40:00

Patrick St-Louis: Dave.

Dave Longley: Yeah. Yeah. The goal is to make it strings if they are. And
if you use a string, it must be the identifier of the issuer or an object.
If it's an object, it's properties about that object. And I put this in the
chat, but wanted to voice it so it goes in the minutes. We should have an
example eventually that shows you can have accepted issuers with a list
that's populated both with perhaps dids and then maybe some objects where
the object could say as we were just discussing on the verifiable issuers
and verifiers They could have the recognized in property and then you could
put your recognition resource there whether that be a verifiable credential
for recognized entities this Etsy list of lists whatever else you want to
put into that failed.

Patrick St-Louis: so that's interesting. I would have an alternate to that
where we leave the ID as the URL and we instead have a type and it could be
as simple as an object has a type of re recognize issuer and the ID is the
URL to that list. if there's no type right we consider the ID as it did of
an issuer and this way we can use the ID to represent a URL and have types
that define what kind of trust registryish list you're going to find at
that URL obviously this is outside of this PR but that's would be another
way I'm not against recognized in but I think

Patrick St-Louis: we made ID required. so yeah I would propose this instead
of having recognized in you would have an object with a type of recognize
issuers and then the ID value is a URL towards that list I do.

Manu Sporny: Yeah. we could do that. I'm hearing that we do want to support
this use case. I have some slight system complexity concerns around it.
meaning can't the software just evaluate the list at some point and this
just be explicit in the accepted issuers thing that can dynamically change
from transaction to transaction. what do folks think about that? I mean I
can go either way on this. I don't have a strong opinion one way or…

Manu Sporny: the other. or do we have system complexity concerns if we
start putting list processing into this?

Patrick St-Louis: So your suggestion is that the verifier actually takes
the responsibility to parse that list,…

Patrick St-Louis: extract the ds and put them just as the accepted issuers.
Is that kind of the approach?

Manu Sporny: That's Yeah, that's right. And it does it dynamically, but
it's explicit in the request. I'm wondering Yeah. Yeah. I agree that the
list could have, 100,000 issuers in it. Yeah. I mean,…

Patrick St-Louis: right.

Manu Sporny: so when we hit scales like that, that's when it becomes
unwieldy. but maybe that is not the primary use case. I don't know. I Nate
makes a good point about when the list gets so big, but I'm just wondering
about system complexity concerns. That's it.

Nate Otto: Just to raise the point that especially for educational use
cases, the verifier does not often know specifically what issuer is coming
from and it's really sort of like any known issuer to any of the registries
that I subscribe to. And so exploding those out into a whole list at sort
of exchange creation time or at the time of this interaction could pose
some performance issues just bloating the size of these payloads etc. I
mean it also is true that those use cases could decide not to use this
property at all and not tell you whether they're not what sources of
authority they're going to accept an issuer from.

Patrick St-Louis: Dave.

Nate Otto: But in any case, if we do want to expose registries in
education, these could become very very

Dave Longley: Yeah, I just wanted to be supportive of the idea that I think
the client is the party that's going to have the information for the
specific transaction based on what they have that will match the rules that
the verifier offers. So I think the client has to figure out what's going
to work that might involve downloading these lists which they might have
cached and sort those things out pick out the specific issuer that's going
to work and…
00:45:00

Dave Longley: if necessary any other credentials in a hierarchy and present
that together. I don't think the verifier can or should do that. and I
think what I just described is also the most privacy preserving way to
accomplish it.

Patrick St-Louis: Okay, I think there's good discussion here.

Patrick St-Louis: The thing that's apparent to me is that we'll need an
issue to kind of discuss now that we have an accepted issuers list of
strings or object with ids and divids. how could we expand this in the
future? I think having this object opens the door to a lot of possibilities.

Patrick St-Louis: for now we can probably just limit it to just ID and open
an issue and have discussion about what we've just discussed how can we
expand the accepted issuers list to also recognize an external trust list
of some sort is there any awesome so we have issue 598.

Manu Sporny: I have raised issue 598 to track

Patrick St-Louis: We'll go see if we have time at the end of the call for
that. I think it's important trust registries are always complicated and
has been mentioned these lists can get very very large.

Patrick St-Louis: so yeah so we'll probably let you time to address these
comments menu and we can come back to it next week. I think the comments
are pretty minor. It's just about changing this from a list of string to
object or strings and not sure did this one like I'm not sure but probably
something to do. Sorry. Yeah, what is this the accepted crystal sweep type

Dave Longley: yeah so this stuff is generated from OAS files and the
specific thing that we're defining here is the value for the accepted
cryptoes is an accepted crypto suite not necessarily a crypto suite so if
we have any other place that we need to specify cryptouite information like
I know we do for issuer instances then we could easily get confused when
doing maintenance and…

Dave Longley: trying to understand the OAS if we define a type that's
crypto suite and it's going to look different from providing the
configuration for an issuer instance and what crypto suite it's going to
use to sign for example.

Patrick St-Louis: So you're worried that this crypto suite is too generic
and…

Patrick St-Louis: might be used in two different place for two different
purpose and…

Dave Longley: Yes. Yeah,…

Patrick St-Louis: we should instead have a reference to an object called
accepted cristo street…

Dave Longley:

Dave Longley: this is just a renaming thing.

Patrick St-Louis: which is focused around being used in a presentation
request.

Dave Longley: Yep, that's

Patrick St-Louis: Yeah, I think I can get behind An accepted envelope and
we're probably the same thing with the issuers, Yeah. Yeah, you mentioned
that. Okay, perfect.

Patrick St-Louis: Yeah, I'm totally on board with this. and then the other
comments this lead seems pretty reasonable. So, me just put a comment here.
let me go just grab the issue number. So, 598. so discuss all go over
comments and update events.

Patrick St-Louis: There we go.

Patrick St-Louis: Perfect. we have time for one or two more. so this one
was a pretty straightforward one. I remember we talked about that last
time. Eric, do you want to take us through this?

Eric Schuh: Yeah, sure.

Eric Schuh: This is pretty straightforward and simple. when we added the
section for the delete presentations ID last week I was now able to fill in
the component table link for that endpoint. so the actual change there is
at the bottom just adding in that delete h a specific presentation so that
the link is properly generated and…
00:50:00

Eric Schuh: then in the HTML I just added the comment so that if anyone
ever comes in and updates that header they hopefully remember to come and
update the oas.yaml as well.

Patrick St-Louis: Right? Because we did merge the actual route last week
and…

Patrick St-Louis: this is just to add a relation to so okay yeah that's
very straightforward. Is there any objection to merging this? Right, let's
merge this. Okay, so we have about five or six minutes left. We closed one
issue. These two are left open.

Eric Schuh: Correct. Yep.

Patrick St-Louis: so we can kind of just try to see so if one issue was
open yesterday and lets discuss so this is a new issue we haven't discussed
it before. I cannot remember where feel like we had discussed this. I don't
know if it was on slack or in the last call. I do definitely remember we
did kind of allude to that idea of having normative stuff for processing
algorithms. so I'm happy to see that this issue is open. Would you like to
take us through this Dave? what we have to call

Dave Longley: Yeah, so we talk about in our spec we give a number of
endpoints where you can provide configuration information and in particular
for creating a workflow we say here are all the different values you can
put into your workflow steps but we don't talk about necessarily how to
process them in an implementation when someone has created an exchange and
you're walking through the exchange that's built based off of a workflow
and its steps. So we don't have any algorithms in the spec today that say
this is how you do it or how you could do it. And I think that would be
helpful for implementers. we don't necessarily have to make this a
normative algorithm.

Dave Longley: But if I wanted to implement a VCOM workflow server, it would
be helpful to me to at least see at least one algorithm for what I could do
to process the information that is stored in a workflow. and so I wrote up
one example of such an algorithm. it's just a first cut. It could be
tweaked in a number of different ways. I made the text kind of look like
how other algorithms and W3C specs look. So it's just available for us as a
starting point to sort of cover all the things that go through workflow
steps. And it's from an implementation that supports four different
protocols on the same exchange OID forvp, and invite request. So it works
with all of those.

Dave Longley: it's protocol agnostic and it has some hooks for where you
would do things with those other protocols. but that's more or less what's
here in this issue. people can feel free to read it and offer response.

Patrick St-Louis: I will be very interested to see how this concept fits in
relation to what Nate shared. because I believe that what Nate shared was a
very specific way to handle a workflow and he mentioned some conformance
tooling. so I'm really curious to see how these two things would correlate
to one another. and if the conformance interoperability guide that was
shared here would probably go into being a little bit more normative than
we would like here just because here we want to keep it fairly agnostic.

Patrick St-Louis: So I think when you want to keep things agnostic you just
don't want to be too super specific normative around some aspect. but I
think that we will still need some normative text if we want to build at
least some kind of test suite some kind of thing that you need to implement
to show conformance with workflows. whether that's processing the states or
they will need some text in hair that people can implement and test
against. so I'm definitely in favor of this. yes Dave
00:55:00

Dave Longley: Just a quick comment. One way to do testing for workflows and
exchanges that might avoid needing to rigorously test a specific algorithm
is have a set of test factors that exercise each feature that's in the spec
and have a client that can walk through an exchange and properly exercise
those features and do the right inputs, get the right outputs, and as long
as your implementations are able to do that, it doesn't really matter what
your algorithm does in the back end. because you're exercising what all
those possible features are. so that's one way to leave this entirely as
non-normative.

Dave Longley: But I'm not necessarily opposed to having it be normative if
it's helpful. But it might be hard to test any individual step in the
algorithm because I think you would end up writing the test suite the same
way I just described regardless of whether the algorithm was normative or
not.

Patrick St-Louis: That's interesting. for me when I think about these
workflows the thing that's important it's a bit like what I was saying it's
not on this call it was another call but is the different states that you
have and be able to make sure that a implementation moves toward the
expected states based on an input. Right? So I'm trying to think of an
example if you have a workflow that says present me this credential and
then I'm going to issue this credential we want to make sure that if the
credential presented doesn't meet the expected presentation request that
the kind of issuing software gets in a state that no I'm not issuing you
the credential like you haven't met this

Patrick St-Louis: previous step. and I'm not sure exactly yet how this can
be sort of detected in a workflow. because when you have two entities
interacting a workflow, they each have their own states on their sides, the
holder will have his different states and the issuer will have his
different states. they are correlatable meaning one state of the issuer
might match a state of the holder but they're kind of from a different
perspective and how you can get the state from the other agent is not
always easy often time they will just abandon the transaction so I'm not
sure exactly how this is done with workflow I'm not sure when a party decid

Patrick St-Louis: to abandon the workflow. Do they need to tell the other
side like I am, I can no longer keep going on this workflow. I don't have
what it takes. Or do they just, hang up and leave? Dave

Dave Longley: So I got on the queue to say something else. The short answer
to your question is they can just hang up and leave. the server would send
errors for certain conditions. so the way I kind of imagine without getting
into the details that's where the problems always are but the way I imagine
a test suite working would be you would have a workflow implementation and
an exchange client implementation and through each protocol message that
gets sent the test suite could both check the resulting state that what the
current state of the exchange is by asking for it from the workflow server

Dave Longley: service and it could check to see what response was sent to
the client either an error or the next message response that's expected for
a step and so the test suite could function on different roles. it could
play the role of the Exchange client and the coordinator at the same time
to just test a workflow. That's for a non-interoperability test. And it
would make sure that the state matches and that you're getting the right
messages or the right errors back for positive and negative tests. and you
could do all that without necessarily requiring anyone to follow a really
specific algorithm. They just have to produce the right exchange state and
the right response to the client based on whatever is expected.

Dave Longley: Then you could take that same thing and swap out that uses,
the exchange client that the test suite uses and swap it out for someone
else's implementation and do interoperability tests. And that's very
similar to what we did with issuers and…
01:00:00

Dave Longley: verifiers and things like that in the data integrity tests
and so in the VC test suite. So, I think it's pretty much the same concept.

Patrick St-Louis: Very interesting.

Patrick St-Louis: With that being said, thank you for taking us through
this issue. I think more will need to be discussed here but definitely in
support of this from what's been told so far. so we are approaching the
time for the end of the meeting. So thank you everyone for attending. we
closed one small PR so that's good. It's a little bit of progress. we
probably have another PR to close next time. we didn't go over that but
there are a couple issues that are assigned to people.

Patrick St-Louis: So if someone has some time, please go ahead and raise
another PR for the next call maybe I'll try to open one too. H and that
includes you Jory. I don't know if you're a developer or something but if
you have some spare time feel free to come in here. usually we do issue
assignment. We didn't have quite enough time for that today. but don't be
shy to take something easy, right? There are some tags on the issues. Some
says it's a loweffort ready for If something speaks to you and you have
some time, feel free to open a PR if you want to join in. so with that
being said, I'm going to join the meeting and thank you all for attending
and see you again next week.
Meeting ended after 01:02:11 👋

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