[MINUTES] CCG VCALM 2025-09-30

Meeting Summary: CCG VCALM - 2025/09/30 Topics Covered:

   - *Review and Discussion of Pull Requests (PRs):*
      - PR 525: Update API component overview to include workflows.
      - PR 549: Define reserved exchange ria
      - PR 555: Add a warning about unknown proof types to security
      considerations.
      - PR 556: Define structure for credential issuing steps and add ID to
      credential templates.
   - *Discussion on Issues:*
      - Issue 547: Provide an example of a Zcap request and response format.
   - *Verifiable Presentation Request (VPR) and ZCAP Integration:*
      - Discussing the format for returning ZCAPs.

Key Points:

   - *PR Updates:*
      - PR 525: Eric Schuh to update the table generation before next week.
      - PR 549: Discussion concluded, Kayode Ezike will incorporate the
      discussion into the PR.
      - PR 555: Manu Sporny will merge this PR by the weekend, unless there
      are further comments.
      - PR 556: Cody to finalize and merge after PR 549 is merged.
   - *Issue 547 - ZCAP Request/Response:*
      - Dmitri Zagidulin proposed an appendix for a non-normative example
      of a ZCAP query and response format.
      - The group discussed how to integrate ZCAPs, with the consensus
      leaning towards including it in the VP directly, through a new VP type.
      - The group is against putting ZCAPs inside of a VC, due to potential
      confusion.
      - Dave Longley proposed a solution using a VP extensions field, with
      a focus on two-party interaction.
   - *General Discussion:*
      - Nate Otto raised concerns about the need for defined schemas in the
      VPR.
      - The group discussed the implications of different integration
      approaches on existing ecosystems, interoperability, and potential
      confusion.
      - The need for clearer explanations and communication of the chosen
      approach was highlighted.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-09-30.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-09-30.mp4
*CCG VCALM - 2025/09/30 14:58 EDT - Transcript* *Attendees*

Dave Longley, Dmitri Zagidulin, Eric Schuh, Joe Andrieu, John's Notetaker,
Kayode Ezike, Manu Sporny, Manu Sporny's Presentation, Nate Otto, Parth
Bhatt, Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right, we've got a good group here. Let's go ahead and get
started. welcome to the verifiable credential API for life cycle management
call. we do have an agenda today. The agenda is largely community updates,
processing PRs, and then we've got a couple of items that still need some
discussion. So, we're going to talk about those. are there any other
updates or changes to the agenda before we get started? Okay, let's go
ahead and dive into it then.

Manu Sporny: we have a set of pull requests. I'm just going to go in order.
I merged a couple that seemed like they were ready to go and the other ones
that didn't seem like they were ready to go, I kind of left. So, let's go
through them again. Eric, should I close this PR? I think I was leaving it
open or maybe I was either leaving it open or leaving it for you to update.

Manu Sporny: Okay.

Eric Schuh: Yeah, don't close it quite yet. I have a couple of bugs left in
the table generation for this particular one that I didn't quite get to
before leaving on my travels here this week. so I should have this one
resolved before I call next week.

Manu Sporny: Sounds good. All right. So that is So we'll leave 525 open
update API component overview to include workflows. and then wait for your
PR to come in before closing next one is this one that Cody raised a couple
of weeks ago which we've had a lot of discussion Cody,…

Manu Sporny: do you have an update for us on this on.

Kayode Ezike: I didn't send this comment that I made recently.

Kayode Ezike: So basically I put together if you look in the meat chat a
gist of sample workflow configurations and I think basically in this PR
you'll see that there is an example workflow configuration that I
introduced but I wanted to either modify it or add another one that
contains a step template example for our discussion in the past. And so
this first one is a basic one. This does not have step template. it has a
data off request step and then started off step and then it has a
credential delivery step. so pretty straightforward and has example
credential variables that are populated into the credential templates array
there.

Kayode Ezike: And then in the other one though, the second file in this
just scroll down. So I'm attempting to use if you notice on the line five
step template was basically trying to follow the advice that I believe Dave
was trying to give around using a templated workflow to populate the
results variable. Essentially what I'm trying to do here is that a couple
things. Did off is a very common step. So it sounds like a good idea to
have it here somewhere. And secondly it seems like a pretty instructive
example because it's an example of a step that dynamically receives
information that would be populated in the future which is the exact reason
why we have results.
00:05:00

