Re: [PROPOSED WORK ITEM] Vaccination Certificate Vocabulary

+Justin, Vitor, Ramesh (PathCheck)

@Tobias - Great to chat with you and Vitor yesterday on collaboration with the PathCheck paper-creds QR codes.  We think it is a great idea to coordinate on the vocabulary for implementations and experiments with QR code implementations, and have shared the link to the repository with the team.  We really thought your ideas for issuing digital from paper are very interesting and look forward to collaborate with you on a proof of concept in the next week or two.

@Chris - Thank you for sharing your research on QR codes, it has also been shared with the team.  We would love your thoughts on the implementation as specified up to this point. Various tradeoffs have been made for ease of implementation, speed distribution, durability, compact size, and human readability.

In this video, at 21 minutes in, Justin gives a talk about the technical challenges and design: https://www.youtube.com/watch?v=9Tx8LH7Mp18&t=0s
The GitHub can be found here https://github.com/Path-Check/paper-cred and we welcome input, feedback, and collaboration,

thank you!

Tony
On Feb 16, 2021, 1:51 PM -0800, Christopher Allen <ChristopherA@lifewithalacrity.com>, wrote:
> On Tue, Feb 16, 2021 at 12:56 PM Kaliya IDwoman <kaliya-id@identitywoman.net> wrote:
> > > Another really big question arising out of the WHO conversations is how to represent VCs on paper. I'm working furiously in my role as Ecosystems Director at CCI to try and connect the key folks who have been working on innovations on paper based VCs to be in dialogue with one another to come up with some clear answers about how this can be done in the most compact format.
> >
> > Even if you don't use our exact UR specification, you may benefit by looking at them. The final spec was designed to be optimal for both standard QRs as well as animated QRs and to take full advantage of the native QR compression that all QRs support. For us, this meant encoding the VC first in CBOR binary, then using a special subset of characters in UPPERCASE that QR libraries will compress rather than double in size because they think the data is binary when it is not (which is what happens when you use JSON or base64). This took a lot of time and missteps to optimize for size as the QRs specs are complicated and you can get weird results when even a single character is misused.
> >
> > Here is the research on the QR encoding issues: https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-003-uri-binary-compatibility.md, our final selection of characters for encoding (see the Brutal encoding section) https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md and more about the overall spec for encoding some cryptographic primitives at https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md. Other related research is in that repo. Goal is at some point to turn these from research into formal specifications for IETF or W3C, but no specific roadmap for that goal at this time.
> >
> > There is a multiframe format for QRs for up to 16 frames, however, we found that though it is in the QR spec, it broke in many QR code libraries used by common platforms. So we created another multi-QR approach we call Animated URs.
> > Though it doesn't directly serve your specific needs for VCs on paper, if the QRs get too large you can use our Animated UR format to print multiple QRs on the same page. We don't have an example of these in our demo, but the key point is each could be scanned out of order and still function — there is nothing in our spec that prevents you from printing each frame on paper. See our animated UR QR demo video at: https://www.youtube.com/watch?v=t-GGZ9FyuT8
> >
> > I hope this is helpful in your research for implementing VCs on paper.
> >
> > -- Christopher Allen, Blockchain Commons
> >
> >
> >
> >