[MINUTES] VC API 2025-04-01

W3C Community Group Meeting Summary - fuw-kgcv-yar (2025-04-01)

*Topics Covered:*

   1.

   *Pull Request Reviews:*
   - PR 465 (API design guidelines): Merged after minor updates linking to
      the Rispull API webpage and clarifying resource naming.
      - PR 466 (validation guidance): Merged after minor typo correction
      and squashing. A conflict was resolved during merging.
      - PR 472 (removing next step in final workflow step configuration):
      Merged after discussion on implementing a default limit for
workflow steps
      to prevent bugs. The final wording emphasizes that implementations
      *may* set a default limit, rather than a normative requirement. The
      discussion about the limit was moved out of the OAS file.
   2.

   *Selective and Unlinkable Disclosure Discussion:* Focused on identifying
   common use cases for pseudonyms in both credential issuance and
   presentation. The discussion expanded into the complexities of predicate
   proofs, specifically the interaction between BBS signatures, different
   cryptographic suites (including future possibilities like Dan Yamamoto's
   work), and their implications for the VC API and verifiable presentation
   query languages. A key point was the need to cleanly separate data modeling
   from cryptographic implementation details to maintain flexibility and avoid
   redefining processes for every crypto suite. The group also discussed the
   implications for wallet UI design and the derive endpoint in the VC API.
   The group noted that the derive endpoint may need enhancements to
   support predicates across multiple credentials.

*Key Points:*

   - The meeting successfully merged three pull requests related to API
   design guidelines, validation guidance, and workflow configuration.
   - The discussion on selective and unlinkable disclosure highlighted the
   need for a standardized approach to predicate proofs, considering both data
   modeling and cryptographic implementation.
   - Future work involving more advanced cryptographic suites to enable
   more complex predicate proofs was acknowledged.
   - The derive endpoint in the VC API requires further consideration to
   accommodate scenarios involving multiple credentials and predicates.
   - The group agreed to continue this discussion next week.

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

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-04-01.mp4
*fuw-kgcv-yar (2025-04-01 15:00 GMT-4) - Transcript* *Attendees*

Benjamin Young, Dave Longley, Eric Schuh, Joe Andrieu, John's Notetaker,
Kayode Ezike, Manu Sporny, Manu Sporny's Presentation, Michael Burchill,
Naomi Szekeres, Patrick St-Louis, Ted Thibodeau Jr
*Transcript*

Manu Sporny: We'll get started in another two minutes or

Manu Sporny: All right, let's go ahead and get started. Let me get the
agenda up here. on our agenda today, we've got some outstanding PRs along
with the new one, that Cody just raised. we are going to be continuing our
discussion on selective and unlinkable disclosure. Although I don't see
Patrick on the call today. hopefully he can join if someone can ping him.
And then we might be caterizing new issues depending on if we have any
other changes or updates to the agenda? Anything else that we should cover
today?

Manu Sporny: All right. if not, let's go ahead and jump into pull requests.
we have a couple open. let's go ahead and jump into pull request 465.
adding API design guidelines. I think we were waiting on Patrick you to
update this which I think you have done at this point.
00:05:00

Patrick St-Louis: So I updated to link to the Rispull API web page. before
that it was using the web application guidelines. I've also put a note
about the controller resource naming There's some on the resource naming
style of that website. there's some, comment history discussing this,…

Patrick St-Louis: saying it might not be the best thing to do, but I don't
know if you want to put this here. It seems a bit can just get convoluted.
yeah,…

Manu Sporny: Yep. Agreed.

Manu Sporny: I think we can just leave it out for now. I mean, we're not
planning on changing it, right? yeah.

Patrick St-Louis: we can link so this is the page, resource naming style
and they kind of just discuss in the comments about most the biggest
concern they have is that if you're not careful how you design your server
action verb could be interpreted as a identifier for a resource. but I
think that is not the case with the VC API. I think the resource is
actually different on the endpoint that have an action verb after for
example the credentials issue I think when you want to get a credential
with an ID it's a credential singular so there wouldn't be a risk of the
term issue being and…

