Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for VC Render Method: OpenAttestationRenderMethod #8

Open
cxcheng opened this issue Mar 28, 2024 · 3 comments
Open

Proposal for VC Render Method: OpenAttestationRenderMethod #8

cxcheng opened this issue Mar 28, 2024 · 3 comments

Comments

@cxcheng
Copy link
Collaborator

cxcheng commented Mar 28, 2024

HI, this comes out of our VC framework OpenAttestation. OpenAttestation has been in production since 2019 and has been implemented in a number of applications such as OpenCerts.io, https://www.healthcerts.gov.sg/, and also TrustDocs.

We feel W3C endorsement and interoperability are essential to us. As a result, we are working hard to align OpenAttestation with VC DM 2.0 and are in the process of creating a new version of OA that is compatible with VC DM 2.0 and running the VC 2.0 TestSuite with it. We also need to provide a good migration path for our users.

OpenAttestationRenderMethod works differently than the svgrenderingtemplate2023 which takes a template from URL. Instead, it points to a decentralised render implementation that implements a PostMessage API for the verifier to pass the VC body to the renderer. The VC presentation is rendered as an embedded document within the IFRAME. This allows us to implement user interactivity. Here are more detailed write ups of how our existing renderer works.

Proposed renderMethod block:

"renderMethod": {
    "id": "https://demo-renderer.openattestation.com",
    "type": "OpenAttestationEmbeddedRenderer",
    "name": "GOVTECH_DEMO"
  },

You can try the renderer in action at https://www.opencerts.io/.

  1. Drag and drop the demo cert into the box.
  2. Click on different tabs to get different views.
  3. For the transcript tab, you can perform selective obfuscation of fields interactively and then download.

Benefits

  1. Already in production. Multiple implementations exist.
  2. Supports interaction and animation for better UX.
  3. Implementers have freedom to provide additional functionality meaningful to specific use cases such as multiple tabs for different views, or presentation of embedded PDFs.
  4. Open source default implementation provided as a Node.js library.

I understand that you may have questions and concerns. We are keen on pushing for this as we want a clear migration path for our existing user.

@wmclaxton
Copy link

My company NextID, author of NextCert, is one of the vendors implementing the OpenAttestation framework. We found a number of shortcomings with the OA decentralised render implementation, mainly with the format of the what is called the 'template' and which we call the 'layout'.

We found the implementation cumbersome because layouts must be created in React or similar programming languages. Among other things, this makes it difficult to edit interactively or get client approvals. So we changed to layouts using HTML and CSS and implemented tag substitution similar to handle bars. A key benefit if this change is that the design of certificate layouts is squarely in the hands of designers rather than engineers. This has enabled greater design flexibility using Flex CSS. NextCert also includes a layout upload feature using a zip package, so there is no need for pull requests in deployment, etc. When a client approves a layout, they can immediately begin using it to issue certificates or attestations.

@cxcheng
Copy link
Collaborator Author

cxcheng commented May 28, 2024

Here is our proposed write up to update the specification: https://docs.google.com/document/d/1RjpRx573aPzTeH5O1UFdDpVWwbppM1ScB5e-NN294_0/edit?usp=sharing

Want to get feedback before proceeding. Will prefer to put into its own section.

@TallTed
Copy link
Contributor

TallTed commented May 29, 2024

[@cxcheng] Here is our proposed write up to update the specification: [...] Want to get feedback before proceeding. Will prefer to put into its own section.

It would be best to turn that Gdoc into a PR against the existing spec, where you would like it to become a new section. This will allow interested parties (including yourselves) to see (via PR-Preview) what it will eventually look like, and to submit change requests against your PR, all while maintaining commit/suggestion history (which is lost in Gdocs), thereby addressing contribution and patent policies, among other concerns.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants