[MINUTES] VC API 2025-03-25

VC API Community Group Meeting Summary - March 25, 2025

*Topics Covered:*

   - *Agenda Review and Announcements:* Standard agenda followed. W3C
   members reminded to vote on Verifiable Credential 20 specifications.
   - *Community Updates:* No significant updates.
   - *Pull Request Review:* Pull requests #461 (fixes to OAS files for
   media type changes related to credential and presentation verification) and
   #465 (API design guidelines) and #463 (validation guidance) were reviewed.
   PR #461 was merged. PR #465 and #463 require further updates.
   - *VC API Issues:* Discussion focused primarily on issue #396 (Adding
   support for advanced BBS features like pseudonyms).

*Key Points:*

   - *BBS Feature Support:* Significant discussion revolved around adding
   support for advanced BBS features (pseudonyms, commitments, range proofs,
   verifiable encryption). The group debated the optimal approach for
   integrating these features into the existing VC API exchange framework,
   considering both ease of implementation and broader ecosystem reusability.
   - *Design Considerations:* The group explored different approaches for
   handling commitment requests in BBS credential issuance, considering
   whether to add new endpoints or integrate them into existing ones. A
   consensus emerged that handling commitment requests via holder services
   (rather than directly within the exchange) is a viable approach, but
   warrants a separate issue for further discussion.
   - *Presentation Request Enhancements:* The need for enhancements to
   presentation requests to handle advanced BBS features and accommodate
   various pseudonym revelation scenarios was highlighted. Suggestions
   included adding a new query type or specifying default behavior with
   options for customization.
   - *Verifiable Encryption vs. Pseudonyms:* The relationship between
   verifiable encryption and pseudonyms in the context of BBS was clarified..
   The group determined that verifiable encryption can be used to enhance
   pseudonym functionality but is not strictly necessary for all use cases.
   Several example use cases (credit card processing, proof of existence) were
   discussed to illustrate different scenarios. The group concluded that many
   use cases for verifiable encryption could be more easily solved with
   simpler encryption techniques, suggesting it is often unnecessary for the
   use cases described. A potential exception is when an issuer needs to
   verify the integrity of a value without being able to access its content..
   - *Action Items:* The group decided to break down issue #396 into
   smaller, more manageable issues focusing on issuance and presentation use
   cases, categorizing them by common and less common scenarios. The need for
   more PRs to move the VC API spec forward was emphasized.

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

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

Benjamin Young, Dave Longley, James Easter, John's Notetaker, Kayode Ezike,
Manu Sporny, Manu Sporny's Presentation, Patrick St-Louis, Ted Thibodeau Jr
*Transcript* 00:05:00

Manu Sporny: All right, welcome everyone. I'm going to go ahead and start
the call. I saw some people in some of the other channels and of course
this happens when you change your meeting location that's been stable for a
long while. but I've told some people to move over here, but I don't know
if they got the message or not. but let's go ahead and get started. welcome
to the verifiable credential API call. this is, March 25th, 2025.

Manu Sporny: we have our standard agenda today which is just agenda review
announcements community updates issue processing and that's pretty much it.
are there any other updates or changes to the agenda today? Anything else
folks would like to talk about? If not, I'll go ahead and go into kind of
community anything of notes since last week, any community updates? All
right.

Manu Sporny: If there are no community updates, a reminder, just to those
of you that are W3C members, that the voting is open for the verifiable
credential 20 specifications. if you haven't voted already, please do so. I
am trying to find the link to that. but I'm probably not going to be able
to find the link to that quickly. so it should show up in your voting
roster. Maybe I do know where it is. One second. let me find it.

Manu Sporny: Okay, I think it's here in unfortunately, chat is not saved as
a part of the new meeting infrastructure. So, the link's there. if you all
want to pass it on to people that of that, could vote, please, do so.
anything else, community updates before we move on? Okay, let's go over
pull requests.

Manu Sporny: I think the only pull requests that we have open are these
ones. Let me go ahead and share. and they're the same ones that have been
open for a while. Let me see if we've got the ability to merge any of
envelope credentials and presentations. John made these changes. It looks
like he added some fixes to the OAS files. I think they were media type
changes we needed. Is that correct?

Manu Sporny: ref these ones.

Dave Longley: Yeah, I'm just taking a look
00:10:00

