Applying "Detached" JWS Signatures to PaymentRequest

[cyberphone]

Assume you have PaymentRequest object like the following:

{
  supportedMethods: "https://example.com/bobpay",
  data: {
     merchantIdentifier: "XXXX",
     bobPaySpecificField: true
  }
}

If such data needs to be signed, there is currently no standardized method for signing JSON data except through Base64Url-encoding the entire object which is in conflict with the API concept.

It would be cool adding an element containing a detached JWS signature like this:

{
  supportedMethods: "https://example.com/bobpay",
  data: {
     merchantIdentifier: "XXXX",
     bobPaySpecificField: true,
     signature: "eyJ0eXAiOiJKV1QiLA0KIC.S9pc19yb290Ijp0cnVlfQ.VP-mB92K1p1r_wWWFOEjXk"
  }
}

Unfortunately that doesn't really work because the order of JSON properties is undefined.

However, a recently published (draft) specification can be used as a bridge between detached JWS and clear text JSON/JavaScript data:

1. Apply https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-00 to a JSON-serialized version of the object to be signed
2. Apply https://tools.ietf.org/html/rfc7515#appendix-F to the result of the above operation
3. Add the resulting compact JWS to the original object through a new property like the sample's signature

https://github.com/cyberphone/json-canonicalization#json-canonicalization

[marcoscaceres]

Unfortunately that doesn't really work because the order of JSON properties is undefined.

All browsers respect order of properties. Authors depend heavily on having the order of those properties be in order and it would be "web breaking" to consider them as unordered.

[marcoscaceres]

To be clear, if the bug is "order of JSON properties is undefined", and given that there is agreement in browsers that order is actually respected, then the ECMAScript spec should be updated, but doesn't affect Payment Request (which is why I'm closing this issue).

[cyberphone]

@marcoscaceres I think you were a bit hot on the trigger here 😂.
The Creator of the signature would not be a browser and is thus affected by JSON property (un)order.

Imagine a PaymentHandler scenario. The browser can't do much with the signature since the key used to sign with, hardly is known by the browser. I.e. the bank/PSP (which also isn't a browser), would be the most likely Verifier.

By relying on platform independent canonincalization you are free defining where a signature is created and verifed. For PaymentRequest there may be quite a bunch of different scenarios.

Anyway, where is the pointer to "the better" solution?

[marcoscaceres]

The Creator of the signature would not be a browser and is thus affected by JSON property (un)order.

Do any JSON implementations not respect the order? if so, exactly which?

[cyberphone]

Believe it or not, essentially none do because the JSON specification (unlike ECMAScript's specific take on JSON), says that the order of properties indeed is unspecified. That and a few other things is the rationale for the I-D.

[marcoscaceres]

ok, but this is still a bug in JSON spec, no? Seems the first step would be to fix the JSON spec to match browsers and developer expectation.

[cyberphone]

Well, it is has been like that since the inception of JSON. Changing it would be a major deal since many JSON systems (including Java and C#) rely on reflection which also enumerates properties in an unspecified order.

I agree that it is strange that if you declare the objects A,B,C, they are typically serialized as A,C,B. Canonicalization is fortunately a simple process both to implement and apply.

I don't think you will find many programs that actually rely on JSON property order. A JSON guru would say "that's a bug" 😂

[marcoscaceres]

Well, it is has been like that since the inception of JSON. Changing it would be a major deal since many JSON systems (including Java and C#) rely on reflection which also enumerates properties in an unspecified order.

Browser vendor bias here, but totally 🤷🏽‍♂️.

I agree that it is strange that if you declare the objects A,B,C, they are typically serialized as A,C,B. Canonicalization is fortunately a simple process both to implement and apply.

Ok, but the above is basically an argument for getting it fixed. Obviously, legacy systems would need to be updated, but the change would be backwards compatible.

[cyberphone]

It will not happen because the cost is huge and the need is not that big. The IETF JSON WG wouldn't accept such a proposal.

[cyberphone]

As an example the Payment Request API does not depend on property order. Only a few and pretty marginal systems do. In those cases people have done special tricks like using "printf" to generate JSON.

[stpeter]

@cyberphone wrote:

It will not happen because the cost is huge and the need is not that big. The IETF JSON WG wouldn't accept such a proposal.

I'm confused. It seems that we (you) can't convince the appropriate working group to solve the problem, therefore we (you) feel the need to define workarounds everywhere downstream from the right place to solve the problem. That doesn't strike me as an effective or efficient approach. Am I missing something?

[cyberphone]

Hi @stpeter @marcoscaceres! A peek in the reference may be of some use: https://tools.ietf.org/html/rfc7159#section-1

   An object is an unordered collection of zero or more name/value
   pairs, where a name is a string and a value is a string, number,
   boolean, null, object, or array

I wouldn't characterize the (fully implemented) proposal as a "workaround", but rather an attempt creating something useful without "boiling the ocean". Since JSON doesn't even separate integers and floating point numbers, it seems that a better alternative would be CBOR but then you browser guys would get a lot of new work which also isn't an option, right?

I have found that JSON (and JavaScript) can do [almost] everything you want although it sometimes looks a bit on the ugly side.

[cyberphone]

There is actually a current and "similar" proposal with Microsoft as well as me as authors, building on ECMASrcript property order: https://tools.ietf.org/id/draft-erdtman-jose-cleartext-jws-00.html

After having checked with major tool vendors as well as getting negative feedback in the JSON WG, I changed my mind and turned to canonicalization which doesn't have to be natively supported in parsers and serializers to work.

Less than 30kb: https://github.com/cyberphone/json-canonicalization/tree/master/java/canonicalizer#json-canonicalizer-for-java

[cyberphone]

You may now try it. It takes seconds.
https://mobilepki.org/jws-jcs/home