Add rendering property to VC Data Model

[msporny]

This PR addresses issue #928 by adding a render property to the VC Data Model. The feature is marked "at risk" in the spec. It attempts to specify a simple, but concrete solution using:

1. Simple handlebars syntax, like so: {{VARIABLE}}.
2. JSON Pointer (simple 6 page spec with many implementations).
3. SVG as the image format.

I expect this feature to generate discussion, so we will need more than the 7 day window to discuss... I'll set it at 30 days and see if we can come to consensus by that point.

This PR is based off of work done at Rebooting the Web of Trust:

• https://youtu.be/YhZAaFExOwM?t=6192
• https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/rendering-verifiable-credentials.md
• https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/rendering-vcs-snapshot-9-27-22.md

---

Preview | Diff

[Sakurann]

Explanation talks about "visual, auditory, or haptic mechanism", but the text mainly defines "SvgRenderingTemplate2023" and the Algorithm.

I think we should with "visual mechanisms", but there is more needed "to include rich imagery of their corporate logo and specific placement of employee information in specific areas of the badge" than an SVG image - color for the background, color for the text, passing issuer logo via URL, etc.

[TallTed]

(( )) would be double parentheses.

{{ }} are double braces.

[iherman]

I am worried to get sidetracked into some complicated specificationndiscussion about templates like the SVG templates in the PR. Wouldn't it be better leave that open, or refer to some existing template languages like Mustache?

[iherman]

I would pause, from a vocabulary point of view, on the usage of the type property.

type has a very well specified meaning in JSON-LD, more exactly in the underlying RDF. It means an instance (with the id) that belongs to a specific class. To make this properly, we would have to properly specify the class in the vocabulary, and add a term for each instance ("individual") into the vocabulary. All this bloats the vocabulary significantly (it already does) for no good reason; as far as I can see the only role of SvgRenderingTemplate2023 is to identify a specific kind of template without any extra ontological beahviour. Ie, the term type is used in its purely English way and not as a formal classification mechanism.

Can we simplify our life and use a different term here referring to simply some list (should I use the term 'registry'?) template categorizations?

---

This is a pattern that we use elsewhere in our vocabularies which indeed bloats the formal part, so this may become a discussion on its own right in re-thinking the way we express things in general...

[decentralgabe]

I am worried that this is not the right layer to add rendering concerns in. Would it open the door for similar rendering for a presentation, etc?

I'm not supportive or objecting just yet, just contemplating what the right place for this is. I think a separate rendering spec that can be layered in would make more sense.

[OR13]

... its ok, its non normative right?

[msporny]

I don't understand the question. Are you saying "This is ok for now?" or are you asking "Is this a non-normative statement?" -- if so, no, it's a normative statement. Also note the issue marker (below) stating that this is a discussion to be had about the data format.

Please clarify what you're asking here so we can address your question.

[OR13]

If we are going to define this, we better start with boring sha256 hashes like what you get from this:

curl https://raw.githubusercontent.com/Gowee/nyancat-svg/main/nyancat.svg --output some.file

openssl dgst -sha256 some.file

Huge -1 to starting with "digestMultibase".

[msporny]

@Sakurann wrote:

Explanation talks about "visual, auditory, or haptic mechanism", but the text mainly defines "SvgRenderingTemplate2023" and the Algorithm.

Yes, the text attempts to point out that visual expressions aren't the only ones that can be expressed using this mechanism. If we ONLY provide visual rendering, I expect the feature to fail Accessibility review because we are not providing for renderings that meet the needs of sight impaired individuals.

This might mean that we need to also provide at least an audio-based rendering mechanism as well.

The SVG rendering template is a concrete placeholder due to the WG's current desire to specify at least one example of a concrete implementation that uses the extension point. We /could/ replace this with an image and still meet that goal (though we'd lose the visual template functionality).

I think we should with "visual mechanisms", but there is more needed "to include rich imagery of their corporate logo and specific placement of employee information in specific areas of the badge" than an SVG image - color for the background, color for the text, passing issuer logo via URL, etc.

AFAIK, you can do all of the things you listed using an SVG image. That said, the template is a starting point. Improvements we could make include:

1. Separate the specification out to a separate specification. We want to support multiple specs, so that's probably the best path forward. I know that @decentralgabe noted that desire.
2. Add an additional rendering type for setting the things you listed above, but letting the wallet decide the rest?

Based on the above, what concrete changes would you like to see to this PR, @Sakurann?

[msporny]

@decentralgabe wrote:

I am worried that this is not the right layer to add rendering concerns in.

What layer would be the right layer to capture how an issuer would like a credential to be rendered?

Would it open the door for similar rendering for a presentation, etc?

I don't think this is meant for presentations (at this point, anyway). I don't quite know how that would work for a holder to specify how they'd like something rendered (don't know if that makes sense to do?). Organizations that issue credentials tend to want some level of control over the look/feel of the credential. A sofware system can ignore render and display it however it wants. This property is specifically for the issuer to state how they want the VC rendered.

I'm not supportive or objecting just yet, just contemplating what the right place for this is. I think a separate rendering spec that can be layered in would make more sense.

Yes, I agree that the SVGRenderingTemplate2023 section should be in its own specification, with the base property being defined here and pointing to an external specification. The reason it's lumped together in this PR is to avoid the "we have to define a concrete, implementable thing or we shouldn't put this in the specification" reaction from some of the WG members. It's up to the WG to determine how to structure and publish the work items.

[msporny]

I am worried to get sidetracked into some complicated specification discussion about templates like the SVG templates in the PR. Wouldn't it be better leave that open, or refer to some existing template languages like Mustache?

Yes, it would be preferable to use Mustache. The PR started with that approach, but I couldn't figure out how to cite it normatively. What would be the W3C Process argument in favor of doing that? The only thing that I could think of is state the dependency on Mustache in a non-normative fashion and that didn't seem like it would go over well with the WG.

[iherman]

I am worried to get sidetracked into some complicated specification discussion about templates like the SVG templates in the PR. Wouldn't it be better leave that open, or refer to some existing template languages like Mustache?

Yes, it would be preferable to use Mustache. The PR started with that approach, but I couldn't figure out how to cite it normatively. What would be the W3C Process argument in favor of doing that? The only thing that I could think of is state the dependency on Mustache in a non-normative fashion and that didn't seem like it would go over well with the WG.

The guiding principles are in https://www.w3.org/2013/09/normative-references. I do not know whether Mustache would satisfy the requirements, though.

[lemoustachiste]

Hey @msporny, so with Blockcerts we've been dealing with rendering since the inception and we've got quite a complete solution which I believe could easily be replicated, but also leaves quite a lot of flexibility to the issuer in the way they want to render their certificate.

At this moment we have support for HTML (SVG would work too), base64 images, base64 pdfs and I'm about to add support for base64 videos (granted, the HTML wrapper for rendering base64 is handled by our frontend component, but as I understand the proposal there would be similar logic involved). Obviously, and as discussed before, base64 comes with the downside of creating heavy certificates, but on the upside it does not rely on forever hosting nor internet to render (we do support hashlinks too to offer the counterpoint there (forever hosting but lightweight)).

We don't do magic handlebar rendering, so the HTML is actually generated before issuance. To me that offers the benefit of having the rendering data cryptographically verifiable and not temperable.

Anyhow, I wanted to attend RWOT to discuss this with you but couldn't get budget to do so. I'm not if I'm too late to the party, but I'd be happy to discuss with you the intricacies of our solution.

[iherman]

I am a bit surprised that the only rendering template would be SVG. Nothing against SVG, of course, but using SVG for rendering textual information might be a challenge. SVG does not have the ability to automatically wrap text into a fixed area, which means that displaying textual information properly is always a problematic. This may make it difficult to use SVG as a template in practice.

I would have expected to have an HTML template instead (or alongside) rather than SVG.

[dlongley]

Something else we're going to need here is security advice for doing the actual rendering, e.g., run it in a sandboxed container of some sort. This may also place restrictions on what the templates will be able to do that authors will need to understand.

[lemoustachiste]

@msporny wrote:

but the requirement for doing XSS filtering is an almost immediate red flag that you are in an area that must be constantly defended.

So I tried to get a little bit deeper in understanding rendering modes of SVG but I found limited information on the subject.
This blog article defines a bit more the usage of rendering modes: https://www.ctrl.blog/entry/svg-embed-dark-mode.html but does not necessarily address XSS vulnerabilities.

