Investigate best ways to render a credential template (inlined?)

[nissimsan]

Ref https://github.com/uncefact/spec-untp/pull/23/files

[onthebreeze]

https://w3c-ccg.github.io/vc-render-method/ specifies a hash-link rather than an embedded render file. My feeling is that this is OK because render templates are related to the VC type (eg a DPP) and so can be cached in a similar way to json-ld context files - improving performance, facilitating offline use, and avoiding an excess of "call home" pings.

Only thing is I see that https://w3c-ccg.github.io/vc-render-method/ talks about an SVG template. What about an HTML / web template? Any reason why we should prefer SVG?

[nissimsan]

I'd love to see this (super quickly) demoed in a meeting, how it works?

[nissimsan]

https://w3c-ccg.github.io/vc-render-method/ (kudos to @ashleythedeveloper digging this up in the ccg mailing list)

[ashleythedeveloper]

ccg mailing list thread - https://lists.w3.org/Archives/Public/public-credentials/2024Mar/0048.html Resulting ticket - https://github.com/w3c-ccg/vc-render-method/issues/7

[PatStLouis]

Defining the purpose of a render method would be useful here.

Assuming the use case of supply chain actors who do not leverage VC and want the data useable as another medium in their system (such as a PDF file), the focus should be on providing a recipe for conversion.

I like the path of json-ld -> html -> pdf. In the example provided by @ashleythedeveloper is seems like a mustache/html template was used. This is interesting.

Another idea is to include a rendered pdf encoded in a similar algorithm to the BitstringStatusList (GZIP compression with b64 url encoding).

I would also like to add the Aries OCA Bundles as an option of how to provide visual representations of credentials. This can help with branding and so on. The model is that these bundles are hosted by the issuer of the credentials and provide rendering instructions/metadata.

[ashleythedeveloper]

Hey @PatStLouis,

Defining the purpose of a render method would be useful here.

I agree. I see two main use cases for the renderer:

To facilitate adoption alongside legacy paper-based systems The idea here is to provide a way to use VCs without putting a tech burden on parties still using paper systems, while not hindering VC usage.

Embedding a QR code on the paper doc is how we've done this before. The QR code contains a link to the verification app and a query param specifying the VC location, hash, and optional decryption key.

This lets paper-based workflows continue as normal. But when the document reaches a VC-capable supply chain actor, they can access the VC via the QR code payload.

To accommodate the humans Pretty self-explanatory. Most VC transactions will likely be machine-to-machine, but when humans need to be involved, we have to support them.

We can't assume border agents and such will understand JSON. The renderer's job is to make the VC human-readable and understandable.

I like the path of json-ld -> html -> pdf. In the example provided by @ashleythedeveloper is seems like a mustache/html template was used. This is interesting.

Yep, we are using handlebars and the HTML template is embedded in the VC.

Another idea is to include a rendered pdf encoded in a similar algorithm to the BitstringStatusList (GZIP compression with b64 url encoding).

Yes, another viable approach, we have also used this approach where we would take the original document produced in the paper-based system, encode it and embed it in the VC.

I will look into Aries OCA Bundles

[PatStLouis]

OCA Bundles can also support multi-language for the key values. This is a useful feature to have. They were originally designed for mobile device and AnonCreds, but I think there's some great concepts in there that could apply elsewhere.

Here's an example of BC Mines Act Permit

[nissimsan]

Defining the purpose of a render method would be useful here.

Yes, also +1 on this. This seems to be diving into technicalities slightly prematurely.

Yep, we are using handlebars and the HTML template is embedded in the VC.

@ashleythedeveloper, is there an example available anywhere publicly demoing this in action?

[PatStLouis]

I agree with these use cases. How high on the chart does a need for multi-language support stand?

I would argue we have a strong enough use case to reach out to the w3c-ccg and inquire about the renderMethod state as it's at risk of being deprecated.

There's a lot of knowledge to get from the folks who worked on this. Maybe reach out to @dmitrizagidulin

[ashleythedeveloper]

Is there an example available anywhere publicly demoing this in action?

