[MINUTES] CCG Weekly 2025-09-23

W3C CCG Meeting Summary - 2025/09/23

*Topics Covered:*

   - *Announcements and Reminders:* Updates on APAC calls (reduction in
   frequency), the Internet Identity Workshop (October 21-23), and an Agentic
   AI protocol creators workshop (October 24). Verifiable Credential Working
   Group rechartering and prioritization poll results were shared. Q3 2025
   work item reviews were scheduled for the following week.
   - *Implementing Data Integrity for Verifiable Credentials:* This was the
   main topic, presented by Greg Bernstein. The presentation focused on a
   practical tutorial approach to teaching verifiable credential
   implementation, using a club membership scenario as an example.

*Key Points:*

   - *Tutorial Approach to VC Implementation:* Greg presented a practical,
   step-by-step approach to teaching verifiable credential implementation,
   suitable for a second-semester web programming course. The example used was
   a club managing member credentials.
   - *Credential Design:* Emphasis was placed on designing verifiable
   credentials using the VC data model and JSON-LD, including the importance
   of well-defined schemas (JSON Schema) and vocabularies to ensure clarity
   and interoperability. The importance of minimizing unnecessary personal
   data included in the credential was highlighted.
   - *Cryptographic Suites and Key Management:* The presentation covered
   the selection and use of cryptographic suites (EDDSA and ECDSA),
   emphasizing the importance of secure key management practices. The
   principles of single-key-per-purpose and the protection of private keys
   were stressed. The use of DIDs (specifically DID Key and DID Web) for
   reliable public key distribution was discussed.
   - *DID Methods for Public Key Distribution:* The use of did:web method,
   leveraging HTTPS for authentication and security in distributing public
   keys was explained. This ensures that the public key truly belongs to the
   issuing entity.
   - *Proofs and Data Integrity:* The process of adding proofs to
   credentials was detailed, emphasizing the structure and purpose of the
   proof, and the role of data integrity.
   - *Code and Resources:* Greg highlighted the availability of sample code
   and resources used to generate test vectors and implement the concepts
   discussed.

The presentation concluded with a discussion of the challenges faced in
putting together the complete implementation, including the need for
readily available wallets that support the presented standards. The meeting
concluded with an invitation to Greg to return and give further
presentations on similar topics due to its effectiveness.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-09-23.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-09-23.mp4
*CCG Weekly - 2025/09/23 11:55 EDT - Transcript* *Attendees*

Alex Higuera, Benjamin Young, Dave Lehn, Dave Longley, Dmitri Zagidulin,
Erica Connell, Fireflies.ai Notetaker Ivan, Geun-Hyung Kim, Greg Bernstein,
Harrison Tang, Hiroyuki Sano, JeffO - HumanOS, Jennie Meier, Joe Andrieu,
Kaliya Identity Woman, Kayode Ezike, Manu Sporny, Manu Sporny's
Presentation, Nate Otto, Phillip Long, Rob Padula, Social Media, Ted
Thibodeau Jr, Vanessa Xu, Will Abramson
*Transcript*

Harrison Tang: Hey, Greg.

Greg Bernstein: Hey Harrison,…

Greg Bernstein: how's it going?

Harrison Tang: Great. I look forward to your session.

Greg Bernstein: Can you hear me?

Harrison Tang: It's so educational,…

Harrison Tang: informative. Yeah.

Greg Bernstein: This one's going to be very educationally…

Greg Bernstein: because it's me thinking about how I would teach verifiable
credentials in a second semester of web programming. So I wanted to come up
with kind of the survey the whole thing including of course since I'm a
cryptography kind of guy fe management and how we use dids because that was
something I didn't need to do in the test vectors and such like that.

Greg Bernstein: So it's kind of beyond the test vectors kind of a step up.

Harrison Tang: Wait, you were a professor before,…

Harrison Tang: isn't it? …

Greg Bernstein: I taught part-time associate professor and such like that.
So I've worked a lot of different things.

Harrison Tang: Have you teach this kind of thing in colleges before or…

Harrison Tang: No. Yeah.

Greg Bernstein: I went as far as you you'll see in these slides,…

Greg Bernstein: I went as far as backend, teaching people…

Harrison Tang: Hey, heat.

Greg Bernstein: how to secure website in terms of we're going to see an
example.

Greg Bernstein: I would make my students develop a club website and they'd
have to give access to guests, members, and an admin as minimum. Those were
the three levels of privilege and show them different things and make sure
it was secure between the different types, escalation of privilege type of
stuff. And there's some good ways to do that. And so that was so the next
step to me is okay shouldn't a club be able to issue credentials to its
members? So that's what I'm going to kind of go through because we got a
lot of the pieces all together to doing this. So that's kind of where we're
coming from.

Harrison Tang: Got it.

