mDL Issuer Specifications
The following are considered necessary capabilities of the reference implementation of the remote issuer web application for the mDL Use Case:
mDL Verifiable Credentials
| Specification |
Optionality |
Description and Reference |
| ISO/IEC 18013-5 (CBOR) |
Mandatory |
[ARF], High Level Requirement: mDL_01
[ARF] "Annex 3.02 - mDL Rulebook" [4th Driving License Directive] Annex I, Part C |
| mDL Data Model |
Mandatory |
As above |
mDL Issuance Profile
| Specification |
Optionality |
Description and Reference |
| Profile of OpenID4VCI to issue mDL |
Mandatory |
ARF in High Level Requirements ISSU_01 specify HAIP as the profile for the OpenID4VCI protocol. HAIP profiles issuance only for SD-JWT VC but not for ISO mdoc. Therefore, an mDL profile for OpenID4VCI protocol needs to be specified to set the requirements for the existing specifications to enable interoperability among Issuers and Wallets of mDLs where a high level of security and data protection is required. |
| Attestation Issuance Interface (AII) |
|
|
| Credential Issuance API according to OpenID4VCI v1.0 specification |
Mandatory |
[ARF] "4.3.3 Wallet Unit interfaces and protocols" mentions that the "Attestation Issuance Interface (AII) complies with the [OpenID4VCI] standard". The version 1.0 of OpenID4VCI shall be implemented. |
Initiation
| Specification |
Optionality |
Description and Reference |
| Issuer-initiated |
Optional |
According to OpenID4VCI v1.0, section 3.1 the Credential Offer endpoint of the mDL Issuer is optional. This endpoint supports the issuer-initiated flow and therefore this flow is optional. |
| Wallet-initiated |
Mandatory |
Since the issuer-initiated flow (above) is optional according to the specification, consequently the wallet-initiated flow is mandatory. The wallet-initiated flow uses directly the Credential endpoint of the mDL Issuer. |
Authorization
| Specification |
Optionality |
Description and Reference |
| OAuth Authorization Server according to OpenID4VCI v1.0 |
Mandatory |
Each organisation acting as mDL Issuer has its own mechanism to authenticate the End User. Each organisation's Credential Issuer has to be protected by an OAuth Authorization Server according to OpenID4VCI v1.0 section 3.2. ARF section 6.6.2.1 point 2 specifies that the mDL Issuing Authority authenticates the user, meaning is sure about the identity of the User. The method by which the user is identified and authenticated is specific to each mDL Issuing Authority.
Additionally, ISO/IEC 18013-5 in section E.2.4.2 specifies that "Issuing authorities are responsible for the accurate provisioning of mDL to the proper mDL holder to achieve their target Identity Assurance Level as defined within their regional trust frameworks". |
| Pre-Authorized Code Flow |
Optional |
According to OpenID4VCI v1.0, section 3.5, point (2) and section 4.1.1, the pre-authorized code is delivered to the End User by the Credential Offer endpoint which is optional. Consequently, this flow is also optional.
Please note that OpenID4VCI v1.0 in section 12.4 lists several vulnerabilities for this flow. |
| Authorization Code Flow |
Mandatory |
According to OpenID4VCI v1.0, section 3.4, the authorization code flows have two variations: wallet-initiated and issuer-initiated. Also in point 2, the wallet has to determine the Authorization Endpoint to send an Authorization Request (point 3) in order to get authenticated and receive the Access Token. In issuer-initiated flow (point 1b) the wallet gets the Authorization Endpoint from the Credential Offer Endpoint which is optional. Therefore, the issuer-initiated authorization flow is optional.
In wallet-initiated flow (point 1a) the Credentials to be issued are pre-configured and so the Authorization Endpoint. In this case the wallet does not use the optional Credential Offer to determine the Authorization Endpoint since it is already pre-configured. After receiving the Access Code, the wallet uses the mandatory Credential Endpoint. Therefore, the wallet-initiated authorization flow is mandatory since it does not use the optional endpoints. |
Driving Licence Authentic Source Integration
| Specification |
Optionality |
Description and Reference |
| Integration with the Driving Licence Authentic Source |
Mandatory |
The mDL Issuer is responsible to issue mDL as verifiable credentials. The mDL claims shall be retrieved from the Driving Licence Authentic Source (ARF 3.10). |
Number of VCs per Issuance Request
| Specification |
Optionality |
Description and Reference |
| One verifiable credential per issuance request |
Mandatory |
The issuance of one credential per issuance request is a fundamental capability of the OpenID4VCI protocol, serving as a baseline or default option. OpenID4VCI section 8 specifies that "The Credential Endpoint issues one or more Credentials of the same Credential Configuration and Credential Dataset". |
| Multiple same verifiable credential instances per issuance request (Batch Issuance) |
Mandatory |
OpenID4VCI in section 11.2.4 defines the "batch_credential_issuance" parameter as optional for the issuer. ARF in High Level Requirements ISSU_04 and ISSU_64 specify the batch issuance as a mandatory capability of the attestation providers and wallets. |
Time of Issuance
| Specification |
Optionality |
Description and Reference |
| Immediate Issuance |
Optional (1) |
OpenID4VCI in section 8 (and 3.1) defines the Credential Endpoint as mandatory. This endpoint could respond with the requested credential either immediately or in a deferred manner. Therefore, the immediate issuance could be considered as optional. |
| Deferred Issuance |
Optional (1) |
OpenID4VCI in section 9 (and 3.1) defines the Deferred Credential endpoint as optional. |
Additional Issuance Flows
| Specification |
Optionality |
Description and Reference |
| Dynamic Issuance (synchronous or just-in-time) |
Optional |
Refer to ARF section 6.6.5.2.4 and Discussion topic "B - Re-issuance and batch issuance of PIDs and Attestations" section 3.4
The dynamic issuance is a capability of the EUDI Wallet ecosystem and OpenID4VCI, particularly for addressing data protection concerns and ensuring fresh credentials. It is not explicitly specified as a mandatory requirement for all issuance processes. |
| Re-issuance |
Mandatory |
ARF in High Level Requirements ISSU_63 specify the re-issuance as a mandatory capability of the attestation providers and wallet. |
Topology for Issuer-Initiated Flows
| Specification |
Optionality |
Description and Reference |
| Same device |
Optional |
According to OpenID4VCI section 3.3.3, both same and cross device flows refer on how the End User receives the Credential Offer from the Credential Issuer. The Credential Offer endpoint is optional and consequently both these flows are considered optional. |
| Cross device |
Optional |
As above |
mDL Presentation Policy
| Specification |
Optionality |
Description and Reference |
| Provide mDL presentation policy |
Mandatory |
ARF in High Level Requirements ISSU_37 and ISSU_38 specifies that the mDL Provider, SHALL have a policy describing which of the methods A, B, C, or D (or any other methods as well), it will use to limit the number of times a Wallet Unit may present a single mDL. |
mDL Revocation
| Specification |
Optionality |
Description and Reference |
| Include Revocation status list bit position within the mDL structure |
Optional (1) |
The specification for mDL revocation via a dedicated status list is expected to be introduced in a future version of ISO/IEC 18013-5. Consequently, mDL Issuers for revocable mDLs shall include the necessary status list bit position within the mDL structure, in anticipation of this future standard update.
ARF section 6.6.3.7 specifies that "Attestation Provider includes revocation information in the PID or attestation, if it is valid for longer than 24 hours." |
| Include Revocation identifier reference within the mDL structure |
Optional (1) |
The specification for mDL revocation via an identifierlist is expected to be introduced in a future version of ISO/IEC 18013-5. Consequently, mDL Issuers for revocable mDLs shall include the necessary identifier reference within the mDL structure, in anticipation of this future standard update. ARF section 6.6.3.7 specifies that "Attestation Provider includes revocation information in the PID or attestation, if it is valid for longer than 24 hours." |
Trust Relationships
| Specification |
Optionality |
Description and Reference |
| The issuer shall authenticate and validate the Wallet Unit during the issuance flow |
Mandatory |
ARF section 6.6.2.1 point 3 and section 6.6.2.3 |
| The issuer shall verify that the Wallet Provider did not revoke the Wallet Unit. |
Mandatory |
ARF section 6.6.2.1 point 4 and section 6.6.2.4 |
| The issuer shall download the Wallet Provider Trusted List(s) it needs from the relevant Trusted List Provider(s) |
Mandatory |
ARF section 6.6.2.3.1 specifies that "Attestation Providers: they must accept all Wallet Solutions and hence must possess all Wallet Provider Trusted Lists". |
| The issuer shall verify the signature over the WUA, using the Wallet Provider trust anchor obtained from the Trusted List. |
Mandatory |
ARF section 6.6.2.3.1 |
| The issuer shall verify that the Wallet Unit possesses the private key belonging to the public key in the WUA. |
Mandatory |
ARF section 6.6.2.3.1 |
| The issuer may be able to obtain a proof that the WSCD described in the WUA protects both the WUA private key and the private key of the new PID or attestation. |
Optional |
ARF section 6.6.2.3.3 |
| The issuer shall implement device binding |
Mandatory |
ARF section 6.6.3.8 specifies that "Attestation Provider implements device binding by including a cryptographic public key in the PID or attestation and signing it". |
mDL Reader Interface
| Specification |
Optionality |
Description and Reference |
| server data retrieval method |
Excluded / not supported |
The interface of the mDL reader and the issuing authority infrastructure can be used only for the server data retrieval method. The server data retrieval method allows the issuing authority to have knowledge when the mDL holder presents the mDL to a specific mDL verifier. This is prohibited explicitly by articles 5a.16 and 5a.5(b) of [eIDAS v2] and ARF] Annex 2 High level requirement "ProxId_02". Therefore, this method is excluded (not supported) from the mDL target solution. |
MS Notifications
| Specification |
Optionality |
Description and Reference |
| A Member State, other than the one issuing a driving license, imposing a driving disqualification shall immediately notify the Member State which issued the driving license |
Excluded / not supported |
[4th Driving License Directive] in the last sentence of Annex I, Part C mandates the notification obligations of Member States. This requirement is expected to be fulfilled in an out-of-band method and therefore is excluded from the mDL Use Case specifications. |
(1) Support for one of the methods or both.