Kayode Ezike: And so I wanted to see if there's a way that I can use that
step template design to do that. But I'm still finding I'm referencing
results. If you go down in credential delivery step, I'm referencing it in
credential further down Request down there somewhere. But it's still not
clear to me exactly how we instruct through the use of this configuration
that population outside of just the VCPI or VCPOM workflow service just
knowing to put it into that verify authentication property underneath the
step configuration. So it's still an open end here that I'm trying to put
together.

Kayode Ezike: And if you scroll down on further you'll see some questions
that I have. where I'm trying to see how exactly we would go about
populating that results field.

Manu Sporny: Go ahead, Dave.

Kayode Ezike: So that's the main thing I was able to make progress on this
week.

Dave Longley: So when you say it's not clear how the population of this
value would occur, I'm not sure I understand that question. So I just want
to walk through in my mind how it would work and you let me know where that
question comes from. So if someone had created an exchange off of this
workflow, the first thing that the exchange would do would be to read the
initial step which is the did off request step. It would get the step
template from that step and it would compile and execute the template using
the variables that were in the exchange.

Dave Longley: And that would produce something very close to what's on the
screen there. I don't see any variables actually used inside of the step
there. So those are all constants, it looks and that step would be
generated and then it would do whatever the step says to do, which is to
send a verifiable presentation request to the client. the client if they're
doing the right thing would respond to that with some credentials and those
would then be stored in the variables for the exchange under results did
off request. So it would store the results of the Then the step processor
would go to the next step which is the credential delivery step. And in
this step all that is listed here is issuing credentials. They are issue
requests.

Dave Longley: there's no other verifiable presentation request to send to
the client. So it would then go through the issue requests, grab every
credential template from the workflow and it would compile and execute
those using the exchange variables which would include the results from the
did off and step which would then populate the value for example wherever
that was referenced in here. there it would populate the value in the
subject ID for that VC it it's its configured issuer instance which would
issue the credential and then it would send that credential to the exchange
client in a verifiable presentation. So it seems like everything would work
out and would follow that flow that I just described.

Dave Longley: where in there is the

Kayode Ezike: Yeah, I think the question lies in the question you asked
early when you said where in step template is are we using variable because
that's also where I was thinking there would be some form of provision of
this reference to results would be somewhere in that step template section
but I think the missing link is how do I put it so to me it almost feels
the most obvious

Kayode Ezike: thing to do which maybe not the right thing to do but would
just be to understand that there is a certain field in which to put
basically this verify presentation field that would be placed under a step
config that would ultimately have that information but I think maybe what
you're saying is that somehow someway the exchange is supposed somehow know
to save it under there it's still a little bit unclear to me how exactly
something like maybe I just need an example of a change that will come from
this to actually enable that.
00:10:00

Kayode Ezike: Okay.

Dave Longley: So my understanding is this PR or…

Dave Longley: another one indicates that the results of a submitted
verifiable presentation in a step will be stored under that step name under
the property verifiable presentation. so we've got some kind of PR
somewhere that might be the one you were working on that says that's where
for any given step if a verifiable presentation was submitted that's where
it will be and then you can use that in your workflow design. what is in
that verifiable presentation will depend on the rest of your workflow
design and you can craft that however you can ask for whatever you want and
you can add JSON schemas to demand that those values be present or else the
next step won't move on.

Dave Longley: So as the workflow designer, you've got a lot of choices to
construct your workflow,…

Dave Longley: your steps, and validate that the Exchange client has
complied with

Kayode Ezike: …

Kayode Ezike: so So, what you said is true. This current PR does introduce
the verify presentation field. that's part of what I added to it. But I
guess what I was getting from the discussion in the PR was that we wouldn't
need to add specific fields underneath results and it would all just be
determined off of the configuration. But if what you're saying is that we
do reserve your presentation and all the fields that exist under the VP
schema in there, then I guess that aligns with it and you just have to know
as a workflow influencer that's where you would place data that comes from
a BP response.

Kayode Ezike: And I guess that explains that, but it still doesn't I guess
deal with the arbitrary variable definition that could potentially go under
results. And maybe that's for a different discussion.

Kayode Ezike: But if what you said is the case that we're just going to
reserve at least that field underneath the step config, then I can guess I
can get behind that too.

Dave Longley: Yeah, I do think we should reserve it…

Dave Longley: because it's going to probably be what people would just
commonly use for this. I also mentioned that we also have the invite
request protocol and we have oid4 protocols that also collect information
in steps and so we could just reserve those fields as well. even if we had
not reserved those fields someone who was designing a workflow to work with
a particular configuration in a particular system could know where those
things get stored based on what they're working with.

