On 22/02/2022 16:52, Mike Prorock wrote:
I think you are pointing out the right concerns that I share with a dencode, store, reencode approach only.

And nobody would seriously consider doing that for a JWT. The JWT is fine just as received. So store it as is, and retrieve it as is in order to forward it to the verifier

Kind regards


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> wrote:
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)