Dave Longley: Yeah, I think the previous changes were making it so you
could set a different media type on the post body. And it looks like that
has been addressed because all of the requests now look like they're JSON
and they have options and the other thing. I'm Yeah,…

Dave Longley:

Manu Sporny: Yeah. Yep.

Manu Sporny: Yeah. I think everything's been put back to…

Dave Longley: I'm just trying to make sure…

Manu Sporny: what it needed to be.

Dave Longley: what endpoints are these for?

Manu Sporny: So this is to credentials verify.

Dave Longley: Yeah, that looks good. That makes sense. And then what does
the presentations verify, I guess. Okay.

Manu Sporny: Yep. Enveloped.

Manu Sporny: And then these are just the compnts. envelope presentation.
Yep, this looks All right. Hooray. we're good there. And then we can rebase
and merge this. And then we can go.

Manu Sporny: Is this a partial 424 breed? So these are all as envelope
things though. What's this thing?

Dave Longley: Yeah, that's confusing. because you wouldn't send it in raw
form. it says inbody and…

Dave Longley: yeah, You would set the enveloped presentation and you
wouldn't send the jaw directly.

Manu Sporny: Yeah. Yeah.

Dave Longley: So, I think what the PR did is what we want. But that comment
seems incorrect.

Manu Sporny: I think we just mark this as done. right because you can
verify based VCs and regular VCs using this PR 461 as okay.

Manu Sporny: So PR461 has addressed issue 424 which is clarifying how
envelope verifiable credentials and based VCs can be verified. Okay, so
that is done and closed array. All right, next item up is API design
guidelines from Patrick

Manu Sporny: Just in time,…

Manu Sporny: We're reviewing your PR for 3:43. Yep.

Patrick St-Louis: All right.

Patrick St-Louis: It still needs update. yeah, I've been having a hard time
finding time for a few things to finish this week. I think it's just a
matter of, not much work need to be done. It's just a matter of changing
the terms. I think mostly around the design principles. Yes, this

Manu Sporny: Okay, sounds good. So that's PR465 add API design guidelines
needs some updates and I presume same thing for the other one attrib add
validation guidance needs some links put in it in kind of different ways.
Okay. All right. So those are those ones.

Manu Sporny: all right. let's go ahead and switch over to VC API issues.
and I think let's see, do we have any that are not ready for Allow generic
unwrapped VCVP and specific media types Where are these?
00:15:00

Manu Sporny: These are all from Go ahead, Patrick. Okay.

Patrick St-Louis: I'd be interested in having a look at the BBS future.
This seems relevant to things that are happening. maybe they've always been
happening, but the things have been in my attention recently.

Manu Sporny: So, this is issue 396. Add support for advanced BBS features
like pseudonyms. I think you've been doing some work on the noncreds in
this area, Patrick, and I think go ahead. …

Manu Sporny: let's Yeah, go ahead, Dave. I think we've done some work here.

Dave Longley: Yeah, we've been doing some work.

Dave Longley: We don't have anything finalized on our end or that's ready
really for the group. I dumped just some quick notes into chat here that
won't get saved. but effectively we need to figure out where we want to
express things that certain crypto suites might need. and we have a number
of different options for where to put that stuff. So BBS is sort of the
first use case for that where we would want some interoperability around it
and the type of thing that you need to send to make to put a BBS credential
on something is a commitment to some values.

Dave Longley: And so prior to issuance, the issuer would send a request for
some kind of commitment and the holder that will be receiving the
credential would provide that commit commitment and then that gets fed into
the issuance process. And so there are a number of places we could put
things like commitments. we could have the holder send. So the framing
around all this is the current things that you can send in a VC API
exchange are a verifiable presentation request, redirect or a redirect and
so either we're going to find a place to put this new information into one
of those fields or we're going to have a new field.

Dave Longley: And there are pros and cons to those approaches. If we put
this kind of information into one of those existing fields, then whatever
we do could be reused across a variety of different protocols and other
places. It wouldn't have to be VCA API specific. but it takes a little bit
more work to do that and to get it right and to have it all sort of
semantically hold together. for less work but less reusability outside of
VC API, we could just drop this anywhere into VC API and say this is where
you put it when you're using VC API. that has the advantages of us being
able to do it quickly, but sort of we're not thinking about the wider
ecosystem and reuse. …

