[MINUTES] CCG Atlantic Weekly 2026-03-10

This CCG Atlantic Weekly meeting focused on a review of Q1 2026,
highlighting progress on various work items and discussing future focus
areas. A significant update was the successful rechartering of the
Verifiable Credentials Working Group, which now includes a broad range of
new specifications. The meeting also touched upon the ongoing development
and potential W3C adoption of the CCG meeting archiver, emphasizing its
role in streamlining meeting processes. Several work items were presented,
showcasing advancements in areas such as VC render method, confidence
method, VC API for life cycle management, and data integrity 2.0 with a
focus on post-quantum cryptography. Discussions also covered the status of
VC delivery test suites, DID resolver testing, and the transition of VC
education efforts. The meeting concluded with a look at proposed work
items, with a particular emphasis on the potential for standardized read
APIs using ZCAPS for wallet storage and the growing adoption of W3C
Verifiable Credentials by other standards bodies.

*Topics Covered:*

   - *Verifiable Credentials Working Group Rechartering:* The Verifiable
   Credentials Working Group has been successfully rechartered for 2026,
   expanding its scope to include numerous new specifications, signaling
   strong community support and global engagement.
   - *CCG Meeting Archiver:* The infrastructure used for this meeting,
   which transcribes, records, and archives meetings, is being considered for
   adoption by the broader W3C, potentially becoming the standard for official
   working group meetings.
   - *VC Render Method:* This work item is focused on defining how
   Verifiable Credentials should be displayed, including aspects of
   templating, sandbox iframes, different modalities (visual, audio, braille),
   accessibility, and internationalization.
   - *VC Confidence Method:* Progress has been made on defining what
   constitutes confidence in the subject of verifiable credentials, addressing
   topics like biometrics, proof of cryptographic key possession, evidence,
   and clarifying terminology like "holder binding."
   - *VC API for Life Cycle Management:* This specification is moving onto
   the W3C standards track and aims to provide vendor-neutral APIs for
   credential issuance and verification systems, supporting various VC formats
   and simpler exchange workflows.
   - *Verifiable Credential Barcodes:* This work item is now in the
   recharter for the VC Working Group, with initial progress made and specific
   sections like privacy needing further discussion.
   - *Verifiable Credentials Over Wireless:* This work is currently
   back-burnered due to the complexity of offline scenarios and the increasing
   prevalence of online connectivity, although NFC-based transmission for
   tap-to-share is progressing.
   - *Verifiable Credential Refresh:* A solution exists and is deployed in
   production, but interest in a global standard for refresh mechanisms is
   currently low from issuers who haven't yet experienced the pain of
   credential expiration.
   - *Issuers and Verifiers (Recognition Credentials):* Work is progressing
   on defining a new credential type for explaining what is recognized in
   terms of who is recognized and what they are able to do, with ongoing
   discussions on naming conventions and community input.
   - *Data Integrity 2.0 (Quantum Safe):* This work item involves
   refactoring to extract common algorithms and procedures, with a significant
   focus on integrating post-quantum cryptography, including NIST-approved
   signature algorithms and establishing clear naming conventions and test
   vectors.
   - *VC Delivery Test Suites:* The test suites have been largely static,
   but there is a push to transition the canibc.com platform from a
   community project to a fully open-source W3C code project with improved
   governance for test suites.
   - *DID Resolver Test Suite:* A first pass of the test suite for DID
   resolvers is available, and implementers are encouraged to submit their
   public HTTPS endpoints to demonstrate conformance with the new DID
   resolution specification.
   - *VC Education:* This task force has reached its goals, including
   facilitating the transition of Open Badges to V3 and demonstrating
   interoperability of credential wallets, and is being folded back into the
   CCG.
   - *DID Link Resources:* This topic intersects with DID URL path handling
   work in the DID Working Group, with ongoing, but not fully clear,
   intentions.
   - *Proposed Work Items & Focus Areas:* Discussion touched on the growing
   adoption of W3C VC work by other standards bodies and the potential for
   standardized read APIs using ZCAPS for wallet storage, with strong support
   from the community for this direction.

*Action Items:*

   - Greg Bernstein will be contacted to schedule a follow-up presentation
   on the Data Integrity 2.0 (Quantum Safe) work.
   - Implementers of DID resolvers are encouraged to submit their public
   HTTPS endpoints to the VC test suite to demonstrate conformance.
   - Individuals with interest and capacity are encouraged to reach out on
   the mailing list regarding proposed work items, particularly the
   standardized read API using ZCAPS.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-atlantic-weekly-2026-03-10.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-atlantic-weekly-2026-03-10.mp4
*CCG Atlantic Weekly - 2026/03/10 11:59 EDT - Transcript* *Attendees*

Alex Higuera, Alex Jackl, Benjamin Young, Dmitri Zagidulin, Elaine Wooton,
Erica Connell, Greg Bernstein, Gregory Natran, Harrison Tang, Hiroyuki
Sano, Isaac Henderson, JeffO - HumanOS, Jennie Meier, Joe Andrieu, Kaliya
Identity Woman, Kayode Ezike, Mahmoud Alkhraishi, Manu Sporny, Phillip
Long, Ted Thibodeau Jr, Will Abramson
*Transcript*

