The Office for Digital Identities and Attributes (OfDIA) is inviting digital verification service providers (DVSPs) to help test new infrastructure that will make the digital verification services (DVS) register machine-readable.
As the DVS market grows, it will become increasingly important for organisations to check that the services they use, rely on or connect with are on the register. Machine-readable infrastructure will make it easier to check the register securely and at scale.
Technical testing will cover two models. The API model supports secure data exchange through direct connections between services, relying parties and public authorities. The credential model supports the verification of credentials presented through digital wallets. This post explains how each model works.
You can find more detailed documentation about technical integration on GitHub.
How the two technical models workWhen organisations check the status of a service on the DVS register, the technical model they use will depend on the type of transaction taking place. We are building two models to support different transaction types.
API model: establishing direct connections between servicesThe API model supports transactions where one service connects directly to another service or organisation. For example, a DVSP might ask a public authority, such as DVLA, to validate an individual’s data. Before sharing data, the public authority needs to check that the service trying to connect is registered. X.509 certificates and the OpenID Federation specification will enable this.
Credential model: verifying issuers, verifiers and credentialsThe credential model supports transactions where an individual presents a credential from a digital wallet. For example, a customer might need to prove their age at a supermarket checkout. Before sharing the credential, the wallet needs to confirm that the reader service is a registered verifier. The reader service also needs to confirm that the credential came from a registered issuer. Two signed lists, called a VICAL (Verifier Identity Certificate Authority List) and a RICAL (Reader Identity Certificate Authority List), will enable this.
Using the new infrastructure Set up your service through the DVSP PortalTo support both models, we are developing a DVSP Portal. DVSPs will gain access to the portal when they join the DVS register. DVSPs that are already registered will receive instructions to create an account when the service is launched.
Submit information through the DVSP PortalWhen a DVSP joins the register, they will use the portal to submit and manage information about their services. This includes technical information that will allow them to generate transport certificates and entity configurations.
Generate transport certificatesUnder the API model, each participating DVSP will generate its own transport certificate bound to its identity. The DVSP will generate a key pair for each registered service and submit a certificate signing request to OfDIA via the DVSP Portal. The private key will remain under its control.
An appointed certificate authority will issue the certificate, and the certificate will chain back to an OfDIA root certificate authority. This creates a trust chain, so that when a DVSP presents a certificate, it can be traced back to OfDIA.
Create and publish entity configurationsEach service has an entity identifier. This is used to identify the service within the federation. The DVSP will publish a statement called an entity configuration at a standard location under this entity identifier.
The entity configuration is a self-signed JSON Web Token (JWT), which contains metadata about the service, the public keys for verifying federation statements, and authority_hints pointing to OfDIA. It can also carry separately signed OpenID Federation trust marks attesting certification details. These are machine-readable assertions, separate to the UK CertifID trust mark.
Separately, OfDIA will publish a signed subordinate statement binding the service’s entity identifier to its federation keys and applying the relevant metadata or policy.
How the API model establishes trust Check that a service is registeredBefore relying on a service, an organisation may want to check that it is on the DVS register. To do this under the API model, an organisation can:
1. Check the certificate using mTLSAn organisation may use mutual TLS (mTLS) to check certificates. During the handshake, the DVSP presents its transport certificate and proves possession of the matching private key. This establishes a protected connection.
The organisation receiving the connection checks that the certificate chains back to the OfDIA root certificate authority. It also checks that the certificate is within its validity period and has not been revoked.
OfDIA only issues transport certificates to registered services. Therefore, a valid transport certificate confirms that a service is on the DVS register. However, it does not confirm what the service is certified to do.
2. Check the client identityAn organisation or DVSP can check client identity in two ways. They can use tls_client_auth, where a service proves its identity using a trusted certificate during the mutual TLS (mTLS) connection. Or they can use private_key_jwt, where it proves its identity by signing a JWT using a trusted private key.
Check what a service is certified to doBefore relying on a service, an organisation may want to check its role types, GPG 44/45 profiles, and supplementary codes to confirm what it is certified to do. To do this under the API model, an organisation can:
1. Fetch the entity configurationThe organisation finds the service’s entity identifier. It then fetches the service’s entity configuration from the standard location. The authority_hints value in the entity configuration points to OfDIA.
2. Fetch the subordinate statementThe service’s entity configuration points to OfDIA’s fetch endpoint. The organisation will use the fetch endpoint to obtain the service’s subordinate statement.
3. Validate the trust chainAn organisation will validate the complete trust chain using OpenID Federation rules. It will:
validate the service’s self-signed entity configuration using federation keys listed in the subordinate statement validate each statement through the chain to a trust anchor reject expired or inconsistent statements and apply the chain’s constraints and metadata policiesA service will not be trusted if the chain fails the required validation.
4. Resolve the metadata and trust marksOfDIA will also provide a resolve endpoint. The resolve endpoint will validate the trust chain and return information about the DVSP including its metadata and trust marks.
The organisation applies the metadata and metadata policies from OfDIA’s subordinate statement to the metadata in the service’s entity configuration.
The resolved metadata reflects the service’s certification details on the DVS register. This confirms the service’s role types, GPG 44/45 profiles and supplementary codes. The service cannot claim certification details that OfDIA does not hold for it on the DVS register.
5. Check it is the same serviceThe organisation checks that the resolved metadata belongs to the same service that presented the transport certificate.
6. Decide whether to exchange informationThe organisation checks that the service’s certification details meet its own authorisation requirements for the transaction. If they do, the two services can exchange information over the mTLS connection.
Removing a service
Validated information can be cached to enable offline transactions and to avoid a central register lookup during every transaction. However, cached chains are usable only within their validity period and the profile’s refresh limits.
If a service is removed from the register, OfDIA will revoke its transport certificate and stop publishing subordinate statements about it. The removal takes effect when the organisation revalidates the trust chain and trust evidence, or when its cached statements expire, whichever happens first.
How the credential model establishes trustBefore accepting credentials, an organisation may want to verify that the parties involved in a transaction can be trusted. In the credential model, trust is established using two signed lists, both defined in the international standard ISO/IEC 18013-5:
a VICAL (Verifier Identity Certificate Authority List) which contains the root certificates of registered credential issuers a RICAL (Reader Identity Certificate Authority List) which contains the root certificates of registered verifiersA VICAL lets a verifier, such as an orchestration service provider, check that a credential was issued by a registered issuer, such as an attribute service provider. A RICAL lets a wallet, such as a holder service provider, check that a verifier is registered before sharing data. Both lists are published by OfDIA.
Under the credential model, an organisation can:
1. Obtain the VICAL and RICALOfDIA publishes the VICAL and RICAL at an OfDIA URL. Each list includes information such as when it was issued and when it will next be updated.
Verifiers obtain the VICAL and wallets obtain the RICAL. They check the list’s signature and cache the list until its next update.
OfDIA will specify how long wallets and verifiers can use a list after its update date. This stops a device which has been offline from trusting an old list.
2. Present a credentialIndividuals can store digital credentials in wallets. To initiate device connection in person, an individual could show a QR code from their wallet or tap their phone to the verifier’s NFC reader. The wallet and the verifier then establish session keys and an encrypted channel.
3. Validate the verifier using the RICALThe verifier sends a request for the data it needs. The request is signed with the verifier’s private key and includes its certificate chain.
Before releasing any information, the wallet:
checks the signature on the request follows the verifier’s certificate chain up to its root certificate, checking that no certificate has expired or been revoked checks that the root certificate appears in the RICAL and confirms that its copy of the RICAL is up to dateIf the verifier passes these checks, the transaction continues.
The wallet may seek approval from the individual to share data with the verifier.
4. Validate the issuer and the credential using the VICALIf the individual agrees, the wallet sends the data they have approved. This includes data signed by the issuer, and the issuer’s document signer certificate.
The verifier then:
follows the document signer certificate up to its root certificate, checking that the document signer certificate has not expired or been revoked checks that the root certificate appears in the VICAL checks the credential type, and the permitted issuer/service scope checks the issuer’s signature, and that the data it received matches what the issuer signed checks device authentication, which shows the credential is being presented from the device it was issued to, not a copy 5. Accept or reject the credentialThe verifier accepts the credential only if all checks pass.
Removing an issuer or verifier
If an issuer or verifier is removed from the register, OfDIA will remove its root certificate from the next version of the VICAL or RICAL. The change takes effect when wallets and verifiers obtain the updated list.
Next StepsIn October 2026, we will be testing our machine-readable infrastructure onboarding process and starting to run interviews with DVSPs to understand readiness for integration testing.
We have also published the technical document for machine-readable infrastructure integration on GitHub. We will begin testing both technical models later this year.
Take part in testingWe need DVSPs to help us test the onboarding process and both technical models. To take part, email us digital.identity.register@dsit.gov.uk.
seen at 18:30, 29 September in Enabling digital identity.