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

Re: Recommendations for Storing VC-JWT

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 22 Feb 2022 11:38:45 -0500
To: public-credentials@w3.org
Message-ID: <2f250705-af61-a6d8-5972-f7e93e1ab29a@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)
Received on Tuesday, 22 February 2022 16:39:03 UTC

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