Mahmoud Alkhraishi: Hello we'll get started in 3 minutes.

Mahmoud Alkhraishi: Can you see my screen?

Alex Jackl: Yes. Yeah.

Mahmoud Alkhraishi: let's get started. Thank you everyone for joining us
today. It is Tuesday, March 10th. IPR note, please make sure that you have
signed the IPR agreement for any substantive contributions to the CCG and
please make sure that you adhere to our code of conduct. Thank you everyone
for joining us today. we're going to be going through a review of Q1 for
2026, what happened, where we are at CCG, and hopefully things we want to
focus on going forward. thank you to everybody who's currently leading a
work item and let's get started. Before we do that though, does anyone have
any announcements they would like to make? Any things they would like to
share with the broader group?

Mahmoud Alkhraishi: Minor place.

Manu Sporny: Just as a high level,…

Manu Sporny: I know we'll get into this in some of the slides, but the vote
for the 2026 rechartering of the verifiable credential working group, the
vote closed a week ago. successful, lots of positive support, no
objections, which was great to number of interesting new companies,
supporting the work. so that's good. as folks probably also remember that
put a huge number of new specifications in scope for the group.

Manu Sporny: we are working on render method and confidence method but the
fble credential API for life cycle management verifiable credent
postquantum signatures verifiable recognition credentials wireless all of
those things were put in scope so that's good last minute there were
requests to put in the European
00:05:00

Manu Sporny: in digital product passport work as well as the European
business wallet vocabulary work and that is now listed in scope as well
which is great to see engagement from Europe on W3C verifiable credentials.
as far as I know there were no objections on any of those additions as
well. and we should hear an announcement from the verifiable credential
working group on that this week. So that's great news. huge thank you to
the CCG for helping to incubate all of those items. this is great. the
pipeline that we spent a decade setting up is operating as designed. and
we're going to see a lot more global standards around verifiable
credentials on the standards track as a result of that. That's it.

Mahmoud Alkhraishi: Thank you, Lana. does anyone else have any
announcements they'd like to make? Awesome. let's get started then. So,
we're going to review current work items and then we're going to look at
some proposals and some upcoming changes. For the current work items, we
have pretty big list of work items that are quote unquote ready for
promotion. A bunch of those, as Mana mentioned, have been promoted as of
last week. We're going to review those and then see what next steps are
there and things that are currently ongoing that are not yet ready for
promotion. So, the CCG meeting archiver manu brought this up. Do you want
to talk about it a little bit about…

Mahmoud Alkhraishi: what it is and what we're trying to do? Yeah.

Manu Sporny: Yeah. Yes.

Manu Sporny: Happy to. so, this meeting we're having right now is using
this infrastructure.'s Google It transcribes, it records, and when the
meeting's over, it autoarchchives onto our CCG servers. It publishes
minutes for archival on the CCG mailing list and does a variety of things
like that. they like the way that we run things here and so they've gotten
really interested in using this for official working group work. and so it
looks like it's once the BCWG is, rechartered, the question is going to be
brought up about whether or not they're going to use this infrastructure to
do it. which is great. and if it goes well there, then it might be that the
entire W3C starts using the infrastructure. Clearly, we are not going to
foot the bill for that.

Manu Sporny: the CCG is not going to, but it'll be kind of absorbed into
the W3C as the way that they run meetings. It'll be voluntary on a working
group by working group basis. So, nobody needs to, stop using IRC if they
don't want to. the new updates are that we had to convert the Google
meetings and the chat transcript and all of those things into IRC format so
the W3C tooling could run on it. but it does which means that all of the
special W3C commands that have existed come into existence over the past 20
7 years or whatever are now possible.

Manu Sporny: I mentioned this is not an official work item, It's just
something like we built for the community. I don't know if it should be an
official work item. Probably It hasn't heard it, since and then some output
at the bottom of the screen. That's kind of what the W3C generated minutes
for the W3C meetings looks like. that's it for this update.

Mahmoud Alkhraishi: Sorry, I'm on mute. I think you're on deck for five or
six in a row.

Manu Sporny: I this so Dimmitri is on deck for this.

Mahmoud Alkhraishi: Do you want to just Okay. Please.

Manu Sporny: The other good news is we've got leaders in this community
that are taking point on many of these specifications. Dmitri over to you.

Dmitri Zagidulin: So yeah a lot of really good conversations happening on
the VC render method task force calls which I highly recommend everybody
join because in a way is deciding a whole bunch like a big chunk about the
VC world which is look at VCs how they're going to interact with them. at
the moment so it's an extension point of each verifiable credential can
carry with it the strong suggestion from the issuer overridable of course
by the user software a strong suggestion of when displaying this credential
this is how you should display it.
00:10:00

Dmitri Zagidulin: So we're talking about a number of things. how to
essentially do templating, how to display credentials in sandbox iframes.
what to do when credentials are in different modalities like visual, audio,
braille, things like that. So essentially we're kicked off the process of
horizontal reaching out to the W3C accessibility group and lastly touched
on the subject of internationalization localization in case that a
credential is not only multi- language but the display differs by country
this would be the mechanism for it.