Dave Longley: and we're just designing for our specific case. And that's
not usually the best way to go.

Manu Sporny: got it.

Manu Sporny: Go ahead. Patrick

Patrick St-Louis: Yeah. …

Patrick St-Louis: this is super relevant to so I gave a presentation this
morning with Stephen about BBS and unknown creds and I've been working on
this little API. I've been trying to keep it separate endpoints to the BC
API, but I'd like to get it as close as possible. And this sort of
commitment requirement is something I remember I brought up a while back
when I was trying to look at anon creds issuing that there was a step
missing in which the holder kind of needs to request the credential and
include that and the issuer then needs to sort of include basically this
blind claim it needs to sign this blind commitment.

Patrick St-Louis: the way I landed on in this sort of API presentation is
there's a credentials request endpoint in which the holder would provide
the holder needs to create a proof of their commitment and then that
request proof of commitment then is passed at the issue point and the
options as a request proof which is sort
00:20:00

Patrick St-Louis: just a encoded version of that proof and I don't know
about other crypto suite but what is in that request is every claim that is
blinded so every blind claims that the issuer won't know the value but the
issuer will kind of sign the holders sorry I got a blank commitment towards
the content

Patrick St-Louis: % of the request proof I'm assuming would depend on each
crypto suite I would know what to do with that request proof if I'm using
the anon BBS crypto suite for example so this would tie in the fact that
the issuer would know what to do with that request proof which is just a
string that has all the thing needed encoded to be able to successfully
issue a credential

Dave Longley: So my issue with some of the elements of that design is that
I don't see how it slots into the exchange framework that we have and the
exchange protocol we have. It sounds like it's going outside of that to
some other endpoint to do something new and then you don't get any of the
benefits that we have built around the exchange process where Go ahead.

Patrick St-Louis: Yeah,…

Patrick St-Louis: there could be an exchange about it, but The same way
that during an exchange you can call the credentials issue endpoint right
the issuer can call that endpoint these endpoints are just exposed to it's
really the request endpoint right that's like the new component but these
endpoints could be called during an exchange right they would hold the same
kind of u trust boundaries as the credentials

Patrick St-Louis: issue that there are internal endpoints like the
credentials request endpoint would be called by the holder and the holder
would actually provide sensitive information to that endpoint in one way or
another and then forward this request to the issuer. But the way that all
these different endpoints calls are being put together to do what's called
it like an credential issuance process like this sort of back and forth
would be done through a workflow exchange. Yep.

Dave Longley: So I think we might be talking about two different things
then. if the credentials endpoint that you're talking about would live on a
holder service then that's a different piece of this interaction. I was
covering the interaction between the holder and the exchange service that a
coordinator or…

Dave Longley: or a issuer is running. And so if the credential request
endpoint that you're talking about is not to request a credential from an
issuer but to ask for a credential request to be constructed by your holder
service right okay yeah we're talking about two very different things…

Patrick St-Louis: No, no,…

Patrick St-Louis: no, no, no. Sorry. Yes. Is for the holder to create a
credential request object, okay.

Dave Longley: then that makes sense I don't take any issue with that that
is about defining the interface between the holder and their service where
the holder can make

Dave Longley: a request to this service and it can construct the
appropriate credential request information that would then be included in
the exchange. and that can be part of this issue…

Patrick St-Louis: Mhm.

Dave Longley: but we might want a separate issue for it because there sort
of independent pieces of the whole process. and the way I was interpreting
this issue though I don't remember who opened it. maybe it was me. the way
I was interpreting this issue was inside of an exchange, how do you send
that information along? How is it expressed? And I think what you're
covering, Patrick, is be prior to the exchange or…

Dave Longley: when you receive an exchange URL, you would go off and hit
this other holder endpoint to get your credential request to send in the
exchange. I've got that right.

Patrick St-Louis: Yeah, because I think …

Patrick St-Louis: how the exchange going to happen that depends on many
things, if you have a self-s served scenario where the holder actually
inputs data that they want issued versus if it's a driver's license that
gets issued the exchange would look very different but in both cases the
holder needs to create something to give the containing the blinded claims
that the verifier then can sort of include in the credentials. signature.
Yeah.
00:25:00

Dave Longley: And that could happen through a VC API call to a holder
service or directly on the device depending on how the wallet implements it..

