Render method to enable card-like displays in wallets and displayers

[ottonomy]

For discussion and consideration, I don't have any particular product that aims to use this concept imminently. Feel free to edit.

The concept is:

• If a credential uses this render method, it is possible to identify which data in the credential best corresponds to summary properties that would be desirable to display on a card, with a few top-level properties and a priority-ordered list of labeled data fields pulled out of a credential's structure for display.
• Summary views could display the core data fields plus one or two of the deeper fields, and detail views could display all of the fields.

---

Preview | Diff

[msporny]

At a high level, this looks useful to me. A couple of suggestions:

• Perhaps we can call this the "Summary" or "Card" render suite? I don't know what a "json-card" is and what this is actually doing is providing a fallback summary display.
• What is the Internationalization and Accessibility story here? I don't think we'll pass the i18n and a11y reviews without one.

[msporny]

I don't understand the purpose of these properties?

[ottonomy]

Changed them to validFrom and validUntil to match v2 versions now that v2 is standardized. Like name and description, these are "built-in" fields that would be expected to be displayed on every credential card in a predictable location.

[msporny]

Suggested change

	"label": "Institution",
	"value": "/issuer"
	"label": "Institution",
	"language": "en",
	"value": "/issuer"

We could do this for i18n?

[ottonomy]

Added in [d26a211](https://github.com/w3c/vc-render-method/pull/39/commits/d26a211fead8c35f05737228c33b40be5c459029)

I worry that proliferating a wild number of different language titles for specific fields would make for very large credentials, especially if the credential claims were also expressed in multiple languages, but I guess in large credentials, the need for sensible rendering is even more.

[dlongley]

+1 to the concept in this PR. I think if any VC has both a "Summary Card JSON" render method and a (forthcoming PR) sandboxed-HTML render method, it should cover the vast majority of rendering cases.

The "Summary Card JSON" rendering is useful for interfaces that want to have significant control over their own UX and integrate perhaps many different VCs at once into a unified view (lists, tables, cards, etc.) and the sandboxed-HTML render method provides the issuer's preferred custom view of a single VC (potentially even interactive!).

[BigBlueHat]

FWIW, Microsoft has something rather similar in their "Credential Display Definition" format that they support: https://learn.microsoft.com/en-us/entra/verified-id/credential-design#create-a-credential-display-definition

It's a ❄️ (unique to them, afaict), but the similarities are strong enough that we should at least be aware which features this proposal covers (or doesn't) for future discussions in the space.

[iherman]

This was discussed during the vcwg meeting on 19 May 2026.

View the transcript

Render method to enable card-like displays in wallets and displayers by ottonomy · Pull Request #39 · w3c/vc-render-method · GitHub

Manu_Sporny: All right. sounds good. Nate, again, we're trying to not let PRs just sit out there for extended periods of time. would it be better to move this back to an issue and work through? I mean, it's how complete do you feel is this we're just going to revise the PR until we can review it or what do you think the path forward here is?

Nate_Otto: I imagine this is a 90% complete. I bet that I think there was some useful small comments and I don't recall every little bit of the history of whether I went back and made more commits. I don' think you could close the PR or something. Don't delete the brand.

Nate_Otto: I mean, it's on my remote, so you can't delete the branch. that's more

Manu_Sporny: Okay, thanks on the queue.

Benjamin_Young: Yeah. I would suggest that this is far enough along that we merge it and…

Benjamin_Young: and then file issues against it. Even if the JSON format or whatever is going to change, if it's 90% complete, otherwise it's just going to idle so long. it's going to be a pain to merge later. And I think we got to the place where it was like this is probably unique opposite the HTML sandbox thing at minimum for efficiency of display. So that's it.

Manu_Sporny: Thanks I'm concerned about merging it in its current form primarily because I don't know if J so I think it's just a terminology, JSON card us data display versus something else. I think we need to be pretty clear about what are we doing here? meaning how do we communicate this to the outside world? One of the things I'm concerned about Benjamin is we merge it and the term Jason card sticks and I don't know if that's the best way of explaining what's going on here. It's really a data view. what you're doing is you're generating a data or it seems like what you're generating is a data view on the thing.

Manu_Sporny: and there's some open questions like why not YAL that sort of stuff not that I think we should do that but those are the other 10% of things it feels like we need to do here go ahead Nate

Nate_Otto: I mean, if there is interest in trying to get this merged and you think that we could resolve open questions around language, I could try and accelerate a little bit of efforts to be able to sort of clean up the last couple things and get it to what I feel confident in merging pretty quickly. I don't care so much about the JSON in there, but I do like the word card is included in here because the idea here was essentially to look at the sort of standard credit card shaped space that something could be displayed in and look at about the amount of fields that could go there.

Nate_Otto: and we're seeing lots of wallets that are choosing to display various credentials even down to the level of concert tickets in a cardlike format. So if we call it a data card whatever, I don't care. And then as far as the use of JSON, I think if folks want to make an argument for a preferred language or syntax other than JSON is the lingua frana most common thing. And I think it would probably be hard to say that there would be something that would be more ubiquitous and easier to use.

Manu_Sporny: Yeah, plus one to that. I was just suggesting we hadn't necessarily talked about that. So, it sounds like maybe if we can try to get quick iterations on this just to make sure we've got the concepts that's nailed in nailed down I'm seeing Dave saying some things that are slightly different from what you said Nate which are slightly different from what I have in my head which is Benjamin why I'm a little concerned about merging it right now but if we can iterate on this quickly I think we can get to something quickly noting that we're all very busy so how about we keep the PR open and we see if it gets any movement over the next couple of weeks hopefully

Manu_Sporny: And then we'll revisit on the next call. Does that sound okay to folks or any objections to taking that path? seeing a thumbs up. all right, one is removing this next one is removing the PDF and SVG mustache render suites. No reviews on this. I think I would like to merge this…

<Dave_Longley> +1 it's some kind of data view / field view ... something along those lines

Manu_Sporny: because I don't think any of us, believe this these two things are going to continue. go ahead, Benjamin.

<Dave_Longley> worried about locking too much to a "card" concept as UIs can change a lot in a short period of time

Benjamin_Young: Yeah, I linked to the issue I created this morning and…

---