[MINUTES] CCG VCALM 2025-10-07

Meeting Summary: CCG VCALM - 2025/10/07 Meeting Overview

The meeting focused on community updates, introductions, pull request
processing, and addressing open issues related to the verifiable credential
API for lifecycle management. The discussion centered on authorization
capabilities, particularly around the integration of verifiable credentials
and the ongoing work on defining structures for credential issuing steps
and ID for credential templates.
Topics Covered

   - *Community Updates:*
      - California DMV's integration of verifiable credentials into digital
      driver's licenses and physical IDs.
   - *Introductions:*
      - Rodrigo, from UPM, introduced himself and his interest in
      verifiable credentials for authorization management.
   - *Pull Request Processing:*
      - Merged PR 529, 559.
      - Discussed and provided feedback on PR 549 (define reserved exchange
      variables) and PR 556 (define structure for credential issuing
steps and ID
      for credential templates).
      - Reviewed PR for updated API component tables.
   - *Open Issues:*
      - Discussion on expressing ZCAPs in verifiable presentations (issue
      555), deciding on a method for representing ZCAP requests and responses,
      with suggestions for separate pull requests.
      - Addressing issue 557 (interaction path for endpoints) and issue 558
      (clarifying service component architecture).
      - Brief discussion of advanced BBS features like pseudonyms.

Key Points

   - *PR 549:* Resolved feedback from Dave and will be looked at again next
   week.
   - *PR 556:* Will be looked at again next week.
   - *API Component Tables:* Eric Schuh will make updates based on the
   discussion
   - *ZCAPs:* Agreed on creating separate PRs for ZCAP representation in
   verifiable presentations and query mechanisms.
   - *Interaction URL:* Nate to take the action item on clarifying the
   language in the spec around these points.
   - *Architectural Clarification:* Eric will address the architecture
   section for clarity on combining components.
   - *BBS Features:* Manu to potentially consult with Greg Bernstein on the
   feasibility of a BBS credential issuance and presentation example.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-10-07.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-10-07.mp4
*CCG VCALM - 2025/10/07 14:57 EDT - Transcript* *Attendees*

Dave Lehn, Dave Longley, Eric Schuh, Joe Andrieu, John's Notetaker, Kayode
Ezike, Manu Sporny, Nate Otto, Parth Bhatt, Rodrigo, Ted Thibodeau Jr,
Vikas Malhotra
*Transcript*

Manu Sporny: Hey folks, let's go ahead and get started. We've got enough
folks here today. Let me go ahead and share my screen. we do have an agenda
today. first of all, welcome to the verifiable credential API for life
cycle management our agenda today is just covering some community updates.
sometimes we do introductions. I know, Rodrigo, you're new today. in a
little bit, we might ask you to do an introduction, if you want. It's
usually just like a couple of sentences about…

Manu Sporny: who you are, why you're interested in the work, and, whatnot.

Rodrigo: All right.

Rodrigo: Whenever you tell me

Manu Sporny: All the agenda today is community updates, and we'll do
introductions.

Manu Sporny: Then we'll process some pull requests and then continue to
categorize and work through some of the open issues. we were talking about
authorization capabilities last week and how to use the API to do those
things. and so we will continue that conversation this week and see what
other issues we want to cover. that's the proposed agenda. are there any
updates or changes to the agenda or anything else folks would like to
discuss today? Okay.

Manu Sporny: If not, let's go ahead and jump into introductions. so,
Rodrigo, if you'd like to introduce yourself, please do.

Rodrigo: All right. thank I've been in this group due to the timing here in
Spain as it is really late into the night, However, I freed my agenda to
come to every meeting here. H I presented here a couple of months ago and I
am from the UPM and we are currently researching that spaces and we're
usually using a verifiable credentials for managing authoritation within
them.

Rodrigo: So, I'm here to see what you guys are doing and to learn about it
now.

Manu Sporny: Wonderful. Welcome again,…

Manu Sporny: Rodrigo. My apologies. I had forgotten that you had presented
before.

Rodrigo: No problem.

Manu Sporny: If you don't mind putting in a link to some of the stuff that
you're working on, we'd love to see the other I guess Okay,…

Rodrigo: All right. I'm looking into them and I'm going to publish it now.

Manu Sporny: wonderful. Thank you. the other thing that we could do and
this is a bad time for you of course since you're in Europe if we could
discuss moving the call time if you want to participate on a very regular
basis right so let us know if this is keeping our friends in Europe from
joining and if

Rodrigo: No, there's no problem. I can join every Tuesday this hour from
now on.

Manu Sporny: Okay. All right. we appreciate it especially because it's very
late for you over there.

Rodrigo: No problem.