Mahmoud Alkhraishi: Awesome. …

Dmitri Zagidulin: Yeah, super important topic. Everybody should join in.
That's it.

Mahmoud Alkhraishi: the confidence method. Joe D. I don't think Denin's on.
Joe, are you on, please?

Manu Sporny: I don't see him. I can take this one. so the confidence method
has been making good progress. a lot of the meetings have been focused on
actually let me go back. so render method and confidence method are in
scope for the VC working group. so this is kind of like an update on what's
happening in the VC working group with those confidence method has had a
number of good conversations around what it is and it isn't. we are
covering some topics that we've kind of pushed off for many years
biometrics and what does that mean and how do we do it safely and what are
the guard rails there.

Manu Sporny: but we are also talking about pretty straightforward things
that we've talked about for years how do you do proof use of a
cryptographic key right proof of possession a digital signature using
that's a part of confidence method as well. there's also a discussion
around how does evidence play into this? do you use evidence for the
confidence thing? Are they two separate things? And so there's some talk
around like we really need to be clear about when evidence is used versus
the confidence method. There has also been a lot of discussion around the
term holder binding.

Manu Sporny: the group has I think come to consensus where that's a really
bad term and it people need to stop using it because it doesn't mean what
people think it means. you can't bind things to a holder. there's
conversations around device binding and how that's different from holder
binding. but basically the group I think is getting ready to write some
stuff in the spec about people really should stop talking about holder
binding. it's confusing. A confidence method is about raising confidence in
who the subject of, a particular set of statements is about. and so we're
talking a lot about just refining what the best way to talk about this
stuff is to create the least amount of confusion around it. it is adopted
on the standards track. Now there's still not a lot of PRs that have been
raised against the spec.

Manu Sporny: we're still in the kind of really nailing down exactly what
the spec is about and what it can do and can't do. more recently, there was
a really interesting based on a presentation in CCG. so the true eyes.ai
folks presented, they mentioned that there's a way potentially to do
privacy preserving biometrics on the client side. So your biometrics never
leave your device. but you can strongly authenticate on the device against
biometrics and send a proof that you did that elsewhere so that the
verifier doesn't receive any of your biometrics. They don't receive a video
feed. They don't receive a picture of you. They don't receive any of that
stuff.

Manu Sporny: They just get a verification that your device was able to run
an algorithm that checked your, driver's license image and You're like
You're really there. You're not an AI generated, video stream and so on so
forth. So, that is kind of where confidence method is right now. I think
everyone's pretty happy about the direction that it's going in. that's it.
00:15:00

Mahmoud Alkhraishi: Thank we have the VC for life cycle management VCOM.

Mahmoud Alkhraishi: I guess that's you again, Unless there's anybody else
from that group that's on

Manu Sporny: Pat Patrick.

Manu Sporny: Yeah, Patrick's not here. yeah, I can take this one, too. the
VC API for life cycle management. it's approved and it's in the new 2026 VC
working group charter. so it's going to become, officially on the W3C
global standards track.

Mahmoud Alkhraishi: Yeah.

Manu Sporny: The group we're meeting today, we meet every week. and we're
continuing to refine that the spec covers a whole bunch of things. So what
we found is that there's a bunch of vendor lock going on in the issuance
systems like behind OID4 VCI and OID4 VP there no APIs defined on how a
vendor plugs into a government's issuing and verification system or a
school's issuing and verification system. So VC API provides those APIs so
that you're not vendor locked.

Manu Sporny: it supports any format. So M W3CVC. It's agnostic to those
formats. largely we're focused on W3CVC's of course. it supports OID4VP.
but it also supports alternatives that are simpler VC workflows and
exchanges. there are 27 implementations of some variety that are out there.
it is used heavily for the test suites. it has been in some capacity for
years. but we continue to refine but it's a pretty good and stable at this
point.

Manu Sporny: people are shipping production software on top of it and so
it's nice to see it going onto the standards track still needs quite a bit
of kind of editorial love. We need to make a good second pass on it. We
need to make concepts easier to understand. but contentwise it's got a lot
in there that is helping people implement interoperable systems.

Manu Sporny: That's it.

Mahmoud Alkhraishi: The verify potential barcodes.

Mahmoud Alkhraishi: Yeah.

Manu Sporny: Yeah, I don't see Wes, so I can Elaine, do you want to take
this one?

Manu Sporny: Just a high level on what it's

Elaine Wooton: Yeah. Yeah.

Elaine Wooton: I'm here and I can talk very little about it, but yeah, it's
in the recharter and so we're going to start working on it. Manu's
indicated that a huge amount of the work is actually already done. There's
just some sections we need to hash out. I think there's privacy. so we'll
need to work on that. But otherwise, I don't want to jinx it by saying it
should be pretty quick, but hopefully it'll be pretty quick.

Mahmoud Alkhraishi: All anybody else wants to add on verify credential
barcodes other than hopefully pretty quick? All next up, verify credentials
over wireless.

Mahmoud Alkhraishi: I don't think cash is here. Some mano. Yep.

Manu Sporny: Yeah, I have to do this one.

