Promoting CCG Work Items meeting summary for 2025-03-19

CCG Promotion from Incubation Meeting Summary - 2025/03/19

*Topics Covered:*

   -

   *Review of Specifications for Promotion to Verifiable Credential Working
   Group (VCWG):* The primary focus was determining which incubated
   specifications were ready for transition to the VCWG. This involved
   assessing maturity, outstanding issues, and required work for each.
   -

   *Verifiable Credential Rendering Methods Specification:* Discussion
   centered on the scope (browser, wallet, print, etc.), the need for a final
   community group report before VCWG submission, and the potential for a
   simplified initial version focusing on visual rendering (SVG, PDF) using a
   mustache-style templating mechanism. Concerns were raised about the need
   for more fundamental modeling work before transition.
   -

   *Confidence Methods Specification:* This specification, lacking recent
   activity and an editor, was discussed. Its purpose (providing verification
   confidence) and potential future directions were outlined. A decision was
   needed on whether to complete the specification before transfer to the VCWG.
   -

   *Verifiable Credential Barcodes Specification:* This mature
   specification, already in production use, aims to compress verifiable
   credentials for use in existing ID formats (driver's licenses, etc.). Its
   dependence on the Core LD work was identified as a potential blocker for
   standardization.
   -

   *Verifiable Credentials API Specification:* This specification, also in
   production use, requires completing outstanding PRs before transition to
   the VCWG. The need to address these before transfer to avoid rework was
   highlighted.
   -

   *Verifiable Credentials over Wireless Specification:* This relatively
   new specification focuses on NFC tap-to-transfer and protocol upgrades.
   Discussion included its potential relation to the rendering methods
   specification.
   -

   *Other potential work items:* Mention was made of post-quantum
   signatures and selective disclosure specifications, along with other
   next-generation data integrity mechanisms, as future candidates for
   discussion and potential promotion.
   -

   *Meeting Logistics:* The recurring nature of the meeting and challenges
   with attendance due to missed invitations and scheduling conflicts were
   addressed.

*Key Points:*

   - Several specifications are ready or nearing readiness for promotion to
   the VCWG, pending completion of outstanding tasks (PRs, design refinements,
   etc.).
   - There is a tension between thoroughness and timely advancement of
   specifications through the W3C process.
   - Resource allocation and dedicated effort were identified as crucial
   for advancing some specifications, potentially through focused community
   sub-groups.
   - The dependence on external standardization efforts (like Core LD)
   presents a potential delay for certain specifications.
   - The meeting structure and invitation process need improvement to
   ensure better attendance and communication.

Video:
https://meet.w3c-ccg.org/archives//w3c-ccg-promoting-ccg-work-items-2025-03-19.mp4
*CCG Promotion from Incubation - 2025/03/19 10:58 EDT - Transcript*
*Attendees*

Alex Higuera, Andrew Whitehead, Benjamin Young, Dave Lehn, Greg Bernstein,
Harrison Tang, Hiroyuki Sano, Manu Sporny, Manu Sporny's Presentation,
Nivas, Phillip Long, Ted Thibodeau Jr, Will Abramson
*Transcript*

Manu Sporny: All right, let's go ahead and get started. I went ahead and I
of course forgot to send the reminder to the mailing list, so only the
people that added the invitation a while ago got it. I just sent an updated
invitation to the mailing list just now. So, we might have some folks
straggling throughout the day once we move over to the new meeting kind of
setup. Hopefully, it'll get on the CCG dar. Ted, I thought of a way that we
could actually do that. So, I'll try to contact the chairs and get this on
the CCG meeting calendar. okay. I think many of us already know each other.

Manu Sporny: so I'm going to skip over introductions just for today. let me
go ahead and share my screen. the kind of general agenda that we have is
going to be reviewing some of the specifications that we've had ating. as
many of the W3C verifiable credential working group is getting ready to
publish seven specifications as global standards soon.

Manu Sporny: in that once they do that that means that there's room to work
on a number of new verifiable credential specifications that have been
incubating over the past year or two years. so the purpose of these calls
today is to review some of the specifications that could be moved over to
the verifiable credential working group. discuss new charter changes that
could potentially happen to do that. and then talk about what would need to
happen on these specifications in order to suggest gem for a new
rechartering for the group.

Manu Sporny: So that's kind of what the purpose of these calls are. any
general questions on the purpose of the calls before we kind of jump into
the work items and where we are on them. And if not, Phil says, "Sounds
good so far." I'm going to go over each one of these potential work items
at a high level, kind of speak to where we are with them. what the
remaining work that needs to be done is, that sort of thing. So, the first
specification up is the verifiable credential rendering methods
specification.
00:05:00

Manu Sporny: the purpose of this specification is to take a verifiable
credential and create some kind of rendering of it that can be sensed with
one of your senses. So the site is the first one of course that we're most
expecting. so how does an individual issuer say how they would like their
credential to be rendered visually. there's also the possibility for audio
rendering and haptic rendering. those are probably a little lesser Audio
rendering is literally an audio file that reads out what the credential is
about and what it allows you to do.

Manu Sporny: that can be useful in certain accessibility people with
accessibility needs. other things that can come into play are high contrast
renderings for the credential for people with site audio for people with a
lack of vision. and then haptic even rendered to braille for example could
be a possibility. so in general that is what the verifiable credential
rendering method specification is about. go ahead Phil you're on the queue.

Phillip Long: Yeah, just clarifying this is intended to be rendering in a
browser context or…

Phillip Long: rendering in a wallet context what in a general context for
either.

Manu Sporny: rendering in a general context.

Manu Sporny: Yeah, you print to PDF's in scope SVGs in scope animations in
SC it's when we say render we're talking about it in a very broad sense in
the browser certainly in the browser…

Phillip Long: Yeah. Just double checking.

Manu Sporny: but also in a wallet but those are a little too focused right
I mean we're also talking about rendering on paper we're talking about
rendering

Manu Sporny: to wireless. So NFC, Bluetooth, those are also ways that
things can be, rendered. so those are all kind of within scope.

Manu Sporny: Clearly, we have to narrow it in what we're going to try and
do in the verifiable credential working group. I'll get into that here in a
bit on what we're going to try to narrow to, but yeah.

Phillip Long: Very good.

Phillip Long: Very good. Thank you.

Manu Sporny: No problem. any other highle questions on render method? what
we're trying to accomplish with render method.

Manu Sporny: Go ahead, Will. Yes,…

Will Abramson: I have high level question kind of about all of these specs
and…

Will Abramson: and just looking at this spec, right? It says it's a draft
community group report. Is there going to be a plan to make this final
group report before we put it to standard or do we not care about that?

Manu Sporny: I would imagine so.

Manu Sporny: We skipped that step with I forget which thing but it was the
BCWG so aggressively pulled it into the group that we weren't able to
finish our process.

Manu Sporny: So yes, the proper process would be to publish a final
community group in a report.

Will Abramson: Yeah,…

Will Abramson: I would like to see that too because I think it just looks
good for the W3C host of endpoint for it and then we can list it as an
output piece.

Manu Sporny: Yeah, that's one totally agree. go ahead, Lane. Yeah,…

Dave Lehn: Yeah, I'm just wondering about, the state of this. I've always
hoped that it would advance more than it has and is the idea to just take
it over from I mean, I guess at the current state as opposed to letting it
mature further in the CCG.

Manu Sporny: usually it's like we've gotten it far enough along where,
we're pretty sure the working group is going to know what to do with it
once we hand it over to them.

Dave Lehn: Yeah.

Manu Sporny: It also helps that the same people are going to go over there
and work on it. So, I think there's going to probably be some aspects of it
that stick around in CCG and…
00:10:00

Dave Lehn: On this it seems a little questionable. I've always thought
there would be a whole lot of interesting development that could happen
with this and exploration and stuff. And so I mean I don't know if that can
happen in the WG or if that needs to happen still over in the CCG.

Manu Sporny: some aspects of it that go to the working group. So, I'll get
to kind of a proposal on what we actually move over. and I think it's going
to be a very limited subset of what's possible, but we'll get to that in a
second. Phil said, maybe, this one is going to be a final report in a week
or so. I don't know. That's what we're here to kind of discuss. I don't
think it's a week or so. I think, at least a month, probably if not a bit
longer.

Manu Sporny: it all depends on feedback from the CCG, I mean, if CCG people
are like, "No, I wanted to make sure that I got X in there." then we do
that. the other thing, to point out, is that there are two kind of
rendering methods in here. the open attestation one which is something that
the Singapore government has been working on for a while and I think it's
in production in Singapore and I think Cambodia as well and they're working
with other partners in the Asia-Pacific region to get that deployed and
it's a very different approach from the SVG rendering template.

Manu Sporny: so just to highlight that there's some differences there. so I
guess what would we move over? they're the easiest thing for us to do is to
just say the first iteration of the spec is just going to be about
graphical rendering. So it's a visual rendering.

Manu Sporny: and we are other than the open addestation stuff also going
along the other stuff is going to be just a dead simple curly b variable
replacement mechanism like mustache template based thing and that will be
applicable to PDF files and SVG files and really any media type that can
allow you to do that kind of search and replace, Right. So any kind of text
based or it's even potentially a binary based format we would let me see if
let me get to an example here.

Manu Sporny: So this is what a render method example actually looks like,
and this is very specific to SVG. And I think some of the learnings we have
from working with SVG is that it is limited in a not so great way. And we
know that for example in the education sector PDF is a very soughta and
desired rendering method. So, we've got to figure out a way to support
PDFs. SVGs are fine. and there may be other textbased, formats that people
want to do. So, I think we're going to want to back off from saying we're
going to be doing just about any type of, media type that you can put
mustachebased, replacement variables in. and that is at least going to be
the base version that we use.

Manu Sporny: It's the one that gives us the most amount of flexibility that
we know of. go ahead, Lane.

Dave Lehn: Yeah, I'm just wondering on the direction here because when this
spec was first posted I think it was the same day I posted an issue just
arguing that the design was and we needed to model some of this stuff in a
completely different way and nothing has ever happened on that since then
because we just haven't had time for it. I'm just wondering whether the
thing that should be focused on is the general modeling of what the render
methods should look like.

Dave Lehn: And so you would have I mean the way that I think that it's
arguable is that there should be a base spec that says how these things
should be designed and then all these specific ones like SVG or the open
testation stuff those should be in completely different specs and allowed
to evolve on their own using the base spec and I don't know what the
direction is here of what you all wanted to be standardized and I'm not
even sure whether some of these base ones should be in the main spec…

Dave Lehn: because it just sort of ties them to that forever and I don't
know why they're special compared to the other ones. I think other types of
methods should be just on the same footing as these particular ones.
00:15:00

Manu Sporny: Okay.

Manu Sporny: So, the more specs we make this into, the more difficult the
W3C process becomes. to the point where it was incredibly painful getting
seven specifications through W3C.

Manu Sporny: So there is a price that we pay if we split these up into many
different specs.

Dave Lehn: …

Dave Lehn: maybe the answer is to not do the special per format ones. I
don't know how this should be done. I understand that concern. It's just
that it seems to be mixing two things together. We do want to have the base
thing available so that it will work well for other types of I don't even
know what we're going to call these things, but this SVG rendering
template,…

Dave Lehn: I think there's some things that should change there. And I
mean, is it we want to tie that in with the main how render method should
work?

Manu Sporny: When you say the main,…

Manu Sporny: what do you mean by the main Okay.

Dave Lehn: I don't know exactly. I mean, I think there's just some work
that can be done on the modeling of how render methods should work and how
they should be interpreted from whatever type of user agent you're using.
And I think there needs to work on this. I don't know what the answers are.
So I'm just sort of wondering…

Manu Sporny: So that's fine.

Dave Lehn: what the focus is. Focus

Manu Sporny: I mean, so if we're basically saying we're not ready to
transition this to the VCWG and we need to work on it more in the CCG, then
that's one of the things we're taking back from the community.

Dave Lehn: What is the …

Dave Lehn: how well developed does it have to be before it's transitioned?
Is that

Manu Sporny: Not very I mean it's more of a conceptually the group is going
to start working on render method.

Manu Sporny: It probably doesn't matter all that much if we work on it here
or we work on it in the working group other than some CCG participants are
not members of the working group so they wouldn't be able to do it. I mean
it also depends on how quickly we think we can rev this right. I mean if
you think that there are fundamental flaws in the design or it's going to
take us months to update it that's a very different conversation from we
need to spend three or four concentrated weeks redoing the spec and then
we're ready to go. So concrete issues and proposals I think at this point
would be helpful.

Manu Sporny: Dave, I'm saying raise them in the issue tracker so that we
can Okay,…

Dave Lehn: Okay, I don't have them at the moment.

Dave Lehn: I mean, I did raise some when the suspect was created and I
don't know if those have been addressed. So,

Manu Sporny: we'll look at them. so I'm going to put a pin in this spec and
we'll move on. the hope was that this was one of the first specs that we
could move forward. because the current VCWG is cleared to work on this.
meaning that as soon as we get it ready, they can start moving it towards
the global standards track process. the idea is that this would be a
separate spec from the main spec.

Manu Sporny: we could integrate it in with the V2.1 verifiable credential
data model spec which we might not want to do. We probably want to keep it
as a separate spec to hit that middle ground that Lane was talking about
being able to independently rev the versus the VC data model to one spec.
So, the feedback here is Dave, you feel like we need to do a significant
amount of work on this before we can transition it to the VCWG.

Dave Lehn: Maybe I don't understand which work should happen where. I want
to see this thing move forward. It'd be great if the working group works on
it. CCG doesn't feel like Either way is fine and people working on it one
way or the other. That's great.

Manu Sporny: We have to make a decision here on whether it's being moved
out of CCG or to VCG or not, that's an active decision we have to make.
Okay. So,…

Manu Sporny: how about this? We're going to come back around and we'll
start looking at issues for render method. That's what I'm hearing. go
ahead, Benjamin. No. Yep.

Benjamin Young: Yeah, I came late,…
00:20:00

Benjamin Young: so I apologize that this was already covered, but are there
requirements on the specifications to be in certain states prior to them
transitioning or is it Yeah, because there's a long list of people
interested in render method who have said they want to make contributions.
and they've sent emails about things and some of them have submitted PRs.
and large the biggest thing it lacks is the formality of a meeting to just
hey, we're going to talk about it to sort of push that to happen. that
could happen in the CCG or WG, but I don't think it makes sense to not put
it on the list for moving to the working group because I think that's more
of a statement about where the group plans to go technologically than it is
about can this be worked on other places.

Benjamin Young: Of course, it could be worked on outside of the W3C, but
the point of making it a working group spec is to focus on it at a
different level and give it a test suite.

Manu Sporny: Less one to that.

Manu Sporny: And it may be that that ends up being the call where we get it
to the shape that we think it needs to be in to be moved, we've got all
these different specs and we might just iterate on them on this call if
people don't feel it's ready just yet. so that is Any other questions on
render method before I move on to the other things? We've got five other
specs to get to. So I want to try to get to those. Okay.

Manu Sporny: So one spec in the running is the render method one. I'm
trying to understand what you're saying being this time slot in weeks ahead
not this yes that's right.

Ted Thibodeau Jr: Just by this time slot weeks ahead not in this

Manu Sporny: We are not just having one calls. We're going to continue
having these calls until we get to some level of consensus on what to move
forward so yes, Ted. okay, next spec up is the confidence method
specification. which I believe Oliver said he is no longer going to be an
editor on. it really hasn't had much work done on it.

Manu Sporny: we copied and pasted a section of the specification in the BC
data model 20 that didn't make it. So we had something called confidence
method in the 20 specification. it didn't make we cut it out and put it
here. and as you can see it's very minimal and it hasn't been worked on
since it got moved here. just as a reminder to those that don't know what
confidence method is about, confidence method is a mechanism that you use
on a verifiable credential. there's a property called confidence method and
you can attach it to a credential subject or any other thing.

Manu Sporny: and this thing the confidence method gives the verifier
additional confidence that whatever is being presented to them is
legitimate. it's a very general concept but the easiest way to understand
confidence method is most of us have credit or debit cards that credit or
debit card in it if it's chip and pen or just if it's a chip card has a
cryptographic key embedded in it that's non-extractable and if you put it
into a card terminal it will generate

Manu Sporny: create a digital signature for the transaction at hand. that
is a type of confidence method. it raises the retailer's confidence that
card is legitimate. It's not just the numbers on the card that are printed
on it. it's a cryptographic assertion that card is a legitimate card. and
then when that token it is sent to the credit card or the debit card
network the network can verify that this is a legitimate card being used.

Manu Sporny: So that's effectively what one variation of confidence method
is if we are issuing verifiable credentials that are effectively represent
physical cards in the real world and that's being done in the ecosystem
right some people are issuing verifiable credentials that talk about an
entity a person something like that others are issuing verifiable
credentials that quite literally represent a physical card and you need the
same mechanism to gain confidence that digital card is legitimate and the
way we do that is using a cryptographic binding of some kind. So when that
card is presented you use a confidence method the cryptographic key listed
with the verifiable credential to do a check to make sure that the person
presenting that digital credential has the cryptographic key material
associated with the credential.
00:25:00

Manu Sporny: okay so that's largely what confidence method is about. You
can attach it to credentials, you can attach it to another confidence
method could be a literal picture of the person. This is again not a good
thing to do from a privacy perspective. but there are other things like
potentially biometric templates that could be used as confidence methods.
there could be remote identity proofing services that an individual trusts
to be used for them instead of sharing their biometrics wi with everyone.
so that's another example of a potential confidence method.

Manu Sporny: so again just like render method it's a fairly generic
generalizable scheme to raise confidence that you are dealing with the
digital data or the entity that you believe you're interacting with. this
specification is cleared to be worked on by the VC working group right now.
but it has gotten very little love in the last year and a half or two
years. it is definitely work that's worth doing. but in order to do that
work, we would need a new editor. We would need, meetings around it. We
would need people to engage.

Manu Sporny: I don't think that it would take much more than, a month or
two of fairly close engagement to get it into a state where we could kick
it over to the verifiable credential working group. but it would be
something that people need to really participate to get it into shape. let
me stop there. Any questions on confidence method? Yes. …

Alex Higuera: Could confidence method be used for verifying or giving
legitimacy to an entry for a registry?

Manu Sporny: if it dep so Alex I think it depends on exactly what does that
protocol look like?

Manu Sporny: What's the registry entry look like?

Manu Sporny: But yeah, I mean if you've got an issuer in a registry and you
want to gain confidence when you contact the issuer that they are the same
one that's in the registry, then you could use the confidence method, to
check that. Was that your question, Alex? Okay,…

Alex Higuera: Okay. Yeah.

Alex Higuera: More or less.

Manu Sporny: Thanks. Dave, you're up.

Dave Lehn: Yeah, along with the render method, I don't know if there's
going to be a pattern with these sorts of things like each of these specs
may be a similar construct on at least at a high level thing how to model
some of this stuff and the render method would have its render methods and
this one would have its competence methods and I don't know maybe the same
issue of inserting the different ones like this is the verification key
confirmation is that supposed to be defined in here as well as just the
general structure and…

Dave Lehn: there could be other competent meth confidence methods. Is it
the same idea as render method in that respect

Manu Sporny: Yes. Yeah,…

Manu Sporny: it's the same concept. I'll to be clear for it to become a VC
working group item we just have to do kind of the base architecture design
and provide one mechanism and then we have to say other mechanisms are
possible you can totally create them it can be an extension yada right I
mean so we don't have to define every single one of them in the spec we
just have to kind of create the base rails

Manu Sporny: that all the other render methods or all the other confidence
methods can roll over.

Dave Lehn: Do any have to be defined in the same it's the same issue with
both Yeah,…

Manu Sporny: We will get formal objections if we don't define at least one.
It's happened every single time, It's like it happened to us with DIDs and
it DID stuff up for a year and a half. It's a bad idea. And that's the
whole reason render method and confidence method are not in the current
spec is because we didn't define at least one concrete mechanism.
00:30:00

Manu Sporny: So Mhm.

Dave Lehn: just I mean from my perspective it just seems like it's two
different problems. One is to define a particular method and the other is
to define the structure of how methods are created and it seems like that
would be two specs to me but I mean I understand putting one into the other
and if people have problems with one that's there they can just call it
verification key confirmation 2 and define it somewhere else. I don't know
if that's the best way to do things, but that is one approach.

Manu Sporny: we have to define one thing. It's just from a process
perspective, it's inescapable. go ahead, Will.

Will Abramson: Yeah, I just wanted to say, I think I agree with you, This
is quite a bit of work, it's definitely underloved and under attentioned in
the CCG, but I think it would be interesting for the CCG to think about,
okay, how do we resource something like this, right? It's a great example
of things that need resource. Can we spin up a community even for a short
period of time that, meets regularly and gets the spec to a state that the
PCWG could take it on?

Will Abramson: Because currently I think the answer is at this current
state right the VCWG wouldn't take this spec on I don't think it's not
quite ready.

Manu Sporny: Yeah. Yeah.

Manu Sporny: Totally agree.

Will Abramson: I do agree with you if we could get a group of committed
individuals to commit I don't know three months or whatever maybe it could
get to the state. but yeah I mean I think for that I'm supportive of the
work. I guess it's what types, longer if this was adopted with the BCWG,
how many types would we want to define? I mean, I kind of agree with Dave
like these things,…

Will Abramson: people come up with a confidence method and can just define
their own spec for it and define a type. I guess you need a context as
well. It's some work to I mean I think the confident method I would like to
see is one that's a signature from a verification method in this of the
subject. is that not a confidence weapon?

Manu Sporny: Yep.

Manu Sporny: And that was proposed as the one type we define because it's
the easiest example and most useful right yeah yeah I mean the default is …

Will Abramson: And I think it's the one that people kind of use already,
without having the structure around it. This is kind of the default. Yeah.

Manu Sporny: if you're using a DID then your confidence method is an
authentication method in DID document.

Manu Sporny: that's a presumption that when you're using ds people make…

Will Abramson: Yep. Mhm.

Manu Sporny: but this would make it a little more explicit. It would also
allow for use cases where it's not did related at all. you're just saying,
"Hey, here's a credit card and it's got a key associated with it and if you
take this card,…

Manu Sporny: you really should you have to verify that the person has,
control of the private key.

Will Abramson: Yeah, that reminds me your example maybe think confidence
method is about maybe you have multiple right and…

Will Abramson: you can do more than one to build up confidence with the
card example you might ask for a signature from the card…

Will Abramson: but if I'm tapping I generally have a maximum amount I can
tap up to before it says it wants extra confidence right and it'll ask me
to put my pin in as that I fit in,…

Manu Sporny: Exactly. Yep.

Will Abramson: but that's additional confidence.

Manu Sporny: Yep. Yeah. And you'd list it as an array of confidence methods.

Will Abramson: Mhm.

Manu Sporny: And then, that raises the question of do we have, levels of
confidence 1 2 3 4, all that. it kind of opens up that can of worms. but
yeah, that's exactly so that's confidence method. I think we're basically
saying the spec needs work before we can even consider moving it to BCWG.
so it's not as far along as render method and render method even needs some
work. The next one, is the verifiable credential barcodes specification.

Manu Sporny: this spec is about basically maximally compressing a
verifiable credential and putting it into existing credentials we use in
the real world like driver's licenses. So this is the PDF 417 data on the
back of a driver's license. This does have I think a 200 bytish verifiable
credential embedded in it that secures all the data on the back of the
driver's license. believe it or not driver's licenses many of the driver's
license the vast majority that we carry around with us you can change as
much data in the back of this card as you want to and no one will be the
wiser.
00:35:00

Manu Sporny: they don't have any kind of digital signature or any mechanism
that a verifier can use to see if it's a legitimate driver's license or
not. That's why it fake driver's licenses have such a healthy secondary
market and buying fake IDs. okay, so that's what this spec is about. you
have to do quite a bit of transformation on data to get it down to get a
verifiable credential down to 185 bytes but it is possible. this spec kind
of outlines how you do it. We also specify how you can do it with QR codes
so employment authorization documents, permanent resident cards, driver's
licenses use PDF 417.

Manu Sporny: it defines all kind the data model, the algorithms, how you
can do things like status lists, and how you can compress these things down
to a really really really small size. we've got a full set of test vectors
that people can use for international driver's licenses and US driver's
licenses. and people can kind of follow along to understand how to both
create and sign and then verify these documents. this spec is from a
development standpoint fairly mature. This technology is going out into
production. the technology has already gone out into production 3 years ago.

Manu Sporny: it is additionally going out into production through a bunch
of different other kind of venues around driver's licenses and permanent
resin cards and things of that nature. that's going to happen before we
even get this specification into the verifiable credential working group.
But the specification has been put together in a way that allows us to
change just about anything in the specification while it goes through
official standardization. So it doesn't mean that we're stuck with what's
being deployed out into production, but it would be very nice if we had
that documented in a way that made this a global standard. let me pause
there. Any questions on the verifiable credential barcode stuff? go ahead,
Lane.

Dave Lehn: Yeah, I have two questions here. one,…

Dave Lehn: this depends on the seabboard LD work. is that going to be a
blocker for moving this forward?

Manu Sporny: Yes, it will be a blocker for it becoming a global standard.

Manu Sporny: Yes, until seorld is also and…

Manu Sporny: and there is a plane just so everyone I think there's and
Benjamin maybe you can speak more to this since you're the chair of that
group.

Benjamin Young: Yeah. …

Benjamin Young: Core LD is making its way into the new JasonLD working
group charter and we're hoping to get that into the voting space towards
TAC so that we can have meetings around it at TAC in November. so if you're
interested in SEO LD work, we'd love to have you come to the JasonLD
working group calls and occasionally we do CG calls as well that anyone can
come to without formally joining the working group.

Manu Sporny: Yeah,…

Benjamin Young: And I believe our next Wednesday is on Cabore LD on the
26th.

Dave Lehn: I had another question too is should this be split up for the
tur spit string status list I've never really understood…

Dave Lehn: why we had these hooked together when it seems like it could be
something else I mean that's where it's being used at the moment but it may
be useful on its own.

Manu Sporny: I mean you know that those are the types of details that maybe
the working group could work on. cuz again it's like we could split tur bit
spitst string status list into its own specification.

Manu Sporny: But that's just doing it just for the sake of doing that to
cleanly architect the specs adds an enormous amount of W3C process over
publishing a four-page specification right …

Dave Lehn: but it's also hard to understand why it's even in here,…

Manu Sporny: because you need tur bit string you need this technology to be
able to compress the credentials down so that they can p fit in a PDF or…

Dave Lehn: I Yeah,…

Manu Sporny: 17. That's…

Dave Lehn: I understand that.

Manu Sporny: why it exists there.

Dave Lehn: But by the same argument, put Seore LD back in here. that
doesn't really make any sense. So, …

Manu Sporny: There you have to make judgment calls on what goes in certain
specs and what doesn't. Clearly core LD is like a big spec and…

Dave Lehn: I mean,…

Manu Sporny: is a separate thing. Tur bit string is kind of you need it to
be able to compress these credentials small enough so that they fit on a ID
card, right?
00:40:00

Dave Lehn: sure, but I mean it could maybe be argued that that should be
put over into the regular bit string status list spec or…

Manu Sporny: Except the regular bitst string status list spec is being
published right now as a global standard and…

Dave Lehn:

Dave Lehn: something, version

Manu Sporny: we can't do that we could in the next version but then that
has a 2-year time window on getting it to we wouldn't, accelerate the
publication of the one thing and we are prevented from adding new features.
that's why it's not in there. Like I said, they're like W3C process things
that get in the way of us, quote unquote doing the right thing here. go
ahead, Ted.

Ted Thibodeau Jr: Yeah, just to note this is one of those places where the
perfect is absolutely the enemy of the good. we could perfectly split
things out…

Ted Thibodeau Jr: if we wanted to look at say a decade to achieve the thing
that we think we might be able to achieve in two or three years. it's
nature of the beast.

Manu Sporny: Yep. Absolutely.

Ted Thibodeau Jr: And I say that from having been in a bunch of W3 groups.

Manu Sporny: Plus one to that. exactly right. so Dave, that's yes, what Ted
said. okay. I'm not going to dwell too much more on this spec. It's just
there and, is pretty mature from a technology perspective. we have multiple
demonstrations of interop that sort of thing. Okay. next item up is the
verifiable credentials API.

Manu Sporny: this specification has been in incubation for I think three
years in the CCG. it's been here for a very very long long time. There has
been a group meeting on it regularly for two of those three years. this is
deployed in large scale production deployments. today variations of this a
subset of it is what powers the verifiable credential working group test
suite. We have 25 implementations of the base API just issue and we have a
number of other implementations that do workflows and exchanges.

Manu Sporny: again the thing this specification is suffering from most is
that we need to write s to finish up the specification. I think we have 45
PRs that we need to write which sounds like a lot but it's really not.
those can be done in 3 months time. there's clear direction on where to go
for all those issues that need PRs. you're just short staffed as far as
getting those PRs done. the design's fairly, locked in at this point. The
end points are fairly locked in. The arguments for the end points, are
fairly locked in. So, that doesn't mean things can't change. Certainly,
they can change. but I think the group that's working on this feels pretty
confident u in its current state.

Manu Sporny: certainly confident enough to hand it over to the VCWG. I
think one thing that would be nice to do here is to clear out all of the
issues and get all those PRs done, but like I said, it's just a number of
people raising PRs and the rate at which we're raising them. thing. go
ahead, Benjamin.

Benjamin Young: I would say the one danger of moving to the WG without
those merged is that they would necessarily need to be redised if they're
in a pending state where it's much easier…

Benjamin Young: if they're already part of the spec which obviously the
spec would get redised but any of those flight PRs can be painful to merge…

Manu Sporny: Yes. Yep.

Benjamin Young: if The governance structure changes.

Manu Sporny: Totally agree 100%. so I think ideally we would do all those
PRs before we handed it over to the verifiable credential working group. I
think that's probably what needs to happen and could happen in the interim
between the charter would need to change the BCWG charter would need to be
updated to include this work. but while the charter is being changed and
voted on we could get a lot of this stuff done and then do a final spec
release on it. Okay.

Manu Sporny: if there are there any questions on VC API, looks like I
opened the barcode spec twice, so we only have one spec left to cover. And
that is the verifiable credentials over wireless spec. we haven't moved
this over to CCG yet. but it's one of those things that has some overlap
with rendering. So this is largely work that's happening so in the retail
sector we're working with a standards body for the retail sector that
wanted to see some kind of movement on NFC.
00:45:00

Manu Sporny: Same thing for work with first responders that we reported on
to the CCG. there's a desire to do tap to transfer verifiable credentials.
so this creates a mechanism where you can do tap to transfer includes
Bluetooth in the future includes Fi and Wi-Fi aware and is protocol
agnostic meaning it can use any of those things including it can switch
over to open ID4 it can switch over to proprietary API if people want to do
that or it can use the more open protocols and APIs defined in the
specification. it also defines a render method for NFC.

Manu Sporny: so an NFC rendering template. And what this does is it allows
you to say, you have your digital wallet in front of you, click on the
card, and then there can be a NFC tap icon that lets you tap to an FC
device. and it supports both legacy NFC and doing it as a verifiable
credential. So, for example, if you have a Subway card today, if you have a
Subway card, it's an NFC tap thing. it's usually a static, payload. this
would allow you to have a verifiable credential of your subway card. and it
would allow you to put it into an NFC mode where you would just walk to a
legacy subway turn style, tap, and go through, right?

Manu Sporny: and you could also use your Subway card online, to, update the
account balance, access Metro services, that sort of thing. so this is a
verifiable credential that you could use potentially through optical
barcode, a different render method, or you could use digitally, when you're
online. this render method thing might be better over in the render method
spec and not in the rest of this kind of deals with protocol related stuff
associated with tap to transfer.

Manu Sporny: So, this has the, Seabore LD compression on a verifiable
credential being able to upgrade from an NFC tap to a Bluetooth connection.
and things of that nature. so, this tells you how you can protocol upgrade
from an NFC tap to an internet-based exchange through verifiable credential
API. It allows you to do an NFC tap and upgrade to i-Fi aware or Bluetooth
with a pairing code and a variety of different things like that. So the
wireless spec is just how do you move verifiable credentials over short
range wireless without having to go over the internet, browser APIs,
protocols, things like that.

Manu Sporny: Any questions on the VC wireless spec? This is one that would
probably need some work before we moved it over. if there are no questions,
we don't need to stick on longer. what we may use the other calls to do is
iterate through these raise issues, address things that we feel we really
have to address before we hand it over to the VCWG. we can also use this
call to work on the changes to the VCWG charter.

Manu Sporny: things that need to be updated to take on are there any other
work items that folks wanted to cover? Anything else that you feel we
should be putting in scope to move over? I guess one of the things we did
not talk about today, noting that Greg's here and Andrew's here, is that we
didn't talk about some of the kind of more next generation data integrity
mechanisms like the postquantum signatures are probably the one that's most
ready to maybe be moved over. They're pretty straightforward things.
00:50:00

Manu Sporny: we may need to do some work on selective disclosure and things
like that, but that group's been work meeting regularly. there's also the
postquantum unlinkable stuff and things of that nature. So there's the
anony v2 BBS stuff that might also be worth discussing. so raising that is,
we didn't cover those things, but there's a different group to kind of
cover those things. Phil, if you don't mind vocalizing that the chat isn't
saved, unfortunately. so you might be muted, Phil, if you're talking.

Phillip Long: It was very articulate I was just saying that asking the
question is there any n work at all in how the data in a credential is
intended to be used by a recipient in terms of describing the way in which
it should or shouldn't be passed on or modified anything like That worked
to do. Okay.

Manu Sporny: not in the CCG that I know of.

Manu Sporny: There is definitely threat modeling work that's being done in
the security IG specifically around digital credentials and the APIs
associated with them. that is where I would expect that work is being done.
Yeah, I mean it would be definitely good if the CCG were participating in
that more directly.

Manu Sporny: But that group's doing a good job of coming up with threat
models for digital credentials and things of that nature.

Phillip Long: very good.

Phillip Long: Thank you.

Manu Sporny: So I see maybe Harrison maybe we bring Simony from the
security IG into the CCG to talk about the threat modeling work that
they've done on digital credentials and the API.

Manu Sporny: In fact, you might already have him booked.

Harrison Tang: I'll check…

Harrison Tang: but yes I will invite him to talk about that.

Manu Sporny: Yeah, because they're doing some really good work on the
threat modeling stuff, which Phil would answer your I think that's it for
today. Any other questions, comments, concerns, anything of that nature?
All right. if not, thank you everyone for the wonderful call today. Thank
you for the great discussion and talking through each one of these specs,
what extra work we need to do on each one of them to get them ready for
promotion. I'll go ahead and send the meeting minutes. This was, using the
new meeting system.

Manu Sporny: So, everything was transcribed and that'll go out hopefully
later today. but before we end, Harrison, over to you.

Harrison Tang: Yeah, I just sorry I joined late, but is this a recurring
meeting because I forgot to put it on my calendar. So, just want to talk

Manu Sporny: It is. Yeah. So, we're going to meet again next week and keep
the discussion going. I think that that is definitely becoming a problem.
we're missing people and picking them up halfway through the meeting. I
forgot to send an invite out. but I also figured out that there is a way to
add them to the main Harrison, I didn't know if we should do that. we
should probably do that now because people are missing the meetings, but
when we, officially move over to the new meeting infrastructure, we're
going to need to update every single one of the meeting links.

Manu Sporny: which I think will be fine, but just a heads up to as chair,…

Ted Thibodeau Jr: Yeah, just to note this will be conflicting with VCWG.

Manu Sporny: you'll be probably in the middle of that administrative task.

Harrison Tang: Got it. Yeah, no problem. Cool.

Manu Sporny: Okay, go ahead, And we'll just cancel the meeting if it does.
we're expecting VCWG to not meet at least for the next two to three months
regularly, but if they do meet, we'll cancel these meetings so people don't
have to that's it for the call today. thank you again to everyone. We will
see you again next week at the same time on the same channel. Appreciate
the discussion. Thanks. Bye.
Meeting ended after 00:55:36 👋

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