Manu,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
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.
On Tue, Feb 22, 2022 at 11:41 AM Manu Sporny <email@example.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
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
* 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. CouchDB doesn't unless you're really
careful. 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 Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)