Manu Sporny: This one's back burnered a little bit. we are making good
progress on it. Meaning Visual Bizarre is doing an implementation. it's
largely around kind of first responders and offline scenarios. so can an
individual use it in a disaster response like somebody's house is
completely flooded or burns down or some masscale disaster happens like the
California wildfires and this individual goes to a disaster recovery center
or they're out in the field they have their mobile phone on them but really
not much else.

Manu Sporny: How do you do tap to share for VCs both to transmit and
receive? we do have an NFC based mechanism that is a tap to transmit that
that's come pretty far along over the last year. we are kind of doing some
of that through render method. so there's still kind of an open question on
how much should we move We know that we can run the entire BC API protocol
over but as everyone knows NFC only transmits at 1 kilobyte a second which
is not a lot of data, and so there's upscale to Bluetooth and that sort of
stuff that's possible.
00:20:00

Manu Sporny: But this is one of the things where it's kind of like getting
a bit of a back burner to everything else that's going on because it turns
out that the online use cases which, VCs were designed for from the
beginning are the ones that tend to be the easiest deploy to deploy and
prove the technology out on offline use cases. are much more few and far
between. and have demonstrated that you need new hardware and that becomes
difficult to deploy. So the work is happening it is in the new charter…

Manu Sporny: but it is not one of the highest priorities right now…

Mahmoud Alkhraishi: Why is Bluetooth at risk?

Mahmoud Alkhraishi: Or did I misunderstand? Okay.

Manu Sporny: because no one's really implementing it. most of the use cases
that we have these days even if you're out in the middle of nowhere Montana
if you're using Mobile you're connected to one of the satellite
constellations. So the idea that you're going to be offline is becoming
less and less of a thing. Even in large scale disaster scenarios one of the
first things that they come in and set up are portable cell towers to do to
connect everyone back up again. Right. so they're there they're not very
common use cases

Manu Sporny: where in and Bluetooth has you can use it but it's kind of
like a pain to do pairing sometimes and…

Mahmoud Alkhraishi: Mhm. Yeah.

Manu Sporny: couple that with some of the limitations that Apple has on
their platform around NFC tap to upgrade to Bluetooth. it's at risk because
a lot of I have an online connection and if I don't have an online
connection I'm just going to use my physical card, but it's important like
we won't Yeah.

Mahmoud Alkhraishi: That's a risk to everything, right? It's not a risk
just to Bluetooth. that would be the risk to this entire spec, right?

Mahmoud Alkhraishi: I hear your point about move being harder to work with
and that if we can get NFC to work that's probably good enough,…

Mahmoud Alkhraishi: but the risks you outlined there are risks to both
methods, right? The risk is to the entire spec rather than to just one of
them. Am I misunderstanding something?

Manu Sporny: potent there's a nuance there that I think matters meaning
people are used to doing tap to pay at retail and…

Manu Sporny: checkout and that's not an offline use case like everyone's
online, but it's way nicer to be able to tap to share versus scanning a QR
code. So, that's a convenience thing.

Mahmoud Alkhraishi: Yeah.

Manu Sporny: That's why NFC used as a convenience thing is positive because
that's not necessarily an offline use case. Bluetooth is a little more
like, you can tap to NFC and then you can upgrade to Bluetooth, but it
requires you clicking on things on the screen and sometimes people get
confused about it and sometimes Bluetooth devices don't pair, necessarily.
So, Bluetooth is useful when you have devices that pair often, but if
you're trying to pair while you're in an airport for the first time,
there's some negative experiences people have had…

Mahmoud Alkhraishi: Yeah, fair enough.

Manu Sporny: where they're like, the technology doesn't work at all." and
so that's why Bluetooth is slightly different than NFC.

Mahmoud Alkhraishi: Greg, you had your hand up and it's down. I don't know.
Is there anything you want to do?

Greg Bernstein: A lot of this has to do with the implementations of
Bluetooth and…

Greg Bernstein: and the support on the different phone platforms. Bluetooth
low energy has got good support but it doesn't have the right mechanisms.
it doesn't have a TCP functionality and so there's when you get down into
these details and trying to do things crossplatform we start running into
issues with Bluetooth u because it's just not supported the same way across
the different platforms and so it's really a platform issue not
00:25:00

Greg Bernstein: the technology itself So yeah, NFC easy to do well
supported and such like that. So yeah, I was looking at this for a bit too
and digging into the Bluetooth specs and it's a bit of a mess.

Mahmoud Alkhraishi: Okay, thank you. does anyone have anything else on this
spec? All right, next up is verify conditional refresh. Demetri, do you
wanna or Caprice or No. De, do you want to walk us through it?

Dmitri Zagidulin: No. So, I would look to Manu for this one. I haven't been
active in that task force.

Manu Sporny: Yeah, problem. This one is this in kind of the same state as
the wireless stuff. it is used out in production broadly in true age. the
California DMV app uses it. refresh is something that we thought would be
used more often than it is for identification cards, but what's turned out
is MDL is doing a refresh every 30 days, right? they don't and it's
hardcoded into the MDL digital wallets. they kind of know, which MDL they
support and they know the specific states refresh interval and so they just
automatically do the refresh thing there. and they kind of did the same
thing with the VCs used for those.

