[MINUTES] CCG Weekly 2025-07-08

CCG Weekly Meeting Summary - 2025/07/08

*Topics Covered:*

   - *Introductions and Announcements:* Brief round of introductions,
   updates on the CCG website, mascot selection, and a proposal for a new work
   item: Verifiable Credentials over Wireless. Kaliya also provided updates on
   upcoming IW and Digital Identity Unconference Europe events.
   - *Multi-key and Multi-base Verifiable Credential Implementation:*
   Jaromil and Andrea presented their implementation of multi-key and
   multi-base verifiable credentials, showcasing a hands-on demonstration
   using Zenroom. They detailed the process, including key generation,
   canonicalization using Manu Sporny's library, signing, and verification.
   Discussions centered on the practical implications of multi-signature and
   multi-key approaches, particularly regarding code readability and the
   efficiency of canonicalization. The use of base58 encoding was also
   discussed.
   - *Post-Quantum Credentials:* The presentation extended to cover the
   implementation of post-quantum credentials, highlighting the ease of
   adaptation by substituting algorithms within the existing codebase.
   - *Data Integrity Spec Improvements:* Discussion on improving the data
   integrity specification to incorporate parameterization, aiming for better
   reusability and simpler implementation across various cryptographic suites.
   - *Identity Wallet Demo:* Andrea demonstrated a web deployment of their
   identity wallet, showcasing the acquisition of a W3C VC 2.0 credential via
   Open ID for VCI draft 15. The demonstration highlighted the wallet's
   capabilities and its upcoming availability on app stores. A discussion of
   transport protocols commonly used in the US versus Europe also took place.
   - *Longfellow ZK Integration:* Andrea presented the integration of the
   Long Fellow zero-knowledge proof system into the Zenroom wallet,
   highlighting its implementation in Android and a microservice. This
   included discussion about the size of the proofs generated (approximately
   350KB compressed) and the challenges of integrating C++ code into a C-based
   environment. An Android app and a microservice for verification were
   showcased. The discussion included plans for future SDK development.

*Key Points:*

   - A novel declarative approach to creating verifiable credentials using
   Zenroom was presented, simplifying the process.
   - The importance of caching contexts during canonicalization for
   performance optimization was emphasized.
   - The use of base64 URL encoding for proof values was suggested over
   base58 for efficiency reasons.
   - The data integrity specification is undergoing revision to improve
   parameterization and reusability.
   - A new identity wallet is nearing release on app stores and includes
   support for verifiable credentials.
   - The integration of Longfellow ZK into the Zenroom wallet is
   progressing, with an Android app and microservice now functional, despite
   challenges related to code size and compilation.
   - Future plans involve creating an SDK with examples for various
   programming languages.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-07-08.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-07-08.mp4
*CCG Weekly - 2025/07/08 11:53 EDT - Transcript* *Attendees*

Andrea D'Intino, Benjamin Young, Brian Campbell, Chandima Cumaranatunge,
Dave Lehn, Dmitri Zagidulin, Erica Connell, Geun-Hyung Kim, Greg Bernstein,
Gregory Natran, Harrison Tang, Hiroyuki Sano, Jaromil, JeffO - HumanOS,
Jennie Meier, Joe Andrieu, Kaliya Identity Woman, Kayode Ezike, Mahmoud,
Manu Sporny, oidf sony, Otto Mora, Parth Bhatt, Phillip Long, Rob Padula,
Ted Thibodeau Jr, Vanessa Xu, Will Abramson
*Transcript*

Jaromil: Hello. I don't need

Harrison Tang: Hello. Thanks,…

Andrea D'Intino: Hello everybody.

Harrison Tang: Andrea, and thanks Jerem for jumping on. And sorry about not
last week, but a couple weeks ago's panical issues.

Andrea D'Intino: No, no worries.

Harrison Tang: So, will lead this call, but yeah, thanks again for

Will Abramson: Hey guys. I think we met just recently, we met I'll turn my
camera on briefly. I'm in a coffee shop. So, hi. I think we met In Geneva.

Will Abramson: I don't know if you can see me. I can't see. Hey, wait.

Andrea D'Intino: Could be.

Andrea D'Intino: I mean, I can't see you there, but maybe Jarm. Not sure.

Jaromil: I'm clicking on the picture…

Jaromil: where you wear a shades.

Will Abramson: Yeah, I tried to turn my camera on,…

Jaromil: I'm happy that we met.

Will Abramson: but it doesn't seem to be working. I don't know what's going
on there.

Jaromil: Cheers.

Will Abramson: Maybe that insert.

Jaromil: will was overall a very good occasion to meet many people and…

Will Abramson: Yeah, totally.

Jaromil: among them you and yeah I was usually hanging out at the table did
that's…

Will Abramson: Yes, I remember seeing you there, y looking super swave.
Yeah. And I did hear about you.

Jaromil: where I went to direct and Simon was there

Jaromil: Yes, I was bragging.

Will Abramson: Didn't you do some karaoke? Maybe one TCG call we can have
karaoke.

Andrea D'Intino: That was wish.

Jaromil: Andrea, update the wheel breeze about the karaoke plan.

Andrea D'Intino: Yeah, that was wishful thinking.

