- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 22 Feb 2022 11:38:45 -0500
- To: public-credentials@w3.org
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:39:03 UTC