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 include 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.

The trust model is similar to how ICAO e-Passports work.

The following diagram depicts the Mobile Credentials 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 that is used to sign Document Signer Certificates (DSCs).

  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).

  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. It is a X.509 certificate used to sign Mobile Security Objects (MSOs).

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

  To sign Mobile Credentials, 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. Note that a Mobile Credential expiry date cannot be later than that of the DSC used to sign it.

• Both the DSC and the MSO are included in an issued Mobile Credential.

  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. 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:

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.

What’s Next?

You should now have a good understanding of the key concepts and technologies that are used by Mobile Credentials. In the next section we will review what communication protocols are used when Mobile Credentials are presented to verifiers.