[MINUTES] CCG Incubation and Promotion 2025-04-02

osb-nmyo-muh Meeting Summary (2025-04-02)

*Topics Covered:*

   1.

   *Verifiable Issuers and Verifiers:* The group discussed a specification
   for verifiable issuers and verifiers, aiming to ensure users can trust the
   source of credentials and the legitimacy of verification requests. The
   existing ETSI standard was mentioned, and the plan is to create a
   JSON-based profile of this standard, potentially adding or modifying fields
   as needed for broader international use. Collaboration with ETSI and the
   VCEDU community is planned to align efforts. The specification is
   considered ready to be handed off to the Verifiable Credential Working
   Group (VCWG).
   2.

   *Verifiable Credential Barcodes:* The group reviewed the specification
   for embedding verifiable credentials in standard barcodes (QR codes,
   PDF417). The key goal is to provide authenticity and integrity to physical
   documents by cryptographically protecting both the VC and existing data on
   the document. The specification is considered mature, but some
   non-normative sections (privacy considerations, security considerations)
   require further work. Discussions centered on:
   - Generalizing beyond AMVA driver's licenses to support other
      international standards.
      - Adding support for "bare" VCs (without data integrity features) in
      QR codes.
      - Addressing the dependence on pre-standard technologies like
      SeaBoard LD and Core LD.
      - Clarifying how to handle the placement of signatures in
      jurisdiction-specific fields within PDF417 barcodes.

*Key Points:*

   - Several specifications are nearing readiness for transition to the
   VCWG.
   - Collaboration with other groups (ETSI, VCEDU, Credential Engine) is
   crucial for alignment.
   - The Verifiable Credential Barcodes specification requires minor
   updates before submission to the VCWG (primarily adding support for bare
   VCs in QR codes and clarifying some points regarding PDF417 barcodes).
   - Multiple independent implementations of the Verifiable Credential
   Barcodes specification already exist.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-04-02.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-04-02.mp4
*osb-nmyo-muh (2025-04-02 11:01 GMT-4) - Transcript* *Attendees*

Benjamin Young, Dave Longley, David C, Elaine Wooton, Harrison Tang,
Hiroyuki Sano, James Chartrand, John's Notetaker, Kayode Ezike, Manu
Sporny, Parth Bhatt, Wesley Smith
*Transcript*

David C: I've been here a few minutes and I was looking through my notes
and it said starts at 300 p.m. every week, but it's actually 4 p.m. So, I
think we got messed up with this, change to summertime.

David C: And maybe the calling notice needs to go out again with correct
information. Yeah. Okay. Thanks.

Manu Sporny: Yeah. Yeah,…

Manu Sporny: David, we're changing over to the new system currently and so
it will go out as a calendar invite which will hopefully automatically sync
with everybody's calls. yeah, we got off track with the whole summertime
thing. Yep. All right. I am noting that there are quite a few people here.
So let's go ahead and get started. we're going to start with some
introductions today. but let me kind of cover our agenda for today. So let
me go ahead and pull this up.

Manu Sporny: as folks know, we have been incubating work in this group that
we are hoping to transition over to the verifiable credential working
group, the global standards working group for verifiable credentials the
credentials community group has been incubating a large number of
specifications that are getting ready to be able to be promoted to global
standards track. We're going to be talking about two of those work items
today. The first one, David Chadwick is going to give us a presentation on
verifiable, issuer and verifiers, which is something he's been involved
with, for a while now. we're going to kind of just get a high level
overview of that and where the work is right now.

Manu Sporny: and then the bottom half of the call will be focused on
verifiable credential barcodes in the things that we would need to update
or change before we hand the work off to the official standard setting, the
verifiable credential working group. So that's what we have on the agenda
today. let's go ahead and do some quick introductions for folks that are
new to the call. so, I'll just call the new folks and, please feel free to
give us a couple of sentences on who you are and, what you're interested
in. David Chadwick, we know you, but, why don't you go ahead and introduce
yourself since you're presenting today.

David C: Hi. David Chadri. I've been around this space longer than I can
remember and I have been the joint editor with Isaac Henderson from
frownhoffer of the verifiable issuers and verifiers specification. And we
implemented this a few years ago in an NGI Atlantic project. and this was
so that users with their wallets could know that the credentials they were
getting from issuers were trustworthy and contained the right information
and that the verifiers they were sending information to were also
trustworthy and were asking for the right information according to GDPR.
Thanks.

Manu Sporny: Thank you, David. Elaine Wooten, if you don't mind introducing
yourself. Oops, she dropped. We'll go to Parth bot next and…

Parth Bhatt: Thank you so much,…

Manu Sporny: then we'll come back around to Elaine.