Greg Bernstein: So whether we Okay.

Harrison Tang: Yeah, I look forward to it. yeah, this is pretty good stuff.
I skimmed through the presentation that thanks for sending it over before
the meeting.

Harrison Tang: Yeah, a lot of great stuff. So, thank you. Yeah.

Greg Bernstein: There's always more slides than I will talk about it so
people can read it and…

Greg Bernstein: we'll see where we want to go from there because I was kind
of imagining a verifiable credential tutorial but written out with more
details. So we'll see.

Greg Bernstein: Okay.

Harrison Tang: Your stuff is always good.

Harrison Tang: By the BBS, right, talk that you gave. man, it was great. I
love it. All right. So I think we'll start welcome to this week's W3C CCG
meeting. today we're very excited to have Greg back here to talk about
implementation of data integrities for verifiable credentials. but before
then just want to quickly go over the agenda no administrative stuff that's
what I meant.

Harrison Tang: a quick reminder on the code of ethics and professional
conduct. Just want to make sure we hold constructive and respectful
conversations that we always have. a quick note about the intellectual
property. anyone can participate in these calls. However, all substive
contributions to CCG work items must be member of the CCG with a full IPR
agreement so if you have any questions about getting a W3C account or
signing the W3C community contributor license agreement please feel free to
reach out to any of the chairs. these calls are automatically recorded and
transcribed and the system will send out the recording and transcriptions
within the next 24 hours.

Harrison Tang: All right, just want to take a quick second for
introductions and reintroductions. So, if you are new to the community or
you haven't been active and want to engage, feel free to just unmute and
introduce yourself. I see mostly a familiar faces here today. So, next
announcements and reminders. Any announcements reminders? thanks.
00:05:00

Will Abramson: Yeah, I have a couple of things. First, I don't know if
people saw on the mailing list, but I no longer represent digital contract
design in this group. I'll just be representing legendary requirements. So,
this is just a slight change in my affiliation of the W3C which led to me
getting kicked out but now I'm back in so I am still the chair of this
group for the time and then secondly on the Apac calls. So I think a number
of reasons I'm probably going to cut back the number of calls, but I do
have definitely one confirmed speaker at the Apac time on the 22nd of
October. I'm hoping to get at least one more speaker, but we probably won't
be doing a call every week in October, unfortunately, just due to lack of
people wanting to speak so far.

Will Abramson: But hopefully we'll have a few and I might just have one
call in October at the APAC time that doesn't have a speaker where we just
see who shows up and get to know the APAC community. but I have canceled
the call on the 1 of October Wednesday. far that's all. I have one other
thing on this APAC calls.

Harrison Tang: Sounds good.

Will Abramson: Maybe I need to reach out to Manu or maybe Harrison, we can
talk offline, but we need to set up the infrastructure for these calls.
I'll chat with you separately. It's fine.

Harrison Tang: Thanks. yeah. Please.

Kaliya Identity Woman: Actually,…

Kaliya Identity Woman: how can you send me something about the APAC call so
I can put it in my newsletter? …

Will Abramson: Sure.

Kaliya Identity Woman: maybe I'll say that first. I have a weekly
newsletter about the industry that apparently people don't even know that I
write. So, I should share it more often. I think I've told this group about
it zero times so far and it's been going for four years. So, I'll share
that. And then, the internet identity workshop number 41 is coming up
October 21 to 23. the date changed. Some people who registered still don't
have not tracked this. I met some people two weeks ago that didn't track
that the date changed. So tell people about it even if you think they know
the date changed please.

Kaliya Identity Woman: And then bonus after the internet identity workshop
on the 24th of October in the same venue, we're putting on the Internet
workshop really to bring Agentic AI protocol creators together. Many of
those protocols happen to be about identities of agents, but not all of
them. and we really want folks who are sort of in the weeds of agentic
protocol creation and manifestation to be there. so those are my two three
things I guess. Thank you.

Harrison Tang: Thanks, Kya.

Manu Sporny: Thanks Harrison. I sent an email out to the mailing list about
the verifiable credential working group rechartering and prioritization
poll. I'm going to share my screen real quick. we have our initial set of
responses back which is good turnout 40 40 people. It's 39 here but we got
one person added at the last second. providing feedback on whether or not
people want to participate in the next VCWG, how much people support each
one of the incubated specs in the CCG. so if you're interested in that,
please take a look. Christopher Allen also asked what does this mean?
because it is kind of hard to look at the data and figure out kind of what
it means.

Manu Sporny: So I provided some bit of discussion on it. I know others have
chimed in on other items that they would have liked to have seen in it as
so just to note that the polls are closed. we're going to take this
information to the VCWG and that is going to inform the next rechartering
phrase with lots of thank yous to those that participated. we are going to
continue incubating these documents until the BCWG wants to adopt them. we
meet and every month on Fridays for the data integrity thing. So they
should be on please look to the CCG calendar if you want to join those
calls. Everyone's welcome. Thanks.
00:10:00