Dave Longley: But it is better for interoperability and less vendor lock in
if we can agree on where to put these things. your suggestion is exactly
how we put it in our implementation and as long as we have two
implementations then that's something we can get into the spec. So that's
always a constraint that is we have to keep in mind…

Dave Longley: if we're going to say this thing's reserved or this is where
you put it. we have to have at least two impleers willing to do it.

Kayode Ezike: Okay.

Kayode Ezike: So, I guess that takes care of at least this use case where
we have reserved variables and I guess the other use case of allowing any
variable X to be populated. Maybe it can be targeted in another PR or
something. But I think at least I have enough to move forward and include
the example slash examples that I have up here inside of PR.

Nate Otto: Hey, this is As I look at this, I see you're using did
authentication as an example, but we don't yet have really any firm schemas
about what type of data might appear in the verifiable presentation
request. Can I get just an update on where we're at with absorbing VPR into
this and whether we will get some sort of harder schemas for the different
query types that are supported within the VPR scope?

Manu Sporny: Yes, that is work that needs to be done. It is not where I
would like it to be right now. I think we have to define the schemas a bit
better. what do we have currently? So I think let's see is this even we
have a semi okay schema the first question is do we want to express the
schemas as oas JSON schema I think the answer is yes to that so we just
need people to raise PRs to do that I don't think we have gotten that done
did authentication is I
00:15:00

Manu Sporny: I think fairly stable. Query by example has nothing in it
right now and we should probably, make it better. but I was kind of holding
off until we had enough examples in the ecosystem to kind of lock it down
and didn't want to lock it down a little too early. and then there's the
whole question about, a dack and where does that fit in and that sort of
thing. so Nate, it's yes, we need to do the work. Anyone's welcome to raise
PRs to move that forward. no particular reason that we haven't done it
other than we didn't want to lock it down too early, but now feels like, as
we get multiple implementations, we're going to need to lock it down a bit
bit more. go ahead, Dave.

Dave Longley: There's also an open issue for converting things like query
by example to a list of JSON pointers which is highly compatible both with
selective disclosure and converting to DCQL. And so we'll want to and
potentially to J presentation definition whatever that thing is called that
uses JSON path. So there are some conversion things that we would want to
document as well.

Manu Sporny: And I think there's an open question around do we even want to
document presentation exchange or presentation definition the stuff that's
old and out there? because I think we're getting signals from the market
that they're just going to drop support for it. so I

Dave Longley: it is significantly more complex. So if we do anything with
that, it might just want to be a non-normative appendix. But I definitely
think we want to do the DAL stuff, but that is significantly easier just
because you can convert to and from with JSON pointers and so on. There's
some interesting things we'll also in a document because query by example
for example lets you ask for something in a set. It doesn't have to be in a
specific location. and that's not something supported by DCQL, but
something that we could perhaps figure out how to approximate. but that's
an important difference between the

Manu Sporny: All right. Thanks, Dave. Nate, did that answer your question?
Or at least give you an idea.

Nate Otto: Yes, thanks for the status update.

Manu Sporny: And if you needed to move faster, just let us know so we can
put the things in that are going to help people, implement interoperable
stuff. okay. Coyote, back to your PR.

Manu Sporny: What are your thoughts on where we are right now? did we
answer your questions here?

Kayode Ezike: So the second one is one we really discussed.

Kayode Ezike: This first one is not a huge one. I mean there's a reference
that I sometimes use in workflow configs to a globals field which is just
an internally known thing. And I guess the thing I was saying there is is
it necessary specifically for the issuer I did to explicitly include that
in templates or is it kind of something as a workflow service
implementation you're just assuming that you would always have to kind of
put that into pretty much every credential that you need to and the
configuration there in is based

Kayode Ezike: off of whatever sort of issuer instance you configured for it
to be used to issue that credential. And so I think the answer to that
question is probably going to be no. We don't need to include if you scroll
up you'll see what I'm talking about. If you go to the first basically the
credential template section issuer ID. Exactly. Yeah. So I imagine that we
probably don't need to have that explicitly be listed out there. It's just
something that every petition just knows to use whatever mechanism they
want to use to actually properly