Manu Sporny: Yeah. In many cases, we use a kind of a random string for the
resources Yep.

Patrick St-Louis: yeah it's the post request as well. So, yeah.

Manu Sporny: Plus one to that. looks good. Thank you very much, Patrick,
for updating that. are there any objections to merge? I think we got Ted.
Okay.

Patrick St-Louis: Yeah, I'm just going to get that in real quick. doesn't
get lines. Thank you very much,…

Patrick St-Louis: I do. H it's outdated. Let me just refer to won't be very
long.

Manu Sporny: All right.

Patrick St-Louis: Yeah, we can come back to it now. We can do the other PR
and the time I'm just going to update this

Manu Sporny: Next PR is PR 466, which adds some validation guidance. this
looks like it's got some of the other PR in it, the design guidelines PR.

Manu Sporny: So, we might want to remove Patrick, I don't know if you can
see this.

Patrick St-Louis: Yeah, let me Okay.

Patrick St-Louis: Yeah, I can do that. I've just updated the other PR so
I've applied the suggestion.

Manu Sporny: Okay. Yeah.

Patrick St-Louis: So the main thing here was to point to specific locations
in the spec that I was referring to.

Manu Sporny: I mean, this looks good to me.

Manu Sporny: Where

Dave Longley: M minor typo on received there.

Dave Longley: Line 1584 at the end. Yep.

Patrick St-Louis: I will update this. What's the line? 19.

Manu Sporny: This one I put in just a change request there.

Manu Sporny: And I'll go back to the other PR and merge that. Okay. maybe

Manu Sporny: Is it okay…

Patrick St-Louis: I should It's okay with me.

Dave Longley: We've also …

Manu Sporny: if I squash for this one?
00:10:00

Dave Longley: go ahead.

Manu Sporny: Is it okay if I squash it, Patrick? Okay.

Patrick St-Louis: And then I'll just rebase the other one.

Manu Sporny: Ted, you had something in here, didn't you?

Ted Thibodeau Jr: Maybe give me a second to put it in chat.

Manu Sporny: Trying to figure out how I can easily get to your GitHub email
and handle. one second.

Manu Sporny: Okay, thanks.

Dave Longley: While we wait for that, there's a question in chat about
whether the meeting URL for this call changes each week or…

Manu Sporny: No, same should be the same.

Dave Longley: if it's the same. Okay.

Ted Thibodeau Jr: It uses full name.

Patrick St-Louis: Yeah, I also add another URL.

Patrick St-Louis: Are we sure it doesn't

Manu Sporny: One second. I know I've got multiple from Ted here. that's the
assigne. any random? no. That probably won't do it.

Manu Sporny: Come on, GitHub. I think that one definitely. Yep, there it
is. And then …

Dave Longley: Ed put something in the chat so you can stop searching.

Manu Sporny: we go. All right, that's that one. Thank you, Patrick. And
then next one is add validation guidance. this is still in here.

Patrick St-Louis: Yeah, I'm just going to take care of it.

Patrick St-Louis: I'm having a look right now. Should be long. This Okay.
How does it look now? If you refresh

Manu Sporny: There we go.

Manu Sporny: That's good. Okay, this one looks good to me. Any objections
on merging this? I'll do a squash on this one,…

Manu Sporny: too. Conflict. no. Yeah, it's not happy.

Patrick St-Louis: It's not happy.

Patrick St-Louis: right. I will

Patrick St-Louis: Should be good.

Patrick St-Louis: Just going to make sure I didn't Yeah, I think it looks
good.

Manu Sporny: Whoops. This removed the design guidelines completely.

Manu Sporny: You see this one, Patrick? definitely don't want that. I'm
going to go to the other one we just closed and…

Patrick St-Louis: Yeah. No,…

Patrick St-Louis: that's not what we

Manu Sporny: close out that issue. Wait, what is going on here? Why is the …

Patrick St-Louis: This is Okay.
00:15:00

Manu Sporny: that's right.

Manu Sporny: this one.

Patrick St-Louis: Is it happy? No. Sign guidelines looks correct to me.

Manu Sporny: need to push. No, it still looks like it's Go on.