From what I can tell, rendering mode is decided by the user-agent (most likely a browser) and a developer has little control over changing it, and the only other browser solution is setting the Content-Security-Policy of the page and disabling for instance inline scripts. This requires the "webmaster" - to use an old term - to test and define what CSP works for whichever page on their site, requiring some intervention anyway.

I'm by no means an expert at CSP and only worked with it on the surface, but with modern websites that take scripts from CDNs and other third parties you can't have full trust that the rendering content cannot be used for targeted XSS.

From limited testing, loading the SVG from an external file as <img src /> or even when it has been encoded to base64 does not trigger XSS (hence being run in Secure Proccessing Mode, I assume). But in the case presented here or with blockcerts model, the SVG (or HTML) data would be part of the certificate and it would be likely that a consumer would just take the available data and present it within an HTML page, hence potentially opening an XSS vector, unless you mitigate that risk with either XSS filtering or CSP (or both).

What I'm getting at, is as soon as you are rendering HTML or SVG from an unknown source, you could have a malicious agent sneak in code, and I don't think a secure rendering mode totally alleviates the need for XSS filtering and/or other security measures, especially that secure rendering mode is not available for direct rendering of the SVG tag.

With blockcerts we made the choice to sanitize the content before rendering it, and handling it at our component level so that consumers don't have to worry about it, and I don't think this should be seen as a red flag, because that would be in any case the right thing to do as a frontend engineer.

[msporny]

rather than define yet another way of doing rendering, could we leverage some of the work already being done in for Credential Manifest (or at least Wallet Rendering)? e.g. perhaps we have the "render" property be an inline Credential Manifest (or URL pointing to one)?

Yes, that's the idea. The render property is associated with an object and that object is one mechanism that can be used to render the VC. The object can describe a DIF Credential Manifest (or whatever subpart of it you'd like), or something from the DIF Wallet Rendering spec, or something else.

There are two parts to this PR:

1. The establishment of the render property itself, and it doesn't look like we have any opposition to that.
2. The establishment of a simple and concrete instance of the property in the spec itself -- that's what people seem to be objecting to.

One way to address item 2 is to say that there are multiple implementations of the render property and that readers can look at the "VC Specifications Directory" for further information on the specifications that utilize the extension point.

i think we should have the ability to do both a "as the issuer of the VC here's exactly how I want it to be rendered" (i.e. a way to provide scriptless HTML with some sort of templating system, maybe a <slot name="foo">?)

Yep, agreed that we need a mechanism to do this. On this, I believe we have consensus (so far, in this PR).

