Re: [MINUTES] VC API 2025-03-25

Wow, this meeting summary—and especially the Key Points covered—is super helpful. Assuming this is due to the switch to Google Meet, all I can say is, the difference is palpable (for the good).

Thanks,

=Drummond

From: meetings@w3c-ccg.org <meetings@w3c-ccg.org>
Date: Wednesday, March 26, 2025 at 11:13 AM
To: public-credentials@w3.org <public-credentials@w3.org>
Subject: [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.