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

CCG Incubation and Promotion Meeting Summary - April 16, 2025

*Topics Covered:*

   - *Report Out from Internet Identity Workshop (IIW40):* Discussion of
   issues raised regarding internationalization, handling compound
   credentials, specifying credential views in render methods, applying logic
   to fields for human-readable output, and iterating through credential
   arrays in templates.
   - *Promotion of Specifications to VCWG:* Focus on the readiness of
   several specifications for transition to the Verifiable Credentials Working
   Group (VCWG), including the Verifiable Credential API, Render Method,
   Confidence Method, Post-quantum secure data integrity crypto suites, and
   the Trusted Issuers Verifiers List. The ZCAP spec was also briefly
   discussed, with uncertainty regarding its appropriate working group.
   - *Render Method Pull Request 17:* The majority of the meeting focused
   on this pull request, aiming to improve the render-method specification
   based on a year of field experience. Key changes include:
      - *Templated Render Method:* Shifting from a solely SVG-based
      approach to a more flexible templating system using Mustache,
allowing for
      various output formats (PDF, text, etc.).
      - *Render Suites:* Introducing render suites similar to crypto
      suites, providing a structured approach to define different rendering
      processes and their associated media types and security considerations.
      - *Media Type Handling:* Extensive discussion regarding the handling
      of media types (e.g., SVG, HTML, PDF), emphasizing the importance of
      security and privacy by preventing network access and scripting within
      rendering processes to avoid tracking and correlation attacks.
      - *Render Property:* Debate over the render property (a list of
      fields to be rendered), with a push towards making it explicit and
      potentially using it for selective disclosure. Concerns were raised about
      issuer trustworthiness and the need for wallets to independently verify
      rendered data. The possibility of using objects instead of strings to
      provide more metadata about fields was raised.
      - *Offline Flag:* Suggestion to add a flag indicating
      offline-friendliness to ensure privacy and prevent network-based
tracking.
      - *ID Property:* Confusion around the use of JSON-LD IRI IDs was
      noted, along with a potential need for clearer documentation or
alternative
      mechanisms. However, consensus was to stay the course for now.

*Key Points:*

   - The render-method specification is being significantly revised to
   improve flexibility and address security and privacy concerns.
   - Render suites are introduced to provide a standardized and secure way
   to define different rendering processes.
   - The use of media types requires careful consideration to mitigate
   tracking and correlation attacks.
   - The render property should be designed to enforce explicitness about
   the data used in rendering and potentially enable selective disclosure.
   - Tooling and linting are crucial to help developers build more
   privacy-preserving credentials.
   - Further discussion is needed on several aspects, including the precise
   format of the render property, function handling in templates, and ID
   property clarity. The meeting will continue next week to address these
   remaining points.

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

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

Alex Higuera, Benjamin Young, David C, Dmitri Zagidulin, Hiroyuki Sano,
John's Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt, Phillip Long
*Transcript*

Manu Sporny: All right, let's go ahead and get started. let me go ahead and
share our agenda for today. welcome everyone. this is the April 16th
credentials community group call on items that have been incubated for a
while and we're getting ready to promote to the verifiable credentials
working group. today on the agenda we are going to try to focus on render
method specifically there is a new pull request 17 to add a template render
method type and a render suite approach to render methods.

Manu Sporny: this is after about a year of kind of field experience
implementing what was in the spec. we found it lacking in a variety of
different areas. and with addition of work that MIT dcc's done and a couple
of other folks in the ecosystem have done we've tried to kind of take those
learnings and unify it into this pull request. So this is expected to be
the one fairly major change to render method before we hand it off to the
verifiable credential working group. so we'll be spending the vast majority
of the call talking about that today. we can also cover anything that is of
relevance from the internet identity workshop.
00:05:00

Manu Sporny: anything relevant to any of the specs that we are planning to
promote. That includes verifiable credential API, render method, confidence
method in any of the postquantum data integrity cryptography suites. those
are the major work items we're thinking of promoting to the VCWG. so we can
cover anything from IW that happened there. okay, I think that's it for the
agenda. Are there any changes or updates that anyone would like to make to
the agenda? All right.

Manu Sporny: If there are no changes or updates, is there anyone new to the
call today that would like to introduce themselves? All right. If not,
let's go ahead and jump into our first agenda item which is a report out
from the internet identity workshop IIW40 which happened last week. is
there anything relevant that happened at IIW related to any of the work
items that we're planning to transition to the verifiable credential
working group?

Manu Sporny: Again that's VC barcodes, VC API, render method, confidence
method, postquantum secure data integrity, crypto suites, BBS pseudonyms,
any of that. and of course the trusted issuers verifiers list. go ahead,
David, please.