Manu Sporny: Did you push up?

Patrick St-Louis: Yeah. Wait,…

Patrick St-Louis: there's something wrong here. Yeah.

Manu Sporny: Okay, we'll come back to this. We've got Coyote's one to Let
us know when you want us still to take a look at that again. Coyote, do you
want to take us through this PR?

Kayode Ezike: Yeah, relatively simple just to remove next step in the final
workflow step configuration. I think the only thing is a question about how
many steps we should limit or we should recommend that users limit their
workflows to I think also Ted has a comment. Okay, try put 10,…

Manu Sporny: That's a good question. Should we provide any limit? yeah.

Kayode Ezike: but not sure how people feel about that.

Manu Sporny: I mean, it feels like any number we pick is going to be
somewhat arbitrary. go ahead, Dave. Okay.

Dave Longley: We can just say that software should configure a default
limit that can be overridden by configuration for more complex flows.

Manu Sporny: This is PR 472. I forgot to mention that.

Manu Sporny: would there be any objections to that? Meaning software should
provide a default limit I guess. What does that do?

Dave Longley: I mean, the threat here is that someone would create a
workflow that could run infinitely and really I think that's just going to
be a point of frustration for users. this is really about detecting
misconfigured software. I don't know that. I'm trying to think of whether
there's some adversarial problem to consider or whether it's just an
annoyance that you would want to catch and not accidentally implement a
flow where the user of an exchange could get caught in a loop and not be
able to escape it.

Dave Longley: And all that would happen is they would stop using the
exchange and leave or…

Dave Longley: maybe complain and say they can't present a credential or
something like that. This is really just about detecting problems in
software I would think.

Manu Sporny: Yeah. …

Manu Sporny: what do we So, so the one concern I have is, the word
recommend is a special word. it means should. and we should probably avoid
doing that because then that creates a normative requirement like we're
saying, normatively you shouldn't do more than 10.

Manu Sporny: Go ahead, Dave.

Dave Longley: Why don't we just say implementations can set a default limit
to help detect bugs?
00:20:00

Dave Longley: We want a different word there. I don't even know that we
have to put a number in there.

Manu Sporny: Yeah. meaning there's default limit for the number of steps
and…

Manu Sporny: then can you loop do we because you can put next step is one
here right?

Dave Longley: You could loop.

Dave Longley: Yep. You could loop…

Manu Sporny: Yeah. All right.

Dave Longley: but you can't have a direct cycle of steps. But it would be
possible to have a loop. I think we say elsewhere you can't directly go
back to the same step, but you could go through some other cycle of steps.
and any software that's trying to detect too many steps, I think would also
count that. this doesn't seem to be a point of interoperability. So I don't
know how much we really need to say other than it's a consideration that an
implementation might want to have a default maximum number of steps to help
prevent bugs and…

Dave Longley: workflows or something. Yeah,…

Manu Sporny: Yeah. And I think…

Manu Sporny: then that means this goes into a security consideration
section, not necessarily, in the OAS Meaning you need Okay.

Dave Longley: I don't even think it's a security consideration. It's just
some kind of consideration. It's a user experience consideration.

Manu Sporny: So do we want to just leave it at passing the next step is
optional?

Manu Sporny: This field it must not be present for the final step right and…

Dave Longley:

Dave Longley: Yeah, that's correct. That seems right to Hey.

Manu Sporny: then for this maybe we delete the sentence and then put the
consideration elsewhere in the spec not necessarily in the OAS file since
it doesn't have any okay coyote thoughts on doing Yeah.

Kayode Ezike: Yeah, that sounds good to me. I mean, I put a candidate text
in. So, basically, hold on one second. Basically, the while there's no text
limitation on number set workflow, implementers may want to use a default
max number of steps to prevent bugs, something simple like that maybe.

Manu Sporny: And that just goes here, right? Okay.

Kayode Ezike: Yeah, exactly.

Manu Sporny: All right.

Kayode Ezike: I can do that.

Manu Sporny: So the.

Manu Sporny: I don't know.

Manu Sporny: Are you changing this real time and we can take a look or do
you want to do it offline? Okay.