Dave Longley: Yeah, the other thing that's important with that is whether
the VC API issue endpoint. I think what we settled on is if an issuer ID is
given to that endpoint, it has to match the configuration over there. But
it can also just be omitted because the issuer endpoint will provide it.
And so there are a lot of cases where you would just rely on the
configuration to provide that value and it's not something that you would
use there. And you can also have workflow steps that issue credentials from
multiple different issuers. So if you had a globals specifically that that
says issuer. ID. I think you would have trouble implementing those
workflows with that might have multiple issuers.
00:20:00

Kayode Ezike: Okay, Yeah, that makes sense. So then I think the main reason
was to just know again the main purpose of the gist is really just to know
what to include as an example. So I'll just remove it from the example that
I include and then I think it just be up toations to include that value
whenever the issue and so to answer your question man yeah I think I have
everything I need for this PR there's still some other I think editorial
things that I need to address as well but I believe I have everything that
I need at this point and yeah I'll just continue to work on

Kayode Ezike: Yep. Yeah.

Manu Sporny: Okay. …

Manu Sporny: So, you're just going to take the discussion that we had
today, roll it back into the make some changes, and then we'll take a look
at it again next week with a presumption that we'll merge at that point. or
I mean, we can just merge after you, tell me that the changes are in. it
sounds like we're all in agreement and at consensus on this. Okay. So, how
about that? I'll wait until you give me the high sign and say this is done
and then I will merge once you've got all your changes in there. And thank
you again, I know this is a significant amount of work that has gone into
the PR.

Manu Sporny: So really appreciate you working through all of it with the
rest of the group. all right, that is 549. Define reserved exchange ria
Moving on to the next PR which is 555. Add a warning about unknown proof
types to security considerations. I think I updated things and I asked Ted
for another review and you have a comma to add, but I think other than that
we're good to go on this PR.

Ted Thibodeau Jr: From my objective.

Manu Sporny: I will merge this next weekend then.

Manu Sporny: it would give other people a chance to review if they want to.
I don't think this is a controversial PR. so merge by weekend unless there
are other folks that want further changes. all right, next PR up is PR 556.
Define structure for credential issuing steps and add ID to credential
templates. Coyote, you want to take us through

Kayode Ezike: So, since last call, so a quick reminder, this PR is
addressing an issue raised some months ago where we needed to be clear
about how we specify that a step is issuing a credential. So the idea here
is that a step inside of the steps field in a workflow configuration would
have a set of issuer request items each of which refer to an entry in the
credential templates configuration field in a workflow either by ID or by
index. and so the idea is that however many templates are referenced from
that array will be the number of credentials that are issued using the
appropriate schemas. And so I think the main thing I did here was just
clean it up a little bit since last week.

Kayode Ezike: I think it's still a dependency of the other PR that I just
presented because it's the reason the variables is something that's defined
in the other ironically enough the other PR also references this a little
bit because it does make a reference to issue requests in the example. but
I don't think that's a big deal because it's going to be a fast follow
anyways. But I'm basically waiting to merge that one before I merge this
one.

Kayode Ezike: And in the meantime, I'll see if there's anything else that I
should clean up here. but it's pretty much ready to go.

Manu Sporny: All right.

Manu Sporny: So you're going to clean this up a little bit more and then
we'll merge as soon as you say it's good to go,…

Kayode Ezike: But only after the other one because it depends on that. Yeah.

Manu Sporny: right? Yep. Yep. Understood. Okay. let me see. Have we gotten
enough other reviews on this? I think Dave, you took a look at All right.
So, folks have until the weekend until Cody gets done. probably till the
weekend to review this and then we'll get it That is the last of our Rs.
any other comments on PRs before we move on to issues?
00:25:00

Manu Sporny: All right. If not, let's go ahead and move on to issues. I
know that we have a couple of new issues here, but I want to get to our
needs discussion issues. I think two of these are yours, Dimmitri. I know
we were discussing one of them when we ran out of time last time. Do you
remember which one it was?

Dmitri Zagidulin: Yes, we were talking about the issue VC request example.

Dmitri Zagidulin: So, could we do the middle one 547 at example because I
feel like this one's much shorter. It just says look,…

Manu Sporny: Yes. Okay.

Manu Sporny: right. Yep.

Dmitri Zagidulin: we have an example how to request a Zquery, but we don't
have an example of what the format that it gets returned in. For verifiable
credentials, we have verifiable presentation, but we don't have an
equivalent for Zcap. All right.

Manu Sporny:

Manu Sporny: Plus one of that. I think in the spec today, yeah, so this was
the Zcap query and then this is an ancient example, Kind of like it was a
bit of a handwave at the time. the other thing we've got going on in the
spec is we're kind of like this section is probably not going to survive
standardization…