Harrison Tang: Thank you. Any other announcements or reminders? Any updates
to the work items? So, we're going to have the Q3 2025 re work item reviews
next week. So if you lead any of the work items, please help us update that
presentation that sent out about two weeks ago, three weeks ago. All right,
last calls for introductions, announcements, reminders, andor work items.
All right. let's get to a main agenda.

Harrison Tang: So today again very excited to have Greg back to talk about
implementing data integrity for verifiable credentials. if you haven't seen
the presentation deck Greg sent it out to the mailing list…

Harrison Tang: but I'll put the link here as well. But Greg the floor is
yours. Yes.

Greg Bernstein: Can you hear me?

Greg Bernstein: So, lot of slides here partially so you can walk through it
on your own. I'm not going to hit them all because we don't have the So,
who am I? I've been working on the verifiable credential stuff for a bit.
You can see if you click that link the different presentations and such
I've done before. Okay. I'm a editor of a lot of the VC data integrity
documents and I'm a generator of a lot of the test vectors the
cryptographic ones. So what's this about?

Greg Bernstein: I got to work on all the test factors and things like that
down in the bowels of the cryptography, but I didn't get to do a whole
credential development issuance managing the keys that are in a
cryptographic keys and the verification with public key things. I did that
on a test vector type of approach. So I wanted to do it all in a very
simple situation. This is going to use the VC data model and JSON LD for
the credential design. we're going to use VC data integrity and the crypto
suites to secure and issue and verify. And something I didn't do really in
the test vectors because we'll see why is use appropriate dids. I we use
the appropriate dids for development, but we didn't deploy because we were
doing test vectors.

Greg Bernstein: This is also somewhat from an applied cryptographic point
of view. Where are What keys are which? Okay, so we do have test vectors.
Okay, that'll show you how to do the steps of the cryptography. And it
turns out that cryptography, you got to be very particular about it.
Doesn't take a lot of lines of code. Okay, we've got sample code that shows
you how to do all this stuff. All the code used to generate the test
vectors is available. and we'll get into what those cryptographic suites
are. The other thing is to help with interoperability testing kick off.

Greg Bernstein: we've got a lot of people that have participated, but at
the beginning, I even wrote a little server that's open source out there
for verifiable credentials to work in the interoperability tests. Okay, so
there's lots of code. So now for me as an individual to come up with an
example, I wanted an example application of small as can be
non-governmental because there's a lot of people who work on the government
driver's licenses blah blah blah all the big stuff. And I've spent a bunch
of different times in and out of teaching, at colleges.

Greg Bernstein: So junior senior level college web design I am not a
designer you can tell from my slides I am not a designer but the
programming aspects so my example application and f other folks that get
creative can think of smaller applications that would be good for teaching
credentials. So I kind of looked at this as could this be a second semester
of web development.
00:15:00

Greg Bernstein: So, we teach front-end and backend web development in a,
junior senior level class. Teach them, how to the networking aspects of it,
the JavaScript, the HTML, the CSS. And a second semester, we kind of more
emphasize access control, security, make sure they understand HTTPS, know
how to secure your APIs and things like that. That's a web systems class
I've taught and I've also taught some cyber security. So what would I throw
in? I think it's time to throw in the design of verifiable credentials and
how we issue and provide for their verification including how do you kind
of manage this process cryptographically. So that's where I'm kind of
coming from.

Greg Bernstein: Okay, it's kind of a tutorial thing. Okay, and my example
is let's say this is what I would teach too is let's say we have a club.
You're designing a website for a club. Now we have two clubs up in Arcada,
California, we have the Tall Trees Hiking Club that likes to hike in the
Redwood Forests out in the White Mountains in California. We have the Old
Trees Hiking Club that likes to hike in the Bristle Cone Pine Forest up at
10,000 ft. And both clubs kind of exist to promote the great outdoors,
hiking, and camaraderie. Okay.

Greg Bernstein: So when I use clubs for teaching web development, sometimes
it would be their first time doing full development. I'd make them use Git
every week, every assignment was building up their club of their choice.
They had to choose their own club. didn't care if it was a tea club, a
soccer club, a movie club, whatever they had to do was choose a club and
every week they would build up that starting from static site learning
HTML, CSS and adding more and more to it. Every week a new branch off their
git repub repo and such like that.

Greg Bernstein: if I was going to make this interesting, from a VC's spe
perspective, I would want the club to certify something about their
members. What they choose to certify and the details is up to the club.
That's going to be part of the design of An example real club that I was
once a member of was the Cal Sailing Club, a university club that morphed
into community club that's been around for 50 or 60 years now and still
going strong. So let's go back to the Both hiking club keep track of their
active members. Both clubs track their members skills. Do they know about
altitude? Do they know about hypothermia?