Manu Sporny: Welcome to the call again. Next item up are community updates.
I'll mention this because it's pretty big news. sent this out to the
mailing list. but this is basically the California DMV. so California is
the fourth largest economy in the world. they've integrated verifiable
credentials into their digital driver's license program about two years ago.

Manu Sporny: they're around 2.7 million cards or million verifiable
credentials out today. they have some stats on their but this last week on
October 1st they started putting verifiable credentials on the physical IDs
as well. So there are now physical verifiable credential barcodes
integrated into the physical California DMV driver's licenses and
identification cards. Those are being rolled out to 34 million people. very
large deployment.
00:05:00

Manu Sporny: it will take years to kind of hit the top end of those numbers
but they print a lot of these things every single day. the other kind of
news there is that the enabling technology is definitely the work that
we're doing in the credentials community group as well as the work that we
are doing in this group. so can't give too many details but the work we are
doing in this group was a part of congratulations to each of you that have
participated in the work. it has led to kind of that release of the
technology. okay, any questions, concerns about this item before we move
into the agenda? All right.

Manu Sporny: Then let's go ahead and move into pull request processing.
let's see. up We've got four pull requests that we're looking I think you
added the API component tables. Should I close 525 at this point?

Eric Schuh: Yes,…

Eric Schuh: as far as I'm concerned the 529 I or…

Manu Sporny: All right,…

Manu Sporny: I will do that. there was a lot of discussion in here, wasn't
there? spare the what was it? no. Five night.

Eric Schuh: sorry have it 559. Yes.

Manu Sporny: Which one?

Manu Sporny: Five. What? 559. There we go. Great. Is that all right. And
then we'll go through just in order. So, let's see. 556 depends on 549, I
think. So, this is 549. define reserved exchange variables. Coyote, you
mind giving us an update on where we are here?

Kayode Ezike: So I was able to respond to all the requests that folks had
on it. So a few editorial things and there were some other things that I
added. I think some of the bigger pieces that I added since the last call
are the refined examples. So there was already a basic example that was
there. I refined that, updated that and I added the example that uses step
template for workflow. and I also added basically just descriptions above
each of those to explain I get to give context as to what it represents and
how it could be used. I think this is example of one of them and this other
one above the other example.

Kayode Ezike: just I think looking for feedback on the language there and
also as I was going through I noticed a few other comments that I had not
seen yet. one of them was related to problem details where Dave was hoping
that we could use the ma for the problem details schema to represent last
error and I had a question saying whether if we should use that or error
response which also seems to be specifying error like types and then
there's another question that I had related to exactly right here.

Kayode Ezike: So basically Dave was wanting to add more variables in
addition to the ones that we already had for results. And so I was asking
whether or not we need to specify the field basically the schema for each
of the fields in there because for example presentation submission string
can also be an object that deserves keys in there. as how far down the
rabbit hole do we actually want to go in terms of specifying that?
00:10:00

Kayode Ezike: So those are the main outstanding questions that I had here.

Manu Sporny: Great. Thanks,…

Manu Sporny: K. go ahead, Dave.

Dave Longley: Just to quickly answer that last question, I would say let's
not fall all the way down the hole. We can peek in there and just put,
object and string types. some of these things like what you listed there
with presentation definition is even changing for the oid4 work from the
draft to their version one version. I don't think they have presentation
definition in there except in a special profile for the legacy code. So I
would say that just marking those things as this is a string, this is an
object and making those things I guess we can mark them even as optional
but just the top level stuff is good enough to let people know this is
where you can put these things and I think we're going to have our plan is
to have appix appendices where we have details around these other protocols
and we'll

Dave Longley: have example messages and things there and links to those
other specs and I think people can get the general idea that if you're
implementing something like oid forvp and you're receiving an authorization
request and you've received it in your exchange this is where you put it in
your results so it can be fetched as needed that sort of thing and maybe
that should even be not authorization request that Might have been a typo.

Manu Sporny: And then the other items I think you just need a response from
Dave Coyote.

Manu Sporny: Is that right?

Kayode Ezike: Yeah. …

Kayode Ezike: and they're relatively small things. Some of them are
editorial things and then the other one is basically preference over which
schema to use for error types

Dave Longley: which thing we use for error types might be a group question.
over time this group has evolved on how much we want to express about error
information and we've decided in a few places to put some error
information. I'm not sure if we're consistent but if we're not I think we
should become consistent and we should just be doing errors one way. if we
report an error here it shouldn't have a different scheme schema from
reporting it in some other place from some other API endpoint. So, …

Dave Longley: let's try and figure out if we're being consistent, if we're
not, decide as a group what we want to do and just reuse stuff that then it
should be an easy decision for this particular