David C: I don't need to now because you just said, " yes." And Okay.

Manu Sporny: Yes, my apologies.

David C: Yes. My

Manu Sporny: I'm having a hard time keeping all of the specs in my head.
There are a lot of them. I were planning to transition, but yes, of course.
as well, Coyote, please. You might be double muted.

Manu Sporny: Still no audio from you. Unfortunately, I think your audio is
not working for some reason. I can't hear All right. we'll take your
comment when you rejoin. And we'll just hold for a second until Cody
rejoins and maybe he'll have his audio things fixed.

Manu Sporny: While we wait, anything else that happened at IW that folks
feel are relevant to the conversation. I will I guess point out that one of
the things that came up on the main CCG call was the Zcap spec, which we
have not touched in a long while. it is something that could potentially be
incubated and moved to and there and there's a big question mark Dimmitri
we're just talking about kind of the ZCAP spec and where the incubation and
promotion would go to VCWG does not seem like the right place but it's kind
of like a big question mark on what would be the right place this came
about as a kind of recap

Dmitri Zagidulin: Makes sense.

Manu Sporny: IW40. …

Dmitri Zagidulin: Makes sense. I think if I can just add a comment.

Manu Sporny: please. …

Dmitri Zagidulin: I think if all else fails, diff would be happy to
incubate CC Zcaps. Yeah.
00:10:00

Manu Sporny: it's not the incubation. It's the standardization. where would
we, send it? meaning what's the official working group that would take it?
I think one of the things I've been trying to figure out at least from a
W3C charter standpoint is that there's a chunk of stuff that's happened in
the BCWG specifically around data integrity that probably belongs in its
own working group around security and data integrity and that kind of stuff
and that if we had a working group like that that would be a kind of ideal
landing place so

Manu Sporny: that working group would take over the data integrity work all
the crypto suites in pull in ZCAPS potentially a future EDV thing…

Manu Sporny: although that would probably be a stretch for that group there
is a security interest group that's been chartered and…

Dmitri Zagidulin: Got it.

Dmitri Zagidulin: And isn't there a straight up security group that was
being chartered? not working.

Manu Sporny: they exist but they're not items…

Manu Sporny: but They're not supposed to work on technology for whatever
reason.

Manu Sporny: I don't know why that decision was made,…

Dmitri Zagidulin: Got it.

Dmitri Zagidulin: And last question about Zcaps.

Manu Sporny: but I would have some deep reservations about doing that given
the votes against a lot of the stuff that we've tried to take

Dmitri Zagidulin: Would it be at all plausible or feasible interest from
this crowd to possibly take it to the idea? understood.

Manu Sporny: there. I mean, multibase, multiash, all of those were shut
down,…

Dmitri Zagidulin: Yeah.

Manu Sporny: I'd want to put it somewhere that had a friendly atmosphere
and,…

Dmitri Zagidulin: right.

Manu Sporny: could survive. yeah, I mean, a lot of the technologies we've
tried to move to ITF just got shut down by …

Dmitri Zagidulin: Got it. Understood.

Manu Sporny: that's so I think though the thoughts there is, we'll continue
to incubate the ZCAP stuff. and then we can figure out where it goes later
and we can always recharter some of these working groups it's not a hard no
from the VC working group.

Manu Sporny: It's just kind of like and maybe there's an argument there for
it to go there because that's where a lot of the people that worked on
Zcaps are and there's strong feelings about VCs are not ZCAPS and there
needs to be a separation between them and that sort of thing. go ahead
Coyote. Yes.

Kayode Ezike: Yeah. No, this is just my audio works now, Okay, great. Yeah,
sorry about that. So, you had asked about whether or not we had touched on
any of these at IW and the answer is So, I just wanted to say that Dimmitri
and I led a discussion about it. These are the issues. I think there's four
of them there that came out of it. some of them around
internationalization, handling compound credentials like CLR2 and linked L
RS and then other things like for example being able to specify what the
item view of a credential is and not just the detail view in a render
method. So a number of interesting conversations came out of that.

Kayode Ezike: There are some other others too that I thought about since
then that I wanted to add on I haven't gotten a chance to yet. But for
example around being able to actually apply logic to certain fields and…

Manu Sporny: Mhm.

Kayode Ezike: not just being able to reference them. For example for date
fields ideally you don't just show a degree and if a degree has a diploma
has a date it wouldn't just be like the ISO 601 value would actually be
something more human readable. So things like that and then being able to
actually do basically iterate through an array of credentials and have
templates for them that you can have inline in a template that are
referenced by an ID that's inside the template that I'll probably spec out
some of these in an issue…

Kayode Ezike: but these are some of the things that I've also been kind of
contending with as well.

