ISO20022 — JSON Schema [PART 4]

Background

In this article we will discuss aspects of the differences in JSON and XML Schema related to validation and security.

Please know i am not making a judgement on what is the right way. Just pointing out the obvious differences.

Blame and Guilt are different sides of the the same coin Judgement. I guess it does not help a healthy and open discussion.

This is the fourth article in a five part series

Part One

Part Two

Part Three

Part Four— This Article

Part Five

Schema

XML Schema

XML Schema is a well known and understood standard. There are tons of tutorials and tools like the one below:

See Link-1 below in references

There is an organisation which works on maintaining the XML and XML Schema standards, see link below:

See Link-2 below in references

Context of XML ISO20022

ISO20022 also has Message definitions on its website below:

See Link-3 below in references

JSON Schema [Experimental ?]

JSON Schema seems to not be a well defined Standard as of now.

Quoting From the “json-schema.org” website as of January 2021 :

“This book describes JSON Schema draft 7. Earlier versions of JSON Schema are not completely compatible with the format described here, but for the most part, those differences are noted in the text.”

See Link-4 below in references

On the W3C website we have something but again it looks experimental as of looking at it in January 2021 :

See Link-5 below in references

Canonical

XML Canonical

Canonicalisation is a way to make sure two XML that mean to have the same data are considered as same.

See below :

See Link-6 below in references

XML Canonical Example

Let’s look at the two addresses below

Person one

<Person>
<Name>Suchak Jani</Name>
<Address>108 Thouchstone Road, LightWorld, LovePlanet</Address>
</Person>

Person Two

<Person>
<Name>Suchak jani</Name >
<Address>108 Thouchstone Road, LightWorld, LovePlanet</Address >
</Person>

Are they the same XML ?

The </Name> tag has a space at the end in the second one </Name > and also the </Address> tag has a space at the end in the second one </Address >

But are they the same XML ?

For all practical purposes the machine reading them must consider the two as the same XML. This is important for XML Digesting and Signing. Both those XML’s will have the same digest as they would be cannonicalized first.

Context of ISO20022

There is a chance that there are unimportant spaces in the tags or end of lines, in ISO20022 XML files.

It is important to consider the business sense of the messages i.e. if they have the same relevant data - they are the same document regardless of unimportant spaces.

JSON Canonical

JSON does not have a definition of canonical

JSON Canonical Example

Let’s look at the two addresses below

Person one

{"Person" :
"Name" : "Suchak Jani"
"Address" : "108 Thouchstone Road, LightWorld, LovePlanet"
}

Person Two

{"Person" :
"Name"    : "Suchak Jani"
"Address" : "108 Thouchstone Road, LightWorld, LovePlanet"
}

Are they the same JSON ?

The “Name” key has extra spaces at the end in the second one.

But are they the same JSON ?

For all practical purposes the machine reading them, should consider the two as the same JSON. However if the JSON does not have a Canonicalization processing standard.

Signatures

XML Security details

For those interested in details of generating xml security please see these links :

See Link-7 and Link-8 below in references

XML Security Quick Overview

Here is the high level logical process for signing

XML document → Canonicalise the document → Generate HASH(SHA 512 for example) digest → Add “signed info” tag along with the hash digest → Sign the HASH with the “Sender” private key(RSA4096) → Add the generated “Signature” to the “signed info” tag → Add the “signed info” tag to the original xml

Here is the high level logical process for verification

Read the “signed info” tag from the incoming xml → Verify the “Signature” with the “Sender” public key and Hash (RSA4096)→Verify the XML HASH (SHA 512 for example) digest against the Canonicalised XML

JSON Security details

For those interested in details of generating JSON security please see these links :

Link-9 and Link-10 below in references

Two JSON Security Processes

There are two processes, Yay Choice !

Process 1: JSON “Compact Serialisation” Security Quick Overview

Format

The format looks like this:

[JOSE Header].[JWS Payload].[JWS Signature]

NOTE: All of the above is also Base64 encoded.

Serialisation

The process is as below:

Build a JSON Object with the three sections → In the header specify the correct algorithm and the public key used for signing → Base64 encode the header → Create the payload [can be JSON or NOT JSON !] → Base64 encode the payload → Compute the “signature” over the previous section → Base64 encode the “signature” → Join the three Base64 encoded sections by dots and you get the JWT

Process 1: JSON “JWS Serialisation” Security Quick Overview

Format

The format looks like this :

{
 "payload": "abcdef1",
 "signatures": [{
   "protected": "abcdef2",
   "header": {
    "kid": "abcdef3"
   },
   "signature": "abcdef4"
  },
  {
   "protected": "abcdef5",
   "header": {
    "kid": "abcdef6"
   },
   "signature": "abcdef7"
  },
 ]
}

NOTE:

1. All of the above is also Base64 encoded.
2. There can be many “signatures”

Serialisation

The process is as below:

Build a JSON Object with the all sections → Fill in the “payload” [can be JSON or NOT JSON !] → Build the JSON structure based on the number of intended signature → Base64 encode the “payload” → Fill in the “protected” for the first signature[This specifies the first algorithm] → Base64 encode the “protected” → Fill in the “kid” for the first signature[This specifies the first public key] → Base64 encode the “kid” → Sign the payload with the first key and fill in the “signature” → Continue like this with each of the signatures

Variations

There are some variations in the above process which are listed in the links above. But this page is just to get the general idea.

Conclusion [ISO20022 XML Schema vs JSON Schema]

Both XML and JSON themselves are mature technologies.

However as seen above here are the differences with respect to representing ISO20022 data represented in XML or JSON.

1. XML Schema is a well defined standard. JSON Schema is in the process
2. ISO20022 Message XML Schemas have been through a rigorous process of discussion and are well document and specified on the ISO20022 web site. JSON ISO2002 2Message Schemas have not been rigorous process of discussion and are not documented on the ISO20022 web site.
3. XML Security and JSON Security are both well defined standards. However as seen above, both are very different in how they approach Security.
4. XML Security includes removing spaces(Canonicalisation), to make two messages with the same business data, to be treated the the same way. JSON Security does away with this.

References

Link-1

XML Schema Tutorial

Link-2

XML Schema

Link-3

ISO 20022 Message Definitions | ISO20022

Link-4

Understanding JSON Schema — Understanding JSON Schema 7.0 documentation

Link-5

JSON Schema Version 0.0 Namespace

Link-6

XML Signature Syntax and Processing Version 1.1

Link-7

XML Signature Syntax and Processing Version 1.1

Link-8

XML Digital Signature API Specification (JSR 105)

Link-9

RFC 7515 — JSON Web Signature (JWS)

Link-10

JWT, JWS and JWE for Not So Dummies! (Part I)