Parth Bhatt: Hello everyone. Part here. I'm a technical product manager and
I have been working with the enterprise businesses in terms of helping them
how to leverage identity and associated protocols including verifiable
credentials and everything in their existing use case. And I'm here because
I wanted to contribute in the opensource technical specs in terms of
developing these standards. So nice to meet you all.

Manu Sporny: Wonderful. Thank you part for the intro and welcome to the
group. wonderful to see you here. all right. I don't see Elaine joining
back. so why don't we just start and go into the presentation David on the
ble issuers verifiers.
00:05:00

David C: Thanks. So, as I said in the introduction, I think it's really
important for especially naive users, who've got a wallet and are
downloading credentials from potentially anywhere in the world, that the
credentials they're getting are valid and trustworthy. you might say, maybe
they should only download credentials from issues that they already know
and trust.

David C: but that really is not necessarily the case because on the web
today when you go to websites you don't necessarily know that they're
trustworthy. You hope they are but often the name of the site doesn't even
match the name of the company. and we had a really good example of some
weird and wonderful site that was actually owned by Microsoft. So everybody
would say that Microsoft is trustworthy. they might say that but they
wouldn't have known that this website by the URL was actually Microsoft so
the idea is that the issuers will be vetted by a trusted third party.

David C: that third party will issue a list of trusted issuers and the user
only needs to trust a trusted third party and if that trusted third party
is run by the government or an offshoot of the government which in Europe
today then they're used on pretty solid ground by trusting the issuer of
the trusted list and in the trusted list for issuers then not only did they
find out who the trusted issuers are, but there's also information about
the schema of the issued credentials. so that the wallet will check and can
check that the credential it gets matches the schema that the trust list
issuer has said goes along with that trusted issuer.

David C: So, you cannot be attributes that you weren't expecting and that
the entity that verified the issue isn't expecting because it checks that
it matches the screen the schema. And then if we switch to the verifiers,
then it's important when you're giving away personal information that the
verifier conforms to GDPR in Europe. that is I mean in the different states
of America you've got different privacy legislation but in essence you need
to know that this verifier is not going to misuse your personal information
and so what the list of trusted verifiers contains is not only that this is
a verifier but this is the request that he will be sending to the wallet
and there are standards now for the request there are there at least

David C: three standards for the format of this request. There's diff PE
and that's versions one, two, and I 2 something. and there's the W3C spec
that manu has been working with on making presentation requests, I think it
called. And then there's also the ODIC the dis DCP as it is now is also
having its own policy statements for requesting credentials.

David C: So what the trusted list issue can do is that the verifier is
trustworthy check the policy that it says it will issue for a particular
resource and then the wallet when it gets the request can check that the
request actually matches and that the verifier is not asking for an undue
set of attributes and that ensures that the verifier conforms to GDPR bec
because the list issuer will have checked that and so the user can then
send his attributes in sure knowledge that his personal information is not
going to be misused. So that's in essence the concept behind the work.

David C: in terms of standardization, there was already an Etsy standard
for trusted lists and this was produced I think 10 years ago under EI-1 and
that's been implemented throughout Europe and that has a European list of
lists and that's the top level and so Europe points to all the trusted
lists within Europe the different countries and then from this list of
lists you can get the trusted list for your particular country and then you
can actually find out who are the trusted issuers in your country and who
are the trusted verifiers. You can do that every country in Europe. So for
the ex standard actually is in XML. So the data structures are in XML.
clearly we don't want XML today because wallets in general won't be
processing XML. we wanted it in JSON.
00:10:00

David C: So one of the things we did in this particular standard is
converted the SC XML into JSON and we also went through all the fields and
we eliminated fields that we didn't think were necessary for the first cut
of this standard. So for example the Etsy trusted list allows you not only
to find out who is trusted today but who was trusted in the past because it
keeps his history. So you can actually look through the history to find out
the state of people who trusted maybe five years ago. So we haven't got
that in this particular version of the draft because we thought that was a
sort of bells and whistles that wasn't essential to the fundamental problem
with it which is can the user now trust the verifier that's asking for his
credentials or the issuer that wants to give him credentials.

David C: and so I've made contact with the Etsy people and Etsy have been
requested to update their spec to conform to EDA 2. from EDAS one and so
what they're working on now is a data model for trusted lists and then that
data model can be mapped into XML, JSON, ASN1 or other formats. So they're
making their next version of the standard format independent and they're
hoping to have that standard published by the end of this year. that's I've
got a meeting with them.