Andrea D'Intino: After the day we were lying horizontal on the Airbnb sofa
and there and you would have need one of those devices to cars to lift us
and to take us somewhere else. next year. I promise.

Will Abramson: Okay, great.

Will Abramson: We'll get started in a few moments. maybe a couple more
minutes.

Jaromil: But don't the interruption…

Jaromil: because I'm on holiday also on this call from seeing from the
point of view of CCG seems like I'm always on holiday and yeah so my kid
interrupting but when we start I'm really volunteering

Will Abramson: …

Will Abramson: I appreciate you joining us while on holiday. That's very
good of you. Yeah.

Jaromil: I'm ready where you

Will Abramson: One second now we can get started. Yeah. I mean, sorry if
there's a bit of background. I'm in a cop shop. Should be okay. But, just
let me know and maybe Harrison can take over is really bad, but I've got my
heads arms. Should be okay. Yeah. Okay.

Andrea D'Intino: is I'm joining.

Will Abramson: I hope so. I don't know. I think he usually joins a little
late. So, I mean, we can just get through the admin. Manu needs this,…

Andrea D'Intino: Yes. Perfect.

Will Abramson: but here he is. welcome to the CCG call. today we got Andrea
and Yarm presenting on multikey and multibase ver verifiable credential
implementation. before I hand it over to them just a brief review of our
standard material. So please everyone review the code of conduct and can I
say that wrong? Code of ethics and professional conduct.

Will Abramson: we like to have a warm friendly environment here and treat
people with respect try to hear from the other people's perspectives all
that sort of stuff I think basically just continue doing as we have been
doing so that's great IP note anyone is welcome to participate in these
calls however substantiative contributions to CCG work items must be made
by members of the TCG with full IPR agreements signed if you have any
questions about that, just reach out to one of the chairs and we'll be
happy to help you. these call notes will be shared and recorded and
available on the mailing list thanks to Harrison mostly in 24 hours. And
then we'll just do a brief round of introductions or…

Andrea D'Intino: Should we get started?
00:05:00

Will Abramson: reintroductions. Anybody want to say hello to the community
today? We'd love to hear from you. hang on. I just give people a little
sec. I think it's probably not there. Nobody gave us introduction or
reintroduction. It's quick pause for announcements and reminders. And I'll
just go first and say a little thing. so I guess I will briefly apologize
not with much deep apologies but for last week maybe it was a bit left
field of me popping into the call and saying hello for a few minutes but I
just wanted to say hi from the GDC and share some appreciation so hopefully
that's okay. It was meant with kind intentions. with that Manu I think you
were first. Go for it.

Manu Sporny: Yeah, just a couple of things that have come up on the mailing
list. there's this kind of circulation about do we want an updated CCG
website? that's out there. Good discussion happening there. the mascot
discussion is kind of a part of that as so that's happening right now. and
then the third thing is that there is a proposal for a new work item
verifiable credentials over wireless that has been put out there. I know
Brent's got a question on it. I know Greg's stepped forward to help edit
and Harrison supporting. So it'd be good to hear from other folks if they
have verifiable credentials over wireless use cases.

Manu Sporny: the incubation calls are happening tomorrow. VC API call
happening later today and data integrity call happening at the end of this
week where we're doing a lot of the postquantum work that Andrea and Yarm
are going to talk about. That's it for me. Thanks. Yes.

Will Abramson: Yeah, great.

Will Abramson: Thanks, A couple of things. Could you drop a link to the
work item or the proposal because I think basically this is announcing it
to the group, and please people review it if you care and if you want to
object to it, as you can probably by next week I imagine we're going to
adopt it because it seems to have broad support from the community. So
yeah, just notification. and also thanks for all the work on the website.
I'm totally game to do it. It looks great. let's continue the discussion on
the mailing list.

Will Abramson: I guess the only thing I'm hesitant about is putting another
thing on your plate, manu how do we make sure that doesn't happen because
always person who creates the website has to be responsible for it or ends
up being responsible for it. So okay clear and then we'll hand over to

Kaliya Identity Woman: IW is coming up in the fall. our dates are the last
week of October before Halloween weekend. I think it's the 27th to the
29th. And we also have our digital identity unconference Europe. Those
dates have moved. they were going to be the first week of September and now
there we're looking at moving it to late November time frame. So that's
just a community update. I'll put a link to the IW website. and thanks so
much

Will Abramson: Thanks, Wonderful. over to you guys. Andrea, go for it.

Jaromil: I'll start and then Andrea will take it from where I live and
after 18:30 I will be in and out. So if it's needed for the last Q\&A I
will pop back in. so I'll be brief with my part. Initially this
presentation was about our implementation of verifiable credentials. We
thought we wouldn't make it for all of that. So we said multi key is the
part that we can for sure get done. but in the meantime with the delays we
managed to get done what we wanted.

Jaromil: So I'm happy to say that today I will share not only our
implementation limited to our use case of multi key multibbase but the
world demonstration of verifiable credentials and I know that Andrea just
made work verifiable credentials W3C verifiable credentials in our wallet
demo.

Jaromil: So you will be hands on. I start showing you this which is please…

