Verified Issuer Certificate Authority List (VICAL)

A VICAL (Verified Issuer Certificate Authority List) is a mechanism defined in the ISO/IEC 18013-5 standard to support establishing trust in digital ecosystems where relying parties need to verify mDocs issued by numerous different issuers.

For example, consider the case of relying parties that need to verify Mobile Driver’s Licenses (mDLs). Different states and/or provinces can issue their own mDLs, each signed by a Document Signer Certificate (DSC) that is itself signed by the state/province unique Issuing Authority Certificate Authority (IACA).

If you’re someone who needs to verify these mDLs (like a police officer or a business verifying identities), you would have to individually assess and trust each state/province IACA. This can become complicated, especially as the number of issuers grows, because you’d have to create and manage a lot of different trust relationships.

A VICAL solves this by collecting and validating IACAs from different issuing authorities, and then cryptographically signing them into a single list. Each IACA in the VICAL is associated with:

• An issuing authority that can use this IACA as the root certificate when signing mDocs.
• Credential types for which this IACA can serve as a root certificate.

When a relying party trusts a VICAL they can trust any presented mDoc, given that:

• The credential was issued by an issuing authority that is included in the VICAL.
• The root certificate (IACA) of the chain of certificates used to sign the credential matches the IACA that is associated with this issuing authority in the VICAL.
• The credential type matches one of the credential types associated with this IACA in the VICAL.

This mechanism enables relying parties to verify mDocs (such as mDLs) from any issuing authority included in the VICAL without managing multiple separate trust relationships with each issuing authority. This can greatly simplify the process of verifying mDocs in complex ecosystems, such as verifying mDLs across various jurisdictions.

A VICAL can be considered a standardised approach to creating a Digital Trust Service (DTS).

VICAL roles

• VICAL Provider: Operates the VICAL and provides it as a service to different ecosystem participants. The VICAL provider collects and validates information from relevant issuers, compiles it into a standardised VICAL format and distributes it to relying parties.
• Issuers: Issue mDocs to holders while attesting the validity of claims included in these credentials.
• Relying parties: Consume the VICAL and use issuers’ information to verify presented mDocs.

VICAL components

• VICAL metadata: This includes general information about the VICAL itself:
  • Version.
  • Provider.
  • Issuance date.
  • Unique identifier.
  • Next update.
• VICAL records: Each record includes the following information that can be used by relying parties to establish trust in mDocs and the IACAs that are used as their root certificate:
  • A trusted IACA that can be used as a root certificate to sign mDocs.
  • Issuing authority that can issue mDocs with this IACA.
  • Credential types that this IACA can serve as a root certificate for, indicated by the docType property. Each VICAL record associates an IACA with a single docType. If the same IACA is used as the root certificate for more than one docType, each of these IACA-docType relationships would require a separate VICAL record.
  • Additional IACA information:
    • Validity period.
    • Unique identifier.
    • State/Province.
    • Country.
    • Public key info (algorithm, curve and value).
    • Signature info (algorithm and value).
    • Fingerprints.
    • Extensions used.

How it works

1. The VICAL provider establishes its own root certificate with an associated Public Key Infrastructure (PKI) chain of certificates, based on the chain of trust model.

2. The VICAL provider collects and validates IACAs from different issuing authorities. Each of these IACAs are vetted by the VICAL provider and trusted to issue mDocs of specific credential types.

3. The VICAL provider uses their chain of trust end-entity certificate to sign the valid IACAs into a single list.

4. Each issuing authority uses their own IACA and associated PKI chain of certificates to sign mDocs.

5. Relying parties can consume the VICAL in one of two ways:

   • Download the VICAL directly from the provider’s website.
   • Retrieve the VICAL via an endpoint exposed by the provider as an API.

6. When a relying party attempts to verify an mDoc, they validate its signature and referenced PKI certificate chain against the VICAL to ensure:

   • This issuing authority can use this IACA as a root certificate when signing mDocs.
   • This credential type can use this IACA as a root certificate.

7. Upon successful validation, the relying party can verify the presented mDoc without having to create and manage a trust relationship directly with its issuing authority directly.

Additional resources

MATTR Labs tools