Re: VC API: handling large documents client to server

The one downside with the approach of keeping stuff external is that it opens up a “phone home” attack (ala “tracking pixels”), enabling the issuer of the VC to obtain information anyone accessing it – which many consider a security/privacy problem.   It’s one reason we have focused on embedding as much information into our C2PA manifests – favoring self-containment over size considerations.

Leonard

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thursday, February 10, 2022 at 4:41 PM
To: public-credentials@w3.org <public-credentials@w3.org>
Subject: Re: VC API: handling large documents client to server
On 2/10/22 3:01 AM, Julien Fraichot wrote:
> Basically when calling a verification API from a (browser) client, there
> might be times where the documents could be quite large (few MBs). I am
> wondering if there are some strategies to reduce the payload that would
> also be standard when dealing with a VC API complying service?

If you have a VC that is several MB in size, I would expect it to struggle in
the ecosystem. Yes, they are legal, in the same way that attaching a 250MB
slide deck to an email is legal -- while the SMTP protocol allows for it, most
mail servers will reject the message as too large.

Typically, these large VCs happen because people are embedding base-encoded
images directly into a VC. Instead, VC creators should consider modelling
their data differently -- e.g., use a hashlink, or some other way of creating
a cryptographic hyperlink:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-sporny-hashlink&amp;data=04%7C01%7Clrosenth%40adobe.com%7Ca2492c0f35044fc40ef008d9eca32591%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637801008759634672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=OALgcIOZcG9fPlx4vUa3kXl5Zok7BldgyAEBlmOZuoM%3D&amp;reserved=0

> I am researching gzipping on the client and tried more exotic approaches to
> no avail, so I’d be willing to hear what the people have thought on the
> matter.

You get gzip compression during transmission (more or less) for free these
days, but that's not really going to save you given that you're probably
base-encoding the raw binary data. Quite counter-intuitively, doing that makes
using gzip expand the file size instead of reducing it:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F38124361%2Fwhy-does-base64-encoded-data-compress-so-poorly&amp;data=04%7C01%7Clrosenth%40adobe.com%7Ca2492c0f35044fc40ef008d9eca32591%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637801008759634672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=8WAzFVAK2y1yQ0l2%2BwHINbuZBluLbQtMAfoD5F9IM8c%3D&amp;reserved=0

This is another reason the JOSE/JWT stack, when used with VCs, harm wire-level
protocols -- everything is base64 encoded, and thus it effectively destroys
any ability to compress data on the wire.

Typical solutions to this problem require that you put the binary data outside
of the VC, if at all possible. This works well for common static images such
as logos. It is also possible to split the VC into two VCs... one with the
machine-readable data from the issuer (with a digital signature) and one with
the image data from any source (without a digital signature, since, if
hashlinked, the signature will verify the validity of the image data). That
latter approach can be more privacy preserving AND more complex than many
might feel is necessary.

Selective disclosure schemes (such as BBS+) are another way to deliver a
subset of the information to a verifier without having to send the image
payload data.

I expect this to be an active area of innovation for the next few years with a
few proposals on standard design patterns that all industries could use. This
problem appears most often with identification cards that have biometric
images embedded in them.

-- manu

--
Manu Sporny - https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&amp;data=04%7C01%7Clrosenth%40adobe.com%7Ca2492c0f35044fc40ef008d9eca32591%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637801008759634672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=dJNSXP7rr%2FHgiDFfLF%2BsSP7JHgHVCb4%2BS78toWMjhrY%3D&amp;reserved=0
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.digitalbazaar.com%2F&amp;data=04%7C01%7Clrosenth%40adobe.com%7Ca2492c0f35044fc40ef008d9eca32591%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637801008759634672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=UGX1Fd%2FP7etT%2Bc6oxSRMJ%2BaWeEKcw%2FCn5Ww%2BbixOYnw%3D&amp;reserved=0