Manu Sporny: and then what we've also found is the VCs have actual
revocation lists and bitstring status list. And so what the digital wallets
are doing is just sending the person back to the original site once the
credential times So, refresh ser, we have a solution here. and it's already
deployed and out there. And the people that have already deployed and put
it out there are kind of like, I don't know, it's working for us. I don't
know if we really need a global standard for this. We still want to push it
through the W3C to make sure that it is approved and in the new charter.

Manu Sporny: but we're not getting a lot of interest from issuers yet to
say we really want the refresh mechanism to be easy for the individual.

Mahmoud Alkhraishi: Hello and

Manu Sporny: I think this also has to do with some of these VCs that are
being are being issued for years and they haven't felt the pain of what
happens when that credential expires, right? So, I think this is largely
driven by issuers haven't felt the pain yet and we really need to get this
in place before they hit that kind of pain. and they're probably going to
hit the pain, when the current credentials expire, but that's not going to
be for at least the credentials we're aware of. So, again, this is semi
semiback burner. There is a solution. we might make some updates or changes
to it. but for the people that did think ahead and that are using this,
they're not really too concerned about it. That's it for this item.

Mahmoud Alkhraishi: Fair enough. All right. issuers and verifiers. Do we
have anybody from Isaac? Do you want to walk us through it?

Isaac Henderson: I was not active in the last two months actually because I
wasn't parentally. So Manu and Benjamin they were active. So I think it
would be great that they could give that update. So, let's find out.

Mahmoud Alkhraishi: Ben, would you mind walking us?

Benjamin Young: Yeah, sure.

Benjamin Young: So, we're meeting Tuesdays at 11, so just before this call.
and have been working through mostly naming for the last month and a half
or so as well as dealing with some stuff David Chadwick was bringing in
from the EU work on lists of trusted lists and trying to match some of that
work as much as possible. we are working on a verifiable recognition
credentials is listed there as the likely winner. There's a discussion
happening on the CCG list and an issue for that if anybody's interested in
weighing in. but ultimately this looks like a new credential type for
explaining what you recognize in terms of who you recognize and what you
recognize them to be able to do.
00:30:00

Benjamin Young: Then we love participants from anybody interested in that
problem space.

Benjamin Young: Thanks. Yeah,…

Mahmoud Alkhraishi: Thank you.

Mahmoud Alkhraishi: This is now in the new VCW charger, right? I think I
read that there, but I'm blanking. It is.

Benjamin Young: I believe it probably depends on…

Mahmoud Alkhraishi: And are you guys going to keep the same meeting time
going forward, or is that probably going to change after the adoption?

Benjamin Young: what chaos ensues once the working group picks back up. But
I don't believe we're planning to move the meeting.

Mahmoud Alkhraishi: Man.

Manu Sporny: Yeah, plus one to what Benjamin said. I don't think we're
planning to move the meeting. One of the things that's changing in the
verifiable credential working group is we have so many work items the only
way that we're going to be able to get those things done is if we
parallelize all of the work. And so actually the CCG has been really
helpful in this. We have created parallel work streams to work on the work
items and those work streams will probably just transition into the actual
working group meeting calls. So we won't move in theory we're not going to
move any of the times. We're going to continue meeting but it's going to
switch from being a CCG call to being an official verifiable credential
working group call.

Manu Sporny: and we're going to have to make sure that anyone that is not a
W3C member gets in as an invited expert if they've been helping out.
there's some of that process stuff that needs to be changed, but I would
expect that most of the meetings that we have on these work items are just
going to stay at the Same people are going to be showing up to them, but
it's just going to transition from a CCG meeting to a VCWG meeting.

Mahmoud Alkhraishi: Thank you for that clarification. that's super
important. does anyone have anything else they want to bring up about
issuers and…

Mahmoud Alkhraishi: verifiers soon to be recognition credentials? Please.

Phillip Long: Just a question for When is the restart of the regular
meetings going to happen or is it continuing a pace?

Benjamin Young: Yeah,…

Benjamin Young: I don't think we're going to let out. so we met just before
this call and we'll be back at it in that same time next week. it is a
weekly call, so love to have you join.

Phillip Long: Yeah. Yeah. Very good. Thanks. All I'll rejoin.

Mahmoud Alkhraishi: All right. the data integrity 2.0. There's a lot of
stuff here, Greg, do you want to walk us through it?

Greg Bernstein: My gosh, what did we grouped a lot of things in here. the
first thing we're doing with data integrity is we're doing some refactoring
to take some of the stuff that was in some of the specific crypto suites
like ECDSA that were used by multiple crypto suites, factor it out and put
it in a place more logical. So that is stuff like the selective disclosure
procedures.

Greg Bernstein: Okay, so part of this one is to put common algorithms and
procedures in some place that makes more sense rather than hiding them in a
specific crypto suite. Having BBS refer to ECDSA is not as good as having
BBS refer back to data integrity 2.0. The other place where some of this
has come up is with the quantum safe work because we have a lot of very
similar patterns that keep being repeated and we've done this with ECDSA,
EDDDSA.