Kayode Ezike: Yeah, I was about to hold on.

Kayode Ezike: Sorry, Dave. You said change made to Is that correct? Yeah.
32 places.

Ted Thibodeau Jr: And that should be limitation on or…

Manu Sporny: Okay.

Ted Thibodeau Jr: limit two. Either one works, but limitation two is not so
flowy.

Kayode Ezike: So it should be up there now.

Kayode Ezike: Okay. Don't f* s*** just say

Manu Sporny: So this is duplicating it.

Manu Sporny: I think coyote we remove it from here. yeah, because this is
in the OAS file and it'll show up in the documentation there. Meaning The
exact same wording will show up twice in the spec if we keep it in here.

Manu Sporny: So I think for this one at the top we just want this text
passing next step is optional. This field and then must not be present on
the final step configuration. So we need to change that should not to a
capital mus not and…

Kayode Ezike: Okay. Yeah.

Manu Sporny: then delete the last sentence there in the oas file and then
you keep the rest of it the same.
00:25:00

Manu Sporny: might think. there's no title.

Kayode Ezike: And for the should I keep the not capitalized? No. Great.

Manu Sporny: Yes, hold on. The should change to a must not. And the word
must and not are both capitalized per the RFC language.

Kayode Ezike: And then nothing changes in the main index file, right? I
missed something.

Manu Sporny: Yeah, I think so. there's no

Kayode Ezike: Look at that. Should be up there now.

Manu Sporny: Yeah. Hey.

Kayode Ezike: Go ahead.

Manu Sporny: then I think maybe we change this to maximum number of stuff
bugs.

Manu Sporny: no. Unless you already committed that. That looks good to Any
objections for merging All right, then. Going to squash this one too
because it's okay. That and then I know let's just do one character change.

Manu Sporny: All right,'s that one. And says PR exists and PR 472. Okay,
that's that one. Thank you very much Coyote for raising that PR. All right,
got a bunch merged. we got this other validation guidance one. there we go.
That looks clean. all right. And then add validation guidance then. Oops.

Manu Sporny: ops. All right. I think that one's done. 379. access. Okay.

Manu Sporny: Okay, I think that that deals with that one. All right. That's
good. We are down to no open PRs. We got rid of three issues. Hooray. All
right. let's see. I think We've covered all the issues and they're all kind
of ready for PR. we could try looking at some of our unlabeled issues, the
old ones, to see if we can actually address any of these. We were talking
about the pseudonyms thing last time, right? so let's go ahead and start.
00:30:00

Manu Sporny: Let's go ahead and pick up where we left off last week where I
totally forget. We were trying to highlight the most common use cases for
pseudonyms both during issuance and during presentation. so for the most
common use case for issuance we wanted a BBS credential that includes a
pseudonym with no special fields being the default behavior.

Manu Sporny: other use cases include including let's see what is it one of
them is the issuer per issuer linkability and the other one was blind
signing right for the issuer were there other use cases that we could think
of for pseudonyms And for all the BBS features base signing, blind signing
and pseudonyms. So I think maybe we have that. And then the most common use
case for presentation is where the holder provides the BBS credential.

Manu Sporny: where the pseudonym is a perverifier pseudonym. what other use
cases are there for presentation other than that one?

Manu Sporny: Go ahead Joe.

Joe Andrieu: Yeah,…

Joe Andrieu: it's not a use case for synonyms, but it is a use case for
BBS, which is the ZK Snarks predicate stuff. I don't know if we want to
talk about that here or…

Manu Sporny: Yeah.

Joe Andrieu: in another place, but it's pretty powerful.

Manu Sporny: So I think BBS doesn't support predicates.

Manu Sporny: The one that's going through ID ITF unless I'm
misunderstanding something.

Joe Andrieu: Is it divergent from…

Joe Andrieu: what Danny Yamamoto demoed at IW where he used CK Snarks on
top of BBS?

Manu Sporny: I think so yeah what's the scope of this discussion?

Manu Sporny: is the scope of the discussion what we can currently do with
BBS or what we could potentially do in the future…

