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

CCG Incubation and Promotion Meeting Summary - 2025-04-30

*Topics Covered:*

   1.

   *Meeting Scheduling and Cadence:* The group discussed the challenges of
   scheduling meetings due to conflicts with the Verifiable Credentials
   Working Group (VCWG) meetings. A solution was proposed: the CCG meeting
   will be held weekly unless a VCWG meeting is scheduled. The cadence will
   become more predictable after May 15th, when all Version 2.0 verifiable
   credential specifications are expected to be published.
   2.

   *VC Render Method Pull Request Review (PR #17):* The majority of the
   meeting focused on reviewing and finalizing a pull request
concerning the render
   method specification. This specification aims to standardize how
   verifiable credentials (VCs) are rendered across different formats and
   devices. Key aspects discussed included:
   - *Template Render Method:* The group reviewed the structure and
      properties of the template render method, including the use of render
      suites (SVG, PDF, NFC) to define different rendering types.
      - *SVG Mustache Render Suite:* Three variations were discussed:
      embedding the SVG template within the VC, linking to a remotely
hosted SVG,
      and externally hosting both the render suite and the template. The
      implications of using digest multibase for security were
explored, allowing
      for either fixed or dynamically updatable templates.
      - *PDF Render Suite:* Similar variations to the SVG suite were
      discussed, acknowledging the use of Mustache templating and potential
      considerations for PDF-specific templating. Leonard Rosenthal's (Adobe)
      positive feedback on the use of Mustache for PDFs was noted.
      - *NFC Render Suite:* This suite focuses on transmitting VC data
      wirelessly via NFC. The importance of specifying which data is
transmitted
      for privacy reasons was highlighted, along with considerations for
      post-quantum security and the trade-offs between data size and
transmission
      time. The use of a label for user understanding ("Tap to Send") was
      discussed.
   3.

   *Issue Review:* The group reviewed open issues in the repository to
   determine which needed to be addressed before handing the specification
   over to the VCWG. Several issues were deemed suitable for the VCWG to
   handle, such as overlay capture bundles (requiring input from Patrick), and
   multilingual support. However, the issue of supporting functional
   operations in the render method was identified as requiring further
   discussion and a proposal before handover. Also requiring further
   discussion was support for compound link credentials and list/card view
   rendering.

*Key Points:*

   - A more stable meeting schedule will be in place after May 15th.
   - The render method specification aims for flexibility and
   extensibility, supporting various rendering formats and allowing for both
   embedded and remotely hosted templates.
   - Security considerations (digest multibase, post-quantum signatures)
   were central to the discussion of various render suites.
   - The NFC render suite prioritizes concise data transmission for a
   smooth user experience while emphasizing privacy concerns.
   - The group identified several issues that are ready for handover to the
   VCWG.
   - Issues related to functional operations and multi-credential rendering
   require further discussion and proposals before handover.

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

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-04-30.mp4
*CCG Incubation and Promotion - 2025/04/30 10:58 EDT - Transcript*
*Attendees*

Alex Higuera, Atoyeje Michael, Benjamin Young, Hiroyuki Sano, John's
Notetaker, Kayode Ezike, Mahmoud Alkhraishi, Manu Sporny, Parth Bhatt,
Przemek P, Ted Thibodeau Jr, Vikas Malhotra
*Transcript*

Mahmoud Alkhraishi: Hello. Is my audio coming through fine?

Manu Sporny: Hey Mun.

Mahmoud Alkhraishi: Awesome.

Manu Sporny: All right, let's go ahead and get started and maybe the other
regulars will join us in a bit. first of all, apologies for the calendaring
thing. I think it got out to some people and didn't other people. I've been
getting emails and messages about whether or not the call's happening today
or not. So, we learned our lesson. Don't try and change the time of the
call. I did speak with Mahmood earlier today to try and get the call on the
CCG calendar. I think people just have multiple copies of this meeting on
their calendar at this point and it's probably going to take us a month or
two to clean them up.

Manu Sporny: the challenge that we have is that we don't know if VCWG
meetings are going to happen because they're typically cancelled the day
before the meeting and I usually try to send out a agenda for the meeting
multiple days in advance for this meeting. we're just going to have to play
it by ear. I think what I'm going to do is just hold this meeting on the
calendar, not change the time, and if a VCWG meeting happens, then the VCWG
meeting happens. And then, if not this meeting happens. So, you just show
up to this meeting and if you know it doesn't open by 5 minutes past the
hour, then it's canled.
00:05:00

Manu Sporny: I will also send cancellations out to the mailing list, but it
looks like we're having the great problem with calendar entries happening
now. so that'll be the plan going forward. I think the VCWG was planning to
continue to meet until all the version 2.0 verifiable credential version
2.0 specifications are published. we expect that to happen by May 15th. and
then after that I think we'll have a more dependable schedule. okay. So
going forward I think the expectation is this meeting will happen every
single week unless there's a VCWG meeting where it won't happen every week.

Manu Sporny: We'll just have some guessing until May 15th and then once May
15th hits, I expect the updated meeting cadence would be 3 weeks with this
meeting, one week with the VCWG meeting, and then alternating until that
group is rechartered with the work that we're incubating and promoting in
this group. let me see if there are any questions on that before I move on.
hopefully that's clear. we do have a couple of new folks. I don't know if
you want to introduce yourself. and I am sorry if I'm going to not
pronounce your name correctly.

Manu Sporny: I don't know if it's Michael or Ottohei. In any case, if you
want to introduce yourself, you're more than welcome to, but if you're just
kind of listening in for today, that's fine, too. okay, let's go ahead and
get started. the agenda for this week is to just cover the rest of the
render method pull request. We started last week on that. and we will
finish that out and then see if there are any other items that we need to
cover in render method before we wrap the work up and send it on to the
BCWG. So that'll be the focus of the call today. Are there any other
updates or changes to the agenda? Anything else that people would like to
cover today? All right.

Manu Sporny: If not, let's go ahead and jump back into where we were the
last time with VC render method. let me pull up the pull request and
thankfully we've got a nice preview render mechanism. so last time we met
two weeks ago maybe it was last week, can't remember. we started looking at
the data model or the render method property. we explored this new so we've
learned a bit around this mechanism over the past year or so really two
years where we've deployed it gotten some experimental feedback and found
out that the thing we were doing previously with the SVG render template
was not adequate.

Manu Sporny: we wanted textbased stuff, we wanted also SVG based stuff and
so what we were doing before was just inadequate and so this is a second
attempt at the render method. with the learnings that we had we went
through the base property, we went through the properties for the template
render method. these properties. we took a look at this kind of general
format. I know that Demetry added a couple of issues that he'd like us to
kind of take a look at and cover.

Manu Sporny: and then we got all the way to the point where we looked at an
example, talked a bit about PDF, but didn't get to look at the specific
render suites. so the render method is structured so that just like the
cryptographic suites that we have for data integrity, we have render
suites. So we only have one templated render method type, but you can have
many different render suites. and these are just strings that identify the
render suite. The expectation is that there's going to be an extension
registry and whoever wants to add new render suites can do so fairly
easily. and without necessarily having to go through the whole glo global
standard setting process to do that. we are discovering that there are some
other countries that are taking advantage of that in a good way.
00:10:00

Manu Sporny: where they are experimenting with these extensions and
sometimes in a very large degree at a national level without necessarily
going through W3C to standardize it or the CCG which is fine we set this
whole ecosystem up for decentralized innovation and that looks like that's
working fairly well or according to plan. So, let me stop there and see if
there are any questions or concerns about what we covered last time. If
not, we'll start looking at the specific render suites. Any questions,
concerns with kind of the general structure of the template render method
so far?

Manu Sporny: and that's of course won't take that as everyone's totally
cool with it. It's just that no questions We have plenty of time to debate,
things once it's in the working group. one of the things that came up is
like, do we really want to specify SVG here or mustache here or do we want
to depend on media types or a variety of other things like that. So I think
those are still kind of up for discussion and debate and design tweaks as
we go on. let's talk about a render suite. So the general template render
method kind of exists here and these are the properties that you can put in
it and these are the properties you can put in a render template. we talked
about some use cases last time. Make sure that we covered everything.

Manu Sporny: And then for the SVG mustache render suite, this is how you
would basically express an SVGbased template to do a graphical layout of
the credential. so the identifier is SVG meaning this is the, type of file
you're expecting. And then mustache is the type of templating language that
you're going to use. other people can make other choices on their
templating language, but we've picked mustache because that seems to be the
thing that most people are comfortable with. and then of course the easiest
example of this is where you include the template in the verifiable
credential itself. So it's a totally self-contained credential.

Manu Sporny: anyone reading that credential can look at the data in the
verifiable credential and render it in a totally offline capacity and then
the verifier that's rendering it knows that the issuer intended the
graphics and all that kind of stuff to look the way it is on screen. So,
this is a way for an issuer to basically say, this is a student ID for
Utopia University and this is all of our branding and logos and colors and
fonts and all of that stuff embedded in here. So, we use data URL to do
that for the template points to a URL. This is a data URL. It expresses an
SVG that's B 64 encoded.

Manu Sporny: And then you have the rest of the B 64 encoded information
here. So that's how you do an embedded item. if you want to remotely host
the SVG file, you can provide a link to the SVG template and this is kind
of up for debate. They're like, do we want to use an SVG here? Do we want
to say it's an SVG template? How do I gzip that sort of thing. this media
type is here to basically signal that you expect this file to be of type
image SVG. This is wrong of course that this should be image SVG plus XML I
think. and then there's questions around what happens if this is gzip. What
do we do here?

Manu Sporny: is that there's some open questions here about this but
fundamentally you're expecting to get back an SVG file and you expect the
SVG file to have this cryptographic digest so that the issuer can say
here's a remote resource I want you to go out and get my template for
rendering the VC but they're going to digitally sign over the cryptographic
digest so that even if the issuer is compromised or accidentally you change
the template in some way. the verifier has a way of detecting it and then
not using the template to do the rendering. They can say, "Hey, the
templates's been compromised. I can't display this." so on and so forth.
you can also choose to not include the digest multibase. And if you do
that, that means that the issuer can change the look and feel of the
credential over time.
00:15:00

Manu Sporny: So if they issue a student ID and then every year the graphics
around the student ID changes then it would allow the branding in the
wallet to update over time where the credential that's issued has a very
long lifespan. So student ID is issued for four years. they put a student
ID, SVG template for what the card should look like into The verifiable
credential is good for four years. it's an SVG, but if they keep the digest
multibase off of it, that university can update the look and feel of the
student ID every single year.

Manu Sporny: the student gets, those updates in their digital wallet. each
time they look at the credential, if it has a new template, the template
updates, fresh branding, organizations like that, brand refreshes every now
and then. but they don't have to go and reissue, tens of thousands of new
credentials to do that. So there's an argument here for not putting digest
multibase on here and just trusting your issue website architecture to
protect that file appropriately. So you can do either is the takeaway here.
So example two is a completely embedded G nder Example three is a remote
render template but it's secured using a digest multibbase.

Manu Sporny: So the verifier can be sure that the thing they're issuing
that they're fetching over the web is valid. and then number four is a
completely remotely hosted render method. which is an interesting we don't
know how useful this is going to be. I'll just be blunt. this is
interesting because it allows issuers to just publish render methods openly
as separate things on their website and include the entirety of it and
digest multibase and secure it. So here you're not even saying whether I
guess this one kind of in the name it says SVG but we could in the future
not even mention that it's an SVG template.

Manu Sporny: there's a question around render suite here as well, But the
idea here is that you could publish rendering suites that are corporate or
organization specific as a completely separate thing that your marketing
and media and design team does they have a totally different process that
results in this and the issuer just includes their output. this is more of
a decoupling the organization's media relations branding folks from the
technical So the technical infrastructure folks just focus on issuing valid
verifiable credentials and the data models good and all that kind of stuff
and then the media team deals with what the look and feel can be. So this
decouples things internally as an organization.

Manu Sporny: Okay so that is kind of the three ways of expressing these
rendering template Cody go ahead little different I think.

Kayode Ezike: Yeah, for this last one you just described, are you thinking
that this would be something like a web view or something that's pulled
into the application that is hosted by the organization or just something a
little different than that? Because

Manu Sporny: I mean, so the design space on this is pretty large, Coyote,
so I wouldn't say that would never happen. that look that sounds like an
interesting idea and this is one way that you could achieve that. But I
think the purpose of this is to put this template information and if it
gets super complicated template information on a totally different website.

Manu Sporny: meaning that let's say that for whatever reason in this file
people wanted to express a template but they wanted to include the raw
template contents as a B 64 encoded thing, So it could be that this file
it's a graphics file, maybe it's 15 megabytes, right? Maybe somebody has a
super high resolution template but they don't want to embed that directly
and they don't necessarily just want to link to the SVG file. they want to
include the entirety of it in kind of one JSONLDD file. So again it's like
this is possible to do with the technology.
00:20:00

Manu Sporny: we don't know if there's a strong enough use case for someone
to pick this mechanism even though it's possible over this mechanism. We
think the first two mechanisms are probably going to be more popular. if I
had to bet on this, I would bet that this one is going to probably be the
most popular mechanism where people want to take their graphics content out
of the digitally signed credential so the credential doesn't balloon in
size to 15 megabytes or whatever. but at the same time they want to secure
the graphics content and there are of course privacy concerns around
posting content like this and who gets to fetch it and that kind of stuff.

Manu Sporny: But if we provide a digest multibase and we provide the link
to the file then that means that content distribution networks can address
some of the priTP could address some of the privacy concerns. I know that
was a very long-winded Coyote, did that answer your question?

Kayode Ezike: Yeah. Yeah. that made it clear. Thank you.

Manu Sporny: So, that's basically the SVG mustache render suite. three
variations of it. have to if I had to bet this one is probably going to be
the most popular, followed by this one when people are okay with their, VCs
being several megabytes in size, and then finally this one, for potentially
future more advanced use cases.

Manu Sporny: Any other questions on this render suite before we move to the
All right. So, moving on to the PDF render suite. This is almost exactly
the same only the base format is PDF instead of SVG. One of the things
we've noticed especially in the education sector is that there is a strong
desire to reuse PDFs for things like certificates of training, even
degrees. those are largely issued or shown in PDFs and people want to just
reuse the same stuff that they're using. meaning there's an existing
workflow that's based on PDF and of course we want to support that as well.

Manu Sporny: there were some concerns brought up around whether mustache is
the best templating mechanism for PDFs. some of you might have seen the
discussion on the mailing list where Leonard Rosenthal who is one of the
chief standards architects for Adobe jumped in and said yeah mustache is
good no problem there that's a fine choice. and then he also pushed back on
the concern around not being able to do templating well in PDFs. and he's
going to come in and chat with us about things we should consider around
the PDF templating. but he sounded like he was a very strong proponent of
supporting PDF as a templating u mechanism or sorry, as a template format
and having a mustache render suite.

Manu Sporny: so again, it's the same exact thing as SVGs. The layout's the
same. So if you want to embed the PDF in the verifiable credential, you do
this, right? You use a template indicator and you use a data URL and in
this case it's application/ PDF and then you base 64 encoded and this is
the B 64 encoded data. so that's if you want to embed the PDF in the
verifiable credential. If you want to link to an external PDF like a
bachelor's degree PDF, this is how you do it. You provide the link. So This
is the link to the template file. It's of type application PDF. And then
you provide a digest multibbase value if you want to lock it in place.

Manu Sporny: and if you want to be able to modify the template over time
again maybe universities want to so this is a great example. So if you have
a bachelor's degree issued at a university this allows the university to
determine if they want to lock the look and feel of that bachelor degree
issued in the year 2005 or whatever. if they want to lock the look and feel
of that they can do that in the VC or if the university wants all of their
degrees kind of from a visual perspective flow with the times where you get
views a new renderings of your degree the verifiable credential is good for
forever potentially right but the look and feel of it can change over time
so
00:25:00

Manu Sporny: an interesting thing, for universities to contemplate. And
again, they can choose one or the other. we're not forcing them to pick
just one. Okay. So, that's for externally hosted PDF files. And then again
if you want to have the rendering template it sorry the render suite
including the template hosted externally you can do that as well and that's
what example 7 is showing and the popularity of these again in theory is
this is probably going to be the most popular thing because people are
probably not going to want to put 1 megabyte PDF

Manu Sporny: FS into their verifiable credentials. followed by H maybe
people do have really highly optimized PDFs that are a couple of tens of
kilobytes in size and so in that case they do want to embed it totally in
the verifiable credential. and then the third option is for the more
advanced use cases. So that's PDF. It's just like the SVG thing. The only
things that's different is the based template format is PDF instead of any
questions on that item before we go to the NFC one? hopefully that means
that's straightfor Third item and this is the last item is the NFC render
suite.

Manu Sporny: so again the render method specification is about physical
manifestation a physical manifestation of the credential and that includes
potentially touch through sound and through basically any part of the
electromagnetic spectrum. So wireless, right? so a render sually, it can
render something to audio and it can render something to wireless. it can
also render something to a haptic display. There are ways of doing that.
render to vibrations.

Manu Sporny: There are a whole bunch of different things that we mean by
render, but this one specifically, the NFC render suite is different from
the other ones in that it's not a visual representation of it. It's a
wireless representation of the credential. And this is what you can use if
you want tap to verify, those kinds of FC like things. the way the render
template works is the render suite says it's we provide a label so that
people know why they would want to select this render method. So this is
kind of a tap to send thing. So if you had a again going back to the
student ID use case, if you had a student ID and there was this render
method in it, the human readable description is tap to send.

Manu Sporny: And so the wallet could render a button that says tap to send
which would then switch the wallet the app into an nse transmit mode and
once a tap happened it would literally transmit the bytes that's encoded in
the this template is an octet stream. It's a binary string right? it's a
bunch of ones and zeros that's B 64 encoded. And when the NFC device
detects a reader, it will transmit verbatim the binary string here. so that
can be used for things like subway tokens, to access subway turn styles.

Manu Sporny: can be used for organization like corporate security gates,
access gates, anything that needs a checkpoint. things like that. the
expectation with NFC as people probably know for every kilobyte of data you
have it takes roughly a second to transmit that kilobyte. there are many
variations of that, but that's the general rule of thumb. So the
expectation is that these templates are probably going to be definitely
less than 4 kilobytes, probably sub 1 kilobyte to make the tap experience a
good experience for the person using it. the other thing that we're looking
at is specifying what parts of the credential are actually transmitted
during the tap.
00:30:00

Manu Sporny: So the wallet needs to sometimes this stuff is binary right it
is binary and so you don't really know what's in there. and this is a way
for the wallet to say hey if you tap this NFC thing to another device we're
going to transmit the bar we're going to transmit the barcode in the
verifiable credential and that barcode will have a very specific value. So
this is a privacy preserving mechanism where your wallet can tell you
exactly the data that you're transmitting. and that's just not the case
these days, I mean you tap one of these cards, you have no idea what's
being transmitted and how traceable it is.

Manu Sporny: the answer is always very highly traceable. and so this could
be a way to get the wallet to help you understand your data that you're
transmitting when you tap via NFC. there are downsides to this or it's not
perfect the issuer can lie about this but if the issuer lies about this
they can be caught in the lie. if somebody reverse engineers the NFC tap
and it's like hey by the way they're transmitting your social security
number as well and they didn't tell you that they were doing that. so it's
a deterrent for issuers to lie about what's in the NFC thing that's being
transmitted. this is halfbaked.

Manu Sporny: I don't think we have fully explored kind of the design space
here, but it's there to try to make sure that we think deeply about that
before going to global standard with this and that's all it does. It
doesn't talk about protocols on purpose here, So, the render method is just
like here's some data and here's how you render it or here's some data and
you can render it, but it doesn't tell you what visual displays to use for
SVG and PDF. And for NFC, it doesn't tell you which NFC protocols to use
either. That's a separate specification. so we're going to try to stay out
of protocol land with this specification. okay, That's the new template
render method.

Manu Sporny: Pamic please.

Przemek P: Hey Manu,…

Przemek P: just a quick question. I know you and I talked about this
briefly, I think, but what are the downsides or limitations to securing
that NFC message or the size of the package in terms of quantum, making it
more quantum proof or the signatures. if you could spend just a little bit,
I know we talked a little bit about the difference of how much more you
could do over Bluetooth versus NFC with more quantum group credentials.

Manu Sporny: Yeah. Yeah. Excellent question. All right. So, how do we get
to postquantum protected payloads through NFC or Bluetooth? I will mention
that, Bluetooth is not one of the render suites that we have on here and we
probably should have it on here. I expect maybe the group will pick up that
work.

Manu Sporny: I think the first question is it possible to have a
postquantum u protected NFC message that transmits in a decent amount of
time? And I think the answer to that is meaning if we have a pretty bare
bones verifiable credential encoded in Seabore LD, we can get that
credential down to about 200 bytes. And then if we use a Falcon signature
on it, the Falcon signature is another couple of hundred bytes, which means
that we're well below the 1 kilobyte range. So with this thing is totally
workable for NFC as it exists today as long as NIST standardizes Falcon,
which they're planning to do at some point in the next year or two. Right?

Manu Sporny: So I think the quick answer is we can totally do a postquantum
secure verifiable credential over FC in a reasonable amount of time.
Totally achievable. We can see how to do that today. the only thing that's
going to lag is the kind of polit politics and standard setting stuff. But
even that's not really that far behind. for more involved postquantum
suites like MLDDSA and SL the lattisbased stuff MLDDSA and the u stateless
hashbased mechanisms like SLH is the worst right it's like 44 kilobyte
signatures you're not going to and over NFC that means you're sitting there
for 44
00:35:00

Przemek P: Tapping 50 times.

Manu Sporny: seconds as the thing. Yeah, Yeah. so that is totally not
workable over NFC and that's where we'd have to upgrade to Bluetooth. the
good news there though is that in the VC API we have a mechanism that
allows you to upgrade to Bluetooth quickly. meaning that let me see if I
can bring that up. we just merged this week. and it's the inactions
protocol work. So there's this thing called an interaction that the
specification defines. It is not specific to VC API.

Manu Sporny: You can do this for any protocol open ID ISO 1803-7 23
whatever dash any protocol can be done in this way right now I think we
generate an interaction URL and this interaction URL would be a Bluetooth
address that is the thing that would be sent over NFC from the wallet to
the reader and then you can pick any protocol from that point out.
Bluetooth being one of them. and then you can upgrade to a Bluetooth
interaction where you have effectively unlimited bandwidth for the purposes
of a postquantum VC.

Manu Sporny: So I think we have very good answers for this penic meaning
VCs allow parallel signatures you can sign in parallel with ECDSA and with
three different postquantum suites if you want the method if we have an NFC
render method we can do Falcon with an fully embedded thing. We can do
Falcon which has very small signature sizes. the other thing that's really
exciting is the isogynes based postquantum things. We have no idea if
they're going to survive, the security review, but they're looking really
good. Meaning the I think the key sizes are 65 bytes, which is very close
to ECDSA DDSA.

Manu Sporny: And then the signature sizes are 128 bytes which is twice as
big as an elliptic curve signature but it's still looking really good. So
that's our hope is that the isogyny stuff is going to stand the test of
time and then that means that all of a sudden we can do a whole bunch of
postquantum things using QR codes and MSC and stuff like that. did that
answer your question PMIC?

Przemek P: Yes,…

Przemek P: Thank you.

Manu Sporny: Okay. Yeah.

Manu Sporny: Yeah. I think I'm increasingly convinced that we've got the
postquantum thing handled in multiple ways. We still have work to do there,
but the data integrity groups working on the postquantum suites right now
that'll go into the next W3C charter.

Manu Sporny: we think maybe a year to a year and a half to standardize that
because the data integrity stuff's already done those are being published
as global standards May in two weeks and then we just build on top of that.
It slots into the existing infrastructure. Yeah. I mean, 2035 is supposed
to be the postquantum switchover date. that means you really want to be
switched over by 2030. but on the timeline re I'd say we'll have all this
stuff done by 2028 at the latest. Yep.

Przemek P: No, it's great. Thank you. And the use case I'm thinking about
just for the group is binding a payment token with a verifiable credential,
right? So, it's kind of helping solve this user not present problem.
00:40:00

Przemek P: That plates all sorts of things from wallet provisioning to
fraudulent purchases.

Manu Sporny: Absolutely. Yep.

Przemek P: So cool.

Manu Sporny: Absolutely. And one of the things that I think is an open kind
of discussion here is on that payment token kind of use case is can we get
to dynamic templates here where we create a template and VC goes in this
part and then maybe payment token specific stuff goes in another part or
maybe the whole thing is a payment token with a VC embedded in it.

Manu Sporny: there's a bunch of really interesting design space there. I
think that would make the NC render suite it would force it to be a little
more dynamic, which would be good. I think that's it for this PR. so if
there are no objections to this, we're just going to merge it. we've gotten
a bunch of good feedback on the PR. let's say by this weekend, so if folks
don't have any objections by this weekend, if you haven't had a chance to
review it, please review it. This is pull request 17 on the BC render
method spec. and then if I don't see any objections by the weekend, I'll go
ahead and merge that. All right.

Manu Sporny: on to the next thing which is just an issue review. what we
are looking for here are signals on we really need to address this before
we hand this over to the verifiable credential working group or it's fine
for the verifiable credential working group to have a discussion on the
primary thing that we're trying to do here is we don't have to solve all
the problems here, but the more problems that we solve here, the easier
it's going to be for the verifiable credentials working group to do the
rest of the work. things take longer in a working group. whereas we can
move more rapidly here.

Manu Sporny: So what we're looking for is like, no, I really want to work
on this problem in the CCG because I'm afraid that if we put it in the VR
fiber credential working group, it could just take a long time due to
process reasons. So with that, let's go ahead and start looking over each
issue. What we're looking for here is someone to say, I really think we
need to work on this before handing it over to the BCWG. And if we don't
get any of that, then we'll, say we're wrapped up with work here. We're
ready to hand it over to the BCWG and we're fine with them addressing these
other issues. All right. The first one is overlay capture bundles. this was
submitted by Michael Sahi June of last year, so almost a year ago.

Manu Sporny: and this has to do with OCA bundles. there is nothing
specifically. Patrick, are you on the call, Patrick today? No, he's not.
we'll ask Patrick if he wants to expand more on this. OCA is something that
they use, I think, in Canada. there is nothing to prevent them from
creating an extension and working on this independently. but I think what
we're trying to see here is if they want their OCA stuff to be in the
render method spec. so we'll have to hear from Patrick if he wants this
included. Does anybody else feel strongly about OCA? You deploying it or
thinking of deploying it or using it?

Manu Sporny: Okay, that'll be up to Patrick then to let us know, what he
feels about that. publish context file for render method. Yes, absolutely
we need to do that. We haven't done that yet because, we're not done. this
will happen as a part of the working group. I don't think we need to work
on this before that they work on it's just a natural part of it. specify
usage type display preference for list view credent can you provide a hint
in a render method that hey if you're rendering it in a list use this to
render it in the list.
00:45:00

Manu Sporny: I saw a hand go up, but I did not see who it was. I guess the
question is, this feels like there's design work around it. and maybe we
need to ask Paul to come in and see if he wants this to happen before we
transition to BCWG. I don't know why are right he's not in this particular
repo really. Is to do of course it's not going to do the right thing.

Manu Sporny: we are trying to figure out if you'd like this resolved before
we hand the work over to VCWG. are you interested in joining a call to
provide your thoughts on this? I think we have a good handle on what? let's
ask Demetri, too. is Dimmitri here today? No, he's not.

Manu Sporny: if you like this be good before we All right. So, I'll do
that. and I think what this would end up it would result in is you would
have something that says, card view, whatever, right?

Manu Sporny: And we'd have list view and pro we'd probably have list view
and card view and then maybe a full view meaning like a full-blown birth
certificate or university degree or something of that nature something that
has a tremendous amount of information on it. citizenship naturalization
certificate, those are examples of kind of full views. let me go ahead and
write that down. At the present, I think the starting set of things to be
something along the lines of card list in that's that item.

Manu Sporny: phone home mitigations is a privacy concern. This will
automatically happen as a part of the VCWG. So, I don't think we need to do
this one. And anyone, please feel free to stop and go back. if you object,
I'm trying to get through all this stuff before the end of the call so we
can wrap up the VC render method stuff today. support rendering of compound
link credentials. Yeah, this one is a bigger discussion.

Kayode Ezike: Yeah, I think it'll be good to tag Paul in that one again.
That he had a suggestion for building stuff that probably would be better
vocalized.

Manu Sporny: Okay, thanks. to explore this a bit more before handing over
as this feels like it would benefit from some discussion. screens. It could
potentially be a lot of work.

Manu Sporny: All right, thats multilingual. that this one's interesting. I
think the working group can handle this one. because the working group has
to deal with internationalization and localization. One approach here is to
use the localized properties.
00:50:00

Manu Sporny: but there's a whole bunch of questions around how to do this.
We've also got to give a heads up to the internationalization group on the
Render method is one of those things that's going to trigger a much more
scrutinized review by both the accessibility community and the
internationalization community. They're going to be very interested in
making sure we get this right. yeah, and there are two ways to go about
this and I hesitate to bring it up in this group. just because it'll slow
down the other things. I'm on the fence about this.

Manu Sporny: does anyone have any feelings about this happening in the VCWG
versus this group? Does anyone have any strong feelings about the way this
should be done? Okay, that to me is a signal that we can just push it into
the VCWG and they'll have to deal with it. they'll be forced to deal with
it. go ahead,…

Manu Sporny: Benjamin. Mhm.

Benjamin Young: Yeah, I think you're just probably going to end up with a
list of render methods with additional notes about…

Benjamin Young: who they're for. it's another way to cross-section the data…

Manu Sporny: Mhm. Yep. Mhm.

Benjamin Young: because nothing in what we're expressing n is not itself
rendered at least in the current proposal in that PR. the labels for things
are gone. some of the past render methods had names and things like that
where you would say this is the landscape view or whatever, but I think the
current proposal doesn't have names or…

Benjamin Young: descriptions for the render methods which then pushes all
the internationalization work out to the remote file or the template file
however you got it.

Manu Sporny: Mhm. Yep.

Benjamin Young: So we may need a way to, have something like HTML laying
for the template itself where you're saying what's in here is for this
language group. But again, I don't think we need to solve it necessarily.

Manu Sporny: Yeah. Yeah. I mean the other thing I was thinking is your
viewing environment also has language information like your browser will
have a default language that it's expecting.

Manu Sporny: And in the browser environment we could maybe depend on that
even though even that is a little dicey, I agree with you Benjamin. I think
we're going to have to start tagging render methods with this is for
Spanish rendering and…

Manu Sporny: this one's for an English rendering. so maybe just
localization. Yeah, we'd probably need to ask the internationalization
folks like, okay, how should we localize this? Mhm. Mhm.

Benjamin Young: Yeah. Yeah.

Benjamin Young: It gets really tangled because the browsers can but don't
often support servers can, but then if you're negotiating on one of these
templates on a language, you're not going to get anything back that matches
any hash. So, you essentially can't negotiate on that URL if you're going
to get it to match a hash, which then means you're going to end up with a
buffet of the same thing in different languages. Yep.

Manu Sporny: Yeah. Yeah. It's a hard problem. So, I'm suggesting we punt
this to the working group because they're not going to be able to go to
wreck without solving it. it'll come up and I don't think we are the right
group to have that in-depth discussion. unless we, invite the
internationalization community in here and it's just that we're talking
months. It takes months to have those discussions. So, I'd rather we have
that discussion happen in the BCWG in an official capacity. that's that
item. and real quick, I know we're at time. support functional operations.
yes, absolutely. I think we need to do this.
00:55:00

Manu Sporny: and I think we should have a proposal here. So, maybe during
the next call or whichever next one you can make. I'm going to have to
cancel the meeting for next week. I forgot I won't be here, but maybe the
week after that. we can talk about what functions look like and if we are
probably going to have to define some base functions in mustache to do
this. but that's fine. I think we were all expecting to have to do that. So
we'll talk about that. All right. So we have one issue that we need to
absolutely make sure that we cover and that's issue 22 support for
functional operations.

Manu Sporny: We also want to have a discussion with Dimmitri and Paul from
GS1 about their multi- credential rendering and list and card view
rendering suggestions and that's it. I mean once we have those discussions
and hopefully get through them then we think render methods ready to go as
well. So right now we've got what's ready to go. VC barcodes is ready to go
very soon. Render methods going to be ready to go and then trailing behind
them is PC API and the postquantum stuff which is happening in parallel and
then the verified issuer verifier list stuff. go ahead coyote.

Kayode Ezike: Yeah, really quickly. I don't think we made a comment on the
first one. I think it was from Pat. Might be worth tagging him on that as
well to he can respond.

Manu Sporny: Yes thank you.

Manu Sporny: I will do that after the call. Definitely. I've got it open.
thank you everyone. really appreciate the call today. we will not have a
call next week. but we'll start up the following week. it will be at the
same time. We won't try and move around this meeting because clearly it did
not work out this time. thank Have a wonderful rest of your week and we
will chat again in two weeks. Take care. Bye.
Meeting ended after 00:57:26 👋

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