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

+1 Leonard - we have no issues with this at a pretty large scale on our
side.

On Wed, Apr 16, 2025, 20:45 Leonard Rosenthol <lrosenth@adobe.com> wrote:

> There seems to be some misinformation, or at least some misunderstandings,
> here around PDF and how it can be used as part of the `render` piece for a
> VC.  If I read this correctly, someone is implying that you can’t do
> variable substitution with PDF – and that is certainly not true. You need
> properly prepared PDFs and good quality PDF libraries – just as do with any
> other format(s) you wish to work with – but it should all be doable.
>
>
>
> Happy to discuss here in email or I can try to attend a future meeting
> with this as the topic.  (or both)
>
>
>
> Leonard
>
>
>
> *From: *meetings@w3c-ccg.org <meetings@w3c-ccg.org>
> *Date: *Wednesday, April 16, 2025 at 6:07 PM
> *To: *public-credentials@w3.org <public-credentials@w3.org>
> *Subject: *[MINUTES] CCG Incubation and Promotion 2025-04-16
>
> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>
>
> 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.*
>