W3C home > Mailing lists > Public > public-credentials@w3.org > February 2022

Re: Recommendations for Storing VC-JWT

From: Mike Prorock <mprorock@mesur.io>
Date: Tue, 22 Feb 2022 11:52:10 -0500
Message-ID: <CAGJKSNT2maQYsje8xcd=aoeem5o3Fz1PLVw-JTkRfKpfBki5PQ@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C Credentials CG <public-credentials@w3.org>
I think you are pointing out the right concerns that I share with a
dencode, store, reencode approach only.  For our side right now we are
going down a path that links the data via a relationship off a UUID, but
splits the encoded data and stores that separately from the un-encoded
"data" proper for analysis and other operations.  Don't see a good way
around that given the variety of things that can pop in seemingly out of
nowhere that would prevent proper verification of that data's integrity.
Note, that this is for JWT stuff only.

Mike Prorock
CTO, Founder

On Tue, Feb 22, 2022 at 11:41 AM Manu Sporny <msporny@digitalbazaar.com>

> On 2/22/22 10:29 AM, Orie Steele wrote:
> > This assumes that the data store will not tamper with the JSON member
> > order
> Your solution will fail when:
> * The signed data in the JWT contains blank space or
>   padding of any kind.
> * There is a part of your application pipeline that does
>   not enforce field ordering. For example,
>   JSON.stringify() that one of your developers injected in
>   your code base because they didn't know about the field
>   ordering requirement.
> * The language you're using, such as a Python dictionary,
>   does not enforce JSON member ordering.
> * The document storage solution does not preserve JSON
>   member order. MongoDB doesn't under certain
>   conditions[1]. CouchDB doesn't unless you're really
>   careful[2]. You will find that as you are exposed to
>   more document-based storage solutions, each have
>   idiosyncrasies that result in JSON member ordering
>   not being preserved at some layer of the stack or in
>   some corner case that won't bite you until your system
>   is in production.
> > This is how we handle VC-JWT in the VC-API today.
> How are you dealing with spaces in the JWT? If you are not taking that into
> consideration, your implementation is broken. If you are canonicalizing in
> some way, you are not compliant with VC-JWT.
> Depending on JSON member ordering in a multi-layered system is a known
> anti-pattern and a foot gun: don't do it.
> Again, this is why the Data Integrity work utilizes canonicalization and
> why
> VC-JWTs non-use of canonicalization leads to misguided solutions (that seem
> like they should work, but don't) like the above.
> -- 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 Tuesday, 22 February 2022 16:53:36 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:28 UTC