David C: I was hoping to have a meeting this morning, but we didn't quite
mesh and I could have given you more updates on it back, but I'll be having
a meeting within the next week with the ETI people. where I'm going to
explain to them what we've done with our work. and then, they might take
some of it on board or not. and so the question really for this group is
what do we want to do about standardization? And my feeling now knowing
what Etsy is doing is that I think this document that we've got should
become a profile of the Etsy work when it's finished. and we profile it and
discard fields we don't think are important for us. and we might need to
add additional extra ones or optional ones that they've got or mandate
optional ones.

David C: In fact, what we've done in this fields that are optional in the
IES1 we've made more or less mandatory in this such as the schema for
example the schema they have a concept of additional information. So we've
used that to publish the schema. so I'll throw the floor open to questions
at the moment if anybody Yeah,…

David C: Manu

Manu Sporny: That was great David.

Manu Sporny: Thank I think my highlevel question. so this is good. somebody
else is working on the data model. and we should be able to profile it into
the specification. I think that that sounds great. we need to understand,
if and I think David,…

Manu Sporny: you're about to have a conversation with them about this, but
we need to understand if Etsy is okay with us profiling some of this stuff
at W3C or if they want to do that work themselves. it, calls into question
should this spec be done at Etsy or should it be done at W3C? and I don't
think we know the answer to that question yet without asking them, right,
David? Or have you had Mhm.

David C: Yeah. But that…

David C: what we have to bear in mind is that sorry it's Etsy not EPS it's
Etsy it's a European standardization organization so it is driven purely
for the requirements of Europe whereas W3C is totally international and we
should so we've got a broader public if you like a broader clientele than
exit than exit and…

Manu Sporny: Mhm. Yeah.

David C: therefore I think there will

David C: value in us profiling it because there may be things that Europe
are not interested in that the worldwide community are and vice versa. Yeah
manu Yeah.

Manu Sporny:

Manu Sporny: Plus one to that. That makes sense to me. I guess the next
question is there is I know and maybe James or Coyote you can speak to
this. I know in the verifiable credential for education group in that
community I think there was a presentation just this week right Monday
about issuer and verifier lists. David is there overlap with that community?
00:15:00

Manu Sporny: I mean clearly we would have to have a discussion with the
VCEDU folks because I know Dimmitri is working quite a bit on trusted
issuer verifier lists. do we know what the overlap there is yet?

David C: No, I missed that.

David C: I unfortunately missed that. it was sort of later in the day. that
would have been really interesting for me to attend.

David C: So I don't know what the overlap is actually at the moment. No,
And I don't know if they know.

Manu Sporny: Okay, there's a recording.

Manu Sporny: There's a recording of it.

David C: Yeah. Right.

Manu Sporny: So we can come in.

David C: Yeah. Yeah, that's right. Yeah. So,

Manu Sporny: Okay, Coyote, you're on the queue.

Kayode Ezike: Yeah, that's Yeah. and it's funny because there's also right
now a concurrent call with led by Crunch Engine and DCC around a ongoing
project that they've been doing around registries as well.

David C: Yeah. Isaac.

Kayode Ezike: I think it's always been a monthly thing. I think they're
wrapping up in a couple months or maybe even sooner than that. But I wonder
if that's also something that you should pay attention to. It's called issu
registry. some AG advisory group or something but something that's worth
looking into either with a credential engine or dcc through Kerry or Jeene
Kitchens happy to maybe send some Context of contact.

Manu Sporny: Yes, that would be great, and then David, I don't know both
you and Isaac are interested in kind of chatting with that community as
well. I mean it feels like there is momentum here clearly and there has
been work done clearly and so we just need to make sure that we've got as
many of the communities working on this stuff aligned on

David C: isn't actually.

Manu Sporny: what the path forward is so that we can make one proposal to
the ential rechartering thing. as far as timing is concerned, David Coyote,
do you have any thoughts on timing? Right now, it feels like putting the
standards track in the next two months might be too early.

Manu Sporny: But within the next 6 months seems like it might work. So, we
might want to carve out some space in the next charter to include this. but
note that the other work needs to be done in the other communities before
we can really put our shoulder to the wheel and get this thing done as a
global standard. thoughts on kind of timing

David C: …

David C: we finished this

David C: So this is our final draft unless people find raise issues and
errors. But as far as Isaac and myself are concerned, we've now finished
our work.

Manu Sporny: So, you're saying this is as far as you're concerned,…

David C: Yeah,…

Manu Sporny: this is ready to be handed over to the verifiable credential
working group.

David C: I mean And it's ready to be implemented by because as I said we
did implement a couple of years ago under the NGI Atlantic project.

Manu Sporny: Okay.

David C: and also this is our implementation based on train some people
know will know about train but train is the trusted list work that's done
by frownhuffer and it's also been used by the United Nations World Health
Organization in some of the work they've been doing. so what train does is
it effectively publishes the lists which are like epic exconformant lists
using the DNS. So the DNS is where you go to find out your list. we've got
papers describing this and that's quite nice because it means you've
automatically can navigate to trusted list providers without having some
source. obviously the DNS is an external source, but you're already using
the DNS.

