Wallet Solution - Relying Party interface
This section contains all tests applicable to the EUDI Wallet to Relying Party interface. Effectively, this interface covers any presentation.
Testing ISO mdoc presentation
Test specification approach for ISO/IEC 18013-5
The test specification approach for ISO/IEC 18013-5 (mdoc) slightly deviates from that for other STS. Given the test method coverage for 18013-5 is standardized in 18013-6, the FCAF follows the 18013-6 approach. Effectively, a profile for ISO/IEC TS 18013-6:2025 for EUDI-wallets is defined.
Below you will find a partially filled Implementation Conformity Statement (ICS) form template. Certain options have been pre-selected as they are applicable for any EUDI-wallet implementations. Remaining options are for the implementor to fill, matching their implementation choices.
EUDI-wallet Implementation Conformance Statement template
The ICS below is pre-filled with mandatory items for EUDI-wallets, aligned with Annex B of ISO/IEC TS 18013-6:2025. All items are 'EUDI_generic' and the underlying requirements for implementations are specified in ISO/IEC 18013-5.
Test cases are specified in ISO/IEC TS 18013-6:2025. This test standards allows selection of applicable test cases using the statements below.
Note that data model and use case test cases are excluded here, as they will be covered under tests related to "the mDL rulebook". Testing of other doctypes, like PID, are likewise covered elsewhere.
Further note that IACA, linking and Document signer certificate test are applicable for the mDL issuing authority, or QEAA/PubEAA Provider in EUDI-wallet terminology. Reader authentication certificates tests are applicable for Readers, or Relying Party (instances) and Providers of Wallet-Relying Party Access Certificates in EUDI-wallet terminology.
Technologies test cases
The "Technologies" layer of ISO/IEC TS 18013-6 matches closest with the "Interactions" layer for EUDI-wallet, and "Message structure" in similar fashion. The various test areas of 18013-6 align with areas of EUDI-wallet FCAF, although not exactly 1-on-1. This mapping has not been further detailed.
| # | ICS | value | EUDI-wallet |
|---|---|---|---|
| 45 | mdoc supports device engagement using NFC Static Handover. | Yes/No | EUDI_optional. |
| 46 | mdoc supports device engagement using NFC Negotiated Handover. | Yes/No | EUDI_optional. |
| 47 | mdoc supports device engagement using QR code. | Yes/No | EUDI_optional. |
| 48 | mdoc supports device retrieval using NFC. | Yes/No | EUDI_optional. |
| 49 | mdoc supports extended-length APDUs for device retrieval using NFC. | Yes/No | EUDI_optional. |
| 50 | mdoc supports BLE version 4.2 (or above) and LE Data Packet Length Extension. | Yes/No | EUDI_optional. |
| 51 | mdoc supports device retrieval using BLE in mdoc central client mode. | Yes/No | EUDI_optional. |
| 52 | If BLE in mdoc central client mode is used for device retrieval, mdoc verifies the value of the Ident characteristic. | Yes/No | EUDI_optional. |
| 53 | mdoc supports the L2CAP transmission profile if it is acting as the GATT client for device retrieval using BLE. | Yes/No | EUDI_optional. |
| 54 | mdoc supports device retrieval using BLE in mdoc peripheral server mode. | Yes/No | EUDI_optional. |
| 55 | mdoc supports the L2CAP transmission profile if it is acting as the GATT server for device retrieval using BLE. | Yes/No | EUDI_optional. |
| 56 | mdoc supports device retrieval using Wi-Fi Aware. | Yes/No | EUDI_optional. |
| 57 | mdoc supports the NCS-PK-2WDH-128 cipher suite for Wi-Fi Aware. | Yes/No | EUDI_optional. |
| 58 | mdoc supports server retrieval using OIDC. | EUDI_prohibited; Server retrieval is explicitly prohibited in (draft amendment of) [EU CIR 2024/2979]. | |
| 59 | mdoc supports server retrieval using WebAPI. | EUDI_prohibited; Server retrieval is explicitly prohibited in (draft amendment of) [EU CIR 2024/2979]. | |
| 60 | mdoc supports transferring server retrieval information in the device engagement structure. | EUDI_prohibited; Server retrieval is explicitly prohibited in (draft amendment of) [EU CIR 2024/2979]. | |
| 61 | mdoc implements a time-out for the time between sending device engagement data and receiving the session establishment message when using QR code for device engagement. | Yes/No | EUDI_optional |
| 62 | If yes, how many seconds is the time-out period implemented by the mdoc? | EUDI_optional | |
| 63 | mdoc implements a time-out for the time between sending device engagement data and receiving the session establishment message when using NFC for device engagement. | Yes/No | EUDI_optional |
| 64 | If yes, how many seconds is the time-out period implemented by the mdoc? | EUDI_optional |
Security mechanisms test cases
The "Security mechanisms" test layer of ISO/IEC 18013-6 matches the EUDI-wallet FCAF "Security mechanisms" test layer. Test various test areas of 18013-6 align with areas of EUDI-wallet FCAF, although not exactly 1-on-1. This mapping has not been further detailed.
| # | ICS | value | EUDI-wallet |
|---|---|---|---|
| 65 | Which curves does the mdoc support for session establishment? Select all that are supported. | Curve P-256 | EUDI_optional |
| Curve P-384 | EUDI_optional | ||
| Curve P-521 | EUDI_optional | ||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| brainpoolP256r1 | EUDI_optional | ||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| brainpoolP384r1 | EUDI_optional | ||
| brainpoolP512r1 | EUDI_optional | ||
| 66 | mdoc supports exchanging more than one device retrieval mdoc request and response with the mdoc reader in a single session. | Yes/No | EUDI_optional |
| 67 | If yes, how many seconds is the time-out period for session termination implemented by the mdoc? | EUDI_optional | |
| 68 | Which curves does the issuing authority support for issuer data authentication on this mdoc? Select all that are supported. | Curve P-256 | EUDI_optional |
| Curve P-384 | EUDI_optional | ||
| Curve P-521 | EUDI_optional | ||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| brainpoolP256r1 | EUDI_optional | ||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| brainpoolP384r1 | EUDI_optional | ||
| brainpoolP512r1 | EUDI_optional | ||
| 69 | The mdoc supports mdoc MAC authentication. | Yes/No | EUDI_optional (note: [ETSI 119 472-1] v1.1.1 excludes use of MAC authentication, v1.1.4 allows MAC authentication) |
| 70 | If yes, which curves does the mdoc support for mdoc MAC authentication? Select all that are supported. | Curve P-256 | EUDI_optional |
| Curve P-384 | EUDI_optional | ||
| Curve P-521 | EUDI_optional | ||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| brainpoolP256r1 | EUDI_optional | ||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| brainpoolP384r1 | EUDI_optional | ||
| brainpoolP512r1 | EUDI_optional | ||
| 71 | The mdoc supports mdoc ECDSA/ |
Yes/No | |
| 72 | If yes, which curves does the mdoc support for mdoc ECDSA/EdDSA authentication? Select all that are supported. | Curve P-256 | EUDI_optional |
| Curve P-384 | EUDI_optional | ||
| Curve P-521 | EUDI_optional | ||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| brainpoolP256r1 | EUDI_optional | ||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| brainpoolP384r1 | EUDI_optional | ||
| brainpoolP512r1 | EUDI_optional | ||
| 73 | mdoc supports mdoc reader authentication. | Yes/ |
EUDI_required |
| 74 | If yes, which curves does the mdoc support for mdoc reader authentication? Select all that are supported. | Curve P-256 | EUDI_optional |
| Curve P-384 | EUDI_optional | ||
| Curve P-521 | EUDI_optional | ||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| brainpoolP256r1 | EUDI_optional | ||
| EUDI_prohibited; algorithm not listed in [EUCC] | |||
| brainpoolP384r1 | EUDI_optional | ||
| brainpoolP512r1 | EUDI_optional | ||
| 75 | If yes, if mdoc reader authentication fails, does the mdoc notify the mdoc holder that the mdoc verifier’s identity could not be verified? | Yes/ No | EUDI_optional. |
| 76 | If yes, if mdoc reader authentication fails, are there any data elements that the mdoc will not release? If so, please list them all by namespace and identifier. | Yes / No | |
| 77 | If yes, mdoc supports retrieving OCSP information, if available, when verifying a mdoc reader authentication certificate. | Yes / No | |
| 78 | A test CRL for all IACA root certificate provided by applicant is available during testing. | Yes / No | |
| 79 | A test CRL for all Document Signer certificate provided by applicant is available during testing. | Yes / No | |
| 80 | If yes, mdoc supports retrieving CRL information when verifying a mdoc reader authentication certificate. | Yes / No |
Data Model
Data Model - Address Data
WS_RP_DM_AddressData_Emailaddress_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim email is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that email is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier email_address.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 5)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:".
The claim email is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
emailin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
emailis present.
WS_RP_DM_AddressData_Emailaddress_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the claim email is a String encoded in UTF-8. Note that email is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier email_address.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 3 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim email is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
emailin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
emailis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
emailis a String encoded in UTF-8, supporting the full Unicode range
WS_RP_DM_AddressData_Emailaddress_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the value of the claim email is an email address in conformance with [RFC 5322]. Note that email is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier email_address.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
- [RFC5322] Section 3.4
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim email is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
emailin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify the value of the email address.
Expected results
- The electronic mail address of the user to whom the person identification data relates, is in conformance with [RFC 5322].
WS_RP_DM_AddressData_Emailaddress_PID_ISO-mdoc_001
Objective
This test case verifies that the data element email_address is present in the mdoc data if this is indicated in the ICS. Note that email_address is the Attribute Identifier in ISO-mdoc for the Data Identifier email_address.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element email_address is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
email_addressin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementemail_address.
Expected results
- One data element with identifier
email_addressis present. - There is no
ErrorItemfor data elementemail_address.
WS_RP_DM_AddressData_Emailaddress_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element email_address is a well-formed CBOR text string. Note that email_address is the Attribute Identifier in ISO-mdoc for the Data Identifier email_address.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element email_address is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
email_addressin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_AddressData_Emailaddress_PID_ISO-mdoc_003
Objective
This test case verifies that the DataElementValue of data element email_address is an email address in conformance with [RFC 5322]. Note that email_address is the Attribute Identifier in ISO-mdoc for the Data Identifier email_address.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC5322] Section 3.4
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element email_address is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
email_addressin the device retrieval mdoc response was verified.
Test Scenario
- Verify the format of the CBOR data item.
- Verify the value of the
email_address.
Expected results
- The data item contains at least 1 UTF-8 character.
- The electronic mail address of the user to whom the person identification data relates, is in conformance with [RFC 5322].
WS_RP_DM_AddressData_Mobilephonenumber_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim phone_number is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that phone_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier mobile_phone_number.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim phone_number is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
phone_numberin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
phone_numberis present.
WS_RP_DM_AddressData_Mobilephonenumber_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim phone_number is a String encoded in UTF-8. Note that phone_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier mobile_phone_number.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim phone_number is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
phone_numberin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
phone_numberis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
phone_numberis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_AddressData_Mobilephonenumber_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the value of the claim phone_number is formatted as an international phone number. Note that phone_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier mobile_phone_number.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim phone_number is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
phone_numberin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify the length of the claim
phone_number. - Verify the value from
phone_number.
Expected results
- The length of the claim
phone_numberis at least 8 UTF-8 characters. - The
phone_numbervalue is the mobile phone number of the user to whom the person identification data relates, starting with the '+' symbol as the international code prefix and the country code, followed by numbers only.
WS_RP_DM_AddressData_Mobilephonenumber_PID_ISO-mdoc_001
Objective
This test case verifies that the data element mobile_phone_number is present in the mdoc data if this is indicated in the ICS. Note that mobile_phone_number is the Attribute Identifier in ISO-mdoc for the Data Identifier mobile_phone_number.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element mobile_phone_number is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
mobile_phone_numberin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementmobile_phone_number.
Expected results
- One data element with identifier
mobile_phone_numberis present. - There is no
ErrorItemfor data elementmobile_phone_number.
WS_RP_DM_AddressData_Mobilephonenumber_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element mobile_phone_number is a well-formed CBOR text string. Note that mobile_phone_number is the Attribute Identifier in ISO-mdoc for the Data Identifier mobile_phone_number.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element mobile_phone_number is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
mobile_phone_numberin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_AddressData_Mobilephonenumber_PID_ISO-mdoc_003
Objective
This test case verifies that the DataElementValue of data element mobile_phone_number is formatted as an international phone number. Note that mobile_phone_number is the Attribute Identifier in ISO-mdoc for the Data Identifier mobile_phone_number.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element mobile_phone_number is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
mobile_phone_numberin the device retrieval mdoc response was verified.
Test Scenario
- Verify the format of the CBOR data item.
- Verify the value of the Mobile Phone Number.
Expected results
- The data item contains at least 8 UTF-8 characters.
- Mobile telephone number of the User to whom the person identification data relates, starting with the '+' symbol as the international code prefix and the country code, followed by numbers only.
WS_RP_DM_AddressData_Residentaddress_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim address.formatted is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that address.formatted is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_address.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.formatted is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
address.formattedin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
address.formattedis present.
WS_RP_DM_AddressData_Residentaddress_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim address.formatted is a String encoded in UTF-8. Note that address.formatted is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_address.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 3 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.formatted is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
address.formattedin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
address.formattedis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
address.formattedis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_AddressData_Residentaddress_PID_ISO-mdoc_001
Objective
This test case verifies that the data element resident_address is present in the mdoc data if this is indicated in the ICS. Note that resident_address is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_address.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_address is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
resident_addressin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementresident_address.
Expected results
- One data element with identifier
resident_addressis present. - There is no
ErrorItemfor data elementresident_address.
WS_RP_DM_AddressData_Residentaddress_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element resident_address is a well-formed CBOR text string. Note that resident_address is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_address.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_address is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
resident_addressin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_AddressData_Residentcity_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim address.locality is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that address.locality is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_city.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.locality is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
address.localityin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
address.localityis present.
WS_RP_DM_AddressData_Residentcity_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim address.locality is a String encoded in UTF-8. Note that address.locality is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_city.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 3 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.locality is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
address.localityin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
address.localityis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
address.localityis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_AddressData_Residentcity_PID_ISO-mdoc_001
Objective
This test case verifies that the data element resident_city is present in the mdoc data if this is indicated in the ICS. Note that resident_city is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_city.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_city is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
resident_cityin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementresident_city.
Expected results
- One data element with identifier
resident_cityis present. - There is no
ErrorItemfor data elementresident_city.
WS_RP_DM_AddressData_Residentcity_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element resident_city is a well-formed CBOR text string. Note that resident_city is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_city.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_city is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
resident_cityin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_AddressData_Residentcountry_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim address.country is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that address.country is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_country.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.country is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully
Test Scenario
- Verify the presence of a claim with identifier
address.countryin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
address.countryis present.
WS_RP_DM_AddressData_Residentcountry_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim address.country is a String encoded in UTF-8. Note that address.country is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_country.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 3 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.country is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
address.countryin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
address.countryis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
address.countryis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_AddressData_Residentcountry_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the value of the claim address.country contains a valid country code. Note that address.country is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_country.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
- [ISO 3166-1:2020] 6.1
- [ISO 3166-1:2020] 8.3
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.country is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
address.countryin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the value of the claim
address.countrycontains a valid country code.
Expected results
- The value of the claim
address.country, an alpha-2 code, corresponding to a country name: Listed in ISO 3166-1:2020, 6.1. Not listed in ISO 3166-1:2020, 6.1. In this case, the user-assigned country codes may be used, which consist in the series of letters AA, QM to QZ, XA to XZ, and ZZ (ISO 3166-1:2020, 8.3).
WS_RP_DM_AddressData_Residentcountry_PID_ISO-mdoc_001
Objective
This test case verifies that the data element resident_country is present in the mdoc data if this is indicated in the ICS. Note that resident_country is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_country.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_country is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
resident_countryin the device retrieval mdoc response - Verify the absence of an
ErrorItemfor data elementresident_country.
Expected results
- One data element with identifier
resident_countryis present. - There is no
ErrorItemfor data elementresident_country.
WS_RP_DM_AddressData_Residentcountry_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element resident_country is a well-formed CBOR text string. Note that resident_country is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_country.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_country is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
resident_countryin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_AddressData_Residentcountry_PID_ISO-mdoc_003
Objective
This test case verifies that the DataElementValue of data element resident_country contains a valid country code. Note that resident_country is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_country.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [ISO 3166-1:2020] 6.1
- [ISO 3166-1:2020] 8.3
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_country is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
resident_countryin the device retrieval mdoc response was verified.
Test Scenario
- Verify that the DataElementValue of the data element contains a valid country code.
Expected results
- The DataElementValue has two characters, an alpha-2 code, corresponding to a country name: Listed in ISO 3166-1:2020, 6.1. Not listed in ISO 3166-1:2020, 6.1. In this case, the user-assigned country codes may be used, which consist in the series of letters AA, QM to QZ, XA to XZ, and ZZ (ISO 3166-1:2020, 8.3).
WS_RP_DM_AddressData_Residenthousenumber_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim address.house_number is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that address.house_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_house_number.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.house_number is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
address.house_numberin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
address.house_numberis present.
WS_RP_DM_AddressData_Residenthousenumber_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim address.house_number is a String encoded in UTF-8. Note that address.house_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_house_number.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.house_number is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
address.house_numberin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
address.house_numberis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
address.house_numberis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_AddressData_Residenthousenumber_PID_ISO-mdoc_001
Objective
This test case verifies that the data element resident_house_number is present in the mdoc data if this is indicated in the ICS. Note that resident_house_number is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_house_number.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_house_number is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
resident_house_numberin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementresident_house_number.
Expected results
- One data element with identifier
resident_house_numberis present. - There is no
ErrorItemfor data elementresident_house_number.
WS_RP_DM_AddressData_Residenthousenumber_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element resident_house_number is a well-formed CBOR text string. Note that resident_house_number is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_house_number.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_house_number is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
resident_house_numberin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_AddressData_Residentpostalcode_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim address.postal_code is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that address.postal_code is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_postal_code.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.postal_code is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
address.postal_codein the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
address.postal_codeis present.
WS_RP_DM_AddressData_Residentpostalcode_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim address.postal_code is a String encoded in UTF-8. Note that address.postal_code is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_postal_code.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 3 (Table 7)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.postal_code is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
address.postal_codein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
address.postal_codeis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
address.postal_codeis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_AddressData_Residentpostalcode_PID_ISO-mdoc_001
Objective
This test case verifies that the data element resident_postal_code is present in the mdoc data if this is indicated in the ICS.
Note that resident_postal_code is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_postal_code.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_postal_code is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
resident_postal_codein the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementresident_postal_code.
Expected results
- One data element with identifier
resident_postal_codeis present. - There is no
ErrorItemfor data elementresident_postal_code.
WS_RP_DM_AddressData_Residentpostalcode_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element resident_postal_code is a well-formed CBOR text string. Note that resident_postal_code is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_postal_code.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_postal_code is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
resident_postal_codein the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_AddressData_Residentstate_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim address.region is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that address.region is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_state.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.region is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
address.regionin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
address.regionis present.
WS_RP_DM_AddressData_Residentstate_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim address.region is a String encoded in UTF-8. Note that address.region is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_state.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.region is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
address.regionin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
address.regionis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
address.regionis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_AddressData_Residentstate_PID_ISO-mdoc_001
Objective
This test case verifies that the data element resident_state is present in the mdoc data if this is indicated in the ICS. Note that resident_state is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_state.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_state is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
resident_statein the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementresident_state.
Expected results
- One data element with identifier
resident_stateis present. - There is no
ErrorItemfor data elementresident_state.
WS_RP_DM_AddressData_Residentstate_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element resident_state is a well-formed CBOR text string. Note that resident_state is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_state.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_state is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
resident_statein the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_AddressData_Residentstreet_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim address.street_address is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that address.street_address is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_street.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.street_address is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
address.street_addressin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
address.street_addressis present.
WS_RP_DM_AddressData_Residentstreet_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim address.street_address is a String encoded in UTF-8. Note that address.street_address is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier resident_street.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 3 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim address.street_address is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
address.street_addressin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
address.street_addressis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
address.street_addressis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_AddressData_Residentstreet_PID_ISO-mdoc_001
Objective
This test case verifies that the data element resident_street is present in the mdoc data if this is indicated in the ICS. Note that resident_street is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_street.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_street is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
resident_streetin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementresident_street.
Expected results
- One data element with identifier
resident_streetis present. - There is no
ErrorItemfor data elementresident_street.
WS_RP_DM_AddressData_Residentstreet_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element resident_street is a well-formed CBOR text string. Note that resident_street is the Attribute Identifier in ISO-mdoc for the Data Identifier resident_street.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element resident_street is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
resident_streetin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
Data Model - Credential Metadata
WS_RP_DM_CredentialMetadata_CredentialStructure007
Objective
Test when valid credential_sets is present, the Wallet can handle these and applies the constraints when processing the request.
References
- [OpenID4VP] Section 6
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a valid "credential_sets" property.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet MUST have used the constraints defined by "credential_sets", to create its response.
WS_RP_DM_CredentialMetadata_CredentialStructure008
Objective
Test the wallet can process and match each entry in the credentials' parameter of the DCQL, with credentials present in the wallet.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet response must show that it processes each entry in the credentials' parameter, where appropriate matching with credentials present in wallet.
WS_RP_DM_CredentialMetadata_CredentialStructure009
Objective
Test that a wallet which holds no matching credentials to the DCQL "credentials", will NOT return any credentials
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with "credentials" that the wallet does NOT contain.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet will either return an "invalid request" error, or an empty VP token
WS_RP_DM_CredentialMetadata_CredentialStructure010
Objective
Test that if the credentials' property "claim_sets" is present then it is used as per the rules defined in [OID4VP 6.4.1]
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with a claim_sets.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet correctly uses the "claims_sets" to determine which claims to send, as per the rules in [OID4VP 6.4.1]
WS_RP_DM_Credentialmetadata_Documentnumber_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim document_number is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that document_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier document_number.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 5)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim document_number is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
document_numberin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
document_numberis present.
WS_RP_DM_Credentialmetadata_Documentnumber_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the value of the document_number is a String. Note that document_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier document_number.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 8)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
document_numberin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
document_numberis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
document_numberis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_Credentialmetadata_Documentnumber_PID_ISO-mdoc_001
Objective
This test case verifies that the data element document_number is present in the mdoc data if this is indicated in the ICS. Note that document_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier document_number.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element document_number is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
document_numberin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementdocument_number.
Expected results
- One data element with identifier
document_numberis present. - There is no
ErrorItemfor data elementdocument_number.
WS_RP_DM_Credentialmetadata_Documentnumber_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element document_number is a well-formed CBOR text string. Note that document_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier document_number.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element document_number is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
document_numberin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_Credentialmetadata_Domestic_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies domestic elements in an appropriate namespace are present, if these have been indicated in the ICS.
References
- [PID rulebook] Annex 3.01, Section 4.2
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1", which contains data elements in a domestic namespace.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify claims in the domestic namespace are present.
Expected results
- One or more data claims in the indicated namespace are present.
WS_RP_DM_Credentialmetadata_Domestic_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies domestic claims are located in a valid domestic namespace, if these have been indicated in the ICS.
References
- [PID rulebook] Annex 3.01, Section 4.2
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1", which contains data elements in a domestic namespace.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim from domestic namespace in the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the domestic namespace complies with a valid the domestic namespace identifier.
Expected results
- Domestic namespace complies with a valid the domestic namespace identifier.
WS_RP_DM_Credentialmetadata_Domestic_PID_ISO-mdoc_001
Objective
This test case verifies domestic elements in an appropriate namespace are present, if these have been indicated in the ICS.
References
- [PID rulebook] Annex 3.01, Section 4.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1", which contains data elements in a domestic namespace.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested, as well as data elements in the domestic namespace indicated in the ICS.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify data elements in the domestic namespace are present.
Expected results
- One or more data elements in the indicated namespace are present.
WS_RP_DM_Credentialmetadata_Domestic_PID_ISO-mdoc_002
Objective
This test case verifies domestic elements are located in a valid domestic namespace, if these have been indicated in the ICS.
References
- [PID rulebook] Annex 3.01, Section 4.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1", which contains data elements in a domestic namespace.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested, as well as data elements in the domestic namespace indicated in the ICS.
- The device retrieval mdoc response was retrieved.
- The presence of data element in the domestic namespace in the device retrieval mdoc response was verified.
Test Scenario
- Verify the data elements in the domestic namespace comply use a valid the domestic namespace identifier.
Expected results
- The domestic namespace: Use a prefix ‘eu.europa.ec.eudi.pid.’ Followed by a ISO 3166-1 alpha-2 country code or the ISO 3166-2 region code. Optionally followed by a dot and a number.
WS_RP_DM_Credentialmetadata_Expirydate_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim date_of_expiry is present in the Credential in IETF SD-JWT VC format. Note that date_of_expiry is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier expiry_date.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 5)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
date_of_expiryin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
date_of_expiryis present.
WS_RP_DM_Credentialmetadata_Expirydate_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim date_of_expiry is a String encoded in UTF-8. Note that date_of_expiry is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier expiry_date.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 4 (Table 8)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
date_of_expiryin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
date_of_expiryis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
date_of_expiryis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_Credentialmetadata_Expirydate_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the format of the claim date_of_expiry is correct. Note that date_of_expiry is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier expiry_date.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 8)
- [RFC3339] Section 5.6
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
date_of_expiryin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify the length of the claim
date_of_expiry. - Verify the characters used in the format of the value of the claim.
Expected results
- The length of the claim is 10 UTF-8 encoded characters.
- The characters used have the following format: date-fullyear "-" date-month "-" date-mday. Where:
- date-fullyear consists of four decimal digits.
- date-month and date-mday consist of two decimal digits.
WS_RP_DM_Credentialmetadata_Expirydate_PID_IETF-sd-jwt-vc_004
Objective
This test case verifies that the claim date_of_expiry contains a valid date. Note that date_of_expiry is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier expiry_date.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 4 (Table 8)
- [ISO 8601-1:2019] 4.2.1, 4.3.2
- [RFC3339] Sections 5.6, 5.7
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
date_of_expiryin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify the value of date-fullyear.
- Verify the value of date-month.
- Verify the value of date-mday.
Expected results
- The value of date-fullyear is between "0000" and "9999" inclusive.
- The value of date-month is between "01" and "12" inclusive.
- The value of date-mday is between "01" and the maximum value specified in section 5.7 of RFC 3339 inclusive.
WS_RP_DM_Credentialmetadata_Expirydate_PID_ISO-mdoc_001
Objective
This test case verifies that the data element expiry_date is present in the mdoc data. Note that expiry_date is the Attribute Identifier in ISO-mdoc for the Data Identifier expiry_date.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 5)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element expiry_date is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
expiry_datein the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementexpiry_date.
Expected results
- One data element with identifier
expiry_dateis present. - There is no
ErrorItemfor data elementexpiry_date.
WS_RP_DM_Credentialmetadata_Expirydate_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element expiry_date is encoded as a well-formed #6.0(tstr) or #6.1004(tstr). Note that expiry_date is the Attribute Identifier in ISO-mdoc for the Data Identifier expiry_date.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Sections 2.1, 2.4
- [RFC8610] Appendix D
- [RFC8943] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element expiry_date is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
expiry_datein the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the value of the tag.
- Verify the major type of the nested CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 6.
- The value and encoding of the tag is one of the following: tag value = 0 (indicating a date-time tstr). The value of the additional information on the only byte is 0. Tag value = 1004 (indicating a full-date tstr). The value of the additional information on the first byte is 25 and the value of the next two bytes is '03 EC'.
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_Credentialmetadata_Expirydate_PID_ISO-mdoc_003
Objective
This test case verifies that the format of the DataElementValue of data element expiry_date is correct. Note that expiry_date is the Attribute Identifier in ISO-mdoc for the Data Identifier expiry_date.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC3339] Section 5.6
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element expiry_date is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
expiry_datein the device retrieval mdoc response was verified.
Test Scenario
- Verify the length of the data element.
- Verify the characters used in the format of the DataElementValue of the data element.
Expected results
- If the value of the tag is equal to:
- 0, the length of the data element is equal to 20 UTF-8 encoded characters.
- 1004, the length of the data element is equal to 10 UTF-8 encoded characters.
-
If the value of the tag is equal to:
- 0, the characters used have the following format: date-fullyear "-" date-month "-" date-mday "T" time-hour ":" time-minute ":" time-second time-offset.
- 1004, the characters used have the following format: date-fullyear "-" date-month "-" date-mday.
Where:
- date-fullyear consists of four decimal digits.
- date-month, date-mday, time-hour, time-minute and time-second consist of two decimal digits.
- time-offset consists of one character: "Z".
WS_RP_DM_Credentialmetadata_Expirydate_PID_ISO-mdoc_004
Objective
This test case verifies that the DataElementValue of data element expiry_date contains a valid date and time. Note that expiry_date is the Attribute Identifier in ISO-mdoc for the Data Identifier expiry_date.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [ISO 8601-1:2019] 4.2.1, 4.3.2
- [RFC3339] Sections 5.6, 5.7
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType ="eu.europa.ec.eudi.pid.1". Data element expiry_date is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
expiry_datein the device retrieval mdoc response was verified.
Test Scenario
- Verify the value of date-fullyear.
- Verify the value of date-month.
- Verify the value of date-mday.
- If present, verify the value of time-hour.
- If present, verify the value of time-minute.
- If present, verify the value of time-second.
Expected results
- The value of date-fullyear is between "0000" and "9999" inclusive.
- The value of date-month is between "01" and "12" inclusive.
- The value of date-mday is between "01" and the maximum value specified in section 5.7 of RFC 3339 inclusive.
- If present, the value of time-hour is between "00" and "23" inclusive.
- If present, the value of time-minute is between "00" and "59" inclusive.
- If present, the value of time-second is between "00" and "60" inclusive.
WS_RP_DM_Credentialmetadata_Issuancedate_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim date_of_issuance is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that date_of_issuance is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuance_date.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 5)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim date_of_issuance is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
date_of_issuancein the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
date_of_issuanceis present.
WS_RP_DM_Credentialmetadata_Issuancedate_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim date_of_issuance is a String encoded in UTF-8. Note that date_of_issuance is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuance_date.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 4 (Table 8)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim date_of_issuance is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
date_of_issuancein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
date_of_issuanceis a String encoded in UTF-8, supporting the full Unicode range
Expected results
- The claim
date_of_issuanceis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_Credentialmetadata_Issuancedate_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the format of the claim date_of_issuance is correct. Note that date_of_issuance is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuance_date.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 8)
- [RFC3339] Section 5.6
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
date_of_issuancein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify the length of the claim
date_of_issuance. - Verify the characters used in the format of the value of the claim.
Expected results
- The length of the claim is 10 UTF-8 encoded characters.
- The characters used have the following format: date-fullyear "-" date-month "-" date-mday. Where:
- date-fullyear consists of four decimal digits.
- date-month and date-mday consist of two decimal digits.
WS_RP_DM_Credentialmetadata_Issuancedate_PID_IETF-sd-jwt-vc_004
Objective
This test case verifies that the claim date_of_issuance contains a valid date. Note that date_of_issuance is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuance_date.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 8)
- [ISO 8601-1:2019] 4.2.1, 4.3.2
- [RFC3339] Sections 5.6, 5.7
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
date_of_issuancein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify the value of date-fullyear.
- Verify the value of date-month.
- Verify the value of date-mday.
Expected results
- The value of date-fullyear is between "0000" and "9999" inclusive.
- The value of date-month is between "01" and "12" inclusive.
- The value of date-mday is between "01" and the maximum value specified in section 5.7 of RFC 3339 inclusive.
WS_RP_DM_Credentialmetadata_Issuancedate_PID_ISO-mdoc_001
Objective
This test case verifies that the data element issuance_date is present in the mdoc data if this is indicated in the ICS. Note that issuance_date is the Attribute Identifier in ISO-mdoc for the Data Identifier issuance_date.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuance_date is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
issuance_datein the device retrieval mdoc response - Verify the absence of an
ErrorItemfor data elementissuance_date.
Expected results
- One data element with identifier
issuance_dateis present. - There is no
ErrorItemfor data elementissuance_date.
WS_RP_DM_Credentialmetadata_Issuancedate_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element issuance_date is encoded as a well-formed #6.0(tstr) or #6.1004(tstr). Note that issuance_date is the Attribute Identifier in ISO-mdoc for the Data Identifier issuance_date.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Sections 2.1, 2.4
- [RFC8610] Appendix D
- [RFC8943] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuance_date is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
issuance_datein the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the value of the tag.
- Verify the major type of the nested CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 6.
- The value and encoding of the tag is one of the following: tag value = 0 (indicating a date-time tstr). The value of the additional information on the only byte is 0. Tag value = 1004 (indicating a full-date tstr). The value of the additional information on the first byte is 25 and the value of the next two bytes is '03 EC'.
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_Credentialmetadata_Issuancedate_PID_ISO-mdoc_003
Objective
This test case verifies that the format of the DataElementValue of data element issuance_date is correct. Note that issuance_date is the Attribute Identifier in ISO-mdoc for the Data Identifier issuance_date.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC3339] Section 5.6
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuance_date is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
issuance_datein the device retrieval mdoc response was verified.
Test Scenario
- Verify the length of the data element.
- Verify the characters used in the format of the DataElementValue of the data element.
Expected results
- If the value of the tag is equal to:
- 0, the length of the data element is equal to 20 UTF-8 encoded characters.
- 1004, the length of the data element is equal to 10 UTF-8 encoded characters.
-
If the value of the tag is equal to:
- 0, the characters used have the following format: date-fullyear "-" date-month "-" date-mday "T" time-hour ":" time-minute ":" time-second time-offset.
- 1004, the characters used have the following format: date-fullyear "-" date-month "-" date-mday.
Where:
- date-fullyear consists of four decimal digits.
- date-month, date-mday, time-hour, time-minute and time-second consist of two decimal digits.
- time-offset consists of one character: "Z".
WS_RP_DM_Credentialmetadata_Issuancedate_PID_ISO-mdoc_004
Objective
This test case verifies that the DataElementValue of data element issuance_date contains a valid date and time. Note that issuance_date is the Attribute Identifier in ISO-mdoc for the Data Identifier issuance_date.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [ISO 8601-1:2019] 4.2.1, 4.3.2
- [RFC3339] Sections 5.6, 5.7
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuance_date is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "org.iso.18013.5.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
issuance_datein the device retrieval mdoc response was verified.
Test Scenario
- Verify the value of date-fullyear.
- Verify the value of date-month.
- Verify the value of date-mday.
- If present, verify the value of all time-hour.
- If present, verify the value of all time-minute.
- If present, verify the value of time-second.
Expected results
- The value of date-fullyear is between "0000" and "9999" inclusive.
- The value of date-month is between "01" and "12" inclusive.
- The value of date-mday is between "01" and the maximum value specified in section 5.7 of RFC 3339 inclusive.
- If present, the value of time-hour is between "00" and "23" inclusive.
- If present, the value of time-minute is between "00" and "59" inclusive.
- If present, the value of time-second is between "00" and "60" inclusive.
WS_RP_DM_Credentialmetadata_Issuingauthority_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim issuing_authority is present in the Credential in IETF SD-JWT VC format. Note that issuing_authority is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuing_authority.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 5)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim issuing_authority is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
issuing_authorityin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
issuing_authorityis present.
WS_RP_DM_Credentialmetadata_Issuingauthority_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim issuing_authority is a String encoded in UTF-8. Note that issuing_authority is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuing_authority.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 8)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim issuing_authority is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
issuing_authorityin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
issuing_authorityis a String encoded in UTF-8, supporting the full Unicode range
Expected results
- The claim
issuing_authorityis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_Credentialmetadata_Issuingauthority_PID_ISO-mdoc_001
Objective
This test case verifies that the data element issuing_authority is present in the mdoc data. Note that issuing_authority is the Attribute Identifier in ISO-mdoc for the Data Identifier issuing_authority.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuing_authority is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
issuing_authorityin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementissuing_authority.
Expected results
- One data element with identifier
issuing_authorityis present. - There is no
ErrorItemfor data elementissuing_authority.
WS_RP_DM_Credentialmetadata_Issuingauthority_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element issuing_authority is a well-formed CBOR text string. Note that issuing_authority is the Attribute Identifier in ISO-mdoc for the Data Identifier issuing_authority.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuing_authority is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
issuing_authorityin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_Credentialmetadata_Issuingcountry_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim issuing_country is present in the Credential in IETF SD-JWT VC format. Note that issuing_country is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuing_country.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 5)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
issuing_countryin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
issuing_countryis present.
WS_RP_DM_Credentialmetadata_Issuingcountry_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim issuing_country is a String encoded in UTF-8. Note that issuing_country is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuing_country.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 8)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
issuing_countryin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
issuing_countryis a String encoded in UTF-8, supporting the full Unicode range
Expected results
- The claim
issuing_countryis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_Credentialmetadata_Issuingcountry_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the value of the claim issuing_country contains a valid country code. Note that issuing_country is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuing_country.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 5)
- [ISO 3166-1:2020] 6.1
- [ISO 3166-1:2020] 8.3
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim issuing_country is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
issuing_countryin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the value of the claim
issuing_countrycontains a valid country code.
Expected results
- The value of the claim
issuing_country, an alpha-2 code, corresponding to a country name: Listed in ISO 3166-1:2020, 6.1. Not listed in ISO 3166-1:2020, 6.1. In this case, the user-assigned country codes may be used, which consist in the series of letters AA, QM to QZ, XA to XZ, and ZZ (ISO 3166-1:2020, 8.3).
WS_RP_DM_Credentialmetadata_Issuingcountry_PID_ISO-mdoc_001
Objective
This test case verifies that the data element issuing_country is present in the mdoc data. Note that issuing_country is the Attribute Identifier in ISO-mdoc for the Data Identifier issuing_country.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuing_country is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
issuing_countryin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementissuing_country.
Expected results
- One data element with identifier
issuing_countryis present. - There is no
ErrorItemfor data elementissuing_country.
WS_RP_DM_Credentialmetadata_Issuingcountry_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element issuing_country is a well-formed CBOR text string. Note that issuing_country is the Attribute Identifier in ISO-mdoc for the Data Identifier issuing_country.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuing_country is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
issuing_countryin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_Credentialmetadata_Issuingcountry_PID_ISO-mdoc_003
Objective
This test case verifies that the DataElementValue of data element issuing_country contains a valid country code. Note that issuing_country is the Attribute Identifier in ISO-mdoc for the Data Identifier issuing_country.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [ISO 3166-1:2020] 6.1
- [ISO 3166-1:2020] 8.3
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuing_country is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
issuing_countryin the device retrieval mdoc response was verified.
Test Scenario
- Verify the first two UTF-8 encoded characters in the data element.
- Verify the third UTF-8 encoded character in the data element.
- Verify that the remaining UTF-8 encoded characters in the data element constitute a valid value.
Expected results
- The first two UTF-8 encoded characters shall refer to the same country as the DataElementValue of data element
issuing_country. - The third UTF-8 encoded character is "-".
- The remaining UTF-8 encoded characters form a code corresponding to a country subdivision listed in ISO 3166-2:2020, 6.1 (according to the corresponding country code).
WS_RP_DM_Credentialmetadata_Issuingjurisdiction_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim issuing_jurisdiction is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that issuing_jurisdiction is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuing_jurisdiction.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 5)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim issuing_jurisdiction is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
issuing_jurisdictionin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
issuing_jurisdictionis present.
WS_RP_DM_Credentialmetadata_Issuingjurisdiction_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim issuing_jurisdiction is a String encoded in UTF-8. Note that issuing_jurisdiction is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuing_jurisdiction.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 8)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim issuing_jurisdiction is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
issuing_jurisdictionin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
issuing_jurisdictionis a String encoded in UTF-8, supporting the full Unicode range
Expected results
- The claim
issuing_jurisdictionis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_Credentialmetadata_Issuingjurisdiction_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the value of the claim issuing_jurisdiction contains a valid country subdivision code. Note that issuing_jurisdiction is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier issuing_jurisdiction.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 5)
- [ISO 3166-2:2020] 8
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim issuing_jurisdiction is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
issuing_jurisdictionin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify the first two UTF-8 encoded characters in claim
issuing_jurisdiction. - Verify the third UTF-8 encoded character in the claim
issuing_jurisdiction. - Verify that the remaining UTF-8 encoded characters in the claim
issuing_jurisdictionconstitute a valid value.
Expected results
- The first two UTF-8 encoded characters refer to the same country as the claim
issuing_country. - The third UTF-8 encoded character is "-".
- The remaining UTF-8 encoded characters form a code corresponding to a country subdivision listed in ISO 3166-2:2020, 6.1 (according to the corresponding country code).
WS_RP_DM_Credentialmetadata_Issuingjurisdiction_PID_ISO-mdoc_001
Objective
This test case verifies that the data element issuing_jurisdiction is present in the mdoc data if this is indicated in the ICS. Note that issuing_jurisdiction is the Attribute Identifier in ISO-mdoc for the Data Identifier issuing_jurisdiction.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuing_jurisdiction is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
issuing_jurisdictionin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementissuing_jurisdiction.
Expected results
- One data element with identifier
issuing_jurisdictionis present. - There is no
ErrorItemfor data elementissuing_jurisdiction.
WS_RP_DM_Credentialmetadata_Issuingjurisdiction_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element issuing_jurisdiction is a well-formed CBOR text string. Note that issuing_jurisdiction is the Attribute Identifier in ISO-mdoc for the Data Identifier issuing_jurisdiction.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuing_jurisdiction is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
issuing_jurisdictionin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_Credentialmetadata_Issuingjurisdiction_PID_ISO-mdoc_003
Objective
This test case verifies that the DataElementValue of data element issuing_jurisdiction contains a valid country subdivision code. Note that issuing_jurisdiction is the Attribute Identifier in ISO-mdoc for the Data Identifier issuing_jurisdiction.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [ISO 3166-2:2020] 6.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element issuing_jurisdiction is present in the EU PID data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence and format of data element
issuing_jurisdictionin the device retrieval mdoc response was verified. - The presence and format of data element
issuing_countryin the device retrieval mdoc response was verified.
Test Scenario
- Verify the first two UTF-8 encoded characters in the data element.
- Verify the third UTF-8 encoded character in the data element.
- Verify that the remaining UTF-8 encoded characters in the data element constitute a valid value.
Expected results
- The first two UTF-8 encoded characters shall refer to the same country as the DataElementValue of data element
issuing_country. - The third UTF-8 encoded character is "-".
- The remaining UTF-8 encoded characters form a code corresponding to a country subdivision listed in ISO 3166-2:2020, 6.1 (according to the corresponding country code).
Data Model - Identifying Data
WS_RP_DM_IdentifyingData_Birthdate_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim birthdate is present in the Credential in IETF SD-JWT VC format. Note that birthdate is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier birth_date.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.4, Section 4.2 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
birthdatein the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
birthdateis present.
WS_RP_DM_IdentifyingData_Birthdate_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim birthdate is a String encoded in UTF-8. Note that birthdate is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier birth_date.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.4, Section 4.2 (Table 7)
- [RFC8943] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim element
birthdatein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
birthdateis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
birthdateis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_IdentifyingData_Birthdate_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the format of the claim birthdate is correct. Note that birthdate is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier birth_date.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.4, Section 4.2 (Table 7)
- [RFC3339] Section 5.6
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
birthdatein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify the length of the claim
birthdate. - Verify the characters used in the format of the value of the claim.
Expected results
- The length of the claim is 10 UTF-8 encoded characters.
- The characters used have the following format: date-fullyear "-" date-month "-" date-mday. Where:
- date-fullyear consists of four decimal digits.
- Date-month and Date-mday consist of two decimal digits.
WS_RP_DM_IdentifyingData_Birthdate_PID_IETF-sd-jwt-vc_004
Objective
This test case verifies that the claim birthdate contains a valid date. Note that birthdate is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier birth_date.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.4, Section 4.2, item 3 (Table 7)
- [ISO 8601-1:2019] 4.2.1, 4.3.2
- [RFC3339] Sections 5.6, 5.7
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
birthdatein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify the value of date-fullyear.
- Verify the value of date-month.
- Verify the value of date-mday.
Expected results
- The value of date-fullyear is between "0000" and "9999" inclusive.
- The value of date-month is between "01" and "12" inclusive.
- The value of date-mday is between "01" and the maximum value specified in section 5.7 of RFC 3339 inclusive.
WS_RP_DM_IdentifyingData_Birthdate_PID_ISO-mdoc_001
Objective
This test case verifies that the data element birth_date is present in the mdoc data. Note that birth_date is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_date.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.4, Section 4.1 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1".
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
birth_datein the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementbirth_date.
Expected results
- One data element with identifier
birth_dateis present. - There is no
ErrorItemfor data elementbirth_date.
WS_RP_DM_IdentifyingData_Birthdate_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element birth_date is encoded as a well-formed #6.1004(tstr). Note that birth_date is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_date.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.4, Section 4.1 (Table 6)
- [RFC8943] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
birth_datein the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the value of the tag.
- Verify the major type of the nested CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 6.
- The tag value is equal to 1004 (indicating a full-date tstr). The value of the additional information on the first byte is 25 and the value of the next two bytes is '03 EC'.
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_IdentifyingData_Birthdate_PID_ISO-mdoc_003
Objective
This test case verifies that the format of the DataElementValue of data element birth_date is correct. Note that birth_date is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_date.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.4, Section 4.1 (Table 6)
- [RFC3339] Section 5.6
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
birth_datein the device retrieval mdoc response was verified.
Test Scenario
- Verify the length of the data element.
- Verify the characters used in the format of the DataElementValue of the data element.
Expected results
- The length of the data element is 10 UTF-8 encoded characters.
- The characters used have the following format: date-fullyear "-" date-month "-" date-mday. Where: date-fullyear consists of four decimal digits. Date-month and date-mday consist of two decimal digits.
WS_RP_DM_IdentifyingData_Birthdate_PID_ISO-mdoc_004
Objective
This test case verifies that the DataElementValue of data element birth_date contains a valid date. Note that birth_date is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_date.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.4, Section 4.1 (Table 6)
- [ISO 8601-1:2019] 4.2.1, 4.3.2
- [RFC3339] Sections 5.6, 5.7
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
birth_datein the device retrieval mdoc response was verified.
Test Scenario
- Verify the value of date-fullyear.
- Verify the value of date-month.
- Verify the value of date-mday.
Expected results
- The value of date-fullyear is between "0000" and "9999" inclusive.
- The value of date-month is between "01" and "12" inclusive.
- The value of date-mday is between "01" and the maximum value specified in section 5.7 of RFC 3339 inclusive.
WS_RP_DM_IdentifyingData_Birthplace_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim place_of_birth is present in the Credential in IETF SD-JWT VC format. Note that place_of_birth is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier birth_place.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
place_of_birthin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
place_of_birthis present.
WS_RP_DM_IdentifyingData_Birthplace_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim place_of_birth is encoded as a JSON structure. Note that place_of_birth is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier birth_place.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 7)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
place_of_birthin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that claim is encoded as a JSON structure.
Expected results
- The claim is encoded as a JSON structure.
WS_RP_DM_IdentifyingData_Birthplace_PID_ISO-mdoc_001
Objective
This test case verifies that the data element place_of_birth is present in the mdoc data. Note that place_of_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_place.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1".
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
place_of_birthin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementplace_of_birth.
Expected results
- One data element with identifier
place_of_birthis present. - There is no
ErrorItemfor data elementplace_of_birth.
WS_RP_DM_IdentifyingData_Birthplace_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element place_of_birth is a well-formed CBOR map. Note that place_of_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_place.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1".
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
place_of_birthin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 5.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_IdentifyingData_Birthplace_PID_ISO-mdoc_003
Objective
This test case verifies that the correct key-value pairs are present in each data element present in place_of_birth. Note that place_of_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_place.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.5, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1".
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
place_of_birthin the device retrieval mdoc response was verified.
Test Scenario
For each item present, perform the following check: 1. Verify the value of the key for each nested key/value pair. 2. Verify that each key is unique within the data item.
Expected results
- The data element item contains between 1 and 3 pairs inclusive, with the following value(s) for the key/ value pair(s): — "country" (optional), — "region" (optional), — "locality" (optional).
- Each key is unique within the data item.
WS_RP_DM_IdentifyingData_Birthplace_PID_ISO-mdoc_004
Objective
This test case verifies that the value of each data element present in place_of_birth is a well-formed CBOR text string. Note that place_of_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_place.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.5, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1".
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
place_of_birthin the device retrieval mdoc response was verified.
Test Scenario
For each data item present, perform the following check for the value of the key/value pair: 1. Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
WS_RP_DM_IdentifyingData_Birthplace_PID_ISO-mdoc_005
Objective
This test case verifies that the country item of data element place_of_birth is a valid country code. Note that place_of_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_place.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.5, Section 4.1 (Table 6)
- [ISO/IEC 3166-1]
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The mdoc contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1".
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of the item ‘country’ in data element
place_of_birthin the device retrieval mdoc response was verified.
Test Scenario
- Verify that the value of the data element
countryin mapplace_of_birthcontains a valid country code.
Expected results
- The DataElementValue has two characters, an alpha-2 code, corresponding to a country name: Listed in ISO 3166-1:2020, 6.1. Not listed in ISO 3166-1:2020, 6.1. In this case, the user-assigned country codes may be used, which consist in the series of letters AA, QM to QZ, XA to XZ, and ZZ (ISO 3166-1:2020, 8.3).
WS_RP_DM_IdentifyingData_Birthplace_PID_ISO-mdoc_006
Objective
This test case verifies that the region item of data element place_of_birth has only UTF-8 characters, and maximum length of 150 characters. Note that place_of_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_place.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.5, Section 4.1 (Table 6)
- [ISO/IEC 3166-1]
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The mdoc contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1".
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of the item
regionin data elementplace_of_birthin the device retrieval mdoc response was verified.
Test Scenario
- Verify that the value of the data element
regionin mapplace_of_birth. - Check the length of the
regionvalue in mapplace_of_birth.
Expected results
- Values includes only UTF-8 characters.
- Length is equal or smaller than 150 characters.
WS_RP_DM_IdentifyingData_Birthplace_PID_ISO-mdoc_007
Objective
This test case verifies that the region item of data element place_of_birth has only UTF-8 characters, and maximum length of 150 characters. Note that place_of_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier birth_place.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [ISO/IEC 3166-1]
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The mdoc contains a Credential in mdoc format with DocType = "eu.europa.ec.eudi.pid.1".
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of the item ‘locality’ in data element
place_of_birthin the device retrieval mdoc response was verified.
Test Scenario
- Verify that the value of the data element
localityin mapplace_of_birth. - Check the length of the
localityvalue in mapplace_of_birth.
Expected results
- Value includes only UTF-8 characters.
- Length is equal or smaller than 150 characters.
WS_RP_DM_IdentifyingData_Familyname_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim family_name is present in the Credential in IETF SD-JWT VC format. Note that family_name is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier family_name.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
family_namein the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
family_nameis present.
WS_RP_DM_IdentifyingData_Familyname_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim family_name is a String encoded in UTF-8. Note that family_name is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier family_name.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 7)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
family_namein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
family_nameis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
family_nameis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_IdentifyingData_Familyname_PID_ISO-mdoc_001
Objective
This test case verifies that the data element family_name is present in the mdoc data. Note that family_name is the Attribute Identifier in ISO-mdoc for the Data Identifier family_name.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
family_namein the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementfamily_name.
Expected results
- One data element with identifier
family_nameis present. - There is no
ErrorItemfor data elementfamily_name.
WS_RP_DM_IdentifyingData_Familyname_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element family_name is a well-formed CBOR text string. Note that family_name is the Attribute Identifier in ISO-mdoc for the Data Identifier family_name.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
family_namein the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_IdentifyingData_Familyname_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the claim birth_family_name is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that birth_family_name is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier family_name_birth.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim birth_family_name is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
birth_family_namein the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
birth_family_nameis present.
WS_RP_DM_IdentifyingData_Familyname_PID_IETF-sd-jwt-vc_004
Objective
This test case verifies that the claim birth_family_name is a String encoded in UTF-8. Note that birth_family_name is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier family_name_birth.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 3 (Table 7)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim birth_family_name is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
birth_family_namein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
family_nameis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
birth_family_nameis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_IdentifyingData_Familyname_PID_ISO-mdoc_003
Objective
This test case verifies that the data element family_name_birth is present in the mdoc data if this is indicated in the ICS. Note that family_name_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier family_name_birth.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element family_name_birth is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
family_name_birthin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementfamily_name_birth.
Expected results
- One data element with identifier
family_name_birthis present. - There is no
ErrorItemfor data elementfamily_name_birth.
WS_RP_DM_IdentifyingData_Familyname_PID_ISO-mdoc_004
Objective
This test case verifies that the DataElementValue of data element family_name_birth is a well-formed CBOR text string. Note that family_name_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier family_name_birth.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element family_name_birth is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
family_name_birthin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_IdentifyingData_Givenname_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim given_name is present in the Credential in IETF SD-JWT VC format. Note that given_name is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier given_name.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
given_namein the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
given_nameis present.
WS_RP_DM_IdentifyingData_Givenname_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim given_name is a String encoded in UTF-8. Note that given_name is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier given_name.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 7)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
given_namein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
given_nameis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
given_nameis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_IdentifyingData_Givenname_PID_ISO-mdoc_001
Objective
This test case verifies that the data element given_name is present in the mdoc data. Note that given_name is the Attribute Identifier in ISO-mdoc for the Data Identifier given_name.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
given_namein the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementgiven_name.
Expected results
- One data element with identifier
given_nameis present. - There is no
ErrorItemfor data elementgiven_name.
WS_RP_DM_IdentifyingData_Givenname_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element given_name is a well-formed CBOR text string. Note that given_name is the Attribute Identifier in ISO-mdoc for the Data Identifier given_name.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
given_namein the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_IdentifyingData_Givenname_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the claim birth_given_name is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that birth_given_name is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier given_name_birth.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim birth_given_name is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
birth_given_namein the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
birth_given_nameis present.
WS_RP_DM_IdentifyingData_Givenname_PID_IETF-sd-jwt-vc_004
Objective
This test case verifies that the claim birth_given_name is a String encoded in UTF-8. Note that birth_given_name is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier given_name_birth.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim birth_given_name is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
birth_given_namein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
birth_given_nameis a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim
birth_given_nameis a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_IdentifyingData_Givenname_PID_ISO-mdoc_003
Objective
This test case verifies that the data element given_name_birth is present in the mdoc data if this is indicated in the ICS. Note that given_name_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier given_name_birth.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
given_name_birthin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementgiven_name_birth.
Expected results
- One data element with identifier
given_name_birthis present. - There is no
ErrorItemfor data elementgiven_name_birth.
WS_RP_DM_IdentifyingData_Givenname_PID_ISO-mdoc_004
Objective
This test case verifies that the DataElementValue of data element given_name_birth is a well-formed CBOR text string. Note that given_name_birth is the Attribute Identifier in ISO-mdoc for the Data Identifier given_name_birth.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
given_name_birthin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_IdentifyingData_Nationality_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim nationalities is present in the Credential in IETF SD-JWT VC format. Note that nationalities is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier nationality.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.2, Section 4.2 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
nationalitiesin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
nationalitiesis present.
WS_RP_DM_IdentifyingData_Nationality_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim nationalities is an array of strings. Note that nationalities is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier nationality.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.2, Section 4.2, item 3 (Table 7)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
nationalitiesin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
nationalitiesis an array of Strings. - Verify the number of items in the array.
Expected results
- The claim
nationalitiesis an array of strings. - There are >= 1 items in the array.
WS_RP_DM_IdentifyingData_Nationality_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that each string within the array of strings in the claim nationalities contains a valid country code. Note that nationalities is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier nationality.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.2, Section 4.2, item 3 (Table 7)
- [ISO 3166-1:2020] 6.1
- [ISO 3166-1:2020] 8.3
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
nationalitiesin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that each string within the array of strings in the claim
nationalitiescontains a valid country code.
Expected results
- Each string within an array of strings in the claim
nationalitieshas two characters, an alpha-2 code, corresponding to a country name: Listed in ISO 3166-1:2020, 6.1. Not listed in ISO 3166-1:2020, 6.1. In this case, the user-assigned country codes may be used, which consist in the series of letters AA, QM to QZ, XA to XZ, and ZZ (ISO 3166-1:2020, 8.3).
WS_RP_DM_IdentifyingData_Nationality_PID_ISO-mdoc_001
Objective
This test case verifies that the data element nationality is present in the mdoc data. Note that nationality is the Attribute Identifier in ISO-mdoc for the Data Identifier nationality.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.2, Section 4.1 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
nationalityin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementnationality.
Expected results
- One data element with identifier
nationalityis present. - There is no
ErrorItemfor data elementnationality.
WS_RP_DM_IdentifyingData_Nationality_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element nationality is an array of Alpha-2 country codes as specified in ISO 3166-1. Note that nationality is the Attribute Identifier in ISO-mdoc for the Data Identifier nationality.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.2, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
nationalityin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the number of items in the array.
Expected results
- The major type value is equal to 4.
- There are >= 1 items in the array.
WS_RP_DM_IdentifyingData_Nationality_PID_ISO-mdoc_003
Objective
This test case verifies that the DataElementValue of data element nationality contains a valid country code. Note that nationality is the Attribute Identifier in ISO-mdoc for the Data Identifier nationality.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.2, Section 4.1 (Table 6)
- [ISO 3166-1:2020] 6.1
- [ISO 3166-1:2020] 8.3
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
nationalityin the device retrieval mdoc response was verified.
Test Scenario
- Verify that the DataElementValue of the data element contains a valid country code.
Expected results
- The DataElementValue has two characters, an alpha-2 code, corresponding to a country name: Listed in ISO 3166-1:2020, 6.1. Not listed in ISO 3166-1:2020, 6.1. In this case, the user-assigned country codes may be used, which consist in the series of letters AA, QM to QZ, XA to XZ, and ZZ (ISO 3166-1:2020, 8.3).
WS_RP_DM_IdentifyingData_Nationality_PID_ISO-mdoc_004
Objective
This test case verifies that each entry in the Array contains a DataElementValue with a valid country code. Note that nationality is the Attribute Identifier in ISO-mdoc for the Data Identifier nationality.
References
- [PID rulebook] Annex 3.01 paragraph 3.1.2, Section 4.1 (Table 6)
- [ISO 3166-1:2020] 6.1
- [ISO 3166-1:2020] 8.3
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
nationalityin the device retrieval mdoc response was verified.
Test Scenario
- Verify that the Array data element contains valid country codes.
Expected results
- Each entry in the Array contains a DataElementValue that has two characters, an alpha-2 code, corresponding to a country name: Listed in ISO 3166-1:2020, 6.1. Not listed in ISO 3166-1:2020, 6.1. In this case, the user-assigned country codes may be used, which consist in the series of letters AA, QM to QZ, XA to XZ, and ZZ (ISO 3166-1:2020, 8.3).
WS_RP_DM_IdentifyingData_Personaladministrativenumber_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim personal_administrative_number is present in the Credential in IETF SD-JWT VC format if this is indicated in the ICS. Note that personal_administrative_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier personal_administrative_number.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim personal_administrative_number is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier personal_administrative_number in the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier personal_administrative_number is present.
WS_RP_DM_IdentifyingData_Personaladministrativenumber_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim personal_administrative_number is a String encoded in UTF-8. Note that personal_administrative_number is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier personal_administrative_number.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 4 (Table 8)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim personal_administrative_number is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim personal_administrative_number in the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim personal_administrative_number is a String encoded in UTF-8, supporting the full Unicode range.
Expected results
- The claim personal_administrative_number is a String encoded in UTF-8, supporting the full Unicode range.
WS_RP_DM_IdentifyingData_Personaladministrativenumber_PID_ISO-mdoc_001
Objective
This test case verifies that the data element personal_administrative_number is present in the mdoc data if this is indicated in the ICS. Note that personal_administrative_number is the Attribute Identifier in ISO-mdoc for the Data Identifier personal_administrative_number.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element personal_administrative_number is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier personal_administrative_number in the device retrieval mdoc response.
- Verify the absence of an
ErrorItemfor data element personal_administrative_number.
Expected results
- One data element with identifier personal_administrative_number is present.
- There is no
ErrorItemfor data element personal_administrative_number.
WS_RP_DM_IdentifyingData_Personaladministrativenumber_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element personal_administrative_number is a well-formed CBOR text string. Note that personal_administrative_number is the Attribute Identifier in ISO-mdoc for the Data Identifier personal_administrative_number.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element personal_administrative_number is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element personal_administrative_number in the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
- Verify the encoding of the data item value.
Expected results
- The major type value is equal to 3.
- All bytes in the data item value are UTF-8 encoded characters.
WS_RP_DM_IdentifyingData_Portrait_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim picture is present in the Credential in IETF SD-JWT VC format. Note that picture is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier portrait.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
picturein the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
pictureis present.
WS_RP_DM_IdentifyingData_Portrait_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim picture is a String. Note that picture is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier portrait.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
picturein the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
pictureis a String.
Expected results
- The claim
pictureis a String.
WS_RP_DM_IdentifyingData_Portrait_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the claim picture is a data URL containing a base64-encoded picture in JPEG format. Note that picture is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier portrait.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 7)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in IETF SD-JWT VC format. vct claim includes base type of person identification "urn:eudi:pid:1".
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
picturein the IETF SD-JWT VC Credential presented was verified. - It was verified that the claim
pictureis a String.
Test Scenario
- Verify that claim
pictureis a data URL containing a base64-encodedpicturein JPEG format.
Expected results
- The claim
pictureis a data URL containing a base64-encodedpicturein JPEG format.
WS_RP_DM_IdentifyingData_Portrait_PID_ISO-mdoc_001
Objective
This test case verifies that the data element portrait is present in the mdoc data. Note that portrait is the Attribute Identifier in ISO-mdoc for the Data Identifier portrait.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 1)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
portraitin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementportrait.
Expected results
- One data element with identifier
portraitis present. - There is no
ErrorItemfor data elementportrait.
WS_RP_DM_IdentifyingData_Portrait_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element portrait is a well-formed CBOR byte string. Note that portrait is the Attribute Identifier in ISO-mdoc for the Data Identifier portrait.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
portraitin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
Expected results
- The major type value is equal to 2.
WS_RP_DM_IdentifyingData_Portrait_PID_ISO-mdoc_003
Objective
This test case verifies that the DataElementValue of data element portrait contains a valid encoded portrait image. Note that portrait is the Attribute Identifier in ISO-mdoc for the Data Identifier portrait.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
EUDI-wallet relevancy
EUDI_specific | EUDI_required
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = “eu.europa.ec.eudi.pid.1”
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
portraitin the device retrieval mdoc response was verified.
Test Scenario
- Verify the first two bytes of the CBOR byte string.
- Verify that the encoded image format corresponds to the value of the first two bytes.
Expected results
- The first two bytes are equal to 'FF D8'.
- If the first two bytes of the CBOR byte string are equal to: 'FF D8', the byte string contains a JPEG encoded image.
WS_RP_DM_IdentifyingData_Sex_PID_IETF-sd-jwt-vc_001
Objective
This test case verifies that the claim sex is present in the Credential in IETF SD-JWT VC format. Note that sex is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier sex.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim sex is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
Test Scenario
- Verify the presence of a claim with identifier
sexin the Credential presented to the Verifier in IETF SD-JWT VC format.
Expected results
- One claim with identifier
sexis present.
WS_RP_DM_IdentifyingData_Sex_PID_IETF-sd-jwt-vc_002
Objective
This test case verifies that the claim sex is a Number. Note that sex is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier sex.
References
- [PID rulebook] Annex 3.01, Section 4.2, item 4 (Table 8)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim sex is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
sexin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
sexis a Number.
Expected results
- The claim
sexis a Number.
WS_RP_DM_IdentifyingData_Sex_PID_IETF-sd-jwt-vc_003
Objective
This test case verifies that the claim sex contains a valid value. Note that sex is the Attribute Identifier in IETF SD-JWT VC for the Data Identifier sex.
References
- [PID rulebook] Annex 3.01, Section 4.2 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in SD-JWT VC format with vct = "urn:eudi:pid:". The claim sex is included in a person identification data.
Preconditions
- A presentation request was sent to the EUDI wallet, to retrieve a PID Credential in IETF SD-JWT VC format.
- All mandatory data elements within namespace "urn:eudi:pid:" and all data elements indicated as present in the ICS were requested.
- EUDI wallet presented the Credential successfully.
- The presence of claim
sexin the IETF SD-JWT VC Credential presented was verified.
Test Scenario
- Verify that the claim
sexcontains a valid value for Sex.
Expected results
- The claim
sexhas one of the values specified in ISO/IEC 5218:2004, 2, i.e. 0, 1, 2 or 9 or one of the other values specified for Europe (i.e. 3, 4, 5, 6).
WS_RP_DM_IdentifyingData_Sex_PID_ISO-mdoc_001
Objective
This test case verifies that the data element sex is present in the mdoc data if this is indicated in the ICS. Note that sex is the Attribute Identifier in ISO-mdoc for the Data Identifier sex.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 2)
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element sex is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
Test Scenario
- Verify the presence of a data element with identifier
sexin the device retrieval mdoc response. - Verify the absence of an
ErrorItemfor data elementsex.
Expected results
- One data element with identifier
sexis present. - There is no
ErrorItemfor data elementsex.
WS_RP_DM_IdentifyingData_Sex_PID_ISO-mdoc_002
Objective
This test case verifies that the DataElementValue of data element sex is a well-formed CBOR unsigned integer. Note that sex is the Attribute Identifier in ISO-mdoc for the Data Identifier sex.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [RFC7049] Section 2.1
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element sex is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
sexin the device retrieval mdoc response was verified.
Test Scenario
- Verify the major type encoded on the first byte of the CBOR data item.
Expected results
- The major type value is equal to 0.
WS_RP_DM_IdentifyingData_Sex_PID_ISO-mdoc_003
Objective
This test case verifies that the DataElementValue of data element sex contains a valid value. Note that sex is the Attribute Identifier in ISO-mdoc for the Data Identifier sex.
References
- [PID rulebook] Annex 3.01, Section 4.1 (Table 6)
- [ISO/IEC 5218:2004] 2
EUDI-wallet relevancy
EUDI_specific | EUDI_optional
Profile applicability
The EUDI wallet contains a Credential in ISO-mdoc format with DocType = "eu.europa.ec.eudi.pid.1". Data element sex is present in the mdoc data.
Preconditions
- A device retrieval mdoc request was sent to the EUDI wallet, to retrieve the document with DocType = "eu.europa.ec.eudi.pid.1".
- All mandatory data elements within namespace "eu.europa.ec.eudi.pid.1" and all data elements indicated as present in the ICS were requested.
- The device retrieval mdoc response was retrieved.
- The presence of data element
sexin the device retrieval mdoc response was verified.
Test Scenario
- Verify that the DataElementValue of the data element contains a valid value for Sex.
Expected results
- The DataElementValue has one of the values specified in ISO/IEC 5218:2004, 2, i.e. 0, 1, 2 or 9 or one of the other values specified for Europe (i.e. 3, 4, 5, 6).
Interaction
Interaction - Engagement
WS_RP_IA_Engagement_001
Objective
Verify that, in the presentation flow via Redirects, wallet can be invoked through custom URL scheme haip-vp:// if that is supported by Wallet and Verifier profiles.
References
- [HAIP] Section 5.1
Profile applicability
Presentations via Redirects; Wallet supports to be invoked through custom URL scheme "haip-vp://".
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Verifier invokes the Wallet through custom URL scheme
haip-vp://. - Verify if Wallet is invoked successfully.
Expected results
- This is the case.
- Wallet is invoked successfully.
WS_RP_IA_Engagement_002
Objective
Verify that Wallet supports invocation via the W3C Digital Credentials API or an equivalent platform API.
References
- [HAIP] Section 5.2
Profile applicability
Presentations via the W3C Digital Credentials API or equivalent platform.
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Verifier invokes Wallet via W3C Digital Credentials API or an equivalent platform API.
- Verify if Wallet is invoked successfully.
Expected results
- This is the case.
- Wallet is invoked through W3C Digital Credentials API or an equivalent platform API successfully.
Interaction - Main interaction
WS_RP_IA_MainInteraction_003
Objective
Test the Wallet accepts and processes DCQL-query with credential property "trusted_authorities", matching and returning a credential issued by an Issuer matching one of the Issuers identified in 'trusted_authorities'.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains more than one credential from the issuer specified in the request.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with a valid "trusted_authorities" property.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet returns response without error and every Credential returned by the Wallet matches at least one of the conditions present in the corresponding trusted_authorities array.
WS_RP_IA_MainInteraction_004
Objective
Test the Wallet accepts and processes DCQL-query with credential property "trusted_authorities", but handles the situation when it does not have any credential issued by an Issuer matching one of the Issuers identified in 'trusted_authorities'.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains no credential from the issuer specified in the request.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with a valid "trusted_authorities" property.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet cannot respond with a Credential, by either:
a. answering with an error with details (
access_denied), b. answering with an error without providing details or, c. discontinuing the interaction.
WS_RP_IA_MainInteraction_005
Objective
Test that the Wallet processes DCQL-query with credential property "require_cryptographic_holder_binding" with value true, by handling credentials with cryptographic holder binding.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a credential of a specified credential type, where the credential has cryptographic holder binding.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a valid DCQL-query with a 'credential' with:
a. the "require_cryptographic_holder_binding" property present with value
true. b. a 'claims' property requesting the specified credential type. - The Wallet evaluates the request and allows the user to continue with presenting matching credentials.
- User selects the available credential and approves to present it.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet allows the user to select the credential of the specified type.
- The wallet presents the selected credential to the verifier with a cryptographic proof of holder binding.
WS_RP_IA_MainInteraction_006
Objective
Test that the Wallet processes DCQL-query with credential property "require_cryptographic_holder_binding" with value true, by handling credentials without cryptographic holder binding.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a credential of a specified credential type, where the credential does not have cryptographic holder binding.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with:
a. the "require_cryptographic_holder_binding" property present with value
true. b. a 'claims' property requesting the specified credential type. - The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet informs the user it has no matching credential available, and does not continue to present any credential to the verifier.
WS_RP_IA_MainInteraction_007
Objective
Test that the Wallet processes DCQL-query with credential property "require_cryptographic_holder_binding" with value false, by handling credentials with cryptographic holder binding.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a credential of a specified credential type, where the credential has cryptographic holder binding.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a valid DCQL-query with a 'credential' with:
a. the "require_cryptographic_holder_binding" property present with value
false. b. a 'claims' property requesting the specified credential type. - The Wallet evaluates the request and allows the user to continue with presenting matching credentials.
- User selects the available credential and approves to present it.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet allows the user to select the credential of the specified type.
- The wallet presents the selected credential to the verifier with a cryptographic proof of holder binding.
WS_RP_IA_MainInteraction_008
Objective
Test that the Wallet processes DCQL-query with credential property "require_cryptographic_holder_binding" with value false, by handling credentials without cryptographic binding.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a credential of a specified credential type, where the credential does NOT have cryptographic holder binding.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a valid DCQL-query with a 'credential' with:
a. the "require_cryptographic_holder_binding" property present with value
false. b. a 'claims' property requesting the specified credential type. - The Wallet evaluates the request and allows the user to continue with presenting matching credentials.
- The user selects and approves and presents the credential without cryptographic holder binding.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet allows the user to select the credential of the specified type.
- The wallet successfully presents the selected credential to the verifier
WS_RP_IA_MainInteraction_010
Objective
Test that the Wallet processes DCQL-query without a credential property "require_cryptographic_holder_binding" as if it had value true.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains credentials of a specified type, with both a credential that has and a credential that does not have cryptographic holder binding.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a 'credential' without the "require_cryptographic_holder_binding" property
- The Wallet evaluates the request and allows the user to continue with presenting matching credentials.
- User selects the available credential(s) and approves to present it.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet allows the user to select only the credential that has cryptographic holder binding.
- The wallet presents the selected credential to the verifier with a cryptographic proof of holder binding.
WS_RP_IA_MainInteraction_012
Objective
Verify the Wallet sends only the specific claims requested by the Verifier
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet has claims (Name, address, phone)
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query asking only for name claim.
- Wallet sends only specific claim requested
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet hides "Address" and "Phone." Presents user with name claim on UI.
WS_RP_IA_MainInteraction_013
Objective
Verify that if a User unchecks a claim in the Wallet UI, it is excluded from the response.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query requesting claims "name" and "address", which the wallet has both.
- Unchecking claim in UI excludes it from the response.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- User unselects "address" claim in the UI, that claim is absent in the vp_token.
WS_RP_IA_MainInteraction_014
Objective
A Credential presentation may include "extra" claims not selected according to rules, if they are requested by a different query within the same session.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet has one ID with Name, Address, and Age.
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends one request with two DCQL queries: Query 1: Asks for Name. Query 2: Asks for Address
- Wallet handles query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request. 3a. The Wallet identifies that both queries can be satisfied by the same credential. It selects the "union" of both requests (Name + Address). 3b. The vp_token contains both Name and Address. Age remains hidden.
WS_RP_IA_MainInteraction_015
Objective
A Credential presentation may include "extra" claims not selected according to rules, if they are non-selective (fixed) technical fields that cannot be hidden.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet has an SD-JWT credential. By definition, the vct (type) and iss (issuer) fields are fixed/mandatory and cannot be hidden.
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query asking only for
given_name. - Response
Expected results
- Wallet and Verifier can interact.
- The Wallet selects
given_namebut must also include the mandatory envelope data required to make the credential cryptographically valid. - The vp_token contains
given_namePLUS the mandatory technical fields (e.g., vct, iss, iat).
WS_RP_IA_MainInteraction_016
Objective
Test that when claims is absent in the request the Wallet MUST return only the claims that are mandatory to present, NO selectively disclosable claims.
References
- [OpenID4VP] Section 6.4
Profile applicability
SD-JWT
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet holds an SD-JWT Credential containing multiple claims: given_name, family_name, and birthdate.
Test Scenario
- The Wallet engages with the Verifier
- A Verifier sends a request for a Credential the wallet holds, but the claims object is absent.
- Wallet handles request
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet generates a valid response containing signature and key binding, but one which contains zero disclosures.
WS_RP_IA_MainInteraction_017
Objective
Test that when claims is absent in the request the Wallet MUST return only the claims that are mandatory to present, NO selectively disclosable claims.
References
- [OpenID4VP] Section 6.4
Profile applicability
ISO mDL
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet holds an ISO mDL with elements: family_name, document_number, and portrait.
Test Scenario
- The Wallet engages with the Verifier
- A Verifier sends a request for a Credential the wallet holds, but the claims object is absent.
- Wallet handles request
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet received query, and generates a valid response showing licence is authentic but giving zero personal data
WS_RP_IA_MainInteraction_018
Objective
Test that if claims is present, but claim_sets is absent the wallet treats all entries listed in claims as mandatory and returns them all.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credentials object with claims but no claim_sets
- Wallet processes DCQL
Expected results
- Wallet and Verifier can interact.
- Wallet received query
- Wallet identifies the missing claim_sets and returns all claims listed
WS_RP_IA_MainInteraction_019
Objective
Test that when a claim_sets is present, the Wallet automatically selects and returns only the first satisfiable combination from claim_sets based on the verifier's preference order, preventing disclosure of multiple sets.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains credentials that can satisfy all claim sets defined in the request.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a valid DCQL query containing a claim_sets property holding 3 distinct claim set objects in a specific order of preference.
- The Wallet generates a response and prompts the user to authorize the release of data.
- The wallet sends the response.
Expected results
- Wallet and Verifier can interact.
- The Wallet recieves the request.
- The user Authorizes the presentation without requiring them to manually choose between different claim sets.
- The Verifier receives a response containing only the data requested in the first claim set object, proving that the wallet automatically prioritised the first match and excluded all subsequent satisfiable sets.
WS_RP_IA_MainInteraction_020
Objective
Verify that if the Wallet can satisfy multiple options in claim_sets, it selects the one appearing earliest in the array.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet has data for #2 and #3 of verifiers claim_sets
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends claim_sets with 3 options (#1,#2,#3)
Expected results
- Wallet and Verifier can interact.
- Wallet responds with #2
WS_RP_IA_MainInteraction_021
Objective
Test If the Wallet cannot satisfy any of the options in the claim_sets, it MUST NOT return any claims.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Verifier sends a DCQL query with a claim_sets that includes a claim the Wallet does not have.
Expected results
- Wallet will not return any claims.
WS_RP_IA_MainInteraction_022
Objective
Test that Claim_sets MUST NOT be supported if claims is absent.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Verifier sends a DCQL query with a credential with claim_sets, but missing claims
Expected results
- Wallet identifies invalid query, returns error.
WS_RP_IA_MainInteraction_023
Objective
Test the Wallet SHOULD treat a claim as if it did not exist in the credential, if its value does not match the one held in the wallets credential.
References
- [OpenID4VP] Sections 6.4, 6.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Verifier sends a Claims Query containing a restriction on the values of a claim.
Expected results
- Wallet sees values do not match, logically considers that specific claim as not being present for this matching flow.
WS_RP_IA_MainInteraction_024
Objective
Verify that if the Wallet cannot pre-parse the data (e.g., it's encrypted), it still allows the user to proceed with the presentation rather than failing the request.
References
- [OpenID4VP] Section 6.4
Profile applicability
Encrypted data
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Verifier sends a DCQL query with a values restriction. The Wallet holds a matching credential, but the data is encrypted/locked (the Wallet can't check the value yet).
Expected results
- The Wallet identifies the Type matches and allows the user to present the credential anyway (as the Credential Type and Path match the request.)
WS_RP_IA_MainInteraction_025
Objective
Test that if the wallet can only return part of the claims in the claim_sets object, it will not return that set but move onto next one.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
Verifier sends a claim_set requiring 3 claims, but the Wallet only has 2 of them, it MUST NOT return that set. It must move to the next option in the array.
Expected results
The Wallet only has 2 of them, so it MUST NOT return that set. It must move to the next option in the array. The response should reflect this.
WS_RP_IA_MainInteraction_026
Objective
Test when the Wallet cannot deliver all claims requested by the Verifier, because it doesn't have one of them, then it does NOT return the respective Credential.
References
- [OpenID4VP] Sections 6.4, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a credential that satisfies only one of the two required claims requested by the Verifier.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a valid DCQL query requesting a specific credential type with 2 required claims.
- The Wallet processes the request.
Expected results
- Wallet and Verifier can interact.
- The Wallet does not prompt the user to release the partially matching credential, or indicates to the user that no matching credentials are available.
- The Verifier receives a privacy-preserving error response access denied.
WS_RP_IA_MainInteraction_027
Objective
Test when the Wallet cannot deliver all claims requested by the Verifier because one of them has a non-matching value, it does NOT return the respective Credential.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a credential that holds both requested claims, but one of those claims has a value that does not match the constraints requested by the Verifier.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a valid DCQL query requesting a specific credential type with 2 required claims containing specific value constraints.
- The Wallet processes the request.
Expected results
- Wallet and Verifier can interact.
- The Wallet does not prompt the user to release the non-matching credential, or indicates to the user that no valid matching credentials are available.
- The Verifier receives a privacy-preserving response completely excluding the credential with the non-matching value.
WS_RP_IA_MainInteraction_028
Objective
Test the wallet for non-selectively disclosable credentials, treats an empty query (no claims or claim_sets) as a request for the entire credential rather than returning an error or an empty token.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet holds credential that does NOT support selective disclosure
Test Scenario
- Verifier sends a DCQL query with a credentials object with no claims or claim_sets
- Wallet processes DCQL
Expected results
- Wallet received query
- Wallet identifies the format as non-selective and interprets the missing claims as a "Full Disclosure" request.
WS_RP_IA_MainInteraction_029
Objective
Test that if credential_sets is provided, the wallet evaluates the request by satisfying all required or omitted Credential Set Queries in the array, while treating Credential Set Queries explicitly marked as required false as optional.
References
- [OpenID4VP] Sections 6.2, 6.4.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a valid credential that satisfies the criteria for Credential Query A, but does not contain any credential that satisfies Credential Query B.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a valid DCQL query containing a credential_sets array with two Credential Set Query objects: Set 1: Contains an options array for Credential Query A and is marked as required: true. Set 2: Contains an options array for Credential Query B and is explicitly marked as required: false.
- The Wallet processes the request.
Expected results
- Wallet and Verifier can interact.
- The Wallet prompts the user to release the credential matching Credential Query A, indicating that the overall presentation requirements can be met despite the missing optional credential.
- The Verifier receives an response containing the credential for Credential Query A, completing the interaction successfully.
WS_RP_IA_MainInteraction_030
Objective
Test the Wallet returns presentations of a set of Credentials that match to one of the options inside the Credential Set Query.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query, including a "credential_sets"; "credentials" includes 1 the wallet has, 1 it does not, "credential_sets" contains one set with the existing credential in wallet.
- Wallet handles query
Expected results
- Wallet and Verifier can interact.
- Wallet received query
- The wallet returns the credential set that matched
WS_RP_IA_MainInteraction_031
Objective
Test the Wallet will not return presentations of a set of Credentials that do NOT match to one of the options inside the Credential Set Query.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query, including a "credential_sets"; "credentials" includes 1 the wallet has, 1 it does not, "credential_sets" contains one set with both an existing credential and a non-existing credential in wallet.
- Wallet handles query
Expected results
- Wallet and Verifier can interact.
- Wallet received query
- The wallet does NOT return the credential set
WS_RP_IA_MainInteraction_032
Objective
Test that the wallet does not return credentials if they do not match the requested constraints.
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet has PID saying (over 18: false)
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query, asking for matching credential to wallet where the PID is (over 18: true)
- Wallet handles query
Expected results
- Wallet and Verifier can interact.
- Wallet received query
- Wallet sees that constraint is not passed in the matching credential request and hence the credential is not offered. If no others are available wallet states that: I have no credentials to meet your requirement.
WS_RP_IA_MainInteraction_033
Objective
Verify that the Wallet correctly evaluates a combination of value constraints in a single DCQL Query, withholding any credentials that fail even a single individual requested criterion.
References
- [OpenID4VP] Section 6.4
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Profile applicability
none
Preconditions
The wallet contains multiple credentials of the same type, provisioned as follows:
Credential A (Full Match): Perfectly satisfies all criteria, including an expiry = 2025
Credential B1 (Fails Age): Matches everything else, but age = 17.
Credential B2 (Fails Data Type): Matches everything else, but kg = 10.5 (float mismatch).
Credential B3 (Fails Case): Matches everything else, but country = "Spain" (capitalized).
Credential B4 (Fails Whitespace): Matches everything else, but name = "Smith" (missing trailing space).
Credential B5 (Fails Encoding): Matches everything else, but city = "Munchen" (missing umlaut).
Credential B6 (Fails Array): Matches everything else, but array = ["FR", "DE"] (multi-element array).
Credential B7 (Fails Expiry Boundary): Matches everything else, but expiry = 2026 (violates <= condition).
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a single DCQL query targeting a single credential with the following combined value constraints:
* Logical boundaries:
age >= 18andexpiry <= 2025* Data type strictness:kg == 10* Case sensitivity:country == "spain"* Whitespace sensitivity:name == "Smith "* Character encoding:city == "München"* Array constraints: Requesting a single-element array["FR"] - The Wallet processes the request.
Expected results
- Wallet and Verifier successfully initiate interaction.
- The Wallet only prompts the user to release Credential A.
- The Wallet completely excludes all target "trap" credentials (B1 through B7) from the user selection prompt.
WS_RP_IA_MainInteraction_034
Objective
Test when the Wallet cannot deliver all non-optional Credentials requested by the Verifier, it MUST NOT return any Credential(s).
References
- [OpenID4VP] Section 6.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The verifier sends a DCQL query requesting 2 non-optional credentials; The wallet only has 1 of them
- Wallet handles query
Expected results
- Wallet sees it can return 1 credential, it cannot return the other
- Wallet does NOT return EITHER credential, sends a privacy keeping requirement not met response
WS_RP_IA_MainInteraction_035
Objective
Test that the wallet returns the VP token in the Authorization response if the response type value is vp_token.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a valid, matching credential requested by the Verifier.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with the response_type value set to vp_token and a valid dcql_query requesting the wallet's stored credential.
- The Wallet processes the request and the user Authorizes the presentation.
Expected results
- Wallet and Verifier can interact.
- The Wallet prompts the user to release the requested credential.
- The Verifier receives an Authorization Response containing a valid vp_token parameter holding the cryptographically signed credential data.
WS_RP_IA_MainInteraction_036
Objective
Test that the vp_token parameter returned by the wallet must be a JSON-encoded object.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a valid, matching credential requested by the Verifier.
Test Scenario
- The wallet engages with the verifier.
- The Verifier sends an Authorization Request with a valid dcql_query requesting the wallet's stored credential.
- The Wallet processes the request, the user Authorizes the presentation, and the wallet transmits the response payload.
Expected results
- Wallet and Verifier can interact.
- The Wallet prompts the user to release the requested credential.
- The Verifier receives an Authorization Response where the vp_token parameter is successfully parsed as a valid, well-formed JSON object containing the requested credential structure.
WS_RP_IA_MainInteraction_037
Objective
Test that the vp_token parameter returned by the wallet, contains ID(s), aligning with the ID value of the credential query.
References
- [OpenID4VP] Section 8.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a valid, matching credential requested by the Verifier.
Test Scenario
- The wallet engages with the verifier.
- The Verifier sends an Authorization Request with a valid dcql_query requesting the wallet's stored credential using a specific, defined credential query ID.
- The Wallet processes the request, the user Authorizes the presentation, and the wallet transmits the response payload.
Expected results
- Wallet and Verifier can interact.
- The Wallet prompts the user to release the requested credential.
- The Verifier receives an Authorization Response where the top-level keys within the vp_token object exactly match the credential query ID specified in the request.
WS_RP_IA_MainInteraction_038
Objective
Test that the vp_token parameter returned by the wallet contains entries where the value(s) are formatted as array(s) of presentation(s) matching the respective credential query ID.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a valid, matching credential requested by the Verifier.
Test Scenario
- The wallet engages with the verifier.
- The Verifier sends an Authorization Request with a valid dcql_query requesting the wallet's stored credential using a specific, defined credential query ID.
- The Wallet processes the request, the user Authorizes the presentation, and the wallet transmits the response payload.
Expected results
- Wallet and Verifier can interact.
- The Wallet prompts the user to release the requested credential.
- The Verifier receives an Authorization Response where the value associated with the credential query ID key inside the vp_token parameter is an array containing the requested presentation data.
WS_RP_IA_MainInteraction_039
Objective
Test that when the wallet returns a vp_token parameter for a multi-credential request, all returned key-value pairs simultaneously and correctly match their respective credential queries.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains two distinct valid credentials that can satisfy separate queries simultaneously.
Test Scenario
- The wallet engages with the verifier.
- The Verifier sends an Authorization Request with a valid dcql_query requesting two separate credentials using two distinct query IDs.
- The Wallet processes the request, the user Authorizes the presentation of both credentials, and the wallet transmits the response payload.
Expected results
- Wallet and Verifier can interact.
- The Wallet prompts the user to release both requested credentials.
- The Verifier receives an Authorization Response where the vp_token parameter is a single JSON object containing both distinct keys, with each key strictly mapping to its respective signed presentation value.
WS_RP_IA_MainInteraction_040
Objective
Test that if the multiple parameter is omitted in a credential query, it defaults to false, and the wallet includes only one presentation in the corresponding response array.
References
- [OpenID4VP] Sections 8, 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains at least two distinct valid credentials that can satisfy the same single credential query (e.g., two different digital diplomas).
Test Scenario
- The wallet engages with the verifier.
- The Verifier sends an Authorization Request with a valid dcql_query requesting a credential, where the multiple attribute for that query is completely omitted.
- The Wallet processes the request, the user selects and Authorizes the maximum no. of credential for presentation allowed, and the wallet transmits the response payload.
Expected results
- Wallet and Verifier can interact.
- The Wallet recieves request.
- The Verifier receives an Authorization Response where the array associated with the credential query ID inside the vp_token object contains exactly one presentation.
WS_RP_IA_MainInteraction_041
Objective
Test that if the multiple parameter is explicitly set to false in a credential query, the wallet includes only one presentation in the corresponding response array.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains at least two distinct valid credentials that can satisfy the same single credential query.
Test Scenario
- The wallet engages with the verifier.
- The Verifier sends an Authorization Request with a valid dcql_query requesting a credential, where the multiple attribute for that query is explicitly set to false.
- The Wallet processes the request, the user selects and Authorizes the maximum no. of credential for presentation allowed, and the wallet transmits the response payload.
Expected results
- Wallet and Verifier can interact.
- The Wallet recieves request.
- The Verifier receives an Authorization Response where the array associated with the credential query ID inside the vp_token object contains exactly one presentation.
WS_RP_IA_MainInteraction_042
Objective
Test the wallet does NOT include entries in the vp_token, for optional Credential Queries, when there are no matching Credentials.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet does NOT contain credential A. Wallet does contain credential B.
Test Scenario
- The wallet engages with the verifier.
- The verifier sends a request where credential query includes an optional credential A, along with a non-optional credential B.
- The wallet returns a vp_token parameter in its response
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request, and user gives permission.
- Verify the vp_token entries contains only credential B
WS_RP_IA_MainInteraction_043
Objective
Test the wallet omits optional DCQL query keys in the presentation when no matching credentials exist.
References
- [OpenID4VP] Section 8.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet does NOT contain matching credentials for the queries optional credentials.
Test Scenario
- The wallet engages with the verifier.
- The verifier sends a request where credential query includes some optional credentials.
- The wallet returns an empty vp_token parameter in its response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request, user gives consent.
- Verify the vp_token returned is empty and does NOT contain key IDs from the optional credentials.
WS_RP_IA_MainInteraction_046
Objective
Test for responses of size > URL limits of user agents, the Wallet can respond to the Verifier using the direct_post mechanism.
References
- [OpenID4VP] Section 8
Profile applicability
Same device response_mode=direct_post.jwt
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a large credential where the resulting presentation size exceeds the typical URL length limit of a user agent.
Test Scenario
- The wallet engages with the verifier.
- The verifier sends a request for the large credential, with parameter
response_mode=direct_post.jwtand aresponse_uriof the verifier. - The wallet processes the request.
- The wallet responds with an Authorization response.
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- The wallet processes the request successfully, recognises that the response exceeds the user-agent URL limit, and prepares to submit it to the response_uri.
- Verify the wallet submits the response to the response_uri, with the Authorization Response as body of the HTTP-request using the POST method.
WS_RP_IA_MainInteraction_049
Objective
Test when using response mode "direct_post.jwt" the Wallet encodes the Authorization Response, in the HTTP POST request body, using format defined by application/x‑www‑form‑urlencoded.
References
- [OpenID4VP] Section 8
Profile applicability
Same device custom URL
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends a request, with parameter
response_mode=direct_post.jwtand aresponse_uriof the verifier. - The wallet processes the request.
- The wallet responds with request object
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- The wallet processes the request successfully and prepares an Authorization Response encoded as application/x-www-form-urlencoded for submission to the response_uri.
- Verify the wallet submits the response including the Authorization Response encoded using format defined by application/x‑www‑form‑urlencoded.
WS_RP_IA_MainInteraction_052
Objective
Test all parameters in the HTTP POST request body are encoded using UTF‑8.
References
- [OpenID4VP] Section 8
Profile applicability
Same device response_mode=direct_post.jwt
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends a request, with parameter
response_mode=direct_post.jwtand aresponse_uriof the verifier. - The wallet processes the request.
- The wallet responds with an Authorization response.
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- The wallet processes the request successfully and prepares the HTTP POST body with all parameters encoded using UTF-8.
- Verify that all parameters in the HTTP POST request body are encoded using UTF‑8.
WS_RP_IA_MainInteraction_053
Objective
Test that the wallet rejects a request when the response_uri parameter is missing and when Response Mode = direct_post.jwt
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends a request, with parameter
response_mode=direct_post.jwtand missingresponse_uriparameter. - The wallet processes the request.
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- Wallet returns an error.
WS_RP_IA_MainInteraction_054
Objective
Test that the Wallet sends the Authorization Response to the provided response_uri using an HTTP POST request.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends a request, with parameter
response_mode=direct_post.jwtand aresponse_uriof the verifier. - The wallet processes the request.
- The wallet responds with an Authorization response.
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- The wallet processes the request successfully and prepares the Authorization Response for submission to the response_uri.
- Verify the wallet submits the response to the response_uri
WS_RP_IA_MainInteraction_055
Objective
When the response_uri parameter is present, the redirect_uri Authorization Request parameter MUST NOT be present.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends a request, with parameter
response_mode=direct_post.jwtand aresponse_uriof the verifier, AND a redirect_uri. - The wallet processes the request.
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- Wallet returns an error.
WS_RP_IA_MainInteraction_056
Objective
Test that the Wallet validates the response_uri according to the strict matching rules defined in [OID4VP] Section 5.9, and rejects the request if the value is invalid.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends a request, with parameter
response_mode=direct_post.jwtand an invalidresponse_uri(not following rules in [OID4VP] section 5.9) - The wallet processes the request.
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- Wallet returns an error.
WS_RP_IA_MainInteraction_057
Objective
Test that Wallet accepts an HTTP 200 response with Content-Type: application/json after sending the Authorization Response to the response_uri.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends a request, with parameter 'response_mode=direct_post.jwt', and a valid response_uri.
- The wallet processes the request.
- The wallet responds with an Authorization response.
- Verifier sends an HTTP status code of 200 + a JSON body
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- The wallet processes the request successfully and submits the Authorization Response to the response_uri.
- The verifier returns an HTTP 200 status code with a JSON body containing a redirect URL or equivalent post-response payload.
- Wallet does NOT return an error, returns user to URL provided in the redirect_uri parameter.
WS_RP_IA_MainInteraction_060
Objective
Test the Wallet redirects the user agent to the redirect_uri if this parameter is included in the initial Authorization Request.
References
- [OpenID4VP] Section 8
Profile applicability
Same device response_mode=direct_post
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends an Authorization request, with response_type=vp_token, and parameter redirect_uri.
- The wallet processes the request.
- The wallet constructs the URL.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The wallet processes the request successfully and proceeds to construct the URL with the Authorization Response appended.
- Verify the wallet appends the Authorization response to the redirect_uri, opens URL in the browser.
WS_RP_IA_MainInteraction_061
Objective
Test the Wallet handles a redirect_uri when a response_uri returns after a successful Response.
References
- [OpenID4VP] Section 8.2
Profile applicability
Same device response_mode=direct_post.jwt
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends an Authorization request, with response_type=vp_token, response_mode=direct_post.jwt and parameter response_uri.
- The wallet performs HTTP POST to the response_uri.
- The verifier responds with HTTP 200 and a JSON body containing a redirect_uri.
- Wallet processes JSON and triggers User agent.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The wallet posts the Authorization Response to the response_uri.
- Verify the wallet DOES NOT append the Authorization response to the redirect_uri.
- Wallet opens redirect_uri, shows user success page.
WS_RP_IA_MainInteraction_064
Objective
Test the Wallet handles a redirect_uri when a response_uri returns after an error response.
References
- [OpenID4VP] Section 8.2
Profile applicability
Same device response_mode=direct_post.jwt
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends an Authorization request, with response_type=vp_token, response_mode=direct_post.jwt and parameter response_uri.
- The wallet performs HTTP POST to the response_uri.
- The verifier responds with HTTP error 400 and a JSON body containing a redirect_uri.
- Wallet processes error and the JSON and triggers User agent.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The wallet posts the Authorization Response to the response_uri.
- Verify the Wallet recognizes the HTTP error status but successfully parses the redirect_uri from the error response body.
- Wallet opens redirect_uri
WS_RP_IA_MainInteraction_065
Objective
Verify that Wallet supports receiving a Credential Query from the Verifier in DCQL language, including the object trusted_authorities (aki)-based as defined in section 6.1.1.1 of [OIDF.OID4VP].
References
- [HAIP] Section 5
- [OpenID4VP] Section 6.1.1.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends an Authorization Request containing a DCQL credential query that specifies an Authority Key Identifier (AKI) inside the trusted_authorities object.
- The wallet processes the DCQL query and validates the requested trusted authorities against the credentials issued to the wallet.
- The wallet prompts the user for consent to present the matching credential.
- The user provides consent.
- The wallet transmits the Authorization Response back to the verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives the request.
- Verify that the Wallet correctly parses the trusted_authorities query without throwing a processing error or returning an invalid_request.
- Verify that the Wallet identifies the matching credential and presents consent to the user.
- User consent is captured successfully.
- Verify that the Wallet compiles the requested payload and successfully transmits the response to the verifier.
WS_RP_IA_MainInteraction_066
Objective
Verify the HAIP requirement that, in the presentation flow via Redirects, Wallet raises an error if Verifier does not include redirect_uri in the HTTP response to the Wallet's HTTP POST to the response_uri, as defined in section 8.2 of [OIDF.OID4VP].
References
- [HAIP] Section 5.1
- [OpenID4VP] Section 8.2
Profile applicability
Same device response_mode=direct_post.jwt OIDF.HAIP
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request using
response_modedirect_post.jwtand includingresponse_uri. - Verify if Wallet sends HTTP POST to
response_uri. - Verifier response to Wallet HTTP POST does not include
redirect_uri. - Wallet processes the request.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Wallet successfully sends the HTTP POST payload to the response_uri.
- The Verifier's response is received without a redirect_uri parameter.
- The Wallet raises an invalid_request error or terminates transaction.
WS_RP_IA_MainInteraction_067
Objective
Verify the HAIP requirement that, in the presentation flow via Redirects, Wallet follows redirect_uri sent by the Verifier.
References
- [HAIP] Section 5.1
- [OpenID4VP] Section 8.2
Profile applicability
Same device response_mode=direct_post.jwt OIDF.HAIP
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request using
response_modedirect_post.jwtand includingresponse_uri. - Verify if Wallet sends HTTP POST to
response_uri. - Verifier response to Wallet HTTP POST includes
redirect_uri. - Wallet processes the request.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Wallet successfully sends the HTTP POST payload to the response_uri.
- The Verifier's response is received containing the redirect_uri parameter.
- Verify the Wallet processes the response successfully and triggers the user agent to navigate to the redirect_uri sent by the Verifier.
Interaction - Metadata
WS_RP_IA_Metadata_008
Objective
Verify that when the Wallet receives an Authorization Request with response_mode = "direct_post.jwt" and a valid HTTPS response_uri, it sends the Authorization Response (vp_token) to the response_uri via an HTTP POST request using HTTPS
References
- [OpenID4VP] Sections 5.2, 8.2, 8.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request with response_mode = 'direct_post.jwt' and a valid HTTPS response_uri.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet sends the vp_token Authorization Response to the response_uri via an HTTP POST request using HTTPS; response body is encoded as application/x-www-form-urlencoded.
WS_RP_IA_Metadata_009
Objective
Verify that when the Wallet receives an Authorization Request with response_mode = "direct_post.jwt", it sends the Authorization Response to the response_uri as an encrypted JWE over HTTPS.
References
- [OpenID4VP] Sections 5.2, 8.2, 8.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request with response_mode = 'direct_post.jwt' requesting an encrypted response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet sends an encrypted Authorization Response (JWE) to the response_uri via HTTPS.
WS_RP_IA_Metadata_010
Objective
Verify that when the Wallet receives an Authorization Request with response_mode = "direct_post.jwt" where both response_uri and redirect_uri are present, it rejects the request with an invalid_request error since the two parameters are mutually exclusive.
References
- [OpenID4VP] Sections 5.2, 8.2, 8.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request with response_mode = 'direct_post.jwt' where redirect_uri is also present.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet returns an invalid_request error because redirect_uri and response_uri MUST NOT both be present.
WS_RP_IA_Metadata_011
Objective
Test that the wallet rejects the Authorization Request if aud does NOT match the issuer claim value in the wallet metadata.
References
- [OpenID4VP] Section 5.8
Profile applicability
Dynamic discovery
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The Wallet receives a Request Object (Dynamic Discovery) where the aud claim does NOT match the iss value in the wallet metadata.
- The Wallet returns a response to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- The Wallet rejects the Request Object due to the aud mismatch and does not proceed to credential selection or user authorization.
- The Wallet returns an error response (e.g. invalid_request).
WS_RP_IA_Metadata_012
Objective
Verify that when the Wallet receives a Request Object using Static Discovery metadata with the aud claim set to the SIOPv2 static identifier "https://self-issued.me/v2", it accepts and processes the request.
References
- [OpenID4VP] Section 5.8
Profile applicability
static discovery
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using Static Discovery metadata with the aud claim set to "https://self-issued.me/v2".
- Wallet parses the Request Object.
- Wallet validates the aud claim against the expected SIOPv2 static identifier.
- Wallet proceeds with request processing.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet validates that the aud claim equals "https://self-issued.me/v2".
- Wallet accepts and processes the request; the flow proceeds normally.
WS_RP_IA_Metadata_013
Objective
Verify that when the Wallet receives a Request Object using Static Discovery metadata with an aud claim whose value is NOT the SIOPv2 static identifier "https://self-issued.me/v2", it rejects the request and returns an invalid_request error.
References
- [OpenID4VP] Section 5.8
Profile applicability
static discovery
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using Static Discovery metadata with the aud claim set to a value OTHER than "https://self-issued.me/v2".
- Wallet parses the Request Object.
- Wallet validates the aud claim against the expected SIOPv2 static identifier.
- Wallet detects the mismatch.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet validates the aud claim and detects that it does not equal "https://self-issued.me/v2".
- Wallet rejects the request and returns an invalid_request error due to the invalid aud value.
WS_RP_IA_Metadata_014
Objective
Verify that when the Wallet receives an Authorization Request using the openid_federation Client Identifier Prefix with a resolvable Entity Identifier, the Wallet resolves the Entity via OpenID Federation and processes the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with client_id using the openid_federation: prefix containing a resolvable Entity Identifier.
- Wallet parses the Authorization Request.
- Wallet recognizes the openid_federation: prefix and resolves the Entity Identifier following OpenID Federation processing rules.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet successfully resolves the Entity via OpenID Federation and processes the request; presentation flow proceeds.
WS_RP_IA_Metadata_015
Objective
Verify that when the Wallet receives a Request Object using the decentralized_identifier Client Identifier Prefix with a resolvable DID Document and all non-key Verifier metadata present in client_metadata, the Wallet performs DID Resolution for the public key and obtains all other metadata from client_metadata.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using decentralized_identifier: prefix; client_metadata contains all non-key Verifier metadata; DID Document is resolvable.
- Wallet parses the Request Object.
- Wallet performs DID Resolution to obtain the public key.
- Wallet extracts all non-key Verifier metadata from client_metadata.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet successfully resolves the DID Document and obtains the public key.
- Wallet uses client_metadata for all non-key Verifier metadata; presentation flow proceeds.
WS_RP_IA_Metadata_016
Objective
Verify that when the Wallet receives a Request Object using the decentralized_identifier Client Identifier Prefix with an empty client_metadata parameter, the Wallet rejects the request since non-key Verifier metadata MUST be obtained from client_metadata.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using decentralized_identifier: prefix with an empty client_metadata parameter.
- Wallet parses the Request Object.
- Wallet attempts to extract non-key Verifier metadata.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet rejects the Authorization Request and returns an invalid_request error due to empty client_metadata (required for non-key Verifier metadata); presentation flow is not initiated.
WS_RP_IA_Metadata_017
Objective
Verify that Wallet states explicit in its metadata which other algorithms and key types are supported for the cryptographic operations.
References
- [HAIP] Section 7
Profile applicability
Wallet supports other crypto suites
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
none
Test Scenario
- Verifier obtains Wallet Metadata (dynamically, out of band mechanism, or pre-obtained static set).
- Check Wallet Metadata
Expected results
- This is the case.
- Verify if Wallet Metadata is explicit for which other algorithms and key types are supported for the cryptographic operations.
Interaction - Protocol Flow
WS_RP_IA_ProtocolFlow_001
Objective
Verify that when the Wallet receives a Request Object via the Request URI flow, it extracts the set of Authorization Request parameters from the Request Object and uses them for further processing.
References
- [OpenID4VP] Section 5.10.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request and receives a Request Object containing all required Authorization Request parameters.
- The Wallet processes the request and sends an Authorization Response to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully receives the Request Object.
- The Authorization Response sent by the Wallet is consistent with the parameter values from the Request Object.
WS_RP_IA_ProtocolFlow_002
Objective
Verify that, in the presentation flow via Redirects, the Wallet supports receiving a Signed Authorization Request using JWT-Secured Authorization Request (JAR) [RFC9101] with the request_uri parameter.
References
- [HAIP] Section 5.1
- [RFC9101] Section 5
Profile applicability
Presentations via Redirects
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- Signature from authorization request is authentic.
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends Signed Authorization Request using JWT-Secured Authorization Request (JAR) [RFC9101] with the
request_uriparameter, and signature is authentic. - Verify if the Wallet obtains the request object from the
request_uri. - Wallet checks signature on the request object.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet answers successfully (presents the Credential) without rejecting transaction.
Expected results
- This is the case.
- This is the case.
- Wallet obtains the request object from the
request_uri. - Wallet authenticates successfully request object signature.
- Wallet asks for user consent.
- This is the case.
- Wallet answers successfully (presents the Credential) without rejecting transaction.
Interaction - Supportive
WS_RP_IA_Supportive_%001
Objective
Verify that, in the presentation flow via Redirects, Wallet processes successfully HTTP response to the Wallet's HTTP POST to the response_uri, including redirect_uri.
References
- [HAIP] Section 5.1
- [OpenID4VP] Section 8.2
Profile applicability
Presentations via Redirects
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request using
response_modedirect_postand includingresponse_uri. - The Wallet sends an HTTP POST to the response_uri.
- Verifier responds to the Wallet's HTTP POST with a body including redirect_uri.
- Wallet processes the request.
Expected results
- The Verifier successfully initiates the presentation request flow with the end-user.
- The Wallet receives the presentation request with response_mode = direct_post and a response_uri parameter.
- The Wallet sends the Authorization Response to the response_uri via HTTP POST.
- The Wallet receives the verifier's HTTP response containing a redirect_uri.
- The Wallet successfully processes the verifier's response and opens the redirect_uri in the user agent.
WS_RP_IA_Supportive_002
Objective
Verify that upon any HTTP error response from the Request-URI endpoint the Wallet terminates the process.
References
- [OpenID4VP] Section 5.10.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request to the request_uri endpoint.
- Wallet receives an HTTP error response (e.g. 4xx or 5xx).
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully sends the POST request.
- Wallet terminates the Authorization Request process; presentation flow is not initiated.
WS_RP_IA_Supportive_006
Objective
Test the wallet returns the error message: wallet_unavailable when the device the wallet is located on is under extreme load and hence is out of RAM/ disk space.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Device is under extreme load
Test Scenario
- The wallet engages with verifier.
- The verifier sends a valid Authorization request.
- Wallet processes request
- Test the response returned by the wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request.
- Wallet cannot process request due to RAM/disk space.
- Verify the Wallet does NOT return a credential; instead, it returns an error response where the error parameter is exactly wallet_unavailable.
WS_RP_IA_Supportive_007
Objective
Verify that, in the presentation flow via Redirects, if Verifier sends a Signed Authorization Request, but it does not use a JWT-Secured Authorization Request (JAR) [RFC9101] with the request_uri parameter, the Wallet responds with an error (detailed or not) or discontinues the transaction.
References
- [HAIP] Section 5.1
- [RFC9101] Section 5
Profile applicability
Presentations via Redirects
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- In the flow via Redirects, Verifier sends a Signed Authorization Request, but it does not use JWT-Secured Authorization Request (JAR) [RFC9101] with the "request_uri" parameter.
- Wallet processes the request.
Expected results
- This is the case.
- This is the case.
- Wallet either:
a. Answers with an error with details (
invalid_request), b. Answers with an error without providing details or, c. Discontinues the interaction.
Message Structure
Message Structure - Credential Formats
WS_RP_MS_CredentialFormats_029
Objective
Verify that the EUDI Wallet can receive, hold and store a JWT Referenced Token that includes a status_list claim.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer issues a JWT Referenced Token with a status_list claim to the EUDI Wallet.
Test Scenario
- Verify that the Wallet accepts and stores the JWT Referenced Token.
Expected results
- The JWT Referenced Token with status_list claim is stored by the Wallet.
WS_RP_MS_CredentialFormats_030
Objective
Verify that the EUDI Wallet can receive, hold and store an SD-JWT Referenced Token that includes a status_list claim.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer issues a SD-JWT Referenced Token with a status_list claim to the EUDI Wallet.
Test Scenario
- Verify that the Wallet accepts and stores the SD-JWT Referenced Token.
Expected results
- The SD-JWT Referenced Token with status_list claim is stored by the Wallet.
WS_RP_MS_CredentialFormats_031
Objective
Verify that the EUDI Wallet can receive, hold and store an SD-JWT VC Referenced Token that includes a status_list claim.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer issues a SD-JWT VC Referenced Token with a status_list claim to the EUDI Wallet.
Test Scenario
- Verify that the Wallet accepts and stores the SD-JWT VC Referenced Token.
Expected results
- The SD-JWT VC Referenced Token with status_list claim is stored by the Wallet.
WS_RP_MS_CredentialFormats_032
Objective
Verify that the EUDI Wallet can receive, hold and store a CWT Referenced Token that includes a status claim.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer issues a CWT Referenced Token with a status claim to the EUDI Wallet.
Test Scenario
- Verify that the Wallet accepts and stores the CWT Referenced Token.
Expected results
- The CWT Referenced Token with status claim is stored by the Wallet.
WS_RP_MS_CredentialFormats_033
Objective
Verify that the EUDI Wallet can receive, hold and store an ISO mdoc Referenced Token that includes a status claim.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer issues a ISO mdoc Referenced Token with a status claim to the EUDI Wallet.
Test Scenario
- Verify that the Wallet accepts and stores the ISO mdoc Referenced Token.
Expected results
- The ISO mdoc Referenced Token with status claim is stored by the Wallet.
WS_RP_MS_CredentialFormats_034
Objective
Test that when a wallet matches a mdoc-based Credential, the CBOR values are matched by first converting to JSON.
References
- [OpenID4VP] Section 6.3
- [RFC8949] Section 6.1
Profile applicability
value matching with ISO mdoc is implemented by wallet
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends a DCQL query requesting a specific element from a mdoc
- Wallet handles Query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request. 3a. The Wallet retrieves the mdoc from secure storage, noting CBOR format. 3b. The Wallet converts the CBOR value into a JSON-compatible representation to compare it against the query filter - it uses the guidance from Section 6.1 of [RFC8949] to avoid issues like Data Type fidelity 3c. The Wallet performs the matching logic
WS_RP_MS_CredentialFormats_035
Objective
Verify that Wallet supports ISO mdoc in the presentation flow.
References
- [HAIP] Section 5 (introduction)
- [HAIP] Section 5.3.1
- [HAIP] Section 6
- [OpenID4VP] Appendix B.2
Profile applicability
Wallet supports ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in ISO mdoc format.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet presents Credential to the Verifier.
- Check value from Credential Format Identifier.
Expected results
- This is the case
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet presents Credential to the Verifier successfully.
- Credential presented has Credential Format Identifier value set to
mso_mdoc.
WS_RP_MS_CredentialFormats_036
Objective
Verify that Wallet supports IETF SD-JWT VC in the presentation flow.
References
- [HAIP] Section 5 (introduction)
- [HAIP] Section 5.3.2
- [HAIP] Section 6
- [OpenID4VP] Appendix B.3
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in IETF SD-JWT VC format.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet presents Credential to the Verifier.
- Check value from Credential Format Identifier.
Expected results
- This is the case.
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet presents Credential to the Verifier successfully.
- Credential presented has Credential Format Identifier value set to
dc+sd-jwt.
WS_RP_MS_CredentialFormats_037
Objective
Verify that Wallet supports IETF SD-JWT VC and ISO mdoc in the presentation flow.
References
- [HAIP] Section 5 (introduction)
- [HAIP] Section 5.3.2
- [HAIP] Section 6
- [OpenID4VP] Appendix B.3
Profile applicability
Wallet supports both ISO mdoc and IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in ISO mdoc format.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet presents Credential to the Verifier.
- Check value from Credential Format Identifier.
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in IETF SD-JWT VC format.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet presents Credential to the Verifier.
- Check value from Credential Format Identifier.
Expected results
- This is the case
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet presents Credential to the Verifier successfully.
- Credential presented has Credential Format Identifier value set to
mso_mdoc. - This is the case.
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet presents Credential to the Verifier successfully.
- Credential presented has Credential Format Identifier value set to
dc+sd-jwt.
WS_RP_MS_CredentialFormats_038
Objective
Verify that Wallet can handle receiving authorization request with response type vp_token and answering properly.
References
- [HAIP] Section 5 (introduction)
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends Authorization Request with response type
vp_token - Verify if Wallet process successfully Authorization Request with response type
vp_tokensent by the Verifier. - Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet includes
vp_tokenparameter in its response.
Expected results
- This is the case.
- This is the case.
- Wallet process successfully Authorization Request with response type
vp_tokensent by the Verifier. - Wallet asks for user consent.
- This is the case.
- Wallet includes
vp_tokenparameter in its response.
WS_RP_MS_CredentialFormats_039
Objective
Verify that when the Verifier uses the vp_token id_token response type, the Wallet responds with an error (detailed or not) or discontinues the transaction.
References
- [HAIP] Section 5 (introduction)
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends Authorization Request with response type
vp_token id_token - Wallet processes the request.
Expected results
- This is the case.
- This is the case.
- Wallet either:
a. answers with an error with details (
unsupported_response_type), b. answers with an error without providing details or, c. discontinues the interaction.
WS_RP_MS_CredentialFormats_040
Objective
Verify that when the Verifier uses the code response type, the Wallet responds with an error (detailed or not) or discontinues the transaction.
References
- [HAIP] Section 5 (introduction)
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends an Authorization Request with response type
code - Wallet processes the request.
Expected results
- This is the case.
- This is the case.
- Wallet either:
a. answers with an error with details (
unsupported_response_type), b. answers with an error without providing details or, c. discontinues the interaction.
WS_RP_MS_CredentialFormats_041
Objective
Verify that when Wallet is presenting several ISO mdocs, each ISO mdoc is returned in a separate DeviceResponse (as defined in 8.3.2.1.2.2 of [ISO.18013-5]), each matching to a respective DCQL query. Therefore, the resulting vp_token contains multiple DeviceResponse instances.
References
- [HAIP] Section 5.3.1
- [OpenID4VP] Appendix B.2 (ISO mdoc profile)
- [ISO/IEC 18013-5] Section 8.3.2.1.2.2
Profile applicability
Wallet supports ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends 3 DCQL query to the Wallet.
- Verifier requests presentation in mdoc format.
- Verify if Wallet can handle receiving multiple DCQL queries for Credentials in ISO mdoc format.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if
vp_tokencontains multipleDeviceResponseinstances. - Verify if for each query, Wallet returns one Device Response matching each DCQL query.
Expected results
- This is the case.
- This is the case.
- This is the case.
- Wallet receives multiple DCQL queries for Credentials in ISO mdoc format successfully.
- Wallet asks for user consent.
- This is the case.
vp_tokencontains multipleDeviceResponseinstances.- For each query, Wallet returns one Device Response matching each DCQL query.
WS_RP_MS_CredentialFormats_049
Objective
Verify that when the Wallet presentation to the Verifier includes status claim, it contains status_list as defined in [I-D.ietf-oauth-status-list].
References
- [HAIP] Section 6.1
- [RFC7800]
- [SD-JWT VC]
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in IETF SD-JWT VC format.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet presents Credential in IETF SD-JWT VC format.
- Verify if
statusclaim is present. - Check
statusclaim content.
Expected results
- This is the case.
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet presents Credential in IETF SD-JWT VC format.
statusclaim is present.statusclaim containsstatus_list.
WS_RP_MS_CredentialFormats_045
Objective
Verify that Wallet can handle presenting Credential in IETF SD-JWT VC format using compact serialization as defined in [RFC9901] when there is key binding.
References
- [HAIP] Section 6.1
- [RFC9901]
Profile applicability
Wallet supports IETF SD-JWT VC with key-binding
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- Credential Issuer issued Credential to the Wallet in IETF SD-JWT VC format, using compact serialization as defined in [RFC9901].
- There is a Key Binding JWT.
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in IETF SD-JWT VC format.
- Verify if Wallet presents successfully Credential in IETF SD-JWT VC format using compact serialization. That is, the compact serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows, where "D.1" to "D.N" represent the respective Disclosures:
... ~ The order of the concatenated parts is the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, and lastly the Key Binding JWT.
Expected results
- This is the case.
- This is the case.
- Wallet presents successfully Credential in IETF SD-JWT VC format using compact serialization. That is, the compact serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows, where "D.1" to "D.N" represent the respective Disclosures:
... ~ The order of the concatenated parts is the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, and lastly the Key Binding JWT.
WS_RP_MS_CredentialFormats_046
Objective
Verify that Wallet can handle being presenting Credential in IETF SD-JWT VC format using compact serialization as defined in [RFC9901] when there is no key binding.
References
- [HAIP] Section 6.1
- [RFC9901]
Profile applicability
Wallet supports IETF SD-JWT VC without key-binding
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- Credential Issuer issued Credential to the Wallet in IETF SD-JWT VC format, using compact serialization as defined in [RFC9901].
- There is no Key Binding JWT.
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in IETF SD-JWT VC format.
- Verify if Wallet presents successfully with Credential in IETF SD-JWT VC format using compact serialization. That is, the compact serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows, where "D.1" to "D.N" represent the respective Disclosures:
... ~ The order of the concatenated parts is the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, the last element is an empty string and the last separating tilde character is not omitted."
Expected results
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in IETF SD-JWT VC format.
- Wallet presents successfully Credential in IETF SD-JWT VC format using compact serialization. That is, the compact serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows, where "D.1" to "D.N" represent the respective Disclosures:
... ~ The order of the concatenated parts is the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, the last element is an empty string and the last separating tilde character is not omitted."
WS_RP_MS_CredentialFormats_048
Objective
Verify that Wallet can handle presenting a Credential using JSON serialization if required by the Wallet profile.
References
- [HAIP] Section 6.1
Profile applicability
Wallet supports IETF SD-JWT VC Wallet profile supports JSON serialization and Credential profile requires it
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in IETF SD-JWT VC format.
- Verify if Wallet presents successfully Credential in IETF SD-JWT VC format using JSON serialization.
Expected results
- This is the case.
- This is the case.
- Wallet presents successfully Credential in IETF SD-JWT VC format using JSON serialization.
Message Structure - Metadata
WS_RP_MS_Metadata_081
Objective
Verify that the EUDI Wallet accepts a JOSE-based Referenced Token containing a "status" claim with a valid "status_list" JSON Object.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer has provided a JOSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains a "status" claim containing a valid "status_list" JSON Object.
Test Scenario
- Verify the presence and content of the "status" claim.
Expected results
- The "status" claim contains a valid "status_list" object and the token is accepted.
WS_RP_MS_Metadata_082
Objective
Verify that the EUDI Wallet handles a JOSE-based Referenced Token without a "status" claim according to local policy.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Issuer has provided a JOSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token does not contain the "status" claim.
Test Scenario
- Verify the Wallet's handling of the absent "status" claim.
Expected results
- The Wallet handles the absent "status" claim according to local policy.
WS_RP_MS_Metadata_083
Objective
Verify that the EUDI Wallet accepts a JOSE-based Referenced Token containing a "status_list" JSON Object within the "status" claim, with valid "idx" and "uri" fields.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer has provided a JOSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains a "status_list" JSON Object within the "status" claim, containing valid "idx" and "uri" fields.
Test Scenario
- Verify the presence of "status_list" within the "status" claim and its "idx" and "uri" fields.
Expected results
- The "status_list" object contains valid "idx" and "uri" fields and the token is accepted.
WS_RP_MS_Metadata_084
Objective
Verify that the EUDI Wallet handles a JOSE-based Referenced Token where the "status" claim does not contain a "status_list" object.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Issuer has provided a JOSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the "status" claim but without a "status_list" object.
Test Scenario
- Verify the Wallet's handling of the absent "status_list" within the "status" claim.
Expected results
- The Wallet rejects the Referenced Token when there is no status_list JSON object present in the status JWT Claims Set
WS_RP_MS_Metadata_085
Objective
Verify that the EUDI Wallet accepts a JOSE-based Referenced Token where the "idx" claim within "status_list" is a valid non-negative integer.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer has provided a JOSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the "idx" claim within "status_list" set to a valid non-negative integer.
Test Scenario
- Verify the value of the "idx" claim within "status_list".
Expected results
- The "idx" value is a non-negative integer and the token is accepted.
WS_RP_MS_Metadata_086
Objective
Verify that the EUDI Wallet rejects a JOSE-based Referenced Token where the "idx" claim within "status_list" is a negative integer.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The Issuer has provided a JOSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the "idx" claim within "status_list" set to a negative integer.
Test Scenario
- Verify the Wallet's handling of the negative "idx" value.
Expected results
- The Referenced Token is rejected.
WS_RP_MS_Metadata_087
Objective
Verify that the EUDI Wallet rejects a JOSE-based Referenced Token where the required "idx" claim within "status_list" is missing.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Issuer has provided a JOSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token does not contain the "idx" claim within "status_list".
Test Scenario
- Verify the Wallet's handling of the missing "idx" claim.
Expected results
- The Referenced Token is rejected.
WS_RP_MS_Metadata_088
Objective
Verify that the EUDI Wallet accepts a JOSE-based Referenced Token where the "uri" claim within "status_list" is a valid URI per RFC 3986.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer has provided a JOSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the "uri" claim within "status_list" set to a valid URI per RFC 3986.
Test Scenario
- Verify the value of the "uri" claim within "status_list".
Expected results
- The "uri" value is a valid URI and the token is accepted.
WS_RP_MS_Metadata_089
Objective
Verify that the EUDI Wallet rejects a JOSE-based Referenced Token where the "uri" claim within "status_list" is malformed.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The Issuer has provided a JOSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the "uri" claim within "status_list" set to a malformed URI.
Test Scenario
- Provide a Referenced Token where the "uri" value has no scheme (e.g., example.com/statuslists/1). Verify the Wallet's handling.
- Provide a Referenced Token where the "uri" value contains an unencoded space in the host (e.g., https://exam ple.com/statuslists/1). Verify the Wallet's handling.
- Provide a Referenced Token where the "uri" value contains invalid percent-encoding (e.g., https://example.com/statuslists/%GG). Verify the Wallet's handling.
- Provide a Referenced Token where the "uri" value contains illegal characters (e.g.,
https://example.com/statuslists/<token>|1). Verify the Wallet's handling. - Provide a Referenced Token where the "uri" value is an empty string. Verify the Wallet's handling.
Expected results
- The Wallet rejects the Referenced Token (missing scheme).
- The Wallet rejects the Referenced Token (invalid character in host).
- The Wallet rejects the Referenced Token (malformed percent-encoding).
- The Wallet rejects the Referenced Token (illegal characters <, >, | are not permitted in URIs per RFC 3986).
- The Wallet rejects the Referenced Token (empty URI).
WS_RP_MS_Metadata_090
Objective
Verify that the EUDI Wallet rejects a JOSE-based Referenced Token where the required "uri" claim within "status_list" is missing.
References
- [Token Status List] Section 6.2
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in JWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Issuer has provided a JOSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token does not contain the "uri" claim within "status_list".
Test Scenario
- Verify the Wallet's handling of the missing "uri" claim.
Expected results
- The Referenced Token is rejected.
WS_RP_MS_Metadata_091
Objective
Verify that the EUDI Wallet accepts a COSE-based Referenced Token containing a valid Status CBOR structure (Map) with at least a "status_list" entry.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains a valid Status CBOR structure (Map) with at least a "status_list" entry.
Test Scenario
- Verify the presence and content of the Status CBOR structure.
Expected results
- The Status CBOR Map contains a valid "status_list" entry and the token is accepted.
WS_RP_MS_Metadata_092
Objective
Verify that the EUDI Wallet rejects a COSE-based Referenced Token containing an empty Status CBOR Map.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains an empty Status CBOR Map.
Test Scenario
- Verify the Wallet's handling of the empty Status CBOR Map.
Expected results
- The Referenced Token is rejected.
WS_RP_MS_Metadata_093
Objective
Verify that the EUDI Wallet accepts a COSE-based Referenced Token containing a "status_list" CBOR structure within the Status Map, with valid "idx" and "uri" fields.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains a "status_list" CBOR structure within the Status Map, containing valid "idx" and "uri" fields.
Test Scenario
- Verify the presence of "status_list" within the Status Map and its "idx" and "uri" fields.
Expected results
- The "status_list" structure contains valid "idx" and "uri" fields and the token is accepted.
WS_RP_MS_Metadata_094
Objective
Verify that the EUDI Wallet handles a COSE-based Referenced Token where the Status Map does not contain a "status_list" entry.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the Status Map present but without a "status_list" entry.
Test Scenario
- Verify the Wallet's handling of the absent "status_list" within the Status Map.
Expected results
- The Wallet handles the missing "status_list" according to local policy.
WS_RP_MS_Metadata_095
Objective
Verify that the EUDI Wallet accepts a COSE-based Referenced Token where the "idx" field within "status_list" is a valid unsigned integer (major type 0)
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the "idx" field within "status_list" set to a valid unsigned integer.
Test Scenario
- Verify the value of the "idx" field within "status_list" is of major type 0.
Expected results
- The "idx" value is a valid unsigned integer and the token is accepted.
WS_RP_MS_Metadata_096
Objective
Verify that the EUDI Wallet rejects a COSE-based Referenced Token where the "idx" field within "status_list" has an invalid type (negative or wrong CBOR type).
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the "idx" field within "status_list" set to an invalid type (negative or wrong CBOR type).
Test Scenario
- Verify the Wallet's handling of the invalid "idx" type.
Expected results
- The Referenced Token is rejected.
WS_RP_MS_Metadata_097
Objective
Verify that the EUDI Wallet rejects a COSE-based Referenced Token where the required "idx" field within "status_list" is missing.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token does not contain the "idx" field within "status_list".
Test Scenario
- Verify the Wallet's handling of the missing "idx" field.
Expected results
- The Referenced Token is rejected.
WS_RP_MS_Metadata_098
Objective
Verify that the EUDI Wallet accepts a COSE-based Referenced Token where the "uri" field within "status_list" is a valid text string URI of major type 3.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the "uri" field within "status_list" set to a valid text string URI.
Test Scenario
- Verify the value of the "uri" field within "status_list" is of major type 3.
Expected results
- The "uri" value is a valid text string URI and the token is accepted.
WS_RP_MS_Metadata_099
Objective
Verify that the EUDI Wallet rejects a COSE-based Referenced Token where the "uri" field within "status_list" is malformed.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the "uri" field within "status_list" set to a malformed URI.
Test Scenario
- Provide a Referenced Token where the "uri" value has no scheme (e.g., example.com/statuslists/1). Verify the Wallet's handling.
- Provide a Referenced Token where the "uri" value contains an unencoded space in the host (e.g., https://exam ple.com/statuslists/1). Verify the Wallet's handling.
- Provide a Referenced Token where the "uri" value contains invalid percent-encoding (e.g., https://example.com/statuslists/%GG). Verify the Wallet's handling.
- Provide a Referenced Token where the "uri" value contains illegal characters (e.g.,
https://example.com/statuslists/<token>|1). Verify the Wallet's handling. - Provide a Referenced Token where the "uri" value is an empty string. Verify the Wallet's handling.
Expected results
- The Wallet rejects the Referenced Token (missing scheme).
- The Wallet rejects the Referenced Token (invalid character in host).
- The Wallet rejects the Referenced Token (malformed percent-encoding).
- The Wallet rejects the Referenced Token (illegal characters <, >, | are not permitted in URIs per RFC 3986).
- The Wallet rejects the Referenced Token (empty URI).
WS_RP_MS_Metadata_100
Objective
Verify that the EUDI Wallet rejects a COSE-based Referenced Token where the required "uri" field within "status_list" is missing.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token does not contain the "uri" field within "status_list".
Test Scenario
- Verify the Wallet's handling of the missing "uri" field.
Expected results
- The Referenced Token is rejected.
WS_RP_MS_Metadata_101
Objective
Verify that the EUDI Wallet accepts a COSE-based Referenced Token containing the status claim at CBOR label 65535 with a valid Status CBOR structure.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Referenced Token includes the Status element that contains the Status_list element (index and URI)
- The EUDI Wallet has retrieved a Status List Token from the referenced URI
- The Status List Token is validated
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the status claim at CBOR label 65535 containing a valid Status CBOR structure.
Test Scenario
- Verify the presence of the status claim at CBOR label 65535.
Expected results
- The status claim at label 65535 contains a valid Status CBOR structure and the token is accepted.
WS_RP_MS_Metadata_102
Objective
Verify that the EUDI Wallet rejects a COSE-based Referenced Token where the required status claim at CBOR label 65535 is missing.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The EUDI Wallet requests and receives a valid Referenced Token issued by an Issuer
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains the status claim at CBOR label 65535 missing.
Test Scenario
- Verify the Wallet's handling of the missing status claim at label 65535.
Expected results
- The Referenced Token is rejected.
WS_RP_MS_Metadata_103
Objective
Verify that the number, keys, and value types of data items in the StatusListInfo CBOR structure within a COSE-based Referenced Token are correct.
References
- [Token Status List] Section 6.3
Profile applicability
The Wallet supports revocation checking via the Token Status List mechanism; The Wallet supports Status List Tokens in CWT format
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- The Issuer has provided a COSE-based Referenced Token to the EUDI Wallet.
- The Referenced Token contains a status claim with a "status_list" CBOR structure.
- The status_list structure passed basic CBOR well-formedness checks.
Test Scenario
- Verify the additional information encoded on the last five bits of the first byte of the status_list map.
- Verify that the required key-value pairs are present with the correct CBOR types.
- Verify that no unrecognized key-value pairs with key major type 3 (tstr) are present, other than "idx", "uri", and optionally "certificate".
Expected results
- The value of the additional information (encoding the number of key-value pairs in the map) is 2 or 3: - 2 if only the required fields are present (idx, uri) - 3 if the optional certificate field is also present
- The key-value pairs present have the following properties: key major type = 3 (tstr), key value = "idx" & value major type = 0 (uint), key major type = 3 (tstr), key value = "uri" & value major type = 3 (tstr), optionally: key major type = 3 (tstr), key value = "certificate" & value major type = 2 (bstr).
- No unrecognized key-value pairs with key major type 3 (tstr) are present beyond those listed in step 2.
WS_RP_MS_Metadata_104
Objective
Verify that when the client_metadata parameter is included in an Authorization Request, it is a valid UTF-8 encoded JSON object and that the Wallet processes only the defined metadata parameters.
References
- [OpenID4VP] Section 5.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends Authorization Request with client_metadata as a valid UTF-8 encoded JSON object containing only defined metadata parameters.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet accepts the request and processes only the defined metadata parameters from client_metadata.
WS_RP_MS_Metadata_105
Objective
Verify that when the client_metadata parameter is included in an Authorization Request, it is a valid UTF-8 encoded JSON object and that the Wallet processes only the defined metadata parameters.
References
- [OpenID4VP] Section 5.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends Authorization Request with client_metadata containing both defined and unrecognized/additional metadata parameters.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet processes only the defined metadata parameters; unrecognized parameters are silently ignored; presentation flow proceeds.
WS_RP_MS_Metadata_106
Objective
VVerify that the Wallet rejects the Authorization Request when the client_metadata parameter is not a valid UTF-8 encoded JSON object, returning an invalid_request error.
References
- [OpenID4VP] Section 5.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends Authorization Request with a client_metadata value that is not a valid UTF-8 encoded JSON object.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet rejects the Authorization Request due to invalid encoding or structure and returns an invalid_request error.
WS_RP_MS_Metadata_107
Objective
Verify that when the Verifier sets request_uri_method = "post" without client_metadata, the Wallet still proceeds by sending its full supported wallet_metadata in the POST request to the request_uri.
References
- [OpenID4VP] Sections 5.10, 5.1
- [RFC9101]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = "post" but no client_metadata parameter.
- Wallet has no information about the Verifier's capabilities.
- Wallet sends an HTTP POST request to the request_uri including a wallet_metadata parameter.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully parses the Authorization Request.
- Wallet proceeds without Verifier capability information.
- Wallet POSTs to the request_uri with wallet_metadata containing its full set of supported capabilities; Wallet retrieves the Request Object and proceeds with the flow.
WS_RP_MS_Metadata_108
Objective
Verify that when the Wallet receives an Authorization Request where all Verifier metadata is provided within the client_metadata parameter, the Wallet processes the metadata exclusively from client_metadata.
References
- [OpenID4VP] Sections 5.9.3, 5.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request where all Verifier metadata is contained within the client_metadata parameter.
- Wallet parses the Authorization Request.
- Wallet extracts Verifier metadata from the client_metadata parameter.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet processes all Verifier metadata exclusively from the client_metadata parameter and proceeds with the flow.
WS_RP_MS_Metadata_109
Objective
Verify that when the Wallet receives an Authorization Request where some Verifier metadata is provided outside the client_metadata parameter, the Wallet ignores such metadata and processes only what is contained within client_metadata.
References
- [OpenID4VP] Sections 5.9.3, 5.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request where some Verifier metadata is provided outside the client_metadata parameter.
- Wallet parses the Authorization Request.
- Wallet extracts Verifier metadata from the Authorization Request.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet ignores Verifier metadata provided outside the client_metadata parameter and processes only the metadata within client_metadata; flow proceeds accordingly.
WS_RP_MS_Metadata_110
Objective
Verify that when the Wallet receives a signed Authorization Request using the redirect_uri Client Identifier Prefix, it rejects the request since the redirect_uri prefix cannot be used with signed requests.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a signed Authorization Request using the redirect_uri: Client Identifier Prefix.
- Wallet parses the Authorization Request.
- Wallet detects the combination of signed request and redirect_uri prefix.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet rejects the Authorization Request (cannot verify signature with no trusted key available for the redirect_uri prefix) and returns an invalid_request error; presentation flow is not initiated.
WS_RP_MS_Metadata_111
Objective
Verify that when the Wallet receives a signed Authorization Request using a Client Identifier Prefix that supports signing (e.g. x509_hash, openid_federation, verifier_attestation, decentralized_identifier, x509_san_dns), the Wallet accepts the request and proceeds with the presentation flow.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a signed Authorization Request using a Client Identifier Prefix that supports signing (e.g. x509_hash).
- Wallet verifies the signature using the keys resolvable through the Client Identifier Prefix.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully verifies the signature and processes the signed request; presentation flow proceeds.
WS_RP_MS_Metadata_112
Objective
Verify that when the Wallet receives an Authorization Request using the openid_federation Client Identifier Prefix containing a valid trust_chain parameter, the Wallet processes the trust_chain and uses it for Verifier trust establishment.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request using the openid_federation: prefix containing a valid trust_chain parameter.
- Wallet parses the Authorization Request.
- Wallet processes the trust_chain parameter per OpenID Federation rules.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet successfully validates the trust_chain, establishes Verifier trust, and proceeds with the presentation flow.
WS_RP_MS_Metadata_113
Objective
Verify that when the Wallet receives an Authorization Request using the openid_federation Client Identifier Prefix containing a trust_chain parameter that cannot be validated, the Wallet rejects the request in accordance with its trust policy.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request using the openid_federation: prefix containing a trust_chain parameter that cannot be validated (malformed, unresolvable, or not trusted).
- Wallet parses the Authorization Request.
- Wallet attempts to validate the trust_chain.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet rejects the Authorization Request (trust chain validation failure) and returns an appropriate error per its trust policy; presentation flow is not initiated.
WS_RP_MS_Metadata_114
Objective
Verify that when the Wallet receives an Authorization Request using the openid_federation Client Identifier Prefix and client_metadata is present, the Wallet ignores the client_metadata parameter and resolves Verifier metadata via OpenID Federation.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_undefined
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request using the openid_federation: prefix with a client_metadata parameter included.
- Wallet parses the Authorization Request.
- Wallet resolves Verifier metadata via OpenID Federation.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet ignores the client_metadata parameter and obtains all Verifier metadata via OpenID Federation; presentation flow proceeds.
WS_RP_MS_Metadata_115
Objective
Verify that when the Wallet receives an Authorization Request using the openid_federation Client Identifier Prefix without a client_metadata parameter, the Wallet resolves all Verifier metadata via OpenID Federation.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request using the openid_federation: prefix without a client_metadata parameter.
- Wallet parses the Authorization Request.
- Wallet resolves Verifier metadata via OpenID Federation.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet successfully resolves all Verifier metadata via OpenID Federation; presentation flow proceeds.
WS_RP_MS_Metadata_116
Objective
Verify that when the Wallet receives an Authorization Request using the verifier_attestation Client Identifier Prefix where the original Client Identifier (part after the prefix) equals the subclaim of the Verifier attestation JWT, the Wallet processes the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request using the verifier_attestation: prefix where the original Client Identifier matches the subclaim of the attestation JWT.
- Wallet parses the Authorization Request.
- Wallet validates that the original Client Identifier equals the subclaim of the Verifier attestation JWT.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet verifies the Client Identifier matches the subclaim; request is processed; presentation flow proceeds.
WS_RP_MS_Metadata_117
Objective
Verify that when the Wallet receives an Authorization Request using the verifier_attestation Client Identifier Prefix where the original Client Identifier does NOT match the subclaim of the Verifier attestation JWT, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request using the verifier_attestation: prefix where the original Client Identifier does NOT match the subclaim of the attestation JWT.
- Wallet parses the Authorization Request.
- Wallet validates the Client Identifier against the subclaim and detects the mismatch.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet rejects the Authorization Request and returns an invalid_request error due to Client Identifier / subclaim mismatch; presentation flow is not initiated.
WS_RP_MS_Metadata_118
Objective
Verify that when the Wallet receives a Request Object using the verifier_attestation Client Identifier Prefix with the Verifier attestation JWT correctly placed in the jwt JOSE header, the Wallet locates and processes the attestation JWT.
References
- [OpenID4VP] Sections 5.9.3, 12
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using verifier_attestation: prefix where the Verifier attestation JWT, containing a cnf claim with the Verifier's public key, is present in the jwt JOSE header.
- Wallet parses the Request Object JOSE header.
- Wallet locates and extracts the Verifier attestation JWT from the jwt header.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Request Object JOSE header.
- Wallet successfully locates and processes the Verifier attestation JWT from the jwt JOSE header; presentation flow proceeds.
WS_RP_MS_Metadata_119
Objective
Verify that when the Wallet receives a Request Object using the verifier_attestation Client Identifier Prefix where the jwt JOSE header is absent or does not contain the Verifier attestation JWT, the Wallet rejects the request.
References
- [OpenID4VP] Sections 5.9.3, 12
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using verifier_attestation: prefix where the jwt JOSE header is absent.
- Wallet parses the Request Object JOSE header.
- Wallet attempts to locate the Verifier attestation JWT.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object JOSE header.
- Wallet rejects the Authorization Request and returns an invalid_request error due to missing jwt JOSE header / Verifier attestation JWT; presentation flow is not initiated.
WS_RP_MS_Metadata_120
Objective
Verify that when the Verifier attestation JWT contains a redirect_uris claim and the redirect_uri request parameter exactly matches one of its entries, the Wallet processes the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- Wallet has a configured list of trusted issuers for Verifier Attestation JWTs.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using verifier_attestation: prefix where the redirect_uri request parameter exactly matches one entry in the attestation JWT's redirect_uris claim.
- Wallet parses the Request Object and the attestation JWT.
- Wallet compares the redirect_uri parameter against the redirect_uris claim entries.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and the attestation JWT.
- Wallet verifies the exact match; request is processed; presentation flow proceeds.
WS_RP_MS_Metadata_121
Objective
Verify that when the Verifier attestation JWT contains a redirect_uris claim and the redirect_uri request parameter does NOT exactly match any entry, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- Wallet has a configured list of trusted issuers for Verifier Attestation JWTs.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using verifier_attestation: prefix where the redirect_uri request parameter does NOT match any entry in the attestation JWT's redirect_uris claim.
- Wallet parses the Request Object and the attestation JWT.
- Wallet compares the redirect_uri parameter against the redirect_uris claim entries.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and the attestation JWT.
- Wallet rejects the Request Object and returns an invalid_request error due to redirect_uri mismatch; presentation flow is not initiated.
WS_RP_MS_Metadata_122
Objective
Verify that when the Verifier attestation JWT does NOT contain a redirect_uris claim, the Wallet does not enforce a redirect_uri match against the attestation and processes the request normally.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- Wallet has a configured list of trusted issuers for Verifier Attestation JWTs.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using verifier_attestation: prefix; the attestation JWT contains NO redirect_uris claim.
- Wallet parses the Request Object and the attestation JWT.
- Wallet checks for the redirect_uris claim and finds none.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and the attestation JWT.
- Wallet does not enforce redirect_uri against the attestation; request is processed normally; presentation flow proceeds.
WS_RP_MS_Metadata_123
Objective
Verify that when the Wallet receives a Request Object using the verifier_attestation Client Identifier Prefix where non-key Verifier metadata is provided outside the client_metadata parameter, the Wallet ignores such metadata and processes only what is contained within client_metadata.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using verifier_attestation: prefix where some non-key Verifier metadata is provided outside the client_metadata parameter.
- Wallet parses the Request Object.
- Wallet extracts Verifier metadata from the Request Object.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet ignores non-key Verifier metadata provided outside client_metadata and processes only the metadata within client_metadata; presentation flow proceeds.
WS_RP_MS_Metadata_124
Objective
Verify that when the Wallet receives a Request Object using the verifier_attestation Client Identifier Prefix where all non-key Verifier metadata is provided within client_metadata, the Wallet uses client_metadata as the source of all non-key metadata and processes the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using verifier_attestation: prefix; all non-key Verifier metadata is included in client_metadata.
- Wallet parses the Request Object.
- Wallet extracts non-key Verifier metadata from client_metadata.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet obtains all Verifier metadata (except public key) exclusively from client_metadata; presentation flow proceeds.
WS_RP_MS_Metadata_125
Objective
Verify that when the Wallet receives a Request Object using the x509_san_dns Client Identifier Prefix where the original Client Identifier (DNS name) matches a dNSName SAN entry in the leaf certificate provided in the request, the Wallet accepts the binding.
References
- [OpenID4VP] Section 5.9.3
- [RFC5280]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using x509_san_dns: prefix where the DNS name in the Client Identifier matches a dNSName SAN entry in the leaf certificate.
- Wallet parses the Request Object and the x5c chain.
- Wallet compares the DNS name in the Client Identifier against the SAN entries of the leaf certificate.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and the x5c chain.
- Wallet verifies the DNS name matches a SAN dNSName; request is accepted; presentation flow proceeds.
WS_RP_MS_Metadata_126
Objective
Verify that when the Wallet receives a Request Object using the x509_san_dns Client Identifier Prefix where the DNS name in the Client Identifier does NOT match any dNSName SAN entry in the leaf certificate, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
- [RFC5280]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using x509_san_dns: prefix where the DNS name does NOT match any dNSName SAN entry in the leaf certificate.
- Wallet parses the Request Object and the x5c chain.
- Wallet compares the DNS name in the Client Identifier against the SAN entries.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and the x5c chain.
- Wallet rejects the Request Object and returns an invalid_request error due to DNS name / SAN mismatch; presentation flow is not initiated.
WS_RP_MS_Metadata_127
Objective
Verify that when the Wallet receives a non-DC-API Request Object using the x509_san_dns Client Identifier Prefix and trust in the Client Identifier is established via the certificate, the Wallet allows the redirect_uri provided the FQDN of the redirect_uri matches the Client Identifier hostname; all non-key Verifier metadata is taken from client_metadata.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- Wallet has a configured trust anchor for X.509 certificate chain validation.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a non-DC-API Request Object using x509_san_dns: prefix where the FQDN of redirect_uri matches the Client Identifier hostname; non-key Verifier metadata is in client_metadata; trust is established via the leaf certificate.
- Wallet parses the Request Object.
- Wallet validates the FQDN of redirect_uri against the Client Identifier hostname.
- Wallet extracts non-key Verifier metadata from client_metadata.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet verifies the FQDN match.
- Wallet uses client_metadata for all non-key Verifier metadata; request is accepted; presentation flow proceeds.
WS_RP_MS_Metadata_128
Objective
Verify that when the Wallet receives a non-DC-API Request Object using the x509_san_dns Client Identifier Prefix and the FQDN of redirect_uri does NOT match the Client Identifier hostname (and trust in the Client Identifier is not otherwise established), the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- Wallet has a configured trust anchor for X.509 certificate chain validation.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a non-DC-API Request Object using x509_san_dns: prefix where the FQDN of redirect_uri does NOT match the Client Identifier hostname.
- Wallet parses the Request Object.
- Wallet validates the FQDN of redirect_uri against the Client Identifier hostname.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet rejects the Request Object and returns an invalid_request error due to FQDN / Client Identifier hostname mismatch; presentation flow is not initiated.
WS_RP_MS_Metadata_129
Objective
Verify that when the Wallet receives a Request Object using the x509_hash Client Identifier Prefix where the original Client Identifier equals the base64url-encoded SHA-256 hash of the DER-encoded leaf certificate provided in x5c, the Wallet accepts the binding.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using x509_hash: prefix where the Client Identifier equals the base64url-encoded SHA-256 hash of the encoded leaf certificate in x5c.
- Wallet parses the Request Object and the x5c chain.
- Wallet computes the base64url-encoded SHA-256 hash of the leaf certificate and compares against the Client Identifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and the x5c chain.
- Wallet verifies that the Client Identifier matches the leaf certificate hash; request is accepted; presentation flow proceeds.
WS_RP_MS_Metadata_130
Objective
Verify that when the Wallet receives a Request Object using the x509_hash Client Identifier Prefix where the Client Identifier does NOT match the base64url-encoded SHA-256 hash of the leaf certificate in x5c, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using x509_hash: prefix where the Client Identifier does NOT match the SHA-256 hash of the leaf certificate.
- Wallet parses the Request Object and x5c.
- Wallet computes and compares the leaf certificate hash.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and x5c.
- Wallet rejects the Request Object and returns an invalid_request error due to Client Identifier / certificate hash mismatch; presentation flow is not initiated.
WS_RP_MS_Metadata_131
Objective
Verify that when the Wallet receives a Request Object using the x509_hash Client Identifier Prefix signed with the private key corresponding to the public key in the leaf X.509 certificate (whose hash is in the Client Identifier), the Wallet successfully verifies the signature.
References
- [OpenID4VP] Section 5.9.3
- [RFC7515]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a signed Request Object using x509_hash: prefix where the Client Identifier equals the SHA-256 hash of the leaf certificate and the signature is made with the leaf certificate's private key.
- Wallet parses the Request Object and x5c.
- Wallet extracts the leaf certificate's public key.
- Wallet verifies the Request Object signature using that public key.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and x5c.
- Wallet successfully extracts the leaf certificate public key.
- Wallet successfully verifies the signature; request is processed; presentation flow proceeds.
WS_RP_MS_Metadata_132
Objective
Verify that when the Wallet receives a Request Object using the x509_hash Client Identifier Prefix where the signature key does NOT correspond to the leaf certificate in x5c, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
- [RFC7515]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a signed Request Object using x509_hash: prefix where the signature was made with a key NOT corresponding to the leaf certificate in x5c.
- Wallet parses the Request Object and x5c.
- Wallet extracts the leaf certificate public key.
- Wallet attempts signature verification.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and x5c.
- Wallet successfully extracts the leaf certificate public key.
- Wallet rejects the Request Object and returns an invalid_request error due to signature verification failure; presentation flow is not initiated.
WS_RP_MS_Metadata_133
Objective
Verify that when the Wallet receives an Authorization Request using the reserved origin: Client Identifier Prefix outside a DC API context, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request using the origin: Client Identifier Prefix outside of a DC API context (e.g. via redirect or request_uri flow).
- Wallet parses the Authorization Request.
- Wallet detects the origin: prefix in a non-DC-API context.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet rejects the Authorization Request and returns an invalid_request error (origin: prefix MUST NOT be accepted outside DC API); presentation flow is not initiated.
WS_RP_MS_Metadata_134
Objective
Verify that when the Wallet requires encrypted Request Objects, it advertises public encryption keys in wallet_metadata.jwks and the supported algorithms via authorization_encryption_alg_values_supported and authorization_encryption_enc_values_supported, and the Wallet successfully decrypts the encrypted Request Object received from the Verifier.
References
- [OpenID4VP] Section 5.10
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request to the request_uri endpoint with wallet_metadata including jwks (public encryption keys) and supported encryption algorithms.
- Wallet receives an encrypted Request Object using the advertised algorithms.
- Wallet decrypts and processes the Request Object.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet_metadata.jwks is correctly populated with public encryption keys and algorithm preferences.
- Wallet successfully receives the encrypted Request Object.
- Wallet successfully decrypts and processes the Request Object; presentation flow proceeds.
WS_RP_MS_Metadata_135
Objective
Verify that when the Wallet has indicated that encryption is required (via wallet_metadata.jwks and supported algorithms) and the Verifier returns an unencrypted Request Object, the Wallet rejects the Request Object.
References
- [OpenID4VP] Section 5.10
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request with wallet_metadata.jwks indicating encryption is required.
- Wallet receives an unencrypted Request Object.
- Wallet inspects the response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet_metadata.jwks is correctly populated.
- Wallet successfully receives the response.
- Wallet rejects the unencrypted Request Object and returns an invalid_request error; presentation flow is not initiated.
WS_RP_MS_Metadata_136
Objective
Verify that when the Wallet uses a Client Identifier Prefix that permits signed Request Objects, the Wallet lists supported Request Object signing algorithms in the request_object_signing_alg_values_supported parameter of wallet_metadata.
References
- [OpenID4VP] Section 5.10
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post and a Client Identifier Prefix that permits signed Request Objects.
- Wallet prepares wallet_metadata for the POST request.
- Wallet sends the POST request to the request_uri endpoint. Inspect wallet_metadata for the request_object_signing_alg_values_supported parameter.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet correctly prepares wallet_metadata.
- Wallet_metadata includes the request_object_signing_alg_values_supported parameter listing all supported Request Object signing algorithms.
WS_RP_MS_Metadata_137
Objective
Verify that when the Wallet uses a Client Identifier Prefix that precludes signed Request Objects (e.g. redirect_uri:), the Wallet does NOT include the request_object_signing_alg_values_supported parameter in wallet_metadata.
References
- [OpenID4VP] Section 5.10
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post using a Client Identifier Prefix that precludes signed Request Objects (e.g. redirect_uri:).
- Wallet prepares wallet_metadata for the POST request.
- Wallet sends the POST request. Inspect wallet_metadata.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet correctly prepares wallet_metadata.
- Wallet_metadata does NOT include the request_object_signing_alg_values_supported parameter.
WS_RP_MS_Metadata_138
Objective
Verify that when the Wallet sent a wallet_nonce in the POST request and the received Request Object contains the matching wallet_nonce claim, the Wallet validates the match and continues processing.
References
- [OpenID4VP] Section 5.10.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request including a wallet_nonce value.
- Wallet receives a Request Object containing the matching wallet_nonce claim.
- Wallet validates the wallet_nonce match.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet_nonce is correctly sent in the POST request.
- Wallet successfully receives the Request Object.
- Wallet validates the wallet_nonce match and continues processing the request.
WS_RP_MS_Metadata_139
Objective
Verify that when the Wallet sent a wallet_nonce in the POST request and the received Request Object contains a different wallet_nonce claim value, the Wallet terminates request processing.
References
- [OpenID4VP] Section 5.10.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request with a wallet_nonce value.
- Wallet receives a Request Object with a DIFFERENT wallet_nonce claim value.
- Wallet validates the wallet_nonce.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet_nonce is correctly sent in the POST request.
- Wallet successfully receives the Request Object.
- Wallet terminates request processing due to wallet_nonce mismatch; presentation flow is not initiated.
WS_RP_MS_Metadata_140
Objective
Verify that when the Wallet sent a wallet_nonce in the POST request and the received Request Object does NOT contain a wallet_nonce claim, the Wallet terminates request processing.
References
- [OpenID4VP] Section 5.10.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request with a wallet_nonce value.
- Wallet receives a Request Object where the wallet_nonce claim is absent.
- Wallet checks for the wallet_nonce claim.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet_nonce is correctly sent in the POST request.
- Wallet successfully receives the Request Object.
- Wallet terminates request processing due to missing wallet_nonce claim; presentation flow is not initiated.
WS_RP_MS_Metadata_141
Objective
Verify that when Wallet is presenting the Credential in IETF SD-JWT VC format, it contains the credential issuer's signing certificate along with a trust chain in the x5c JOSE header parameter.
References
- [HAIP] Section 6.1.1
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
TODO: TBD
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in IETF SD-JWT VC format.
- Verify if Wallet presents the Credential in IETF SD-JWT VC format.
- Check the presence of credential issuer's signing certificate along with a trust chain in the
x5cJOSE header parameter.
Expected results
- This is the case.
- Wallet presents the Credential in IETF SD-JWT VC format.
- Credential presented contains the credential issuer's signing certificate along with a trust chain in the
x5cJOSE header parameter.
Message Structure - Protocol Messages
WS_RP_MS_ProtocolMessages_002
Objective
Verify that the Wallet can process a plain RFC9700 Authorization Request where parameters are passed directly as URL-encoded parameters (not as a Request Object, not signed).
References
- [RFC6749]
- [RFC9700]
- [OpenID4VP] Section 5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_undefined
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a plain RFC9700 Authorization Request where parameters are passed directly as URL-encoded parameters (not as a Request Object, not signed).
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully processes the plain RFC9700 Authorization Request and proceeds with the presentation flow.
WS_RP_MS_ProtocolMessages_003
Objective
Verify that the Wallet rejects a Request Object where the typ header parameter equals oauth-authz-req+jwt.
References
- [RFC9101]
- [OpenID4VP] Section 5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_undefined
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends Authorization Request as a Request Object by VALUE with typ header = oauth-authz-req+jwt.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully processes the Authorization Request and proceeds with the presentation flow. Wallet MUST NOT process request objects where the typ does not have the value oauth-authz-req+jwt
WS_RP_MS_ProtocolMessages_004
Objective
Verify that the Wallet can process an Authorization Request sent as a Request Object by VALUE, where the Request Object includes the typ JOSE header parameter with the value oauth-authz-req+jwt.
References
- [RFC9101]
- [OpenID4VP] Section 5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a Request Object embedded directly by value with typ header = oauth-authz-req+jwt.
- Wallet inspects the typ JOSE header parameter of the Request Object.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives and parses the Request Object directly from the Authorization Request.
- Wallet validates the typ header value as oauth-authz-req+jwt and proceeds with the presentation flow.
WS_RP_MS_ProtocolMessages_005
Objective
Verify that the Wallet can process an Authorization Request sent as a Request Object by REFERENCE (via request_uri), where the Request Object includes the typ JOSE header parameter with the value oauth-authz-req+jwt.
References
- [RFC9101]
- [OpenID4VP] Section 5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a request_uri parameter.
- Wallet fetches the Request Object from the reference URI.
- Wallet inspects the typ JOSE header parameter of the retrieved Request Object; value = oauth-authz-req+jwt.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives the Authorization Request and recognizes the request_uri parameter.
- Wallet successfully fetches the Request Object from the reference URI.
- Wallet validates the typ header value as oauth-authz-req+jwt and proceeds with the presentation flow.
WS_RP_MS_ProtocolMessages_006
Objective
Verify that the Wallet rejects a Request Object where the typ header parameter is missing.
References
- [RFC9101]
- [OpenID4VP] Section 5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a request_uri parameter.
- Wallet fetches the Request Object from the reference URI.
- Wallet inspects the typ JOSE header parameter of the retrieved Request Object; the typ header parameter is absent.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives the Authorization Request and recognizes the request_uri parameter.
- Wallet successfully fetches the Request Object from the reference URI.
- Wallet does NOT process the request and returns an invalid_request error.
WS_RP_MS_ProtocolMessages_007
Objective
Verify that the Wallet rejects a Request Object where the typ header parameter does not equal oauth-authz-req+jwt.
References
- [RFC9101]
- [OpenID4VP] Section 5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a request_uri parameter.
- Wallet fetches the Request Object from the reference URI.
- Wallet inspects the typ JOSE header parameter of the retrieved Request Object; value is set to an invalid value (not oauth-authz-req+jwt).
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives the Authorization Request and recognizes the request_uri parameter.
- Wallet successfully fetches the Request Object from the reference URI.
- Wallet does NOT process the request and returns an invalid_request error.
WS_RP_MS_ProtocolMessages_008
Objective
Verify that the Wallet successfully processes the Authorization Request when client_id is present but iss claim is absent.
References
- [RFC9101]
- [OpenID4VP] Section 5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet holds at least one credential that can match a valid DCQL query, and a second scenario where no matching credential is available.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object containing client_id but NO iss claim.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet processes the Authorization Request successfully; Verifier is identified by the client_id claim.
WS_RP_MS_ProtocolMessages_009
Objective
Verify that the Wallet successfully processes the Authorization Request when both client_id and iss are present, but their values differ.
References
- [RFC9101]
- [OpenID4VP] Section 5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet holds at least one credential that can match a valid DCQL query, and a second scenario where no matching credential is available.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends a Request Object containing both client_id AND iss claim, with iss value different from client_id.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet processes the Authorization Request successfully; iss claim is silently ignored; Verifier is identified by the client_id claim only.
WS_RP_MS_ProtocolMessages_010
Objective
Verify that the Wallet does not process the request if client_id is missing from the Request Object.
References
- [RFC9101]
- [OpenID4VP] Section 5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet holds at least one credential that can match a valid DCQL query, and a second scenario where no matching credential is available.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends a Request Object where client_id is absent.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet rejects the request and returns an invalid_request error indicating missing client_id; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_011
Objective
Test that wallet continues with JAR when it receives a request_uri_method with the value post but does not support this feature.
References
- [RFC9101]
- [OpenID4VP] Sections 5, 6.4
Profile applicability
Wallet does not support POST method
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives Authorization Request with request_uri and request_uri_method = 'post'.
- Wallet does not support the POST method for request_uri retrieval.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Authorization Request is processed by the Wallet.
- Wallet falls back to JAR processing [RFC9101] using HTTP GET and continues with the flow.
WS_RP_MS_ProtocolMessages_012
Objective
Verify that the Wallet successfully evaluates a valid dcql_query that matches exactly one credential and proceeds with the presentation flow.
References
- [OpenID4VP] Sections 5, 6.4
- [ISO/IEC 18013-7] Annex C
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet contains a credential matching the request.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a valid dcql_query that matches exactly one credential held by the Wallet.
- Wallet evaluates the DCQL query and identifies the matching credential.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives and parses the Authorization Request successfully.
- Wallet selects the single matching credential and proceeds with the presentation flow.
WS_RP_MS_ProtocolMessages_013
Objective
Verify that the Wallet successfully evaluates a valid dcql_query that matches multiple credentials and presents the user with all candidate credentials for selection.
References
- [OpenID4VP] Sections 5, 6.4
- [ISO/IEC 18013-7] Annex C
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet contains a credential matching the request.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a valid dcql_query that matches multiple credentials held by the Wallet.
- Wallet evaluates the DCQL query and identifies multiple candidate credentials.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives and parses the Authorization Request successfully.
- Wallet presents the user with all matching credentials for selection; presentation flow proceeds after user selection.
WS_RP_MS_ProtocolMessages_014
Objective
Verify that the Wallet returns an error and does not initiate the presentation flow when no credential satisfies the dcql_query.
References
- [OpenID4VP] Sections 5, 6.4
- [ISO/IEC 18013-7] Annex C
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet does not hold a matching credential.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a valid dcql_query that cannot be satisfied by any credential held by the Wallet.
- Wallet evaluates the DCQL query and finds no matching credential.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives and parses the Authorization Request successfully.
- Wallet informs the user that no suitable credential is available and returns an access_denied error to the Verifier; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_015
Objective
Verify that the Wallet rejects the Authorization Request and returns an error when the dcql_query is malformed.
References
- [OpenID4VP] Sections 5, 6.4
- [ISO/IEC 18013-7] Annex C
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet contains a credential matching the request.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a malformed dcql_query.
- Wallet attempts to parse the dcql_query.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives the Authorization Request.
- Wallet rejects the Authorization Request and returns an invalid_request error; no credential is presented.
WS_RP_MS_ProtocolMessages_016
Objective
Verify that the Wallet ignores unrecognized parameters in the Authorization Request.
References
- [OpenID4VP] Section 5
- [RFC6749]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Authorization Request parameters under test apply to both regular Authorization Requests and Authorization Requests delivered via a Request Object (signed JWT, passed by value or by reference via request_uri).
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request containing one or more unrecognized parameters that are NOT transaction_data.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet ignores all unrecognized parameters and proceeds with the presentation flow as if those parameters were absent. No error is returned.
WS_RP_MS_ProtocolMessages_017
Objective
Verify that the Wallet rejects an Authorization Request that contains the transaction_data parameter when the wallet does not support this parameter.
References
- [OpenID4VP] Sections 5.8, 8.5
- [RFC6749]
Profile applicability
Wallet does not support transaction_data
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Authorization Request parameters under test apply to both regular Authorization Requests and Authorization Requests delivered via a Request Object (signed JWT, passed by value or by reference via request_uri).
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request that includes the transaction_data parameter the Wallet does NOT support.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet MUST reject the Authorization Request and return an invalid_transaction_data error; the presentation flow is NOT initiated.
WS_RP_MS_ProtocolMessages_018
Objective
Verify that the Wallet accepts an Authorization Request that contains the transaction_data parameter when the wallet does support this parameter.
References
- [OpenID4VP] Section 5
- [RFC6749]
Profile applicability
Wallet does not support transaction_data
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Authorization Request parameters under test apply to both regular Authorization Requests and Authorization Requests delivered via a Request Object (signed JWT, passed by value or by reference via request_uri).
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request that includes a valid transaction_data parameter to a Wallet that DOES support it.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet processes transaction_data correctly and proceeds with the presentation flow.
WS_RP_MS_ProtocolMessages_019
Objective
Verify that the Wallet processes an Authorization Request containing either a dcql_query parameter, or a scope parameter representing a DCQL Query.
References
- [OpenID4VP] Section 5.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
TODO: Need to check if EUDIW supports both by DCQL and scopes - and if scopes are supported which values are defined.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request containing only a dcql_query parameter.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet processes the Authorization Request successfully using the dcql_query.
WS_RP_MS_ProtocolMessages_020
Objective
Verify that the Wallet processes an Authorization Request containing either a dcql_query parameter, or ascope parameter representing a DCQL Query.
References
- [OpenID4VP] Section 5.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
TODO: Need to check if EUDIW supports both by DCQL and scopes - and if scopes are supported which values are defined.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request containing only a scope parameter representing a DCQL Query.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet processes the Authorization Request successfully using the scope parameter.
WS_RP_MS_ProtocolMessages_021
Objective
Verify that the Wallet rejects an Authorization Request containing both a dcql_query and a scope parameter simultaneously.
References
- [OpenID4VP] Section 5.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
TODO: Need to check if EUDIW supports both by DCQL and scopes - and if scopes are supported which values are defined.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request containing both a dcql_query and a scope parameter simultaneously.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet rejects the Authorization Request and returns an invalid_request error; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_022
Objective
Verify that when the Authorization Request contains a request_uri parameter and request_uri_method = "get", the Wallet retrieves the Request Object using HTTP GET as defined in RFC9101.
References
- [OpenID4VP] Section 5.1
- [RFC9101]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing request_uri and request_uri_method = "get".
- Wallet retrieves the Request Object.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Request parsed successfully.
- Wallet sends an HTTP GET to the request_uri, retrieves the Request Object, and processes the Authorization Request successfully.
WS_RP_MS_ProtocolMessages_023
Objective
Verify that when the Authorization Request contains a request_uri parameter and request_uri_method = "post", a Wallet that supports POST retrieves the Request Object using HTTP POST as defined in OID4VP Section 5.10.
References
- [OpenID4VP] Sections 5.1, 5.10
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing request_uri and request_uri_method = "post".
- Wallet retrieves the Request Object.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Request parsed successfully.
- Wallet sends an HTTP POST to the request_uri, retrieves the Request Object, and processes the Authorization Request successfully.
WS_RP_MS_ProtocolMessages_024
Objective
Test that the Wallet returns an error if a request contains even one unrecognized transaction data type or transaction data not conforming to the respective type definition.
References
- [OpenID4VP] Sections 5.1, 8.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request with a transaction_data array where at least one entry has an unrecognized transaction data type.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet returns an invalid_transaction_data error due to the unrecognized transaction data type; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_025
Objective
Verify that the Wallet returns an invalid_transaction_data error when the type field inside a transaction_data object is not a string.
References
- [OpenID4VP] Sections 5.1, 8.3, 8.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Applicable only if tested in combination with a Verifier that sends a transaction_data array.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends an Authorization Request containing a transaction_data array where at least one entry has a type field set to a non-string value (e.g. an integer, boolean, or object).
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet returns an invalid_transaction_data error; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_026
Objective
Verify that the Wallet returns an invalid_transaction_data error when the credential_ids field inside a transaction_data object is not a non-empty array of strings.
References
- [OpenID4VP] Sections 5.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Applicable only if tested in combination with a specific transaction data type.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends an Authorization Request containing a transaction_data object where credential_ids is set to a non-array value (e.g. a string, integer, or object).
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet returns an invalid_transaction_data error; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_027
Objective
Verify that the Wallet returns an invalid_transaction_data error when a string in the credential_ids array inside a transaction_data object does NOT match any id in the DCQL Credential Query.
References
- [OpenID4VP] Sections 5.1, 8.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Applicable only if tested in combination with a specific transaction data type.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends an Authorization Request containing a transaction_data object whose credential_ids array includes at least one string that does not match any id in the dcql_query.
- Wallet parses the transaction_data and cross-references credential_ids against the dcql_query.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives and parses the Authorization Request.
- Wallet returns an invalid_transaction_data error; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_028
Objective
Verify that the Wallet successfully processes a transaction_data object when every string in the credential_ids array matches an id in the DCQL Credential Query.
References
- [OpenID4VP] Section 5.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet supports the transaction_data type; Authorization Request includes a valid dcql_query.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends an Authorization Request containing a transaction_data object whose credential_ids array consists of strings all matching an id in the dcql_query.
- Wallet parses the transaction_data and cross-references credential_ids against the dcql_query.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives and parses the Authorization Request.
- Wallet validates that all credential_ids reference valid dcql_query ids and proceeds with the presentation flow using only the referenced Credentials for transaction authorization.
WS_RP_MS_ProtocolMessages_029
Objective
Verify that when a verifier_info attestation omits the credential_ids field, the Wallet applies the attestation to all Credentials requested in the DCQL query.
References
- [OpenID4VP] Section 5.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a verifier_info attestation with no credential_ids field.
- Wallet parses the attestation.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives and parses the Authorization Request.
- Wallet applies the attestation to all Credentials requested in the dcql_query; presentation flow proceeds.
WS_RP_MS_ProtocolMessages_030
Objective
Verify that when the Wallet supports scope-based Presentation requests and receives an Authorization Request containing a scope value it does not recognize, it rejects the request with an appropriate error.
References
- [OpenID4VP] Sections 5.5, 8.5
- [RFC6749]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing only a scope parameter with a value NOT recognized by the Wallet.
- Wallet parses the Authorization Request and attempts to resolve the scope value.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives and parses the Authorization Request.
- Wallet rejects the Authorization Request and returns an invalid_scope error; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_031
Objective
Verify that when the Wallet receives an Authorization Request containing a state parameter with a valid ASCII URL-safe value, it processes the request and returns the state unchanged in the Authorization Response.
References
- [OpenID4VP] Section 5.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a state parameter with a valid ASCII URL-safe value.
- Wallet parses the Authorization Request and prepares the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully parses the Authorization Request.
- Wallet processes the request and returns the state parameter unchanged in the Authorization Response.
WS_RP_MS_ProtocolMessages_032
Objective
Verify that when the Wallet receives an Authorization Request without a state parameter, it processes the request successfully without returning a state in the Authorization Response.
References
- [OpenID4VP] Section 5.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request without a state parameter.
- Wallet parses the Authorization Request and prepares the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully parses the Authorization Request.
- Wallet processes the request successfully without returning a state in the Authorization Response.
WS_RP_MS_ProtocolMessages_033
Objective
Verify that when the Wallet receives an Authorization Request containing a state parameter whose value is not a valid ASCII URL-safe string (e.g. a non-string type or contains disallowed characters), it rejects the request.
References
- [OpenID4VP] Sections 5.2, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction.
- Wallet receives an Authorization Request containing an invalid state parameter.
- Wallet parses and validates the state parameter.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully parses the Authorization Request.
- Wallet rejects the Authorization Request and returns an invalid_request error; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_034
Objective
Verify that when the Wallet receives an Authorization Request under the conditions of Section 5.3 (i.e. require_cryptographic_holder_binding = false) without a state parameter, it rejects the request.
References
- [OpenID4VP] Sections 5.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction.
- Wallet receives an Authorization Request under Section 5.3 conditions without a state parameter.
- Wallet parses the request.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully parses the Authorization Request.
- Wallet rejects the Authorization Request and returns an invalid_request error; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_035
Objective
Verify that the Wallet accepts vp_token as a valid response_type value in an Authorization Request and does not reject the request.
References
- [OpenID4VP] Section 5.6
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Verifier sends an Authorization Request with response_type = "vp_token".
- Wallet parses and validates the Authorization Request.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet accepts the response_type value and proceeds with the presentation flow without rejecting the request.
WS_RP_MS_ProtocolMessages_036
Objective
Test that when wallet receives a response_type of "vp_token" in an Authorization Request, that a successful response includes the vp_token parameter.
References
- [OpenID4VP] Section 5.6
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with response_type = "vp_token".
- Wallet parses and validates the Authorization Request.
- Wallet selects a matching credential based on the request parameters (e.g. dcql_query).
- Wallet generates and returns the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses and validates the Authorization Request.
- Wallet identifies and selects a matching credential.
- Wallet returns a successful Authorization Response that includes the vp_token parameter.
WS_RP_MS_ProtocolMessages_037
Objective
Test that when wallet receives a response_type of "vp_token" in an Authorization Request, the Wallet does NOT contain an OAuth 2.0 Authorization Code, Access Token, or Access Token Type in a successful response to the grant request.
References
- [OpenID4VP] Section 5.6
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet holds at least one credential matching the dcql_query in the Authorization Request.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with response_type = "vp_token".
- Wallet parses and validates the Authorization Request.
- Wallet selects a matching credential based on the dcql_query in the Authorization Request.
- Wallet generates the Authorization Response to the grant request.
- Inspect the full Authorization Response returned by the Wallet for the presence of OAuth 2.0 grant parameters (code, access_token, token_type).
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses and validates the Authorization Request.
- Wallet identifies and selects a matching credential from those referenced by the dcql_query.
- Wallet returns a successful Authorization Response to the grant request.
- The Authorization Response does NOT contain an OAuth 2.0 Authorization Code (code), Access Token (access_token), or Access Token Type (token_type) parameter.
WS_RP_MS_ProtocolMessages_038
Objective
Verify that when the Wallet receives an Authorization Request using the redirect_uri Client Identifier Prefix with a valid HTTPS URI, the Wallet recognizes the prefix, uses the embedded URI as the redirect/response target, and processes the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an unsigned Authorization Request with client_id = 'redirect_uri:https://client.example.org/cb'.
- Wallet parses the Authorization Request.
- Wallet recognizes the redirect_uri: prefix and extracts the embedded URI.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet recognizes the redirect_uri: prefix, uses the embedded URI as the redirect/response target, and processes the request successfully.
WS_RP_MS_ProtocolMessages_039
Objective
Verify that when the Wallet receives an Authorization Request using the redirect_uri Client Identifier Prefix where the embedded URI is not a valid HTTPS URL, the Wallet rejects the request and returns an invalid_request error.
References
- [OpenID4VP] Sections 8.5, 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request using the redirect_uri: prefix where the embedded URI is not a valid HTTPS URL (e.g. malformed URI or non-HTTPS scheme).
- Wallet parses the Authorization Request.
- Wallet validates the embedded URI.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet rejects the Authorization Request and returns an invalid_request error due to the invalid redirect URI; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_040
Objective
Verify that when the Verifier uses the redirect_uri Client Identifier Prefix and omits the redirect_uri Authorization Request parameter, the Wallet derives the redirect target from the Client Identifier and processes the request successfully.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with client_id using the redirect_uri: prefix and no redirect_uri parameter; response_mode is not direct_post.
- Wallet parses the Authorization Request.
- Wallet derives the redirect target from the Client Identifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet derives the redirect URI from the Client Identifier and processes the request successfully.
WS_RP_MS_ProtocolMessages_041
Objective
Verify that when the Verifier uses the redirect_uri Client Identifier Prefix with response_mode = direct_post.jwt and omits the response_uri Authorization Request parameter, the Wallet derives the response target from the Client Identifier and processes the request successfully.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with client_id using the redirect_uri: prefix, response_mode = direct_post.jwt, and no response_uri parameter.
- Wallet parses the Authorization Request.
- Wallet derives the response target from the Client Identifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet derives the response URI from the Client Identifier and processes the request successfully.
WS_RP_MS_ProtocolMessages_042
Objective
Verify that when the Wallet sends a request to the Verifier's Request URI Endpoint, it uses HTTP POST over HTTPS with Content-Type application/x-www-form-urlencoded and Accept header application/oauth-authz-req+jwt.
References
- [OpenID4VP] Section 5.10
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a request_uri and request_uri_method = post.
- Wallet prepares to send the POST request to the request_uri endpoint.
- Wallet sends the POST request. Observe the HTTP method, scheme, Content-Type header, and Accept header used.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet correctly prepares the POST request.
- Wallet sends an HTTP POST request to the request_uri using HTTPS, with Content-Type: application/x-www-form-urlencoded and Accept: application/oauth-authz-req+jwt.
WS_RP_MS_ProtocolMessages_043
Objective
Verify that when the Verifier's Request URI Endpoint is only accessible over plain HTTP (not HTTPS), the Wallet refuses to connect or rejects the request due to the non-HTTPS scheme.
References
- [OpenID4VP] Sections 8.5, 5.10
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a request_uri using the http:// scheme (not https://) and request_uri_method = post.
- Wallet prepares to send the POST request to the request_uri endpoint.
- Wallet attempts to connect.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet detects that the request_uri scheme is not HTTPS.
- Wallet refuses to connect or rejects the request and returns an invalid_request error due to non-HTTPS scheme; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_044
Objective
Verify that when the Wallet sends a POST request to the Verifier's Request URI Endpoint, all names and values in the request body are encoded using UTF-8.
References
- [OpenID4VP] Section 5.10
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet prepares the POST body for the request_uri endpoint.
- Wallet sends the POST request. Inspect the encoding of all names and values in the body.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet correctly prepares the POST body.
- All names and values in the POST body are encoded using UTF-8.
WS_RP_MS_ProtocolMessages_045
Objective
Verify that when the Wallet sends a POST request to the request_uri endpoint with a wallet_nonce value, the Verifier returns a signed Request Object containing the same wallet_nonce as the wallet_nonce claim, and the Wallet validates the match.
References
- [OpenID4VP] Section 5.10
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request to the request_uri endpoint including a wallet_nonce value.
- Wallet receives a signed Request Object containing the same wallet_nonce claim.
- Wallet validates that the wallet_nonce in the Request Object matches the value sent.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- wallet_nonce is correctly included in the POST request body.
- Wallet successfully receives the signed Request Object.
- Wallet validates the wallet_nonce match and continues processing the request.
WS_RP_MS_ProtocolMessages_046
Objective
Verify that when the Wallet sends a POST request to the request_uri endpoint with a wallet_nonce and the returned Request Object contains a different or missing wallet_nonce claim, the Wallet rejects the Request Object.
References
- [OpenID4VP] Sections 8.5, 5.10
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request to the request_uri endpoint including a wallet_nonce value.
- Wallet receives a signed Request Object whose wallet_nonce claim is different or absent.
- Wallet validates the wallet_nonce.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- wallet_nonce is correctly included in the POST request body.
- Wallet successfully receives the Request Object.
- Wallet rejects the Request Object and returns an invalid_request error due to wallet_nonce mismatch or absence; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_047
Objective
Verify that when the Wallet receives the Request URI response, it has Content-Type application/oauth-authz-req+jwt and the body is a signed (optionally encrypted) Request Object conforming to RFC9101.
References
- [OpenID4VP] Section 5.10.1
- [RFC9101]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request to the request_uri endpoint and receives the HTTP response.
- Inspect the Content-Type header and body of the response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully receives the HTTP response from the request_uri endpoint.
- HTTP response has Content-Type: application/oauth-authz-req+jwt and the body is a signed (optionally encrypted) Request Object conforming to RFC9101; presentation flow proceeds.
WS_RP_MS_ProtocolMessages_048
Objective
Verify that when the Wallet receives a Request URI response with an incorrect Content-Type (not application/oauth-authz-req+jwt), the Wallet rejects or fails to parse the response.
References
- [OpenID4VP] Sections 8.5, 5.10.1
- [RFC9101]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with request_uri_method = post.
- Wallet sends a POST request to the request_uri endpoint.
- Wallet receives a response with an incorrect Content-Type (e.g. application/json).
- Wallet inspects and attempts to parse the response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully sends the POST request.
- Wallet receives the response.
- Wallet rejects or fails to parse the response as a valid Request Object; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_049
Objective
Verify that when the Wallet receives an Authorization Request where the same parameter is present both in the query string and in the Request Object with different values, the Wallet uses only the value from the Request Object.
References
- [OpenID4VP] Section 5.10.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request where a parameter (e.g. nonce, response_mode) is present in both the query string and the Request Object with different values.
- Wallet parses both the query string and the Request Object.
- Wallet selects the parameter source for processing.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses both the query string and the Request Object.
- Wallet uses only the parameter values from the Request Object; the conflicting query parameter value is ignored; presentation flow proceeds.
WS_RP_MS_ProtocolMessages_050
Objective
Verify that when the Wallet receives an Authorization Request where the client_id in the query parameter and the Request Object client_id claim are identical (including the Client Identifier Prefix), the Wallet processes the request.
References
- [OpenID4VP] Section 5.10.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request where client_id is present in both the query string and the Request Object claim, identical (including the Client Identifier Prefix).
- Wallet parses the query string and the Request Object.
- Wallet compares the two client_id values.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses both sources.
- Wallet verifies the client_id values match exactly; request is processed; presentation flow proceeds.
WS_RP_MS_ProtocolMessages_051
Objective
Verify that when the Wallet receives an Authorization Request where the client_id in the query parameter and the Request Object client_id claim differ, the Wallet terminates request processing.
References
- [OpenID4VP] Sections 8.5, 5.10.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request where client_id in the query and client_id in the Request Object differ.
- Wallet parses the query string and the Request Object.
- Wallet compares the two client_id values.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses both sources.
- Wallet terminates processing and returns an invalid_request error due to client_id mismatch; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_052
Objective
Test the Wallet checks the DCQL query has a valid property "credentials" which is a non-empty array, containing valid entries (according to [OID4VP 6.1]).
References
- [OpenID4VP] Section 6
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a valid "credentials" property (as per section 6.1)
- Wallet can successfully use DCQL query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet responds to request without error
WS_RP_MS_ProtocolMessages_053
Objective
Test that if DCQL does not have a valid property "credentials", the Wallet rejects the request.
References
- [OpenID4VP] Sections 6, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a malformed "credentials" property
- The wallet evaluates the request
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_054
Objective
Test that if DCQL does not contain a property "credentials", the Wallet rejects the request.
References
- [OpenID4VP] Sections 6, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a missing "credentials"
- The wallet evaluates the request
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_055
Objective
Test that if DCQL contains a property "credentials" but is empty, the Wallet rejects the request.
References
- [OpenID4VP] Sections 6, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with an empty credentials array.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_056
Objective
Test that if DCQL contains a property "credentials" that is not an array, the Wallet rejects the request.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a non-array form credentials.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_057
Objective
Test when given a valid DCQL query that does not contain the credential_sets property, the Wallet is able to accept it.
References
- [OpenID4VP] Section 6
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a valid DCQL-query without a "credential_sets" property.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet responds to request without error
WS_RP_MS_ProtocolMessages_058
Objective
Test when credential_sets is present, the Wallet rejects credential_sets if it is an empty array.
References
- [OpenID4VP] Sections 6, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a "credential_sets" property that is an empty array.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_059
Objective
Test that the Wallet ignores unknown properties at the top level of a DCQL-query.
References
- [OpenID4VP] Section 6
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with unknown properties at the top level of the DCQL-query to the wallet.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet responds to request without error, the Wallet should not change its behavior in any way due to the unknown property.
WS_RP_MS_ProtocolMessages_060
Objective
Test that the Wallet ignores unknown properties in the structure (non-top-level) of the DCQL-query.
References
- [OpenID4VP] Section 6
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with unknown properties in the DCQL-query structure (non-top-level) to the wallet.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet responds to request without error, the Wallet should not change its behavior in any way due to the unknown property.
WS_RP_MS_ProtocolMessages_061
Objective
Test the Wallet rejects DCQL-query with credentials object without property "id"
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with missing "id" property
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_062
Objective
Test the Wallet rejects DCQL-query credential object property "id" when it is not a string
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with non-string "id" property
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_063
Objective
Test the Wallet rejects DCQL-query credential object property "id" when it is an empty string.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with empty string "id" property
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_064
Objective
Test the Wallet accepts DCQL-query credential object property "id" when it contains valid characters (consists of alphanumeric, underscore (_), or hyphen (-)).
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with valid "id" property containing characters of the form alphanumeric, underscore (_) and hyphen (-).
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet accepts and process the request, continuing to respond with matching response.
WS_RP_MS_ProtocolMessages_065
Objective
Test the Wallet rejects DCQL-query credential object property "id" when it consists of invalid characters (i.e. other than alphanumeric, underscore (_), or hyphen (-)).
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with "id" property containing a character other than alphanumeric, underscore (_), or hyphen (-).
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_066
Objective
Test the Wallet rejects DCQL-query credential object property "id" when it appears more than once within the Authorization request.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with the DCQL-query containing 2 'credential' with the same "id".
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_067
Objective
Test the Wallet accepts a DCQL-query with credential format values conform to those defined in [OID4VP] Appendix B.
References
- [OpenID4VP] Section 6.1
- [HAIP]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with a "format" value that is one of
mso_mdocordc+sd-jwt. - The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet accepts and process the request, continuing to respond with matching response without any error.
WS_RP_MS_ProtocolMessages_068
Objective
Test the Wallet rejects DCQL-query when the credentials property format is missing.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with the property "format" missing.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_069
Objective
Test the Wallet rejects DCQL-query when credential format values do not conform to those defined in [OID4VP] Appendix B and allowed by [HAIP]
References
- [OpenID4VP] Sections 6.1, 8.5
- [HAIP]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with a "format" value is one of
jwt_vc_json,ldp_vc. NOT HAIP allowed formatsmso_mdocordc+sd-jwt. - The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_070
Objective
Test the Wallet handles DCQL-query when credentials "multiple" property is omitted, as having the default value "false".
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains more than one credential matching the request.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential without the "multiple" property.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet responds with only one credential in the response without an error.
WS_RP_MS_ProtocolMessages_071
Objective
If "multiple" is present, the Wallet processes it when determining how many matching Credentials may be returned.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains more than one credential matching the request.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with the "multiple" value: TRUE.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet responds with multiple credentials in the response.
WS_RP_MS_ProtocolMessages_072
Objective
Test the Wallet rejects DCQL-query when credentials has an invalid "multiple" property.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with the "multiple" value in a non-boolean format.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_073
Objective
Test the credential property "meta" must be used by the wallet to constrain matching of any requested credential.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with "meta"
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet responds without error with credential matching dependent on the "meta" property.
WS_RP_MS_ProtocolMessages_074
Objective
Test the Wallet rejects a DCQL-query with credential property "meta" not applicable to the requested credential format.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with its "meta" property containing a value defined for another credential format as indicated by the "format" property.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_075
Objective
Test the Wallet rejects a DCQL-query with credential property "meta" omitted.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential missing its "meta" property.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_076
Objective
Test the Wallet accepts a DCQL-query with an empty credential property "meta" and handles request without further constraints on the credential.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains a credential in the requested format.
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with the "meta" property present with an empty value and the format matching an available credential.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet responds without error and includes the requested credential
WS_RP_MS_ProtocolMessages_077
Objective
Test the Wallet rejects a DCQL-query with the credential property "trusted_authorities" left empty.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with an empty "trusted_authorities" property.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_078
Objective
Test the Wallet rejects a DCQL-query with the credential property "trusted_authorities" in an incorrect format (i.e. not an array).
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with a non-empty, non-array type "trusted_authorities" property.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_079
Objective
Test if present the credential property "trusted_authorities", is made of objects defined in [OID4VP 6.1.1]
References
- [OpenID4VP] Sections 6.1.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with a non-empty array "trusted_authorities" property, but which includes an object not defined in [OID4VP 6.1.1]
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet responds with an error: "invalid_request"
WS_RP_MS_ProtocolMessages_080
Objective
Test that if the credential property "trusted_authorities" is not present, it will not invalidate credential
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential without the "trusted_authorities" property
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet is able to respond with credential matching, without an error.
WS_RP_MS_ProtocolMessages_081
Objective
Test the Wallet rejects a DCQL-query with credential property "require_cryptographic_holder_binding" present but in incorrect format (i.e. not a boolean)
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with the "require_cryptographic_holder_binding" property in NON-boolean form.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_082
Objective
Test that if credentials property "claims" is not present in the query it doesn't invalidate credential
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential without a "claims"
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet responds with a credential.
WS_RP_MS_ProtocolMessages_083
Objective
Test the Wallet rejects a DCQL-query with a credentials' property "claims" present that is empty.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with an empty "claims"
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_084
Objective
Test the Wallet rejects a DCQL-query with a credentials' property "claims" present that is not an array.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with a non-array type "claims"
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
-
Wallet receives the request.
-
Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_085
Objective
Test the Wallet rejects DCQL-query with credentials property "claim_sets" present that is empty.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with and empty
claim_sets. - The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_086
Objective
Test the Wallet rejects DCQL-query with credentials property "claim_sets" present that is not an array.
References
- [OpenID4VP] Sections 6.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credential with a non-array type claim_sets
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet detects an invalid credential "claims_sets" property and returns an invalid_request error
WS_RP_MS_ProtocolMessages_087
Objective
Test that the wallet can handle Multiple Credential Queries in a request which MAY request a presentation of the same Credential.
References
- [OpenID4VP] Section 6.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends two separate credential queries in one request, where both are matched to the same credential in the wallet.
- The wallet handles user consent and response.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet recognises that one credential satisfies both queries and MUST NOT return an error for this scenario, or force the user to "pick" the credential twice.
WS_RP_MS_ProtocolMessages_088
Objective
Test the Wallet Rejects a DCQL-query with a constraint on "trusted_authorities" with an unspecified type.
References
- [OpenID4VP] Sections 6.1.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential constraint with a trusted_authorities "type" that is not defined in [OID4VP 6.1]
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_089
Objective
Test the Wallet Rejects a DCQL-query with a constraint on "trusted_authorities" with a missing type.
References
- [OpenID4VP] Sections 6.1.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential with a "trusted_authorities" property missing its type parameter
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_090
Objective
Test the Wallet Rejects a DCQL-query with a constraint on "trusted_authorities" with a missing value property.
References
- [OpenID4VP] Sections 6.1.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential with a "trusted_authorities" property missing its value parameter
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_091
Objective
Test the Wallet Rejects a DCQL-query with a constraint on "trusted_authorities" with a type in an incorrect format.
References
- [OpenID4VP] Sections 6.1.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential with a "trusted_authorities" property with its type property not as a string.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_092
Objective
Test the Wallet Rejects a DCQL-query with a constraint on "trusted_authorities" with a value property in an incorrect format.
References
- [OpenID4VP] Sections 6.1.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential with a "trusted_authorities" property with its value property is not an array.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_093
Objective
Test the Wallet Rejects a DCQL-query with a constraint on "trusted_authorities" with a value containing an item that is not a string.
References
- [OpenID4VP] Sections 6.1.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential with a "trusted_authorities" property with its value property as an array containing an element that is not a string.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_094
Objective
Test the Wallet Rejects a DCQL-query with a constraint on "trusted_authorities" with a value property containing an item that is an empty string.
References
- [OpenID4VP] Sections 6.1.1, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential with a "trusted_authorities" property with its value property an array containing an empty string.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_095
Objective
Test the Wallet when processing trusted_authorities, type "etsi_tl" is supported.
References
- [OpenID4VP] Section 6.1.1
Profile applicability
Wallet supports trusted authorities query based on ETSI Trust List.
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query requesting a credential with a "trusted_authorities" property with its type being "etsi_tl".
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- No errors returned, with the wallet using the Trusted List when performing credential matching.
WS_RP_MS_ProtocolMessages_096
Objective
Test that the credential_sets "options" property is REQUIRED and correctly processed by the Wallet.
References
- [OpenID4VP] Sections 6.2, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "credential_sets" property, but where it is missing its "options" property.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet detects a missing credential_sets "options" property and returns an invalid_request error.
WS_RP_MS_ProtocolMessages_097
Objective
Test the "options" property must be non-empty.
References
- [OpenID4VP] Sections 6.2, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "credential_sets" property, but where its "options" property exists but is empty
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet detects a missing credential_sets "options" property and returns an invalid_request error.
WS_RP_MS_ProtocolMessages_098
Objective
Test the "options" property must be an array.
References
- [OpenID4VP] Sections 6.2, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "credential_sets" property, but where its "options" property exists but is not an array.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet detects a missing credential_sets "options" property and returns an invalid_request error.
WS_RP_MS_ProtocolMessages_099
Objective
Test the elements in "options" MUST be identifiers that reference elements in "credentials".
References
- [OpenID4VP] Section 6.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential_sets property
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The wallet confirms each "options" value maps to the "credentials" in the query, then successfully performs matching.
WS_RP_MS_ProtocolMessages_100
Objective
Test that if elements in "options" are NOT identifiers that reference elements in "credentials", the wallet will reject query and remain privacy preserving.
References
- [OpenID4VP] Sections 6.2, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential_sets property with different options' element mapping.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet stops the transaction, producing a privacy preserving error response.
WS_RP_MS_ProtocolMessages_101
Objective
Test that the credential_sets property "required" is correctly supported by the wallet when all credentials exist.
References
- [OpenID4VP] Section 6.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "credential_sets" property, including "required" property set as true for a set containing a PID that the wallet has.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet identifies that the set containing the PID is marked as required: true.
- The Wallet confirms the PID exists and satisfies the query. It prepares the PID for presentation.
- The Wallet presents the PID to the user. Because it is marked as required, the UI should indicate it is mandatory (e.g., no "skip" option for this specific set).
- The Wallet generates the Verifiable Presentation containing the PID as required by the Verifier
WS_RP_MS_ProtocolMessages_102
Objective
Test that the credential_sets property "required" is correctly supported by the wallet when a PID is missing.
References
- [OpenID4VP] Section 6.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "credential_sets" property, including "required" property set as true for a set containing a PID that the wallet is missing. No other sets available.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet realises it doesn't have PID and sees "required": true, hence it must NOT offer this set. No other sets are available, so the transaction stops, making sure it sends a privacy preserving response.
WS_RP_MS_ProtocolMessages_103
Objective
Test that the credential_sets property "required" will default to True if omitted.
References
- [OpenID4VP] Section 6.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "credential_sets" property "required" omitted
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet reacts identically to the test case where "required" was included and set to True.
WS_RP_MS_ProtocolMessages_104
Objective
Test that the credential_sets property "required" if set to False, the wallet can proceed with other valid sets flow without error.
References
- [OpenID4VP] Section 6.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with "required" credential_sets property set to False. The Credential looked for is missing in the wallet.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet sees missing credential but continues with next set and completes successful matching.
WS_RP_MS_ProtocolMessages_105
Objective
Test that the wallet can handle a DCQL query with a "credentials" object with a "claims" property present.
References
- [OpenID4VP] Section 6.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request with a DCQL-query with a credentials object with a claims property.
- Wallet can handle Query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet processes the DCQL query, it MUST use "id" and "path", and if present "values" 3.1. Claim properties are used to perform matching and complete matching without error.
WS_RP_MS_ProtocolMessages_106
Objective
test the Wallet will not attempt to return a credential when it can't find one due to "path".
References
- [OpenID4VP] Sections 6.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a path that does not exist in any of the wallets credentials
- Wallet handles Query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet correctly identifies that no credentials satisfy the query and returns access_denied (with the description that no credentials match).
WS_RP_MS_ProtocolMessages_107
Objective
test the Wallet will not attempt to return a credential when it can't find one due to "values" mismatch.
References
- [OpenID4VP] Sections 6.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with "values" mismatched to any of the wallets credentials
- Wallet handles Query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet correctly identifies that no credentials satisfy the query and returns access_denied (with the description that no credentials match).
WS_RP_MS_ProtocolMessages_108
Objective
Test that the Wallet will not accept a DCQL query if "claims" property "id" is not present, when claim_sets is present.
References
- [OpenID4VP] Sections 6.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential with "claims" object missing its "id" property, but a claim_sets is present.
- Wallet handles Query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet recognises missing "id" and occurring claim_sets, producing an error invalid_request.
WS_RP_MS_ProtocolMessages_109
Objective
Test that the Wallet will accept a DCQL query without a claims "id" if claim_sets is NOT present
References
- [OpenID4VP] Section 6.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a credential with "claims" object missing its "id" property, without a claim_sets present.
- Wallet handles Query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet concludes matching without error.
WS_RP_MS_ProtocolMessages_110
Objective
Test the Wallet checks that within a particular claims array, the same ID MUST NOT be present more than once.
References
- [OpenID4VP] Sections 6.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The verifier sends an Authorization request containing a "credentials" object which itself contains "claims" with the same "id" occurring twice in the claims array.
- Wallet handles Query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet detects duplicate claims "id" values in the claims array and returns an invalid_request error
WS_RP_MS_ProtocolMessages_111
Objective
Test the Wallet checks a claims object property "id" must be a non-empty.
References
- [OpenID4VP] Sections 6.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The verifier sends a DCQL query containing a "claims" object with "id" property whereby it is empty
- Wallet handles Query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet detects malformed "id" and returns an invalid_request error.
WS_RP_MS_ProtocolMessages_112
Objective
Test the Wallet checks a claims object property "id" must consist of alphanumeric, underscore (_), or hyphen (-) characters.
References
- [OpenID4VP] Sections 6.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The verifier sends a DCQL query containing a claims object with malformed "id" property whereby it contains a character NOT of the form alphanumeric, underscore (_), or hyphen (-).
- Wallet handles Query
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet detects malformed "id" and returns an invalid_request error.
WS_RP_MS_ProtocolMessages_113
Objective
Test that the Wallet will NOT accept a DCQL query with credentials with a claims property but without a claims "path" property.
References
- [OpenID4VP] Sections 6.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "claims" object missing its "path" property.
- Wallet handles Query.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet returns an invalid_request error.
WS_RP_MS_ProtocolMessages_114
Objective
The claims property "path" MUST be non-empty.
References
- [OpenID4VP] Sections 6.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The verifier sends a DCQL query containing a "claims" object with "path" property whereby it is empty.
- Wallet handles Query.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet returns an invalid request_error.
WS_RP_MS_ProtocolMessages_115
Objective
The claims property "path" MUST be an array.
References
- [OpenID4VP] Sections 6.3, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The verifier sends a DCQL query containing a "claims" object with "path" property whereby it is not an array.
- Wallet handles Query.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet returns an invalid_request error.
WS_RP_MS_ProtocolMessages_116
Objective
Test that the Wallet will accept a DCQL query with credentials with a claims property without a "values" property.
References
- [OpenID4VP] Section 6.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "claims" object missing its "values" property.
- Wallet handles Query.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet concludes matching without error.
WS_RP_MS_ProtocolMessages_117
Objective
Test that if credential_sets is not provided, the wallet interprets this as the Verifier requesting presentations for all Credentials in credentials to be returned.
References
- [OpenID4VP] Section 6.4.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query, with "credentials" asking for 2 credentials, "credential_sets" is NOT included.
- Wallet handles query.
Expected results
- Wallet and Verifier can interact.
- Wallet received query.
- The Wallet interprets the missing credential_sets as a mandatory request for all defined credentials without any "credential_sets" rules.
- The Wallet offers both credentials to the user as a single, required bundle.
- Upon consent, the Wallet generates a Verifiable Presentation containing both credentials.
WS_RP_MS_ProtocolMessages_118
Objective
Verify the positive flow that the Wallet can accept a claims path pointer that is a non-empty array whose members include the following: strings, nulls & non-negative integers.
References
- [OpenID4VP] Section 7
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer that is a non-empty array of strings, nulls & non-negative integers.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet accepts the claims path pointer and resolves the referenced claim successfully.
WS_RP_MS_ProtocolMessages_119
Objective
Verify negative case that the wallet cannot accept a claims path pointer that is an empty array.
References
- [OpenID4VP] Sections 7, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer that is an empty array.
Expected results
- Wallet-verifier interaction is successfully initiated.
- The Wallet rejects the request by either:
- answering with an error with details (
invalid_request), - answering with an error without providing details or,
- discontinuing the interaction.
- answering with an error with details (
WS_RP_MS_ProtocolMessages_120
Objective
Verify negative case that the Wallet cannot accept a claims path pointer that is an array that contains a Boolean.
References
- [OpenID4VP] Sections 7, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage Wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer that includes a boolean.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet rejects the request and returns an invalid_request error; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_121
Objective
Verify negative case that the Wallet cannot accept a claims path pointer that is an array that contains a negative integer.
References
- [OpenID4VP] Sections 7, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage Wallet-verifier interaction
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer that includes a negative integer.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet rejects the request and returns an invalid_request error; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_122
Objective
Verify negative case that the Wallet cannot accept a claims path pointer that is not an array.
References
- [OpenID4VP] Sections 7, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage Wallet-verifier interaction
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer that is not an array.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet rejects the request and returns an invalid_request error; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_123
Objective
Test that when the Wallet is given an invalid claims path pointer, it will abort processing and return an error.
References
- [OpenID4VP] Sections 7, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage Wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer with an invalid element (e.g. path: [true]).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet validates the structure of the claims path pointer.
- Wallet detects an element of an unsupported type.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet validates the path pointer structure.
- Wallet aborts processing and returns an error (e.g. invalid_request) due to invalid path pointer element type; presentation flow is not initiated.
WS_RP_MS_ProtocolMessages_124
Objective
Test that the Wallet ignores any unrecognized parameters when Response Mode = direct_post.jwt.
References
- [OpenID4VP] Section 8.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends a request, with parameter
response_mode=direct_post.jwtplus an additional unknown parameter. - The Wallet processes the request.
- The Wallet responds with request object.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The wallet evaluates the request, ignores the unknown parameter, and proceeds without returning an error.
- The wallet submits the Authorization Response to the verifier successfully.
WS_RP_MS_ProtocolMessages_125
Objective
Test that Wallet returns an error after an HTTP 200 response not of form json.
References
- [OpenID4VP] Sections 8.2, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends a request, with parameter 'response_mode=direct_post.jwt'.
- The Wallet processes the request.
- The Wallet responds with request object.
- Verifier sends an HTTP status code of 200 + a plain text body.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The wallet evaluates the request and proceeds without returning an error.
- The wallet submits the Authorization Response to the verifier's response_uri.
- The wallet detects that the verifier's HTTP 200 response body is not valid JSON and returns an error.
WS_RP_MS_ProtocolMessages_126
Objective
Test that Wallet returns an error after an HTTP error response from the Verifier.
References
- [OpenID4VP] Sections 8.2, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends a request, with parameter 'response_mode=direct_post.jwt'.
- The Wallet processes the request.
- The Wallet responds with request object.
- Verifier sends an HTTP status code of 400 + a JSON body.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The wallet evaluates the request and proceeds without returning an error.
- The wallet submits the Authorization Response to the verifier's response_uri.
- Wallet returns an error without crashing.
WS_RP_MS_ProtocolMessages_127
Objective
Test the Wallet ignores an unrecognized parameter provided by the Verifier in its JSON response, returned from a response_uri.
References
- [OpenID4VP] Section 8.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request, with response_type=vp_token, and parameter response_uri.
- The Wallet performs HTTP POST to the response_uri.
- The Verifier responds with HTTP 200 and a JSON body (containing an unrecognized parameter).
- Wallet processes JSON and triggers User agent.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The wallet submits the Authorization Response to the verifier's response_uri.
- The wallet receives the HTTP 200 JSON response.
- Wallet opens redirect_uri, shows user success page.
WS_RP_MS_ProtocolMessages_128
Objective
Test the Wallet ignores an unrecognized parameter in both the Authorization request & the response following a POST to a response_uri.
References
- [OpenID4VP] Section 8.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request, with response_type=vp_token, and parameter response_uri & unknown parameter.
- The Wallet performs HTTP POST to the response_uri.
- The Verifier responds with HTTP 200 and a JSON body (containing an unrecognized parameter).
- Wallet processes JSON and triggers User agent.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The wallet submits the Authorization Response to the verifier's response_uri.
- The wallet receives the verifier's HTTP 200 JSON response.
- Wallet opens redirect_uri, shows user success page.
WS_RP_MS_ProtocolMessages_129
Objective
Test that when the JWK has kid parameter, the Wallet MUST include that same kid value, in the kid JWE header of the response.
References
- [OpenID4VP] Section 8.3.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier
- The Verifier sends an Authorization request to the Wallet, with response mode=direct_post.jwt, and a client_metadata object containing a JWK with kid parameter
- Wallet processes request
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- Verify the Wallet returns a response, without an error, and that it includes that same kid value, in the kid JWE header of its response.
WS_RP_MS_ProtocolMessages_130
Objective
Test the Wallet chooses enc from Verifier metadata when explicitly set, to perform the response encryption.
References
- [OpenID4VP] Section 8.3.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The verifier sends an Authorization request to the Wallet, with response mode=direct_post.jwt, and a client_metadata object containing an enc parameter.
- Wallet processes request.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Verify the wallet returns a response, without an error, and that it uses that enc value in the verifier metadata to perform its encryption.
WS_RP_MS_ProtocolMessages_131
Objective
Test the Wallet will default to A128GCM for enc value, when Verifier metadata does NOT explicitly set it.
References
- [OpenID4VP] Section 8.3.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The verifier sends an Authorization request to the Wallet, with response mode=direct_post.jwt, and a client_metadata object containing NO enc parameter.
- Wallet processes request.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Verify the Wallet returns a response, without an error, and that it uses a default enc of A128GCM to perform its encryption.
WS_RP_MS_ProtocolMessages_132
Objective
Test the Wallet puts the response content fields at the top level of the JWT payload.
References
- [OpenID4VP] Section 8.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The verifier sends an Authorization request to the Wallet, with response mode=direct_post.jwt.
- Wallet processes request.
- Test the decrypted JWT payload sent by the Wallet contains all response parameters as top-level JSON members (not nested inside a sub-object).
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Verify the wallet returns an encrypted response.
- The decrypted JWT payload contains all response parameters as top-level JSON members, not nested inside a sub-object.
WS_RP_MS_ProtocolMessages_133
Objective
Test that Response Mode direct_post.jwt causes the Wallet to send the Authorization Response using an HTTP POST request.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request to the Wallet, with response mode=direct_post.jwt.
- Wallet processes request, returns response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Verify the wallet returns an Authorization response using an HTTP POST request.
WS_RP_MS_ProtocolMessages_134
Objective
Verify that for direct_post.jwt, the Wallet encapsulates the response in a JWT and delivers it via an HTTP POST body with the correct Content-Type.
References
- [OpenID4VP] Section 8.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request to the wallet, with response mode=direct_post.jwt.
- Wallet processes request, returns encrypted response.
- Verify the HTTP POST request content-type header shows it is application/x-www-form-urlencoded, and the HTTP POST request body contains only the Wallet response parameter holding the JWT.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Verify the wallet sends an HTTP POST request.
- Body is form-encoded and contains the response parameter holding the JWT.
WS_RP_MS_ProtocolMessages_135
Objective
Verify that when transaction_data is provided in the request, the Wallet includes a reference to it in the credential presentation, to ensure transaction integrity.
References
- [OpenID4VP] Section 8.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request containing a transaction_data object.
- Wallet displays the transaction data to the user, then processes request upon user approval.
- Verify the JWT payload contains reference to the transaction_data.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The wallet displays the transaction_data to the user and processes the request upon user approval.
- The wallet submits a presentation whose JWT payload contains a transaction_data_hashes parameter referencing the transaction_data from the request; the verifier successfully identifies and validates the reference.
WS_RP_MS_ProtocolMessages_136
Objective
Test a Wallet that received transaction_data in a request, but cannot support it, MUST return an error.
References
- [OpenID4VP] Section 8.4
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request containing a transaction_data object which the wallet cannot support.
- Wallet determines it cannot support this request.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Wallet does NOT show a credential selection screen to user, it will return an error response.
WS_RP_MS_ProtocolMessages_137
Objective
Test that the Wallet responds with invalid_scope when the Requested scope value is unknown.
References
- [OpenID4VP] Sections 5.2, 5.5, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request with a scope value that is intentionally unknown by wallet (e.g. a made up category of data).
- Wallet processes the request and identifies the scope as invalid.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The Wallet does NOT proceed to credential selection or user authorization.
- Verify: The Wallet returns an error response where the error parameter is exactly invalid_scope.
WS_RP_MS_ProtocolMessages_138
Objective
Test that the Wallet responds with invalid_scope when the Requested scope value is malformed.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request with a scope value that is intentionally malformed (e.g. illegal characters).
- Wallet processes the request and identifies the scope as invalid.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The Wallet does NOT proceed to credential selection or user authorization.
- The Wallet returns an error response where the error parameter is exactly invalid_scope.
WS_RP_MS_ProtocolMessages_139
Objective
Test that the Wallet responds with invalid_scope when the Requested scope value is empty.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request with a scope value that is intentionally empty (e.g. missing any value).
- Wallet processes the request and identifies the scope as invalid.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The Wallet does NOT proceed to credential selection or user authorization.
- The Wallet returns an error response where the error parameter is exactly invalid_scope.
WS_RP_MS_ProtocolMessages_140
Objective
Test that the Wallet will not leave the verifier hanging after an error response, it must terminate the session.
References
- [OpenID4VP] Sections 5.2, 5.5, 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request with a scope value that is intentionally empty (e.g. missing any value).
- Wallet processes the request and identifies the scope as invalid.
- Test the response returned by the Wallet to the Verifier.
- Test the Wallet terminates the session.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The wallet identifies the scope as invalid and does not proceed to credential selection or user authorization.
- The wallet returns an error response where the error parameter is exactly invalid_scope.
- The wallet terminates the session without leaving the verifier hanging; no further communication is sent.
WS_RP_MS_ProtocolMessages_141
Objective
Test the Wallet responds with invalid_request when the request contains both a dcql_query parameter and a scope parameter referencing a DCQL query.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request that includes both a valid dcql_query object & a scope value intended to trigger a DCQL based credential request.
- Wallet processes the request and identifies the conflicting parameters.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The Wallet does NOT proceed to credential selection or user authorization.
- The Wallet returns an error response where the error parameter is exactly invalid_request.
WS_RP_MS_ProtocolMessages_142
Objective
Test the Wallet responds with invalid_request when the request asks for a vp_token, but does not include instructions on what data to put in the token.
References
- [OpenID4VP] Sections 8.5, 8.6
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request with response_type=vp_token, but omitting both the dcql_query & any scope values referencing a credential.
- Wallet processes the request and identifies no data requirements provided.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- True: The Wallet does NOT proceed to credential selection or user authorization.
- Verify: The Wallet returns an error response where the error parameter is exactly invalid_request.
WS_RP_MS_ProtocolMessages_143
Objective
Test the Wallet responds with invalid_request when the Wallet does not support the Client Identifier Prefix passed in the Authorization Request.
References
- [OpenID4VP] Sections 8.5, 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request with an unsupported client_id prefix.
- Wallet processes the request and identifies unsupported prefix.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- True: The Wallet does NOT proceed to credential selection or user authorization.
- Verify: The Wallet returns an error response where the error parameter is exactly invalid_request.
WS_RP_MS_ProtocolMessages_144
Objective
Test the Wallet responds with invalid_request if the Client Identifier violates the specific security requirements of its prefix.
References
- [OpenID4VP] Sections 8.5, 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the verifier.
- The Verifier sends an Authorization request using client_id prefix HTTPS, but the request is sent as plain unsigned URL parameters, instead of a Signed Request Object (JWT).
- Wallet processes the request and identifies security violation for the prefix.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- True: The Wallet does NOT proceed to credential selection or user authorization.
- Verify: The Wallet returns an error response where the error parameter is exactly invalid_request.
WS_RP_MS_ProtocolMessages_145
Objective
Verify that the Wallet returns an invalid_client error when it receives client_metadata in a request from a Verifier that the Wallet already has locally stored metadata for.
References
- [OpenID4VP] Sections 8.5, 11.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet has stored trusted metadata for Verifier A.
Test Scenario
- The Wallet engages with verifier A.
- The Verifier sends an Authorization request that includes the client_metadata parameter, even though the Wallet already knows this client.
- Wallet identifies the conflict between the incoming metadata and the stored trusted metadata.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- True: The Wallet does NOT proceed to credential selection or user authorization.
- Verify: The Wallet returns an error response where the error parameter is exactly invalid_client.
WS_RP_MS_ProtocolMessages_146
Objective
Verify that the Wallet returns invalid_client when the client_id resolves to a trusted registry entry, but the request attempts to override it with dynamic client_metadata.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet is configured to resolve the client_id, via a trusted registry where Verifier A is pre-registered.
Test Scenario
- The Wallet engages with verifier A.
- The Verifier sends an Authorization request containing both a known client_id, and a client_metadata parameter.
- Wallet identifies the conflict between the incoming metadata and the pre-registered client.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- True: The Wallet does NOT proceed to credential selection or user authorization.
- Verify: The Wallet returns an error response where the error parameter is exactly invalid_client.
WS_RP_MS_ProtocolMessages_147
Objective
Test the Wallet returns the access_denied error message when the Wallet does not have the requested Credentials to satisfy the Authorization Request.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with verifier.
- The Verifier sends an Authorization request for credentials the wallet does not have.
- Wallet processes request.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The Wallet does NOT proceed to credential selection or user authorization.
- Verify the Wallet returns an error response, where the error parameter is exactly access_denied.
WS_RP_MS_ProtocolMessages_148
Objective
Test the Wallet returns the access_denied error message when the End-User did not give consent to share the requested Credentials with the Verifier.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with verifier.
- The Verifier sends an Authorization request for credentials the wallet does have.
- Wallet processes request.
- The User explicitly does NOT give consent to share requested credential.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The Wallet proceeds to credential selection or user authorization.
- The wallet detects the user's denial of consent and does not proceed with credential presentation.
- The Wallet does NOT return a vp_token, instead it returns an error response, where the error parameter is exactly access_denied.
WS_RP_MS_ProtocolMessages_149
Objective
Test the Wallet returns the access_denied error message when the Wallet failed to authenticate the End-User.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with verifier.
- The Verifier sends an Authorization request for credentials the wallet does have.
- Wallet processes request.
- The User fails authentication.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- The Wallet proceeds to credential selection or user authorization.
- True.
- Verify the Wallet does NOT return a vp_token, instead it returns an error response, where the error parameter is exactly access_denied.
WS_RP_MS_ProtocolMessages_150
Objective
Test the Wallet returns the error message vp_formats_not_supported when the wallet does not support any of the formats requested. (vc+sd-jwt case)
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet supports mso_mdoc, but does NOT support vc+sd-jwt
Test Scenario
- The Wallet engages with verifier.
- The Verifier sends an Authorization request for format vc+sd-jwt.
- Wallet processes request.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- The Wallet identifies it cannot fulfill request due to format requirement and does NOT show credential selection screen.
- Verify the Wallet returns an error response, where the error parameter is exactly vp_formats_not_supported.
WS_RP_MS_ProtocolMessages_151
Objective
Test the Wallet returns the error message vp_formats_not_supported when the Wallet does not support any of the formats requested. (mso_mdoc case)
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet supports vc+sd-jwt, but does NOT support mso_mdoc
Test Scenario
- The Wallet engages with verifier.
- The verifier sends an Authorization request where the vp_formats parameter only includes mso_mdoc.
- Wallet processes request.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- The Wallet identifies it cannot fulfill request due to format requirement and does NOT show credential selection screen.
- Verify the Wallet returns an error response, where the error parameter is exactly vp_formats_not_supported.
WS_RP_MS_ProtocolMessages_152
Objective
Test the Wallet returns the error message invalid_request_uri_method when the value of request_uri_method is invalid.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with verifier.
- The Verifier sends an Authorization request with request_uri, setting request_uri_method to an invalid value.
- Wallet processes request.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- The Wallet identifies it cannot fetch request object.
- Verify the Wallet returns an error response, where the error parameter is exactly invalid_request_uri_method.
WS_RP_MS_ProtocolMessages_153
Objective
Test the Wallet returns the invalid_transaction_data error message, when one object in the transaction_data structure contains an unsupported transaction data type value.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with verifier.
- The Verifier sends an Authorization request including a transaction_data array where one object has an unsupported type.
- Wallet processes request and the transaction_data structure.
- Test the response returned by the Wallet to the verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Wallet identifies unsupported type.
- Verify the Wallet does NOT proceed to the user consent screen, instead it must return an error response: invalid_transaction_data.
WS_RP_MS_ProtocolMessages_154
Objective
Test the Wallet returns the invalid_transaction_data error message, when one object in the transaction_data structure is an object of a known type but containing an unknown field.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with verifier.
- The Verifier sends an Authorization request including a transaction_data array where one object has a supported type but includes an unknown field.
- Wallet processes request and the transaction_data structure.
- Test the response returned by the Wallet to the verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Wallet identifies unknown field.
- Verify the Wallet does NOT proceed to the user consent screen, instead it must return an error response: invalid_transaction_data.
WS_RP_MS_ProtocolMessages_155
Objective
Test the Wallet returns the invalid_transaction_data error message, when one object in the transaction_data structure contains fields of the wrong type for the transaction data type.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet has a schema for a known transaction data type.
Test Scenario
- The Wallet engages with verifier.
- The Verifier sends an Authorization request including a transaction_data array where one object uses a known type, but with a field containing a different/wrong data type.
- Wallet processes request and the transaction_data structure.
- Test the response returned by the Wallet to the verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Wallet identifies type mismatch.
- Verify the Wallet does NOT proceed to the user consent screen, instead it must return an error response: invalid_transaction_data.
WS_RP_MS_ProtocolMessages_156
Objective
Test the Wallet returns the invalid_transaction_data error message, when one object in the transaction_data structure contains fields with invalid values for the transaction data type.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet has a defined range for a known transaction data type.
Test Scenario
- The Wallet engages with Verifier.
- The Verifier sends an Authorization request including a transaction_data array where one object uses a known type, but with a field of value of same type but outside defined range.
- Wallet processes request and the transaction_data structure.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Wallet identifies value outside acceptable range.
- Verify the Wallet does NOT proceed to the user consent screen, instead it must return an error response: invalid_transaction_data.
WS_RP_MS_ProtocolMessages_157
Objective
Test the Wallet returns the invalid_transaction_data error message, when one object in the transaction_data structure is missing required fields for the transaction data type.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet has a known transaction data type, where specific fields are marked as required.
Test Scenario
- The Wallet engages with Verifier.
- The Verifier sends an Authorization request including a transaction_data array where one object uses a known type, but with a missing mandatory field.
- Wallet processes request and the transaction_data structure.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Wallet identifies missing mandatory field.
- Verify the Wallet does NOT proceed to the user consent screen, instead it must return an error response: invalid_transaction_data.
WS_RP_MS_ProtocolMessages_158
Objective
Test the Wallet returns the invalid_transaction_data error message, when one object in the transaction_data structure has credential_ids that do not match to the credentials requested.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with Verifier.
- The Verifier sends an Authorization request including a transaction_data object that references a different set of IDs than the credentials requested.
- Wallet processes request and the transaction_data structure.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Wallet identifies mismatch of credential_ids.
- Verify the Wallet does NOT proceed to the user consent screen, instead it must return an error response: invalid_transaction_data.
WS_RP_MS_ProtocolMessages_159
Objective
Test the Wallet returns the invalid_transaction_data error message, when one object in the transaction_data structure has referenced Credential(s) that are not available in the Wallet.
References
- [OpenID4VP] Section 8.5
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with Verifier.
- The Verifier sends an Authorization request including a transaction_data object that contains credential_ids for a specific credential the Wallet does not have.
- Wallet processes request and the transaction_data structure.
- Test the response returned by the Wallet to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Wallet identifies that it does not hold credentials of credential_ids in transaction_data object.
- Verify the Wallet does NOT proceed to the user consent screen, instead it must return an error response: invalid_transaction_data.
Security Mechanisms
Security Mechanisms - Device Binding
WS_RP_SM_DeviceBinding_002
Objective
Verify that when the Wallet receives an Authorization Request containing a key-bound Verifier Info attestation whose signature object correctly includes both the nonce and client_id request parameters, the Wallet validates the signature and accepts the attestation.
References
- [OpenID4VP] Section 5.11.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a key-bound Verifier Info attestation whose signature object includes both the nonce and client_id parameters.
- Wallet parses the Authorization Request and the attestation.
- Wallet validates the signature object using the attestation's bound key.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the attestation.
- Wallet validates the signature object successfully and accepts the attestation; processing continues.
WS_RP_SM_DeviceBinding_003
Objective
Verify that when the Wallet receives an Authorization Request containing a key-bound Verifier Info attestation whose signature object is missing the nonce or client_id parameter, the Wallet rejects the attestation.
References
- [OpenID4VP] Section 5.11.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a key-bound Verifier Info attestation whose signature object is MISSING the nonce or client_id parameter.
- Wallet parses the Authorization Request and the attestation.
- Wallet validates the signature object.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the attestation.
- Wallet rejects the attestation and returns an invalid_request error due to missing nonce or client_id in the signature object; presentation flow is not initiated.
WS_RP_SM_DeviceBinding_004
Objective
Verify that when the Wallet receives a Verifier Info attestation whose proof is valid per the active profile, the Wallet successfully validates the proof and accepts the attestation.
References
- [OpenID4VP] Section 5.11.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with a Verifier Info attestation whose proof is valid per the active profile.
- Wallet parses the Authorization Request and the attestation.
- Wallet validates the proof per the active profile's rules.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the attestation.
- Wallet validates the proof successfully and accepts the attestation; processing continues.
WS_RP_SM_DeviceBinding_005
Objective
Verify that when the Wallet receives a Verifier Info attestation whose proof fails validation per the active profile, the Wallet rejects the attestation.
References
- [OpenID4VP] Section 5.11.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with a Verifier Info attestation whose proof FAILS validation per the active profile.
- Wallet parses the Authorization Request and the attestation.
- Wallet validates the proof per the active profile's rules.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the attestation.
- Wallet rejects the attestation and returns an invalid_request error due to proof validation failure; presentation flow is not initiated.
WS_RP_SM_DeviceBinding_006
Objective
Verify that when the Wallet receives a Verifier Info attestation of a type NOT defined or supported by the active profile, the Wallet ignores the unrecognized attachment type and continues processing the rest of the request.
References
- [OpenID4VP] Section 5.11.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request with a Verifier Info attestation of a type NOT defined by the active profile.
- Wallet parses the Authorization Request.
- Wallet inspects the attestation type.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request.
- Wallet ignores the unrecognized attestation type; processing continues with remaining valid request elements; presentation flow proceeds.
WS_RP_SM_DeviceBinding_007
Objective
Verify that whenever Wallet presents a SD-JWT containing a cnf claim, cnf conforms to definition given in [I-D.ietf-oauth-sd-jwt-vc].
References
- [HAIP] Section 6.1
- [RFC7800]
- [SD-JWT VC]
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier requests Credential presentation in IETF SD-JWT VC format.
- Wallet asks for user consent to present the Credential.
- User gives consent.
- Wallet presents Credential in IETF SD-JWT VC format.
- Check
cnfclaim is used within the SD-JWT component of the SD-JWT VC - Check
cnf.
Expected results
- Wallet-verifier interaction is initiated.
- Wallet receives the presentation request.
- Wallet asks for user consent.
- User consent is registered.
- Wallet presents Credential in IETF SD-JWT VC format.
cnfclaim is used within the SD-JWT component of the SD-JWT VCcnfcomplies with definition given in [I-D.ietf-oauth-sd-jwt-vc].
WS_RP_SM_DeviceBinding_008
Objective
Verify that when Verifier requires Cryptographic Key Binding, cnf claim is used within the SD-JWT component of the SD-JWT VC as described in [I-D.ietf-oauth-sd-jwt-vc].
References
- [HAIP] Section 6.1
- [RFC7800]
- [SD-JWT VC]
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Credential requested in the test supports Cryptographic Key Binding.
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in the IETF SD‑JWT VC format that supports Cryptographic Key Binding.
require_cryptographic_holder_bindingis set to true in the Credential Query.- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet presents Credential in IETF SD-JWT VC format.
- Check
cnfclaim is used within the SD-JWT component of the SD-JWT VC
Expected results
- This is the case.
- This is the case.
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet presents Credential in IETF SD-JWT VC format.
cnfclaim is used within the SD-JWT component of the SD-JWT VC
WS_RP_SM_DeviceBinding_009
Objective
Verify that when the Verifier sets require_cryptographic_holder_binding=false, the Wallet still includes the cnf claim within the SD-JWT component of the SD-JWT VC, providing the underlying credential type inherently includes it.
References
- [HAIP] Section 6.1
- [RFC7800]
- [SD-JWT VC]
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet holds a valid SD-JWT VC credential that inherently contains a cnf claim.
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier requests presentation from a Credential in IETF SD-JWT VC format
require_cryptographic_holder_bindingis set to false in the Credential Query- Wallet asks for user consent to present the Credential.
- User gives consent.
- Wallet presents Credential in IETF SD-JWT VC format.
- Check
cnfclaim is present within the SD-JWT component of the response.
Expected results
- Wallet-verifier interaction is initiated.
- Wallet receives the presentation request.
- Wallet processes the request parameter where holder binding is not mandated by the verifier.
- Wallet asks for user consent.
- User consent is registered.
- Wallet presents the Credential in IETF SD-JWT VC format.
- Verify that the cnf claim is included within the SD-JWT component of the SD-JWT VC response payload.
WS_RP_SM_DeviceBinding_010
Objective
Verify that when Wallet uses cnf claim within the SD-JWT component of the SD-JWT VC as described in [I-D.ietf-oauth-sd-jwt-vc], the claim contains the confirmation method identifying the proof of possession key.
References
- [HAIP] Section 6.1
- [RFC7800]
- [SD-JWT VC]
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet holds a valid SD-JWT VC credential that supports Cryptographic Key Binding.
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier requests presentation from a Credential in IETF SD-JWT VC Credential format that supports and/or requires Cryptographic Key Binding.
- Wallet asks for user consent to present the Credential.
- User gives consent.
- Wallet presents Credential in IETF SD-JWT VC format.
- Check
cnfclaim is used within the SD-JWT - Check
cnfcontent.
Expected results
- Wallet-verifier interaction is initiated.
- Wallet receives the presentation request.
- Wallet asks for user consent.
- User consent is registered.
- Wallet presents Credential in IETF SD-JWT VC format.
- The cnf claim is successfully used within the SD-JWT response payload.
- Verify the cnf claim contains the confirmation method identifying the proof of possession key as described in [I-D.ietf-oauth-sd-jwt-vc].
WS_RP_SM_DeviceBinding_011
Objective
Verify that when Wallet uses cnf claim within the SD-JWT component of the SD-JWT VC as described in [I-D.ietf-oauth-sd-jwt-vc], the KB-JWT in the presentation of the SD-JWT is secured by the key identified in cnf claim.
References
- [HAIP] Section 6.1
- [RFC7800]
- [SD-JWT VC]
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet holds a valid SD-JWT VC credential that supports Cryptographic Key Binding.
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier requests presentation from a Credential in IETF SD-JWT VC Credential format that supports and/or requires Cryptographic Key Binding.
- Wallet asks for user consent to present the Credential.
- User gives consent.
- Wallet presents Credential in IETF SD-JWT VC format.
- Check
cnfclaim is used within the SD-JWT component of the SD-JWT VC. - Verify that the KB-JWT in the presentation of the SD-JWT is secured by the key identified in 'cnf' claim.
Expected results
- Wallet-verifier interaction is initiated.
- Wallet receives the presentation request.
- Wallet asks for user consent.
- User consent is registered.
- Wallet presents Credential in IETF SD-JWT VC format.
- The 'cnf' claim is successfully used within the SD-JWT component of the SD-JWT VC response payload.
- Verify that the KB-JWT in the presentation of the SD-JWT is secured by the key identified in the 'cnf' claim.
WS_RP_SM_DeviceBinding_012
Objective
Verify that if the credential has cryptographic holder binding, Wallet presents a KB-JWT, as defined in [I-D.ietf-oauth-sd-jwt-vc] when presenting SD-JWT VC.
References
- [HAIP] Section 6.1.1.1
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet holds a valid SD-JWT VC credential that mandates Cryptographic Key Binding.
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in IETF SD‑JWT VC format that has Cryptographic Key Binding.
- Wallet asks for user consent to present the Credential.
- User gives consent.
- Wallet presents Credential in IETF SD-JWT VC format.
- Check if Wallet presents a KB-JWT.
Expected results
- Wallet-verifier interaction is initiated.
- Wallet receives the presentation request.
- Wallet asks for user consent to present the Credential.
- User consent is registered.
- Wallet presents Credential in IETF SD-JWT VC format.
- Verify that the Wallet successfully includes a structurally valid KB-JWT in the presentation payload, checking it aligns with definition held here: [OIDF.HAIP 6.1.1.1]
Security Mechanisms - Issuer Integrity
WS_RP_SM_IssuerIntegrity_012
Objective
Verify that Wallet uses MSO revocation mechanism following requirements defined in ISO/IEC 18013-5 ([ISO.18013-5.second.edition]).
References
- [HAIP] Section 5.3.1
- TODO: [ISO/IEC 18013-5] MSO revocation
Profile applicability
Wallet supports ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The mdoc's status is set to revoked.
Test Scenario
- Wallet and verifier engage.
- Verifier sends request for a revoked MSO.
- Wallet sends response.
Expected results
- Wallet and verifier successfully engage.
- Wallet processes request.
- Wallet returns error to verifier, without revealing reason (revocation of MSO).
WS_RP_SM_IssuerIntegrity_013
Objective
Verify that Wallet supports X.509 certificate-based key resolution to validate the issuer signature of an SD-JWT VC.
References
- [HAIP] Section 6.1.1
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential in IETF SD-JWT VC format.
- Verify if Wallet presents the Credential in IETF SD-JWT VC format.
- Check header's content from Credential presented by the Wallet.
Expected results
- This is the case.
- Wallet presents the Credential in IETF SD-JWT VC format.
- Wallet passes the headers properly and unmodified around. That is Credential's header Wallet received from the Credential Issuer are passed to the Verifier without any modification.
- Wallet verifies the header's content from Credential
WS_RP_SM_IssuerIntegrity_014
Objective
Verify that when Wallet is presenting the Credential in IETF SD-JWT VC format, the X.509 certificate of the trust anchor is not included in the x5c JOSE header of the SD-JWT VC.
References
- [HAIP] Section 6.1.1
Profile applicability
Wallet supports IETF SD-JWT VC
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Wallet receives a presentation request for a Credential in IETF SD-JWT VC format.
- Wallet presents the Credential in IETF SD-JWT VC format.
Expected results
- Wallet and verifier interact.
- Wallet processes the presentation request for a Credential in IETF SD-JWT VC format.
- The presentation response sent by the Wallet contains the Credential whose
x5cJOSE header includes the credential issuer's signing certificate along with a trust chain, but does not include the X.509 certificate of the trust anchor.
Security Mechanisms - RP Integrity
WS_RP_SM_RpIntegrity_CryptographicSignature002
Objective
Verify that Wallet does not support RSASSA-PSS using SHA-384 and MGF1 with SHA-384 (RS384) for validating signed presentation requests.
References
- [HAIP] Section 8
Profile applicability
JOSE algorithm identifier ES257
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential.
- Verify that Wallet receives signed request using RSASSA-PSS using SHA-384 and MGF1 with SHA-384 (RS384).from the Verifier.
- Wallet processes the request.
Expected results
- This is the case.
- This is the case.
- Wallet receives signed request using RSASSA-PSS using SHA-384 and MGF1 with SHA-384 (RS384).
- Wallet rejects the transaction and either:
a. returns specific error
invalid_client, b. returns general error, c. only discontinues the transaction.
WS_RP_SM_RpIntegrity_CryptographicSignature003
Objective
Verify that Wallet supports ECDSA with P-256 and SHA-256 (COSE algorithm identifier -7) for validating signed presentation requests.
References
- [HAIP] Section 7
Profile applicability
COSE algorithm identifier -7 supported
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential.
- Verify that Wallet receives signed request using ECDSA with P-256 and SHA-256 (COSE algorithm identifier -7) from the Verifier.
- Verify if Wallet is able to validate signed request from the Verifier that used ECDSA with P-256 and SHA-256 (COSE algorithm identifier -7)
Expected results
- This is the case.
- This is the case.
- Wallet receives signed request using ECDSA with P-256 and SHA-256 (COSE algorithm identifier -7) from the Verifier.
- Wallet is able to validate signed request from the Verifier that used ECDSA with P-256 and SHA-256 (JOSE algorithm identifier ES256; COSE algorithm identifier -7)
WS_RP_SM_RpIntegrity_CryptographicSignature004
Objective
Verify that Wallet supports ECDSA with P-256 and SHA-256 (COSE algorithm identifier -9) for validating signed presentation requests.
References
- [HAIP] Section 7
Profile applicability
COSE algorithm identifier -9 supported
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential.
- Verify that Wallet receives signed request using ECDSA with P-256 and SHA-256 (COSE algorithm identifier -9) from the Verifier.
- Verify if Wallet is able to validate signed request from the Verifier that used ECDSA with P-256 and SHA-256 (COSE algorithm identifier -9)
Expected results
- This is the case.
- This is the case.
- Wallet receives signed request using ECDSA with P-256 and SHA-256 (COSE algorithm identifier -9) from the Verifier.
- Wallet is able to validate signed request from the Verifier that used ECDSA with P-256 and SHA-256 (JOSE algorithm identifier ES256; COSE algorithm identifier -9)
WS_RP_SM_RpIntegrity_001
Objective
Verify that when the Wallet uses information from a verifier_info attestation and signature validation or binding verification fails, the Wallet rejects the Authorization Request.
References
- [OpenID4VP] Sections 5.1, 5.11
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
Wallet elected to use verifier_info
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request containing a verifier_info array whose attestation objects include a data member matching the declared format, but with either an invalid signature or incorrect binding to the Verifier/purpose.
- Wallet chooses to use the information from verifier_info, attempts to validate the signature and check binding.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives and parses the Authorization Request.
- Wallet rejects the Authorization Request due to signature or binding failure; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_002
Objective
Verify that when the Wallet receives a signed Request Object via the DC API with an invalid signature and is configured to validate signatures, it rejects the request.
References
- [OpenID4VP] Sections 5.3, 5.9.3, Appendix A
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction via the DC API.
- Wallet receives a Request Object via the DC API carrying an invalid signature.
- Wallet attempts to validate the signature.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet processes the Request Object.
- Wallet rejects the Authorization Request due to signature validation failure; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_003
Objective
Verify that when the Wallet receives a Request Object via the DC API and the Wallet is configured NOT to validate signatures, it processes the request without signature validation in accordance with its configured profile.
References
- [OpenID4VP] Sections 5.3, 5.9.3, Appendix A
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction via the DC API.
- Wallet receives a Request Object via the DC API.
- Wallet proceeds without signature validation.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet processes the Request Object.
- Wallet processes the request without signature validation in accordance with its configured profile; presentation flow proceeds.
WS_RP_SM_RpIntegrity_004
Objective
Verify that when the Wallet is configured to validate signatures on Request Objects received via the DC API and receives a Request Object with a valid signature, it successfully validates the signature and processes the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
DC API
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction via the DC API.
- Wallet receives a Request Object via the DC API carrying a valid signature.
- Wallet parses the Request Object.
- Wallet validates the signature according to its configured profile and trust anchors.
- Wallet proceeds with request processing.
Expected results
- Wallet-verifier interaction via the DC API is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet successfully validates the signature.
- Wallet processes the request and the presentation flow proceeds normally.
WS_RP_SM_RpIntegrity_005
Objective
Verify that when the Wallet is configured to validate signatures on Request Objects received via the DC API and receives a Request Object with an invalid signature, it rejects the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
DC API
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction via the DC API.
- Wallet receives a Request Object via the DC API carrying an invalid signature.
- Wallet parses the Request Object.
- Wallet attempts to validate the signature.
Expected results
- Wallet-verifier interaction via the DC API is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet rejects the Authorization Request due to signature validation failure; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_006
Objective
Verify that when the Wallet receives a Request Object signed using the decentralized_identifier Client Identifier Prefix where the signing key is identified by the kid JOSE header and is present in the verificationMethod of the resolved DID Document, the Wallet successfully verifies the signature.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object signed with the DID's private key and using the decentralized_identifier: Client Identifier Prefix; the kid header identifies the signing key.
- Wallet parses the Request Object.
- Wallet resolves the DID Document for the Verifier and locates the public key identified by kid in verificationMethod.
- Wallet verifies the Request Object signature using that public key.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet successfully resolves the DID Document and locates the public key.
- Wallet successfully verifies the signature using the public key from the DID Document verificationMethod; request is processed.
WS_RP_SM_RpIntegrity_007
Objective
Verify that when the Wallet receives a Request Object using the decentralized_identifier Client Identifier Prefix where the signing key is NOT listed in the verificationMethod of the resolved DID Document, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using decentralized_identifier: prefix where the signing key is NOT listed in the resolved DID Document verificationMethod.
- Wallet parses the Request Object.
- Wallet resolves the DID Document and attempts to locate the signing key.
- Wallet attempts signature verification.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet resolves the DID Document; signing key is not found in verificationMethod.
- Wallet rejects the Request Object and returns an invalid_request error due to signature verification failure; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_008
Objective
Verify that the Request Object is signed with the private key corresponding to the public key in the attestation cnf claim (proof of possession).
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using verifier_attestation: prefix; the attestation JWT contains a cnf claim with the Verifier's public key; the Request Object signature is made using the corresponding private key.
- Wallet parses the Request Object.
- Wallet extracts the public key from the cnf claim of the attestation JWT.
- Wallet verifies the Request Object signature using that public key.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet successfully extracts the public key from the cnf claim.
- Wallet successfully verifies proof of possession; presentation flow proceeds.
WS_RP_SM_RpIntegrity_009
Objective
Verify that the Request Object is signed with the private key corresponding to the public key in the attestation cnf claim (proof of possession).
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using verifier_attestation: prefix where the Request Object signature is made with a key that does NOT match the cnf claim public key.
- Wallet parses the Request Object.
- Wallet extracts the public key from the cnf claim.
- Wallet attempts signature verification.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet extracts the cnf claim public key.
- Wallet rejects the Request Object and returns an invalid_request error due to failed proof of possession; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_010
Objective
Verify that when the Wallet receives a Request Object whose Verifier attestation JWT has a valid signature and an iss claim identifying a trusted issuer of Verifier attestations, the Wallet establishes trust and processes the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object with a Verifier attestation JWT whose iss identifies a trusted issuer and whose signature is valid.
- Wallet parses the Request Object and the attestation JWT.
- Wallet validates the attestation JWT signature and checks the iss against its trusted issuer list.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and the attestation JWT.
- Wallet successfully validates the signature and trust; request is processed; presentation flow proceeds.
WS_RP_SM_RpIntegrity_011
Objective
Verify that when the Wallet receives a Request Object whose Verifier attestation JWT has an iss claim NOT listed among the Wallet's trusted issuers, the Wallet refuses the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object with a Verifier attestation JWT whose iss is NOT in the Wallet's trusted issuer list.
- Wallet parses the Request Object and the attestation JWT.
- Wallet checks the iss claim against its trusted issuer list.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and the attestation JWT.
- Wallet refuses the request and returns an invalid_client error due to untrusted attestation issuer; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_012
Objective
Verify that when the Wallet receives a Request Object whose Verifier attestation JWT signature is invalid, the Wallet refuses the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object with a Verifier attestation JWT whose signature is invalid.
- Wallet parses the Request Object and the attestation JWT.
- Wallet attempts to validate the attestation JWT signature.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and the attestation JWT.
- Wallet refuses the request and returns an invalid_client error due to invalid attestation JWT signature; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_013
Objective
Verify that when the Wallet receives a Request Object using an X.509-based Client Identifier Prefix (x509_san_dns or x509_hash) signed with the private key corresponding to the public key in the leaf certificate of the x5c JOSE header chain, the Wallet successfully verifies the signature.
References
- [OpenID4VP] Section 5.9.3
- [RFC7515]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- X.509 certificate is configured
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a signed Request Object using an X.509-based prefix where the signature is made with the leaf certificate's private key and x5c contains the certificate chain.
- Wallet parses the Request Object and the x5c JOSE header.
- Wallet extracts the leaf certificate's public key from x5c.
- Wallet verifies the Request Object signature using the leaf certificate public key.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and the x5c JOSE header.
- Wallet successfully extracts the leaf certificate's public key.
- Wallet successfully verifies the signature; request is accepted; presentation flow proceeds.
WS_RP_SM_RpIntegrity_014
Objective
Verify that when the Wallet receives a Request Object using an X.509-based Client Identifier Prefix where the x5c JOSE header is missing, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
- [RFC7515]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- X.509 certificate is configured
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a signed Request Object using an X.509-based prefix where the x5c JOSE header is missing.
- Wallet parses the Request Object JOSE header.
- Wallet attempts to extract the leaf certificate public key for signature verification.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object JOSE header.
- Wallet rejects the Request Object and returns an invalid_request error due to missing x5c header; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_015
Objective
Verify that when the Wallet receives a Request Object using an X.509-based Client Identifier Prefix where the signature key does NOT correspond to the leaf certificate in x5c, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
- [RFC7515]
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- X.509 certificate is configured
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a signed Request Object using an X.509-based prefix where the signature key does NOT correspond to the leaf certificate in x5c.
- Wallet parses the Request Object and x5c.
- Wallet attempts signature verification using the leaf certificate public key.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and x5c.
- Wallet rejects the Request Object and returns an invalid_request error due to signature verification failure; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_016
Objective
Verify that when the Wallet receives a Request Object using an X.509-based Client Identifier Prefix with a valid signature and a complete X.509 trust chain leading to a trusted root, the Wallet validates both the signature and the chain.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
x5c JOSE header contains the full certificate chain.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using an X.509-based prefix where the x5c chain is complete and leads to a trusted root, and the signature is valid.
- Wallet parses the Request Object and x5c.
- Wallet validates the X.509 trust chain.
- Wallet validates the Request Object signature using the leaf certificate.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and x5c.
- Wallet successfully validates the X.509 trust chain.
- Wallet successfully validates the signature; request is processed; presentation flow proceeds.
WS_RP_SM_RpIntegrity_017
Objective
Verify that when the Wallet receives a Request Object using an X.509-based Client Identifier Prefix where the X.509 trust chain is incomplete or leads to an untrusted root, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using an X.509-based prefix where the x5c chain is incomplete or leads to an untrusted root.
- Wallet parses the Request Object and x5c.
- Wallet attempts to validate the X.509 trust chain.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and x5c.
- Wallet rejects the Request Object and returns an invalid_request error due to failed trust chain validation; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_018
Objective
Verify that when the Wallet receives a Request Object using the x509_hash Client Identifier Prefix with a valid signature and a complete X.509 trust chain leading to a trusted root, the Wallet validates both the signature and the chain.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using x509_hash: prefix where the signature is valid and the certificate chain in x5c is complete and leads to a trusted root.
- Wallet parses the Request Object and x5c.
- Wallet validates the X.509 trust chain.
- Wallet validates the Request Object signature.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and x5c.
- Wallet successfully validates the X.509 trust chain.
- Wallet successfully validates the signature; request is accepted; presentation flow proceeds.
WS_RP_SM_RpIntegrity_019
Objective
Verify that when the Wallet receives a Request Object using the x509_hash Client Identifier Prefix where the X.509 trust chain is broken or leads to an untrusted root, the Wallet rejects the request.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using x509_hash: prefix where the certificate chain in x5c is broken or leads to an untrusted root.
- Wallet parses the Request Object and x5c.
- Wallet attempts to validate the X.509 trust chain.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object and x5c.
- Wallet rejects the Request Object and returns an invalid_request error due to failed trust chain validation; presentation flow is not initiated.
WS_RP_SM_RpIntegrity_020
Objective
Verify that when the Wallet receives a Request Object using the x509_hash Client Identifier Prefix with valid signature and trust chain, and all non-key Verifier metadata is provided within the client_metadata parameter, the Wallet uses client_metadata as the source of all non-key metadata.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using x509_hash: prefix where signature is valid, trust chain leads to a trusted root, and all non-key Verifier metadata is in client_metadata.
- Wallet parses the Request Object.
- Wallet validates signature and trust chain.
- Wallet extracts non-key Verifier metadata from client_metadata.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet successfully validates signature and trust chain.
- Wallet obtains all non-key Verifier metadata from client_metadata; request is accepted; presentation flow proceeds.
WS_RP_SM_RpIntegrity_021
Objective
Verify that when the Wallet receives a Request Object using the x509_hash Client Identifier Prefix where non-key Verifier metadata is provided outside the client_metadata parameter, the Wallet ignores such metadata and processes only what is contained within client_metadata.
References
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object using x509_hash: prefix where some non-key Verifier metadata is provided outside the client_metadata parameter.
- Wallet parses the Request Object.
- Wallet extracts Verifier metadata from the Request Object.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet ignores non-key Verifier metadata provided outside client_metadata and processes only the metadata within client_metadata; presentation flow proceeds.
WS_RP_SM_RpIntegrity_022
Objective
Verify that when the Wallet receives a Request Object via the DC API where the audience is the origin value prefixed by origin:, all non-key Verifier metadata is taken from client_metadata, and the Wallet processes the request within the DC API context.
References
- [OpenID4VP] Section 5.9.3, Appendix A.2
Profile applicability
DC API
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives a Request Object via DC API where audience uses the origin: prefix and all non-key Verifier metadata is in client_metadata.
- Wallet parses the Request Object.
- Wallet processes the audience as
origin:<origin>per DC API rules. - Wallet uses client_metadata for non-key Verifier metadata.
Expected results
- Wallet-verifier interaction via the DC API is successfully initiated.
- Wallet successfully receives the Request Object.
- Wallet successfully parses the Request Object.
- Wallet processes the audience correctly per DC API rules.
- Wallet uses client_metadata for all non-key Verifier metadata; presentation flow proceeds within the DC API context.
WS_RP_SM_RpIntegrity_023
Objective
Verify that, for signed requests, Wallet accepts Client Identifier Prefix x509_hash as defined in section 5.9.3 of [OIDF.OID4VP].
References
- [HAIP] Section 5 (introduction)
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends signed presentation request.
- Verifier uses Client Prefix "x509_hash" correctly.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet presents Credential successfully.
Expected results
- This is the case.
- This is the case.
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet presents Credential successfully.
WS_RP_SM_RpIntegrity_024
Objective
Verify that, for signed requests, if Verifier does not use Client Identifier Prefix x509_hash, the Wallet responds with an error (detailed or not) or discontinues the transaction.
References
- [HAIP] Section 5 (introduction)
- [OpenID4VP] Section 5.9.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends a signed presentation request.
- Verifier does not use Client Prefix "x509_hash".
- Wallet processes the request.
Expected results
- This is the case.
- This is the case.
- Wallet either:
a. answers with an error with details (
invalid_request), b. answers with an error without providing details or, c. discontinues the interaction.
WS_RP_SM_RpIntegrity_025
Objective
Verify that if X.509 certificate of the trust anchor is included in the x5c JOSE header of the signed request, the Wallet responds with an error (detailed or not) or discontinues the transaction.
References
- [HAIP] Section 5 (introduction)
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends signed presentation request.
- Verifier includes X.509 certificate of the trust anchor in the
x5cJOSE header of the signed request. - Wallet processes the request.
Expected results
- This is the case.
- This is the case.
- This is the case.
- Wallet either:
a. answers with an error with details (
invalid_client), b. answers with an error without providing details or, c. discontinues the interaction.
WS_RP_SM_RpIntegrity_026
Objective
Verify that if X.509 certificate signing the request is self-signed, the Wallet responds with an error (detailed or not) or discontinues the transaction.
References
- [HAIP] Section 5 (introduction)
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends signed presentation request.
- X.509 certificate signing the request is self-signed.
- Wallet processes the request.
Expected results
- This is the case.
- This is the case.
- This is the case.
- Wallet either:
a. answers with an error with details (
invalid_client), b. answers with an error without providing details or, c. discontinues the interaction.
WS_RP_SM_RpIntegrity_027
Objective
Verify that, in the presentation flow via Redirects, Wallet rejects presentation request if the signature validation of the JWT-Secured Authorization Request fails.
References
- [HAIP] Section 5.1
- [RFC9101] Section 5
Profile applicability
Presentations via Redirects
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
A Signature from authorization request is authentic.
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends Signed Authorization Request using JWT-Secured Authorization Request (JAR) [RFC9101] with the
request_uriparameter, and signature is authentic. - Verify if the Wallet obtains the request object from the
request_uri. - Wallet checks signature on the request object.
Expected results
- This is the case.
- This is the case.
- Wallet obtains the request object from the
request_uri. - Signature validation fails and Wallet either:
a. answers with an error with details (
invalid_request_object), b. answers with an error without providing details or, c. discontinues the interaction.
WS_RP_SM_RpIntegrity_028
Objective
Verify that Wallet supports unsigned, requests.
References
- [HAIP] Section 5.2
Profile applicability
Presentations via the W3C Digital Credentials API or equivalent platform.
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends unsigned request.
- Verify if Wallet answers unsigned request successfully.
Expected results
- This is the case.
- This is the case.
- Wallet answers unsigned request successfully.
WS_RP_SM_RpIntegrity_029
Objective
Verify that Wallet supports signed requests.
References
- [HAIP] Section 5.2
Profile applicability
Presentations via the W3C Digital Credentials API or equivalent platform.
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends signed request.
- Verify if Wallet answers signed request successfully.
Expected results
- This is the case.
- This is the case.
- Wallet answers signed request successfully.
WS_RP_SM_RpIntegrity_030
Objective
Verify that Wallet supports multi-signed requests.
References
- [HAIP] Section 5.2
Profile applicability
Presentations via the W3C Digital Credentials API or equivalent platform.
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends multi-signed request.
- Verify if Wallet answers multi-signed request successfully.
Expected results
- This is the case.
- This is the case.
- Wallet answers multi-signed request successfully.
WS_RP_SM_RpIntegrity_031
Objective
Verify that Wallet supports ECDSA with P-256 and SHA-256 (JOSE algorithm identifier ES256) for validating signed presentation requests.
References
- [HAIP] Section 7
Profile applicability
JOSE algorithm identifier ES256
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Verify that Wallet receives signed request using ECDSA with P-256 and SHA-256 (JOSE algorithm identifier ES256) from the Verifier.
- Verify if Wallet is able to validate signed request from the Verifier that used ECDSA with P-256 and SHA-256 (JOSE algorithm identifier ES256)
Expected results
- Wallet receives signed request using ECDSA with P-256 and SHA-256 (JOSE algorithm identifier ES256) from the Verifier.
- Wallet is able to validate signed request from the Verifier that used ECDSA with P-256 and SHA-256 (JOSE algorithm identifier ES256)
WS_RP_SM_RpIntegrity_032
Objective
Verify that Wallet does not support RSASSA-PSS using SHA-384 and MGF1 with SHA-384 (RS384) for validating signed presentation requests.
References
- [HAIP] Section 8
Profile applicability
JOSE algorithm identifier ES257
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential.
- Verify that Wallet receives signed request using RSASSA-PSS using SHA-384 and MGF1 with SHA-384 (RS384).from the Verifier.
- Wallet processes the request.
Expected results
- This is the case.
- This is the case.
- Wallet receives signed request using RSASSA-PSS using SHA-384 and MGF1 with SHA-384 (RS384).
- Wallet rejects the transaction and either:
a. returns specific error
invalid_client, b. returns general error, c. only discontinues the transaction.
WS_RP_SM_RpIntegrity_033
Objective
Verify that Wallet supports ECDSA with P-256 and SHA-256 (COSE algorithm identifier -7) for validating signed presentation requests.
References
- [HAIP] Section 7
Profile applicability
COSE algorithm identifier -7 supported
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential.
- Verify that Wallet receives signed request using ECDSA with P-256 and SHA-256 (COSE algorithm identifier -7) from the Verifier.
- Verify if Wallet is able to validate signed request from the Verifier that used ECDSA with P-256 and SHA-256 (COSE algorithm identifier -7)
Expected results
- This is the case.
- This is the case.
- Wallet receives signed request using ECDSA with P-256 and SHA-256 (COSE algorithm identifier -7) from the Verifier.
- Wallet is able to validate signed request from the Verifier that used ECDSA with P-256 and SHA-256 (JOSE algorithm identifier ES256; COSE algorithm identifier -7)
WS_RP_SM_RpIntegrity_034
Objective
Verify that Wallet supports ECDSA with P-256 and SHA-256 (COSE algorithm identifier -9) for validating signed presentation requests.
References
- [HAIP] Section 7
Profile applicability
COSE algorithm identifier -9 supported
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request for Credential.
- Verify that Wallet receives signed request using ECDSA with P-256 and SHA-256 (COSE algorithm identifier -9) from the Verifier.
- Verify if Wallet is able to validate signed request from the Verifier that used ECDSA with P-256 and SHA-256 (COSE algorithm identifier -9)
Expected results
- This is the case.
- This is the case.
- Wallet receives signed request using ECDSA with P-256 and SHA-256 (COSE algorithm identifier -9) from the Verifier.
- Wallet is able to validate signed request from the Verifier that used ECDSA with P-256 and SHA-256 (JOSE algorithm identifier ES256; COSE algorithm identifier -9)
Security Mechanisms - Session Binding
WS_RP_SM_SessionBinding_001
Objective
Verify that when the Wallet receives an Authorization Request that contains a valid nonce parameter, the wallet will accept the Authorization Request.
References
- [OpenID4VP] Sections 5.2, 14.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request containing a valid nonce parameter.
Expected results
- Wallet-verifier interaction is successfully initiated.
- The Wallet successfully receives the Authorization Request.
WS_RP_SM_SessionBinding_002
Objective
Test that the Wallet rejects Authorization Requests that do not contain a nonce parameter.
References
- [OpenID4VP] Sections 5, 14.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- The Wallet receives an Authorization Request where the nonce parameter is absent.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet rejects the Authorization Request and returns an invalid_request error; presentation flow is not initiated.
WS_RP_SM_SessionBinding_003
Objective
Test that the Wallet rejects Authorization Requests that do not contain a valid nonce parameter.
References
- [OpenID4VP] Sections 5, 14.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code). 2.The Wallet receives an Authorization Request where the nonce contains characters outside the ASCII URL safe character set.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet rejects the Authorization Request and returns an invalid_request error due to invalid nonce character set.
Security Mechanisms - Session Encryption
WS_RP_SM_SessionEncryption_001
Objective
Verify that if the Wallet encrypts the Authorization Response it uses an unsigned, encrypted JWT.
References
- [OpenID4VP] Section 8
- [RFC7519]
Profile applicability
Encrypted response
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends an Authorization request to the wallet, with response mode=direct_post.jwt.
- Wallet returns an encrypted Authorization response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Verify the Encryption the wallet used is an unsigned, encrypted JWT [RFC7519].
WS_RP_SM_SessionEncryption_002
Objective
Test the Wallet ensures that the selected Verifier JWK contains an alg parameter.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends an Authorization request to the wallet, with response mode=direct_post.jwt, and a client_metadata object containing a JWK without an alg parameter.
- Wallet processes request.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives request.
- Verify the wallet does NOT send a response, instead returns an error.
WS_RP_SM_SessionEncryption_003
Objective
Test the Wallet checks the JWE alg value exactly matches the alg value from the chosen JWK.
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The wallet engages with the verifier.
- The verifier sends an Authorization request to the wallet, with response mode=direct_post.jwt, and a client_metadata object containing a JWK with an alg value different to the JWE alg value
- Wallet processes request
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- Verify the wallet does NOT send a response, instead returns an error
WS_RP_SM_SessionEncryption_005
Objective
Verify that in the encrypted response sent by the Wallet: the JWE alg (algorithm) header parameter (as defined in section 4.1.1 of [RFC7516]) value is set to ECDH-ES (as defined in section 4.6 of [RFC7518]), with key agreement utilizing keys on the P-256 curve (as defined in section 6.2.1.1 of [RFC7518]).
References
- [HAIP] Section 5 (introduction)
- [OpenID4VP] Section 8.3
- [RFC7516] Section 4.1.1
- [RFC7518] Section 6.2.1.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends a presentation request
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet sends encrypted response by using utilizing response mode direct_post.jwt.
- Verify if, in the encrypted response, the JWE alg (algorithm) header parameter value is set ECDH-ES.
- Verify if key agreement uses keys on the P-256 curve.
Expected results
- This is the case.
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet sends encrypted response.
- In the encrypted response, JWE alg (algorithm) header parameter value is set ECDH-ES.
- Key agreement uses keys on the P-256 curve.
WS_RP_SM_SessionEncryption_006
Objective
Verify that Wallet raises an error if there is no jwk within client_metadata sent by the Verifier with alg value set to ECDH-ES.
References
- [HAIP] Section 5 (introduction)
- TODO: [OpenID4VP] Section 8.3 The alg parameter MUST be present in the JWKs
- [RFC7516] Section 4.1.1
- [RFC7518] Section 6.2.1.1
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Verify that Wallet raises an error if there is no "jwk" within "client_metadata" sent by the Verifier with "alg" value set to ECDH-ES.
Expected results
- Wallet raises an error.
WS_RP_SM_SessionEncryption_007
Objective
Verify that Wallet supports A128GCM for the JWE enc (encryption algorithm).
References
- [HAIP] Section 5 (introduction)
- [OpenID4VP] Section 8.3
- [RFC7516] Section 4.1.2
Profile applicability
Wallet supports only A128GCM
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends a presentation request.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet sends an encrypted response.
- Check value from JWE "enc" (encryption algorithm) header parameter used by the Wallet.
Expected results
- This is the case.
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet sends an encrypted response.
- JWE "enc" value is set to A128GCM.
WS_RP_SM_SessionEncryption_008
Objective
Verify that Wallet supports A256GCM for the JWE enc (encryption algorithm).
References
- [HAIP] Section 5 (introduction)
- [OpenID4VP] Section 8.3
- [RFC7516] Section 4.1.2
Profile applicability
Wallet supports only A256GCM
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends a presentation request.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet sends an encrypted response.
- Check value from JWE "enc" (encryption algorithm) header parameter used by the Wallet.
Expected results
- This is the case.
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet sends an encrypted response.
- JWE "enc" value is set to A256GCM.
WS_RP_SM_SessionEncryption_009
Objective
Verify that if both A128GCM and A256GCM are supported for the JWE enc (encryption algorithm), Wallet will use A256GCM for the JWE enc
References
- [HAIP] Section 5 (introduction)
- [OpenID4VP] Section 8.3
- [RFC7516] Section 4.1.2
Profile applicability
Wallet supports A128GCM and A256GCM
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends a presentation request.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet sends an encrypted response.
- Check value from JWE "enc" (encryption algorithm) header parameter (section 4.1.2 of [RFC7516]) used by the Wallet.
Expected results
- This is the case.
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet sends an encrypted response.
- JWE "enc" value is set to A256GCM.
WS_RP_SM_SessionEncryption_010
Objective
Verify that if Verifier did not supply ephemeral encryption public keys specific to each Authorization Request via client metadata, the Wallet responds with an error (detailed or not) or discontinues the transaction.
References
- [HAIP] Section 5 (introduction)
- [OpenID4VP] Section 8.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends a presentation request and does not supply ephemeral encryption public keys specific to each Authorization Request.
- Check Wallet behaviour.
Expected results
- This is the case.
- This is the case.
- Wallet either:
a. answers with an error with details (
invalid_client_metadata), b. answers with an error without providing details or, c. discontinues the interaction.
WS_RP_SM_SessionEncryption_011
Objective
Verify that - for each authorization request - Wallet uses the correct ephemeral key passed via client metadata in the encryption process.
References
- [HAIP] Section 5 (introduction)
- [OpenID4VP] Section 8.3
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request including 2 authorization requests, ephemeral public key
key1for authorization request 1 and ephemeral public keykey2for authorization request 2. - Verify if Wallet uses the correctly ephemeral public key for each one of the authorization requests in the response encryption process.
Expected results
- This is the case.
- Wallet uses
key1as input for key agreement included in the encryption process of the response related to "authorization request 1". - Wallet uses
key2as input for key agreement included in the encryption process of the response related to "authorization request 2".
WS_RP_SM_SessionEncryption_012
Objective
Verify that, in the presentation flow via Redirects, Wallet sends encrypted response when Authorization Request includes response_mode parameter set to direct_post.jwt.
References
- [HAIP] Section 5.1
- [OpenID4VP] Section 8.3
Profile applicability
Presentations via Redirects
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends presentation request with response mode direct_post.jwt.
- Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet sends encrypted response using parameters provided in "client_metadata".
- Verify if Verifier is able to decrypt response sent by the Wallet.
Expected results
- This is the case.
- This is the case.
- Wallet asks for user consent.
- This is the case.
- Wallet sends encrypted response using parameters provided in "client_metadata".
- Verifier is able to decrypt response sent by the Wallet.
Security Mechanisms - Trust Mechanisms
WS_RP_SM_TrustMechanisms_002
Objective
Test that the Wallet when processing trusted_authorities, the type "aki" is supported.
References
- [OpenID4VP] Section 6.1.1.1
- [RFC5280] Section 4.2.1.1
Profile applicability
Wallet supports trusted authorities query based on 'aki'.
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends a DCQL query containing a credential query with trusted_authorities of type "aki", and a specific KeyIdentifier value that matches the AuthorityKeyIdentifier of an X.509 certificate.
- The Wallet returns a response to the Verifier.
Expected results
- Wallet and Verifier can interact.
- Wallet successfully receives the DCQL query.
- The Wallet returns an Authorization Response containing the matching credential.
WS_RP_SM_TrustMechanisms_003
Objective
Test the Wallet processes a DCQL-query with an "aki" correctly when it does contain a matching credential.
References
- [OpenID4VP] Section 6.1.1.1
- [RFC5280]
Profile applicability
Wallet supports trusted authorities query based on 'aki'
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The stored credential in the Wallet used in test is issued under a certificate chain containing a specified AuthorityKeyIdentifier
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "trusted_authorities" property with its type being "aki", and its value contains a specific keyIdentifier of a certificate in the certificate chain of the credential issuer
- The Wallet evaluates the request and allows the user to continue with presenting matching credentials.
- User selects the available credential and approves to present it.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet allows the user to select the credential matching the certificate chain.
- The Wallet presents the selected credential.
WS_RP_SM_TrustMechanisms_004
Objective
Test the Wallet processes a DCQL-query with an "aki" correctly when it does not contain a matching credential.
References
- [OpenID4VP] Section 6.1.1.1
- [RFC5280]
Profile applicability
Wallet supports trusted authorities query based on 'aki'
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The stored credential(s) in the Wallet used in test is/are issued under a certificate chain with none of the certificates matching a specified AuthorityKeyIdentifier.
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "trusted_authorities" property with its type being "aki", and its 'value' contains only a value not matching any AuthorizationKeyIdentifier in the credential issuer's certificate chain.
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet informs the user it has no matching credential available, and does not (allow to) continue to present any credential to the verifier.
WS_RP_SM_TrustMechanisms_005
Objective
Test the Wallet processes a DCQL-query with an "aki" correctly when it does contain a matching credential, with the match in the end-entity (Issuer) certificate.
References
- [OpenID4VP] Section 6.1.1.1
- [RFC5280]
Profile applicability
Wallet supports trusted authorities query based on 'aki'
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The stored credential in the Wallet used in test is issued under a certificate chain containing a specified AuthorityKeyIdentifier in the end-entity (Issuer) certificate, with the chain having a depth of at least 3.
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "trusted_authorities" property with its type being "aki", and its value contains a specific keyIdentifier of the end-entity (Issuer) certificate in the certificate chain of the credential issuer
- The Wallet evaluates the request and allows the user to continue with presenting matching credentials.
- User selects the available credential and approves to present it.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet allows the user to select the credential matching the certificate chain.
- The Wallet presents the selected credential.
WS_RP_SM_TrustMechanisms_006
Objective
Test the Wallet processes a DCQL-query with an "aki" correctly when it does contain a matching credential, with the match in a sub-CA certificate.
References
- [OpenID4VP] Section 6.1.1.1
- [RFC5280]
Profile applicability
Wallet supports trusted authorities query based on 'aki'
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The stored credential in the Wallet used in test is issued under a certificate chain containing a specified AuthorityKeyIdentifier in a sub-CA certificate, with the chain having a depth of at least 3.
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "trusted_authorities" property with its type being "aki", and its value contains a specific keyIdentifier of a sub-CA certificate in the certificate chain of the credential issuer
- The Wallet evaluates the request and allows the user to continue with presenting matching credentials.
- User selects the available credential and approves to present it.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet allows the user to select the credential matching the certificate chain.
- The Wallet presents the selected credential.
WS_RP_SM_TrustMechanisms_007
Objective
Test the Wallet processes a DCQL-query with an "aki" correctly when it does contain a matching credential, with the match in the CA certificate.
References
- [OpenID4VP] Section 6.1.1.1
- [RFC5280]
Profile applicability
Wallet supports trusted authorities query based on 'aki'
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The stored credential in the wallet used in test is issued under a certificate chain containing a specified AuthorityKeyIdentifier of the CA certificate, with the chain having a depth of at least 3.
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query with a "trusted_authorities" property with its type being "aki", and its value contains a specific keyIdentifier of the CA certificate in the certificate chain of the credential issuer
- The Wallet evaluates the request and allows the user to continue with presenting matching credentials.
- User selects the available credential and approves to present it.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- The Wallet allows the user to select the credential matching the certificate chain.
- The Wallet presents the selected credential.
WS_RP_SM_TrustMechanisms_008
Objective
Test the Wallet processes a DCQL-query with an aki trusted_authorities value correctly when the Wallet does NOT contain a credential whose X.509 certificate chain matches the specified AuthorityKeyIdentifier.
References
- [OpenID4VP] Section 6.1.1.1
Profile applicability
Wallet supports trusted authorities query based on 'aki'.
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends a DCQL query containing a credential query with trusted_authorities of type aki and a KeyIdentifier value that does NOT match the AuthorityKeyIdentifier of any X.509 certificate in the chain of any credential the Wallet holds.
- The Wallet returns a response to the Verifier.
Expected results
- Wallet and Verifier can interact.
- The Wallet successfully receives the DCQL query.
- The Wallet does not return any credential in the Authorization Response (no credential satisfies the aki constraint).
WS_RP_SM_TrustMechanisms_009
Objective
Test the Wallet can resolve a trusted_authorities request of type etsi_tl by matching the credential's issuer against a recognized ETSI Trusted List.
References
- [OpenID4VP] Section 6.1.1.2
Profile applicability
Wallet supports trusted authorities query based on ETSI Trust List.
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
A mock ETSI trusted List is active to be used
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query requesting a credential with a "trusted_authorities" property with its type being "etsi_tl".
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request. 3a. The Wallet checks the issuer of its stored credential against the entries in the Trusted List. 3b. It confirms the Issuer's status according to the list's metadata. 3c. The Wallet displays the credential to the user because the Issuer was found and validated in the ETSI list.
WS_RP_SM_TrustMechanisms_010
Objective
Test the Wallet can resolve a trusted_authorities request of type etsi_tl by matching the credential's issuer against a recognized ETSI Trusted List scenario when no Match.
References
- [OpenID4VP] Section 6.1.1.2
Profile applicability
Wallet supports trusted authorities query based on ETSI Trust List.
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
Credential Issuer is not on Trusted List A mock ETSI trusted List is active to be used
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query requesting a credential with a "trusted_authorities" property with its type being "etsi_tl".
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request. 3a. The Wallet checks the issuer of its stored credential against the entries in the Trusted List. 3b. It confirms the Issuer's status according to the list's metadata. 3c. The Wallet does not use the credential if the Issuer is not on the list (even if the credential is valid otherwise). 3d. Wallet will make sure it only returns privacy-safe error response to verifier.
WS_RP_SM_TrustMechanisms_011
Objective
Test the wallet can resolve a trusted_authorities request of type etsi_tl by matching the credential's issuer against a recognized ETSI Trusted List scenario when invalid trusted list.
References
- [OpenID4VP] Section 6.1.1.2
Profile applicability
Wallet supports trusted authorities query based on ETSI Trust List.
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
Scenario when the Trusted List signature is invalid or if the URL in the query is unreachable. A mock ETSI trusted List is active to be used
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query requesting a credential with a "trusted_authorities" property with its type being "etsi_tl".
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request. 3a. The Wallet checks the issuer of its stored credential against the entries in the Trusted List. 3b. It confirms the Issuer's status according to the list's metadata. 3c. The wallet will not use the credential and returns an error if the Trusted List signature is invalid or if the URL in the query is unreachable. 3d. Wallet will make sure it only returns privacy-safe error response to verifier.
WS_RP_SM_TrustMechanisms_012
Objective
The Wallet can parse the identifier of a Trusted List as specified in ETSI TS 119 612 [ETSI.TL], in a "trusted_authorities" request.
References
- [OpenID4VP] Section 6.1.1.2 TODO: ETSI TS 119 612 [ETSI.TL]
Profile applicability
Wallet supports trusted authorities query based on ETSI Trust List.
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
A mock ETSI trusted List is active to be used
Test Scenario
- The Wallet engages with the Verifier.
- Verifier sends a DCQL query requesting a credential with a "trusted_authorities" property with its type being "etsi_tl".
- The Wallet evaluates the request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request. 3a. The Wallet successfully extracts the URI string 3b. Wallet fetches the list, validates that it follows the ETSI TS 119 612 schema (correctly handling XML or JSON).
WS_RP_SM_TrustMechanisms_013
Objective
Verify the Wallet can navigate an ETSI Trusted List (List of Trusted Lists) to identify and validate a Trust Service Provider’s (TSP) certificate.
References
- [OpenID4VP] Section 6.1.1.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
The Wallet contains a credential issued by a valid Trust Service Provider (TSP). A mock ETSI trusted List is active to be used
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request containing a DCQL query with trusted_authorities of type etsi_tl whose value is the URL of the ETSI Trusted List.
- The Wallet returns a response to the Verifier.
Expected results
- Wallet and Verifier can interact.
- The Wallet successfully receives the DCQL query.
- The Wallet returns an Authorization Response containing the credential whose issuing Trust Service Provider is listed in the linked Trusted List or its cascading Trusted Lists.
WS_RP_SM_TrustMechanisms_015
Objective
Test the Wallet will not return a credential if its X.509 Certificate trust chain cannot be verified against the specified etsi_tl or its cascading lists.
References
- [OpenID4VP] Section 6.1.1.2
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_optional
Preconditions
A mock ETSI trusted List is active to be used
Test Scenario
- The Wallet engages with the Verifier.
- The Verifier sends an Authorization Request containing a DCQL query with trusted_authorities of type etsi_tl, with values containing the identifier of the Trusted List, but no wallet credential's X.509 in the cascading Trusted List entries.
- The Wallet returns a response to the Verifier.
Expected results
- Wallet and Verifier can interact.
- The Wallet successfully receives the DCQL query.
- The Wallet does not return any credential in the Authorization Response.
WS_RP_SM_TrustMechanisms_021
Objective
Verify that Wallet can handle Authorization Request using authorization key identifier mechanism to support multiple X.509-based trust mechanism supported by the Wallet profile.
References
- [HAIP] Section 5 (introduction)
- [OpenID4VP] Sections 6.1.1.1, 8.5
Profile applicability
multiple X.509-based trust mechanisms supported by the Wallet
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- End-user interacts with the Verifier, triggering the Verifier to send a presentation request.
- Verifier sends Credential Query to the Wallet using Authority Key Identifier (aki)-based Trusted Authority Query (trusted_authorities) for DCQL.
akiarray includes a collection of encoded Key Identifiers from the certificates- Verify that Wallet does not answer with error
invalid_request, which can be sent when the Wallet does not support the Client Identifier Prefix passed in the Authorization Request. - Verify if Wallet asks for user consent to present the Credential.
- User gives consent.
- Verify if Wallet answers Credential Query successfully.
Expected results
- This is the case.
- This is the case.
- This is the case.
- Wallet does not answer with error
invalid_request, which can be sent when the Wallet does not support the Client Identifier Prefix passed in the Authorization Request. - Wallet asks for user consent.
- This is the case.
- Wallet answers Credential Query successfully
Shared
Shared - Cryptography
WS_RP_SH_Cryptography_CryptographicHash001
Objective
Verify that when presenting an IETF SD-JWT VC, the Wallet produces a Verifiable Presentation whose digests are generated using SHA-256.
References
- [HAIP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet holds a presentable IETF SD-JWT VC.
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives Authorization Request.
- Wallet returns the Authorization Response. Inspect the vp_token and the Verifier's validation outcome of the SD-JWT VC digests under SHA-256.
Expected results
- Wallet-Verifier interaction is successfully initiated.
- Wallet successfully processes Authorization Request.
- Wallet sends an Authorization Response whose vp_token holds the SD-JWT VC with SHA-256-based digests.
WS_RP_SH_Cryptography_CryptographicHash002
Objective
Verify that whenever Wallet uses hash function during presentation for ISO mdoc, it leverages hash algorithm SHA-256.
References
- [HAIP] Section 9
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Wallet engages with the Verifier.
- Wallet receives Authorization Request.
- Wallet returns the Authorization Response and receives the response acknowledging the presentation.
Expected results
- Wallet successfully engages with the Verifier.
- Wallet processes Authorization Request.
- Wallet sends an Authorization Response whose vp_token holds the ISO mdoc with SHA-256-based digests.
WS_RP_SH_Cryptography_CryptographicHash006
Objective
Verify that Wallet includes in its metadata information related to other hash algorithms supported, if the Wallet profile allows other hash algorithms
References
- [HAIP] Section 8
Profile applicability
Wallet supports other hash algorithms besides SHA-256.
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
There is a defined mechanism for this Wallet profile, through which Verifier receives Wallet Metadata.
Test Scenario
- Verify if Wallet includes other hash algorithms supported (besides SHA-256) in its Metadata.
Expected results
- Wallet does include other hash algorithms supported (besides SHA-256) in its Metadata.
WS_RP_SH_Cryptography_CryptographicHash007
Objective
Verify that Wallet does not use other hash algorithm than SHA-256 during presentation if that is not supported by the Verifier.
References
- [HAIP] Section 8
Profile applicability
Wallet supports other hash algorithms besides SHA-256.
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
- Verifier Client Metadata does not include any other hash algorithms.
Test Scenario
- Wallet engages with the Verifier.
- Wallet receives the Authorization Request whose client metadata advertises SHA-256 only.
- Wallet returns the Authorization Response and receives the response acknowledging the presentation.
Expected results
- Wallet successfully initiates the interaction and
- Wallet receives the Authorization Request advertising SHA-256 only.
- Wallet sends an Authorization Response whose vp_token holds SHA-256-based digests.
WS_RP_SH_Cryptography_CryptographicHash008
Objective
Verify that Wallet raises an error if Verifier uses any hashing function other than SHA-256 and that is not included in the Verifier Client Metadata.
References
- [HAIP] Section 8
Profile applicability
Wallet does not support other hash algorithms besides SHA-256.
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Verifier Client Metadata does not include any other hash algorithms. Verifier uses other hashing functions than SHA-256.
Test Scenario
- Verify if Wallet raises an error when Verifier uses any hashing function other than SHA-256.
Expected results
- Wallet raises an error when Verifier uses any hashing function other than SHA-256.
WS_RP_SH_Cryptography_CryptographicHash010
Objective
Verify that when the credential to be presented uses a digest hash algorithm other than SHA-256 that the Wallet does not support, the Wallet does not produce a presentation for that credential.
References
- [HAIP] Section 8
Profile applicability
Wallet does not support other hash algorithms besides SHA-256.
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Credential Issuer Metadata does not include any other hash algorithms. Credential Issuer uses other hashing functions than SHA-256.
Test Scenario
- Wallet engages with the Verifier.
- Wallet receives the Authorization Request targeting the credential whose digest algorithm is not SHA-256.
- Wallet processes the Authorization Request.
Expected results
- Wallet successfully initiates the interaction.
- Wallet receives the Authorization Request.
- Wallet does not send an Authorization Response containing a vp_token for that credential, presentation is terminated.
WS_RP_SH_Cryptography_Encryption002
Objective
Verify that if encrypted_response_enc_values_supported within client metadata from the Verifier, does not include A256GCM, and Wallet only supports A256GCM, the Wallet responds with an error.
References
- [HAIP] Section 5 (introduction)
- [OpenID4VP] Section 8.3
- [RFC7516] Section 4.1.2
Profile applicability
Wallet supports only A256GCM
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request using response mode direct_post.jwt, whose client metadata lists encrypted_response_enc_values_supported without A256GCM.
- Wallet processes the request.
- Wallet returns its response to the Authorization Request.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet receives the Authorization Request
- Wallet successfully proccesses request.
- Wallet returns an access_denied error.
Shared - Encodings
WS_RP_SH_Encoding_TextualEncoding001
Objective
Test that in a claims path pointer array, a string value indicates the respected key is to be selected.
References
- [OpenID4VP] Section 7
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet has a credential: { "name": "Arthur Dent", "address": { "street_address": "42 Market Street", "locality": "Milliways", "postal_code": "12345" }, "degrees": [ { "type": "Bachelor of Science", "university": "University of Betelgeuse" }, { "type": "Master of Science", "university": "University of Betelgeuse" } ], "nationalities": ["British", "Betelgeusian"] }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer where one element is a string (e.g. path: ["name"]).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet evaluates the claims path pointer against the matching JSON-based Credential.
- Wallet selects the claim value at the key indicated by the string element.
- Wallet generates and returns the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet correctly resolves the path pointer to the targeted key in the Credential.
- Wallet selects the value associated with that key (e.g. "Arthur Dent" for path: ["name"]).
- Wallet returns an Authorization Response containing only the selected claim value.
WS_RP_SH_Encoding_TextualEncoding002
Objective
Test that a null value indicates that all elements of the currently selected array(s) are to be selected.
References
- [OpenID4VP] Section 7
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "name": "Arthur Dent", "address": { "street_address": "42 Market Street", "locality": "Milliways", "postal_code": "12345" }, "degrees": [ { "type": "Bachelor of Science", "university": "University of Betelgeuse" }, { "type": "Master of Science", "university": "University of Betelgeuse" } ], "nationalities": ["British", "Betelgeusian"] }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer where one element is null and the currently selected element at that position is an array (e.g. path: ["degrees", null, "type"]).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet evaluates the claims path pointer against the matching JSON-based Credential.
- Wallet expands the null element to select all elements of the currently selected array(s).
- Wallet generates and returns the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet correctly resolves the path pointer up to the null element.
- Wallet selects all elements of the currently selected array(s) at the null position (e.g. all type values across all entries of the degrees array).
- Wallet returns an Authorization Response containing all selected claim values.
WS_RP_SH_Encoding_TextualEncoding003
Objective
Test that a non-negative integer indicates that the respective index in an array is to be selected.
References
- [OpenID4VP] Section 7
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "name": "Arthur Dent", "address": { "street_address": "42 Market Street", "locality": "Milliways", "postal_code": "12345" }, "degrees": [ { "type": "Bachelor of Science", "university": "University of Betelgeuse" }, { "type": "Master of Science", "university": "University of Betelgeuse" } ], "nationalities": ["British", "Betelgeusian"] }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer where one element is a non-negative integer and the currently selected element at that position is an array (e.g. path: ["nationalities", 1]).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet evaluates the claims path pointer against the matching JSON-based Credential.
- Wallet selects the array element at the index indicated by the integer.
- Wallet generates and returns the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet correctly resolves the path pointer up to the integer element.
- Wallet selects the array element at the specified index (e.g. "Betelgeusian" for path: ["nationalities", 1], where nationalities[1] = "Betelgeusian").
- Wallet returns an Authorization Response containing only the selected array element value.
WS_RP_SH_Encoding_TextualEncoding004
Objective
Test that the claims path pointer array is processed left to right
References
- [OpenID4VP] Sections 7, 7.1.1
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "name": "Arthur Dent", "address": { "street_address": "42 Market Street", "locality": "Milliways", "postal_code": "12345" }, "degrees": [ { "type": "Bachelor of Science", "university": "University of Betelgeuse" }, { "type": "Master of Science", "university": "University of Betelgeuse" } ], "nationalities": ["British", "Betelgeusian"] }
Test Scenario
- The Wallet engages with the Verifier
- A Verifier sends a request With a DCQL-query with
patharray: ["street_address", "address"]. - Wallet handles request
- Wallet responds to request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet successfully parses the request.
- Verify the wallet responds with an error
WS_RP_SH_Encoding_TextualEncoding005
Objective
Test that the Wallet handles DCQL-query for SD-JWT VC credential with a matching top-level claim path pointer.
References
- [OpenID4VP] Sections 7, 7.1.1
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet contains an attestation with a specific top-level attribute.
Test Scenario
- The Wallet engages with the Verifier
- A Verifier sends a request With a DCQL-query with a claims for the attestation with
pathwith value an array containing the named attribute. - Wallet handles request
- Wallet responds to request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet successfully parses the request.
- Verify the wallet responds with the credential, including selective disclosure of the named attribute.
WS_RP_SH_Encoding_TextualEncoding006
Objective
Test that the Wallet handles DCQL-query for SD-JWT VC credential with a non-matching top-level claim path pointer.
References
- [OpenID4VP] Sections 7, 7.1.1
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The Wallet contains an attestation without a specific top-level attribute.
Test Scenario
- The Wallet engages with the Verifier
- A Verifier sends a request With a DCQL-query with a claims for the attestation with
pathwith value an array containing the name of the specified top-level attribute - Wallet handles request
- Wallet responds to request.
Expected results
- Wallet and Verifier can interact.
- Wallet receives the request.
- Wallet successfully parses the request.
- Wallet rejects the request by either:
a. answering with an error with details (
invalid_request), b. answering with an error without providing details or, c. discontinuing the interaction.
WS_RP_SH_Encoding_TextualEncoding007
Objective
Test that when processing claims path pointer array, an element at the first level is selected. If the selected element is not an object, abort processing and return an error
References
- [OpenID4VP] Sections 7.2.1, 7.3
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet contains the credentials { "name": "Arthur Dent", "address": { "street_address": "42 Market Street", "locality": "Milliways", "postal_code": "12345" }, "degrees": [ { "type": "Bachelor of Science", "university": "University of Betelgeuse" }, { "type": "Master of Science", "university": "University of Betelgeuse" } ], "nationalities": ["British", "Betelgeusian"] }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer where a string element is applied to a value that is NOT a JSON object (e.g. claims path pointer: ["name", "firstname"] where name is a string).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet evaluates the claims path pointer against the matching JSON-based Credential.
- Wallet detects that the currently selected element is not an object when the string path element is applied.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet evaluates the path pointer.
- Wallet aborts processing and returns an error (e.g. invalid_request); presentation flow is not initiated.
WS_RP_SH_Encoding_TextualEncoding008
Objective
Test the following condition when processing claims path pointer array is at step 2.1: if the key does not exist in element currently selected, remove that element from the selection.
References
- [OpenID4VP] Sections 7.2.1, 7.3
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "name": "Arthur Dent", "address": { "street_address": "42 Market Street", "locality": "Milliways", "postal_code": "12345" }, "degrees": [ { "type": "Bachelor of Science", "university": "University of Betelgeuse" }, { "university": "University of Betelgeuse" } ], "nationalities": ["British", "Betelgeusian"] }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer where a string component targets a key that is absent from one or more currently selected element(s) (e.g. claims path pointer: ["degrees", null, "type"] where one entry of degrees has no type field).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet evaluates the claims path pointer against the matching JSON-based Credential.
- Wallet identifies element(s) where the targeted key is absent and removes them from the selection.
- Wallet generates and returns the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet evaluates the path pointer.
- Wallet removes element(s) lacking the targeted key from the selection without aborting (e.g. a degrees entry without a type field is dropped, while "Bachelor of Science" is retained).
- Wallet returns an Authorization Response containing only the retained selected values; presentation flow proceeds.
WS_RP_SH_Encoding_TextualEncoding009
Objective
Test that at step 2.2 of claims path processing if any of the currently selected element(s) is not an array, abort processing and return an error.
References
- [OpenID4VP] Sections 7, 7.2.1, 7.3
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "name": "Arthur Dent", "address": { "street_address": "42 Market Street", "locality": "Milliways", "postal_code": "12345" }, "degrees": [ { "type": "Bachelor of Science", "university": "University of Betelgeuse" }, { "type": "Master of Science", "university": "University of Betelgeuse" } ], "nationalities": ["British", "Betelgeusian"] }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer where a null component is applied to a currently selected element that is NOT an array (e.g. claims path pointer: ["address", null, "street_address"] where address is a JSON object rather than an array).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet evaluates the claims path pointer against the matching JSON-based Credential.
- Wallet detects that the currently selected element is not an array when the null component is applied.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet evaluates the path pointer.
- Wallet aborts processing and returns an error (e.g. invalid_request) due to the null component being applied to a non-array element; presentation flow is not initiated.
WS_RP_SH_Encoding_TextualEncoding010
Objective
Test that at step 2.3 of claims path processing If any of the currently selected element(s) is not an array, abort processing and return an error.
References
- [OpenID4VP] Sections 7, 7.2.1, 7.3
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "name": "Arthur Dent", "address": { "street_address": { "house_no": "54a"} }, "degrees": [ { "type": "Bachelor of Science", "university": "University of Betelgeuse" }, { "type": "Master of Science", "university": "University of Betelgeuse" } ], "nationalities": ["British", "Betelgeusian"] }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer where a non-negative integer component is applied to a currently selected element that is NOT an array (e.g. claims path pointer: ["address", "house_no", null] where house_no is a string).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet evaluates the claims path pointer against the matching JSON-based Credential.
- Wallet detects that the currently selected element is not an array when the integer component is applied.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet evaluates the path pointer.
- Wallet aborts processing and returns an error (e.g. invalid_request) due to the integer component being applied to a non-array element; presentation flow is not initiated.
WS_RP_SH_Encoding_TextualEncoding011
Objective
Test that at step 2.3 of claims path processing, if the index does not exist in a selected array, remove that array from the selection.
References
- [OpenID4VP] Sections 7, 7.2.1, 7.3
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "degrees": [ ["Bachelor of Science"], ["Master of Science", "Ph.D."] ] }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer where a non-negative integer index is applied to selected array(s), and the index is out of range for at least one of those arrays (e.g. path: ["degrees", null, 1] where some degrees entries have only one element).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet evaluates the claims path pointer against the matching JSON-based Credential.
- Wallet identifies array(s) where the requested index is out of range and removes them from the selection.
- Wallet generates and returns the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet evaluates the path pointer.
- Wallet removes array(s) lacking an element at the requested index from the selection without aborting (e.g. a ["Bachelor of Science"] entry is dropped because index 1 is out of range, while ["Master of Science", "Ph.D."] retains index 1 = "Ph.D.").
- Wallet returns an Authorization Response containing only the retained selected values; presentation flow proceeds.
WS_RP_SH_Encoding_TextualEncoding012
Objective
Test that at step 2.4 of claims path processing if the component is anything else, the wallet should abort processing and return an error.
References
- [OpenID4VP] Sections 7, 7.2.1, 7.3
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "address": { "street": { "road": { "house": "blue" } } } }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer with a component of an unsupported type (e.g. path: ["address", "street", false]).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet validates the structure of the claims path pointer.
- Wallet detects a component of an unsupported type.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet validates the path pointer structure.
- Wallet aborts processing and returns an error (e.g. invalid_request) due to an unsupported component type in the claims path pointer; presentation flow is not initiated.
WS_RP_SH_Encoding_TextualEncoding013
Objective
Test that at Step 3 of claims path processing, if the set of elements currently selected is empty, abort processing and return an error.
References
- [OpenID4VP] Sections 7, 7.2.1, 7.3
Profile applicability
claims path pointer when applied to a JSON-based Credential
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "address": { "street": { "road": { "house": "blue" } } } }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query whose claims path pointer resolves to an empty set against the matching Credential (e.g. claims path pointer: ["address", "postal_code"] where the Credential has no postal_code field under address).
- Wallet parses the Authorization Request and the DCQL query.
- Wallet evaluates the claims path pointer against the matching JSON-based Credential.
- Wallet observes that the resulting set of selected JSON elements is empty.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet evaluates the path pointer.
- Wallet aborts processing and returns an error (e.g. invalid_request) because the set of selected JSON elements is empty; presentation flow is not initiated.
WS_RP_SH_Encoding_TextualEncoding014
Objective
Verify that when the Wallet receives a DCQL query with a claims path pointer applied to an ISO mdoc Credential, where the path is a two-element array containing a valid namespace and a valid data element identifier, the Wallet selects the corresponding data element and returns it CBOR-encoded in the Authorization Response.
References
- [OpenID4VP] Sections 7, 7.2, 7.4
Profile applicability
claims path pointer when applied to a credential in ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet has an ISO mdoc credential with data element specified in verifier request
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer path: ["org.iso.18013.5.1", "first_name"] applied to an ISO mdoc Credential.
- Wallet parses the Authorization Request and the DCQL query.
- Wallet evaluates the claims path pointer: locates the namespace, then the data element identifier within it.
- Wallet selects the matching data element value and CBOR-encodes it.
- Wallet generates and returns the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet correctly resolves the namespace and the data element identifier within it.
- Wallet selects the data element value (e.g. "Alice" for first_name) and CBOR-encodes it.
- Wallet returns an Authorization Response containing the selected first_name value CBOR-encoded; presentation flow proceeds.
WS_RP_SH_Encoding_TextualEncoding015
Objective
Test that the first element of mdoc claims path pointer refers to a namespace.
References
- [OpenID4VP] Sections 7, 7.2, 7.4
Profile applicability
claims path pointer when applied to a credential in ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
The wallet has an ISO mdoc credential with data element specified in verifier request
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer path: ["org.iso.18013.5.1", "first_name"].
- Wallet parses the Authorization Request and the DCQL query.
- Wallet interprets the first element of the path as a namespace and looks it up in the mdoc Credential.
- Wallet selects the data element identified by the second element within that namespace.
- Wallet generates and returns the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet correctly resolves org.iso.18013.5.1 as the namespace.
- Wallet selects the first_name data element and CBOR-encodes its value (e.g. "Alice").
- Wallet returns an Authorization Response containing the first_name value CBOR-encoded; presentation flow proceeds.
WS_RP_SH_Encoding_TextualEncoding016
Objective
Verify that if the first element of the path does not match any namespace in the mdoc, the Wallet aborts and returns an error.
References
- [OpenID4VP] Sections 7, 7.2.1 step 2, 7.4
Profile applicability
claims path pointer when applied to a credential in ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "org.iso.18013.5.1": { "first_name": "Alice" } }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer path: ["org.iso.18013.5.1", "first_name"] whose first element does NOT match any namespace in the Credential.
- Wallet parses the Authorization Request and the DCQL query.
- Wallet attempts to locate the namespace identified by the first element in the mdoc Credential.
- Wallet detects that no matching namespace exists.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet attempts to resolve the namespace.
- Wallet aborts processing and returns an error (e.g. invalid_request) due to the namespace not being present in the mdoc Credential; presentation flow is not initiated.
WS_RP_SH_Encoding_TextualEncoding017
Objective
Test that the second element of mdoc claims path pointer refers to a data element identifier.
References
- [OpenID4VP] Section 7
Profile applicability
claims path pointer when applied to a credential in ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "org.iso.18013.5.1": { "first_name": "Alice" } }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer path: ["org.iso.18013.5.1", "first_name"].
- Wallet parses the Authorization Request and the DCQL query.
- Wallet resolves the namespace from the first element.
- Wallet looks up the data element identifier (second element) within that namespace and selects its value.6. Wallet generates and returns the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses the Authorization Request and the DCQL query.
- Wallet correctly resolves the namespace.
- Wallet correctly resolves the first_name data element identifier and selects its value (e.g. "Alice").
- Wallet returns an Authorization Response containing the value "Alice" CBOR-encoded; presentation flow proceeds.
WS_RP_SH_Encoding_TextualEncoding018
Objective
Test that the claims path pointer does not contain exactly two components then abort processing and return an error.
References
- [OpenID4VP] Section 7
Profile applicability
claims path pointer when applied to a credential in ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer with a wrong number of components for an mdoc (e.g. path: ["org.iso.18013.5.1"]).
- Wallet parses the Authorization Request and validates the structure of the claims path pointer.
- Wallet detects the wrong number of components.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses and validates the path pointer structure.
- Wallet aborts processing and returns an error (e.g. invalid_request) due to the path not containing exactly two components; presentation flow is not initiated.
WS_RP_SH_Encoding_TextualEncoding019
Objective
Test that the claims path pointer is not a string then abort processing and return an error.
References
- [OpenID4VP] Section 7
Profile applicability
claims path pointer when applied to a credential in ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer where a component is not a string (e.g. path: ["org.iso.18013.5.1", 123]).
- Wallet parses the Authorization Request and validates the structure of the claims path pointer.
- Wallet detects a non-string component.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully parses and validates the path pointer structure.
- Wallet aborts processing and returns an error (e.g. invalid_request) due to a non-string component in the mdoc claims path pointer; presentation flow is not initiated.
WS_RP_SH_Encoding_TextualEncoding020
Objective
Test claims path pointer processing by selecting the data element referenced by the second component. If the data element does not exist in the Credential it MUST abort processing and return an error.
References
- [OpenID4VP] Section 7
Profile applicability
claims path pointer when applied to a credential in ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "org.iso.18013.5.1": { "first_name": "Alice" } }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer where the second component does not exist within the resolved namespace (e.g. path: ["org.iso.18013.5.1", "Bob"]).
- Wallet parses the Authorization Request, resolves the namespace, and looks up the data element identifier within it.
- Wallet detects that the data element is not present.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully resolves the namespace.
- Wallet aborts processing and returns an error (e.g. invalid_request) because the data element identifier is not present in the namespace; presentation flow is not initiated.
WS_RP_SH_Encoding_TextualEncoding021
Objective
Verify that the wallet can successfully select the data element references by the second component of a claims path pointer.
References
- [OpenID4VP] Section 7
Profile applicability
claims path pointer when applied to a credential in ISO mdoc
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
{ "org.iso.18013.5.1": { "first_name": "Alice" } }
Test Scenario
- Engage wallet-verifier interaction.
- Verifier sends an Authorization Request with a DCQL query containing a claims path pointer path: ["org.iso.18013.5.1", "first_name"].
- Wallet parses the Authorization Request, resolves the namespace, and selects the data element value within it.
- Wallet CBOR-encodes the value and returns it in the Authorization Response.
Expected results
- Wallet-verifier interaction is successfully initiated.
- Wallet successfully receives the Authorization Request.
- Wallet successfully selects the first_name data element value ("Alice").
- Wallet returns an Authorization Response containing "Alice" CBOR-encoded; presentation flow proceeds.
WS_RP_SH_Encoding_TextualEncoding022
Objective
Test that when the wallet sends the authorization response using HTTP POST, the names and values in the body MUST be encoded using UTF-8
References
- [OpenID4VP] Section 8
Profile applicability
none
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
Wallet has a credential containing non-ASCII characters
Test Scenario
- The wallet engages with the verifier.
- The verifier sends an Authorization request to the wallet, with response mode=direct_post.jwt, requesting the non_ASCII credential
- Wallet processes request
- Test the HTTP POST body sent by wallet
Expected results
- Wallet-verifier interaction is successfully initiated
- Wallet receives request
- Wallet processes request and performs HTTP POST to the response_uri.
- All special characters (e.g. in names or values) are correctly encoded using UTF-8 bytes.
Use Cases
Use Cases - Presentation
WS_RP_UC_Presentation_003
Objective
Verify that a Wallet supporting OAuth 2.0 scope-based Presentation requests processes an Authorization Request using a valid pre-defined scope value, by presenting a credential of the type the scope value identifies.
References
- [OpenID4VP] Section 5.5
Profile applicability
Wallet supports OAuth 2.0
EUDI-wallet relevancy
EUDI_generic | EUDI_forbidden
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction (e.g. click link / scan QR code).
- Wallet receives an Authorization Request using a valid pre-defined scope value as defined by the applicable profile.
- The Wallet returns a response to the Verifier.
Expected results
- Wallet-verifier interaction is successfully initiated.
- The Wallet successfully processes the Authorization Request.
- The Wallet returns an Authorization Response containing a credential whose type matches the type identified by the scope value per the applicable profile.
WS_RP_UC_Presentation_004
Objective
Verify that when an Authorization Request is rendered on Device A using the invocation mechanism mandated by the applicable profile (e.g. a custom URL scheme, universal link, or QR code encoding such a URI), the Wallet on Device B is able to receive and process the request.
References
- [OpenID4VP] Section 5.7
Profile applicability
Wallet supports DC API cross-device flow (Appendix A); HAIP/ETSI profile defines cross-device requirements
EUDI-wallet relevancy
EUDI_generic | EUDI_required
Preconditions
none
Test Scenario
- Engage wallet-verifier interaction on Device A (Verifier device), which renders the Authorization Request using the invocation mechanism mandated by the applicable profile.
- User transfers the Authorization Request from Device A to Device B (Wallet device) using the rendered invocation mechanism.
- Wallet on Device B receives the Authorization Request via its registered handler for the mandated scheme.
- Wallet parses and validates the Authorization Request.
- Wallet performs the presentation flow on Device B.
Expected results
- Authorization Request is successfully rendered on Device A using the profile-mandated mechanism.
- The request is successfully transferred to Device B.
- Wallet on Device B successfully receives the Authorization Request via its registered handler.
- Wallet successfully parses and validates the Authorization Request.
- Wallet completes the presentation flow on Device B and returns the Authorization Response to the Verifier.