Andrea D'Intino: What one more thing guys…

Andrea D'Intino: if we have some extra time I will quickly show you long
fellow losk integrated and then we'll tell you what we doing with it but
let's see if we have All right.

Jaromil: which is the Google zero knowledge which was released free and
open source in Geneva and yeah so I'll be brief on this part you see a link
in
00:10:00

Jaromil: the chat and literally this link is not just public documentation
but is what I pass to my colleagues at forbomb and dine to work on
verifiable credentials W3C. So this is both internal and external
documentation and the objective is to hold the hand while putting our hands
in the door hold the hand of integration engineers that want to implement
verifiable credentials and I'll share briefly if I walk through this page
as you can see there

Jaromil: are now three options and these are all related to W3C
credentials. the two ECDSA and EDDDSA So I will start with the most common
ECDSA on the P256 curve and show you our implementation down to the code
level. But don't be afraid because the code is readable is in Zen code and
it helps me to show you our strategy.

Jaromil: So in this case these are the three reference documents that I
think are most important to implement this and are very useful of course.
this is our key ring generation. I can skip over it. You can imagine this
is a generating a key pair and we go directly to the canonization so I use
the same examples on the specifications. This is so-called unsecured
document not signed yet. This is the key ring and I pass it to our code.

Jaromil: So the code somehow is walking you through what needs to be done
to an insecure document in order to get to a canon serialized form which
can be signed and yeah you see here there are a few operations to be done.
first of all create a proof config which is the unsecured document ready
for colonization which is the serialized form of a credential that needs to
be done so that the signature is applied to exactly the same serialized
form. So we create a proof config we copy the context from the unsecure
document proof config.

Jaromil: We write data integrity proof in a type inside proof config. And
then we write a string which we have did dine. So any will work in this
verification method. We move the verification method in proof config. We
write a string in this case of the signature that we are doing in We move
also cryptosuit in proof We write assertion method proof We move proof
purpose in proof config. We write a time stamp in this case we use the time
stamp of the example actually of the time in which I wrote this in created
and it could be generated real time and we move created in proof config. We
rename unsecure document to document. Then we print proof config and we
compute the canonization.

Jaromil: This is done this is a different zen code is like a cucumber
girkin so is a behavaldriven development language just given and then we
have an sion the extension compute is calling an external library because
we did not work on our own colonization we use first the library by walt ID
correct me if I'm wrong Andrea developed in Austria. then in Typescript
then we found out that it was not portable and so we pick the library by
our friend here Manusporne which is developed directly in JavaScript and
therefore we found that it was more portable.
00:15:00

Jaromil: So thumbs up Manu for the great development because you saved us a
lot of work and this runs also client side with your library. So we compute
the canonization calling this library literally on a document that we
output that we created we generated this way and this is the document. So I
created this context credential subject type and then all this proof config
which has also copied the context inside with all these strings that I
generated. I could have taken them from somewhere else with the language.
So what you're seeing is the output of the code and what you saw before it
was literally the code.

Jaromil: The colonization form is returned by the library in a B 64 format.
So this B 64 is the JSON can the canonized RDF form and someone wanted to
interject. Andrea you have comments. I go on with the s signature. I give
this same input to the signing code and I use this Zen code to sign I
import the cannon. Here you see a little bit in a few lines of code. What
needs to be done is u create the hash of the canonization.

Jaromil: create the of the proof config and of the document both in
canonized form and then we happen the document hash to the proof config and
we sign that according to the spec and this is the way we solve the
multi-ign part. we want to make it explicit. So rather than building a
implicit exporter in Zenode, we want to add the line and leave a comment
about it. I experimented with making exporting the multi- signature
exporting or importing the multibase and the multi key in Zenode.

Andrea D'Intino: Oops.

Jaromil: So far we only can import a multibase.

Jaromil: So you can say here I have a multibase named proof config in case
it will be a multibase encoded document then that will work but for the
rest we did not go in deep because it's really confusing from the point of
view of an implementation that already accepts B 64 to introduce all these
sort of prefixes. So we like to make it explicit In this case, we just
write in a new string proof value and we append the base 58 of the
signature to proof value. And this way it's a valid multi- signature for ES
256. this will be the output.

Jaromil: What we created here is the proof value which is the signature and
the verification is straightforward takes this same input and this is the
code. So the verification is supposed to take the basic 58 of the proof
value and here we have a statement after string prefix zed. This is the way
I read in this multi- signature rather than again implementing multi-
signature. yeah, we rename it to signature. we copy the context in proof.
we create the public key could be retrieved from a did in this case and
then we verify the signature.

Jaromil: in this case, first we canonized. So there's a first passage to
first one step to canonize again from the verifier point of view and then
verify. So once we have the canonical output here, I go quick quickly
through you can take questions. two observations here. One is that I
understand the reasons why we have multi- signature and multi key but I
must say that from an implementation point of view when you have a lot of
things coming to you already in a form that is generic but what they are.
So you see here we have a context of code in which we know what we're
getting in.
00:20:00