David C: So you're leveraging systems that are already built into your
infrastructure to find the roots of trust.

Manu Sporny: Okay, that sounds good.

Manu Sporny: Okay, so David, you and Isaac feel this is ready to be moved
over to VCWG. We need to get confirmation from VCEDU, the verifiable
credential education folks to see if this is aligned or not. who wants to
take kind of the action to do that? David, do you want to do that? Coyote,
I don't want to. Okay.

David C: Yeah, he sent me a list.

David C: I'm just going to click on that in the Credential engines.
00:20:00

Kayode Ezike: Yeah, that's for yes.

David C: Yeah. Issue registry advis group. Okay. no. This is only issue
registry.

David C: So, are they doing verifiers as well not?

Kayode Ezike: So they are also interested in that part of their work was
exploring the different solutions that are out there. So they did actually
take a look into the is verifiable issue verifier as well as federation 1.0
0 from open ID and I think another one from BIFF. they ultimately landed on
the federation 1.0 but yeah so they have also explored that but for the
prototype they were mostly kind of seeing how they can leverage this for
the issuer use case but as you can see there's still a few more dates left
in the meeting. I guess only one more actually for next month.

David C: Yeah, it's just Matt May the 7th,…

Kayode Ezike: But yeah,…

David C: isn't it? Yeah, that's right. Yeah. Yeah.

Kayode Ezike: but it might maybe be worth reaching out.

David C: Yeah. Yeah.

David C: I'll join and see if I can I'm not sure whether I'm around May the
December, but I'll request to join it. and then for the EDU one, what I'll
do is I'll listen to the broadcast from last Monday.

David C: Because as you said it was recorded, I find the minutes are not
very good. The minutes that are automatically taken are not that good, are
they?

Manu Sporny: Yep. No,…

Manu Sporny: no, but the recording should give you…

David C: Yeah. Yeah.

Manu Sporny: what you need. And Okay.

David C: Okay.

Manu Sporny: right.

David C: Thank you very much.

Manu Sporny: Thank you so much, David, for giving us that overview. we've
got some concrete next steps that you'll follow up on, David, and we'll
check back in a week three to see what you've been able to kind of learn
about what other groups are doing. I think that's it for that item. we are
now going to switch over to the verifiable credential barcodes work and I
think you're going to take us through kind of a high level where we are
with this particular specification what might need to be done so on and so
forth.

Manu Sporny: But before we do that, we had some new people join. maybe we
could get some in Elaine, are you able to intro

Elaine Wooton: Yeah, I apologize. I lost the audio earlier and there's
nothing. I couldn't figure out what's going on, but I managed to get back.
so I was a career fed. My last day was Monday. And my basic subject area is
idity secure documents and I'm huge huge proponent of adding graphic
elements of some kind to pretty much everything in the world. and obviously
this is one of the ways of doing that.

Elaine Wooton: So I appreciate that I can participate. I'm also a standards
development geeky person. So, I'm excited to join the gang with you all.

Manu Sporny: Welcome.

Manu Sporny: Welcome to the group, Wonderful to see you here. James, I know
you've introduced yourself before, but, you mind doing a quick intro to
yourself?

James Chartrand: Yeah, no problem. so I work in the digital credentials
consortium at MIT along with to be tree sagadoodle sagadulan krie lamoy and
a couple of others and coyote for a little while as and I'm just here today
to learn a little bit more about all of these things and in particular
about the one that we're just about to talk about, the verifiable
credential barcodes. And I did want to quickly say about the prior question
of what VCEDU is doing with verifiable registries. The person to talk to
there is Dimmitri. if David could get in touch with Dimmitri could very
quickly I think talk through the issues and that's it for me.

Manu Sporny: Great to see you again, James. …

James Chartrand: Yeah.

Manu Sporny: thanks for joining us today. And yeah, and we Dimmitri is a
well well-known well-known person in the community, so we'll follow up with
him as well. Wes, over to you. could you please take us through just at a
high level what we're trying to do with the verifiable credential barcode
spec and then I think we'll want to spend most of the next 30 minutes
focused on what needs to be updated or…

Manu Sporny: fixed or changed before we hand this thing over to the
verifiable credential working group over to us.

Wesley Smith: Yeah, absolutely.

Wesley Smith: Do you mind letting me screen share so I can drive?

Manu Sporny: Yep. There we go. Yep, we can see it.
00:25:00