Manu Sporny: That's awesome.

Manu Sporny: That's fantastic. Yeah, I totally missed that these new issues
were raised, but yeah, that's great. and yes, please Coyote add those other
issues so that we can kind of process them with the spec. and we'll go over
these later on today if we can get to them, but they all are good solid
asks and we can discuss as we do. Okay.
00:15:00

Manu Sporny: anything else from IIW that we should cover related to the
work that we're incubating to promotion. All right. if not then we will
jump into the main topic of today. I thought the way that we could go about
this is to just look at the PR in the spec as it go through it, kind of
explain what we're doing here and and then we can go into questions that
people have. Clearly, just ask questions as we go, so if you raise comments
or whatever, please fit it into the conversation where you think it's
appropriate just via hand raise.

Manu Sporny: The other request I have is that if you do have a change or
modification or something like that, please raise it on the pull request so
that we can make sure that we capture all of the changes that people are
requesting. So here's the links in the chat channel. please go there, add
your comments if there's something that you want to have covered.

Manu Sporny: With that, let's go ahead and jump into it. let's start off
with an example. so as a reminder to folks, what was in the spec or what
still is in the spec is this SVG render method example. And what we have
heard over, we've implemented it and what we've heard over the last year
was, sure, okay, SVGs, but what about PDFs? Those are way more

Manu Sporny: prevalent in the ecosystem. What are we doing for that? and
what are we doing for the other types of rendering? So render method is
very broad in what it means. Meaning we render to the electromagnetic
spectrum which includes visible light like a QR code. It includes near
field wireless like NFC and Bluetooth.

Manu Sporny: and includes again human interpretable optical pictures right
including other things we're also talking with accessibility folks on
braille and audio and stuff like that so when we say render it in a very
broad sense but the biggest thing that people have asked for is I as an
issuer want to at least provide the way I would like the credential to be
rendered in a variety of different form factors. So primarily this is the
issuer going if you're going to render this in a variety of different ways.
I have opinions about how I think it be It is however totally up to the
wallet and how the holder has configured their wallet to do the rendering.
Same thing with the verifier.

Manu Sporny: So this is all based on what the entity that's looking at the
render method, wants to do with it. So, we used to have just a pure SVG
thing. That didn't cut it. people wanted a different approach. So, we've
gone through and refactored it with this PR. So, what we have now is we
still have the render method property. So this is just a bog standard
verifiable credential. and it's got this property in here. we do have an
extra context for render method because it didn't get into v2. there's some
extra properties we need. So we need this extra context up here.

Manu Sporny: And then down in the main kind of type of render method that
we're proposing is a templated based render method. So it's largely a
textbased template where it uses mustache is a template language where you
put double curly braces. So the name mustache comes from the curly brace.
You rotate it 90° and it looks like a mustache. That's why it's named that.
and so you put double curly braces around variables and the variables come
from the verifiable credential.

Manu Sporny: So this would be double curly brace valid from right would
fill this in directly and as coyote mentioned that's kind of ugly and we
don't want to expose that to a human being that doesn't know what ISO the
XML datetime format looks and this is not in the spec right now but we can
have functions in the mustache templates that execute and would form that
this into a nice human readable datetime that is in their current local and
so on so forth because not everyone writes dates in the same way in
different societies.
00:20:00

Manu Sporny: the US does it differently from other places and even within
those individual states it can be done differently as okay so this render
suite so sorry so the high level thing is a template render method and
we're adding render suites that are somewhat equivalent to crypto suites
like we do for the data integrity proofs. These ones would provide a render
suite so that you can do an SVG mustache-based template thing or you can do
a text file mustachebased template thing or you could do a PDFbased one.

Manu Sporny: and we could also potentially do binary templated syntaxes
here as well. That's very experimental. I don't think we're going to do it
the first go out. But the idea here is the render suite gives you a lot
more flexibility and we only need to support one kind of type for most of
the use cases, certainly not all. Demetri, you're on the queue, please.

Dmitri Zagidulin: Two questions comments on that. one is about both in
media type property and in the file extension in the ID. I was going to say
I wonder if it make more sense but no it's more like we've got two sort of
competing things to denote. One is the end result after the templating
which is the SVG but before the templating might we also need to use the
mustache specific file extension…

Dmitri Zagidulin: which in our case we used handlebars so it's HBS do you
know what I mean right the type of the template is not the same as the
media type of the end result and…

Manu Sporny: Yeah. Interesting.

Manu Sporny: Mhm. Yeah.

Dmitri Zagidulin: so I'm wondering if there's some way we can denote
similarly to your earlier question you mentioned people are wondering about
PDF but the thing about PDF is that it is that or at least the only way
we've been able to do it sort of consistently at dcc is to start with SVG
or HTML and pass it to a PDF printer library and it converts it there so
I'm wondering if there's some way

