Re: Recommendations for Storing VC-JWT

On Tue, Feb 22, 2022 at 10: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.
>

Seems like a good thing to discourage issuers from doing this.


>
> * 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.
>

I have postman integration tests that show this is safe with
JSON.stringify... but you are right, if a developer tampers with the order
this will break.


>
> * The language you're using, such as a Python dictionary,
>   does not enforce JSON member ordering.
>

https://medium.com/@ty0h/preserving-json-object-keys-order-in-javascript-python-and-go-language-170eaae0de03


>
> * 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.
>

https://medium.com/@ty0h/preserving-json-object-keys-order-in-javascript-python-and-go-language-170eaae0de03

I am certain that JSON member ordering will continue to be a problem in
production systems.

However, the alternatives seem worse... and this issue is more to do with
JSON than it is to do with JWTs.


>
> > 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.


Yes, this is a great point... what if the issuer injects a lot of white
space into their JWT, should we reward them for that?

No, let's punish them... ideally with additional normative restrictions in
VC-JWT :)

VCDM 2.0 can revise VC-JWT to address these issues, we don't need to keep
forwarding bad design decisions onto future generations.


> If you are canonicalizing in
> some way, you are not compliant with VC-JWT.


I don't think this is true, since JSON objects are inherently NOT ordered,
ordering them before signing is the prerogative of the issuer, and using
JCS instead of JSON.stringify is equally valid wrt a JWT... you just can't
rely on everyone to do it the same way...(unless a spec / profile says you
can) which is to say, its compliant, but it doesn't help you with
credentials from other issuers.

If you make it clear that order MUST be preserved if a decoded
representation is to be stored, AND that the original must not contain
whitespace, I think you have clearly communicated requirements for an
efficient solution... Since VC-JWT is a relatively new standard, these
requirements would seem to be both acceptable and advisable.

If these requirements can't be met, then the encoded token must be
preserved, and the storage cost will need to be borne due to the poor
decisions made at the time the credential was issued.


>
> Depending on JSON member ordering in a multi-layered system is a known
> anti-pattern and a foot gun: don't do it.
>

I sorta agree, but the alternatives still seem worse.


>
> 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.
>

alternatives to JWT are not a solution to this problem.


>
> -- 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/
>
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>
ᐧ