Remote Flow: Presentation Request (of verifiable credentials) according to ISO 18013 -7 Annex B (OpenID4VP specification)
Mandatory
[ARF] "4.3.3 Wallet Unit interfaces and protocols" mentions that "For remote presentation flows (…) the Wallet Instance implements the OpenID for Verifiable Presentation protocol [OpenID4VP] in combination with the [W3C Digital Credentials API]".
Presentation in combination with the Digital Credentials API using ISO 18013-7 Annex C
Optional
As above and ISO 18013-7 Annex C ARF in section 4.4.3.1 states that "The use of this API by Wallet Units and Relying Parties is optional"
Presentation in combination with the Digital Credentials API using OpenID4VP, HAIP
Optional
As aboveOpenID4VP version 1.0 will be supported instead of Draft 18 which is specified in ISO 18013-5 Annex B ARF in section 4.4.3.1 states that "The use of this API by Wallet Units and Relying Parties is optional"
ARF section 4.4.1 defines the remote flows where in both remote scenarios, the Verifier sends a presentation request to the Wallet. OpenID4VP in section 3.1 and 3.1 specifies that for same and cross device flow the verifier initiates the flow by sending the Authorization Request to the wallet.
OpenID4VP section 5.10 specifies that the Wallet could require the Verifier to encrypt the Request Object
End-User authentication using SIOP v2
Excluded / Not Supported
OpenID4VP Appendix C specifies the presentation of Credentials combined with the End-User authentication using [SIOPv2]. It has already been removed from HAIP (editor's copy, draft 4, not yet published) via https://github.com/openid/oid4vc-haip/pull/186
DC API is optional according to ARF section 4.4.3.1 According to Annex C.2 in ISO/IEC 18013-7, the Request is a javascript object which contains the CBOR encoded DeviceRequest and EncryptionInfo
Device Response
Optional
Refer above for optionality According to Annex C.3 in ISO/IEC 18013-7, the Response is a javascript object which contains the CBOR encoded EncryptedResponse
HPKE single shot encryption /decryption
Optional
Refer above for optionality According to Annex C.4 in ISO/IEC 18013-7, HPKE (Hybrid Public Key Encryption) single-shot API is defined in RFC 9180
Session Transcript
Optional
Refer above for optionality According to Annex C.5 in ISO/IEC 18013-7, the session transcript shall be used for encryption, mdoc authentication and mdoc reader authentication and it is structured as a CBOR array
The verifier shall verify the signature of the mDL (Issuer data authentication)
Mandatory
ARF section 6.6.3.1 point 5 specifies that "The Relying Party Instance verifies the signature of the PID or attestation. This ensures that the Relying Party can trust that the PID or attestation it receives is issued by an authentic Provider and has not been changed"
The verifier shall verify that the mDL Issuer did not revoke the mDL (Revocation of mDL)
Mandatory
ARF section 6.6.3.1, point 6 (and 6.3.6.7) The specification for mDL revocation via a status list or reference list is expected to be introduced in a future version of ISO/IEC 18013-5. Consequently, mDL Verifiers shall be capable to verify the validity status of the mDL by retrieving the status list or identifier list, based on status info element of the mso. 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."
The verifier shall verify mDL device binding (mdoc authentication)
Mandatory
ARF section 6.6.3.1 point 7 (and 6.3.6.8) and Annex 2 OIA_02 specifies that "The Relying Party verifies that the PID Provider or Attestation Provider issued this PID or attestation to the same Wallet Unit that presented it to the Relying Party"
Section 9.3.3 in ISO/IEC 18013-5 specifies that "mdoc reader shall have access to certificate revocation information". A remote mDL verifier needs access to the issuing authority's certificate authority (IACA) root certificate to verify issuer data authentication. It checks the status of the Document Signing certificate and the IACA certificate against the published CRLs. Confirm that the issuer's IACA certificate is present, and that it is listed as an issuer of the doctype "org.iso.18013.5.1.mDL".
ETSI LOTL support
Mandatory
The Reference Implementation supports ETSI trusted lists because of other use cases, see e.g. ARF Annex 2 requirement PuBPNot_03 "The format of the PuB-EAA Provider Trusted List SHALL comply with ETSI TS 119 612 v2.1.1 or with a suitable profile similarly derived from ETSI TS 102 231"
IACA retrieval via VICAL
Mandatory
[4th Driving Licence Directive] in Article 5.7 mandates that the Commission shall adopt implementing acts [among others] for recognition of those driving licences by third country authorities. Annex C in ISO/IEC 18013-5 specifies the VICAL mechanism. It does not explicitly specify this mechanism as mandatory and therefore it is considered optional. This mechanism applies to the third countries