Jaromil: So we don't get a generic key because also we read from other
fields what is it the encoding the kind of signature. So we don't need this
information embedded in the data then it is not really helpful. we can work
around it but we don't use the attributes that are in the data as relevant
because who writes the zen code knows already what is being done with the
data and what should be done. and another observation is that the
canonization it is and I communicated this to colleagues also of W3C in
Geneva the canonization I believe there is a sense for it. So I'm from the
camp of people that supports its use.

Jaromil: I think ignoring the pitfalls that are not having a proper
RDFbased in this caseization of materials that are signed is it will bite
in the future. all those people that ignore its importance. but on the
other side I would like to see those libraries evolving in the direction of
caching in the RDF perhaps declaring how often the context is updated and
so to make it clear that it can be cached in the application and not call
home because as is the libraries they fetch the context.

Jaromil: So these URLs every time they do canonization it's up to the
implementtor to do that but it could be like a bit more facilitator or…

Jaromil: perhaps default to have them cached depending from how often they
are updated but I believe they are not really updated often so it's just
Okay.

Will Abramson: Sorry y I see man's got his hand.

Manu Sporny: Yeah, these are all great comments.

Will Abramson: Now's a good time.

Manu Sporny: So going back to the beginning, I have a number of comments.
I'll try to keep it brief. I think your approach with Zen Renoom is really
interesting, meaning that this is the first time we're actually seeing kind
of this declarative, way of creating verifiable credentials. I don't think
anybody else out there is doing that. And when you see kind of the steps
that are happening the Zen room language you can kind of see how simple the
steps are. so that I think is really interesting and useful to on the RDF
canonicalization and the fetching of contexts. right now we try really hard
in the specifications to tell people to not fetch the context. They should
cache them forever. They're not expected to change.

Manu Sporny: So all of your suggestion that we get to better defaults it
very much resonates. I think that's absolutely right. we really absolutely
should not be fetching these things in production systems. the contexts
that are out there as standards are never going to change. We're never
going to update them. Which means then the other thing that you said about
caching the canonicalization is also meaning that you only have to
canonicalize once and you can use what we're calling RDF templates or just
a templated language to just inject values into things that you're going to
sign which then means that you canonicalize once and it's ompiled and then
you can do tens of thousands of signatures a second and parallelize those
operations and all that kind of stuff.

Manu Sporny: in most cases there are some cases where you can't do that. so
I think you're right that's an area that we need to spend a little more
time. the other thing that you mentioned was the base encoding including
the Z prefix or the U prefix in the proof value. you're right that when
you're gen verifying a signature, the people that have written the
libraries know what they're expecting. And so that prefix doesn't really
help in that scenario. The reason we have the prefix is for other use cases
where we have generalized compressors of this data.

Manu Sporny: So for example in Seabore LD it will look through the document
for all the multibbase values and if it sees a multibase value it knows it
can compress that to a binary byte string meaning that it can then gain 33%
compression over base 64 because it knows even though it doesn't know what
this data structure is it doesn't know it's a verifiable credential or a
signature when it goes through to compress it goes I know this is a
multibase value which means that it is B 58 or B 64 URL and that means that
I can compress it down to a bite value…
00:25:00

Jaromil: Thank you.

Manu Sporny: into a seabboard byte string which means that I automatically
get 30% compression over the payload. and that is kind of one of the
advantages we're using to compress these things down so that they can fit
in QR codes or fit across an NFC connection. so you're You're absolutely
right that the crypto suite might not need that, but the compression tool
chain that sits above, benefits from it if we just include that tiny little
hint in there. That's it. but this is fantastic work.

Manu Sporny: Yarm and Andre, it's really exciting to see the progress on
this.

Jaromil: No, thanks Manu for your feedback…

Jaromil: because now I understand and you give me a good reason actually to
the multi- semant attributes to the data. It makes sense what you say. So
then you can have a con if there is any other interjection now is a good
time just in interrupt me. I mean I can just go quickly back it will be
super simple to show you post quantum credentials.

Jaromil: given this way of implementing things I posted it at the beginning
the postquantum is in the link in front it's this and…

Andrea D'Intino: Jarvin,…

Andrea D'Intino: did you post the link to this page? Yes. Cool.

Jaromil: consider what you have seen conforming to these documents so we're
using the lithium fips 204 and this draft which will be probably rewritten
and reworked very soon that we started for quantum safe crypto suits. What
you have seen before changes just like substitute P256 with MLDDSA44 and
the code works.

Jaromil: so the most interesting thing is seeing the keying of MLDDSA for
four being 5237 bytes so 5K approx and then here is the exact same thing
that I'm doing just I write MLDDSA RDFC 2025 in crypto suit and the
signature

Jaromil: ex will be done in zen code just saying this is canonizing here I
create the mlddsa 44 signature which was before the 256 or p256 signature
this part of zen code will change in zeroom 6 it will be also between the
quotes because we are implementing so many signatures in Zen room that we
will parameterize it rather than hardcode it.

Jaromil: So here you will create the quote MLDDSA 44 and any other flavor
and signature. So literally it's enough to change one word in the code.

Andrea D'Intino: There is a question.

Andrea D'Intino: There are two questions.

Jaromil: Yes, please.