Manu Sporny: because I think Danielle Mamoto's work is maybe what we could
do in the future That's very interesting.

Joe Andrieu: My understanding the reason I was so turned on by it and…

Joe Andrieu: why I'm mentioning it now is because my understanding was the
crypto suite was straight BBS and the predicate was a negotiation between
the holder and the verifier. So you could issue a standard BBS credential
and at a separate point in the process late bind the predicates that are
used on it.

Manu Sporny: I didn't know about that. That's interesting. Dave

Dave Longley: There's some additional complexities there. certainly with
the 2023 BBS crypto suite, you could do predicates across entire end quads.
Daniel Mamoto's work further breaks the nquads down into their subject,
predicate, object, graph components, and then you can do predicates for
each one of those individual pieces. But that requires an additional crypto
suite. and the proof sizes are larger. If that becomes a crypto suite, BBS
2025 or whatever, where you have these larger proofs but allow you to do
these more complex predicates, then you can do all the things Joe just said.

Dave Longley: But on top of that, I would expect for that to get through
the W3C process, you would need something down at the IETF layer that shows
you how to specifically do those additional proofs. so there's standards
layers and stuff to sort of get through to get to that place. so those
things are technically possible. It's future work that is of interest,…

Joe Andrieu: That does align with my understanding.

Dave Longley: but there's some standards hoop jumping that has to happen to
get us there. And so it's sort of like on the road map.

Joe Andrieu: The BBS on its own doesn't do it, but if you have it, then we
can standardize the rest of this later.

Manu Sporny: So that mean do we need to change this at all for issuance?

Joe Andrieu: I
00:35:00

Manu Sporny: It's typically the issuer gives you the ability to predicate
presentations. I think is that accurate? the issuer has to set that up for
you. Go ahead, Dave.

Dave Longley: No. I think the issuer just has to pick the crypto suite. If
they picked a crypto suite that caused your BBS signature to the way that
the BBS signature was generated to make each individual component of a quad
its own scaler, then you can do predicate proofs across each one of them.
but all that being said, at the VC API layer, I think what we're interested
in is if we can do all these things, where do the little primitives and
bits go so that it can happen using VC API? and some of this is also just
around verifiable presentation s. how would you say please prove to me
these different predicates?

Dave Longley: This combination of

Joe Andrieu: Yeah, that is my understanding as well.

Joe Andrieu: Sorry, is there a queue? I'm jumping. Thanks,

Manu Sporny: Yeah, Patrick's on it.

Manu Sporny: And then you're after.

Manu Sporny: Go ahead, Patrick.

Patrick St-Louis: Yeah. …

Patrick St-Louis: I think and I think I briefly talked about it. So, I
think any predicate could be represented as a statement which is a new
element that could be part of the presentation query language. So it could
be a new type of specifically designed for signatures and…

Joe Andrieu: Thank you.

Patrick St-Louis: statements specifically designed for maybe not limited to
BBS but for advanced features that would be difficult to convey with a
query by example. at least that's what I could think.

Patrick St-Louis: I don't know exactly when you say predicate I'm not sure
what it encloses when I think of predicate it's usually larger or smaller
than it's comparing n figures I don't know if predicate has a larger term
than that but this would require in the first place the actual value from
the claim of the predicate to be a valid integer whether it's a integer as
a string or an integer but it needs to be able to be evaluated as an
integer. so yeah, I would say probably a way to request statements from a
presentation like can you meet this statement?

Manu Sporny: So there are two things that sorry Joe, you're next.

Joe Andrieu: yeah I think that is the right boundary of…

Joe Andrieu: where we standardize my understanding with Dan's work was the
predicate is the negotiation between the verifier and the holder and they
need to have a third party standard that they are both referring to. It
could be a first party standard in the Facebook style, but basically
they're the ones who are agreeing on the algorithm that is applied to the
message structure. And so the language by which you would request a
particular proof would have to ask for that predicate. And that's the part
we haven't standardized yet.

Manu Sporny: Right. …

Manu Sporny: go ahead. Go ahead, Patrick.

Patrick St-Louis: I would say this could be done with a cryp …