Wesley Smith: How's that Okay, so I think it seems like there's a mix of
people on this call in terms of, prior exposure or experience with this
work. So I'm going to spend just a few minutes giving a kind of brief
highle overview of how it works, what it does, and so on and so forth
before I get to the kind of next steps portion and talk about what needs to
be done going forward. So what is verified barcodes? Essentially, it's
about embedding verifiable credentials in standard barcodes, things like a
QR code or a PDF 417. and there are a few reasons why we want to do this.

Wesley Smith: so we have a couple goals with this work, right? One goal is
to give things like authenticity and integrity to a physical document,
right? We want to have reason to believe that a physical document came from
the organization that it claims to have come from, sub issuing authority.
and we also want to have reason to believe that it hasn't been tampered
with or changed. and so to that end we add verifiable credentials in the
form of a barcode on the physical credential that do a couple things. One
is provide authenticity as I mentioned but another is actually digitally
protect the data that already exists on the card. So verifiable credentials
in general there is a digital signature over that payload over the
verifiable credential.

Wesley Smith: the verifiable credential barcodes work takes it one step
further and it says not only are we going to digitally sign the verifiable
credential that we add to add to the document we're also going to have that
digital signature be over the data that was already on the card and so for
example if you have a machine readable zone on the card that MRZ is
protected by the digital signature in the barcode and similarly if there's
something like a PDF 417 this is a PDF a 417 barcode you'll see on the back
of a driver's license. in there there is a verifiable credential, but
there's also a bunch of other data and the digital signature in the
verifiable credential signs over not only the VC itself, but the rest of
the data in the barcode as well. So that's sort of the goal is not only to
add a verifiable credential that gives you authenticity, but also to
provide integrity over the data that's already in the credential.

Wesley Smith: and so to that end, if you actually look at one of these
verifiable credentials, you'll note that there isn't very much data in the
credential subject portion. And that's because the data is already on the
card, The data that we're trying to cryptographically protect is not just
the verifiable credential that we're adding, but it's the stuff that's
already there. So that data doesn't need to go in the credential itself
because it's elsewhere in a machine readable form on the card. and that's
basically it in the specification. We go over obviously in detail the
mechanisms by which we do this and we give some examples and test vectors.
I believe we give both so we give an example employment authorization
document and a driver's license both from Utopia.

Wesley Smith: and that's basically that there are mechanisms to put
verifiable credential barcodes in both QR codes and PDF 417 specified in
the document. and yeah, I think that's it for kind of a brief overview. All
right. So, I'll talk a little bit about what the next steps are for this
specification. So, in general, this is a fairly mature specification. both
normative and informative sections are for the fairly complete. We have
test vectors. We know of multiple independent implementations that have
successfully tested against those test vectors. so we think the
specification is in a pretty good place. With that said, there is work that
is still to be non-normative sections of the specification need work.

Wesley Smith: for example, privacy considerations need to be added. things
along those lines as well as of course the standard security considerations
and the standard writing grammar all that sort of stuff that kind of
review. as I said we do have reason to believe that the normative sections
of the document the algorithms and the are in a pretty good place because
we have multiple independent implementations. however there might need to
be some kind of formalization of that process or confirmation of that. One
thing I will note to the group is that there is a strong dependence in this
specification on seabboard LD and core LD is another pre-standard
technology.
00:30:00

Wesley Smith: so just noting that is potentially something that the group
will have to work through as VC barcodes as this spec goes to the
standardization process that there is a dependence on a technology that is
also a pre-standard and not yet a full standard. and I think that's about
it. I don't know if there's anything that stands out as something that the
group will need to address in the immediate term. Manu go ahead.

Manu Sporny: Yeah, I mean plus one for that analysis. I think that's
certainly spot on. Wes, a couple of things jumped out at me. So I'm going
to start raising issues on the spec just as we talk.

Manu Sporny: I think one of the privacy let's see. Is this a private? Let's
say it's a add security consideration for cloning attacks, right? One of
the things we can't guard against never mind.

Wesley Smith: We do have that…

Wesley Smith: but understood.

Manu Sporny: Is that in the spec right now?

Wesley Smith: Yes. Yeah. I'm sharing the P

Manu Sporny: Why is it not showing up? Is it in privacy consideration,
security consider mind. It's in security. Never mind. I'm not going to
raise that issue since it's already done. the other thing that I could see
there is that we call out VA specifically AMA driver's license scannable
information is this thing that we call out and the protected component
index covers that.

Manu Sporny: I think we want to generalize this to just international
driver's licenses have a good story about how other than North America and
countries use the prot component index. Any thoughts on that is that just I
mean and we definitely don't need to figure that out here like that can be
done in the official working group.