and "for environments that desire uniformity, here's how to get the important bits of data" (i.e. a Credential Manifest in it's current form with "title" and "properties" and etc.)

Hrm, don't understand this statement above, could you elaborate on it a bit more?

also, if we really want to have such a freeform way to visually represent a VC then I kinda feel like we should add that to the Credential Manifest too (and then reference it here), as that'd likely be just as useful

That presumes that Credential Manifest is the way we do things, and I expect objections on that front.

All this to say, we can probably all agree that we need a render property... and that there will be multiple ways to use it (so we should point to how they're used in the VC Specifications Directory).

[msporny]

Based on the above, what concrete changes would you like to see to this PR?

I don't think there is an agreement in the WG that this should be the first normative rendering property. The topic needs more discussion before it is ready for PR.

There are two parts to this PR:

One of the parts seems to have consensus: the establishment of the render property itself.

The other part does not have consensus: That SvgRenderTemplate2023 (which was proposed as a simple straw man) should be ONE of the concrete mechanisms that we could standardize to demonstrate usage of the property.

Chairs (@Sakurann and @brentzundel), please schedule either VCWG call time or a special topic call to address @Sakurann's concerns.

[iherman]

The other part does not have consensus: That SvgRenderTemplate2023 (which was proposed as a simple straw man) should be ONE of the concrete mechanisms that we could standardize to demonstrate usage of the property.

I think that having a straw man in the spec may be helpful, but we should not make it normative. It can also be put as an example in the appendix, for example.

[OR13]

One of the parts seems to have consensus: the establishment of the render property itself.

To be clear, I don't think this has consensus.... It feels like something for the "directory"... not the core data model.

[OR13]

Prefer to not add rendering to the core data model, seems it belongs in the "directory".

[dlongley]

@OR13,

It feels like something for the "directory"... not the core data model.

Could you provide the rationale you're using for determining whether you think something belongs in the core data model or the directory?

[OR13]

@dlongley Everything we add to the core data model increases the complexity of the spec, the burden on implementers, the chances for bugs, security issuers, etc...

We should in general avoid adding features to the core data model, especially if the code data mode is based on JSON-LD which supports decentralization through context and RDF type extensions.

Features in the core data model should be implemented and relied on by the vast majority of Issuers, otherwise they would be better to be handled with an extension.

What percentage of VerifiableCredential RDF classes will use this property if it is added to that class?

Here are some existing properties of that class to consider:

• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L17 (credentialSchema)
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L21 (credentialStatus)
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L29 (description)
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L33 (evidence)
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L37 (holder is a property of VerifiableCredential)
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L41 (issued... should be validFrom)
  https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L45 (issuer)
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L49 (name)
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L53 (proof)
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L58 (refreshService)
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L62 (termsOfUse)

When implementing "the version 2 standard" an implementer will need to support all of these... or interoperability will be only on the properties that all implementers choose to support.

I think many of these would be better addressed via extensions, so that the cost to implement the core data model is minimized, and that extensions can be used to indicate support for interoperability with optional features.

[dlongley]

@OR13,

When implementing "the version 2 standard" an implementer will need to support all of these... or interoperability will be only on the properties that all implementers choose to support.

The purpose of standardizing certain properties / features is so that there's just one way of doing things -- for those people that want to do those things. That doesn't mean everyone has to do every one of those things. It's just that, for any one of those things, if they want to implement, they should do it in a particular way.

I think many of these would be better addressed via extensions, so that the cost to implement the core data model is minimized, and that extensions can be used to indicate support for interoperability with optional features.

A cost is paid in the ecosystem when there is a popular feature that is implemented many different ways. Adding a single way to do it in the core data model (or in another spec that the core spec references) mitigates that cost. Therefore, the idea that we should only put into the core data model the things that everyone in the ecosystem does (which we cannot know) I consider flawed.

[OR13]

@dlongley Does this not accomplish the exact same goal:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://example.com/svg/context/v1",
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential", "SvgCredential"],
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "render": [{
    "id": "https://example.edu/credentials/BachelorDegree.svg",
    "type": "SvgRenderingTemplate2023",
    "sha256": "ac996ae492f9a987c84f109f2118d3f6632e2259455d30c455a9ecd66c3c4959"
  }]
}

Why do we need to keep adding industry / domain specific credential metadata to the VerifiableCredential RDF Class, when RDF and JSON-LD support decentralized multiple inheritance?

This working group does not need to add support for "render", it would be better to have it defined and experimented with in the vc-specs-directory, and then after years of testing and evaluation, we could add it to the core data model... and the only thing that would change would be:

1. one less context (a minor improvement)
2. no RDF type to signal the SVG rendering is expected (this seems less desirable).

[dlongley]

@OR13,

I understood your original argument to be (not directly quoting you below, just my understanding):

We should stop adding things to the core data model that aren't going to be implemented by everyone (or nearly everyone). Everything that is in the core data model should be understood by implementers as "MUST/SHOULD implement".

I disagreed with this (as seen above) and I believe you are now making a different argument that I understand to be:

It's too soon to decide if people will want to put rendering information in the render property. Let's let the ecosystem experiment further before we say they should put it in the render property. They may decide to put it in the display, hear, renderCredential, showImage, showCredentialImage properties instead -- who knows?

Is this right? If so, I'm more amenable to the "it's early, let's let the market sort it out first" approach as a valid argument (vs. my view of your original argument, which I did not find compatible with the standards work we're doing here). However, I don't think I really agree ... since we're just potentially standardizing on a single property render -- and I think we already have multiple approaches from the market that people could put under this property? Why wouldn't we want to just go ahead and tell them to put those under the same property?

