Re: Limitations when Storing VC-JWT (was: Re: Recommendations for Storing VC-JWT)

On 2/17/22 9:21 AM, Orie Steele wrote:
> It would seem the rational thing to do is:
> 
> 1. to store them decoded 2. store a decoded version next to the encoded
> version.

That means your best case scenario is 233% storage bloat when you use VC-JWTs.
It sounds like you're finally hitting a problem that we identified (and warned
against) years ago:

https://www.w3.org/TR/vc-imp-guide/#pf10b

This limitation is one of the (many) reasons Data Integrity (was Linked Data
Proofs/Signatures) was invented and is scheduled to be standardized in the VC
2.0 WG.

While a 233% storage cost might not sound like much, remember that
storing/processing VCs is the majority of what these systems we are building
are doing, and at scale, there is a big difference between a production
replicated/sharded database that's costing you $100K/month vs. $200K/month.
Storage is cheap, but it's not free. Moving twice as much data around is not
free. Ensuring that your JWT and your VC data is aligned is not free. These
are all costs that you pay when you use VC-JWTs that are not problems for VC's
protected via the Data Integrity spec.

VC-JWTs continue to be a terrible, half-baked solution for the use cases that
the various markets using Verifiable Credentials are dealing with:

https://www.w3.org/TR/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs

People seem to be gravitating towards the solution because it's easy to
implement (lots of tooling exists to output the format vs. the limited tooling
for the Data Integrity stuff).

I'll note that the same argument that people are using for why we should use
VC-JWT applies to why we should use X509 instead of DIDs. "There is so much
more tooling for x509, and the world knows how to use it and runs off of it
today! We don't need this new fangled DID stuff, it's such a waste of time
when the problem is already solved with DIDs!"

The reality is that all of these technologies have trade-offs. Using "off the
shelf" technologies that have existed for years is easier, but doing so
completely misses the point of why these newer technologies exist.

Now, I'm sure this email will be thoroughly unconvincing to those that want to
use VC-JWT. Digital Bazaar started using JWTs for the same reasons over 8+
years ago before very quickly discovering that the solution had severe
drawbacks when deployed at scale. If you use VC-JWTs, there is no way around
the challenge that Orie has identified in his opening email. My heart goes out
to those that will struggle with this, as we felt that pain years ago and then
kicked encoding VCs as JWTs to the curb because the cost was not worth it.

-- 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 Friday, 18 February 2022 14:48:50 UTC