Manu Sporny: Plus one to just standardizing the way we respond with
problems.

Manu Sporny: So we should use problem details if we can. my recollection is
that we had errors and warnings as well that we responded back with.

Manu Sporny: I think you can add those things to problem details, but I
does anyone remember.

Dave Longley: There's also when you had up the navigator on the left when
you had the tab up that had problem details on it the navigator on the left
of your screen this in the sidebar had error response and…

Dave Longley: I think that was the other thing that was mentioned.

Manu Sporny: I was trying to see. So we do use problem details in the
warnings and the errors. so we should probably use problem det This this is
a verification response. but if there's just a flatout error, we should
probably just return a problem detail, I'm guessing. go ahead, Coyote.

Kayode Ezike: So then where are we using the arrow response? The one I
linked to in that comment. Are we using that anywhere else? Seems it's a
similar layout but slightly different.

Manu Sporny: Yeah, I don't know where we're using it. no,…

Nate Otto: We are using it in one case on the post endpoint to slash
exchange ID. Looks like I'm sorry for speaking without

Kayode Ezike: I think focus.

Manu Sporny: it's totally fine. Yeah, if that's the only place we're using
it, we should probably replace it with problem details, unless I'm missing
something. Yeah, because we're trying to standardize using problem details
across the data integrity specs, the DID spec, and might as well do it
here. It's been working pretty well for us in those other specs.

Kayode Ezike:

Kayode Ezike: Okay, So I can then update that endpoint to use problem
details as well.

Kayode Ezike: And then I'll update the last error to use that. And then the
only thing left will just be the editorial descriptions of those examples.
And can talk about that offline if you want to.
00:15:00

Manu Sporny: Okay, sounds good.

Manu Sporny: All right, so you are So feedback from Dave and then you'll
make some more updates and we'll look at it again next week. Coyote or I
mean this thing we have reviewed this thing to death. So unless there's
anything significantly new think get changes in there and…

Kayode Ezike: Yeah, that was good.

Manu Sporny: if there are no objections let's just merge it by the weekend.
okay. All right.

Manu Sporny: So we'll proceed with that plan. All next up is define
structure for credential issuing steps and ID for credential templates.
This one builds. So this is PR 556.

Manu Sporny: It builds on top of PR 549. go ahead and take us through it
please.

Kayode Ezike: Yeah. Yeah.

Kayode Ezike: So, there was a recent comment that was put there I think
earlier today. I think there was basically this credential options thing
which my understanding of it generally is that it's supposed to be the
input that's the payload that's passed to the issuance endpoint. And I
haven't seen a comment response since then, but I wasn't sure where exactly
we are expecting this object to be created from which endpoint cuz I think
of it as either the workflow service or the workflow coordinator would
generate this payload before passing it to the issuer service to issue. but
yeah, take it away Dave if you want to elaborate on that.

Dave Longley: I put a comment in here that you didn't have time to see yet.
so that this object that has credential and optionally options in it is
supposed to be the rendered output of any credential template. And it is
that way because that this matches the body that gets sent to the I
credential issue endpoint. So I think I was not quite sure where to put
this in the spec either, but I guess the place we could put it is where we
describe a we could say that the credential template must render to include
at least these two things or in render to have this schema with minimally
credential and options in it or something along those lines.

Dave Longley: So that it's clear that when you provide a credential
template in a workflow, when you render that thing, it's supposed to create
the body that you send to the VC API issue credential endpoint.

Kayode Ezike: So, sorry just so to clarify. So, basically when you say
render you mean basic the way that the service will intend internally se
So, they'll basically parse all the variables and everything and then once
they have that credential parsed it will then create this payload to send
over to the issuer service. I guess what's confusing to me is that seems
like an internal thing that services would just need to know to do. It's
not entirely clear what that is specified interface is necessary per se.
I'm trying to grasp exactly what you mean when you say render to that pay.
Yeah.

Dave Longley: So, So, the input is a template and The template is compiled.
The variables are applied and the rendering of that which is the output is
the JSON payload that is meant to go to the VC API issuer endpoint. So,
this is about defining the interface around a credential template. We could
say it's up to your workflow implementation to somehow take in a template
and somehow turn it into this body that goes to the VC API issuing
endpoint. But it all needs to work that way anyway. That's how when you
provide a credential template that to workflow, the VC API workflow is
going to talk to a VC API issuer to issue the credential.

Dave Longley: So, it's an expectation and these are sort of API boundaries.
we could leave that somewhat open-ended, but even if we were to do that, I
would suggest so that implementers know how to do anything with this that
they would know how to build these systems at least in one way. If it said
the credential templates that you put into a workflow must render to the
request body that will be sent to the VC API credentials endpoint.
00:20:00