I'd rather not have to deal with writing code that has to search across N-many properties to find possible rendering information. This situation, to me, seems to be very similar to our decision to standardize name and description -- instead of having the market go through many different ways of expressing those. Maybe your view is that the market sorted those things out enough for us to make a decision, I don't know. But I felt like we should have probably included those in the 1.1 work because it was painful to not have them.

[OR13]

I'd rather not have to deal with writing code that has to search across N-many properties to find possible rendering information.

I think you end up needing to do this anyway, given that type is what actually matters for render.

Maybe this example makes that even clearer:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://example.com/svg/context/v1",
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential", "RenderableCredential"], // note the word renderable
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "render": [{
    "id": "https://example.edu/credentials/BachelorDegree.svg",
    "type": "SvgRenderingTemplate2023", // note the type agility
    "sha256": "ac996ae492f9a987c84f109f2118d3f6632e2259455d30c455a9ecd66c3c4959"
  }]
}

... since we're just potentially standardizing on a single property render and I think we already have multiple approaches from the market that people could put under this property?

There might be formal objections if we do this, we saw similar complaints for credentialSchema, credentialStatus, etc...

Those are all places where we standardized a "predicate" that relied on "non standard" "types" to actually be useful, and it has been argued this harmed interoperability.

I agree with those arguments.

I think if we standardize a "predicate" we are also on the hook for at least one "type" to demonstrate its use... hence, we are not just standardizing "render"... we are also sorta-sneakily standardizing "SvgRenderingTemplate2023"... similar to how JsonSchemaValidator2018 was introduced in v1.1, it forced us to do a bunch of work on "types" outside of the WG, and with a very fragmented experience that produced poor interoperability.

[iherman]

The issue was discussed in a meeting on 2023-03-08

• no resolutions were taken

View the transcript

1.8. 'render' property.

Kristina Yasuda: does the directory has to point to a URL or can have a specific text?.

Manu Sporny: question to the group - what do people think about the 'render' property for the core spec.
… there's a PR, we know of at least 3 other mechanisms to provide render hints (and this proposal unifies those).

Kristina Yasuda: +1 for rendering in the directory, -1 in the core spec.

Manu Sporny: this is not a new work item, it's an extension point.

Orie Steele: +1 for rendering in the directory, -1 in the core spec.

Manu Sporny: if you want this credential rendered, use this extension point.

Kristina Yasuda: me sorry, can't speak.

Manu Sporny: to be clear, what we'd need to do in the group is just agree to an extension point called 'render'. and then the VC directory would list the various specs.

Orie Steele: We don't need to agree to an extension point in this group, we have @context for that :).

Manu Sporny: so, just looking for feedback.

Kerri Lemoie: +1 to render endpoint.

Paul Dietrich: +1 to rendering extension.

Oliver Terbu: +1 to rendering extension.

See github pull request vc-data-model#1035.

Dmitri Zagidulin: Wanted to say +1 to proposal for render extension point, Orie is right, PR to VC context, but also means adding a paragraphs/section to VC spec to say "render" is an extension point, for options go see the directory..

ToddSnyderGS1: +1 to rendering extension.

Kristina Yasuda: +1 to rendering extension in the directory or in the core spec.

Dave Longley: +1 to render extension point.

Dave Longley: (or rendering if people prefer that name).

Dmitri Zagidulin: The render proposal was a paper in RWoT, with the proposal takes a look at existing prior art, Open Badges, DIF render, this mechanism adds support for expressing all those options. There was a session at IIW , packed room, on render, lots of interest from many parties. Question to the community, is there support for adding an extension point, then specifics in the directory..

Brent Zundel: from what I see in the chat, folks seem generally favorable, so I encourage to go to the PR.

Oliver Terbu: +1 to render instead of rendering.

Orie Steele: the DID Core @context has very few terms defined in core.
… it relies using the JSON-LD @context for extensions, defined as RDF classes or properties.
… there are cases where we probably made the wrong call on that, in DID Core.
… for example, not defining any public key formats in DID Core.
… there may be cases like that in the VC v1 or v2 context.
… where we're defining things in the @context that we shouldn't be defining there, that would be better in an extension or in a second context.
… or we're missing something that SHOULD be defined in the core context..
… this 'render' property feels like a perfect candidate for the VC Directory.
… I don't feel it's ready for the core spec though.
… the challenge with including the 'render' property in the core VC spec, is the interaction with that render property, protected contexts, the terms defined in the specs.
… I propose we wait and see how it's deployed in the wild.
… so, I recommend we just rely on the JSON-LD mechanism, and not add it to core spec.