Dmitri Zagidulin: to denote it that the initial template is handlebars/html
for use with the intended use of creating PDF and it might be just as
simple as a description comment string like this is a template converting
HTML to P

Dmitri Zagidulin: but I just wanted to raise it up right it's not clear how
to denote to consumers to developers really that hey Although this is an
HTML template, we're really using it to do PDF. And also this notion of the
template format versus media type of the end format.

Manu Sporny: Yeah, excellent point.

Manu Sporny: How would that change this? so what you're saying is that the
media type here would really be a handlebars media type.

Dmitri Zagidulin: Yeah. Yeah. whatever the mustache media type is.

Manu Sporny: Mhm. And…

Dmitri Zagidulin: Or maybe we should just straight up have two different
properties,…

Manu Sporny: then Yeah.

Dmitri Zagidulin: right? Templify output media type or

Manu Sporny: And we did discuss that a bit that here's where things we
started getting in trouble, right?

Manu Sporny: when you needed to look at multiple different media types or
multiple different properties to do something in the crypto suite stuff, we
ended up in a variety of dangerous situations. that is the kind of the same
approach that JWTs can take the cording of multiple properties was an
anti-attern that we didn't want to do. So we wanted to make sure that when
you looked at the render suite,…
00:25:00

Dmitri Zagidulin: Got it.

Manu Sporny: you knew exactly what you needed as input and you knew exactly…

Dmitri Zagidulin: Got it.

Manu Sporny: what was going to be the output and all of it lived here.
Meaning that what you look at one field and everything that's going to be
an input and everything that's going to be an output.

Manu Sporny: And it's kind of like these things are secondary to the render
suite.

Manu Sporny: So the render suite is the thing that provides kind of the
security guarantees around…

Dmitri Zagidulin: Got it.

Dmitri Zagidulin: Got it.

Manu Sporny: what you're doing or at least limits what you're doing. and
this gets into kind of the security and privacy considerations. what we
didn't want is the ability to make decisions based off of media types that
were either server provided

Manu Sporny: because that could lead to different types of attacks
correlation attacks like HTML is a good example of that. that doesn't mean
we don't do it.

Dmitri Zagidulin: Understood.

Dmitri Zagidulin: Got it. No,…

Manu Sporny: I'm just noting where kind of some of the concern came from
with Mhm.

Dmitri Zagidulin: No, you know what? you're right about the render suite
that is the primary thing to look at. So while there's still a question
about what file extension to put on the template, I agree with you that we
don't need an input and output media type that is contained in the media
suite in the render suite, sorry.

Manu Sporny: Yeah. so I Don't drop it yet, Demetri. I think we need to
really analyze it. But I think that's why we were leaning towards render
suite is the source of truth and then everything else must match up. This
media type is for a different purpose. it's basically the issuer going you
need to fetch this and if you don't get a media type of image SVG throw an
error, right?

Manu Sporny: because that means that someone's tried to intercept this or
they've modified the media type and they've put an in HTML file in place,
if that makes sense. so yeah, Demetri, I think that's a really good concern.

Manu Sporny: We should discuss it at depth to make sure that we are making
the right decision all next up, Benjamin.

Benjamin Young: Yeah, sure.

Benjamin Young: Just kind of picking up from Dimmitri. there's a use case
for SVG where that ultimate rendered output would be like a PNG or
something. so I like Demetri, I'm wondering around render suite and whether
or not what else needs to go in there if anything. because as far as
mustache is concerned and handlebars has a registered media type, mustache
doesn't, but that's kind of fine because u you can use mustache on SVG
file, basically any text file.

Benjamin Young: you can feed through a mustache template engine. So, it
doesn't need its own media type per se, but we do need to know that
whatever text thing we're getting back or feeding into the mustache
renderer, we should assume contains mustache holes and we're going to fill
those in. but I'm not sure that at what point does the rendering system
need to know that when is SVG meaning going to be valuable to the thing
running the text file through the template and then doing something on the
output.

Benjamin Young: and that may be idiosyncratic. If the system knows it got
an image SVG file in, ran it through mustache, then maybe the wallet
decides is it going to render it as a PNG, is it going to turn it into a
PDF, is it going to display the raw SPG content, etc. those are my thoughts
at the moment. Thanks.

Manu Sporny: Yeah, plus one to that. Yeah, good thoughts.

David C: Yeah, I mean given that you said that the render suite property is
the primary determinating factor of the code that's going to process all
this. then I just wondered why do you just make it the type? So the type is
the SVG mustache because what do you gain by having a type of a template
render method and then the next parameter completely differentiates between
all the different ones? cuz you may find you've got some non-ommonality
anyway and maybe you don't even need the template object then if you get
rid of the template render method and just call the type the render suite
the SVG mustache right right on.
00:30:00