Patrick St-Louis: if we're talking here about data integrity like a cry a
cryptosweet specification should convey enough information about how to
answer to a predicate or at least what a verifier would be expected. So in
the same way that in a query by example I think you can limit to certain
specific crypto suites like the crypto suite you accept and the crypto
suite should be responsible for defining the cryptographic way of how
you're going to meet this predicate because a predicate in itself is just
do you meet this statement that I'm asking for and then how you will prove
that it's been mentioned

Patrick St-Louis: both the verifier and the holder needs to agree on how
this is going to be done. But I think this is very similar to a verifier
and a holder need to agree on what o e to use. what crypto suite will the
verifier be able to verify and what can the holder produce in the case of a
derived credential if they use E ECDSA based S is with selective disclosure
or BBS. So I think that that could convey this negotiation.

Manu Sporny: Yep. Go ahead, Joe. What are you
00:40:00

Joe Andrieu: I agree with your intuition,…

Joe Andrieu: but I think it's not quite on here in that what The predicate
space is not really the crypto suite space, but our intuition is It is
about specifying what kind of crypto is okay for both parties. But that's
what I was so excited about Dan's work is that if you use the BBS structure
that allows you to have these different messages that are signed, then you
can have predicates over those messages which the issuer was not involved
with. So, you don't need the California DMV to specifically define an over
18 and over 21 and over 65 and over whatever age predicate. You can just
have a recognized date of birth field and a predicate that knows how to
calculate that you're over a particular age.

Joe Andrieu: And as long as you have that predicate standardized, then the
verifier can present to a holder who understands that just the derived
proof.

Patrick St-Louis: Yes, that's the second example you mentioned is aligning
with what I'm trying to explain. I don't like for me a predicate is not
just a boolean field in a credential that says over 18 or under 19. That's
just revealing an attribute. For me, a predicate is you have a value and
you will ask a cryptographic mathematical operation based on that value.
that's going to result in a true or false is it higher and lower. So the
verifier provides a value to compare with that value and…

Joe Andrieu: Agreed.

Patrick St-Louis: there's a operation between both values that succeed or
doesn't succeed.

Dave Longley: So I think all that's true but there's two different layers
we want to consider here. One is the data modeling layer how this would be
expressed and the other is the cryptographic layer that would prove that
expression was valid could be verified. And if we don't have a clean
separation there then you're going to what would end up happening is a
redefinition of all of this stuff for every different type of crypto there
was. And we want to make sure that we keep those things separate so that we
can have a data model that expresses the information appropriately. And
that then you would just announce these are the cryptographic suites I
would understand as a verifier and the holder has to pick one of those to
express the information and provide their proof that information is
actually attested by the issuer.

Patrick St-Louis: Yeah, I think let's take a simple example of a predicate
that there's a field in a credential that's an integer. It could represent
a date of birth or anything in my mind a way to represent that predicate
you you need to identify which claim you're talking about from which
credential and then you want to give either a maximum or minimum value or
both together or whichever. and the way you answer this,…

Patrick St-Louis: then you define that with a specific crypto suite.

Manu Sporny: All right.

Manu Sporny: I don't know so I haven't been writing anything down because I
don't necessarily know exactly what I can add to other use cases for the
presentation. So bringing us kind of back to we're trying to identify use
cases the main use case for issuance the main use case for presentation and
then sub use cases for issuance and sub use cases for presentation I think
we're saying this stuff is largely in the use cases around presentation
bucket and there are considerations for both the presentation

Manu Sporny: request query language and their considerations for the VC API
for constructing the presentation. did I miss anything?

Manu Sporny: Go ahead Dave arrive.

Dave Longley: I was going to say I'm not sure…

Dave Longley: what the VC API would need to do other than transport the
query language and transport a verifiable presentation back if it's having
to do more than that for the presentation. the VC API doesn't do
derivation. Crypto suites do that. Those provide those functions. if you
think of the BBS crypto suite provides the derivation mechanism.
00:45:00

Manu Sporny: But we have an end point.

Dave Longley: Okay, I see what you're saying. yeah, I guess the only part
that would be relevant here would be the holder endpoints if you're
implementing like a cloud-based derivation mechanism.