Kayode Ezike: Sorry, just one last thing. Thank you for clarifying that. is
part of your expectation that there would be potentially a need for
implementations to save that payload as with the credential options field
and that's part of why is the expectation always that once it's actually
generated it's immediately passed over to the issuer is as directly okay
all right so …

Dave Longley: I would expect it to be passed over. yep.

Kayode Ezike: I can try to find a to put a place to put that somewhere, but
I might call on you to review that whenever I have something up, but no
problem.

Manu Sporny: That sounds good. So, next step here is Cody, you're gonna
apply some changes and then we'll just take a look again next week.
Awesome. Thank you for working this one through as well. All right.

Manu Sporny: We have one more PR to look at today and that's the updated
API component tables. go ahead, Over to you.

Eric Schuh: Sure.

Eric Schuh: It might actually be nice if I could share my screen Monu since
I have it running locally.

Manu Sporny: Yeah, please do. Yep, please do.

Eric Schuh: Yeah. So this PR involves updates to both the VCA al ALM repo
as well as the respspec OAS repo. So I have a PR in here. that will need to
be incorporated before this one I think will work. but yeah, this is what
it looks like. maybe I'll go over to the Google doc if needed, but just
kind of taking a quick look at each one of these tables. it matches what is
currently in the Google doc. as we discussed for all of the different
services and components as well as workflow service here.

Eric Schuh: so mostly I guess if we just take a quick look at the code this
involved updating the expected callers for all of the endpoints making sure
that they were matching and then updating the HTML calls to include all of
the proper endpoints in the tables. along the way there were some minor
fixes as far as the exchange ID parameter name was just not following the
convention of the rest of our parameters. So I updated that alongside this.
but yeah that is the crux of this PR.

Eric Schuh: there were a couple of questions that I had in terms of as I
went through the YAML file, I did find these three endpoints that were not
listed in our table and did not already have an x- expected caller
parameter in the YAML. so I would like someone to come through if they
could and just double check that these three all look proper in the table.
and if not, it's a easy updates at this point. hopefully no more updates to
the respect OAS are needed even if these need to change. but it's these
three here, the, workflows/protocols, the slash exchanges, and this slash
exchanges exchange ID. That's it.

Manu Sporny: That's great. thanks,…

Manu Sporny: I think there was a bug before in the code where it was
listing both a get and a post and only one of them belongs somewhere. Do
you know which bug I'm talking about?

Eric Schuh: Yes. yeah,…

Manu Sporny: Okay.

Eric Schuh:

Eric Schuh: I can show that so it happened with the slashcredential id for
both the get and delete where the issuer service was also show showing the
holder coordinator as one of the expected callers and…

Manu Sporny: Okay.

Eric Schuh: the holder service was also showing the issuer co coordinator
as expected caller. so that was one of the updates that was needed in the
respect file. it was just for that disambiguation between those two

Manu Sporny: So, that's in there as well. That's great. Okay.
00:25:00

Manu Sporny: over to you, Dave.

Dave Longley: Yeah, thanks for doing this, I don't know if you wanted to
scroll to those three items. We could talk about them now. the get
exchanges and post exchanges. I don't think they certainly don't exist as
listed there, I believe. they're missing their prefixes there because those
would be off of a workflow. And so yeah, like that if there was get it
would be yeah so maybe we've just got some weirdness in a file somewhere.
there is no get exchanges like that. posting to an exchange is already
there and that would be the thing that says the post with the workflows
that says anyone it's two or three up from it.

Dave Longley: So post exchanges with the exchange ID doesn't exist. that is
duplicated by the first post that is up the one right after that.

Dave Longley: Yeah that is what that endpoint is. I believe the get
exchanges. I don't think that that one exists anywhere. which was the third
one was that get yeah okay so that one exists.

Eric Schuh: this protocols…

Eric Schuh: which I also think

Dave Longley: Yeah that exists. It can be called by either of those
coordinators. Technically speaking, anyone could also call it. So, it could
also be called by anyone, but I don't know if we want to highlight that
it's most likely to be called by the coordinators. because what they'll
probably be doing is the coordinators will be serving an interactions
endpoint. They will fetch the protocols from the related exchange and
include that in their interactions endpoint.

Dave Longley: So, I would suggest those other two are just some I don't
know…

Dave Longley: how they got in There might be some weird automated thing
that's making them show up, but I don't think those exist or they're
duplicates.

Eric Schuh: It was probably just part of the YAML refac refactor…

Eric Schuh: where these just got I would imagine left in or they were
floating around when they had been deprecated but sorry Nate, I jumped the
queue.

