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.

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.

Chain of trust and RP Aggregators

The RICAL trust model is deliberately shallow at the point of distribution. The RICAL provider only needs to add each Reader Root Certificate to the RICAL. Holder applications (wallets) then validate that a signed presentation request chains back to one of those trusted Reader Root Certificates present in the list. Everything below the root can change without ever touching the RICAL that wallets have already consumed.

This is what makes the model operationally effective at scale. Rather than adding every individual relying party to the RICAL directly, the RICAL provider can trust a smaller set of RP Aggregators. An aggregator handles the onboarding of individual relying parties on the RICAL provider's behalf, and signs each relying party's intermediate certificate using a root that is already stored in the RICAL.

The practical benefit is that the RICAL does not need to be redistributed every time a new relying party joins the ecosystem. Adding a relying party is a signing operation performed by the aggregator, not a change to the trust list itself. The RICAL provider therefore avoids the cost of constantly pushing new root certificates and re-publishing the RICAL to potentially millions of wallet applications.

Holders retain full traceability throughout. Because each intermediate certificate is signed using a root that the wallet can find in the RICAL, a holder can always trace an incoming request back to a trusted root, even for a relying party that was onboarded after the wallet last consumed the list.

Relying party identity metadata

We recommend requiring relying party identity metadata to be shared with holder applications, so key information about the requestor can be surfaced to the end user, such as their name and logo.

Presenting a recognizable name and logo directly enhances the user experience and increases the holder's trust in a request. Instead of being asked to release data to an opaque identifier, the holder sees who is actually asking and can make an informed consent decision.

The recommended metadata schema is based on Google's existing implementation guidelines:

RelyingPartyMetadata = {
  "schema_version" : tstr,
  "display" : DisplayInfo,
  ? "aggregator_info" : DisplayInfo
}

DisplayInfo = {
  "display_name" : tstr,
  "logo_uri" : tstr,
  ? "privacy_policy_uri" : tstr
}

Our detailed recommendations for relying party identity metadata are:

• It must be added by value to the end-entity (leaf) Reader Authority Certificate that signs the request, so it is incorporated into presentation requests and holder applications do not need to fetch it separately when receiving a request.
• It must be CBOR-based for better compatibility with X.509 certificates.
• It should be treated as a custom OID extension allocated by the RICAL provider.
• RP Aggregator identity metadata can optionally be included as well.

Authorized purposes

To convey which request purposes each relying party is authorized to use, we recommend supporting an attenuated delegation model. Under this model, the RICAL provider delegates a set of authorized purposes to the Reader Root Certificate. Holder applications can then validate that:

1. The presentation request includes a declared purpose.
2. That declared purpose is authorized by the end-entity (leaf) certificate, and remains within the scope delegated by each certificate in the chain, back to the trusted Reader Root Certificate listed in the RICAL.

The defining property of attenuated delegation is that authority can only stay the same or narrow as it is delegated downstream. A certificate can never grant a purpose to the certificate below it that it was not itself granted. This improves the security and privacy of the solution by cryptographically binding every request to a purpose that has been explicitly authorized end to end, which prevents a relying party from requesting data for a use case it was never approved for. It also improves the RICAL provider's governance capabilities, because the set of purposes each participant may use is expressed and enforced through the certificate chain itself rather than through out-of-band agreements.

Technical format

From a technical point of view, we recommend using the emerging Authorized Purposes schema from draft revisions of ISO/IEC 18013-5, so the approach remains broadly standards-aligned and future-proofed. The schema is made up of two main components:

• Purpose Controller: Identifies the authority that manages the purpose taxonomy and policy definitions behind each purpose code. It is displayed in a reverse namespace format, such as org.example.rical.purposes.
• Purpose Code: Each authorized purpose is represented by a code, which maps to a definition maintained by the Purpose Controller.

AuthorizedPurposes = {       ; purpose codes grouped by controller
  + PurposeControllerId => [+ PurposeCode]
}

For example, the following authorizes three purpose codes managed by a single controller:

AuthorizedPurposes = {
  "org.example.rical.purposes" : [1, 2, 3]
}

Relying parties and holder application providers can then refer to separate policy documentation managed by the Purpose Controller to understand the definitions and policy requirements behind each purpose code.

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.