Greg Bernstein: So these are different signature suites that we turned into
VC crypto suites. And after doing this for a while and producing test
vectors, we see common patterns and it's like, can we factor these out
because those of us that help generate test vectors see these common
patterns and we can take advantage of it in our code and make it easier for
us to implement this stuff. And we don't want to get too indirect and too
abstract in our specs with too much parameterization of algorithms, but a
bit does seem to help. So that's what we're exploring. there's two aspects
of this. Factoring out common routines that are in the crypto suites and
then looking at common patterns.
00:35:00

Greg Bernstein: and we're trying this out right now with the u quantum safe
stuff. I do have a lot more to say about quantum safe if we want to do that
later. or if we can do it now, that's your choice.

Mahmoud Alkhraishi: I think go ahead and talk about it now. I think
probably it's here.

Greg Bernstein: So, let me throw some stuff just if you don't have the link
link to quantum safe. what's happened? first of all, we have two NIS specs
that have been solid, have not changed for a year and a half, almost going
on two years. That's FIPS 204 and FIPS 205. So that's module lattice
digital signature algorithms and we're only concerned with the new
postquantum signature algorithms not the key encapsulation methods. Okay,
so we have two of those. Previously in the quantum safe spec, these were
labeled as experimental. They're not really experimental anymore. There are
open-source public domain implementations of these things.

Greg Bernstein: the other thing that has also changed is the fact that a
key NIST spec on key management was updated in December to talk about the
postquantum algorithms and They changed the classic way of talking about
strengths into something they call security categories. And this is very
helpful for us to provide guidance because we don't want to be writing and
making this stuff up or quoting the original literature.

Greg Bernstein: It's much better for us to be able to just quote the nice
and nest key management spec like we've done in our previous what we call
classical crypto specs like ECDSA and EDDDSA. And so that's very helpful
because that will set rules like what hashes you should use to go with what
signature strengths and things like that. So the other thing is BIPS 206 is
supposed to be coming out sometime soon and that's the Falcon suite.

Greg Bernstein: So in the DI data integrity quantum safe right now we have
four different methods. Okay MLDDSA stateless ash DSA SLHDSA falcon and ski
sign. Falcon so the first two are already PIP standards. Falcon is supposed
to become FIP standard. after doing some of this data integrity update
stuff and looking at these common patterns, we chose to refactor the U
document a bit to make it easier to bring in new postquantum stuff and
bring in things at different security strength levels. Okay, so we've
refactored the document and the algorithms a bit.

Greg Bernstein: To make that easier to do, we've come up with naming
conventions and select, made it very clear which parameter sets and
algorithm flavors, for example, for SLHCSA. All our previous work has been
on Shaw 2based hashes and so we're using the variants based on Shaw 2
rather than Shaw 3 based hashes. They're both listed by NIST as things to
do, but it's like we have to make a decision. Then we come up with a naming
convention for the crypto suite and So all that pieces in place, which you
can see in the updated document, it's time to add test so we've added test
vectors for the MLDDSA and SLHDSA.

Greg Bernstein: And we've done that in a way that should be generalizable
because we've broken that up into common algorithms and to the specific
crypto suites. And the help I would like is I need somebody to go and try
and see if they can reproduce those because it's not a test specture and
it's not a official until we've had somebody else verify that they get the
same results. And so that's where we are now. So, the document has been
updated a lot. We have sections that still need to be done like our
security sections and our privacy sections. Those should be similar to what
we've done in other crypto suites but updated and taking into
considerations the postquantum type suites. and that's where we are. things
have changed a lot in the last couple months because like I said these
specs are mature.
00:40:00

Greg Bernstein: There are third-party implementations of the signatures
themselves. We've got open source code I posted for the test vectors that
people can try and if you guys want at a future time we can walk through
the spec and the test vectors and it's interesting to see the compromises
we get from the different postquantum routines as far as key size,
computational intensity, signature size and things like that. Sorry to take
so much time, but lots gone on that.

Mahmoud Alkhraishi: No. I think we can hold you to that presentation, Greg.
If you're up for it,…

Greg Bernstein: I mean,…

Mahmoud Alkhraishi: I'll reach out after we can try and schedule something.

Greg Bernstein: okay, because it's okay. Great.

Mahmoud Alkhraishi: That sounds super interesting. Awesome. does anyone
have anything else they'd like to add on this topic? Anything else they
want to bring up? All right. the VC delivery test suites,…

Mahmoud Alkhraishi: I believe, Ben, these are done and they've been static
for a while. Is that true?

Benjamin Young: Yeah, the test suites have not changed much in the last six
months besides a few library upgrades.

Benjamin Young: Probably one bit of news here is more related to canibc.com
which we're working with the W3C to sort of shift that from a digital
bizaar project on behalf of the community into the W3C as a fully open
source code project which is kind of a new space for the W3C. which may
sound odd to those of you who've worked on test suites because those do
typically get coded within the W3C but as an organization it policies and
procedures only really govern standards. So open source code including the
test suites is kind of a mixed bag of how it's been approached.