Patrick St-Louis: 100%. Yeah. Yes. Yes. Yes. in the end on creds sort of BC
wallet all the wallet is local right? So the wallet kind of creates that
locally. the end point is just to define how that would look like if
someone want to have this model. I've exposed it to an endpoint and my
thing just to show what it looks like. but yeah this could definitely be
done. In fact it should be done on the device. I think that's obviously the
most secure way but again depends on the use case.

Patrick St-Louis: the second part for this that's missing is and I posted
something on Slack it's about the presentation request because I don't know
if this issue is just focused around the issuance but I think to create a
presentation request of a credential that has a pseudonym I don't think the
query by example is at least in the way it's now is suff efficient to kind
of request these things. especially with BBS, there are specific features
that are enabled by such as a commitment, range proof, verifiable
encryption and these things. and the query by example is good. I think we
had discussion about how it can be used for selective disclosure. that's
one thing that's possible for this.

Patrick St-Louis: but advanced sort of feature that are unique to as a
subset of crypto suite. I don't think currently it's flexible enough for
this. so that's another thing I would kind of look at how can these
different features can be requested right in a presentation request. Yeah.

Dave Longley: Yeah, we should look into that. we do have another query type
that's like for did off or something and it could be similar to that, but
it could also be the case and we should do that. But it could also be the
case for some of these credentials there is no other way to do the
presentation. or we might define that the way that you do such a
presentation is you must construct a presentation that will have a
pseudonym that uses the domain in the query in the BPR something along
those lines.

Dave Longley: And so for some of the cases you might not even need an
additional query type but there's a specific way that when you receive a
presentation request if it doesn't say anything else this is how we would
put it in a spec and say this is how you create the presentation. This is
the context that you use to generate the pseudonym. That is the default
behavior.

Patrick St-Louis: But at least from What I've seen there's also use case
that different pseudonym can be revealed with different domains in the same
presentation.

Patrick St-Louis: So it's not always the verifiers domain. So one of the
feature was the example a verifiable using an encryption key provided by
the issuer where you would want to provide the issuers's domain for that
specific pseudonym to be encrypted. while another identifier then you might
want to do it with so this idea of one domain for the whole presentation I
found wasn't suitable. they needed an option to have a domain per pseudonym
claim.

Dave Longley: Yeah. I'm suggesting that the default behavior would be to
use the domain that you're doing the presentation to and that if that needs
to be customized that can be provided in another type that we define that's
similar to DD off and…

Patrick St-Louis: Yep.

Dave Longley: wallets that don't recognize that type could throw up a
warning and say I don't know what this is. and when not present they could
otherwise say that you're going to present to this domain. you're going to
create a pseudonym for this domain. Is this a web origin you trust? And we
keep it really simple for the 90% use case of presenting a credential to a
website. And it all just sort of slots into how regular humans are used to
interacting with websites and the trust signals they have are the origin
you're on. And we don't make it more complex than that for the 90% use case..
00:30:00

Patrick St-Louis: I think that makes sense.

Manu Sporny: So we have a lot written down. we probably need to outline the
specific use cases we want to solve and…

Manu Sporny: have examples for all of them. It feels like the next step to
see what extra fields we need and when we need those fields and things of
that nature. let's start with use cases like I agree with you…

Patrick St-Louis: I think this could probably be broken down into three
different issues. I feel like I don't know sub issues like the VPR could be
its own presentation the issuance could be a separate issue. Okay.

Manu Sporny: but you know we will

Manu Sporny: get to that when we get to, exactly what we're trying to do.

Dave Longley: Let's divide the use cases into two sets.

Manu Sporny: Let's send presentation for each.

Dave Longley: Issuance and presentation. those are not Yeah.

Manu Sporny: Yeah, I know.

Dave Longley: into categories.

Manu Sporny: Create categories of use.

Dave Longley: Yeah. Categories of use cases.

Manu Sporny: I'm going to create two categories of use cases, issuance and
presentation for each category.

Manu Sporny: break down the most common expected use case and other use
cases that would require changes to the query language or protocol. Okay.

Dave Longley: You can leave that there…

Dave Longley: but I think that's kind of getting ahead of ourselves. it's
just what are the most common use cases period and then what are some other
use cases…

Manu Sporny: Make sure what's the change in language for each category?

