Structure of a Digsig

Dynamic data structures using DigSig Definition Descriptors(DDDs)

Different applications will require different data fields to be stored inside their DigSigs. And every time a new field needs to be added to the data structure one shouldn’t have to re-design the whole structure. This is why the ISO/IEC 20248 specification describes a JSON based declarative language that can be used to describe the binary data structure of given DigSig. Not only does it describe the types of the fields, the order in which they appear, their sizes and how they should be collected; it also describes how they should be translated and formatted before being displayed to a user.

The following attributes can be natively described for any given field using the 20248 DDD language

The type of field, some examples include:
- string
- unsignedint
- boolean
- binary string (A binary string that is stored as is. Also known as a blob.)
- structures (A structure is a grouping of a field collection.)
- arrays of structures
How the field should be captured during the verification step, some examples include:
- How the field should be read from a specific databank of a RFID tag
- The field should be read from a separate barcode such as from an ID book
- The user should type in a value into the verifier to capture the field
Field optimisations
- Fields might have limitations such as the character limitations or length limitations. These parameters can be used to optimise the binary encoding
- Limiting the range of a number can optimise the field width required for it
Nullable fields

Encoding a DigSig

A DigSig is produced encoding given structured data using the rules as defined in a DDD document to produce a signed binary data structure. The signature found in this data structure is produced by a cryptographic module referred to as a signer.

Decoding a DigSig

A DigSig can be decoded by applying the rules found in the DDD document to decode the binary string from the Digsig. Once decoded, the signature field found inside the decoded data can be used to verify the authenticity and the integrity of the decoded data.

Since DDD documents are distributed along with the X.509 DigSig Certificate the decoding party has both the DDD and the public key at hand during the decoding phase

Data usage optimisations

In the domain of barcodes and RFID designers of data structures are often constrained by the data they can store in their selected carrier.

Barcodes need to be as small as possible to preserve the aesthetics of the document they are printed on
RFID carriers are usually limited in space, especially the EPC memory banks

To get around these types of constraints ISO/IEC 20248 proposes a couple of strategies to optimise the data that actually need to be stored in the DigSig.

Only store values in your carrier

X.509 digital certificates mostly contains information about a signer or encrypting party, but these certificates can also act as a carrier to include additional information. If we embed information about your DigSig fields (the DDD) into the DigSig Certificate then we don’t have to include them in the DigSig.

Data type intelligence

Using the wrong data serialisation technique your system can waste a lot of space which is unacceptable for smaller carriers.

For example, consider the following JSON:

{
  "passed_the_test": true
}

The json above describes only a single field and its value. If we were to minimise this JSON and store it using traditional ASCII encoding then the result would be as follows.

Encoded as ASCII:

{"passed_the_test":true}

Binary encoding (192 bits)

01111011001000100111000001100001011100110111001101100101011
00100010111110111010001101000011001010101111101110100011001
01011100110111010000100010001110100111010001110010011101010
110010101111101

But by using the ISO/IEC 20248 DDD language we break the data up into two parts. The data descriptor part and the value part.

Data descriptor part

{
  "fieldid":"passed_the_test"
  "type": boolean
}

Value part

true

If we only have to store the value in our medium, and distribute the descriptor by other means, then we can use a single bit to encode the binary value.

Binary encoding of only the value (1 bit)

So by breaking up the data descriptor and the value we can optimise space requirements of the values stored in DigSigs.

Limiting data ranges

When designing a data structure for a barcode it is important that we design it in such a way so that we use as little storage space as possible. This section compares traditional string encoding with DigSig string encoding strategies.

Traditional string encoding strategies such as ASCII assumes that every character of the string is encoded into exactly 8 bits, forming a “byte”. To store the string “HELLO WORLD” you will therefore need a minimum of 88 bits. The reason why ASCII encoding needs 8 bits per character is because it has support for an extended alphabet of 255 characters.

By limiting the alphabet for a particular field DigSig fields can optimally utilise all the bits available.

Encoding	Binary encoding
ASCII 8 bits per character	01001000 01000101 01001100 01001100 01001111 00100000 01010111 01001111 01010010 01001100 01000100 (88 bits)
ISO/IEC 20248 encoding Limiting alphabet to capital letters only (and space) variable length	1010110011100100010110101101 110110101011001110100010101100011 (61 bits)
Full alphabet { "fieldid": "thestring", "range": "[A-Z ]", "type": "string" }