Re: [EXTERNAL] [jfraichot@learningmachine.com] Re: VC API: handling large documents client to server

On 2/10/22 2:30 PM, Nikos Fotiou wrote:
> Can you please provide some more information about why “base64url encoding
> is a major problem for signatures over complex data”. At least to me, it is
> not obvious.

By default, base64 encoding in JWTs leads to 133% message size increase when
the JWT is sent over a network connection and when being stored in a database.

This is because HTTP uses gzip/deflate compression by default, except that
when base64 is used, the compression algorithm goes into a "worst case" mode
and it results in the opposite of what you want to happen (duplication of
data, not compression).

This means that exchanging base64 data across HTTP takes 1.33x more space, and
storing it takes 1.33x more storage than a clear-text JSON representation.
While this might not sound like a lot, it adds up when you're doing tens of
millions of these sorts of transfers/storage a day.

This article explains why:

https://stackoverflow.com/questions/38124361/why-does-base64-encoded-data-compress-so-poorly

The problem gets even worse when you have to chain signatures together,
storage requirements start multiplying in the wrong direction.

I will note that JSON-LD encoded and Data Integrity protected Verifiable
Credentials don't suffer from this problem (except for where they use base64
to encode an image) and take advantage of standard HTTP compression available
today. Due to JSON-LD's semantics, it is possible to do the appropriate
(efficient) binary conversion when you go to the wire or to disk.

As Orie mentioned, there could be fixes for this that the original proponents
of JWS did not include:

https://mailarchive.ietf.org/arch/msg/jose/l2e0SCf57V-9s2HWG-sJRhXV23I/

... and even though it's defined for JWE, most JWT libraries don't support any
sort of feature in an interoperable way:

https://github.com/dvsekhvalnov/jose2go/issues/25#issuecomment-539958151

... and (depending on how it's implemented) the VC-JWT2 stuff is probably not
going to be backwards compatible OR is going to be specific to VC-JWT even if
it is backwards compatible... not that that's a big deal because until
recently, there wasn't a good test suite for VC-JWT and so there was no such
thing as provable interop for VC-JWT.

All that said, this is a curiosity that many developers don't care about. They
either don't know (most developers), or if they know, they just pay the 133%
over original size penalty and move on because they're more concerned about
"other more pertinent to them" things in their system.

-- 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/

Received on Thursday, 10 February 2022 20:07:21 UTC