Manu Sporny: Yes. Right. Yeah. Yeah. Under understood. let's see. I put
myself on the queue to respond to Benjamin your point and David's, but I'll
do them in the opposite order. so the reason we have a single type here is
the same kind of reason that we have a single type for data integrity
proof. if we wanted to add a new type in the future between verifiable
credential version two let's say 2.1 in version 3 and 31 and 40 we would
have to keep adding new types and new variations and we didn't want to
centralize the development of new render suites to the verifiable

Manu Sporny: credential working group. We wanted to make sure that this is
effectively a text field in any and that allows for decentralized
innovation so that they wouldn't have to come and centralize the types at
the verifiable credential working group because the verifiable credential
working group is the one that has authority over this thing. So it's very
much we could do what you're saying David and that is where we started out
with cryptography suites but we learned very quickly that it's centralized
the development of cryptography suites at W3C to the working group and we
felt that that was bad for the ecosystem. so that's why we use just a very
general name here.

Manu Sporny: we have a sweet property and then have fairly open a string
here that you can do decentralized innovation on.

Manu Sporny: Did that make sense David? Sure.

David C: Can I respond to that?

David C: Can I respond to that? Because if you got fully decentralized and
you've just got a string there, then you're going to get string clashes.
somebody in China is going to, maybe have the same string as someone in
Chile. and then when you process it in Luxembourg, you won't know whether
it's the Chinese string or the Chilean string because it's the same string
because there's no control over what the string can be. there is an
expectation that there's going to be a registry that people can register
these things in…

Manu Sporny: There is an expectation that there's going to be a registry
that people can register these things in but it's optional right anytime
you go to fully decentralized systems there's always the risk of potential
clashes and…

David C: but it's optional right anytime you go to fully decentralized
systems there's always the risk of potential clashes and…

Manu Sporny: names like this…

David C: names like this…

Manu Sporny: but we sorry David I'm getting a lot of feedback from your
audio thanks there's always the possibility of name clashes.

David C: but we sorry David I'm getting a lot of feedback from your

Manu Sporny: When you go fully decentralized, we provide an optional
registry for people that want to avoid those name clashes. and the same
thing's true for the cryptography suites, I mean, someone could choose the
same cryptography suite name. but we don't expect that to happen.

Manu Sporny: especially with render method cuz we're not expecting there to
be even above 10 is probably not going to happen but even if it does go
above 10 managing 10 to 20 strings globally is probably not that big of an
issue. did that make sense David? I mean I think we're saying yes we know
that there's a possible

David C: are saying, "Yes, we know that you could use URIs.

Manu Sporny: Yep.

David C: You could just say there URIs there and then you've solved that.

Manu Sporny: So, I mean, if folks want to use URIs, they can use URIs. I
don't know if we'd necessarily suggest that, Because we're kind of
standardizing things, but in any case, let's put this down as, one thing
that we can kind of discuss. Should this be a URI or should it be a string?
we can raise that as an issue. okay.

Manu Sporny: Benjamin, I unfortunately forgot the comment I was going to
mention with you. yes yeah yeah yeah.

Benjamin Young: We were talking about input and…

Benjamin Young: output media types, I think, and the lack of input media
types.
00:35:00

Manu Sporny: so the media type so yes I mean a plus one to what you said
this should be good enough for most of it we do have a media type here it's
debatable on how useful it is there is a concern about just leaving this
open it could be anything it might be a SVG that's served as text HTML and
there's an attack where if you do that a different rendering engine is
picked in if you pick a different rendering engine your correlatability
charact characteristics change dramatically. So for example for SVG I think
in the spec we would insist that you cannot go out to the network. So
there's a type of SVG processing where it's purely local.

Manu Sporny: You absolutely cannot go out to the network and fetch images
and other things like that. it's completely self-contained. You can't run
scripts. you can't go out to the network and fetch extra items. you can't
do animations. there's all this stuff. There's a simplified version of SVG.
So I think we'd say you have to use that version because if you don't use
that version then issuers can put tracking tokens in the SVG files so that
whenever anybody renders it they can track the person either as it's being
rendered in the wallet so you can figure out when people are using their
credentials or when it's used at the verifier you can figure out what
verifiers are receiving what credentials from what specific individuals.

Manu Sporny: so that's important, right? I mean, with HTML, we might say if
you're going to take HTML and generate a PDF from it, you have to do it in
a sandboxed environment where there's no network traffic. that's allowed.
and if you detect network traffic, you should just immediately break the
rendering. be very aggressive about shutting down correlatability. yeah,
Coyote, I think it also means no linked images. again, this goes into our
security privacy characteristics. I think we'd have to have a very in-depth
discussion about this.

