- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 10 Feb 2022 15:07:00 -0500
- To: Nikos Fotiou <fotiou@aueb.gr>, 'Orie Steele' <orie@transmute.industries>, 'Julien Fraichot' <Julien.Fraichot@hyland.com>
- Cc: 'Mike Prorock' <mprorock@mesur.io>, 'W3C Credentials CG' <public-credentials@w3.org>
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