Dave Longley: where the changes are required is independent of that. So
most common expected use cases from less common ones period.

Manu Sporny: Break down the most common expected use cases.

Manu Sporny: All So, we need someone to go in and do that before we come
back to this. ideally with some implementation experience. I know Patrick,
I know you've got something in here somewhere.

Dave Longley: So I think we could probably just write the most common use
case for issuance and presentation right now which is there's the most
common use case I would assert for issuance is you want to be issued a BBS
credential that allow that includes pseudonym support and no there's no
special fields or anything it's just all you need to do is the default

Dave Longley: behavior to get a BBS credential that will allow you to put
to present with a pseudonym. And then the most common for presentation is
going to be present such a credential to a web origin…

Dave Longley: where the context for the pseudonym is the web origin. So you
present that…

Manu Sporny: Hold on.

Manu Sporny: Present a basic credential that has synonym support to a

Dave Longley: to a website where the context used to generate the pseudonym
is the web origin. I would say somewhere between 90 to 99% of the use cases
are going to be

Manu Sporny: All right.

Manu Sporny: And then Patrick, you said something about verifiable
encryption being another

Patrick St-Louis: So the sort of use case that I built my demo around was
so it involves two credentials,…
00:35:00

Patrick St-Louis: right? to put it more specific. So the idea was a digital
credit card and then a sort of membership card for some organization and
both cards have a unique identifier, right? So the verifiable encryption is
used for the credit card number and the membership card identifier and the
credit card number. Verifiable encryption is encrypted with the issuers's
encryption key. So the verifier cannot decrypt that value. So we provide
the issuers domain and encryption key and then the membership card is
encoded with the verifiers encryption key. So the first of all I would like
to know is the pseudonym and verifiable encryption the same thing?

Patrick St-Louis: so verifiable encryption is I can encode a secret value
without revealing it and as long as it's encoded with the same domain it
will be decrypted to the same value. So I can have a consistent sort of
pseudonym with each verifier but the verifiers cannot correlate this
identifier in between them. Is that what sodm works? Yeah.

Dave Longley: So that's not where I thought your question was going to end.
So I got a little confused. so the way that the pseudonym works is there is
a secret that only the holder has that is bound to their credential and you
combine that with a context identifier to deterministically generate a
pseudonym. It will always be the same pseudonym for the same context
identifier. And the most common use case would use a web origin for the
context.

Patrick St-Louis: Okay. Yeah.

Dave Longley: So whenever you present your credential to website If you
present as website B, you get pseudonym B. And those are the only options.

Patrick St-Louis: So, it's very very similar at the exception that
verifiable encryption can als you can have the same behavior but on a value
that the issuer has enco So that's the case with the credit card So I
encode the credit card number send that to a the verifier cannot decrypt
it, but they can know that I've encoded right the original value and then
they can send this transaction request to the bank or the card issuer and
they can sort of decrypt it and either reject or accept the transaction.

Patrick St-Louis: So that's slightly different but same kind of idea that
every time I encode that credit card number with the issuer's domain they
will get a consistent value but the verifier cannot get a sort of unique
value based on

Dave Longley: Is this use case to cover where you might want to aggregate
payment authorizations and…

Dave Longley: allow the purchase to happen and then store and forward them
later. I'm struggling to understand why in a regular setting you wouldn't
forward something that perhaps you can't read and then get a response from
the issuer at the time. Is this to well…

Patrick St-Louis: Isn't that the…

Patrick St-Louis: what I just explained?

Dave Longley: if that's true I don't know why all the complex machinery
needs to be there. You could have just used so my spidey sense went off.

Dave Longley: Why are we encrypting a value that's intended for someone
else with all of the BBS stuff when you could have just encrypted it using
regular encryption to a target and you include that in your bundle. And
there's nothing complex about that at all. You don't even need it to be a
credential from the issuer. It's just here, I encrypt my credit card number
to the public key of the issuer and I send the encrypted stuff to this site
that's going to forward it to the issuer.

Dave Longley: I don't need to do anything else complex and they seem like
they're independent problems that can be solved that way. So I'm trying to
understand the use case for sort of mixing it all together with one

Patrick St-Louis: So far first answer is that I came up with this scenario
to showcase the feature right I didn't put too much thought into…