Dave Longley: So this would be about saying what you want to be derived by
hitting those endpoints. And I think that's it. I was conflating the
presentation part with what would need to go into an exchange for VC API,
but I don't think you would need to do anything at that layer.

Manu Sporny: Yeah. …

Manu Sporny: real quick, let me just check. credentials derive.

Manu Sporny: What do we do here?

Patrick St-Louis: I think this derive should probably be reviewed.

Patrick St-Louis: I don't think that this matches what we're talking about
because when you receive a presentation request, there is a bit of a
credential selection step that's going to happen. you would likely need to
query your wallet to say first of all which credential I have from I can
satisfy this presentation request as the derive endpoint and the VC API
specification takes an already selected verifiable credential and then in
the example there gives selective pointers but I'm assuming a combination
of an array of credentials and a presentation request

Patrick St-Louis: and then as a response you get the presentation. so it
seems like the derive endpoint here happens after the sort of credential
selection. so it's not an endpoint that you would give the presentation
request on itself and then you get a presentation. You would give the array
of credential the ids of the credential you've selected. and then you get
and the presentation request but I think it's important to support when a
presentation request is going to ask predicates across different
credentials.

Manu Sporny: All right.

Patrick St-Louis: I don't think it's always going to be all against one
credentials which is what the derive endpoint currently seems to assume.

Manu Sporny: Okay. Joe, you're next and then Dave.

Joe Andrieu: So I've been working through this question so I think I might
know the answer…

Joe Andrieu: but my understanding is the way that folks are talking about
predicate proofs and crypto suites there isn't an appetite to treat BBS as
a crypto suite and predicate proofs as a separate layer. So if I want to
add predicate proofs in the way that Danny Amamoto was doing with BBS, I
would have to define a new crypto suite that has BBS for its signing
mechanism but has this other derived predicate mechanism. Is that the
architecture that we're talking about?

Manu Sporny: Yes, I believe so.

Manu Sporny: The canonicalization step matters there. go ahead, Dave.

Joe Andrieu: Okay.

Dave Longley: I'll try to come back to and…

Dave Longley: say something about what you just asked, Joe. I got on the
queue to say I wanted to this to sort of speak to the awkwardness of
building a wallet UI with a se with a selection around that that would have
selection in the way that Patrick was describing. I don't think that you
would choose a credential before doing derivation. So we need to be a
little bit careful about how that language would work. I would expect users
to want to make their selection after they see what's been derived. So it's
very clear to them what would be revealed.

Dave Longley: And so I would ex and maybe the word choose when Patrick was
using it when you were using it there you didn't mean that there was
necessarily a user interaction there but it seems like there's a matching
phase and then there's a derivation phase and then there is user review and
selection of what would be consented to share and so I would expect a piece
of software that's using the VC API to do derivation would first do some
matching then it would call the derived endpoint on all of the potential
matches that the wallet has decided the user would be interested in and
then present those derived credentials as options to the user in a UI.

Dave Longley: I go going back to what Joe was saying. in order, so you
could do predicatebased proofs on BBS 2023, but only over entire quads. So
you could prove that an entire quad was this and do some potentially
interesting proofs with that. because the entire quad is what maps to this
integer thing that Patrick's talking about, maps to a scaler. If you want
to get and that means that the proof size is linearly related to the number
of quads in your VC. If you want to do what Dan Yamamoto is doing, then you
have to go a little bit more atomic than that and break up the quad
statements into their individual pieces.
00:50:00

Dave Longley: And then you have an individual scaler so quad each one
individually maps to its own integer through something called a hash to
curve function. each one of those becomes its own value that you can make
statements about and that's why when Monu said the canonicalization matters
when you canonicalize and then you decide how to break your whole VC up
into individual pieces. Daniel Mamoto's work is breaking it up into even
smaller pieces so that you can make individual claims about stuff.

Dave Longley: And so the BBS signature would have to change for that. Now
you would only have to make that crypto suit once to have this other kind
of BBS this other to support all these predicates. You would have to do
this once because to express breaking it all up like that with the
trade-off of larger proofs,…