Greg Bernstein: hyperothermia. Both track their members hiking
accomplishments. and now both sponsor a number of different activities. in
this case hikes, could be knowledge presentations or things like that, but
let's say hikes in the case of a hiking club. and they're at different
difficulty levels which will require certain prerequisites do you know what
to bring and wear on this type of hike? Have you done a hike over one mile
before, over two miles, six miles, Now, we've got two hiking clubs. They
would like to do some reciprocity of their events.

Greg Bernstein: to preserve the members privacy and avoid having to
synchronize databases and things like that. They don't share their member
databases with each other, right? That makes sense. Why wouldn't you share
all that extra information about their members? Instead, this is what I
would teach. I would have the clubs issue credentials to their members so
the members can take it to the other club as they desire. And that brings
up a lot of issues of how does the other club know about our credentials
and things like that. And we'll see that that kind of stuff is built into
the verifiable credential in if you do the steps that you're supposed to do
that you might not do if you're just generating test vectors like I did.
Okay. So, let's talk about designing the club's VCs.
00:20:00

Greg Bernstein: Sorry, I don't know enough about hiking to offer myself
that. So, I'm going to go back to a windport club. So, one of the things
you might ask is how many credentials? at a windport club like the Cal
Sailing Club, they might offer a number of different disciplines. Dingy sa
keelboat sailing, surfing, windsurf wing foiling. Then you go like," how
many credentials?" In the old days, you gave them a laminated piece of
paper and that was And if you had to do multiple credentials for each
discipline, that would be a pain. But with digital credentials, it's like
want to break this up in pieces.

Greg Bernstein: Okay, there may be overlap with the disciplines or things
like that, but thision that we didn't get to have before that digital
credentials make it easier to do smaller credentials. when I think about
the wind sport category, I think about general knowledge. Don't leave your
junk on the do your equipment on the dock. Other people need to use it. So,
doc Don't run a ground tides and currents. Don't get washed out to the
fereralons. that's some islands way off California. What conditions are
dangerous? Boundaries. Do you know how to rig up your Sports equipment
specific. Do you have some basic skills for that? And maybe there's some
achievements. Okay.

Greg Bernstein: So, there's a lot of stuff you could put into the VC for
your club. If we were teaching this to people, we might want to remind them
of things that they can and should admit, There's a lot of things a club
might need to know, especially anything associated with sports. You might
want to have contact number. Did they make it back? You'd like to be able
to call them. Maybe you need their address if you're dropping off Emergency
contact information you always have to have for any kind of sporting kind
of hiking or whatever. Student status if it's a student club. These are
things that you really don't need in the credential. If somebody's signing
up for another club's hike, they might furnish their own emergency contact.
So, we want to start reminding the students ourselves too about privacy and
personal information.

Greg Bernstein: we don't start our credentials from scratch. We start with
the VC data model, It's got required fields in it, But it's got a lot of
optional fields and so If you don't need to put in the ID of the
credential, don't. This isn't the unlinkability talk that's coming up in
about a month. You need to have the type. It's a verifiable credential and
maybe extra information that is going to about our club specific stuff. You
got to have the issuer. You got to have the subject. But the rest think
about it before you make it put it in. what is that format we just looked
at? If you've never seen it before because you don't deal with the details
of this stuff, JSON's the data lingua frana for the web.

Greg Bernstein: in a web programming class. I would teach that early In any
programming class nowadays, you can get tools to process JSON. So, even if
I was teaching C, I could get a library to process JSON. So, we could deal
with some data. first thing because it's just nice. It's human readable,
easy to process and such like that. at the point that we get to JSON, we
can actually model our credential with experts that know about the club.
So, everything we do is going to go within the credential subject. And I
can just model things in just almost readable simple English, right?
Membership, start, end.

Greg Bernstein: Okay, I guess this is going to mean their paid membership
starts here and ends here. What knowledge tests have they passed and when
did they do that? Doc etiquette, you've known about that since 1984. Great.
Might be a little out of Tides and currents, wind patterns, landmarks.
okay. This is making sense. This seems nice and straightforward. Skills.
You know how to rig the gear. know how to set up a foil landmark. This
doesn't make much sense, does it? Okay, so we're going to come back to that
in a sec. Now, notice that there's not a lot of this isn't super general.
Okay, JSON's very general. It's great for modeling anything, right?
00:25:00

Greg Bernstein: So we want to restrict what stuff is and be able to
validate our credential with ourselves and such like that. So for data
validation we want to specify what fields we only have knowledge, skills,
membership blah blah blah and what goes inside those things. How do we do
that? We need something called a schema of some type. there's something
called JSON schema that lets you specify what should go in In addition,
this thing called JSON schema is specified in JSON itself. If that doesn't
sound a little confusing, it is. Okay, I would teach this in a second web
development course. Okay, and I've got slides explaining JSON schema.