Will Abramson: I don't know if I was first or man was but maybe we have the
same question. My question is exactly about less parameterization. I don't
know if you've seen in the data integrity work. I mean I've not actually
attended the call for a couple weeks but there's a discussion ongoing
around how do we revamp the data integrity spec to integrate some of that
parameterization into the spec writing itself. at the moment a lot of the
crypto suites or signature suites, whatever we call them these days,
ED25519 or SECP and stuff, they're all repeating the same text over and
over again. I think it'd be great to pull a lot of that text into the main
data integrity spec at least as a baseline that people can extend or
overwrite in their custom specs, but don't need to if they're just using
the same kind of algorithms.

Will Abramson: I don't know if you've thought anything about that,
especially since you said, you're implementing a bunch of different crypto
suites.
00:30:00

Jaromil: What I would recommend is to offer a easy way to diff the specs…

Jaromil: because for someone that has implemented already P256 then the
first thing is I would diff the specs and if the lines are at the same
eight so if it's easy if the diff is meaningful and minimize then I would
immediately see the few differences and knowing how to implement the other
one I would be very quick in implementing the next one it's not trivial I
know to make specs that are easily easy to be dipped and…

Jaromil: for sure you have to drop the lines and be very very attentive on
what you change

Will Abramson: Yeah. …

Will Abramson: Maybe I'll let Mario speak, but I think our hope is, we
would make it even better than just letting you diff the specs, but really
have most of the spec written in the core data integrity spec. And then
mostly all you do when you define a crypto suite is define a new signature
algorithm and…

Jaromil: Okay. Yeah,…

Will Abramson: a few different parameters, that's all you're doing. You're
saying, okay, we're using data integrity with SEC B26K1 or whatever, and
we're going to use the same hash algorithm that are using data integrity,
the same proof, all that sort of stuff to say. man, I don't know if you
have more context on that.

Jaromil: I got it.

Manu Sporny: Yeah, I mean plus one to…

Manu Sporny: what you're saying. I think what we're trying to do is create
algorithmic primitives in the specifications and reuse the primitives as
much as possible, which means that the implementers will then also end up
reusing the same primitives. So there'll be, a small set of primitives that
you reuse in every single one of these algorithms. and then that means that
the final specification you do get that diff at Yarmmill the only thing
that we need to specify in the final leaf specification is just the inputs
to the core algorithmic primitives things like that. So we are definitely
trying to move in that direction Yarl that you mentioned.

Manu Sporny: it probably won't be just like a sidebyside diff, but it'll be
kind of like a human readable diff, meaning you'll be able to go to the
leaf spec on MLDDSA, 44. You'll be able to just read the algorithms and
know that only the text here in that algorithm is new. everything else will
point back to a primitive algorithm that you've had to implement either for
the the ED25519 signature or things like that. So we are moving in that
direction. I think unfort and unfortunately the implementers are feeling
the pain right now because we haven't done that. in the future hopefully
it'll be better on that front.

Manu Sporny: But I do expect it to take us multiple months because that
kind of refactoring is just diff difficult to do. I put myself on the queue
for something slightly different. I noticed the encoding of the proof value
here. You're using base 58.

Jaromil: It's coming.

Manu Sporny: I would suggest we use B 64 URL in this case because B 58 has
an exponential compute. when you get past 256 or 512 bytes, it's just a
carryover, weirdness with base 58. The reason we use base 58 for public key
values is because developers tend to look at those and compare them and we
didn't want to accidentally create this misreading like you look at a
public key or the last five bytes of a public key and you misunderstand
zero for O or whatever L for one and things like that.

Manu Sporny: So the suggestion here is to use B 64 URL because that doesn't
have the computational issue and we are not expecting people to look at
MLDDSA postquantum signature sizes that are 5 kilobytes and…

Jaromil: Yeah. No,…

Manu Sporny: trying to visually inspect them. they're just too big.

Jaromil: exactly. Yeah.

Manu Sporny: But that's the only difference I see here from the
implementation we're wanting to do which is great. I mean I think we're
already very much aligned you've demonstrated it works and since you've
done an implementation and we're doing an implementation I think that is
enough to get through the global standards process.

Manu Sporny: So I think we're in good shape there. that's it.

Jaromil: Thanks. I'll align the B 64 URL.

Jaromil: Good suggestion. we have all implementations inside, but I like
more the B 64. It's more tested. I mean, the 58 by Luke Junior in Bitcoin
is a little bit like funky. I didn't know about this exponential
computation problem Good tip. yeah, if there is not anything else about
this part, I'm done. you can browse the code. there's Zen room boiler plate
how to include it. This is the gist of how we implement it inside. And I
take this documentation.
00:35:00

Jaromil: I gave it to our colleagues that implement the web or…

Jaromil: the mobile Andrea will be showing I think Android application in
preview. Yes, please.

Andrea D'Intino: I wish I'm fighting with it,…

Andrea D'Intino: but I can show it running on my phone if I'm lucky. But
yes, So, I want to show you two things. Let me see if I can run. doesn't
work. Okay, first of all, I want to show you that what JR showed you in his
presentation. we are implementing it in our identity wallet. I think I Can
I share my screen? Let me see. Present

