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.