Manu Sporny: but if you think about you've got this BBS credential it's
unlinkable and you have all these nice properties and then you've got a
HTML rendering mechanism in there to just completely destroys the
cryptography and makes it fully linkable because you're tracking images
which we know people are going to want to do right to track where these
things are being used. So, I think we do need to be careful about, these
rendering subsystems and what they're allowed to do and what we say, should
be done and how people are going to get the implementation wrong anyway,
And all and go out to the network anyway. go ahead, Benjamin.

Benjamin Young: Yeah, relatedly that template ID value could be unique to
the credential or…

Manu Sporny: Yeah. Mhm.

Benjamin Young: made to be unique or contain a query string that's unique
and guarding against that is nearly impossible. which is why in
experimentations last year, and there's still, I think, one on the VC
playground, we stuffed the entire thing, including the photo of the person
into the credential, which ends up, with a five meg credential or
something. so there's a weird tension between how to ship a generic truly
templated contains no

Benjamin Young: no PII or identifying anything in it. and then how do you
assure that from the credential side and I don't know that you can

Manu Sporny: Less one to that.

Manu Sporny: There are some strategies that we've talked about in the past
for example and again this is dangerous but wallet systems keeping track
having a public registry of images and links that are in credentials and
seeing how many other credentials out there refer to images that you link
to.

Manu Sporny: And if the number is below five then you are holding a
tracking credential meaning you can take this value hash it and you can see
how unique it is and you can be in a kind of a public registry. so that at
least your wallet or other wallets even if they're not big wallets at scale
can know you've got tracking data in your credential right as an example.
I'm not saying that's well thought through or anything like that, but
they're ways of potentially trying to provide signals to individuals. go
ahead, Dimmitri.
00:40:00

Dmitri Zagidulin: So I'm wondering if the other thing I was going to bring
up may help this which is I wonder if it makes sense to add a property for
this is offline friendly or not right and if we have an offline flag…

Manu Sporny: Mhm. Yep.

Dmitri Zagidulin: then we can say okay lock it down to make network tracks
etc etc right that's thought one. And the other one that I wanted to
mention before I forget, I wanted to mention about the ID property. I've
heard from several people including the guy from GS1 at IW. he was looking
at the template. He's like, "Where's the URL?" I'm like, it's this weird
JSON LDSM that IDs are URLs." He's like, " that is not intuitive at all."
And I've seen other developers hit up against this as well.

Dmitri Zagidulin: So, I just wanted to flag it that it is a source of
confusion. Not sure…

Manu Sporny: Mhm. Yep.

Dmitri Zagidulin: if we want to add a template URL field, but the ID thing
is confusing

Manu Sporny: Noted. I mean, we can have a discussion about that.

Manu Sporny: I mean, Demetri, as you know, we had a very long discussion
about that in the VC working group,…

Manu Sporny: and this is where we landed. And it's like, okay, are we going
back and revisiting that conversation, or this is just the way you do it in
go ahead, Benjamin.

Benjamin Young: Yeah, I'd be in favor of staying the course.

Benjamin Young: I don't know what people think URLs are if not identifiers.
I realize it's not intuitive in language, but they come around.

Dmitri Zagidulin: Locators.

Benjamin Young: Those are the same thing, right? It one's a subset of the
other one. I think it's just an educational failure on the part of browsers
and computer science people. but we should do more to hoist that. I did
want to come back to monetary tracking wallets recording URLs going out.

Benjamin Young: I think developer tools before that would be helpful to
when doing a render method or when rendering anything through one of these
catalog all the requests that are made or forcibly put it through some of
the sandboxed ones or not to just show the developer what's happening. This
is maybe part of the render method test suite in the future. because
Demetri, you mentioned having an offline flag. I think the wallet's going
to need to I mean you could signal to do that, but the wallet should take
the strict depending on the wallet should take the strictest approach for
preserving the privacy of the individual. some wallets will not, right?

Benjamin Young: But some way to surface that to at least developers,…

Benjamin Young: but even the end user to say, you've got credentials that
all have matching content in them. So maybe you're not who you think you
are.

Manu Sporny: Yep. Yeah.

Manu Sporny: Huge plus one. Tooling, linting, all that stuff. I think it
helps people design better credentials, more privacy preserving
credentials, and not accidentally fall into a situation where they have,
this credential that they're starting to issue and then they find out after
they've issued the first 15,000 of them that none of the wallets are
rendering it because they've been flagged as a tracking beacon, We
definitely don't want that experience. so yeah, huge plus one to that,
Benjamin.