Patrick St-Louis: if it made sense to do like that or if there not other
ways to do it. for this I'm sure could come up with other use case that
would make more sense. I know another thing that was used was the driver's
license. For example, if you are, you need to present your driver's license
to you get stopped or something and you don't want to reveal the number to
the agent, but they can confirm by contacting the authority that you didn't
change the value and this can be sort of used at a later time.
00:40:00

Patrick St-Louis: but to respond directly, wouldn't it make more sense to
do it this way instead of sort of mixing different mechanisms like doing
regular encryption and then showing a presentation and all these things? if
this can all be supported, is it really that much more complex?

Manu Sporny: So it's short.

Dave Longley: I can short answer that. I would say because if you can
generalize encrypting a credential for example, then you don't need to mix
it with any crypto suite. you don't get the feature for just one crypto
suite. You get it for all crypto suites as an example. So if you wanted to
forward a presentation or a credential or something through someone else,
then if you just had an independent feature that allowed you to encrypt to
that endpoint and you're just going to pass through, then it solves it for
all crypto suites and all these other cases. You don't have to build it
separately for every possible type of cryptography you have.

Manu Sporny: Yeah, then it okay two things that but doesn't it become
correlatable at that point when you do that?

Manu Sporny: And then the second that's not necessarily…

Dave Longley: The answer is no…

Dave Longley: because if the encryption were correlatable it would not be
encryption. So each time you encrypt it, it's going to look entirely
different.

Manu Sporny: where I was going with that. Let me go back to the first
question though.

Manu Sporny: Is this verifiable encryption stuff is that just like
perishure pseudonyms? It sounds like it.

Patrick St-Louis: It can be perish or…

Patrick St-Louis: per verifier can be used in both.

Manu Sporny: I'm trying to map what you're talking about, Patrick. There's
a vocabulary like matching thing. I'm trying to map what you're talking
about to the BBS stuff. the

Patrick St-Louis: Yeah, we are also trying to do that on the side. So there
was one question Stephen. So this is Mike Lauder's implementation of BBS
with Anon Creds V2. and part of the question we have is how does this map
to the IETF work,…

Manu Sporny: Yeah, this is it.

Patrick St-Louis: Do they mean the same thing?

Manu Sporny: Sounds like it's just per issuer pseudonyms that it sounds
like the whole verifiable encryption thing is throwing me off because I'm
thinking it's like a different technology when it's just the pseudonym work
that's already been done at ITF and it's just per issuer pseudonyms.

Patrick St-Louis: But it can also be used per verifier.

Manu Sporny: That's correct. Yeah, they're per issuer pseudonyms and…

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: perverifier pseudonyms. But Dave, is that

Dave Longley: Yeah. …

Patrick St-Louis: That's probably what it is. Yeah. Yeah.

Dave Longley: the way that the BBS stuff works at ITF is it's just per
context. It doesn't matter whether you're an issuer, a verifier, someone's
dog.

Patrick St-Louis: Yes. Yes.

Dave Longley: It's not.

Patrick St-Louis: Depends on the domain and the encryption key provided and
who can decrypt it. and the idea is that if the issuer makes available his
encryption key he can use it or verifier can just provide their own with
their domain and

Manu Sporny: There's no need for an encryption key,…

Manu Sporny: I don't think, unless we're using that term very loosely in
the BBS or

Dave Longley: I think this is different from what's going on in BBS because
of this encryption component where you're effectively not opening the
commitment. It's like you're putting the pseudonym in a commitment and
passing it through without opening it. that seems like what's going on.

Dave Longley: So it's like an additional layer built into BBS to pass a
value through another party where when it goes to the first party that it's
going to pass through, you can do a proof that it's part of the credential,
but they don't get to see the value. They don't get to open the commitment,
and then you pass the commitment off to the party that actually is intended
to receive it, and they're able to open Something like that.

Dave Longley: But also built on the crypto.

Manu Sporny: Yeah, but I guess Yeah,…

Manu Sporny: I'm just trying to figure out. It feels rub Goldbergian to do
that. I'm trying to understand the difference.

Patrick St-Louis: What's that mean?

Manu Sporny: It feels an extra thing that you don't have to do to achieve
the use case.

Patrick St-Louis: Okay. yeah,…

Manu Sporny: Because I Yeah, sorry.

Dave Longley: Rub Goldberg is the guy that made all those cool puzzles that
a ball rolls down a board and…

