Chain of trust

Mobile Credentials are verified based on a chain of trust model. In this model, the Mobile Credential is linked to its issuer via a series of certificates, all of which must be validated for the Mobile Credential to be verified.

Chains of trust comprise three parts:

  • Root certificate: This digital certificate belongs to the issuing Certificate Authority (CA), and as its name implies, is at the root of the trust chain. Any certificate along the chain of trust must be linked to the root certificate.
  • Intermediate certificate: This digital certificate is linked to the root certificate and acts as an intermediary between the root certificates and the end-entities. A chain of trust must have at least one intermediate certificate.
  • End-entity: This is the final certificate that is being issued to holders and sent to verifiers when required. It is signed by an intermediate certificate.
This trust model is similar to how ICAO e-Passports work.

Mobile Credentials chain of trust

The following diagram depicts how Mobile Credentials implement the chain of trust model:

Chain of trust

Issuing Authority Certificate Authority (IACA)

The root certificate, operated by or on behalf of an issuing authority. The IACA is a X.509 certificate used to identify a Mobile Credential issuer and verify the Mobile Credentials they issue. An IACA is used to sign Document Signer Certificates (DSCs), which are then in turn used to sign Mobile Security Objects (MSO) in Mobile Credentials.

There can be only one IACA per MATTR VII tenant. The private key linked to the certificate is stored and managed in the highly secure and reliable Key Management System (KMS).

IACAs can be valid for up to 20 years.

Once an IACA is created on a MATTR VII tenant, it can be retrieved via an API request. This endpoint is publicly available by design, as it enables a relying party to use the IACA to verify a signed Mobile Credential. This endpoint can be obtained by querying the tenant's /.well-known/openid-credential-issuer endpoint and inspecting the mdoc_iacas_uri property in the response.

Each IACA includes the following elements:

  • Signature: As the IACA is the root certificate, it is self-signed and verified against its own public key also in the certificate.
  • Public key: Used to verify the IACA’s certificate signature, as well as the DSC signature.

Document Signer Certificate (DSC)

An intermediate certificate. The DSC is a X.509 certificate used to digitally sign Mobile Security Objects (MSOs) in Mobile Credentials. The DSC itself must be issued and signed by the root certificate, which is the Issuing Authority Certificate Authority (IACA).

A single MATTR VII tenant can have multiple DSCs. Different DSCs can have different validity periods and activation status.

To sign a Mobile Credential, a valid and active DSC must be used. If there are multiple valid and active DSCs on the tenant, the most recently created or modified one is used.

The DSC is included in the signed Mobile Credential, so a relying party only needs to retrieve the IACA to verify the credential.

Note that a Mobile Credential expiry date cannot be later than that of the DSC used to sign it.

Each DSC includes the following elements:

  • Signature: DSCs are signed by the IACA, and this signature is verified against the IACA’s public key.
  • Public key: Used to verify the MSO signature.

Mobile Security Object (MSO)

The end-entity. Mobile Credentials include an IssuerAuth data structure, as defined in the ISO/IEC 18013-5:2021 standard (opens in a new tab). It contains the MSO payload, which comprises metadata and salted hashed claims.

Each MSO includes the following elements:

  • Signature: MSOs are signed by the DSC. Their signature is checked against the DSC public key, and the DSC is validated all the way up to the IACA.
  • Public key: Used to verify the signature of the device the Mobile Credential was issued to, enabling device authentication.

Currently our APIs for both IACAs and DSCs only support the ECDSA with P-256 (ES256) algorithm. Contact us if you want to better understand the rationale for this choice.

Certificates Validity

The concept of certificates validity is of paramount importance in the context of Mobile Credentials. For a Mobile Credential to be verified, all the certificates within its chain of trust must be valid. If during the verifications process any of the certificates have expired, the Mobile Credential cannot be verified:

Certificate validity timeline

Careful analysis must be conducted before determining the certificates life cycle. IACAs are usually created with long expiry dates, some as long as 10-15 years. There are a variety of trade offs in making this duration longer or shorter.

Shorter expiration periods enable things like faster key rotation intervals and provide the opportunity to change the cryptographic algorithms being used if required.

On the other hand, short expiration periods come with increased deployment overhead. Whenever a new IACA is issued, the certificate must be distributed to all verifiers that verify Mobile Credentials from that issuer.

Consider the example of applying validity life cycles when issuing e-Passports:

  • In 2023, an e-Passport issuer creates a root certificate valid for 15 years (until 2038).
  • From 2023 to 2028, the issuer uses this root certificate to issue e-Passports valid for 10 years. Depending on their issuance date, these e-Passports will expire between 2033 and 2038 (an e-Passport issued in 2023 would expire in 2033, an e-Passport issued in 2024 would expire in 2034, etc.).
  • The latest e-Passport using the current root certificate is issued in 2028 and will expire at the same time the root certificate expires in 2038. This ensure that issued e-Passports are never found invalid due to an expired root certificate.
  • In 2028, the issuer creates a new root certificate valid for 15 years (until 2043) and uses it to issue e-Passports from 2028 to 2033. The previous root certificate will still be used to verify e-Passports issued between 2023 and 2028, but will no longer be used to issue new e-Passports.
  • The cycle will continue in the same manner, to ensure that new e-Passports never expire before their root certificate does. Note that this means that by design, there are always several root certificates valid and in use at the same time.

Understanding the unique needs and requirements of ecosystems is crucial to applying correct certificates validity periods.

Additional resources


API Reference