Manu Sporny: okay. We've talked about media type. digest multibase is just
a digest of the file to make sure that it doesn't change. Sometimes you
want that, sometimes t. sometimes you want to update the look and feel of
your credential while it's out there in the wild. And other times you do
not want to do that, Meaning you do not want to change what the credential
you issued looks like. because everyone expects it to look a very specific
way. So something like a driver's license or a permanent resident card once
it's issued people do not expect the entire face of the card to change. the
last one here is render property and these we're still heavily debating the
name for this.
00:45:00

Manu Sporny: This is basically the list of fields that will be taken from
the verifiable credential and passed into the renderer to render the thing.
right now this is an issuer supplied list. And the reason for this is kind
of like a consent privacy thing for the individual. when you render this
thing, we think it might be important for your wallet or something to say,
"Hey, by the way, these fields from this credential are going to go into
this PDF file." And if you're going to take this PDF file and you're going
to send it somewhere, just know that these five fields are in there.
They're going to be in the PDF and when you email it to someone, they're
going to see that information.

Manu Sporny: Sometimes when you render these things like a certificate of
completion or a birth certificate or something like that there is so much
data in there that you don't think twice about printing it out and sending
it to someone but hey by the way this thing includes your social security
number in it or your national ID number or something like that. the
argument against this is what if the issuer lies? we can also have an
argument that hey what the temp the renderer can figure out what properties
are there because there's a whole bunch of mustache templates that are used
and filled out. and then of course the counterargument to that is not for
NFC you have no idea everything's a binary blob so you don't really know.

Manu Sporny: go ahead, Benjamin.

Benjamin Young: Yeah. …

Benjamin Young: I wonder if we could use this render property, especially
with mustache as almost a selective disclosure style thing because mustache
uses a view model. that doesn't obviously need to be fed this list of
render properties or some similar sort of filtered thing could be what is
used to selectively disclose parts of the credential data to create a view
model that then is passed into the mustache template engine.

Benjamin Young: So that's basically you're stating this template needs
these fields and you need to create an object that is just those fields. so
essentially if you don't as the developer list a property in there, you
won't have access to it in your template. So you have to be explicit for
the render suite to even send you the data. You have to state what data you
want from that way it's not a secondary thing you need to remember to
update and it's a nice to have signal or something you have to go out of
your way to do.

Benjamin Young: You're going to have to trip over it to get data into your
rendering system at all. and then those two things are tied more tightly
together.

Manu Sporny: Yep. Absolutely.

Manu Sporny: I think that that was the purpose of this Coyote, you had a
good feedback and in my instinct was the same as yours. So Coyote, maybe
you want to kind of vocalize the counterargument there.

Kayode Ezike: Yeah, I think you covered it. It was basically that right why
should the world decide to trust the issuer on that either it could be out
of a simple oversight that the issuer just didn't remember all the fields
that were exposed and so that's the reason why it wasn't listed or it could
be maliciously hidden and there's not really a way to determine which one
it was but the point is that it is a misguidance to the wallet either way.
And so that's where I felt that for something that seemed to me that could
be deterministically determined from the wallet with the combination of the
credential and a template that it should be I hear there are some cases
where it could be difficult to do that.

Kayode Ezike: But I wonder even for those binary cases, is it still
possible for the wallet to get some of that data anyway and determine with
some processing or is it absolutely no way to get around it for some types
of credentials? I'm see.

Manu Sporny: Yep. Good question.
00:50:00

Manu Sporny: Benjamin, you're up.

Benjamin Young: I think I take the stance that the wallet should be
generally distrusting of render methods even…

Benjamin Young: though they come with the credential that it should be
suspicious. and I think forcing the render method developer to be explicit
about what data they depend on in whatever their render method is. even if
the contents of that template is somehow binary to tell the wallet this is
the stuff I need to render properly and then it's on the wallet to not
overexpose the user and to also accommodate the render method with the
things it asked for. and potentially, it's conceivable that the user might
say, I don't actually want this stuff rendered. So, you could go farther
with it.

Benjamin Young: But I think at minimum if this is a required field that
builds the bridge between the data in the credential and what the render
method needs for the template. then that becomes a forcing function to make
the render method expose what it's doing in an easily parsible and
potentially even selectable way by the wallet on behalf of with the help of
the user. and then the person developing the render method has to do it to
get any data to begin with. because it's a little freaky when you do a
render method now and many of the experience experiments we've done over
the past year what am I going to feed into this thing?

Benjamin Young: I could feed it the whole credential and often you just end
up being like here's the credential because you need valid from which is on
the top and so you can't just relegate yourself to credential subject which
initially feels like all you would need but you want issuer data sometimes
you want all this other stuff so you end up just saying here you go render
method here's the whole credential which then gives them the potential to
expose all kinds of data which it probably shouldn't have access to.