Wesley Smith: Yeah. So, my thoughts are strongly agree that we need to have
some way for other communities to hook into this if they want to do things
like add a VCB to a driver's license. I will note that the AMA specific
thing the fact that this is related to AMA is important because without
getting into the technical details too much there is some index that is
created based on a data structure in the AMA specification for US driver's
licenses and ID cards. So, we can't get away from the fact that we need
information from the AMB spec for US driver's licenses, but I agree we
should generalize so that that's not limiting people from other countries
or other places to, add VCBs to their own driver's licenses or whatever
form of identity document.

Wesley Smith: Does that make sense?

Manu Sporny: Certainly. I don't know who we talked to about that, but we'll
probably want to The reason I'm wondering who we talk to about that is in
the leazison section of the new recharter, we should probably include AMVA
and we should probably include maybe it's ISO that we talked to about the
international, fields and versions. So we'll want to include that in the
charter. plus one of that. The shifting topics section 3.5 the extra
information ECDSA crypto suite.

Manu Sporny: I am guessing that we would probably want to move that into
the ECDSA crypto suite specification as a How do we do that? we don't have
to, but I think that's work that the VCWG probably needs to do. I don't
think we can do anything about it here.

Wesley Smith: So just for the group really quick,…

Wesley Smith: there is a data integrity crypto suite that is currently
specified in the verify credential barcodes work. This XI crypto suite that
is almost identical to easy DSA RDFC 2019. The only difference is that
instead of getting a hash of your document and a hash of your proof and
then doing something with them, you add in a third hash and that is a hash
of the other data on the card that you're protecting. Right?

Wesley Smith: So it's like a hash of the machine readable zone essentially
modulo a couple technical details. and that's what the ECDSA XI crypto
suite is. Manu definitely agreed that it would make sense to put that in
the EDS ECDSA RDFC 2019 spec, but I defer to you on the standardization
process and how feasible that is and so on.
00:35:00

Manu Sporny: Yeah, the challenge there is that we are not going to be
allowed to make new normative additions to the ECDSA crypto suite. I don't
know how that would work. Go ahead Dave.

Dave Longley: I would think it could be done in this spec and then a
follow-on maintenance revision could be done to move things around …

Dave Longley: because then would all be in normative standard space at that
point in time. So that it might have to go through a two-step process, but
I would think that

Manu Sporny: Okay. Yep,…

Manu Sporny: that makes sense to me. okay, that sounds good. is there
anything that we were hoping would happen in this specification that's not
already in there?

Manu Sporny: I randomly picking something, we really wish we could have
encoded these as jab codes or that new Microsoft multicolor CMK barcode
format anything like that.

Manu Sporny: Go ahead, Wes.

Wesley Smith: So definitely we've talked a little bit about basically
extending this in any direction right supporting more different barcode
formats supporting more credential formats.

Wesley Smith: One big thing that I want to note is right now this
specification is around putting credentials in barcodes that also protect
external data on the card and I think that we had discussed previously
combining you can put a verifiable credential in a barcode even if it
doesn't have this feature of protecting some external data as well right
and so we had discussed

Wesley Smith: may be combining the kind of specifications or
prespecifications that say how to do that with this specification which we
call verifiable credential barcodes because it's very confusing to see a
verifiable credential in a barcode and be like no that's not a verifiable
credential barcode because it doesn't have this extra feature right so
that's something that we had talked about previously is adding support for
VC barcodes that don't have some external protection if that makes sense.

Manu Sporny: Yes, thank that is a big thing that I think we probably need
to do before handing this spec over. it's not a big thing. we need to do
that before handing the spec over. This is just raw verifiable credential
in a QR code, as you said. So, that's a fairly easy thing to do. So, I'm
raising an issue. So, add bare VCs in R code to spec. It's possible to put
a bare VC I a verifiable presentation. Yeah. do we want VPs as QR codes?
It's just kind of an open question to the group. Okay.

Dave Longley: there might use cases for it. I don't see a reason to do a
restriction at this time.

Manu Sporny: all right. So, let's see. It's possible to put a bear VC or VP
into a QR code. the specification isn't clear on how to do that and should
probably in the section on how to achieve that using the VC barcodes So I
think that is so may yeah maybe no the other issue is allow PDF 417 barcode
types beyond AMBA drivers licenses.

Manu Sporny: Ly the section on PDF 417 is specific to AMVA drivers licenses
and should be expanded to support any sort of barcode data such as ones
that might be put on birth education certificates. okay.
00:40:00

Manu Sporny: Yeah, I think So that's the second issue. any other issues
that we need to raise that people can think of?

Wesley Smith: Yeah. …