Andrea D'Intino: and I want to share Some of you may know that we've been
working on this for a while. this year this has not been The focus of our
development is something that I haven't mentioned to anybody here. that's
something that we presented in Geneva and would pretty much present to you
but I don't think we'll have the time today. the other solution is about
conformance interrupt marketplace for identity. But we have been working a
wallet for a couple of years now. So if you go on did here you can get the
mobile apps which will not yet do what I'm going to show now because now
I'm going to show you a web deployment of the mobile app.

Andrea D'Intino: it's something we can do because of the technology we're
using for the UIX which is called capacitor.js I believe which allows us to
do user interface in/Javascript gold multiplatform and we can also deploy
as a web application which is something that speed up our development 100
times. So, if you go here, you might be able to even create an account, but
I'm just going to show you how I get a W3CVC 2.0 credential over open ID
for VCI draft 15. And this is something that has been running for the first
time today. So, it's already a little miracle that I got it run.

Andrea D'Intino: Let's see if I can get it running once more. Give me a
second. All right. So, this is a web deployment of the wallet in a few
days. Yeah, we're going to push it to the stores. So, if you download the
wallet in a couple of days, this should be working. And we're also still
working on the verification that's going to be done next week. So, for now,
to get a new credential, I can do this. Can you read?

Andrea D'Intino: So this is a credential offer for VCI latest version that
dev dot this one that credential issuer.

Manu Sporny: Yes.

Andrea D'Intino: So this is the credential issuer and then we have hold on
a second because I don't remember it by heart this. So, okay, I already
made a mistake.
00:40:00

Andrea D'Intino: So this is the well-known of our current test issuer that
can offer two different kind of credentials where one is as the jot and the
other one is LDPVC. So what I'm trying to do here, okay, I have to log in
again and I have to go to do this and scan This is obviously a fake scanner
when I am online. So here I am asking this issuer to get an authorization
code for a credential named fake P.

Andrea D'Intino: So we messing up with formats. We know that is an LDR
thing, but that was the fastest thing for us to do. I go further and
something is happening. I can actually show you what happens in the console
and later in the storage. I think that this is more interesting
application. So here we basically use the local storage while obviously
Android and iOS we use something else but here you can see what is being
stored and right now we have capacity stores. So those are the credentials
currently stored by the wallet which is empty. Now I'm asking to get a
credential that it's going to contain my name. Hello world.

Andrea D'Intino: And I press on authenticate. And if everything goes I
should be getting something is happening. Yes, that's the credential that
we got which got stored here. Let me see if I can share it a bit better.
Okay, so this is what came out of the issuer.

Andrea D'Intino: LDPVC configuration context credential subjects family
name hello world given name Andrea participation true because this is
something that we will demonstrate at the summer school at ubc.ca next
week. This is still rolling. I don't know why but the credential got
stored. It's probably because my computer is horribly slow and the issuer
created this. We all know about proof value. This should be canonized
already. So this includes what JR has showed you before. this is the
verification method. This is probably the public key of the issuer. Yes.

Andrea D'Intino: Did D sandbox generic column this type verifiable
credential ID credential valid until yes so that's the credential we go let
me see if I close this and reload if I can show the credential in the
wallet in a card this is happening because let me turn off my camera. Maybe
it's going to help. All right. Yes, it is the one that we just got. It
expires one year from now.

Andrea D'Intino: and in one year last two three minutes that's the content
those are the claims so we chose to issue the credential over open ID for
VCI draft 15 because the actually draft 16 is out draft 15 should have been
the final one but apparently not the final but it's because as you know
guys we're based in Europe And here when you talk about it And it's all
about ADRF which requires open ID for VP. manu we had a very very good look
at VC APIs and I'll ping you later to explain we don't know exactly what
people use on your side of the pond as transport protocols.
00:45:00

Andrea D'Intino: So of course we know about bitcom about carry but we miss
the big picture of which are the transport protocols that are mostly used
in the US. We would very like to know that. So this thing that is now
running in the browser before next Tuesday you will see the wallet in the
stores for Android and iOS and we also have a web-based verifier that I saw
working today but it's 12 I don't want to show it it's also going to work
next week and in the next couple of months we will integrate this in the
dash

Andrea D'Intino: dashboard of our wallet solution which I don't think I
want to show today because it would take too long. Good. Manu has a
question.

Manu Sporny: Yes, that's all really really wonderful to see. I noticed I
think the wallet's AGPLV3. What's the license for the wallet?

Andrea D'Intino: Everything we do is open source. AGPLB3. Yeah.

Manu Sporny: Okay, brilliant. the other thing I wanted to invite you to is
the VC playground has some wallets and we're adding more wallets to it.
because you can speak, ID4 VP and support the verifiable credential format,
you should be able to integrate just right away with, VC playground.

Manu Sporny: So, we'd love to list you at the bottom of that playground,
once you get the wallet into a state where you're happy with, stability and
that sort of thing,…

Andrea D'Intino: That would be very nice.

Manu Sporny: but just offering that Yes.

Andrea D'Intino: I guess you're referring to the webbased version of the
wallet.

Manu Sporny: Although the native one should work as well. either one should
work.

Andrea D'Intino: The next thing I want to show you which I would guess that
most people are most excited about is our integration of long fellow Z so
at our story with long fellow Z key is the following. We had a student
helper that went off to do some research at university.