Nate Otto: Yeah, I just recommend to remove the two highlighted floaters.
And then I had a question about the protocols endpoint. that's a very long
URL and that is the URL that would often be encoded into a QR code or
something like that. do implementers need to implement the interactions URL
like that or may they choose a shorter path to it?

Dave Longley: So that URL would not go in a QR code. The interactions one
would and when you fetch the interactions the coordinator might call that
longer one to populate its protocols.

Dave Longley: So that one is definitely not expected to directly go into a
QR code. You could do it I guess technically but that you won't get the
trust signal from the coordinator origin. So you should be using the
interactions one on the coordinator origin so that when you put that in a
QR code and someone fetches the QR code they can surface the origin of the
coordinator and use that as a trust signal for whether or not someone wants
to continue within exchange.

Nate Otto: Sure.

Nate Otto: So the interactions URL is actually some outside of this API
spec and is hosted on a different system.

Dave Longley: No, it's no, it's in the spec. so yeah, Eric is highlighting
it there.

Nate Otto: Get slash interactions. Okay.

Nate Otto: is there a requirement to implement the URL that I had suggested
was long the protocols endpoint related to one exchange

Dave Longley: No, not nothing is a requirement to implement. it just
depends on your conformance class but all that that's doing is making it so
that you can ex that an exchange which has all of it the information in it
about what protocols it supports can surface that. But you could just not
do that and…

Nate Otto: Okay, thanks.

Dave Longley: you could have a system where your coordinator knows what all
the protocols are going to be for any given exchange and it can maybe
compute that on its own. but it's helpful to do, but I don't know. You
might need to do that to pass a test suite for conformance. If we say every
single it we recently added that conformance section that says you need to
implement something and we'll determine what that is in this

Manu Sporny: All did we cover everything, Eric, that you needed.

Eric Schuh: Yeah,…

Eric Schuh: I believe So I think my action items are just to remove these
two end points and then I think this should be good to go as soon as the
respec OAS PR is accepted as well.
00:30:00

Manu Sporny: Okay, sounds great. all right. Thank you very much for working
on that. it'll be good to have that update in there. I'll try to process
that respspec OAS thing and…

Manu Sporny: make a new release. I didn't even know PR was open, so I need
to go take a look at it and I'll try to process it.

Eric Schuh: It's only open an hour ago,…

Eric Schuh: so don't feel too bad.

Manu Sporny: I'll process it and then we'll do a new release. Unless you
think there's more that needs to be done, we'll work through it in the PR.
And if I forget, please please ping me and remind me because I want to make
sure that gets in there.

Manu Sporny: All sharing my screen again. And that was our last PR. So
that's Making good progress. let's go ahead and take a look at issues. we
do have a number of needs discussion issues. I think last time we had
Dimmitri here. I don't see Dimmitri today though. my recollection and I
could be totally wrong is that we discussed what is a issue of EC request.
Wait, hold on. Is this it? No. No. we were talking about ZCAPS, weren't we
last time? Okay.

Dave Longley: Yes.

Manu Sporny: and Demetri was like, "What does a ZCAP request look like?"
and unfortunately, I did not write down anything that we talked about last
week, but it's in the minutes that were sent to the mailing list. Yeah.

Dave Longley: I think one of the key things that came out of the
conversation is we started to get consensus around creating a subtype of
verifiable presentation that would let you put some kind of extensions in
there. So you could do things like present zcaps include zcaps when you're
issuing and do other stuff like bs components and so on.

Manu Sporny: And I think if I recall correctly, we're probably going to put
it in a verifiable presentation and then we're trying to figure out if it's
a new subpropy in a verifiable presentation something else.

Manu Sporny: I think we decided definitely not in BC due to potential
confusion. There was a third option there that I totally forget right now.

Dave Longley: Dropping it directly into the protocol was the third option,…

Manu Sporny: right.

Dave Longley: but then you have the problem of having to repeat that across
different protocols,…

Manu Sporny: So, we're basically down to how do we express this in a
verifiable presentation? five 10.

Dave Longley: And that's the response component of this, not necessarily
the request. So, this says add an example response and once we sort that
out, it would cover that piece of it. We also need to say how would you
request a ZCAP so that you would know what to respond with.

Manu Sporny: No, I think it was two.

Manu Sporny: Was it the second? No, it was the first. No, was it what was
last Tuesday?

Dave Longley: Last Tuesday were the 30th of September.

Manu Sporny: Thank you. at 9:30 calls and came to forward Zcap.

Manu Sporny: A response that includes a Zcap should be a verifiable
presentation. details request query language still needs to be specified.
Do we want to continue this conversation this week or do we want to let
somebody raise a PR and then we can talk about something concretely? Okay.