Wesley Smith: I'd like to briefly mention this turbing stless entry stuff
just because similar to the XI crypto suite, it is a slight modification of
a different standards or standards track technology to make it work with
the VC barcode stuff. specifically this is about how to use bitst string
status list in a very spacede efficient way. obviously we have a lot of
constraints when we're putting VCs into barcodes of this size. We have
literal physical space constraints right a driver's license is only so big
and so we can only put so many bytes in one of tur bit string status list
entry is how to use bit string status list in a maximally space efficient
way.

Wesley Smith: I just want to bring it up because again it's similar to XI
crypto suite it is a slight modification of a different technology so I
don't know if this is the same deal where the idea is standardize it here
and then in some maintenance pass move it into biting status list or what
the idea is but I want to bring that

Manu Sporny: Go ahead,…

Manu Sporny: Awesome.

Dave Longley: Yeah, I would expect it to follow the same path.

Dave Longley: And the two-step process actually has the additional benefit
of being able to take the specs where we eventually push these things and
link to the BCB spec or to the VCB spec as another set of material you
should be reading if you're interested in using those features. so I think
there's actually some advantage to doing it in that way anyway.

Manu Sporny: Okay, the other thing going back to kind of the AMBA thing is
we currently put the signature in jurisdiction specific field in a PDF 417
and we might want to provide guidance there.

Manu Sporny: I mean the problem here is that in the EU or in the US people
might start sticking these signatures in jurisdiction specific fields that
then everyone picks a different one and they're now 15 different it's not
difficult to do. You can probably detect these things fairly easily. but we
might want to speak to some of that standardization.

Manu Sporny: And it may be that we might want to ask for just a spec AMA or
ISO for a very specific signature, field for this purpose. Go ahead, Wes.

Wesley Smith: Yeah, a agreed.

Wesley Smith: I was just going to say that I think that would be a place
where we could really use Amlas input because they specify and standardize
exactly what in a USPDF47, So, they have a lot of specification of this
already. it would be a little bit strange for us to choose something that
is supposed to work with their spec without discussing it with them.

Manu Sporny: That sounds good. any other issues or concerns that people can
think of for the verifiable credential barcode spec? I think right now we
only have two There's really only one thing identified that we need to do,
which is, the bare VCs in QR codes addition to the spec. Everything else
feels like something that the working group can do. so I guess last call.

Manu Sporny: Can anyone think of anything else that we need to do to this
spec before we hand it over to the working group?

Manu Sporny: Go ahead, Wes. Yeah,…

Wesley Smith: Yeah,…

Wesley Smith: I don't know exactly what falls within the working group's
domain. I will note things small things like there is no privacy
considerations section. I don't know if that is

Manu Sporny: they can do that. Yeah, I mean clearly we do need to have a
privacy consideration section, but that's something that's editorial that
the group can work on, one of the things that might be interesting, once we
get it into a working group, we will request a horizontal review by the
security group at W3C and they may be interested in creating a kind of a
global attack model for verifiable credential barcodes. same thing for the
privacy group.
00:45:00

Manu Sporny: clearly we'll seek input from Electronic Frontier Foundation,
ACLU and those folks primarily because they've been arguing for right to
paper for quite a while and so this will be a good kind of temperature
check on all right we're doing right to paper. what are the attack models?
What are you concerned about? that sort of thing from a civil liberties
perspective. All right. as we expected this was one of the more In fact,
it's probably the most ready to be handed over to the working group even in
front of the render method stuff. So let's talk next steps here.

Manu Sporny: I think over the next so I don't think we need to meet about
this again but over the next couple of weeks I think we need to add the
bear VC's QR code stuff into the spec we might need to just raise an issue
in the spec itself to say hey we want to go beyond just AMA driver's
licenses here there's a plan to do that here's the issue that's tracking it
we might also want to do a scan through the other issues. We've got six of
them open and…

Wesley Smith: Yeah, most of those don't require much.

Manu Sporny: okay.

Wesley Smith: And I expect most of those are things that the working group
could handle. It's things like in the test vectors the check some digit is
wrong in the barcode and things along those lines. things that are issues
that are not at the level of the core technology in the specification.

Manu Sporny: Okay, that sounds Okay. Yeah. I mean, so it sounds like we're
in really good shape and the only thing that's blocking this from being
handed over is the bare VCs and QR codes thing. that's largely what needs
to be done. does anyone have any general questions about the specification?
Anything else that we're planning to do with it? I think we've covered it
in pretty good depth today, but anything else people want to have questions
about James, we do intend this to be usable with education certificates,
degrees, learner records, things like that.

Manu Sporny: So interested in your thoughts what you saw today seems like
it might work for those use cases. h, you're on the queue.

Parth Bhatt: Yeah. are there any reference implementation which is
currently in use of this standards

Manu Sporny: Yes, there are implementations. I forget if ours is open or
not yet.