Manu Sporny: to provide a counter-argument. the reason we define extension points in the spec, is to convey how people SHOULD extend.
… we already have feedback from multiple implementers that they want to render credentials somehow, signaling to the market that rendering has value.
… especially since there are many issuers today who DO care what the VCs look like.

Kristina Yasuda: +1 to relying on json-ld mechanisms for now, instead of adding a new property in the core spec for rendering..

Manu Sporny: the danger if we do not specify the property in the spec, is that market will fragment with many terms, renderFoo and renderBlah etc.
… the ask is very minimal. can we specify it /as/ an extension point.
… so, very tightly scoped.
… with a pointer to the VC Specs directory, where people can do the extension stuff that Orie is mentioning.

Orie Steele: Manu, sounds like you are arguing that JSON-LD's extension mechanism leads to fragmentation, perhaps this is the core problem this is highlighting..

Dave Longley: Orie: it's not binary like that..

Manu Sporny: yeah, Orie, please don't misrepresent the argument. :).

Joe Andrieu: the spec directory (not a registry) is good for open innovation, but isn't standardization. having a standard for rendering is going to be useful..

Brent Zundel: if you're an editor for one of our work items and want to provide an update, please jump on the queue, then we'll move to PRs.

[gobengo]

Instead of defining a one-off interpolation algorithm, perhaps it would make sense to define this algorithm in terms of svg/xml. e.g. replace <vc-select selection="{jsonpointer}" /> instead of {{jsonpointer}} (or whatever it is)

I think this would have the nice property of making the SVGRenderingTemplate2023 still be valid svg? svg2 says unknown elements should render as <g />

({{syntax}} may also be valid svg, but I imagine they'd render ugly)

[gobengo]

it might also scale to more complex types of replacements later (e.g. 'selections' with more complex types than just a jsonpointer)

[gobengo]

@OR13 i like that Renderable 'trait' idea

[OR13]

@gobengo in JSON-LD, we call "traits" "multiple inherence"...

• https://www.w3.org/TR/json-ld11/#example-15-specifying-multiple-types-for-a-node

@type is aliased to type in the JSON-LD @context files.

• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v1#L7

• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L7

This enables open world extensibility with semantic term definitions without needing to maintain all the terms in a "single registry" or in a "single specification" : )

[Sakurann]

this PR should be closed when PR #1108 is merged - ie this property is added to the reserved table

[iherman]

The issue was discussed in a meeting on 2023-05-03

• no resolutions were taken

View the transcript

3.1. Add rendering property to VC Data Model (pr vc-data-model#1035)

See github pull request vc-data-model#1035.

Brent Zundel: rendering property.
… a few approvals, a copule of folks requesting changes.
… my read is that this will be addressed by rendering property being added to the table of reserved properties.
… so anticipate being resolved by that.
… so, i don't assume we need conversation on that.
… if no conversation, we can move on.

Orie Steele: There is also a new CCG work item proposal for the rendering property w3c-ccg/community#244.

[iherman]

The issue was discussed in a meeting on 2023-05-17

• no resolutions were taken

View the transcript

3.2. Add rendering property to VC Data Model (pr vc-data-model#1035)

See github pull request vc-data-model#1035.

Brent Zundel: similar questions here.

Manu Sporny: This item did get into the reserve property table.
… There is a proposal to make it a CCG item.

Orie Steele: +1 to closing the PR.

Manu Sporny: I think we can close this immediately (or after the call).

Michael Prorock: #1108 was merged so no reason to keep this open.

Manu Sporny: The plan here is that it is in the reserved properties table, there's a work item in CCG. maybe a future version of the group can add it, or after CR.
… +1 to marking pending close.

Brent Zundel: alright. unless there's objection...
… I'll mark pending close.
… Now, beginning conversation on two related PRs. Last five minutes of this call.
… To queue up what we need to talk about.

[msporny]

I opened this PR, there were no objections to closing it on the call, so I'm closing it now. It lives on in the CCG work item on rendering methods.