Benjamin Young: So, we're working with the W3C over the next few months to
try and create more policies and governance process around code
specifically. And then the hope is to bring canibc.com fully into AW3C
space for governance. that might be an existing CG, that might be a
dedicated one. and that group ostensibly would also help with or at least
inform the future of related test suites like the ones you see here or the
ones on the other slides. So, that's bigish news.

Mahmoud Alkhraishi: Awesome. That's super interesting and…

Benjamin Young: It's nothing final, but it's been in the works and it's
work that's accelerating now that people are realizing it's 2026. not a lot.

Mahmoud Alkhraishi: hopefully it works out. has there been any change for
the implement side?

Benjamin Young: We have lost a few who basically just stopped maintaining
their public endpoints. and there's a few that probably need cleaning out
because they likewise haven't either updated their integrations or they
were side projects clearly that somebody was just doing and wanting to
promote and then lost interest. but the core names that have been there
from the beginning are still there, which is pretty much everyone you see
on this tech.

Benjamin Young:

Mahmoud Alkhraishi: Okay. …

Mahmoud Alkhraishi: do you think there's probably not going to be another
push for any of these until the current work is going to close out, All the

Benjamin Young: So, yeah. So my hope and really expectation from the
working group and you've heard some of this from Greg already is that
people will take test vectors more seriously earlier because it does not
have to be a dead sprint in the last three we hours of the working group
and if you do it throughout the process it's much healthier both for the
spec and the tests because the tests are meant to inform the
specificationability in that specs can often be written with musts and
shoulds and whatever that are actually untestable and…
00:45:00

Benjamin Young: that coming to light earlier can help shape the spec test
dynamic from the beginning. So in answer to your question,…

Mahmoud Alkhraishi: Mhm. That makes sense.

Benjamin Young: once the working group is officially back up and running
for 2026, then my hope is towards TAC, we can start in the fall, we can
start having conversations about who's leading which effort in for which
spec around test suites and start getting some of that scaffolding up and
running and then tests being run into 2027.

Mahmoud Alkhraishi: Does anyone have anything else they'd like to add about
the test suites or the implementations? All right. I think this is the same
thing, right?

Mahmoud Alkhraishi: I'm just gonna move forward and then are you. okay.

Benjamin Young: Yeah. So this one,…

Benjamin Young: yeah, most well should take this one,…

Mahmoud Alkhraishi: Is this you?

Benjamin Young: but the other slide. Yeah, it's more

Will Abramson: Yeah yeah yeah yeah yeah I am on yeah this just really a
flag to anyone on this call and…

Mahmoud Alkhraishi: Are you one? Yeah.

Will Abramson: anyone that you might know in your networks who has an
implementation of a bid resolver that they want to check and demonstrate is
conformant with the new did resolution spec. So we've got a first pass of
the test suite. Currently there's two implementations integrated. That's
the diff universal resolver and then I think digital bazar has an old
implementation that they are going to get up to date because it's not
passing the current test. so that to add your implementation the first
thing you need is like a HTTPS endpoint that's public that can execute the
resolution request.

Will Abramson: So either you're an implement who already has this available
and it's public and then submitting your implementation is very simple. You
go to this VC test suite and add a JSON file to represent your
implementation and provide some did that we can test and validate against
your did resolver. We don't care what did method you resolve. As long as
you can successfully execute a resolution request that takes in a did and
returns a conformant resolution result,…

Will Abramson: then you are a conformant did resolver. And that's great.

Mahmoud Alkhraishi: Is there a minimum two dids resolve or…

Will Abramson: We would love to Currently for us,…

Mahmoud Alkhraishi: something or is it just any one did resolution works is

Will Abramson: yeah, it's just any did. I mean, you can provide more than
one DID, of course, that would be useful. And we also ask if you can
provide some DIDs that fail because one of the important things we want to
test is all the error cases. so you need to tell us which maybe it's a did
key, but a DID key that doesn't have a proper key encoded, for example.
obviously they're kind of individual depending on the DID method.

Will Abramson: Yeah, and then the other question the other thing is…

Mahmoud Alkhraishi: That All right.

Will Abramson: if you have a DID resolution did resolver implementation
that's just a library. currently there's no way to add that to the resolver
unless you can create a wrapper that is like a HTTPS endpoint that you're
willing to stand up. I think the work to actually do that if you have a
resolver library that is conformant and you should take less than an hour's
work I would be happy to help anybody who thinks they have a library that
would want would like to do

Mahmoud Alkhraishi: Thank you all. so please if you have a resolver, reach
out and submit your resolvers to this test suite.

Mahmoud Alkhraishi: VC education. do we have anyone on from there?

Mahmoud Alkhraishi: Is it Dimmitri? Are you Yep.

Dmitri Zagidulin: So I can speak to that a little bit.

Dmitri Zagidulin: So VC education is essentially at a good stopping point.
So we founded it a number of years ago. one of the primary motivations was
shephering the transition of the open badges standard from the just plain
website hosted v2 to a verifiable credentialsbased v3. So the vci task
force was instrumental in sort of advising and guiding that transition.

