Re: VC API: handling large documents client to server

+1 manu - great notes - I will note from our side that we utilize hashlink
(and related approaches) when dealing with larger binary data that needs to
be referenced in a credential - e.g. image of a product, etc.

Mike Prorock
CTO, Founder
https://mesur.io/



On Thu, Feb 10, 2022 at 9:39 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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://datatracker.ietf.org/doc/html/draft-sporny-hashlink
>
> > 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://stackoverflow.com/questions/38124361/why-does-base64-encoded-data-compress-so-poorly
>
> 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://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>