VC API meeting summary for 2025-03-18

VC API Weekly Call - 2025/03/18 Summary

*Topics Covered:*

   -

   *AnonCreds V2 Presentation and Discussion:* Patrick St-Louis presented
   AnonCreds V2, a Rust library for issuing and verifying credentials with
   crypto agility. Key discussion points included:
   - Representing AnonCreds V2 within the W3C Verifiable Credential Data
      Model.
      - The generation and use of multiple public keys within the BBS
      signature scheme (clarified as not necessary).
      - The structure and representation of presentation requests and
      zero-knowledge proofs within the AnonCreds V2 framework, and how these
      could be mapped to existing query languages (DCQL or presentation
      exchange). The group explored different approaches to handling multiple
      proof types within a single presentation.
      - Strategies for efficiently handling the necessary data (credential
      definitions, etc.) for presentation requests in a decentralized
environment.
      - How to handle the case of an empty credential subject in a
      presentation request.
   -

   *Community Updates:* Upcoming discussions on promoting CCG items
   (including VC API) to the W3C Verifiable Credentials Working Group were
   announced.
   -

   *Processing Pull Requests:* A pull request (PR #23309 by Kayode Ezike)
   updating response statuses and adding location headers was reviewed and
   approved for merging.

*Key Points:*

   - The group explored ways to integrate AnonCreds V2 features,
   particularly zero-knowledge proofs and verifiable encryption, into the
   existing W3C Verifiable Credential framework.
   - Efficient caching and encoding of credential definition information
   for both holders and verifiers were identified as important considerations
   for implementation.
   - Mapping AnonCreds V2's presentation requests to existing query
   languages (e.g., DCQL) or developing a new, compatible query language was
   discussed. The preferred approach would involve minimal changes to existing
   query languages.
   - The challenge of handling empty credential subjects in presentations,
   and possible solutions, were addressed.
   - A PR focused on updating HTTP response codes and location headers was
   merged.

Video: https://meet.w3c-ccg.org/archives//w3c-ccg-vc-api-2025-03-18.mp4
*VC API Weekly Call - 2025/03/18 14:59 EDT - Transcript* *Attendees*

Benjamin Young, Dave Longley, Eddie Dennis, James Easter, Joe Andrieu,
Kayode Ezike, Manu Sporny, Manu Sporny's Presentation, Patrick St-Louis,
Patrick St-Louis's Presentation, Ted Thibodeau Jr
*Transcript*

Eddie Dennis: Afternoon everybody.

Manu Sporny: All right, welcome everyone to the verifiable credential API
call. this is Tuesday, March 18th, 2025. we have a pretty straightforward
agenda today. Let me go ahead and share the agenda. it's our standard
issue, discussion, processing, PRs, assigning issues to participants,
thing. So, fairly straightforward. we are continuing to use the new Google
Meet stuff to test it out for the main working group calls. and I think
that's it. so our agenda, again, fairly straightforward PRs, assigning
ready for R issues, that sort of thing. any updates or changes to the
agenda? Anything else we could discuss today? go ahead, Patrick.

Patrick St-Louis: So I would like to propose something a bit different
today. so next week I'm giving a presentation with Mike Lauder and Stefan
Karin about Anon Creds V2 and some of the features. I would like today to
present some of the work I'll be demonstrating focusing on the sort of W3C
aspect of it. I want to discuss how this could become a data integrity
crypto suite. I do have an API available and I implemented a few of the VC
API route and I have some question regarding presentation requests and…

Patrick St-Louis: also zero knowledge proof in verifiable credentials. So
if that's okay I would like to present this and get discussions started
with This Sounds good.

Manu Sporny: Yeah, that sounds good.

Manu Sporny: Any objections to adding that to the agenda today? where do
you want to discuss? I feel like we should give plenty of time for that.
Patrick, I'm wondering where we are on kind of PRs. I want to make sure
that we're able to process some PRs as well. There's just four of them
here. So, how about this? Let's time box to the first 45 minutes for your
item and then try to get these other PRs processed by the end of the call.
does that work for you, Patrick? Okay.
00:05:00

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: Any other updates or changes to the agenda today?

Manu Sporny: All right. next up is relevant community updates. just have
one and is that we are going to be holding the first of a series of
discussions around promoting CCG items to the verifiable credential working
group at W3C. so moving VC API being one of the things on that's going to
be proposed along with re confidence method things of that nature. so
please join if you are interested or let folks know that we'll be having
those first set of discussions starting tomorrow.

Manu Sporny: and that is going to be at 11:00 a.m. Any other community
updates that we should discuss today? All if not let's go ahead and jump
into your item Patrick which is the anon v2 presentation. I'll stop
presenting so you can share.

Patrick St-Louis: Thank you very much. let me get this window. So anon
creds v2 obviously it's the sort of evolution from ancreds v1. and some of
the core features that are very important is the crypto agility of the
library. So first and foremost It's a rust library that can conduct
different issuance and sort of proof or statements over credential that are
issued. The library is currently you can swap out the underlying
cryptography for BBS and PS signatures. The work I'll be demonstrating is
using the BBS implementation.

Patrick St-Louis: so what I'm hoping to get from this presentation is
primarily feedback and there's going to be some I think important
discussion about presentation exchange and zero knowledge proof when it
comes to verifiable credentials and how to represent this in a way that is
so to get started so this library sort of covers issuance of claims and
also so it's not a case that the revocation mechanism is separate from the
sort of credential library. It encompasses everything. So this library has
its own data classes and data models.

Patrick St-Louis: One of the objectives I'm trying to pursue is how to
represent this in a W3C verifiable credential data model using features
from the data model specification. Ideally how it would work first so an
issuer would create a schema for the credentials they want to issue. The
way I've implemented this is you can pass in a normal JSON schema and
that's going to define your claims. It's not going to define the schema of
the verifiable credential, but it's going to verify can understand. There's
at the moment five possible claim types that you can define.

Patrick St-Louis: You can define a revocation claim, a scalar claim, and a
enumeration claim. and the example I'm going to do, I'm going to keep it
very simple. They're all going to be hashed claims. That's not the goal I
want to discuss today. so I have a JSON schema here with a title
description. The object type is automatically filled and I have five
properties. Each property is a different claim. They're all of a type of a
string. can execute this and this is the object that the library can
understand. So I have The order of the claim is very important. these
different values are accessed by their index.
00:10:00

Patrick St-Louis: and I'll explain a little bit what I can do and what this
revocation claim can be used for. it is possible to have some able So the
blindable claims are values that the know. the holder will put a signature
over these values and request them from the issuer. so this is useful in a
case. so Anra has this concept called which is a secret value that the
holder can use to bind the credential to himself. So the link secret it's a
unique string that only the holder knows and it can be used to bind some
credentials to his wallet and it can also be used when presenting
credentials. I'm not going to showcase this today.

Patrick St-Louis: I want to keep it simple that is not the goal for today.
So we can get a schema ID. So the next thing I want to do as my issuer is I
need to generate some verification material for this. So I need to generate
a signing key and a verification key. so I would take this input and I like
to call it I'm defining a credential. So is these schemas could be shared
amongst many issuers right and then issuer would sort of generate their own
cryptographic material to take them. So again this API you're going to see
private keys and stuff. This is just for development.

Patrick St-Louis: obviously everything private would not be disclosed. The
issuer would keep this. this is just so we can see what is being done. So
the public component is what the issuer would likely host somewhere and
make this available for holders and verifiers so we can see in the
verifying key we have I'm not the most familiar with BBS signatures but
from what I understand you generate a key and then you sort of derive a
public key for each of the claims you want to issue. So with this
verification key I can sign up to six messages and these corresponds to my
claims that I have in my schema.

Patrick St-Louis: So in my scheme I have six claims. This key can sign up
to six messages. I'm not too sure how the BBS crypto suit does it. I
believe this is done at issuance time. maybe someone can correct me. In the
case of the unrest library, these are issued when the issuer kind of sets
up his instance. We also have a Yes.

Dave Longley: I just wanted to comment on that. I'm not aware the crypto
suite does not need to generate multiple public keys to go with a BBS
private key. So, I'm not really sure what's going on that with that piece.

Patrick St-Louis: Okay. thank you.

Patrick St-Louis: I'll try to clarify that outside of this meeting with we
also generate a key pair for the revocation registry or the revocation
accumulator. So this is the key that the issuer will use to update the
status registry and we also have a verifiable encryption key that the
issuer makes available for one of the statements that I'll cover. This is
one of the topic I want to cover today which is to enable the holder to
provide an encrypted value for a claim without re revealing it to the
verifier and the verifier can then delegate this value to the issuer and
the issuer does what it does. I'll explain how this can work in my example.

Patrick St-Louis: the revocation registry is the initial state of the
accumulator for the revocation registry. so this value would be hosted
somewhere and then as revocation are made new version of this value would
be published and then the private is sort of the private counterparts to
this public section. So the sign in the verifiable decryption key. where we
have the key to encrypt, this is the decryption and then revocation
registry which is there. yeah. Yep.
00:15:00

Dave Longley: I just wanted to suggest that maybe those values are
independent like individual generators that are used for each message. that
is something that happens internally in the BBSETF spec.

Dave Longley: Those are autogener generated. and…

Patrick St-Louis: Yeah, possibly.

Dave Longley: maybe these are just cached and that's what's going on

Patrick St-Louis: So I know these are static, So they're not going to
change. They just need to be available for the holder and the verifier. but
you can see this information as you would cache this right. So the same way
you would did document with verification material you would cach this I see
this as being one verification method entry. at least that's how I perceive
it. Does this make sense to what you just said?

Dave Longley: I think would be odd to include it in a verification method.
I mean, I would expect that there's a single public key associated with the
private key and that's what goes into a verification method. These are
things that are deterministically generated based on an API identifier that
goes into BBS and based on some number of generators you need to create

Dave Longley:

Patrick St-Louis: Okay,…

Dave Longley: if that's what this maps to. and so it just feels yeah I
haven't thought through all the details of what it would mean to put them
in a verification method and if that's useful or not.

Patrick St-Louis: So, the next step, just going to go over to this,
issuance tab. So, again, you get an ID for these. so I'll first present.

Patrick St-Louis: So, I did a credentials issue to kind of picture what I
envision this looking like in a W3C format and then I'll go over the
issuance process with the data model as defined by the library. So, we have
our credential subject which each of these claims are dependent on the
schema. the only thing missing here is the revocation claim and we will use
the credential ID to be able to track the revocation for this credential
the cred ID. So this is the issuer public portion that I need to retrieve.
So I need to identify this. I'm assuming this could be preconfigured with
this instance. I'm just providing it here.

Patrick St-Louis: so a few things happen. so I created a credential status.
there should be a type in there. so this is the sort of credential status
entry that happens for this type of issuance. So when the holder gets his
credential, he's going to get a revocation handle value and it's going to
get The revocation ID currently I just use the credential ID that you
provided but there could be another separate ID. You just need a random
string and that's the value of the revocation claim.

Patrick St-Louis: the revocation registry ideally that would be a URL sort
of like the redential for bitstring status list. It would be a URL to the
registry and then from that registry you could get the different states
timestamps when they were published credential subject and then the proof
this is sort of a signature over this object. So this would correspond to a
ba base proof right? So this is a credential that only the holder would
see. You would never disclose this properly to a verifier or so and then
the next step is what this holder can do what kind of presentation he can
make So in this library they define those as statements.
00:20:00

Patrick St-Louis: So a verifier can request a series of statements. There's
a few different statements type that are predefined. there's a signature
statement. You would always include this. This is just a signature that you
would include in your presentation and the verifier can request claims to
be revealed in that signature statement. You can also have a revocation
statement. So this would be the holder using his credential ID to prove
that his credential is not revoked. You can include a verifiable encryption
statement which is the main point that we want to demonstrate next week and
I'll show what's the purpose of this when it comes to a credit card number.
and a few other ones there's a range statement.

Patrick St-Louis: So if you have a value that's an integer, you can ask if
it's in a certain range. and you can also have a membership proof
statement. So you provide a subset of values and you can ask if one of the
claim is in that subset. So these are different type of zenero knowledge
proof that can happen. Yes. No,…

Dave Longley: So the signature statement you would generate a proof for
that you would not send over the base signature value. Is that correct?
Okay.

Patrick St-Louis: And I'm going to demonstrate this. I'll show this not in
W3C style, but this is one of the thing I want to discuss is how can all
these statement proofs because there's going to be a different proof for
each of the statements. And I'm wondering if these should be sort of an
array of proofs on a derived credential that would be included in a
presentation.

Patrick St-Louis: At least that's I see how it could be currently. so
that's fine. So I'm going to reissue this credential with the sort of
library style data models. We can see just trying to be precise. so the
credential request it would be used in the case that the holder had a link
wanted to add blindable claims. So you could sign a request signature over
the blind claims you want to get issued. So you would include this in the
credential request. Not going to show this today.

Patrick St-Louis: so again I need to give a credential definition ID which
I'm just going to get the one I put here. So these are the different
claims. So the order as I mentioned earlier is very important. these are
often accessed by their revocation claim as a good practice I always put it
at the first index so the index zero and then I would put in second
followed by the blindable claims and then these are my hashed claims so you
can see the claim type h for the moment these are all hash but I could have
also a number claim for example you can disclose if they are print friendly
or not this is

Patrick St-Louis: just use as a hint if it's something you want to display.
Probably this one you could put sensitive information you would flag things
that are just random that are not very useful to be displayed. and then
this is the signature that is produced. I'm not too sure I said I'm not too
sure what happens in there but it's a signature that's produced by the
issuer that can be used to derive proofs from this. in my example I just
concatenated these as a sort of encrypted value.

Patrick St-Louis: So I just put them basically did a GCS on this object and
put it in base 58 multibbase. this is the revocation handle that I include
in the credential status and the revocation index. So we can sort of
compare to where these items have been placed in here right the revocation
registry comes from the issuer part the revocation ID here is the actual
revocation claim value. this one just generated a new one. okay so we got
this.
00:25:00

Patrick St-Louis: So now I want to get into the topic of presentation
requests and this is where I'd like to get some ideas about how this could
fit in with the request specification. so we're going to request a
presentation. So the way it works is you have different statements. for
this one I have a verifiable encryption statement, a revocation statement.
Signature statement is always included and you can choose which claims you
want to have disclosed in the proof. So in this game I could disclose my
CVV number. Is it Forget There you go.

Patrick St-Louis: the card type, could probably be a good thing. I want to
see sorry, I'm just trying to see for the encryption statement here. so I
want an encryption statement of the number of the credit card. So this
would be a verifi like a store for example. So is going to get the
encrypted version of the number. They will not see the credit card number,
but they will be able to know that the value that's encrypted comes from
the right value and they could forward this request to the issuer of the
credential or whoever has the private key associated with this encryption
key.

Patrick St-Louis: So a verifier could very well provide the holder with
their own encryption key if they wanted them to decrypt this value or they
can provide the encryption key provided of the issuer. If this is some
information that the verifier shouldn't see for privacy reason you would
give a domain. so for example I'm just going to use visa domain. and this
domain is a domain that would be provided by the owner of this key pair. so
the verifier could give their own domain or they could give a domain
provided by an issuer. now I'm going to go and see here. I'm going to get
that encryption key.

Patrick St-Louis: For the revocation, the verifier would give the value of
the current accumulator against which they want the revocation to be
proved. in this API, I just did that. If you leave it empty, it's just
going to get whatever the latest is. we can ignore this domain here for
sure. just want to double check I have the right credential definition ID.
Okay. So this is the presentation request. Yeah. Yeah.

Dave Longley: I was just going to suggest that the credential definition ID
you might want to make the in the base proof value be like some
seabourcoded thing that includes that credential ID so it's always
available to the holder so they can find it to make their presentation.

Patrick St-Louis: Yeah, that's probably a good idea. yeah, this is fresh. I
just made this Rust kind of. So, this is a sort of shim in between my
Python framework and the Rust. So, I just put these things together. So
I'll definitely any kind of suggestions like this one are more than welcome
for encoding and so basically right now all these objects are in the
library itself but we want to try to find what is going to live where and
how different parties are going to get access to these information.

Patrick St-Louis: Yeah.

Dave Longley: Right. Yeah.

Dave Longley: the current VCDI BBS crypto suite is something to take a look
at because it has some seabboard encoding of a number of different
parameters that'll fit it in there and you could follow that

Patrick St-Louis: Yeah. I had a little bit of a look while working on test
suite of the seabboard encoding and it's definitely something so you would
include this in the proof value of the base credential. is there really
something that's interesting?
00:30:00

Dave Longley: Right.

Patrick St-Louis: Yeah. yeah.

Manu Sporny: And to further underscore that, Patrick, it's basically shove
absolutely everything that's useful to someone to either the holder or the
verifier. Shove absolutely everything that you can into the pro proof value
so that you don't have all of these bits and…

Manu Sporny: pieces of data kind of floating out there kind of disconnected
from the proof.

Patrick St-Louis: Yeah. Yeah.

Dave Longley: Yeah.

Patrick St-Louis:

Patrick St-Louis: So that's the thing, right? So in the VCDM model and the
issuance and the credential schema this is this issuer public component. So
in this schema here you're going to find the schema and the issuer public
components.

Patrick St-Louis: and this is kind of important especially for these claim
indices because where is it this claim number here this is a helper
function. So you just give the string but ideally in the actual statement
you need to give the index of which claim this proof should be about. Yep.

Dave Longley: There might be some ways to deterministically generate that.
that's something to explore. But that being said the comment I wanted to
make is if you're going to use that URL to fetch something if it's not
available in the proof then you would implicitly be taking on a requirement
by holder wallets that they're either online or…

Dave Longley: have cached this credential definition blockchain thing that
a noncred uses. those are trade-offs and considerations. …

Patrick St-Louis: And there's no blockchain here.

Patrick St-Louis: No blockchain whatsoever.

Dave Longley: …

Patrick St-Louis: This probably won't live on the blockchain, right? Yes.

Dave Longley: there's a URL right there to fetch all that stuff. And so
either you're online and…

Patrick St-Louis: Yeah. the wallet would have cached this at issuance time
definitely this is not signed to the credential right it's only a value
that what's the word I'm looking for the holder would…

Dave Longley: you got to fetch that or you have cached it or maybe you get
that when you get the credential and you save it with your credential and
that sort of thing. Okay.

Patrick St-Louis: but it's a bit redundant because the verifier would also

Patrick St-Louis: already have cached that. So, definitely I think this
could be taken out and some of this information could be either in the
proof value or just be cached. because it's expected that the verifier when
they make their presentation request,…

Dave Longley: Yeah.

Patrick St-Louis: they add knowledge of this item and the holder has
knowledge of it at issuance time. the only time that you need to find these
is when they want to do their presentation request they need somewhere to
find this right they need somewhere to initially get it to cach it.

Patrick St-Louis: And…

Patrick St-Louis: this is the challenge here. Yeah. Yeah,…

Dave Longley: Right. my only other comment would be to just make sure to
think through architecturally the different layers that a wallet implement
would have to implement and…

Dave Longley: where they would put these different pieces based on whether
the credential is coming back with multiple different proof types. maybe it
has a proof set on it that can do a non-creds and a different proof that
can do something else. so just think through that so that wallet providers
can put all the special handling code in one place if possible.

Patrick St-Louis: I think that makes So, this is a presentation request.

Patrick St-Louis: So the one thing I'm wondering is how could this be
translated to a query language either DCQL or a presentation exchange right
the presentation request. so each statements are about a specific claim.
and then each of these statements the holder would generate a different
proof to satisfy the statement. at the minimum you always need a signature
statement which you can say which value you can disclose. So I could see
how this would be made into a query language for these other ones.
00:35:00

Patrick St-Louis: since this is another layer this is where I would need to
reflect a little bit. Yeah.

Dave Longley: So there's a number of different considerations here. the
first one is whether or not you So one way to approach this problem is to
make an entirely new type of query. And in doing that, it makes it really
easy to make your query because you can work from scratch, do whatever you
want with it. The trade-offs there are if a wallet has multiple credentials
in multiple different formats and the verifier is willing to accept a
variety of those or…

Dave Longley: if the wallet wants to index their credentials in different
ways, you might make that really hard for both verifiers and wallets by
having this really bespoke a non-cred specific query language. And so those
are your pros and cons with that approach. The next approach would be to
come up with a way to map this in potentially all Yeah.

Patrick St-Louis: That's Yeah,…

Patrick St-Louis: that's what I'm looking for. Yeah. Okay.

Dave Longley: Yeah. If you could map it directly to an existing language,
that I would think would be the best. But you could also have something in
between that's sort of like if you look at example 10 on the VPR spec, you
can have where multiple queries have to be true. And if you find that you
can't map everything to a particular query language, you could map perhaps
everything about all the claims, but then you need to say and it's this
credential definition and maybe just all you would need to do is you would
have a v a query by example that's able to be fully mapped and…

Dave Longley: then you would have an additional query in a non-cred
credential definition query and it would just say the credential
definition. there might be a way to do things like that that would break it
up and…

Patrick St-Louis: Yeah, I think there's a desire here.

Dave Longley: make it work well for implementers on the verifier and holder

Patrick St-Louis: So the same way that a schema can be shared by issuer
could sort of publish these statements that I like here's the kind of stuff
my credential can be used for. and verifiers could then pick and choose
some of these statements to include in their queries or a verifier could
maintain their or own sort of presentation request schemas that they can
use, right?

Patrick St-Louis: Because if a issuer issues a driver's license, there are
certain things that verifiers will use this for that are kind of universal.
Maybe some verifiers going to be more specific in what they want, but
there's definitely proof of age is very common. So the issuer can publish a
presentation schema along with their issuance schema that verifiers can
use. so I think that's more like the first option that you mentioned that
they would just host these schemas and it's a very specific query language.
But yes, what I would really like to do is to map this to some well-known
query language if possible.

Dave Longley: And then an additional option would be for a noncreds to sort
of have every issuer have a table of this VC type goes to this credential
definition and have that somehow be well known between issuers and holders.
So that if you made a query that did not mention credential definition at
all, but it set up these are the issuers I'm willing to accept from, then
the holder could look at what credentials they have and find the credential
definitions from those credentials that map to the acceptable issuers.

Patrick St-Louis: Yeah.

Dave Longley: And as long as the verifiers indicated that the proof type
they will accept is in a non-cred proof type, you could have the verifier
essentially just all of their queries would look the same as any other
language in theory like any other expression. So you could have a query by
example. it would look the same for whether you're using a noncreds some
other data integrity crypto suite. They would say what their acceptable
crypto suites were and which issuers they're willing to accept from and the
holder could then do that translation on the other side and say based on I
can find which credentials I have that match these issuers and…
00:40:00

Dave Longley: if it's a noncreds I know how to find the credential
definition and how to map a query by example to whatever they're asking for
if that makes sense.

Patrick St-Louis: I think so.

Patrick St-Louis: I think so. I'd love to Yeah.

Patrick St-Louis: I think so. yeah.

Dave Longley: So I think that might be the best outcome…

Dave Longley: because it keeps everything separated and clean. and the only
challenge is put on the place where is put on the holder which has to know
how to make the presentation of ancreds credential anyway. And so it's able
to map and…

Dave Longley: find out whether or not this a nonredit credential will work
based on a standard query that would work for any other type of crypto
suite.

Patrick St-Louis: Yeah, I think regardless Yeah,…

Dave Longley: And then it knows what to do to make that presentation.

Patrick St-Louis: I think regardless of the option at the end of the day
the wallet will need some to do implementation work if they want to support
any other crypto suite. But yeah, if this can all be mapped from this
similar type object and then the wallet there's a way to handle the mapping
internally, I think that's the best way.

Dave Longley: Yeah, because…

Patrick St-Louis: Yeah.

Dave Longley: then it makes it you don't have any extra burden on the
verifier.

Patrick St-Louis: So quickly so to make a presentation so I give the
presentation request ID currently.

Patrick St-Louis: So the presentation I just created is going to be shown.
I created a challenge and then I give the credential here. and let's
generate this. this is where this is the So the presentation is just a list
of proofs with a challenge and I asked to disclose the card type and the C
the verifiable encryption is the interesting bit. this is a encrypted hash
of the credit card number. The verifier would never know this value.
however they can forward this request to the issuer. Right?

Patrick St-Louis: But I just use a credit card in this example because I
think it showcase it explains the purpose of this really well. And then the
issuer will be able to decrypt this specific proof using their decryption
key. So the encryption key is the verifier knows The issuer has their
decryption key and then they will get the hash of the credit card number
which they can then kind of find they would maintain a hash table of all
their credit card number and they could find it this by association.

Patrick St-Louis: So this is one of the features that I think Stephen Karn
really wants to put forward this sort of idea that the holder can present
identifier in a anonymous way. so that manager isn't one my Yeah.

Dave Longley: So when you say in an anonymous way, you mean to the verifier
since the issuer,…

Patrick St-Louis: Yeah.

Dave Longley: it seems, would have full linkability.

Patrick St-Louis: So there's many the issuer would no in the case of the
credit card example at the end of the day the payment needs to be made
right so you need that number and only the credit card company would know
this number but there's many things you can do with verifiable encryption
another thing that is possible is if you have two verifiers and they both
have their own encryption keys they can include

Patrick St-Louis: their encryption key in the presentation and the proof
that the holder would send to each of them is different, So the verifiers
could not correlate this identifier because they would only get the
encrypted value. That make sense.

Dave Longley: Yeah, that's very similar to the HD how oblivious HTTP works
underneath the scenes.

Patrick St-Louis: Interesting. Yeah, I think this is the goal today is do
pseudo identifiers. so yeah one of my questions I have two questions and
this is what I really wanted to get answered today. This is a presentation,
but if I was to present this as a verifiable credential, I would do a
derived credential.
00:45:00

Patrick St-Louis: And would it make sense to have each of these proof as a
totally separate proof in the proof attribute of the credential with a I
could define not the type of the proof the type would be like an signature
but there maybe something similar to proof purpose right the statement
purpose would be like signature this one is revocation this one in
verifiable encryption yep.

Dave Longley: I would hide them all under one BBS noncreds proof and…

Patrick St-Louis: Interesting. Yeah.

Dave Longley: have each one of those be encoded in seabboard or something
with their own type information there.

Patrick St-Louis: I see more.

Dave Longley: That way you have full power to express this however you want
to and you don't have to involve it.

Patrick St-Louis: So just encode this whole bit pretty much.

Dave Longley: Yes. Yep.

Patrick St-Louis: Okay. that's interesting. Now my other question.

Patrick St-Louis: So in the case so here I asked to disclose some message
but maybe I don't want to what do you do in this case and you have an empty
credentials subject where would that fit in that's my last question But you
wouldn't reveal the case you don't reveal anything about there's nothing in
the credential subject that's being revealed like there is a credential
subject in the base proof…

Dave Longley: An empty credential subject would be an invalid VC. So, you
might just need to change your modeling. if you're going to model a credit
card, you would probably model it as a credential sub there is a credential
subject and it has a credit card in it. it would be a per a person. You
don't have to say anything about that person or a whole oral card holder
and it holds that card. And so if you model it that way you would always
have a credential subject. in that case you would be re …

Patrick St-Louis: but in

Patrick St-Louis: the derived proof there is absolutely nothing revealed.
They're all sort of zero knowledge proof based. you only put a verifiable
encryption for example or…

Dave Longley: what can you give an example of what field would be revealed
in such a presentation? So if you're revealing nothing in the subject, what
is being revealed?

Patrick St-Louis: you only give a proof that one of the field like the age
is between 18 and 24 but you don't reveal the age right?

Patrick St-Louis: So the credential subject would be empty from the derived
proof…

Patrick St-Louis: but you can know that the original credential had a age
value that is between 18 and 24. Okay.

Dave Longley: Yeah, it's a good question.

Dave Longley: It might be of value to always have a field in It's a good
question. Maybe there's a better solution than One possible solution is
there's always a type field in the credential subject that always gets
revealed and it doesn't really tell you very much but it would guarantee
that you can express that. So I see Mon's got his hand up so I want to get
off the queue.

Patrick St-Louis: That's it. Sorry, I took a bit longer.

Manu Sporny: Okay, no problem.

Manu Sporny: I was just going to remind us that we're getting ready to blow
past our time window. we have 10 minutes left.

Manu Sporny: Patrick, anything else on this? I mean, we'll do what we can
in 10 minutes, but any other questions? Patrick, for the group in general.
go ahead, Patrick. Then Joe's on the queue.

Patrick St-Louis: Yeah. No,…

Patrick St-Louis: no, I just wanted to say sorry if some of this is a bit
not clear, I didn't write the library. I'm just trying to use it and to
connect some dots. and if there's questions, I can definitely relate them
to either Mike Lauder or Stephen Curran. There's more specific questions.
That's it.

Manu Sporny: Thanks, Joe, you're up.

Joe Andrieu: I just wanted to reflect back.

Joe Andrieu: I think in the derived case where you've got this predicate,
what you probably want to do is figure out how to represent the derived
predicate. it's an age range predicate and put that as the property in the
credential subject with the value because you are making a derived claim
and it seems like that may be one way to go about it well to capture in the
predicate right you're going to have the credential subject as a property
and…

Patrick St-Louis: just a true boolean or something like that.

Joe Andrieu: then within that we have properties…

Patrick St-Louis: So you would put the proof as the value of the age in the
subject.

Joe Andrieu:

Joe Andrieu: which are predicates for then the statement. So you can have a
predicate that says, "Hey, it's an age over 18 proof and here's the proof
value or the proof statement and then that is wrapped in a proof type that
lets people understand how they interpret that predicate.
00:50:00

Patrick St-Louis: Is that what I'm understanding?

Joe Andrieu: No, that's probably not right.

Patrick St-Louis: Okay. Sorry.

Patrick St-Louis: Yeah.

Joe Andrieu: the thought was simply that in the VC architecture the
property within the subject claims is the predicate of the meaning of the
value and…

Patrick St-Louis: Yeah, interesting.

Joe Andrieu: so that's where you want to instead of saying that we don't
have the data birth property we have this derived claim property and I'm
just sort of spitballing how you might map to that structure You're welcome.

Patrick St-Louis: Yeah, I think more thoughts need to be put into this.
thank you.

Manu Sporny: All thank you, Parick. it was good to run through that. good
to understand kind of where everything is. of course, if you see any rough
edges where it's not a clean fit with the VC API or the query language or
any of that stuff, certainly let us know so we can improve those things.
real quick in the 3 minutes that we have, I wanted to make sure that I
already looked through some of the PRs. It looks like, Coyote, maybe your
PR is the only one that's ready to wanted to confirm with you that that's
true before looking at merging.

Kayode Ezike: Yeah, the main changes there basically changed the response
status to 204, added a heck location headers and specified kind of what
that would look like for creating responses and workflows. So there's no
longer the returning the actual exchange or workflow when you create them.
and then just removed if you scroll down there's a place…

Kayode Ezike: where the exchange was being returned in the exchange key and
we agreed to remove that as well. Yeah. 23 309.

Manu Sporny: Great. …

Kayode Ezike: So that's the main thing. I think I was wondering if we also
maybe wanted to add text to clarify that it's being returned in that
location header. Just didn't have time to get to that. an actual spec text.

Manu Sporny: yeah, I think that would be helpful. You do say something
here. I'm guessing does it show up somewhere? when we do that. I guess
that's the question. I don't know if the renderer actually renders this
part of it.

Kayode Ezike: Yeah. Yeah.

Manu Sporny: I think this is a new thing. and it might Okay.

Kayode Ezike: So I tested it in at least the red view and it seems that it
does render. there I maybe should check also for

Manu Sporny: That's okay. I think that can be done in another PR. I'd like
to kind of merge this in if nobody Any objections to merging this?

Manu Sporny: I think Cody addressed all of the things we raised last week.

Kayode Ezike:

Manu Sporny: Looks like Longley agrees. we will merge this. if you could go
into main and maybe try to squash the merge conflict commit out just
because it kind of creates a messy history. other than that, I think we're
good to go. So, I'm going to re rebase and merge this. …

Kayode Ezike: Could you repeat? Sorry, I was.

Manu Sporny: there you committed a resolve merge conflict thing and…

Kayode Ezike: Okay.

Manu Sporny: it's like we care more about the changes you're making to the
spec than the,…

Kayode Ezike: Yeah. Right. Okay.

Manu Sporny: addressing merge conflicts. so we'll want to squash that out
you can just go to main and maybe squash and force push if you have those
permissions.

Manu Sporny: If not, I can maybe do that if I can remember next time. I
think that's it for PRs. Thank you very much, Coyote doing that PR. and I
think that's it for a reminder again that we'll be talking about VC API
along with a couple of other specs to promote tomorrow on a weekly basis,
every Wednesday at 11:00 a.m. Eastern. I'll try to remember to send out a
reminder to the mailing list on that later today. and we will then of
course meet again next week and continue processing issues and PRs. thank
you everyone for the wonderful discussion today. Thank you Patrick for the
Good luck in the presentation next week and we'll see everyone next week.
Take care. Bye.
Meeting ended after 00:54:58 👋

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