Wesley Smith: I know parts of ours is open. For example, the ECDSAXI crypto
suite is open. I don't know for sure if we have anything that I don't think
we have any code that is like an end to end run through the test vectors if
that makes sense. But I believe the components of you what you need to put
that together are open from us.

Wesley Smith: And on GitHub I've seen other companies implementations of
the VCB's work. I haven't looked at them in detail, but I know that there
are other open implementations as well.

Parth Bhatt: understood. Thank you.

Manu Sporny: If you're a asking because you're interested in doing an
implementation, absolutely. We'd love to see more implementations. I think
Spruce has one maybe that's out there.

Wesley Smith: Screw says one.

Manu Sporny: Okay.

Parth Bhatt: Yeah, I will check it out.

Manu Sporny: Okay. Great. James

James Chartrand: Yeah, you just asked what I thought of it as far as the
educational sector goes and I think it is something that's very necessary.
So I'm really happy to see it and I'm really looking forward to seeing it
mature a little bit more. I personally think that things like degrees which
are traditionally printed on paper could really use something like this and
in fact worked on a project at McMaster University where they were doing
exactly this.

James Chartrand: the paper copies of degrees that they issued which were
PDFs contained a QR code that had a seabore LD encoded version of a
verifiable credential asserting the statement of the degree.

James Chartrand: So anyhow all that to say that I think this is wonderful

Manu Sporny: Great. Awesome.

Manu Sporny: That Thank you, always great to have that feedback. and I had
totally totally forgotten that you were involved in the McMaster University
thing. so that's great. okay. James, did you re raise your hand? Okay.
00:50:00

Kayode Ezike: That was me third. so just a really quick one because I do
recall that there's something around the fact that there's only particular
fields that are protected in that bar code. Is it made clear anywhere in
fact that that limitation that is not supposed to be particular that you
actually indicate when you do the signature that you're actually able to
protect and that others And I'm not sure if I'm misre misunderstanding that
or misrepresenting that so if that is covered properly in the spec. Yeah.

Manu Sporny: we could use probably more language to make it more clear. so
for those of you that are not familiar, there's this protected component
index thing that's a part of the credential subject and that basically says
hey this signature protects the person's the last name and their address
but it doesn't cover for example their eye color or some jurisdiction
specific field right in reason that we have that in there is that believe
it or not some of these printing systems the things that print the IDs are
so complex that they modify the data that the issuer gives them.

Manu Sporny: So you'll have a DMV say print these thousands of cards and
they go to the printing facility and then the printing facility will modify
some of the data before they actually put it on the card and that is not
known beforehand and the entity that's signing is not the printing
facility. It's like the DMV. And for those use cases, that's why we can't
protect some of these fields because the printing facilities actually
modify the data before they're printed to the card and they have no ability
to create the digital signature at that point in the process.

Manu Sporny: So the protected component index basically says these are the
things that are covered by the signature and…

Manu Sporny: all the other fields are not. go ahead Wes

Wesley Smith: Yeah, and…

Wesley Smith: just to add to what you said, it's not just an issue of
modification. It's an issue of a lot of these documents get produced in
secure facilities and some of the values in these documents aren't actually
known until the time of ing. for example, discrimination fields,
identifiers for, what batch of card stock is being used on that day or
whatever it is. Those are things that just cannot be known ahead of time.
so you can't just take the whole barcode as it exists without the VC and
put your signature over that. You can't do that. So you need to select out
the pieces of data that you are going to sign and then specify how you kind
of canonicalize a PDF 417 to get those put them in the right order, and
then do your digital signature.

Wesley Smith: And that's what protected component index is.

Wesley Smith: And going back to what we were talking about earlier, that's
why we need this AMA specific pointer is because we're using a data
structure that's in the AMVA DLD specification in order to construct this
index. Go

Manu Sporny: Yep. Exactly.

Manu Sporny: Exactly right. okay. I'm time check. we are at the end of the
call. thank you everyone for the wonderful discussion today. thank you
David for presenting on verifiable issuers and verifiers. Thank you Wes for
presenting on the verifiable credential barcode stuff. I think we have a
good understanding about where we are with so our meeting next week will
move on to the other specs that we're incubating. I think we're going to
probably pick up whichever ones are closest to being handed over.

Manu Sporny: I think the render method one is pretty far up there. So,
we'll at least do render method and we'll do another one if we have time.
I'll send that out in the invite agenda for next week. All that's it for
the call today. thank you everyone. have a wonderful week and we will meet
again same channel.

Elaine Wooton: Thanks. Bye.

Manu Sporny: Thanks all. Fight.

Parth Bhatt: Thank
Meeting ended after 00:54:37 👋

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