Dave Longley: I recommend someone should raise a PR with a suggestion.

Manu Sporny: A PR should be raised with the following items above proposal
for the following two items above.
00:35:00

Manu Sporny: I'm going to mark this as Yeah.

Dave Longley: Yeah, you could say two different PRs…

Dave Longley: if not, the presentation part has more value than just ZCAPS.

Manu Sporny: Yeah. different PR should be raised to discuss proposals more
concretely.

Manu Sporny: PR for what the ZCAP looks like in a verifiable presentation
and a separate PR for what the query for that VP containing Zcap looks
like. All right. And this one's going to be a little challenging. tie ready
for sort So, this one will be a bit more of an adventure than most of our
other issues. did not mean to click All that one is ready for PR. Which one
of these do we want to tackle next?

Manu Sporny: Does anybody have a preference?

Dave Longley: I think we should do that first one. I know that Nate was
just asking something similar about

Manu Sporny: So this is issue 557. Is it required to use the path slash
interaction ID for the endpoint or can another arbitrary path with IUV
equals 1 which is interaction version equals 1 query parameter be used
instead?

Manu Sporny: Eric, do you want to guess who should localize it? Okay.

Eric Schuh: Yeah, I can just give an intro.

Eric Schuh: So, this comes from PR550 where Nate made this comment and I
thought it might warrant some discussion. I know there's some history in
terms of the retail spec that we've been working on with Kexus as far as
why this is in the form that it is currently in. but I thought give the
group a chance to discuss this. So Dave

Dave Longley: So I think from the perspective of a client that's like
receiving an interaction URL however they get it via QR code or some other
means I think they're going to treat that URL as opaque. with the exception
of looking for the query parameter and the version. I don't think they care
what the URL looks like. So from that perspective I don't think there's any
requirement that you have to put it at the end of this endpoint. so I think
we should have a statement that says you don't have to do that. but it's
also good to say this is what we recommend you do. because you get these
other benefits from dividing your space up like this and so on. but from
the perspective of someone consuming the URL as the client who's trying to
do the actual interaction, I don't think it should matter.

Manu Sporny: All right. Any other proposals for different approaches?

Kayode Ezike: I guess just to add on to that maybe is that and I think I
mentioned this a few calls ago it's to underscore that technically it's not
even supposed to be hosted by the workflow service. and so that even
highlights it further because the coordinator has as much freedom as it
wants to the kind outside of obviously having that IUV query parameter but
it could be anything because of the fact that the coordinator can format it
to be anything. It just has to make sure that it returns the data that
comes back from the protocols endpoint that the ser workflow service
exposes.

Kayode Ezike: So I'm not sure if that's an additional language that should
be made clear is that technically as far as the table is concerned for
example even it wouldn't even be hosted by the workflow service it would
just be at the coordinator and I even kind of a little bit at putting that
path there at all on it because again it can be anything but maybe it's
just a way of for We can maybe make it clear that it can be anything. It
just has to have URL type and has to have that query parameter with that
value in there somehow or another.

Dave Longley: Can I jump Q real quick just to say let's not say it doesn't
need to be hosted…

Manu Sporny: Go ahead, sure. Thanks.

Dave Longley: because this is not an endpoint for the workflow service and
I don't want to mislead a reader into thinking that they would put it there
so let's just say it is not hosted there instead of you could just edit the
text instead of it saying it is not hosted at the workflow service comment
it lives at the coordinator and that's it sorry for the Q
00:40:00

Nate Otto: Yeah,…

Manu Sporny: Go ahead.

Nate Otto: I think this issue could probably be closed relatively quickly,
although maybe we do want to improve the clarity of the language in the
spec around these points. So, I'd be happy to take an action item for if no
one else grabs it. but it'll be a few weeks before I'll be able to get to
it. And then the only other point I wanted to make is that we very likely
will see a lot of implementers combining multiple of these named services
within one single application.

Nate Otto: I am currently gage in doing some assessment of implementations
of the verifiable credentials u end to end and…

Nate Otto: I'm seeing far more than half of the implementations I'm looking
at are combining services in ways that are not predicted by this
specification. So I guess I would caution about being too hard about that
uppercase not hosted at the workflow service…

Manu Sporny: Thanks. Thanks,…

Nate Otto: because we almost certainly will see workflow services that are
the same exact application as verifier coordinators.

Manu Sporny: Go ahead, Eric.

Eric Schuh: Yeah,…

Eric Schuh: I think you could go ahead and assign this to me as well. I
have a very similar language update in response to issue what is it 558
which is effectively trying to clarify the same type of idea that workflow
services can interface with multiple coordinators and that any individual
piece of software could take on multiple roles of different components in
our system. So, I think I could probably get this language update in at the
same time as doing number 558.

