Re: Recommendations for Storing VC-JWT

On 2/22/22 11:52 AM, Mike Prorock wrote:
> Manu,
> 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.

Yes. What we've found at DB is that some form of "normalization" is
going to be necessary when you're dealing with complex, structured data
-- as opposed to simple user IDs or similar. The only question is
whether it gets pushed to the application developer such that they are
dealing with it in some form or another at many layers ... or it's
isolated around the crypto layer.

We have found that a decision to avoid normalization/canonicalization
around the crypto layer was a trade off -- that pushed it out of the low
level data integrity-related tools and into everything else.

My view is, for the complex, structured data use case, that
such a trade off leads to a failure to separate concerns and a failure
to properly prioritize constituencies. However, this kind of use case
may not have been the major target for the designers of standards where
this trade off was made. But an assumption that these systems should
"just work" for that use case seems to be off the mark. No one wants to
deal with normalization/canonicalization, but it's better to put it in
the corner than all over the room.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Tuesday, 22 February 2022 17:31:17 UTC