Dmitri Zagidulin: and then later on helped to organize and run
interoperability plug fests where we demonstrated essentially credential
wallets using W3C verifiable credentials as well as the protocols like VCOM
open ID and didcom and make sure of interoperability between the wallets.
we've held a lot of sort of general purpose education seminars used as a
test bed for some of the other topics that we're working on in this group
such as render method such as the verified identifiers and verifiers so
we're at a point where I think we've reached enough of the goals that we're
looking to hand
00:50:00

Dmitri Zagidulin: to fold the task force back into the CCG in general. So
we reached out to the chairs and…

Mahmoud Alkhraishi: All right.

Dmitri Zagidulin: continuing that conversation and…

Mahmoud Alkhraishi: And we're more than happy to help. Let's get back.
Wonderful.

Dmitri Zagidulin: and the year-long project with the DCC and unissue
registry that concluded and shipped credential engine is running an issue
registry currently and so on. Yeah.

Mahmoud Alkhraishi: Did link resources is anchor Alex are you guys on?
thanks and we have reached out. I don't think I've heard anything from
them. does anyone know any news on this?

Dmitri Zagidulin: I know a little bit in the sense that part of it slightly
intersects with the did URL path handling work that's happening in the did
working group that sort of bubbled out of the diff web VH working group. so
Alex and Anker were part of that conversation. but I'm not sure what the
current intention is.

Mahmoud Alkhraishi: all Does anyone else have any other updates they have
on Anything else All right. proposed work items and areas of focus. Does
anyone have anything they'd like to So, I know we're a little bit short on
time. There's sevenish minutes left. Are there any proposed work items that
anybody has, anything that they want to talk about? Are there any areas
that we want the CCG to focus on specifically? Any work items that you wish
existed or things that you want to point people and say "Hey, there's
probably a gap here. We should probably target it." Does anyone have
anything along those lines they want to bring up?

Mahmoud Alkhraishi: I mean, I know we have a lot already, so it's a little
bit of a funny question to ask, but yeah. M

Manu Sporny: I'll mention that we are seeing a pretty significant uptick
with other standards bodies adopting the W3C verifiable credential work and
kind of doing work elsewhere. which is I think a super healthy sign. so for
example I've heard of the vital records community doing that. there are a
number of states that have done that. the retail sector is very heavily
leaning into W3C verifiable credentials. seeing some uptick in banking and
finance as well as some pretty exciting new education things happening this
year.

Manu Sporny: and of course Steve Capel and the UNP work so the UN
transparency protocol the business registry stuff European Union digital
product passport and European business wallet stuff they're bringing that
to W3C. so I think one of the healthy signs here is people are doing this
without us having to really be too involved and in different market
verticals. So I think that's good. That's it.

Mahmoud Alkhraishi: Thank you. Demetri.

Dmitri Zagidulin: Yeah, I was wondering if there's any interest in the
group to I know we mentioned it possibly last year, but now there's even
more momentum behind it. I'm wondering if there's interest in two areas.
one is using things like authorization capability, ZCAPS, which is one of
the specs in the CCG or essentially to polish it up c, put together a new
version and specifically the part of the reason why there's sort of renewed
work there is the interest of storage, right?
00:55:00

Dmitri Zagidulin: now that we've got a more or less decent infrastructure
for DIDs and verifiable credentials, wallets, building building
applications with them and having standardized backends for those wallets,
the problem space suggests something like a standardized readr API using
ZCAPS as authorization. So I was wondering if there's interest in this
group in storage in Zcap's work essentially

Mahmoud Alkhraishi: Phil, I know you're on the cube, but does anyone have
anything they want to respond to me? Do we have any Nice.

Manu Sporny: Yeah, I mean huge interest from us specifically digital bizaar
specifically in that we've rolled some of this stuff out in production and
we really would like to see kind of standards around it. I think it's
really important for the interoperability story and the no vendor lock
story. everything that she said Demetri so we are very very supportive
would love to help and participate in that work noting how horribly spread
thin we are with the current upcoming BCWG work items so we certainly can't
lead the work but would be very happy to try and join and help if we

Mahmoud Alkhraishi: Nice. no.

Phillip Long: And I'm not going to suggest something that's new work, but
rather to expand a little bit on what Manu said earlier about other groups
taking advantage of the W3C framework and credentiing environments that
have been done so far and that particularly includes one edtech which is
focused on education credentials. Demetri mentioned that there was a
transition to the badge from version two to version three that was
primarily done within one edtech but to be conformant with W3C as an
overall envelope for consistency and interoperability.

Phillip Long: they've done the same thing with their work with the
transcript what they call the comprehensive learner record version two and
now there's emerging in the open a trusted credential profile which is
intended to make a version of a resume available in a way that's conformant
with W3C. So I just emphasize that the work is being done elsewhere but
people are looking to W3C as an envelope and larger

Mahmoud Alkhraishi: And thank you to everybody else who helped today. Thank
you to all people who are contributing to CCG. If anyone has anything else
they want to bring up, any other ideas, any other areas of focus, please
don't hesitate to reach out to the mailing list. I'm sure if you reach out
there, you'll get a broader audience than what you get from this call. And
hopefully you can get some volunteers to help you focus on whatever new
work item or area you'd like to work on. but again, thank you everyone
today and have a great rest of your week.
Meeting ended after 00:59:34 👋

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