Hey @nissimsan, you can find an example using the WebRenderingTemplate2022 render method here.

[nissimsan]

To close this, I propose a similar approach as what we discussed on issue 31:

1. List business requirements, noting how verifier app developers should be considering this (formatting is optional)
2. Note Handlebars as a supported solution option

[PatStLouis]

@nissimsan adding a section in the spec about credential rendering where we list these requirements/purpose, as well as the suggested method (vc-render-method) and a selection of types sounds like a great way to capture this. Are we ok to establish that the vc-render-method is the current preferred approach for this? Then we can spec a html render method and/or oca render method.

Including @amanji in the conversation as he's the most knowledgeable about OCA bundles. He made a proposal for OCA bundle extensions at the Open Wallet Foundation and we could spec a OCABundle render method with the w3c-ccg group. https://github.com/openwallet-foundation/bifold-wallet/tree/main/packages/oca/src/formatters/credential

We will investigate this, I believe Akiff would also be willing to host a demonstration if need be

[amanji]

Please let me know if there's any additional information I can provide on the subject of OCA.

[nissimsan]

@PatStLouis , @amanji , I encourage you to collaborate with @ashleythedeveloper on this section.

I would expect it to comprise of:

• Introduction (what is this for where is it shown)
• Requirements
• Recommendations

[ashleythedeveloper]

Initial thoughts:

1. Compatibility with legacy systems:

   • The render method should support embedding a QR code on paper documents to provide a bridge between paper-based workflows and digital VCs, allowing easy scanning and access to the associated verifiable credential.
   • The QR code should include a link to the verification app to guide users to the appropriate application for verifying the authenticity and integrity of the associated VC.
   • The QR code should incorporate query parameters specifying the VC location to provide a direct reference to the location where the VC is stored.
   • The QR code query parameters should include the VC hash to enable verification of the integrity of the VC by comparing the stored hash with the hash of the retrieved credential data.
   • The QR code query parameters should include an optional decryption key to facilitate secure access to the VC data in cases where the credential is encrypted to protect sensitive information.

2. Human readability:

   • The render method should make the VC human-readable and understandable, without assuming knowledge of JSON or other technical formats.

3. Multi-language support:

   • The render method should consider multi-language support to accommodate diverse user needs and facilitate global adoption.

4. Compliance with standards:

   • The render method should be compatible with the vc-render-method specification, to ensure interoperability and consistency across implementations.

5. Flexibility in presentation:

   • The render method should allow for customisation of the visual presentation of the VC, enabling issuers to maintain their branding and style while ensuring the integrity and verifiability of the credential.

6. Accessibility:

   • The render method should adhere to web accessibility guidelines to ensure that the rendered VC is accessible to all users.

7. Cross-platform compatibility:

   • The render method should produce output that is compatible with a wide range of devices and platforms, including mobile devices, to facilitate widespread adoption and usability.

8. Performance and efficiency:

   • The render method should be optimised for performance, ensuring that the rendering process is efficient and does not introduce significant latency or processing overhead.

9. Scalability:

   • The render method should be designed to scale effectively, accommodating the potential for high volumes of VC issuance and verification as adoption grows.

10. Security and privacy:

    • The render method should maintain the security and privacy of the VC data and the end consumer, ensuring that sensitive information is protected and only accessible to authorised parties.

11. Extensibility:

    • The render method should be designed with extensibility in mind, allowing for future enhancements and the incorporation of new features or types of credentials as the VC ecosystem evolves.

[PatStLouis]

@amanji @ashleythedeveloper I had discussions with Dimitri during IIW this past week and there's interest in starting a render method taskforce at the w3c-ccg. The goal will be to define 2 rendering methods, html templating and OCA. We will try to get a publication on the public credentials mailing list this week. Would you be willing to participate?

[amanji]

@PatStLouis that sounds great! Happy to assist with this.

[onthebreeze]

https://www.figma.com/file/NpUtygjBEl0xEaDtG8A9aU/DPP-Render-Template?type=design&node-id=60-26564&mode=design

For those interested, here's a draft design for a default html rendering template that we could include with the UNTP spec