Benjamin Young: So at least here it must be explicit about what it wants.

Manu Sporny: Plus one to that.

Manu Sporny: Demetri, you're You might be muted. Dimmitri

Dmitri Zagidulin: Whoops. I wonder if it makes sense for us instead of an
array of strings to do an array of objects, and that's a constant heristic
whenever you see an array of strings, always pause and ask this should
probably be array of objects. But the reason I bring it up is to our
earlier comment about processing functions, You could easily see instead of
just field identifiers set of tupils such as valid from comma pass it to
this date formatting function right so what I'm going to saying is we may
want to leave ourselves room to add additional metadata to the field
identifiers so objects not strings

Manu Sporny: That's an interesting point. I think so the other proposal
here was to because Mustache has the ability to talk about functions that
you expose that would do the kinds of transformations that Coyote was
mentioning and…

Dmitri Zagidulin: I see.

Manu Sporny: we were and if we had that then we could still do strings but
I think your point still stands which is like what if we want to do
something else we're stuck with strings

Manu Sporny: Or we could say strings and…

Manu Sporny: objects where the object kind of future proofs us from
mistakes we made,…

Dmitri Zagidulin: Yeah. Yeah.

Manu Sporny: the first. go ahead, Benjamin.

Benjamin Young: Yeah. …

Benjamin Young: mustache functions are useful for string formatting mostly
and almost exclusively. they can't really look around the data object. they
can only take in what's currently in that context of that processing
moment. but where objects in render property could be useful is signaling
that you have a date for example that you need to run that function on.
because I think with this render method related to mustache, the question
are we going to provide a set of fixed functions that wallets have to or
that the render method has to implement or plan to implement to be
compliant with rendering it that are certain date formats or whatever. or
are we going to make it more broadly extensible?
00:55:00

Benjamin Young: But the object format could be useful there for at least
signaling that this is a date or I wanted it to be treated that way because
you can hard to explain but in mustache the function is It's just another
property really that's prepopulated inside the view model. so who does that
and…

Benjamin Young: when they do it and whether that's in the spec or not is
related to what other handles we might want in render property.

Manu Sporny: Yep. yes,…

Manu Sporny: all good points. yeah, if we're going to do functions, we
would almost certainly have to define it in the specification. The step
after that is to quite literally make the object take a function like a
JavaScript function that's executed at runtime which is probably a bridge
too far.

Manu Sporny: there is another argument that hey if you want all that kind
of flexibility use an HTML file and dump scripts into that HTML file and
you can do all the processing you want to using JavaScript but then of
course it's like beware the correlatability characteristics of things like
that and the ability to run arbitrary endless loops that eat

Manu Sporny: CPU cycles and that sort of thing. but those are decisions I
think we're going to have to have to make eventually here. noting the time,
we are out of time but thank you very much for the wonderful discussion
today. I think we got a lot of stuff out on the table. I'm hoping some
folks were able to write some of that down. I certainly was not if there is
one of those items that you really want to make sure sticks around and is
applied to the R, please write it down or raise an issue. a lot of the
things we discussed seemed like issues that need more detailed
conversation. We didn't get through all of it. there's this SVG Mustache
render suite.

Manu Sporny: here we have different types of expressions that we can use
where you can put the template inline. You can link to a template and
provide a digest multibbase. or you can even put the entirety of the render
method on a remote resource. That's possible too. so we need to cover those
items. And then we didn't touch on the NFC render suite either. so we'll
come back next week and discuss those items. In the meantime, please do
take a look at pull request 17. Provide any feedback that you would like on
that. after we give it, another week or so, we will probably merge it down
unless there's some standing objections to any particular part of it.

Manu Sporny: And then again remember we're not trying to get it perfect.
We're just trying to get it good enough so that when it goes into the
verifiable credential working group people have a good kind of
understanding of what we were going for here. And of course many of us are
going to show up in the verifiable credential working group to continue
work on it.

Manu Sporny: Yes exactly right. same time I have made that request a while
ago.

Dmitri Zagidulin: Are we going to have same time next week?

Dmitri Zagidulin: Any chance we can add it to the CCG calendar? got it.
Okay, I'll poke Harrison.

Manu Sporny: Okay.

Dmitri Zagidulin:

Dmitri Zagidulin: Yeah, got it. Thanks.

Manu Sporny: Thanks. yeah, there are a number of meetings like this that
are still not on the CCG calendar and I think they're having some technical
difficulties getting it updated. thanks everyone. Have a wonderful rest of
your day and we will meet again next week. Take care. Bye.
Meeting ended after 00:59:18 👋

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