Greg Bernstein: And even myself besides my examples that I would show for
students in my VC interoperability test server. I use JSON schema for data
validation so here's a very simple example for figuring out what should be
When I get a VC that comes into my server and somebody wants me to do
signing or verification. it better have context type credential subject
issuer. Okay, so this is, yet another language written in JSON that tells
you what must be in the thing. and we use that for data validation, not
verification, no cryptography here. But JSON's very general how do we
restrict it down and specify the restriction?

Greg Bernstein: One approach is to use this thing called JSON schema. Okay,
so I've used it and I'd have my students use it and J and JavaScript.
There's a library called AGV. Do people use this stuff? I've never seen
numbers like this. That's 148 million downloads per week of an open source
library. That's how often people use this because they use it in all sorts
of little servers They use it in web applications that they're writing and
things like that. So That's how we reduce the universe of Java of JSON down
to what we intend to put in our credential. That's different from
verification, the signing stuff we're going to do. However, we're missing
something.

Greg Bernstein: What does the credential mean? I didn't really say that
this membership thing means the start and stop of their own membership in
this club. knowledge seems almost explanatory, but that might be different
to somebody else. And distance achievement makes no sense at all until
somebody tells you, " this club's based out of Berkeley.

Greg Bernstein: So either the harbor, Berkeley Marina here or the South
Sailing Basin depending on the All the distances that the club people refer
to when they talk about distance achievements are relative to Berkeley. you
make it up to Treasure Island? Did you make it up to the buoy R2? shouldn't
we explain that? We need to give the context of the club. distances are
relative to Berkeley because that's where the club's based. And we're going
to keep it simple and short, okay? Because that's what everybody in the
club says. Did you go to R2? There's a buoy above Treasure Island. It's red
and it's known as R2 on the charts. What do those different date sub fields
mean? Okay. This is why we got to define our term someplace.

Greg Bernstein: give the context of those short terms like membership,
skills. Okay, you can use somebody else's terms you get from schema.org to
say if you're going to use a first name for us, you can use this global
identifier for given names and they'll go and explain what that means. Or
we can come with a unique identifier for each one of What do I mean by
that? distance achievements. our long-term that's specific to our club,
that's unique to our club is this whole long why is it unique to my club?
Because this is the unique domain for my club. and then I add some stuff
onto the end of it for distance achievements. I give it a unique identifier.
00:30:00

Greg Bernstein: So we assemble all these definitions of these terms meaning
the left hand side stuff here in the JSON these are the terms okay design I
define all those things okay give them long ids but wait that's good enough
okay for JSON LD

Greg Bernstein: But we also need to give human readable information about
that and that's what we call a vocabulary document. And this is a bunch of
infrastructure that's already set up for the verifiable credentials. So
let's say which we're going to be using coming up. I want to set up the
public For my club. So if you can verify the signatures. I want to use the
term public multibase. But that's defined in the context blah blah security
multike key. What happens if I click this? This is the raw data is just a
JSON file. Okay.

Greg Bernstein: This is a context document. It defines and has contained in
it the public key multibase. So that's The full term is blah blah blah blah
blah security public key multibase. What happens if I actually click on
that? it takes us to a definition. Public key multibase range blah b blah
blah. they don't write it out here. They point us to the SID document. so
it'll get us there. You may need to click through it a bit. But what is
this thing we're looking at? This document. for scrolling. I know it makes
me motion sick when people scroll past. This is a security vocabulary.

Greg Bernstein: It explains what the terms mean or at least points where
you can get the definition of the terms. so we have a context document and
an explanation where you actually can read the definition of the terms. So
here's what the club context looks like. So each one of these terms like
skills shortterm, Gets a fullon ID. Distance achievements landmark. Gets an
ID. Okay, that's good. Greg, does this sound kind of familiar? Yeah.

Greg Bernstein: I mean, we're talking about things like you get in
achievements, open badges. Okay, that's based on the data model 2.02 or
comprehensive learner records. Yes, but sorry, students must design their
own club credential from scratch and create a context document and a
vocabulary document so they understand this entire process. In addition
that initial modeling of the credential here, this is very nice before you
go and try and use some standardized format like a CLR or open badges
because this is something that even the people in the club could kind of
understand. Look, we got membership, knowledge, information, skills.

Greg Bernstein: So I do encourage people to model it themselves then go
look at these bigger specifications. So our steps we got to deploy the
context and the vocabulary. Okay. Our context resolves to the JSON LD from
the link blah blah blah blah blah. Okay. So, I put that on my website and I
had set up the redirects and engineix. Okay, these are all the kind of
things we'd be teaching the students. look, we've got all our definitions,
distance, achievements. We click through there. it takes us to the
vocabulary just like We're supposed to have a vocabulary document. Okay, we
say what things mean.
00:35:00