Andrea D'Intino: very very bright young man who has been helping us
part-time for about a year who basically last January came back to us and
say guys I was at a conference and I saw something interesting and he
actually saw Mattel Frigo presenting long we looked at the paper around a
week later I pinged him on LinkedIn and he was super kind and super
available so we had a first call where explained us what the paper was
about, the story behind it and he mentioned that soon there would be some
open source code available. between April and the beginning of May we were
invited to the then closed GitHub repo which should be this one Google.

Andrea D'Intino: Yeah, this one which was open on the day of GDC. So I
guess it was last Wednesday or something. I'm going to post the link here
to those who haven't seen it yet, even though I believe that most of you
have seen it. So we looked at it first in the beginning of May I think and
in those days I was at a conference in Berlin called EIC where I met some
guys from Bulkai being the German mint. those guys are pretty advanced with
everything they do. So I asked them if they were looking at Longfellow and
they said they were also looking at fellow. At the same time I spoke with
Italian mint and they were also looking after Longfellow. for those of you
wondering what the Mint has to do with this.

Andrea D'Intino: So here in Europe as the national mints are not printing
money anymore because the ECB in Frankfurt is printing money for the whole
of Europe. So the mints pivoted to printing ID cards and passports and now
wherever there is a mint which is not in every European country but
wherever there is a mint typically the mint will be the one issuing P IDs
so the personal identifiers for the Audi wallet. So therefore people the
ones that are they usually collaborating with somebody else but they're the
ones on the forefront of Audation.
00:50:00

Andrea D'Intino: So long story short, I came back to Jarl who has already
been studying the code and I told him that I thought this was relevant and
getting some traction. So we did literally a marathon and within a few
weeks we got long fellow integrated into Zam which wasn't easy because Zam
is written in which wasn't easy and it's not completed yet. So Longfellow
is written in C++ while Zenum is written in C. So there was a lot of work
to be done on the tool chain which is still not complete because we wasn't
trans compiling yet. So I cannot yet get long fellow to run here in the
browser. we hope that we'll get there in a week or two. Anyway, what we
focused on was

Jaromil: Interesting trivia while I'm doing Andrea mentioned Mateo Frigo.
We recognize him because he's the author of the fastest four transform in
the west.

Jaromil: FFTW3. Maybe someone from the DSP knows it. Anyway,

Andrea D'Intino: …

Andrea D'Intino: we did rush to Longfellow into Zen room. we focused
initially on having it running in Android. So we worked on packaging on
building static libraries in the four AI targets that Android requires and
you can see the result in here.

Andrea D'Intino: I believe that Jeremy is it already merged? So if they got
Okay,…

Jaromil: Yeah, Andrea, it's merged and that's why we have some builds
broken.

Andrea D'Intino: good. No,…

Jaromil: But yeah, we are fixing Android and iOS and…

Andrea D'Intino: Jeremy is not merged because of the size because long
fellow is seven megabytes.

Jaromil: it's merged but it's not built as a release.

Andrea D'Intino: Okay. All right.

Jaromil: So, yeah.

Andrea D'Intino: CI we don't build it yet.

Jaromil: I have fusions.

Andrea D'Intino: When you will see this growing from three to seven. I have
a custom build. we revamped an Android app that you can see here and it was
obviously running on my machine last week, but it's obviously not running
now. So, I tried to run an emulator, but it will crash. and I don't want to
know why,…

Andrea D'Intino: but it works on my phone.

Jaromil: Two interesting things on Long Fellow just to connect it to the
theme of verifiable credentials.

Jaromil: One is that the proofs are 350K big and the other one is that
stepping into this world of zero knowledge working with legacy
infrastructure which is very interesting. I think that we need to update
some of the specifications to include the presence of proofs that are not
exactly signatures and…

Jaromil: should be treated differently because they are considerably big in
size. 350K compressed with the ZPD.

Andrea D'Intino: Yes, that I can show in a second.

Andrea D'Intino: So, we've been focusing on having a long fellow running on
Android as well as in a micros service. So, Android I cannot show you here,
but if I'm lucky, I can show it running on my phone. okay. can you read it?

Manu Sporny: We can see it. Yep.

Andrea D'Intino: All So, I'm going to tap on long file of ZK here, and this
comes up. So what you read here is the actual code at some point it
generate The code reads when I create the proof of okay let me try that
stop presenting.
00:55:00

Jaromil: Andrea, stop sharing the screen.

Andrea D'Intino: Okay, tell me if you can read this.

Manu Sporny: Yes. No,…

Andrea D'Intino: So that is the actual code. is my screen flipped?

Manu Sporny: it's good.

Andrea D'Intino: In keys we have hidden the circuit. We could actually
generate the circuit on Android but we wouldn't go through the pain of
storing it. So anyway we just build it outside and put it in Android app.
And here you see the data that we are sending to fellow K. Sorry, let me
open it again.

Andrea D'Intino: So here I am showing you just the data and if you scroll
with your eyes at some point you find an object called document and
document is the M do that is fed to long fellow ZK there is on top okay the
interesting things are transcripts which I'm not exactly sure what it is JR
knows and that's good enough for And then you have a public key and then at
some point you have the document. So I'm going to scroll down to show you.
So most of it is the MDO file. Then I press on execute zode. No. Yes. check
out. It took less than a second.

