[MINUTES] VCs for Education 2025-05-12 from meetings@w3c-ccg.org on 2025-05-12 (public-credentials@w3.org from May 2025)

From: <meetings@w3c-ccg.org>
Date: Mon, 12 May 2025 15:09:13 -0700
To: public-credentials@w3.org
Message-ID: <CA+ChqYeftm-4sWfhVEJfo4xPG9YDLcmDQkU7r=VzwviZCUZgYg@mail.gmail.com>

📝 Meeting Summary: VC ADU Task Force - May 12, 2025 Summary

The VC ADU task force meeting discussed advanced UI considerations for
verifiable credentials (VCs), focusing on challenges related to duplicate
credentials and credential deletion in edge wallets. The discussion also
covered public links for credential sharing and briefly touched upon future
discussions on VC updates.
Topics Covered:

*Handling Duplicate VCs:* The group explored definitions of duplicate
VCs (byte-for-byte identical, same content/different timestamps, same
ID/different content, no ID). Different strategies for identifying and
handling duplicates in wallet databases were discussed, including using the
VC ID, assigning random IDs, or using deterministic hashes (like the
signature value). Implementers shared their approaches, highlighting
varying levels of duplicate detection and user prompting.
-

*Deleting VCs and Attachments:* The complexities of deleting VCs in edge
wallets were examined, particularly concerning the handling of duplicate
credentials and associated attachments. The analogy of Unix file system
links (soft and hard links) was used to illustrate the different approaches
to managing multiple references to the same credential data. The
implications for user interface design were emphasized.
-

*Public Links for Credential Sharing:* The functionality of creating
public links for VCs in edge wallets was discussed, focusing on the
implications of uploading a copy to public storage and managing the shared
copy when the original credential is deleted. The Europass wallet's
approach, which includes mandatory expiry dates and restrictions on
recipient actions, was presented as an example.
-

*VC Updates (briefly):* The need for future discussion on handling VC
updates (e.g., content changes, revocations, accruing information) was
noted.

Key Points:

- There's no single, universally agreed-upon definition of a "duplicate"
VC, leading to varied implementation strategies.
- Wallet implementers use different primary key strategies for their
databases (VC ID, random IDs, deterministic hashes).
- Deleting VCs in edge wallets presents challenges, especially when
handling duplicates and attachments. The user experience needs careful
consideration.
- The creation of public links for VC sharing introduces complexities
related to managing the shared copy when the original is deleted.
- The Europass wallet's approach to share links (expiry dates,
restricted actions) was presented as a case study.
- The topic of handling VC updates requires further discussion.

Suggested Next Steps:

- Create documentation (blog post or wiki section) on handling
unique/duplicate VCs and credential deletion.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-vcs-for-education-2025-05-12.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-vcs-for-education-2025-05-12.mp4
📝 Notes

May 12, 2025
Meeting May 12, 2025 at 10:59 EDT

Meeting records Transcript <?tab=t.cfse4n45vx56> Recording
<https://drive.google.com/file/d/1JrU24nXl5gvUbA-4yUVqVaQJ6L4D33LX/view?usp=drive_web>
Summary

The VC ADU task force meeting, led by Dmitri Zagidulin, covered advanced UI
considerations for verifiable credentials, including managing duplicate
credentials based on various identification strategies discussed by
participants like Ildiko Mazar and Kayode Ezike, and the complexities of
deleting credentials and their associated attachments in edge wallets,
drawing analogies to file system links as suggested by Ted Thibodeau Jr.
The discussion also touched on the creation and management of public links
for sharing credentials, as exemplified by the Europass wallet approach
described by Ildiko Mazar, and briefly mentioned future discussions on
handling VC updates.
Details