Manu Sporny: because zcaps aren't standards track and if we try and ref
something that's not standards track they won't let us do that right. we
could say stuff non-normatively in an appendix and get that through there.

Dmitri Zagidulin: Yeah, yeah,…

Dmitri Zagidulin: yeah, yeah, yeah. I was going to say let's get a
non-normative thing going. Maybe the old VPR spec can be that or Appendix
is even better so that people don't have to jump to another page.

Manu Sporny: Yeah, I'd say let's put it in an appendix.

Manu Sporny: Because if we put it in another spec we have to go through the
whole crank turning for that.

Dmitri Zagidulin: Yeah. Yeah. Yeah.

Manu Sporny: We do have something on authorization capability request in
here right now. We could fill this section out more completely and then,
almost inevitably someone's going to object that we can't do this…

Manu Sporny: because we don't have ZCAPS on standards and the plan would…

Dmitri Zagidulin: So I'm happy to volunteer to do a non-normative appendex
a semi-regist All right.

Manu Sporny: then Go ahead. All That sounds good. I guess Dimmitri right
now we don't have to do non-normative appendix right we can just put it in
the spec I'm just warning all of us that it's going to come to a point
where a W3C staff is like you are doing a normative dependency on something
that's not standards track you have to take it out and then at that point
we move it to an appendix and say it's not normative and then we hope that
nobody in the working group objects to even having that in an appendix okay
let's go ahead Dave

Dmitri Zagidulin: Yeah.

Dave Longley: I was going to say that what is in the VPR spec for ZCAP
queries today was matched up against an implementation. And the way that
that implementation responded was with a verifiable presentation request
that had an additional type that allowed you to add ZCAPS to that
verifiable presentation request. this also is related to the issue we have
around sending parameters for unlinkability for BBS schemes there. It's an
open question whether we want to include that information in a verifiable
presentation request of some kind. Whether that is a specifically typed
verifiable presentation request for the specific parameters or whether we
make a VP I might have just said verifiable presentation request.

Dave Longley: meant to say verifiable presentation or if we want to make a
verifiable presentation that allows you to include JSON parameters and then
you could extend it with any kind of JSON for protocol purposes. or if we
want to go outside of the verifiable presentation and include parameters
and Zcaps and whatever else in the VC API channel as separate properties
next to verifiable presentation. there are pros and cons to each one of
these approaches. So, I think when we start documenting what we're doing
with BBS, that might also help inform what we ought to do with ZCAPS.
00:30:00

Manu Sporny: Which means that we might also want to prioritize the BBS
schedule.

Dave Longley: I think I wrote just real quick, I might have written down
some of these options in that issue, the BBS one,…

Manu Sporny: Yeah,…

Dave Longley: if you were to bring it

Manu Sporny: one second. Let me try and find it. This one.

Dave Longley: Yeah. yeah,…

Dave Longley: we had a meeting about it and it looks like if you go above
that, we had a number of options there, pros and cons.

Manu Sporny: Yep. go ahead, Ditri.

Dmitri Zagidulin: So I would so looking at that list of pros and…

Dmitri Zagidulin: cons I would point out that new context is a significant
con and conversely very custom request changes to the VC API, but they're
additive changes. They're not backwards breaking changes. So, in that
regard, it's a very safe change to the API.

Dave Longley: The VC API exchanges allow you to speak any number of
protocols over it. And so whatever we do, if we fit what gets transferred
inside of a verifiable presentation, it can continue to work over any of
those protocols. If you change that, then it will only work with the VC
delivery one. it would not work with OID4 for example. So if you wanted to
pick up ZCAPS through that mechanism that's not something you'd be able to
do. so that's a consideration there or if didcom each one of the protocols
would have to come up with their own way of representing the data…

Dave Longley: if you put it at the protocol layer as opposed to putting in
the data model. As for creating the additional context, this group would do
that. We would make that context and one of the options for how to do that
would be to make it like a JSON extensible presentation, which allows for
more extensibility for this sort of thing.

Dmitri Zagidulin: Can you clarify…

Dmitri Zagidulin: what you mean about protocol layer versus data model? to
me the response is still the data model layer.

Dave Longley: So, should I jump Q?

Manu Sporny: Yep.