Dave Longley: falls into a cup and it knocks over some dominoes and all

Patrick St-Louis: Okay, okay, okay. Yeah, yeah, yeah, yeah.
00:45:00

Manu Sporny: these things.

Manu Sporny: A complex machinery to accomplish a simple task. but I don't
know if I'm missing something. I thought with the r pseudonym stuff, the
issuer if presented the issuer issues a base BBS credential, the holder
takes that and they can do any number of presentations with it.

Manu Sporny: But if to a verifier, but if the verifier takes that
presentation, the derived, approved thing back to the original issuer, the
issuer can always map every single one of those back to a very specific
identifier.

Dave Longley: That is not correct if you're using blind BBS signatures. and
the default way to construct these credentials is for the secret that is
used to generate the pseudonym to be blindsigned. And so at the time of
issuance, the issuer can either demand that commitment be opened so that
what you just said is true, Manu. So for that particular credential the
issuer could always do that or…

Dave Longley: the issuer can say I don't need that information and you're
allowed to use this credential without that kind of trackability to ever
happen and I expect that to be the more common case than the issuer can
track where you've done presentations…

Manu Sporny: Okay. But sure,…

Manu Sporny: but that I sure …

Dave Longley: but the holder always knows which kind of credential they

Manu Sporny: but for Patrick's credit card use case,…

Patrick St-Louis: So they would Yeah.

Manu Sporny: the issuer could request a reveal because it's going to be
your credit card number or something like that, Or something that maps to
your credit card number.

Manu Sporny: So that when a derived presentation is done to the verifier
just sends it back to the right that's…

Dave Longley: Yeah, they could just send the pseudonym that they have to
the issuer and the issuer could just open it up. There would be no
additional machinery to make that work.

Manu Sporny: what I was trying to say is that it sounds to me like the
credit card use case is solved that was Yeah.

Dave Longley: So I think that's why I was trying to get maybe there's some
additional use case I don't understand for this feature.

Manu Sporny: So, Patrick, that's where I was getting tripped up is that it
doesn't feel like you need the extra, verifiable encryption stuff for this
use case. So, we need to find one where that is actually needed. if that
makes sense. Okay.

Patrick St-Louis: Yeah. Yeah.

Patrick St-Louis: Yeah. I think that makes sense. Yeah.

Manu Sporny: So for issuance there's something so there's a reveal the
commitment I don't know what to write here but Here we go.

Dave Longley: Yeah, it doesn't go under most common use case though. I
think the most common use case is just one of them. other use cases at the
bottom. And so the first one is the one we would just be the issuer
requires the user the holder to reveal their cryptony or their pseudonym
secret so that they can deon so they can link presentations.

Patrick St-Louis: doesn't that defy the purpose to reveal the pseudonym
secrets. Mhm.

Dave Longley: So presentations can be linked. you get perverifier
unlinkability, but you don't get issuer unlinkability. And this would cover
things like the credit card use case or some kind of limitation use case
where the verifiers have to send this over to the issuer and the issuer
intentionally has to track something for some high value tracking use case.

Dave Longley: And ideally as this would be in the 1% use case thing for
some kind of special situation.

Manu Sporny: I be careful of that credit cards are not a credit card
tokenization and…

Manu Sporny: processing is not a French use case, right? Okay.

Dave Longley: True. It's not clear that doing it through this mechanism,…

Dave Longley: doing credit cards through this mechanism is even what people
will end up doing. But it is one way to do
00:50:00

Manu Sporny: what are the other use cases for is insurance is that there
were some other commitments I think Patrick that you mentioned early on

Dave Longley: Yeah, another use case would be the issuer has specific
fields that they will blind sign for you that the issuer doesn't get to
see,…

Dave Longley: but they want to be able to present those as part of the
credential. I don't know what this use case is, but this is something that
people have talked about. I don't No,…

Patrick St-Louis: But that's…

Patrick St-Louis: what I understand the pseudonym to be is that you signing
a blind claim that you have a secret

Dave Longley: this is like I want to put into some self asserted set of
messages that the issuer will sign over those self- asserted messages and
the verifier will know that they're self asserted and part of the
credential but the issuer won't know what they are and that you are reusing
the same mechanism that gets used

Dave Longley: for pseudonyms, but it's not specifically a pseudonym. It's
some other field for some other purpose.

