light-mode-image
Learn

Overview

Introduction

A RICAL (Reader Identity Certificate Authority List) is a mechanism defined in ISO/IEC 18013-5 Annex F to support establishing trust in digital ecosystems where holders need to verify the identity of relying parties (verifiers) requesting data from their mDocs.

ISO/IEC 18013-5 uses the term reader for the entity that requests data from an mDoc. Throughout this documentation we use verifier or relying party for the same role. Certificate names defined by the standard (for example, Reader Root Certificate and Reader Authority Certificate) keep their ISO terminology.

It is the counterpart to a VICAL: where a VICAL lets relying parties consume issuer trust information from a single authoritative source, a RICAL lets holder applications (wallets) consume verifier trust information in the same centralized way.

For example, consider the case of a holder presenting a Mobile Driver's License (mDL) to a verifier. Different relying parties (law enforcement agencies, age verification services, financial institutions) each operate their own Reader Authority Certificates. Without a RICAL, every wallet would have to individually assess and trust each verifier's root certificate, which becomes impractical as the number of verifiers in an ecosystem grows.

A RICAL solves this by collecting and validating Reader Root Certificates from different relying parties, and then cryptographically signing them into a single list. When a wallet trusts a RICAL, it can trust any verifier whose certificate chain anchors to a root included in the RICAL, without maintaining a direct trust relationship with each individual verifier.

RICAL roles

  • RICAL Provider: Operates the RICAL and provides it as a service to ecosystem participants. The RICAL provider collects and validates Reader Root Certificates from relying parties, compiles them into a standardized RICAL format and distributes the result to holders.
  • Relying parties (verifiers): Request data from mDocs and present their verifier certificate so holders can authenticate them.
  • Holders (Wallets): Consume the RICAL and use verifier information to verify the identity of relying parties before releasing data.

RICAL components

  • RICAL metadata: General information about the RICAL itself:
    • Version.
    • Provider.
    • Issuance date.
    • Unique identifier.
  • RICAL records: Each record carries the information a wallet needs to establish trust in a verifier's certificate chain:
    • The DER-encoded trusted Reader Root Certificate.
    • The certificate serial number.
    • The Subject Key Identifier (SKI).
    • The issuing country and (where applicable) state or province name.
    • The DER-encoded issuer and subject distinguished names.
    • The certificate validity period (notBefore and notAfter).

Unlike a VICAL, a RICAL record does not include a docType array. A trusted Reader Root Certificate in a RICAL is treated as authoritative for the ecosystem rather than scoped to specific credential types. Authorization of which data a verifier may request is conveyed separately through the verifier's signed request and the holder's consent flow, not through the trust list itself.

RICAL structure

The decoded RICAL payload is structurally similar to a VICAL, but each record describes a trusted Reader Root Certificate rather than an issuer, and there is no per-record docType array:

RICAL = {
  "version" : tstr,                 ; RICAL structure version, currently "1.0"
  "provider" : tstr,                ; Identifies the RICAL provider
  "date" : tdate,                   ; date-time of RICAL issuance
  "id" : uint,                      ; Uniquely identifies this specific issue of the RICAL
  "type" : tstr,                    ; RICAL type, currently "reader"
  "certificateInfos" : [+ {
    "certificate" : bstr,           ; DER-encoded X.509 certificate
    "serialNumber" : biguint,       ; Serial number of the certificate
    "ski" : bstr,                   ; Subject Key Identifier
    "issuingCountry" : tstr,        ; ISO 3166-1 alpha-2 country code
    "stateOrProvinceName" : tstr,   ; State or province (sub-national issuers)
    "issuer" : bstr,                ; DER-encoded issuer distinguished name
    "subject" : bstr,               ; DER-encoded subject distinguished name
    "notBefore" : tdate,            ; Certificate validity start
    "notAfter" : tdate              ; Certificate validity end
  }]
}

How it works

  1. The RICAL 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 RICAL provider collects and validates Reader Root Certificates from different relying parties. Each of these roots is vetted by the RICAL provider before inclusion.
  3. The RICAL provider uses their chain of trust end-entity certificate to sign the validated Reader Root Certificates into a single list.
  4. Each relying party uses their own Reader Authority Certificate (and the associated PKI chain) to sign verifier requests.
  5. Holders can consume the RICAL in one of two ways:
    • Download the RICAL directly from the provider's website.
    • Retrieve the RICAL via an endpoint exposed by the provider as an API.
  6. When a holder receives a request from a verifier, the wallet validates the verifier's signature and referenced PKI certificate chain against the RICAL to ensure that the chain anchors to a trusted Reader Root Certificate present in the list.
  7. Upon successful validation, the wallet can confidently authenticate the relying party without maintaining an individual trust relationship with each verifier.

Linked certificates

A linked certificate lets a participant rotate the Reader Root Certificate they use in the ecosystem without breaking trust for holder applications (wallets) that already trust the previous certificate. When you add a new certificate for a participant, you can add it as a successor to a previously uploaded certificate by selecting the predecessor and uploading a link certificate that ties the new certificate to the previous one.

This preserves trust continuity for the participant across the rotation, so wallets can continue to authenticate the verifier without first having to consume an updated RICAL.

To add a linked certificate, refer to the RICAL guide.

Next steps

  • Follow the RICAL guide to set up a RICAL and publish a list of trusted Reader Root Certificates, using either the Portal or the MATTR VII API.
  • Refer to the RICAL consumption guide to learn how wallets can retrieve, validate and use a published RICAL.

How would you rate this page?

Last updated on

On this page