Dave Longley: So when you're speaking the VC API delivery protocol for an
exchange, you're posting JSON messages or receiving them that either
include that that include up to they're either empty JSON objects or they
include a verifiable presentation request, a verifiable presentation or
redirect URL and then anything else that's non-standard today. so if we add
other fields to those messages like Zcap for example without thinking about
any other complexities we just add some field called Zcap there that only
works if you're speaking that API delivery protocol if you want to talk to
a VC API exchange and use oid for VP different you use the exchange
endpoint but you're using additional endpoints

Dave Longley: packed onto the end of that an authorization request and an
authorization response and those things can contain a verifiable
presentation which would allow you to transfer through that other protocol.
if you add the Zcap property to just the VC API delivery messages that you
don't get that feature in the other protocols and then you would have to
repeat that effort for every protocol. So whatever DIDCOM does to send
messages around, you now need to find a place to insert Zcaps there as
opposed to saying if you want to ask for Zcap, you can get it in a
verifiable presentation. Here's how you do it.

Manu Sporny: So for those reasons, this one seems like it would throw
ecosystems. it would just be a lot of repeated work for effectively the
same payload. so this feels like I would like to take this option off the
table. it is clean in that it's a separate JSON payload, but it's not super
great if we want verifiable or if we want ZCAPS to be more broadly deployed
than just in the VC API. this one feels like the best option to me right
now. Just put it in a new VP type.
00:35:00

Manu Sporny: But again, if it's a VP, we can just create a new VP type that
encapsulates it.

Manu Sporny: VC and a VP feels a bit like overkill. I feel like people are
going to get confused about a Zcap being a VC.

Dmitri Zagidulin: Yes, we don't want that.

Manu Sporny: And then this whole a VC can be anything and everything
including a ZCAP is just like that again that's confusion there. So it
feels to me like this is our best option. interested to hear others
thoughts on that. Go ahead, Dmitri.

Dmitri Zagidulin: So my main question is that's going to break other
ecosystems as well. At very least it's going to require changes in their
JSON schemas in their validation changes, right?

Dmitri Zagidulin: they're going to need to change their code to support a
new type of VC. This is no different and in some ways worse and more work
than a new field.

Manu Sporny: I don't quite follow that. VPs are very generic objects.

Manu Sporny: Are you saying Yeah,…

Dmitri Zagidulin: They're not though.

Dmitri Zagidulin: The JSON schema from the verifiable credential data model
spec is very tightly like it only says you're allowed to have verifiable
credentials in them and that's it. So those are not generic objects. We've
tightened them down considerably.

Manu Sporny:

Manu Sporny: I mean that's a problem. But I mean then again there anything
that asks for a ZCAP and gets one back is I mean I think it's wrong like we
could I think our position should be the VC data model schema got it wrong
and we lock things down way way more.

Dave Longley: Let's not assume I'm going to go check for a link to that…

Dave Longley: because I remember this coming up in the group and we tried
to make sure it didn't do that.

Manu Sporny: Yeah. I don't know…

Dave Longley: Maybe we failed…

Manu Sporny: if we can reach out. Mhm.

Dave Longley: but we should check

Dmitri Zagidulin: I just want to be careful in comparing those two options.

Dmitri Zagidulin: Making it seem like one is less work than the other.
Code's going to need to be changed in either case. And adding a new field
is always much less code than adding conditional handling of an existing
one.

Dave Longley: you're going to have to add code in one place if you go
through the VP and you'll have to add it in a place for every protocol. So,
O VP if you want things to go OD4 VCI OID4 VP if you want to go in another
direction. The VC API delivery didcom. Anything else that you might want to
transfer a Zcap over,…

Dave Longley: you will need new code as opposed to writing it once for
handling a VP.

Dmitri Zagidulin: My point is existing VP handling code in other protocols
is going to break…

Dmitri Zagidulin: if they receive something other than verifiable
credential. So you're still going to have to do change code on all the
other protocols. Anyways, I'm protesting against the notion that the second
option will involve no code changes or…

Dmitri Zagidulin: even less code changes.

Dave Longley: I don't no I don't think any option would involve no code
changes.

Dave Longley: The goal is to put those code changes in one place in your
verifiable presentation processor as opposed to in your protocol processor.
So on screen, Mono, can you scroll up to what is required in a VP, the
required fields? Yeah, it's not required. I believe we did that correctly
with this use case in mind because verifiable presentations can carry
different kinds of information and we just made sure for them to carry
verifiable credentials.

Dave Longley: But it was always intended that you could present other
things and you could extend the data

Dmitri Zagidulin: I see.