Andrea D'Intino: And if you read the I think is hold on a second let me see
parameters. Okay if you read around here you read Z K and Z K is the proof.
Okay I'm going to scroll down to show you the size of this monster. It's
very big. Yeah. Okay. You get an idea. look at a scroll bar on the right
side. Yes. So, this is the Android app. in a second, I'm gonna post you a
link to a LinkedIn post where you can get the app iled. You can download it
compiled. there is the link to the GitHub repo. Then there is the link to
the microser that I'm going to show you in a second along with the w of the
microser.

Andrea D'Intino: So what we did here is that we also implemented a rest
call that calls our micros service that verifies online which I'm going to
activate by pressing this. Here we go. And that's the result. So you read
the URL of the microser with the ver verification and you read the time
stamp and it says okay. It's funny. I see the screen flipped, but if you
don't see it flipped, then it's fine. All right, let me paste this. So,
yeah,…

Will Abramson: Yeah, just a quick interrupt. There's just a couple minutes
left, so you can add more, but maybe to wrap it up soon.

Andrea D'Intino: I'm good.

Will Abramson: Yeah, you share your links or…

Andrea D'Intino: Go ahead.

Will Abramson: did you already share?

Andrea D'Intino: You can get the Android app compon I'll show you in a
second micros service ripple Okay,…

Will Abramson: Yeah, Yeah, thanks for very interesting in depth stuff. What
is the size of that proof you were sharing?

Jaromil: about 350k.

Will Abramson: 360K. Okay.

Jaromil: Within due time, I also finished my humus.

Andrea D'Intino: I'm going to share my screen again. I p I ed paste the
link.

Will Abramson: Nice. Yeah.

Will Abramson: The LinkedIn link, right? Yeah.

Andrea D'Intino: Yeah, this is the micros service. Here we go. So what you
see here is you read here code room is a binary that's whose source code
you can find here which embeds NodeJS at a certain version. So we compile
Node.js
01:00:00

Andrea D'Intino: JS into this application and then we build a small web
server around it and the main task of this no code room/ncr is to expose
zen room scripts. So here you have long title Z K. We have generate circuit
which I'm not going to click now because it takes 15 seconds. But I will
click on this. Here we have ompiled in the swagger the input that long file
expects and you can read a little bit better the transcript which I don't
know exactly what it is but it's J can explain what that is public key and
document document is the M do file again and this is exactly as long fellow
takes it in inputs the M do we're using

Will Abramson: Mhm.

Andrea D'Intino: is the one that they have in their examples in the long
fellow repo and it was produced in the spring funk competition. So it
contains an Audi P. So when I click on send API here I'm going to generate
a proof here just to show you what happens and what it looks like. Yeah,
here it's a little bit slower because we deployed it on a machine that has
under 30 other microservices, one gig of RAM, one core, something like
that. It's the simplest thing we could find. It's a machine to mess around.
It's my baby.

Andrea D'Intino: what I can do here let me copy this stuff and let's see if
I can show you the other side of the coin. So here of course we have the
verify proof REST API which needs parameters now public key ID transcript.
Okay, so that's what it needs as set case back equal one. Let me see if
this stuff is the same.

Andrea D'Intino: Come on. Yes. Doesn't want to collaborate.

Andrea D'Intino: So, parameters this we have to kill.

Will Abramson: Yeah. …

Will Abramson: we should probably ap, to cut you off, but just over time,…

Andrea D'Intino: Sorry..

Will Abramson: We will.

Andrea D'Intino: Just trust us that this works.

Will Abramson: It Looks deep and…

Andrea D'Intino: Yeah. Yes.

Will Abramson: complicated. Cool.

Andrea D'Intino: Three.

Will Abramson: No,…

Andrea D'Intino: So sorry last thing…

Will Abramson: no problem. Thank you so much for coming on here, both of
you. I really appreciate you sharing your work and all the work you've done
to, make these things work. Cool. s***.

Andrea D'Intino: because before we leave as I mentioned that this is still
up in the air but we will was working in next few days that's the next
thing we want to do meaning that we can run it inside HTML so in the web
and in the next couple of weeks if we're lucky. We like to put together an
SDK with examples for all the languages that we have bindings for being so
Java we have it already JavaScript, Python, Rust,…

Will Abramson: Great.

Andrea D'Intino: Go, Cotlin, Yeah. So we will publish an SDK with all the
examples to integrate whatever you want.

Andrea D'Intino: No,…

Will Abramson: Yeah, when you do that, maybe you could share it on the
mailing list. That'd be excellent.

Andrea D'Intino: absolutely. Thank you.

Will Abramson: Okay, with that, thanks everyone for joining. Sorry we went
a little bit over, but have a great rest of your day and a great week. See
you next week. Thanks. Yep. Thanks, Andrea. Next,

Andrea D'Intino: Bye, guys.

Jaromil: Cheers. Bye everyone.

Harrison Tang: Thank you.
Meeting ended after 01:04:55 👋

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