Greg Bernstein: We tell them about landmarks and the jargon the club uses
for trips and the strange names people have for some things like a bridge
run and such like that. So, why spend time writing up a good vocabulary
documents? Other clubs, remember, we're not talking about big government
documents. We're not talking about big standards approved documents like u
driver's license etc etc. We're talking about a little club made by me that
might want to work with another club made by you. We write up a good
vocabulary document to explain what our credential means. So they can
determine whether they'd like to accept it or not for some purpose. Right?

Greg Bernstein: they can understand that somebody who can make it to TI and
back has to go about 10 to 12 miles, on a wind surfer board or what boat or
whatever. And remember, these things aren't super hard to generate. I know
it's HTML, but a lot of us all use markdown for things just like I use
Markdown for these slides. though you can use markdown to help you with
your vocabulary document too. Okay, so they've got to come up with a
context with a vocabulary document and they do all that by starting with
modeling their club specific information in JSON.

Greg Bernstein: That's something I didn't do when I was doing test vectors
because people handed me nice examples and said use this run that now the
other thing our students and me with my individual club have to do is deal
with how do I decide the crypto suites which we'll find out it's quite easy
and the other thing is what about keys okay sorry any

Greg Bernstein: break for questions otherwise we'll keep going then we can
take the questions at the end we have suites data integrity crypto seats
associated with something called EDDDSA and another set with ECDSA each of
these contain multiple things within them we have different curves for
ECDSA and such like that we have BBS which is

Greg Bernstein: Okay, these are technical recommendations. Okay, but wait,
doesn't the government get involved with signature standards? Yes, they do.
they get involved with those exact con signature standards that we have
already produced our documents Chapter six of their most current signature
standard is dedicated to ECDSA and to chapter seven to EDDDSA. They also
have another document all about the elliptic curves that are used in here.
that does not mean that everything in these two chapters and in this
document here get used anymore. A lot of legacy The stuff that we put into
these data integrity specs are some of the most commonly used.

Greg Bernstein: If we didn't hit it, I guarantee there'll be another crypto
suite coming out. We've got some for some new other types of signatures
that are in the works. Okay, not just postquantum. We've got some that are
more related to some of the elliptic curves used by Bitcoin. Okay, so we
got signature algorithms. How to choose this crypto suite simple for our
club?

Greg Bernstein: if we don't have any other requirements being pushed on us
choose ED DSA based signatures they're modern they're faster and they rest
on a more rigorous foundation that rigorous foundation is something known
as schno signatures which for the first part of their life were covered by
the patent and it went off patent so EDDDSA based signatures came out older
you got some older hardware requirements and things like that you may have
to use EDCDS SA if you do you'll probably be told what curves you must use
and things like that. So basically you'll see this even with the newest
versions of They'll by default produce an 20 E ed ED22517 or whatever one N
base keys.
00:40:00

Greg Bernstein: We'll see that in a second rather than RSA keys, but older
versions will use RSA. There's different algorithms, some of which are just
old canonicalization choice pretty simple. Both RDFC and CS work fine.
Okay, we don't have a choice when it comes to selective disclosure, only
But RDFC is made for JSONLDLD and we took the time to develop a complete
context and RDFC canon authorization takes full advantage of that. use it.
So we choose ED DSA RDFC 2022. Okay. And of course we can say more about
those things.

Greg Bernstein: working with keys, this is something that doesn't get
mentioned as much. We did cite some of this in one of the data integrity
specs. And the main place that people reference is a document
recommendation for management. Even the folks that do the OAS key
management cheat sheet, which isn't that short, reference NIST 857.

Greg Bernstein: Okay, one of the cardinal rules is a single key shall be
used for only one purpose. Okay, and we reflect that in a lot of places on
our verifiable credentials recommendations too. Just so there's 19
different types of cryptographic keys mentioned in that NIST document. We
only worry about two private signature keys and public signature
verification keys. These things come as a pair. Okay, it's relatively easy
and it's an important piece of the crypto primitives to generate those keys
for you. It's either a one-step or two-step procedure. And one of the
libraries I use that's a very good library and kept up to date.

Greg Bernstein: you just use one command key generates the public key and
the private key and we use the private key for signing the public key for
verifying. You'll see in the different specs whether they be IETF
cryptographic specs or our different representations of public and private
keys. Sometimes you use raw X. So in our BBS specs at the CFRG, you'll see
us using raw hex throwing it around. You'll see public key multibase being
used in higher level specs and you'll see us use dead key which uses the
public key multibase as part of it. Okay.