Dmitri Zagidulin: So, I see man is on the queue.

Manu Sporny: Right.

Manu Sporny: But it's wrong, Because we have proof chains in here. I think
right this is wrong in items one of anyway I mean I think …

Dmitri Zagidulin: And people do use the schema across a whole bunch of
languages.

Manu Sporny: if they did actually use the schema it should be fine yeah
okay so I mean it should be fine part of the schema but even if the schema
was wrong I think what we're trying to do is make sure that we're making
the right call long term. even if there's some implementation cost your
point Dmitri like breaking the entire ecosystem over this is not what we
want. but I think in order for the ecosystem to break,…
00:40:00

Manu Sporny: an implementation to break, it would actually have to ask for
a Zcap, which nobody's doing today, …

Dmitri Zagidulin: …

Dmitri Zagidulin: so the point is moot. if we add another field at what
you're calling the protocol level, that's not going to break anything
either because they're not going to be asking for it.

Manu Sporny:

Manu Sporny: but it goes back to the first comment I made, which is we're
trying to do the right thing from an architectural design perspective long
term and the right thing long term is to try and put this in a VP is the
assertion. we'll see if folks agree with that. Go ahead, Nate.

Nate Otto: I think it could be reasonable to do in a VP directly. as
someone who has been, trying to run interference for the stand between the
standards communities and implementers within the open badges space. I
would find that option harder to explain to someone in a VP option which is
more verbose. But the VC is just the object that we are telling everyone
this is the one that you extend.

Nate Otto: And I think that would be an okay start where we could then
follow up in a future edition of the verifiable presentation data model the
inavp directly option.

Manu Sporny: Yeah. my concern on that approach,…

Manu Sporny: Nate, is we'll get stuck in this and people won't upgrade,
meaning the first thing that's successful that gets out there will end up
sticking and we'll have to support it forever and then we won't get to this
thing. but noted the challenge you highlighted I think is fair and…

Manu Sporny: we need to figure out a way to convey communicate this to
folks. go ahead Deitri.

Dmitri Zagidulin: So, I'd be very concerned with VCV…

Dmitri Zagidulin: because we already have way too much confusion and
argument about using If we package a Zcap inside a VC, that's going to add
so much more. I would be very strongly against that.

Manu Sporny: with David Chadwick would love it.

Dmitri Zagidulin: I would be very strongly against that option though.

Manu Sporny: Okay, good input. Nate, what are your concerns around So,
okay, what would this look like? we'd have a VP and then it would be what
in a VP? it would not be a verifiable credential in a VP. would be
something like a ZCAP field in a VP. What would it look like?

Nate Otto: Yeah, that's what I'm hearing from you is that it would look
like a Zcap field in instead of a verifiable credential field. There would
be an additional type a context added so that that field would become
available and then it could be modeled inside issues that you might run
into is that some system that doesn't support this but supports VPs has not
added that context to its list of static contexts and is doing JSON LD
processing on it because it hasn't seen the context and then I think it
just seems to me that this is usually done in a credential and a Zcap being
something that is not a non-private value does not seem terribly dangerous
to put

Nate Otto: inside a credential in sort of a claim that says you have this
Zcap. because if you accidentally expose it somewhere, it doesn't expose
the ability to use the Zcap. and it does seem just like the the more
understood method for giving data to the person about the

Manu Sporny: I guess my concern Nate with put it in a VC is that we have a
group of folks which are different from I think the group of folks that
you're talking about, having an issue with kind of understanding this. We
have another group of folks that are effectively asserting that VCs you
don't need ZCAPS. you should just use VCs to do what Zcaps do. And I think
what some of the community has been pushing back with is VCs are for a
three-party model where you have an issuer or holder verifier. ZCAPS are
for a two-party model. You need to keep those two things very separate from
each other. They each are intended for different purposes.
00:45:00

Manu Sporny: one of them carries claims that the other one is an
authorization capability to prove to the issuer that you have the ability
or have been delegated you have the authority or have been delegated the
authority to do something back at the issuing system so then taking that
and putting it in a VC I think at least my concern and I think this is also
Dimmitri's concern is that people will get confused all over again that VCs
are ZCAPS and they will build systems that effectively use the VC as a Zcap
and then just confusion follows.

Manu Sporny: But I will also admit that we are trying to predict I mean
which is we have to do to try to figure out what the right design here is
but we're trying to predict that there's going to be another horrible
failure with understanding no matter which approach that we take and I
think we're trying to figure out what does the least damage or what's the
easiest to explain is going to go ahead, Nate.