Dave Longley: Yeah, we are in dire need of that language because it is
everything Nate just said is true about how you can combine all of these
different components into the same application and it is the language we
have in the spec today I think is confusing people because it's still true
that this endpoint will not be hosted at the workflow service but if you
combine your workflow service and your coordinator it will be hosted in the
same application But it is an aspect or feature of the coordinator and we
need to figure out how to unconuse readers of the spec. it's totally
understandable that they would say the words that Nate just said because
they're thinking about the architecture in multiple different ways at once.
So if you think of this as a single application you put everything into all
the endpoints are going to be part of your application.

Dave Longley: But which component are they part of? And where does that con
concept of architecture end up breaking down? If you're mixing things like
I just have this one workflow service is not an issuer works flow service
or a verifier one. It does and so we both want to adhere to making sure our
architecture makes sense and we say where these things are, but we also
have some weird things in our current architecture and categorization that
might not be quite right for even what we intend. but we don't want people
to think you've got to cut your application up in ways that don't make
sense for your use case. You don't have to do that.

Manu Sporny: Right. yeah, I agreed. so I think what we're saying
architecturally we want to talk about things as conceptually kind of
different components and then talk about combining those components into a
single application. and that being totally fine and legitimate thing to do.
is that a part of the PR you were thinking of doing as well,…

Manu Sporny: Eric or Nate, or should we raise another issue for that?

Eric Schuh: I guess no I think that tracks pretty closely with the
discussion that was happening on issue 558.

Eric Schuh: So if you read my last comment there I think that's about where
I had ended up which is that I think the architecture section probably
could use opening paragraph that effectively explains this aspect of our
components and that we made choices for clarity sake in the specification
but that any implementer may choose to effectively implement any
combination of the components as they wish in their own software
application. So I think it's all part of the same conversation at least in
my mind.
00:45:00

Dave Longley: If you're speaking monu, you might be muted.

Manu Sporny: Thank you. I was muted. yes, that sounds good. We've got both
issues that we're tracking. They're both ready for PR. So, whenever you all
get to them, that's great. Ted also provided some useful language here,…

Eric Schuh: I just put it in 558's issue.

Manu Sporny: which could be copied and pasted into that issue. Ted, I don't
know if you want to do that or Good, that's captured. anything on issue 557
before we move on to the next one. All right, moving through these in a
pretty fast clip, which is where is our needs discussion? All right. which
one do we want to take next?

Manu Sporny: advanced BBS features like pseudonyms or add an issue of
verifiable credential request example. I hesitate to talk about issue 548
issue VC request example without Demetri here. but we'll need to revisit it
once he's on the call again and then we've got this pseudonym feature thing
as well. Any preference

Dave Longley: If we want to wait for Demetri, we can talk about the second
one. I don't know how far we will get in terms of progress on that second
one. I think the second one is needing someone to do an implementation. but
I can give a quick lead into this. this is around being able to issue
certain types of privacy preserving unlinkable credentials to people.

Dave Longley: and when you're doing that, there's additional bits of
information or cryptographic commitments to certain values that have to be
provided by the holder prior to being issued something. And so in our
protocol, we need to say here's where you would put those things. And it's
looking like the place you would put those things is still going to be in a
verifiable presentation. but we just need a subt type of verifiable
presentation that would allow us to easily add little extensions.

Dave Longley: So, I think the proposal that has been floating around
without being written down in a PR or anything yet is if you wanted to be
issued a BBS credential that supported unlinkable pseudonyms, then you
would provide a verifiable presentation that had a commitment in it to some
secret values. And when once you've provided that in during an exchange,
the issuer could receive it, process verify do what they need to, and then
issue the credential that would be bound to the secrets therein. and then
you would receive your BBS signed credential in a verifiable presentation
from the issuer.

Manu Sporny: I am wondering if this is something we should ask Greg
Bernstein to work on. because we need just an example that covers all the
bases and then we can potentially start refining it. this makes me really
sad. I don't know why yet. Just have a viscerally bad reaction to this. not
to say that it's not what we end up doing. I'm wondering sure. Yeah.

Dave Longley: Can I speak to that for a second? So, one of the great
strengths of JSONLDLD is for three-party models. So, one party might be
authoring a piece of data that needs to be self-describing because you have
no idea who else is going to read that data. it allows you to scale to you
can get massive scale from using that technology. because you can scale to
parties you don't know that you might not even be in communication with
potentially ever.
00:50:00

