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

st 26. 3. 2025 v 19:14 odesílatel <meetings@w3c-ccg.org> napsal:

> 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
>

Very cool stuff, but both these links not found ^^


> *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.*
>