Re: decentralised VC renderer question

I would suggest the developer of a given credential type should be the one
developing a suitable rendering. By analogy with the web, if you think
about an HTTPS connection to a website, the content you obtain is
verifiably from that site. In this sense, the web has always had rendering
performed by the content issuer. This solves the n^2 problem you mention.
That rendering is verifiable also, since.it allows for the issuer to sign
the rendering.

That is not to imply a rendering must be 'pretty': PDFs, CSS, colours, etc.
It could be abstract: LaTeX, HTML, ....

On Tue, 29 Jun 2021 at 07:14, Daniel Hardman <daniel.hardman@gmail.com>
wrote:

> Horacio Nunez (Kiva) has been talking about how to automatically generate
> an SVG of a VC -- either with a custom SVG template published by the
> issuer, or using a default algorithm published by a whole industry.
> His work is here: https://github.com/kiva/credential-representation
>
> On Tue, Jun 29, 2021 at 4:26 AM steve capell <steve.capell@gmail.com>
> wrote:
>
>> Hi all,
>>
>> I'm just wondering whether this group has had any discussion of - or any
>> implementations of - a decentralised VC renderer that works a bit like this
>> https://www.openattestation.com/docs/advanced/custom-renderer/
>>
>> The idea here is that it helps with scalable implementations when a
>> verifier of a VC doesn't need to design and build it's own human consumable
>> view of the VC.  Instead it can say "I'll show it the way this rendering
>> template from the issuer says it should be viewed"...
>>
>> It's very helpful in long supply chains where we can't assume every step
>> has a machine integration for a given credential type.  From my perspective
>> the key value is that it massively reduces implementation costs across a
>> linked data network where there are many issuers and verifiers of similar
>> things - because it reduces the human rendering development from an
>> N-squared problem to an N problem..
>>
>> if it hasn't been a topic for the group then maybe it's something to add
>> somewhere on the long list of future to-do's?
>>
>> --
>> Steve Capell
>>
>>