Greg Bernstein: a bit about signature security and particularly EDDDSA
comes with all these flavors of strong UFCMA binding signatures this has to
do with non-reudiation strongly binding signatures. So what do these things
look like? We assume we've got some adversary that's trying to forge
signatures. Okay, everybody can get the public key to verify signatures. So
we assume the adversary has the public key, okay, of the issuer, the signer.

Greg Bernstein: this criteria chosen message attacks we assume that the
adversary can get the signature from the issuer on as many arbitrary
messages of its choice. Not just watching a few credentials a verifier
might see but anything it would like. And under that condition, it cannot
output a valid signature for a new message of which it hadn't gotten a
signature before except with essentially zero negligible probability. Okay,
that's that basic criteria of signature security So this means the attacker
doesn't try and break the signature algorithm.
00:45:00

Greg Bernstein: They don't try and go from the public key and somehow get
the private key back. Okay, that's maybe what you're working on a quantum
computer but that's not here yet. They work on stealing private keys
impersonating the issuer by swapping out the issuer's public key with an
impostor's public key where the impostor has the private key part so they
could generate a signature. Okay. So we have this impostor issue. Okay.

Greg Bernstein: If I can give you this public key and make you think I'm
the issuer, okay, I can fool you. So there's two things we have to protect.
The private key and making sure people really know that the public key came
from who we intended from. There's one other trick in the attacker's
playbook is and it's more subtle. It's somehow restricting the private keys
generated to a smaller set of values. So then we can try brute forcing it.
Okay, this is kind of the thing why we don't have eight character passwords
anymore because easy to brute force with modern computers. So we got to
protect the private key portion.

Greg Bernstein: It must be protected, never revealed. The nice thing is it
only needs to be known to our code that will actually run the signing
algorithm. And if you didn't know every website using HTTPS, which every
website should nowadays, uses a public private key pair and has to protect
its private key. So, it's not like we aren't used to protecting private
keys for websites and protecting private keys out in the web. The extent
that you go to it may depend on how critical that website is. My little
club, the way I protect my keys is maybe a little different than what you
might want for a financial institution. Okay?

Greg Bernstein: But notice the private key portion must be protected and
never revealed. It only known to our club code that actually runs the
signing algorithm. So if you're getting super duper serious, you can go to
things like hardware security modules that never let the key out and never
let anybody see the key. So then we have this question of how do we
distribute the public key portion reliably so nobody can swap it out and be
an impostor. The way we do that there's a couple ways we can do that. First
we can hand it to you directly. Okay.

Greg Bernstein: So if you have ever set up SSH access to say a server in
the cloud from a laptop say what you'll do is you generate key pair on your
laptop. You keep your very secret and then what you do is you personally
manually put that public key into the authorized key file up on the server.
Similar technique is if you set up setting up a wireguard VPN tunnel, okay,
you're doing it directly. Obviously, that doesn't scale very well. So, you
want to automate that thing. Okay, there's a whole public key
infrastructure that's been built for doing this for the web. Okay, another
approach is sharing public keys with DIDs.

Greg Bernstein: Okay, here's information about DIDs if you want to review
it. But we're going to use and have used two different DID did key for
direct distribution and testing. Okay, What does a DID key It looks like
did key colon. What's this thing? it's the multibase of the actual key
value. That's an encoded version of the multi public key value. we use
these all the time in every single test factor. You'll see verification
method. How do we Did key..
00:50:00

Greg Bernstein: So I took this straight from our E vcdsa spec. I told you
that in previous courses the students or ourselves have developed the club
website first as a simple static site to show off their design skills and
programming ability. Then develop this server site with varying access
privileges based on roles. guest, member, admin. And to do that these
role-based access privileges, we had to provide secure login access to that
site over HTTPS. So that means my club website because HTTPS is
participating in the public key infrastructure.

Greg Bernstein: So that means my little club, the Bay Area Windsor Foiling
Club, thoretworking.com has A public key. What It says that let's encrypt a
certificate authority has checked that I truly own and control this domain.
And then assigns that and says okay he controls that domain and this is the
public key that goes with that domain.

Greg Bernstein: we're using did web since we have https. The point of the
did med method such as did web is resolved to a the did document as far as
me a cryptographer cares that's where I get the public key information. I
don't know what else might be in there, but all I care is that's where I'm
going to get the public key information. And it's the responsibility of the
did. my god, we're almost out of time. Did method to ensure authenticity.
Okay, here's the example club did document.

Greg Bernstein: All it has in it is okay. This is the identity did web.
Here's where I'm putting the signing And here ultimately public key
multibase the value of the key. So if you use a did web, it resolves
eventually to DID document which is in JSON. the did web thing resolves to
a location on the web and it is delivered see the little thing via HTTPS.
So we have our assurance that this is really coming from the club's website.