Nate Otto: Yeah. I mean, I see that there are some sort of a thumbs up in
support of that. it does make sense to keep apart the three-party model
from the two-party model use cases. I just think we already have been
trained already to understand that the claims made in a credential are
slightly different than the credential wrapper itself. and so yeah, it is
just kind of an argument of guessing whether other people who aren't us
will have more difficulty understanding option option B. And they're both
kind of complex.

Manu Sporny: Yep. so maybe we can talk about how we would explain this to
people each approach to people. So, the BP directly thing is you can have
something presented to you in a way that the thing that makes it verifiable
is the digital signature on the presentation. it came from a particular
party identified by the effectively the entity that put the proof on the
presentation. So you have been given something you've been presented
something but it could really be It could be a verifiable credential it
could be an authorization capability it could be something else that are
not those two things.

Manu Sporny: And so in this case, you're not being presented a verifiable
credential. You're being presented a capability, and that capability has
instructions on where you use it and how you invoke it and that kind of
stuff. does that feel like a clear enough explanation or what are we
concerned about, I guess, with that explanation? Okay. …

Manu Sporny: go ahead, Nate.

Nate Otto: Just very briefly,…

Nate Otto: I just think the error states are more understandable you
received a presentation that contained a credential we didn't understand.
More likely for them to be able to generate a reasonable error than you
received a presentation that was empty, which would be the behavior if
there was a presentation that contained a property that wasn't understood.

Joe Andrieu: Okay.

Manu Sporny: Go ahead, Dave.

Dave Longley: So, one of the possible ways to design this that was
considered before and is being mentioned in the chat here, which sadly
won't survive the minute, so I'll talk a little bit about it would be for
the new VP type to define a single property called we can come up with a
name for it, but maybe extensions or something like that that takes a JSON
value and then those sorts of errors would there's an extension that we
don't understand. and there would be no additional need to necessarily do
self-describing JSON LD in that field. it would be based on a closer API
interactions and so in where you're doing that presentation is they're
expected to understand that data.

Dave Longley: there's not a third one that's going to be analyzing their
presentation later to try and understand what all that means without the
context of a spec for…

Dave Longley: what was transferred. So, it seems like a sensible place to
put JSON data in a presentation for that purpose.
00:50:00

Manu Sporny: Go ahead, Joe.

Joe Andrieu: …

Joe Andrieu: yeah, I like that. That was not what I got on the cube, but I
like the extensions. I wanted to respond, I think it's less confusing than
you think because the VPR is asking for either a VC or VP. So, I think
there's some context from what was asked for that would help deal with,
wait a minute, I don't see a VC. I didn't ask for V a VCS for a Zcap.

Manu Sporny: I really don't like the extensions route. it feels like why
don't we just call it a data field and just dump whatever we want to in it.
I think it's lazy data modeling.

Dave Longley: To be clear,…

Dmitri Zagidulin: Bammanu a WordPress.

Dave Longley: to be clear, that is what it is. It is a field for you to
dump things. And the data is only useful if you have a spec that the two
parties that are communicating when that's presenting to party B, they have
to have an agreement on the specification that's in use when doing it.
which is how all JSON APIs work. And in this particular use case there does
not seem to be a reason to have a third party come in and understand a
presentation without the context in which it was actually being delivered
in the spec over which it was being used which is where having
self-describing data is very powerful and that does not seem to apply here
in the same way that Zcaps themselves are transferred between two parties
in a two-party system.

Manu Sporny: All right.

Dave Longley: There's no third party involved.

Manu Sporny: I'm glad we all agreed that extensions is the best thing and
best way to go. all right. we are out of time for today. but really
appreciate the discussion. this is very clearly kind of the first time
we've broached a topic but this is the first time we're trying to actually
get to a direction. we've got a lot of everyone made good points today. So
we're going to have to keep struggling through this until we get to
something where we are semi okay with the direction. understanding that of
course we have plenty of time to change the direction and try different
things.

Manu Sporny: okay. That's it for the call this week. please raise some PRs
if you have, some spare cycles. there are plenty of, ready for issues. at
least some of them that are ready for we will come back to this next week
or the other item and keep talking through them until we get to a
resolution where we can raise a PR. okay. That's it for the call today.
Thank you everyone. have a great rest of your week. we will meet again next
week. Take care.
Meeting ended after 00:53:09 👋

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