*Meeting Link Issue and Introductions* Ildiko Mazar noted that Dimitri
Zagidulin had initially shared the wrong meeting link, but a reminder was
sent, and Dimitri confirmed the correct link from the W3 calendar (
00:00:00 <#00:00:00>). Dmitri welcomed everyone to the VC ADU task force
meeting, emphasizing it's open to all but specification contributions
require W3C membership and IP agreement (00:04:04 <#00:04:04>). Colin
Reynolds reintroduced themself and announced the upcoming Badge Summit in
Boulder, Colorado, from July 21st to 24th, which will focus on implementing
verified credentials in education (00:05:23 <#00:05:23>).
-

*Badge Summit Details* Colin Reynolds described the Badge Summit as a
key event for discussing verified credentials in the education sector,
highlighting its low cost despite potential hotel expenses in Boulder (
00:06:41 <#00:06:41>). They mentioned a "LER petting zoo" at the end of
the three days of conversations, designed to engage with real solutions
like verified credentials and digital wallets. Dmitri Zagidulin endorsed
the Badge Summit based on their positive experience last year and shared a
link in the chat (00:07:50 <#00:07:50>).
-

*Advanced Topics in Verifiable Credentials* Dmitri Zagidulin introduced
the main topic: advanced considerations for user-facing UI in verifiable
credentials, stemming from implementer questions and the MIT Digital
Credentials Consortium's wallet implementation experience (00:09:01
<#00:09:01>). The discussion would cover issues like handling duplicate
credentials and the process of deleting them, with a potential discussion
on updating VCs if time allowed (00:10:26 <#00:10:26>).
-

*Handling Duplicate Verifiable Credentials* Dmitri Zagidulin raised the
issue of duplicate verifiable credentials, explaining that duplicates can
arise from multiple scans of QR codes or repeated clicks on download links (
00:11:45 <#00:11:45>). He questioned what constitutes a duplicate,
ranging from byte-for-byte identical credentials to those with the same
content but different timestamps or issuance details, and also those with
the same ID but different contents or no ID at all (00:13:04 <#00:13:04>).
Dmitri then asked wallet implementers about their primary key strategy in
their databases for storing credentials (00:16:07 <#00:16:07>).
-

*Credential Identification Strategies* Dmitri Zagidulin discussed
various approaches to uniquely identifying verifiable credentials in a
wallet's database, including using the verifiable credential ID, assigning
a unique random ID, or employing deterministic hashes like the signature
value. He highlighted the initial naive approach of using the VC ID which
led to issues with credentials lacking an ID (00:17:31 <#00:17:31>) (
00:25:43 <#00:25:43>). Ildiko Mazar explained that the European wallet
uses the mandatory unique identifier of RVCs and prevents duplicates by
issuing an error message if a credential with the same ID is encountered
again (00:18:54 <#00:18:54>). This policy means their wallet cannot
ingest credentials without a VC ID (00:19:57 <#00:19:57>).
-

*Alternative Duplicate Handling Approaches* Kayode Ezike described their
approach of using JSON canonicalization to check for semantic duplicates
before adding a credential to their store, and they use a randomly
generated UUID as the internal ID. Dmitri Zagidulin mentioned that the
Learn a Credential wallet initially used VC ID but now likely uses a
composite approach: the VC ID if present, or a hash (potentially the
signature) (00:21:52 <#00:21:52>) (00:24:19 <#00:24:19>). He pointed out
the complexities of handling credentials with the same ID but different
contents, or same contents with differing timestamps or expiration dates,
suggesting wallets could prompt users to replace older or expiring
credentials (00:25:43 <#00:25:43>) (00:28:38 <#00:28:38>).
-

*Wallet Behavior with Duplicate Credentials* Dmitri Zagidulin summarized
that when a duplicate VC is encountered, a wallet could silently ignore it
if byte-for-byte identical, store another copy, or prompt the user (
00:36:34 <#00:36:34>). For credentials with the same ID but different
contents, storing both might be reasonable. The Learn a Credential wallet
prompts the user if a similar credential exists, allowing them to choose
whether to store another copy (00:37:42 <#00:37:42>).
-

*Deleting Verifiable Credentials and Attachments* Dmitri Zagidulin
transitioned to the topic of deleting verifiable credentials, particularly
in edge wallets where the credential is only stored on the user's device (
00:39:06 <#00:39:06>). He raised questions about handling duplicates
upon deletion – whether deleting one should delete all copies or prompt the
user. Ted Thibodeau Jr introduced the concepts of soft links and hard links
from Unix file systems as a way to think about managing multiple references
to the same credential data, highlighting the implications for deletion (
00:40:29 <#00:40:29>). Dmitri emphasized the user interface challenges
of displaying and managing potentially duplicated credentials (00:42:51
<#00:42:51>). The discussion extended to handling attachments associated
with credentials, such as PDFs, and whether deleting a credential should
also prompt or automatically delete these attachments, drawing an analogy
to email clients (00:44:08 <#00:44:08>).
-

*Public Links to Verifiable Credentials* Dmitri Zagidulin discussed the
functionality of creating public links to credentials in edge wallets for
easier sharing, noting that this involves uploading a copy to public
storage and informing the user of the implications (00:48:23 <#00:48:23>).
He raised the question of what should happen to the publicly shared copy
when the original credential is deleted from the wallet, comparing it to
sharing and deleting files in cloud storage like Google Drive (00:51:06
<#00:51:06>). Ildiko Mazar described that in the Europass wallet, share
links have mandatory expiry dates and restrict the recipient's actions to
viewing the content and verification status, without allowing JSON-LD
download or resharing (00:53:21 <#00:53:21>). Dmitri noted that this
approach of server-side verification for shared links differs from the
general verifiable credential model that emphasizes independent third-party
verification (00:54:50 <#00:54:50>).
-

*Updates and Further Discussion* Dmitri Zagidulin briefly touched upon
handling updates to verifiable credentials, mentioning that while the
refresh service can be automated, other types of updates (content changes,
revocations, accruing additional information) and the distinction between
everything-at-issuance and accruing methods would be topics for future
discussions . He thanked everyone for their participation and encouraged
further conversation on the mailing list .

Suggested next steps

- [ ] The group will create documentation on the discussed topics
regarding unique and duplicate verifiable credentials and credential
deletion, potentially as a blog post or a wiki section on the DCC site.

*You should review Gemini's notes to make sure they're accurate. Get tips
and learn how Gemini takes notes
<https://support.google.com/meet/answer/14754931>*

*Please provide feedback about using Gemini to take notes in a short
survey.
<https://google.qualtrics.com/jfe/form/SV_9vK3UZEaIQKKE7A?confid=rO04c0qV6I6xFNhaFUWCDxIUOA8MCwMyBwiKAiAAGAEI>*
📖 Transcript

May 12, 2025
Meeting May 12, 2025 at 10:59 EDT - Transcript 00:00:00 {#00:00:00}

*Ildiko Mazar:* Hello. Hello again. This time there will be a crowd.
*Ted Thibodeau Jr:* I'll hold you to it.
*Ildiko Mazar:* It's I just picked up Dimitri's message and I think he
quite simply shared uh the wrong um meeting link. So I just sent a a
reminder to the group and him. So he should be uh here. Yes, he is. Hello.
Yeah, that's better than last week. Hello.
*Dmitri Zagidulin:* Why? I had the wrong link, but that's good to know.
Thank you so much, Eldico.
*Ildiko Mazar:* No problem at all. I hope I have the right link, but uh I
have this uh uh from from before and Ted was here too. So I think this is
it. But
*Dmitri Zagidulin:* Right
*Ildiko Mazar:* I'll
*Ted Thibodeau Jr:* This
*Dmitri Zagidulin:* on.
*Ildiko Mazar:* check
*Ted Thibodeau Jr:* is
*Ildiko Mazar:* too.
*Ted Thibodeau Jr:* this
*Dmitri Zagidulin:* Right
*Ted Thibodeau Jr:* is
*Dmitri Zagidulin:* on.
*Ted Thibodeau Jr:* the
*Dmitri Zagidulin:* Right
*Ted Thibodeau Jr:* one
*Dmitri Zagidulin:* on.

00:02:18

*Ted Thibodeau Jr:* in the W3 calendar. So
*Dmitri Zagidulin:* Perfect.
*Ted Thibodeau Jr:* hopefully
*Dmitri Zagidulin:* That's That's important.
*Ildiko Mazar:* Yeah.
*Dmitri Zagidulin:* A minor minor friction when switching to a new uh
*Ildiko Mazar:* Of course.
*Dmitri Zagidulin:* new platform. Oh, we're going to give a couple more
minutes uh for uh people to connect given the switch and then we'll get
started. Meanwhile, I'm going to change all my calendar entries here.
*Ildiko Mazar:* Yeah, that's the one thing that I couldn't quite figure out
and I might be just uh did a ton when it comes to technical issues, but uh
I couldn't import uh the calendar however hard I tried. So, it's a manual
entry for now.
*Dmitri Zagidulin:* Yeah, the calendar story is harder. had had these
questions for other task forces of the CCG.
*Ildiko Mazar:* And we're supposed to have transcription, but I don't see
where it is. It just says that it's being transcribed.
*Dmitri Zagidulin:* Yeah, I think uh it I think it's uh in an email to the
CCG somewhere. uh it might automatically make a pull request to the
meetings uh GitHub repo, but we'll we'll double check.

00:04:04 {#00:04:04}

*Dmitri Zagidulin:* Yeah,
*Ildiko Mazar:* Absolutely.
*Dmitri Zagidulin:* I suppose we could turn on the live captions. Yeah,
here we go. For those who like it, I suppose you could turn it on uh
individually. So, uh all right. Uh well, we'll we'll get started even if
people are filing in. Awesome. Welcome everyone to uh the weekly uh VC ADU
uh verifiable credentials and education task force of uh the W3C
credentials community group. Uh calls are open to anyone. Um you do not
need to be a member of W3C to participate. Uh however to contribute to
specifications uh you do need to be a member of uh W3C uh which also ju
just to be safe uh when you know when giving suggestions here in case you
uh ever have IP restriction questions. You probably want to be a member of
W3C and uh the CCG group and sign the IP uh requirement. Uh calls are
recorded uh and we are under the W3C code of conduct. I think that's all
the boiler plate.

00:05:23 {#00:05:23}

*Dmitri Zagidulin:* Uh any introductions or reintroductions? Do we have um
people that are that are new that I want to that want to introduce
themselves? For those of us uh just joining uh we're on the introductions
and reintroductions uh part. I noticed a couple couple new people stepped
in. Are there any community announcements uh upcoming conferences uh events
that we want and uh as always we ceue up by just raising your hand uh here
in um in Google Meet. same same mechanism as um as we did in Jity. Yeah. Go
ahead, Colin.
*Colin Reynolds:* Well, I'll say hello again and just uh try out the new
platform. I
*Dmitri Zagidulin:* Yeah,
*Colin Reynolds:* I apologize. I I missed the last week. I think mostly
because I hadn't updated the Google Meet link. Um so,
*Dmitri Zagidulin:* no worries. We didn't have call last week anyways.
*Colin Reynolds:* oh okay, great.
*Dmitri Zagidulin:* All
*Colin Reynolds:* Um
*Dmitri Zagidulin:* good.
*Colin Reynolds:* well, Badge Summit is coming up in Boulder, Colorado in
July, uh July 21st to the 24th.

00:06:41 {#00:06:41}

*Colin Reynolds:* for Americanbased folks. I think that's a big big place
for us to get together and and talk through the implementation of verified
credentials in the education space at scale. I I know that's a a higher
education focused engagement, but uh that's certainly a big one that's on
uh education design labs radar as well as as many others. So, I just will
throw that out there. And it's a very lowcost uh conference to attend. It's
probably more expensive to get to just because Boulder is a pretty small
town and doesn't have a ton of hotel options, but um if folks uh need I
think there's a list of hotel blocks on the on the website, but that's a a
big conference coming up where we'll jam on a lot of this. And I think a
big focus that Noah Geel um he's the coordinator planner of all of it is um
the LER petting zoo, which is what he's calling it. So it's uh intended to
be I think at the end of um so there'll be TLN is also opening the trusted
learner network from Arizona State is also hosting their unconference there
uh on that Monday.

00:07:50 {#00:07:50}

*Colin Reynolds:* So there'll be three days of of conversations and at the
end of it then the LER petting zoo which is I think designed in a way that
should build on what people have learned throughout the week to then engage
with some some folks in a real meaningful tangible way uh with some of the
solutions that they're providing including verified credentials, digital
wallets, comprehensive learner records, that type of thing. So uh I just
wanted to put that out there for the group.
*Dmitri Zagidulin:* Thank you so much. Yeah. Uh want to plus one to that. I
attended badge summit for the first time last year and it was uh it was a
really uh helpful experience. Uh looking forward to it this year. Uh uh
paste a link uh to the badge summit in chat here uh just in case. Instead,
go ahead.
*Ted Thibodeau Jr:* That was all I was going to ask for is link.
*Dmitri Zagidulin:* Yeah, we want the link. Um, all right. Thank you. Uh,
okay. Uh, so our main topic today, unless uh there's anybody else who wants
to do introductions or announcements, our main topic today is, uh, let's
talk about some advanced topics in verifiable credentials, especially when
it comes to userfacing, uh, UI.

00:09:01 {#00:09:01}

*Dmitri Zagidulin:* Um part of it is just uh questions that we've gotten
sort of over uh over time from implementers and part of it uh this is based
on the experience from uh MIT's digital credentials consortium team uh just
in having uh implemented a u an open source VC wallet. The these are the
internal discussions we had. These are the uh problems we bumped up
against. Uh and we wanted to sort of surface the discussion here. uh one uh
just because those of you who are impleers might be interested uh in the
topic uh to get some input from uh from the group uh because it's it's an
interesting topic in general. So let me share my screen. Uh and also I just
posted a link to the slides in in chat. All right. Can everybody see my
screen? Actually, you know what? I'm going to going to join from another
from another computer as well so that so that I can keep an eye on the chat
in um while while sharing screen in full full screen mode.

00:10:26 {#00:10:26}

*Dmitri Zagidulin:* Give me just a second. We'll get started. Here we go.
Here we go. Excellent. Okay, I should be able to I I see the chat now. All
right. So, yeah. Um, we wanted to talk about to to put out some interesting
questions about, uh, what does it mean to have, uh, a unique or duplicate
verifiable credential and what happens when user has a credential in their
wallet and they click delete this credential. Uh, and yeah, so that that's
the kind of stuff uh that we want to talk about. And if uh if we got time
uh in the discussion today, I want to approach the subject of hey, how do
we handle updates to VCs? Because that's a frequently asked question um
that that we get when introducing the concept of verifiable credentials to
somebody uh that we'll get into. All right. So let's start start with this
uh what happens when you have a credential in a wallet and a user adds
another duplicate credential to it right so another copy of it.

00:11:45 {#00:11:45}

*Dmitri Zagidulin:* So first and this is again very very real um issue that
any uh wallet implement uh deals with. So first of all what do we mean by
duplicate and why would duplicates be uh why would they be happening? Uh so
one depends on how your users add credentials to your wallet, right? A lot
of wallets offer the ability to scan a QR code uh to add a verifiable
credential or to click a download link and and uh get a credential in uh
into a wallet. Plus there's NFC tabs, all sorts of uh all sorts of methods.
And so one of the one of the things imagine you have a link to uh to a QR
code for a credential that's uh hosted somewhere and a user happens to scan
it twice, right? happens all the time. Just like uh there's duplicate form
submissions in uh any sort of form on a website and since time in memorial
developers had to come up with various uh safeguards of how do you prevent
a form being submitted twice? Well, you disable the button uh you put a
little spinner so that the user doesn't double click.

00:13:04 {#00:13:04}

*Dmitri Zagidulin:* But even with that, you have to check for duplicates on
uh on the server side. this the same sort of thing. So first of all, what
do we mean by duplicates? That's that's part of the reason that uh we
wanted to bring up this discussion uh here because it's an interesting
topic. Verifiable credentials are are complex uh complex field, complex
data model and it turns out we could mean several things. One is it could
literally be a bite forbyte identical verifiable credential. Like literally
there's a credential in a QR code. Let's say it's embedded in there. But
even if it's hosted on a cloud and the user scans the same credential
twice. It's not a dynamic issuance endpoint, right? So so two VCs are not
issued twice or not signed twice. They're issued once, but a user pick
picks up a credential twice. Right. What so what should happen then? What
about when it is a dynamic issuance endpoint? Right. Right.

00:14:14

*Dmitri Zagidulin:* So, so user happens to scan a QR code several times uh
and each time the wallet goes through a uh uh uh verifiable presentation
issuance protocol handshake with with the issuing server and the contents
of the credential is the same. ment. So the only thing that that that
changes is the created timestamp on on the signature, right? So let's say
I'm picking up a course completion credential. It's the same course. I just
uh just finished it and uh I click on the link twice and my wallet picks up
uh two freshly issued uh credentials. What should the user see in that in
that case? Well, so part of it is of course uh server side the pick up your
credential application could be coded as such that uh to to help minimize
or prevent this. But it's still it's still very possible uh that a wallet
either uh there's a transmission glitch and the wallet retries or whatever.
So what should happen should it hap uh should uh that case be encountered.
Now, what about a very different use case where you're not picking up the
same copy where two different verifiable credentials are issued with the
same ID and we're going to talk about uh the verifiable credential ID uh in
just a second.

00:16:07 {#00:16:07}

*Dmitri Zagidulin:* And and what about And what about those credentials
that don't have an ID? The the things that we we call bearer credentials uh
that and then there's two copies of of say credential with the same
contents uh but maybe with slightly different time stamps otherwise they'd
be bite for by identical PCs. So I I'd love to hear some thoughts uh from
um from the group or actually let's let's talk about uh let's talk about
ids for a second. Uh those of you who have uh implemented verifiable
credential wallets uh I'd love to hear what do you use as the primary key
in the database when you store a credential. So the easiest easiest thing
uh when dev teams first encounter verifiable credentials is to be like all
right we can just use the verifiable credential ID. So that's that's what
happened to us a developer uh implementing it was creating the table
structure for the internal database and the wallet and and again we we have
what is known as an edge wallet which means there's no cloud component that
uh verifiable credentials are stored only on a mobile device.

00:17:31 {#00:17:31}

*Dmitri Zagidulin:* Right? So there's an internal database in in the phone
uh in the mobile app that stores each incoming verifiable credentials. So
the question is how do you uniquely identify that credential? So the the
first iteration uh the developer doing this was like I'll just use a
verified credential ID and you can immediately see that what happens when
uh it receives a credential that doesn't have an ID and and the answer to
that is it was a bug. Uh there were a bunch of credentials with the ID of
undefined uh which is which is JavaScript jargon for when the field is
missing and it led to some funny behavior. All right, another thought is uh
you can assign it a unique random ID or an auto incrementing integer. Uh
which is great and that it prevents collisions. Uh but it also means that
you can have any number of copies of the same credential in your database.
And and lastly you there is a class of techniques of forming ids uh that is
called uh deterministic uh hashes.

00:18:54 {#00:18:54}

*Dmitri Zagidulin:* I see uh Eldico has a in in chat question of updates in
what sense? So yeah. So so let's let's talk about that in just a second.
But let's um but first I want to ask uh those who who have implemented
wallets or uh just just think about it as a logic puzzle. How would you
store verify how would you uniquely identify a verifiable credential in uh
in a wallet? So any any takers? Ilico, go ahead.
*Ildiko Mazar:* Uh of course as you know I'm very happy to promote our
European digital credentials. So
*Dmitri Zagidulin:* Yeah.
*Ildiko Mazar:* uh first of all we do not have uh local databases. Uh what
we do is uh we have the uh various instantiations of uh the credential
issuer but once it's issued there are no there's no trace for uh just uh
the protection of uh the person's uh identity. And when it's deposited uh
into a wallet uh it's registered under the unique identifier that is a
compulsory property of RVCs. So
*Dmitri Zagidulin:* Now,

00:19:57 {#00:19:57}

*Ildiko Mazar:* uh
*Dmitri Zagidulin:* so,
*Ildiko Mazar:* every
*Dmitri Zagidulin:* so
*Ildiko Mazar:* one
*Dmitri Zagidulin:* wait,
*Ildiko Mazar:* of them
*Dmitri Zagidulin:* wait,
*Ildiko Mazar:* has
*Dmitri Zagidulin:* just
*Ildiko Mazar:* one. Yep.
*Dmitri Zagidulin:* ju just to uh just to clarify, we're talking about the
unique database in the mobile wallet, not on the
*Ildiko Mazar:* Ah
*Dmitri Zagidulin:* issuer. The it's
*Ildiko Mazar:* okay.
*Dmitri Zagidulin:* it's a given that the issuer doesn't keep track of it
for for privacy reasons.
*Ildiko Mazar:* Okay.
*Dmitri Zagidulin:* We're talking about in the receiving user's wallet. How
is it
*Ildiko Mazar:* Okay.
*Dmitri Zagidulin:* indexed?
*Ildiko Mazar:* And then so based on that uh unique identifier uh once you
would try to upload it twice or issue it twice you would receive an error
message that this credential already exists in the wallet. So uh there's no
it doesn't get overwritten. It's just a single copy of the credential
there. So that's how it works
*Dmitri Zagidulin:* got it. So that uh that means your wallets cannot
ingest credentials that don't have uh a verified credential ID.

00:20:44

*Dmitri Zagidulin:* Right.
*Ildiko Mazar:* It's correct.
*Dmitri Zagidulin:* Okay. And it's, you know, that that's a that's a
reasonable uh policy decision. It just so happens that the verifiable
credential specification does not require verifiable credential ID field.
And so there is a number of VCs out there that don't have a VC ID. So one
easy uh one easy decision is like like I mentioned is to not handle those.
And I'm assuming it gives um error if you try to ingest a credential
without an ID.
*Ildiko Mazar:* I have to say uh I never tried it because uh the uh Europas
wallet is part of a a bigger library where
*Dmitri Zagidulin:* All right.
*Ildiko Mazar:* uh one component is the wallet the other is just a regular
uh upload based library uh into
*Dmitri Zagidulin:* Yep.
*Ildiko Mazar:* which you can upload any other documents PDFs uh open
badges uh JPEGs uh scanned documents uh whatever. So one way or another the
user is able to store them. What happens if you try to open or upload a
credential that is VC but doesn't have an identifier?

00:21:52 {#00:21:52}

*Dmitri Zagidulin:* Excellent. Yeah. And uh you it'll be interesting to uh
to hear what uh once you do check what happens. Uh and you know I'm
realizing as part of this discussion uh what we could what we could do here
at BC Edu is uh create a list of example verifiable credentials that people
could just test on right so we can we can create a verifiable credential
without an ID that people can ingest into their wallet and just see what
happens uh other other implementers who who's got uh who's got questions
comments on this uh Kyota go head.
*Kayode Ezike:* Yeah. Um, so this is an interesting topic. I think about it
to so the way that I've gone about it is to use Jason canonicalize um to to
determine if there is another potential that has the same value um you know
you canize both. So there's still room for optimization right because it
you know requires to actually go through and do that for everyone um in
*Dmitri Zagidulin:* Uh-huh.
*Kayode Ezike:* there. But at the very least, you know for sure if you will
collide um when you and and if it does collide, it just doesn't do anything.

00:23:04

*Kayode Ezike:* just
*Dmitri Zagidulin:* So what does what does your wallet do for assigning an
internal database ID? What do you use as a primary key for
*Kayode Ezike:* so it doesn't So at the moment it just kind of uses uh the
So currently for the credential uh wallet side of things it's using um
storing it kind of in a store and like really this comes up when you're
adding when you're actually adding it to the door um where you want to
check to see whether or not there's another credential that has the same uh
value. But as far as um like a a primary key at the moment, it's really
kind of just that we we have this store that we're managing and um we're
moving towards sort of a more proper database storage solution, but um
currently it's just a um I have to double check again, but basically just
kind of relying upon um an ID, which I double check quickly, which
*Dmitri Zagidulin:* I
*Kayode Ezike:* I
*Dmitri Zagidulin:* suspect it's that option too. I think uh databases by
or a lot of database by default either auto increment an integer or just
assign a random ID.

00:24:19 {#00:24:19}

*Kayode Ezike:* yeah um exactly so I'm just double checking the code right
now. Actually what we are doing is we're we're generating a a random VU ID
and then using that for the ID of the credential but that is distinct from
the ID that is on the credential itself. Um so it's just the the main
question around how we're checking the collisions again is just checking
for canalization and seeing that it's equal. Um, and then we just auto
generate an ID as as we receive it into the wallet.
*Dmitri Zagidulin:* Got it. Makes sense. Makes sense. Anyone else? So what
we what we ended up doing in uh at least learn a credential wallet is we
started out with just a naive implementation of VC ID uh ran into a bug
where not all credentials had IDs uh and I believe we now uh I'd have to
double check uh the code but I believe we use this option four which is if
there is an ID we use it or uh we use a hash. And it just so happens that
every single credential comes with a unique hash which is its signature
value.

00:25:43 {#00:25:43}

*Dmitri Zagidulin:* In general, for for those unfamiliar with the uh
cryptography, what's a signature? It's an encrypted hash of an object. Uh
which means if you sign two identical credentials, it comes to the same
comes to the same signature. So uh signature is a uh a convenient and
useful if slightly long unique identifier for any given credential. Um, of
course, if you do use this composite method, if you do use the VCID, now
you start uh having the having to uh find out what happens if um you try to
ingest different credential with the same ID but with different contents.
Uh so so so let's go back to our question. Now now that we've talked about
what's what some of the options uh for storing credentials in in wallets
are uh you either use the provided credential ID, you assign it your own
random number or you use a deterministic hash. You can use a signature
value for it. Right? Right. So, so now given those tools, we have to h
handle these four scenarios.

00:27:06

*Dmitri Zagidulin:* So when a new VC comes in and it is bite forbite
identical to an existing one, do you have code that that checks for that?
Right? And and you can you can easily picture a uh sort of very simple
implementation of a wallet that doesn't check for it that just stores an
additional copy. But you can also see how that that may lead to uh user
confusion. Uh, Ildico mentioned that the uh, European wallet uh, that her
team deals with um, just uses the VC ID and may or may not uh, check
incoming VCs for for uh, identical contests. Coyote mentioned that uh his
team's wallet does check uh not just bite for bite but canonicalized which
means like you sort the keys uh just so that you you remove difference in
whites space for example. Uh but yeah, so for those for those of you who do
rely on uh VC ID, uh question becomes what happens when uh two different
verifiable credentials come in with the same ID. So it sounds like for for
the European wallet, it looks at the ID and says, "No, you already have
one."

00:28:38 {#00:28:38}

*Dmitri Zagidulin:* Uh rejects it. Valid valid approach. And it sounds like
uh in in Coyote's case uh it checks the canonicalized equivalence and and
also rejects it if it's a duplicate one. But I wanted which again is also a
valid approach but I wanted to show that there there that it's not obvious
there's different options right you you could easily see a credential
saying hey these two credentials are identical except for the time stamp
and this one is slightly newer do you perhaps want to replace the newer
credential with the older one right or or for example an incoming
credential uh that again has the same fields but one expires later. You can
see how you would want uh the the UI to prompt the user, hey, this one this
credential is going to live longer. Do you want to replace it? So, any any
questions about this operation? Yeah, go ahead.
*Ildiko Mazar:* While the others are thinking uh I know that uh and this is
why I asked the other question about the uh what kind of updates because