Greg Bernstein: Okay, the rest is somewhat easier. Okay, we're going to add
a proof now to our credential. As the data model says, there's two ways of
doing this. You can put in a proof straight in the credential or you can
wrap the entire credential with some type of signature algorithm. Okay,
we're using embedded proofs because that's what data integrity is about.
lots of information can go in the proof. Okay, there's some required
information and some of that only has one value type.

Greg Bernstein: Data integrity, proof purpose, assertion method, crypto
suite is required, verification method, that's where we tell them we're
going to use did key or did web how to verify it. The rest of this stuff,
if it's optional, you don't need it. The one thing in here that is
calculated is Everything else within that proof that we get in the data
integrity really can be considered as proof options or proof metadata and
cryptographically we have to protect these things and we do in our data
integrity algorithm. Okay.

Greg Bernstein: So our inputs for club issuance unsigned credential. We had
to come up with the club specific context document. We have to come up with
the proof options. Okay. And we have a private key from there. Example
proof options type proof verification method did key or did web. Proof
Persia assertion method. RX signed credential. Where's the signing? we
added proof inside with the The proof value here protecting everything in
the credential except it can't protect itself because it doesn't need to.
Okay.
00:55:00

Greg Bernstein: How hard is it to do these things? Okay, there's a key
generation file that generates all the keys that we showed you and
generates did JSON file from the public key. All it needs to know is where
you're going to put these things. Signing the credential. took that from
our test vector code reduced it around that's verified a credential around
70 lines document loader to help load up our custom context from local and
our data model local not too hard to do libraries used four general
libraries one specific to JSON LD one for coding

Greg Bernstein: up multi keys and two for hashes and curves. Let's create
some credentials and go sailing. any questions? I know that was rushed, but
I was trying to show what a full tutorial teaching. I would probably do
three weeks, six lectures if I was going to teach this to a second or third
semester class. Anybody there?

Manu Sporny: Yeah, we are just three minutes left. lots of questions. What
was the most difficult part of putting all of this together? I know you did
this all the way through just by yourself.

Manu Sporny: What was the most challenging part of all of it?

Greg Bernstein: I was trying to go directly from the JSON LD spec defined
the most straightforward way to go from my example credential to a context
and…

Greg Bernstein: I had to cheat and I ping Dave longly on that. it looks
very simple and straightforward what he ended up telling me but I was not
able to reverse I was not able to get that straight from the JSON LD thing
and so for me the cryptography wasn't too bad understanding dids was the
second one but I did the test vector so the crypto was the easiest and I
had the code for generating that stuff the other one

Greg Bernstein: was coming up with a minimal application. if you don't do
clubs and such like that, maybe you can do it within a single organization,
but you have to come up with an organization that has that thing. So, I
wanted to kind of make this plausible and such like that. But, we've got
most of the pieces. The one thing I was hoping for I was hoping for I could
just go to the Android store and look up a wallet that would accept
verifiable credentials and there's not one there with Chappie

Harrison Tang: Any other comments or questions? I like Greg. I think this
is one of the best end to end digital credentials talk.

Harrison Tang: So I'm going to share with my friends or colleagues. this is
really good. I love it. Yeah.

Greg Bernstein: Yeah, if we…

Greg Bernstein: if we get enough demand, I started writing up it as a
tutorial to work it through myself. And then I turned it into slides, which
can be a lot more overviewy. But I'd like to say more about how to go from
that example credential, the example thing into JSON, the context, put in
more things about key management because with an individual club, the admin
changes, oh, you could just change out all the keys and it's not that hard
to let members know
01:00:00

Greg Bernstein: to just go back and…

Greg Bernstein: fetch a new credential or change our keys and all those
kind of things and such like that. So key rotation, make it simple, make it
easy. explain why you do those things.

Harrison Tang: Yeah. By the way,…

Harrison Tang: I forgot to kind of share the context with the community,
but basically the culture is that Mammud, Will and we're talking about
adding some introductory educational series every quarter for the stuff
that we're working on at WPCCG. So, we asked Greg to do one. this is
amazing. So thanks Greg and I would love to invite you back every quarter
and…

Harrison Tang: talk about different topics because you are such a great
explain explainer and educator. So thanks

Greg Bernstein: One of the rules is to learn something well,…

Greg Bernstein: you got to try and explain it. So, I learned a bunch and I
was very convinced by the end that we need some wallets, easy to get in
wallets that accept Chappie. But we're very good there. I want to learn a
little bit more about how specific I can make resolve did web things. And
that did webb coming out from our friends in VC.

Harrison Tang: Right. Sounds good.

Greg Bernstein: So we're very close to making it very easy for folks to
generate their own credentials. All right.

Harrison Tang: All right. We're at time. So, thank you, Greg. Thanks again.
And this concludes this week's CCG call. Thanks,
Meeting ended after 01:02:07 👋

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