Dave Longley: but then it would give you all these properties. So you do
need to have this other crypto suite to do those more complex proofs.
Hopefully that all made sense.

Joe Andrieu: But for the simple ones,…

Joe Andrieu: we are also arguing that even if the VC uses a crypto suite
for a generic BBS with the whole quad, then you might have another crypto
suite that the present ation is signed with that is using the crypto suite
for a derived predicate operating over that VC. So the issuer still never
sees the predicates and they don't need to for example I'm comfortable
working at the quad level with my predicate right.

Dave Longley: Yeah, the issuer doesn't need to be involved in any of this.

Dave Longley: I don't think the only way the issuer needs to be involved is
in how they select the crypto suite. And then based on the crypto suite
that's selected, then that informs how complex your proofs can be.

Manu Sporny: Doesn't sure.

Joe Andrieu: Yeah, that makes sense to me.

Manu Sporny: Go ahead, Patrick.

Patrick St-Louis: Yeah so when I think about the derive step from my
understanding is you take a credential or more that the holder has that is
private to the user and you derive another credential that is like a change
version of it containing the information you want to share with a verifier.
So the input is private and the output is something you're going to include
in a presentation. the reason I don't think a sending a credential and some
option is sufficient is for a case like a predicate which is equality of
two claims across two different credentials you would surely need to input
both of these credential to derive your proof out of that whatever that
proof might look like.

Patrick St-Louis: this is why I think the derive endpoint keeping in mind
that all this would happen through a workflow. It would be like a
multi-step thing. If we agree that when you call a derive endpoint like the
derive action you have previously selected which credentials you're going
to use to meet this predicate with whatever restrictions the verifier is
using. you can maybe restrict on a specific well-known credential, a
driver's license or I don't know. And then you would look if you have this
or from a specific issuer. And then once you got this package of all your
credential bundle that can output one or more proof that's going to meet
the predicate bundle, you feed that to your derived endpoint and then you
get something that you can fit in a presentation.

Patrick St-Louis: And I'm not sure what that's something looks like exactly
because I think with sector disclosure and BBS gets a bit muddy the
credentials and presentations.

Manu Sporny: Go ahead, Dave.

Dave Longley: Yeah, and I agree pretty much with most of that in that the
derive endpoint is going to need more information than just a credential.
but my point is that you're probably going for any given interaction with a
verifier, it seems likely to me that there might be many different calls to
derive that need to happen to or maybe not many, but there might be several
different options that could be presented to the user and each one of those
is going to be a possible derivation. So a call to the drive API you might
say there are three or four different ways we could combine all the
credentials that you have to meet this request.
00:55:00

Dave Longley: We will call derive four or…

Dave Longley: five times and then present those bundles to the user and say
which one do you want do you want to use and which one you want to give to
the verifier.

Patrick St-Louis: possibly. I think this could be maybe sort of broken down
by…

Patrick St-Louis: how many queries are in the presentation request. each
query would require one derive call. maybe it needs to be broken down more
than this but at least that's how I would see it that it makes sense and
you sort of take the query make your selection and then feed that selection
and the query itself to the derive endpoint and then behind the scene it's
going to use instantiate whatever crypto suite is being requested or used
and then you get something back that you can fit in a presentation. Sure.

Manu Sporny: All right. noting that we're out of time.

Dave Longley: Yeah, just real quick I wanted to say I think it'll be more
complex than a single A query might ask for I want show me some set of
skills you You might have 10 different credentials that could fulfill that
query and then you want to combine that with a proof on something else. So
that I would expect possibly many different combinations.

Manu Sporny: All with that, thank you for the, in-depth discussion. we'll
come back to this next week to see if there are any other use cases that we
can think of, but we got, at least one, good new one down. thank you, Joe,
and for the discussion, Patrick and, thank you also to, Coyote and Patrick
for the PRs today. if you have the band this is to everyone. If anyone has
the bandwidth please raise more PRs so that we can review next week. we
will meet again next week and continue going through PRs and issues. Thanks
everyone. Have a good one. Ciao.
Meeting ended after 00:57:46 👋

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