Dave Longley: what we're talking about here is modifying potentially a
verifiable presentation to allow extension through maybe simpler JSON,
which can make more sense because you've transitioned into a two-party
model when you're just a holder trying to get something from an issue and
you're just you're just trying to pass data back and forth that's really
specific to whatever type of credential or crypto cryptography you're
trying to get put on And so you're both going to have to adhere very
strongly to a spec that you both know about and it's going to be very
rigidly defined and nobody else should ever be looking at that information.
So all the parties that are involved. It's a two-party exchange of
information and it's very rigidly defined by specification as opposed to
here's some vocabulary from some other community that defines my claims and
a credential.

Dave Longley: And so it's a more natural fit to allow people to write these
extensions to do this sort of thing in those situations as opposed to when
you're doing something like modeling claims in a verifiable credential
where you have no idea who might be consuming or using those claims or
merging them with other claims.

Manu Sporny: So you're saying this is for communication between I'm seeing
two use cases here maybe. One of them is I'm wondering what the use case
is. One of them is during the issuance process, you want to commit to a
secret or provide some values to the issuer, you're the holder and you need
to provide something to the issuer.

Dave Longley: That's

Manu Sporny: Okay, so that's the second one is when you are doing a derived
proof and you're the holder doing a derived proof and you want to
communicate that to the verifier. is that even a use case?

Dave Longley: No, that's not a use case. I don't think that the site.

Manu Sporny: All right.

Manu Sporny: So I'm going to stop thinking about that without and…

Dave Longley: Okay. Yeah.

Manu Sporny: then the other one is you are the holder talking to your own
kind of holder service to do things and you might need to provide something
to that service to derive the proof. Is that a use case?

Dave Longley: And the final use case is an issuer is talking back to a
holder handing them other information that might not be verifiable
credentials might be Zcaps as an example.

Manu Sporny: All right. Yep. So with that and one of them doesn't seem like
a two-party model thing to me, which is the use case where you're the
holder, interacting with the software, I would expect that, yes, it's
originally defined and all that kind of stuff, but I don't see why. there
are two thoughts come to mind.

Manu Sporny: One of them is should we put it in the actual data integrity
layer, the cryptographic layer or something like that. benefit there it
kind of gets put into an area of the payload that is kind of the
cryptography stuff. The downside being that it wouldn't work with other
types of enveloped, ZKP, things. It's the same thing as putting it at the
protocol layer. Same downsides there. I'm wondering why it feels more like
an ecosystem thing and more like a highle standardization thing. It doesn't
feel like a two-party thing. it does feel like a three-party thing to me.
So, I'm wondering what I'm missing there. Yeah.

Dave Longley: So the reason I say it's a two-party thing is the information
that's generated by the holder is only ever intended to be given directly
to the issuer and no one else is ever meant to look at it. So, there is no
third party that's going to be looking at it.

Dave Longley: This is the case for doing things like I'm going to put
something in an envelope, send it to a specific recipient, and they can
open the envelope and read it as opposed to I'm going to mint some claims
and put them out into the world and they might go to anybody. So that is
definitely not the use case here.

Manu Sporny: Yeah. No,…

Manu Sporny: I guess I'm looking at it from kind of a semantic
understanding of that's true. but I'm looking at a higher kind of protocol
layer. the protocol is a well-known protocol and that's why it feels more
three-party. I mean, I get that the information is only going between two
parties, but the protocol itself and the fields and all that kind of stuff
is kind of more of an open ecosystem thing. We'll have to think about this
a bit more.
00:55:00

Manu Sporny: if something feels a bit off to me about it, I don't quite
understand what it is. noting that we're two minutes over. I'm just reading
Coyote's thing. Okay. So, we'll come back to this in the next call, maybe
talk about it a bit more. I'm wondering how much time we should spend on
these things until somebody implements something, it's kind of hard to talk
about it more concretely. so maybe next step here is to maybe get Greg to,
because he did put together that whole kind of example for this DCG.

Manu Sporny: maybe talk about what would a BBS presentation back and forth
issuance and presentation look like. okay, we are out of time for today.
Thank you everyone very much for the great discussion. we've got a couple
of actions on pull requests that we need to process. there are 30 issues,
many of them with ready for PR labels with a fair number of loweffort
issues that could be done. So if you're looking for something to do,
there's quite a few here that we could write PRs for already. we will meet
again next week. go through the issues, and keep working on A reminder that
tomorrow is a verifiable credential working group call.

Manu Sporny: instead of our incubation community call. so try to make that
we are only meeting once a month but we're going to be talking about
adopting the render confidence method and processing issues. I expect we'll
also talk about W3C technical plenary and the new charter. Okay, that's it
for today. Thanks everyone. Have a great rest of your day and we'll chat
with some of you tomorrow. Take care. Bye.
Meeting ended after 00:57:15 👋

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