DocsCredential formatsmDocsStandards and technology

Standards and technology

This page details the following mDocs concepts:

  • Underlying standards: This will help you understand where mDocs are positioned in relation to existing standards.
  • Foundational technologies: This will help you understand what technologies are being used to enable the core concepts of mDocs, and how they might interface with your existing ecosystem.

Underlying standards

The ISO/IEC 18013-5:2021 standard was created to standardise certain aspects in a Mobile Driver Licences (mDLs) ecosystem. It defines the interface for a mobile device to present an mDL to a verifier using a digital wallet in a close proximity scenario. This includes data structure and important security features enabling the verifier to validate the mDL.

The ISO/IEC 18013-7 technical specification was created to augment capabilities defined in the ISO/IEC 18013-5 standard, mainly by enabling the presentation of an mDL to a verifier on-line. This standard specifies two protocols to support online presentation of mDLs - Device retrieval messages and OpenID for Verifiable Presentations (OID4VP). MATTR mDocs implement the latter, which defines a mechanism on top of OAuth 2.0 to enable online verification of verifiable credentials, including mDLs.

The ISO/IEC TS 23220 standard series (currently under development) aims to generalise applications of this technology for more use cases, broadly referred to as Mobile Documents or mDocs. ISO/IEC TS 23220-4 is compatible with ISO/IEC 18013-5 while introducing additional capabilities such as web-flows.

MATTR mDocs have a generic format that can be presented with any claims and can be used in many scenarios - purchasing age-restricted items, opening bank accounts, renting or sharing cars, going through airport security, accessing secure locations and more.

Foundational technologies

Object representation

As mDocs verification workflows require compact data structures, Concise Binary Object Representation (CBOR) is the main format used to encode data structures in both the ISO/IEC 18013-5 and ISO/IEC TS 23220-4 standards.

CBOR is a binary data format designed to be interoperable with JSON while supporting more complex data types. Being binary, it offers more compact messages, and allows encoding data directly without converting it to a base64-encoded string first. In the context of mDocs, this is a big advantage over JSON, which is a less space efficient data encoding method.

Refer to CBOR.io to go deeper into CBOR.

Object signing and encryption

Personal information included in mDocs must be signed and encrypted to be tamper proof. CBOR Object Signing and Encryption (COSE) allows encrypting and singing CBOR data structures in the same way JSON data structures can be encrypted and signed by JavaScript Object Signing and Encryption (JOSE).

mDocs use COSE to sign CBOR data structures, verifying the validity of the signed credential by authenticating both the issuer and the device.

Hash functions

mDocs include different claims that are encrypted using Hash Functions. A hash is a cryptographic function that takes in data of any length, and creates a fixed length unique output, referred to as a Hash (also known as a Digest). The algorithm type indicates the fixed output length. For example, the SHA-256 algorithm generates 256 bits / 32 byte long hashes:

Hash function

Valid hash functions must meet the following requirements:

  • Collision resistant: Two distinct inputs must never result in the same hash.
  • One-way: A Hash cannot be used to decipher the original input.
  • Repeatable: The same data input should always generate the same output hash.

X.509 certificates

mDocs are high assurance identity credentials. Verifiers must be able to authenticate their issuers to enable digital trust workflows within the ecosystem.

X.509 certificates are a standardised format for digital certificates, fundamental to Public Key Infrastructure (PKI). Each certificate includes a public key and details about the certificate holder, binding this information to a specific identity. Public key validation and verification processes guarantee that the information in the certificate aligns with the claimed identity, maintaining the overall security and trustworthiness of the PKI infrastructure.

X.509 certificates commonly use certificate chains which encompass multiple layers of digital certificates to establish a chain of trust. The PKI hierarchy begins with a root certificate, acting as the highest authority that issues intermediate certificates, creating a chain of trust leading to end-entity certificates (such as mDocs). Certificate chain validation ensures the integrity of this hierarchy, confirming that each certificate in the chain is legitimate, signed by its issuer and has not been revoked.

In the context of mDocs, an Issuing Authority Certificate Authority (IACA) and a Document Signer Certificates (DSC) are both X.509 certificates. Refer to the Chain of trust sub-section for more information.