Re: Request for Editor permission to add OpenAttestationRenderMethod

Thanks Manu,

My Github handle is "ashleythedeveloper", and Steves is "onthebreeze".

On Mon, 27 May 2024 at 02:27, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On Tue, May 14, 2024 at 7:21 PM Ashley Harwood
> <ashley.harwood@gosource.com.au> wrote:
> > We would also like to contribute to this specification, particularly to
> RenderTemplate2024.
> > Our team is currently working on an implementation, and we are more than
> happy to contribute our efforts to this initiative.
>
> Sounds good, I need your Github account to give you access.
>
> Steven Cappel wrote:
> > We are also preparing an html render template spec - which is very
> similar to OA except it’s a hash link to the external rebderer (just to
> prevent an attack where someone manipulates a rebderer to present something
> not in the vc)
>
> Got it, feels like we could align the use of "digestSRI" or
> "digestMultibase" for that?
>
> https://w3c.github.io/vc-data-model/#integrity-of-related-resources
>
> Note: There are a number of us that are nervous about allowing HTML
> rendering (due to cross-site scripting attacks, etc). There are ways
> to mitigate this, but we expect many implementations to get the
> details wrong. Just noting that as a concern, we can add stuff to the
> security considerations section in an attempt to mitigate some of the
> security concerns (like using a sandboxed renderer, etc.)
>
> Same concern as above, Steven, need your Github handle to add you.
>
> Sin Yong, Loh wrote:
> > Let's collaborate since we are also working on this. The last thing we
> want is to have each of us having a different implementation that are not
> interoperable.
>
> Noted, aligning would be better than most, but we don't have to align
> in the beginning. Let's get all of the approaches documented and go
> from there.
>
> Patrick St. Louis wrote:
> > If there's enough interest/participants in starting this effort I would
> be happy to facilitate.
>
> That would be good. I know that some of us won't be able to
> participate until the VC Data Model v2.0 work is complete and we can
> move on to the extensions (render method, confidence method, etc.). We
> are also going to have to find a time that works well for Singapore,
> which will inevitably mean Europeans won't be able to participate.
>
> > Would it make sense to follow the model of the vc specifications
> directory to manage adding the different methods proposed in this thread?
>
> I'd rather we put all of the mechanisms in the same spec for now, if
> we can. There is A LOT of overlap and it's been suggested that many of
> these approaches only differ in the media type used. That is, it seems
> like the HTML, SVG, PDF, and other formats all use handlebar-like
> mechanisms and so we might be able to unify 3-4 of the render methods
> if we allow media type selectability for the render method.
>
> > BCGov and I will be looking at implementing the OverlayCapture method,
> we will also implement the RenderMethod2024 proposed by Steve and Ashley.
>
> Sounds good, let's try to get things loosely documented at a high
> level in the spec. This might not be possible for things like OCA
> (which has it's own set of specs, IIRC). In that case, it does make
> sense to list them in the VC Specifications Directory as separate
> extension specifications.
>
> For now, let's get people raising PRs for the Render Method spec and
> get everything documented as much as we can, we can then see if it'll
> be possible to merge multiple methods together. I have a hope that
> some about of convergence will be possible with the less involved
> rendering methods.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>

-- 


---
The content of this email and attachments are considered 
confidential. If you are not the intended recipient, please delete the 
email and any copies, and notify the sender immediately.  The information 
in this email must only be used, reproduced, copied, or disclosed for the 
purposes for which it was supplied.