Skip to content

Conversation

@BigBlueHat
Copy link
Member

@BigBlueHat BigBlueHat commented Jan 9, 2026

This is a very early draft of the HTML Render Method approach mentioned on this weeks call. It's currently more descriptive than "spec-ready" so the MUST language is likely misplaced and decisions need making around what the MUSTs must be (heh) for environments not running in a "classic" Web browser of WebView.

Additionally, I'm also writing up the specifics for providing and using a "ready"/"error" handler so the template can let the Wallet know when it's ready to be displayed...or when it's errored out.

@dlongley deserves all the credit for this design.

Cheers!
🎩


Preview | Diff

@dlongley
Copy link

dlongley commented Jan 9, 2026

For interested developers, there is a dev-targeted demo here (may be actively changed so be forewarned):

https://digitalbazaar.github.io/html-render-method-test

With source code here:

https://github.com/digitalbazaar/html-render-method-test

To make it clear these are not to be rendered on their own.
@dmitrizagidulin
Copy link
Collaborator

PR discussed in the Wed Jan 28 call. This is a great start, moving in the right direction. Ivan requested a bit more specification algorithm code before merging the PR (diagram will come later). To do:

  • Add spec language / algorithm
  • Consider instead of injecting the full (but pre-filtered) VC, instead inject a "data" object that is just key/value pairs (keys being the JSON Pointers, values being the property values from the VC)
  • Add a separate template example, with CSS
  • Clarify roles -- trusted template provider, renderer (who has access to the full VC)
  • Clarify the use of "selective disclosure" (the filtering of non-shared fields before it gets injected into the template)
  • We're using JSON Pointers instead of JSON Paths here

@BigBlueHat
Copy link
Member Author

  • Add spec language / algorithm

First draft of this is done.

  • Consider instead of injecting the full (but pre-filtered) VC, instead inject a "data" object that is just key/value pairs (keys being the JSON Pointers, values being the property values from the VC)

I corrected the example code and also referenced the selectJsonLd method described in Data Integrity ECDSA Cryptosuites v1.0 per @dlongley's suggestion. It essentially uses JSON Pointer on the original VC and results in a partial VC as a JSON object.

Sample code for that approach is available at https://github.com/digitalbazaar/html-render-method-test/blob/main/select.js

  • Add a separate template example, with CSS

I added CSS to the main example instead.

  • Clarify roles -- trusted template provider, renderer (who has access to the full VC)

I wasn't quite sure how to address this one. The template code is considered to have the same "trust" levels as any other data in or referenced by the VC in question. A sandboxed iframe is used to prevent network access, etc. to (in part) avoid the need for additional "trust" to be brokered around the template code provided via the render method.

  • Clarify the use of "selective disclosure" (the filtering of non-shared fields before it gets injected into the template)

The flowchart I added used "selective disclosure" but much of the text I wrote talks about a "filtered" VC. It's something the group should discuss as I don't think we want to force selective disclosure cryptograph on folks considering this Render Method approach, but if a Wallet/Renderer had that capability, there's perhaps added value for certain use cases (such as rendering a VC Barcode of the derived credential.

  • We're using JSON Pointers instead of JSON Paths here

Yeah...that "bug" was just in how I was talking about things on the call. It wasn't in the text. They're very easy to confuse (imo) given the one that looks like a filesystem path is the Pointer... 😖 Anyhow. Not a bug with the text, in this case (thankfully!).

If folks seem happy "enough", I'd love to get this PR merged, so we can then work on smaller revisions to it and avoid a long lived PR.

Thanks!
🎩

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

Successfully merging this pull request may close these issues.

4 participants