[BigBlueHat]

• Rename card to highlights Render Suite.
• Fix SHOULD validate to MUST validate.
• Remove template-level validFrom/validTo overrides.

Other things we might also consider include:

• Should string values (non-JSON Pointers) continue to be supported in fields?
  • what about name, description, and icon?
• Should these JSON objects be inline-able as JSON under template?
• Should we swap theme out for outputPreferences.style?
• Should the 3 explicitly named fields (name, description, icon) be contained in a summary section?
  • or conversely, might they just be handled in fields also?

---

Preview | Diff

[dmitrizagidulin]

Discussed during 2026-08-25 call.

• Group not sure if highlights is the right name, possible others: summary, priority fields etc
• We shouldn't over-optimize on cards specifically, nor create two separate suites (cards + summary), summary alone should be sufficient

[BigBlueHat]

Similar work Digital Bazaar uses in the Veres Wallet: https://github.com/digitalbazaar/bedrock-vue-wallet/blob/5bed1ceb87aaf77493413a846244a26dbb98a145/lib/cardDesigns.js#L15

Those are not issuer provided, but provided by the Wallet implementer. It's related to this and also #78 for those who want to muse on that vector of implementation also.

[dlongley]

I think "highlights" or "priority" (or other abstract names that aren't about a particular concrete UI component) are better for this render method.

To me, the most important aspect of this render method is that it allows an issuer to tell the consumer what information to prioritize in their renderings, without making any statement or constraint about what kind of UI component(s) a consumer might use, allowing the consumer to integrate the information appropriately into their own UI(s).

There are certainly renderings that are known to us today that we want to support, such as short summaries/overviews, tables/lists with rows, card-like or other compact single or grid components, and "highlighted fields" or "fields displayed in order of significance" in more detailed views. This render method should support these, but not be limited to them.

[iherman]

I am warming up to 'highlight' after the discussion; maybe 'emphasis' is more neutral in term of a visual connotation.

'priority', usually, involves putting things in terms of priority order which is not the case here. Hence my preference for 'highlight'/'emphasis'.

[dmitrizagidulin]

I am warming up to 'highlight' after the discussion; maybe 'emphasis' is more neutral in term of a visual connotation.

'priority', usually, involves putting things in terms of priority order which is not the case here. Hence my preference for 'highlight'/'emphasis'.

I agree about not using visual connotation if at all possible, and avoiding priority order connotation. What about summary as the suite name? Since that's the most common use case for this suite.

[BigBlueHat]

@dmitrizagidulin we should probably close this one in favor of redoing it once/when a new renderSuite name is created/decided upon.

[dmitrizagidulin]

Agreed, we can close this one until the name gets sorted out.

[TallTed]

we should probably close this one in favor of redoing it once/when a new renderSuite name is created/decided upon

@dmitrizagidulin, @BigBlueHat — I strongly suggest that when this PR is closed, a tracking issue be opened to help ensure this PR is "redone" at the appropriate time.

[dmitrizagidulin]

PR overtaken by events (and several of the changes made it into PR #76), closing.