Patrick St-Louis: Okay.

Patrick St-Louis: But isn't the end result the same? is at the end of the
day they're just blind claims and whether you use it as a pseudonym or not,
what's the

Dave Longley: It's a little different. So the primitive used is the same.
So you still use blind claims to implement this. But you don't generate
pseudonyms from To generate a special pseudonym function has to be
performed and a proof for that has to happen.

Patrick St-Louis: Right. Right.

Dave Longley: And that's not what would happen with these. these would just
be revealed like you never reveal your pseudonym secret to a verifier ever.

Dave Longley: But for the other blind claims you would just reveal the
value.

Patrick St-Louis:

Patrick St-Louis: Yeah. I So there's the distinction and more around the
use case and Okay.

Manu Sporny: isn't it a proof of existence I mean one use case this is a
stretch…

Dave Longley: All that being said that's not really a use case. it's more
like a feature and I don't know what the use case for it

Manu Sporny: but one use case is a proof of existence for some set of data
at a particular point in time that was blind signed by the issuer So,…

Dave Longley: That is true. Yep. No, that's a good use case. So, if you
wanted to prove that some piece of information existed and the issuer saw
it, but the issuer doesn't know what it is, that's a perfect use case. And
you can put it under the blind claim.

Manu Sporny: notary of a document that isn't revealed to the notary as an
example.

Manu Sporny: And again, I don't know where that is useful.

Patrick St-Louis: It seems like there's a needs to be a distinction between
…

Patrick St-Louis: what we can do and it's fun and versus What has a
purpose? Yeah.

Manu Sporny: Yeah. Yeah. Yeah. witnessing, is the fundamental use case and…

Dave Longley: I'm trying to think of this might be contrived.

Manu Sporny: it does

Dave Longley: I'm trying to think of a patent office. You wouldn't get any
validation that you wrote a proper patent, but you could do proof of pri
prior art. You could get a credential that says I went to the patent
office. The issuer signed this and they don't know what they signed, but
they did sign this effectively of some prior art.

Patrick St-Louis: Could there be something like something underwent a
modification?

Dave Longley: And now I have the patent office's signature proving that I
went to them and that I knew whatever the pre-image for this hash is at
that time.

Dave Longley: And I have the signature.

Patrick St-Louis: You don't want to say what the modification is, but you
want to capture that it's been modified or altered. That make sense?

Manu Sporny: Yeah. I mean,…

Manu Sporny: yeah, that's fundamentally a proof of existence,…

Patrick St-Louis: Okay.

Manu Sporny: You want to prove that something existed at a certain point in
time.

Patrick St-Louis:

Patrick St-Louis: Okay. Yeah. Yeah. Okay.

Dave Longley: I think we just write proof of existence. you as a use case
and there's some issuer that people trust to all you're doing really is
you're leveraging the fact that there's a popular issuer out there that
provides a service. You're gonna go to them and they will put a stamp on
some blind message that you pass over and all they're asserting is, "Yep,
you sent me this blind message at this time." That's my only assertion. I
don't know what's in it, but I did see it. And so, if you can later prove
that you have the content that hashes to that, then that proves that it
existed at whenever I put my signature on here.
00:55:00

Dave Longley: You get my signature and you get the time stamp I put on it
as an issuer.

Manu Sporny: Yeah. Yeah.

Patrick St-Louis: Yeah, I think this claim exists. Don't know what it is.
It's the pretty much just describes…

Manu Sporny: Yeah.

Patrick St-Louis: what claims are.

Manu Sporny: We're at the top of the hour. but we got a good chunk into
this issue. We'll start back at it this issue next week. we are in
desperate need of people to raise PRs. we have a lot of ready for PR
issues. So, if you do have some cycles, please take a look and see if you
can raise a PR for one of these issues.

Manu Sporny: this is going to be one of the things that holds up the VC API
spec from going into a working group. we want to get, a good chunk of these
handled. that's it for the call today. Thank you everyone for the,
discussion today. we will go ahead and, meet next week. and if everything
goes according to plan, this meeting should be auto smarized in the summary
email to the mailing list at 6 PM Eastern today. we'll see if it works.
okay, that's it. thanks everyone for the call. have a great week and we
will chat again next week. Bye.
Meeting ended after 00:56:55 👋

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