Use cases for human rendering and hosted verifiers.

There is a scope item in this project to prepare "rendering templates" but it's not made completely clear why this is important. Also I think we have perhaps conflated two separate questions when we talk about rendering.

• How do you show a human readable version of a digital document to a user that is not equipped with VC tools?
• How can a verifier that has no VC capability still do a verification of the digital document?

Lets start with a common business scenario - the cross border commercial invoice. Bit of a misnomer because it's really more like evidence of value than demand for payment but nevertheless the important thing in my opinion is to understand that this is not a two-party (seller -> buyer) transaction. It's a multi-party process.

The diagram shows all the different parties that may have a genuine business reason to have access to the commercial invoice. What is very quickly evident (and indicated by the pdf/digital icons at the bottom) is that the likelihood that ALL parties to this process are digital VC ready is pretty much zero. And if the issuer had to know who is digital ready and who isn't and act differently for each then there would be no implementations because it's just too complex.

Here's a typical scenario

• The exporter issues the invoice and is using some VC-ready accounting package and wants to send an invoice to the importer, and provide it to his export customs broker (who will do the export declaration), and to a chamber (that will issue a preferential certificate of origin). This exporter just wants to send the same thing to all parties.
• The chamber is under a legal obligation to verify the authenticity and integrity of the invoice before issuing a preferential CoO but doesn't have a VC ready system - so wants to scan something that will give confidence of document integrity.
• The customs broker also has a legal KYC obligation and his broker system has a nice feature to extract data from invoices to fast-track the creation of export declarations - but it doesn't know about VCs. So the broker wants to do the verification manually (scan something) but will extract data to his system.
• The importer knows their supplier very well, was expecting the invoice and doesn't feel any need to verify it. This importer doesn't have a VC ready system and so will treat this invoice just like the PDF ones that have been received before. His software is not VC ready but does have a useful feature that reads unstructured data to create draft accounts payable invoices. The importer also needs to give the invoice to his import customs broker and also to a financial institution for trade finance purposes.
• The finance institution is on-board with algorithmic due diligence and is perfectly capable of verifying and processing the invoice VC themselves. They just want the credential and dont care about any human rendering and don't need any third party verifier.
• The same goes for the importing customs authority. They've seen the light about the huge improvement in compliance outcomes ($ billions of revenue improvement due to reduced tariff and excise leakage as well as much reduced piggybacking). So they also just want the verifiable credential and will process it and verify it themselves.

So out of this we can distill a few different recipient "verification" patterns:

1. "do nothing" : the recipient that is not a verifier. Just expects to get a PDF invoice and treat it like they always have with no specific concern about verification.
2. "just scan" : the recipient that does want some evidence of integrity but will generally accept a verifier service specified by the issuer. Will just expect to scan a QR and see something trustworthy. This verifier is likely to start to look for who is actually hosting the verifier service and decide wither to trust it.
3. "choose my own" : the recipient that does want to verify the document but doesn't trust an issuer specific verifier and so wants to be able to drop the document onto a verifier site of their choosing - one that they trust.
4. "Internal" : the recipient who is an advanced VC user and has their own internal verification service and just wants the structured VC.

so type 1 will just look at the human readable doc. Types 2 & 3 will look at the human readable doc and verify it using some external verifier service. type 4 wont look at the human readable doc at all and will just process the VC.

So, the design question is : what is the advice to the issuer of this VC that allows them to issue one VC that meets all four recipient verifier patterns? Some design options are

1. Separate documents, no verifier. Issuer makes a PDF invoice as normal and separately issues a VC and stores it at a URL. Puts a QR on the PDf that resolves directly to the VC. Probably makes sure that the storage location is unguessable (ie a UUID) so that only the holder of the PDF can get the VC.

• Pros: Simple. If the recipient knows that the QR links to a raw VC then they can drop the PDF with QR into a verifier service they know and trust.
• Cons: PDF data is totally decouples from structured data so an attack vector is to put the valid QR on a fake document. Also if any human simply scans the QR they will just see meaningless code.

2. Separate documents, hosted verifier. Issuer makes a PDF invoice as usual and puts a QR in the corner. But this time the QR points to a verifier service of the issuers choosing and the VC is a URL parameter that the verifier service can access and verify.

• pros: Gives the "just scan" verifier a good experience. When the QR is scanned, the verifier doesnt see code, they see the VC rendered and verified. It should also be possible for the recipient to say "i don't trust your verifier, I'll choose my own" but the verifier they choose will need to know how to process he URL string in the QR to ignore the hosted verifier and just grab the VC.
• cons: PDF data is still totally decoupled from structured data so the same real QR on fake document attack is possible. Imposes a little more complexity on hosted verifiers to know how to parse a component verifierURL?VC-URL structure.

3. single document, hosted verifier. In this case the issuer creates a digital credential only and the credential has built-in rendering information. The issuer sends only the link to any consumer (as a URL and/or a QR). When clicking the link or scanning the QR, the recipient sees a human rendered and verified version because the link is of the Verifier-URL?VC-URL pattern. The rendered version has a "print" button in case they want a paper copy for records.

• pros: no separation of data so there's no way to put real QRs on fake documents- there's just one source of truth. A human verifier sees a printable, verified document. A machine verifier can pull the VC and do it's own verification, ignoring the hosted verifier.
• cons: requires a change in human behaviour from sending PDFs to sending links. Issuers may feel that their customers will be annoyed at the need to click, view and print/save rather than just save the PDF. Also there's a risk that if the hosted verifier is down, the invoice link is unusable.

4. Some hybrid. For example, try to gradually set human understanding and expectations but putting two QRs on a PDF. One is a link to the VC and the other is a link to a verifier. There is wording that trains users about their options. Use the hosted verifier than verify the invoice, or pick your own verifier then verify the invoice. In either case trust the results from the verifier not what you see printed on this page.

My experience so far in this ecosystem is that all kinds of technical options are easy. What is really hard is changing behaviour and conveying understanding of risks. So, at least for me, a design approach that not only achieves the outcome but, as it does so, raises awareness about how verifiable documents work, is likely the best one.