Relying Party - Wallet Solution test cases

Interaction

Interaction - Main Interaction

RP_WS_IA_MainInteraction_001a

Objective

Verify that the Relying Party accepts a valid presentation of a PID in SD-JWT VC format and releases exactly the requested attributes.

References

• [ARF] Annex 2, OIA_03c, OIA_08a, OIA_12
• [HAIP] section 5, 6.1
• [OpenID4VP] section 8.6
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid.

Comments

This test case is the positive control for the unhappy-flow test cases of the Relying Party SUT that present a credential in SD-JWT VC format. When it fails, those test cases cannot produce a meaningful verdict in the same environment.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_IA_MainInteraction_001b

Objective

Verify that the Relying Party accepts a valid presentation of a PID in mdoc format and releases exactly the requested attributes.

References

• [ARF] Annex 2, OIA_03b, OIA_08, OIA_12
• [HAIP] section 5, 5.3.1
• [OpenID4VP] section 8.6
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid.

Comments

This test case is the positive control for the unhappy-flow test cases of the Relying Party SUT that present a credential in mdoc format. When it fails, those test cases cannot produce a meaningful verdict in the same environment.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

Security Mechanisms

Security Mechanisms - Revocation

RP_WS_SM_Revocation_001a

Objective

Verify that the Relying Party accepts a PID in SD-JWT VC format whose revocation status is VALID.

References

• [Token Status List] section 6.2, 7.1, 8.3
• [SD-JWT VC] section 2.4
• [HAIP] section 6.1
• [ARF] Annex 2, VCR_11a, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the status list referenced by the credential holds the value 0x00 (VALID) at the credential's index.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid. The Test Status Provider has logged a request from the Relying Party for the status list referenced by the credential.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_001b

Objective

Verify that the Relying Party accepts a PID in mdoc format whose revocation status is VALID.

References

• [Token Status List] section 6.3, 7.1, 8.3
• [ISO/IEC 18013-5 ed2]
• [HAIP] section 5.3.1
• [ARF] Annex 2, VCR_11, VCR_12, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the status list referenced by the credential holds the value 0x00 (VALID) at the credential's index.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid. The Test Status Provider has logged a request from the Relying Party for the status list referenced by the credential.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_002a_UF

Objective

Verify that the Relying Party rejects a revoked PID in SD-JWT VC format.

References

• [Token Status List] section 6.2, 7.1, 8.3
• [SD-JWT VC] section 2.4
• [HAIP] section 6.1
• [ARF] Annex 2, VCR_11a, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the status list referenced by the credential holds the value 0x01 (INVALID) at the credential's index.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The OIDF verifier test module oid4vp-1final-verifier-present-revoked-credential covers the same objective.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_002b_UF

Objective

Verify that the Relying Party rejects a revoked PID in mdoc format.

References

• [Token Status List] section 6.3, 7.1, 8.3
• [ISO/IEC 18013-5 ed2]
• [HAIP] section 5.3.1
• [ARF] Annex 2, VCR_11, VCR_12, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the status list referenced by the credential holds the value 0x01 (INVALID) at the credential's index.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The OIDF verifier test module oid4vp-1final-verifier-present-revoked-credential covers the same objective.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_003a_UF

Objective

Verify that the Relying Party rejects a suspended PID in SD-JWT VC format.

References

• [Token Status List] section 6.2, 7.1, 8.3
• [SD-JWT VC] section 2.4
• [HAIP] section 6.1
• [ARF] Annex 2, VCR_11a, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the status list referenced by the credential holds the value 0x02 (SUSPENDED) at the credential's index.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_003b_UF

Objective

Verify that the Relying Party rejects a suspended PID in mdoc format.

References

• [Token Status List] section 6.3, 7.1, 8.3
• [ISO/IEC 18013-5 ed2]
• [HAIP] section 5.3.1
• [ARF] Annex 2, VCR_11, VCR_12, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the status list referenced by the credential holds the value 0x02 (SUSPENDED) at the credential's index.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_004a_UF

Objective

Verify that the Relying Party does not treat an application-specific status value as VALID for a PID in SD-JWT VC format, unless it declared a meaning for that value.

References

• [Token Status List] section 6.2, 7.1, 8.3
• [SD-JWT VC] section 2.4
• [HAIP] section 6.1
• [ARF] Annex 2, VCR_11a, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_generic | EUDI_undefined

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the status list referenced by the credential holds the value 0x03 (application-specific) at the credential's index.

Expected results

1. If the Relying Party declares no meaning for the status value 0x03 in its ICS: the Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx. If it declares a meaning: it handles the presentation as declared.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_004b_UF

Objective

Verify that the Relying Party does not treat an application-specific status value as VALID for a PID in mdoc format, unless it declared a meaning for that value.

References

• [Token Status List] section 6.3, 7.1, 8.3
• [ISO/IEC 18013-5 ed2]
• [HAIP] section 5.3.1
• [ARF] Annex 2, VCR_11, VCR_12, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_generic | EUDI_undefined

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the status list referenced by the credential holds the value 0x03 (application-specific) at the credential's index.

Expected results

1. If the Relying Party declares no meaning for the status value 0x03 in its ICS: the Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx. If it declares a meaning: it handles the presentation as declared.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_005a_UF

Objective

Verify that the Relying Party rejects a PID in SD-JWT VC format whose status reference is malformed.

References

• [Token Status List] section 6.2, 7.1, 8.3
• [SD-JWT VC] section 2.4
• [HAIP] section 6.1
• [ARF] Annex 2, VCR_11a, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that its status.status_list object has no idx member.
2. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that its status.status_list object has no uri member.
3. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the idx member of its status.status_list object is -1.
4. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the idx member of its status.status_list object is the string 7 instead of a number.
5. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the uri member of its status.status_list object is the string not a uri.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
3. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
4. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
5. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

A Status List Token that cannot be used leaves no reliable revocation status. For PIDs the Relying Party SUT rejects the presentation in that case; for QEAA, PuB-EAA and non-qualified EAA the policy declared in the ICS applies (see [ARF] Annex 2, VCR_14).

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_005b_UF

Objective

Verify that the Relying Party rejects a PID in mdoc format whose status reference is malformed.

References

• [Token Status List] section 6.3, 7.1, 8.3
• [ISO/IEC 18013-5 ed2]
• [HAIP] section 5.3.1
• [ARF] Annex 2, VCR_11, VCR_12, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the status_list map in the status element of its MSO has no idx entry.
2. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the status_list map in the status element of its MSO has no uri entry.
3. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the idx entry of the status_list map in its MSO is -1.
4. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the idx entry of the status_list map in its MSO is the text string 7 instead of an unsigned integer.
5. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the uri entry of the status_list map in its MSO is the text string not a uri.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
3. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
4. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
5. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

A Status List Token that cannot be used leaves no reliable revocation status. For PIDs the Relying Party SUT rejects the presentation in that case; for QEAA, PuB-EAA and non-qualified EAA the policy declared in the ICS applies (see [ARF] Annex 2, VCR_14).

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_006a_UF

Objective

Verify that the Relying Party rejects a PID in SD-JWT VC format whose status index lies outside the status list.

References

• [Token Status List] section 6.2, 7.1, 8.3
• [SD-JWT VC] section 2.4
• [HAIP] section 6.1
• [ARF] Annex 2, VCR_11a, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the index in its status reference equals the number of entries in the referenced status list, one past the last valid index.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_006b_UF

Objective

Verify that the Relying Party rejects a PID in mdoc format whose status index lies outside the status list.

References

• [Token Status List] section 6.3, 7.1, 8.3
• [ISO/IEC 18013-5 ed2]
• [HAIP] section 5.3.1
• [ARF] Annex 2, VCR_11, VCR_12, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the index in its status reference equals the number of entries in the referenced status list, one past the last valid index.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_007a

Objective

Verify that the Relying Party accepts a PID in SD-JWT VC format without revocation information whose validity period is shorter than 24 hours.

References

• [Token Status List] section 6.2, 7.1, 8.3
• [SD-JWT VC] section 2.4
• [HAIP] section 6.1
• [ARF] Annex 2, VCR_11a, VCR_13
• [ARF] Annex 2, VCR_01, VCR_01b
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid_short in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid_short.

Comments

The OIDF verifier test module oid4vp-1final-verifier-present-credential-without-status covers the same objective.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_007b

Objective

Verify that the Relying Party accepts a PID in mdoc format without revocation information whose validity period is shorter than 24 hours.

References

• [Token Status List] section 6.3, 7.1, 8.3
• [ISO/IEC 18013-5 ed2]
• [HAIP] section 5.3.1
• [ARF] Annex 2, VCR_11, VCR_12, VCR_13
• [ARF] Annex 2, VCR_01, VCR_01b
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid_short in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid_short.

Comments

The OIDF verifier test module oid4vp-1final-verifier-present-credential-without-status covers the same objective.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_008a_UF

Objective

Verify that the Relying Party rejects a PID in SD-JWT VC format without revocation information whose validity period is longer than 24 hours.

References

• [Token Status List] section 6.2, 7.1, 8.3
• [SD-JWT VC] section 2.4
• [HAIP] section 6.1
• [ARF] Annex 2, VCR_11a, VCR_13
• [ARF] Annex 2, VCR_01, VCR_01b, VCR_14
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it carries no status claim.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

A PID valid for longer than 24 hours must carry revocation information ([ARF] Annex 2, VCR_01 and VCR_01b). Without it no reliable revocation status is available, and the Relying Party SUT rejects PIDs in that case.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_008b_UF

Objective

Verify that the Relying Party rejects a PID in mdoc format without revocation information whose validity period is longer than 24 hours.

References

• [Token Status List] section 6.3, 7.1, 8.3
• [ISO/IEC 18013-5 ed2]
• [HAIP] section 5.3.1
• [ARF] Annex 2, VCR_11, VCR_12, VCR_13
• [ARF] Annex 2, VCR_01, VCR_01b, VCR_14
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that its MSO carries no status element.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

A PID valid for longer than 24 hours must carry revocation information ([ARF] Annex 2, VCR_01 and VCR_01b). Without it no reliable revocation status is available, and the Relying Party SUT rejects PIDs in that case.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_009_UF

Objective

Verify that the Relying Party rejects a PID in mdoc format whose identifier is listed in the referenced identifier list.

References

• [Token Status List] section 6.3, 7.1, 8.3
• [ISO/IEC 18013-5 ed2]
• [HAIP] section 5.3.1
• [ARF] Annex 2, VCR_11, VCR_12, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.
• Identifier list in CWT format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.
5. The status element of the MSO of every presented credential carries an identifier_list entry (id, uri) that references an identifier list in CWT format (application/identifierlist+cwt) served by the Test Status Provider.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the referenced identifier list contains the credential's identifier.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The OIDF verifier test module oid4vp-1final-verifier-present-credential-on-identifier-list covers the same objective.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Revocation_010

Objective

Verify that the Relying Party accepts a PID in mdoc format whose identifier is not listed in the referenced identifier list.

References

• [Token Status List] section 6.3, 7.1, 8.3
• [ISO/IEC 18013-5 ed2]
• [HAIP] section 5.3.1
• [ARF] Annex 2, VCR_11, VCR_12, VCR_13
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.
• Identifier list in CWT format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.
5. The status element of the MSO of every presented credential carries an identifier_list entry (id, uri) that references an identifier list in CWT format (application/identifierlist+cwt) served by the Test Status Provider.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the referenced identifier list does not contain the credential's identifier.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid. The Test Status Provider has logged a request from the Relying Party for the identifier list.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

Security Mechanisms - Session Encryption

RP_WS_SM_SessionEncryption_001a

Objective

Verify that the Relying Party accepts an Authorization Response via redirects encrypted with ECDH-ES on P-256 and A128GCM.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [RFC7516] section 5.2
• [RFC7518] section 4.6, 5.3
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, encrypted as a JWE with alg ECDH-ES (P-256) and enc A128GCM to the encryption key from the client_metadata of the request.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_001b

Objective

Verify that the Relying Party accepts an Authorization Response via the W3C Digital Credentials API encrypted with ECDH-ES on P-256 and A128GCM.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [RFC7516] section 5.2
• [RFC7518] section 4.6, 5.3
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, encrypted as a JWE with alg ECDH-ES (P-256) and enc A128GCM to the encryption key from the client_metadata of the request.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_002a

Objective

Verify that the Relying Party accepts an Authorization Response via redirects encrypted with ECDH-ES on P-256 and A256GCM.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [RFC7516] section 5.2
• [RFC7518] section 4.6, 5.3
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, encrypted as a JWE with alg ECDH-ES (P-256) and enc A256GCM to the encryption key from the client_metadata of the request.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_002b

Objective

Verify that the Relying Party accepts an Authorization Response via the W3C Digital Credentials API encrypted with ECDH-ES on P-256 and A256GCM.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [RFC7516] section 5.2
• [RFC7518] section 4.6, 5.3
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, encrypted as a JWE with alg ECDH-ES (P-256) and enc A256GCM to the encryption key from the client_metadata of the request.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_003_UF

Objective

Verify that the Relying Party rejects an unencrypted Authorization Response when it requested response mode direct_post.jwt.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that it is not encrypted: the Conformance Wallet posts vp_token and state as form parameters to the response_uri, as in response mode direct_post.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_004a_UF

Objective

Verify that the Relying Party rejects an Authorization Response via redirects encrypted to a key it did not issue.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that it is encrypted to a newly generated P-256 key that the Relying Party did not issue, while the JWE header carries the kid of the Relying Party's encryption key.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_004b_UF

Objective

Verify that the Relying Party rejects an Authorization Response via the W3C Digital Credentials API encrypted to a key it did not issue.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that it is encrypted to a newly generated P-256 key that the Relying Party did not issue, while the JWE header carries the kid of the Relying Party's encryption key.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_005a_UF

Objective

Verify that the Relying Party rejects an Authorization Response via redirects encrypted to the ephemeral key of another transaction.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Start a presentation for default_query_pid via redirects (transaction T1) and record the encryption key from the client_metadata of its request. Send no response for T1.
2. Perform a presentation for default_query_pid via redirects (transaction T2) in which the Conformance Wallet encrypts an otherwise valid Authorization Response for T2 to the encryption key recorded for T1, with the kid of that key.

Expected results

1. The request of T1 carries an encryption key in its client_metadata.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_005b_UF

Objective

Verify that the Relying Party rejects an Authorization Response via the W3C Digital Credentials API encrypted to the ephemeral key of another transaction.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Start a presentation for default_query_pid via the W3C Digital Credentials API (transaction T1) and record the encryption key from the client_metadata of its request. Send no response for T1.
2. Perform a presentation for default_query_pid via the W3C Digital Credentials API (transaction T2) in which the Conformance Wallet encrypts an otherwise valid Authorization Response for T2 to the encryption key recorded for T1, with the kid of that key.

Expected results

1. The request of T1 carries an encryption key in its client_metadata.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_006a_UF

Objective

Verify that the Relying Party rejects an Authorization Response via redirects encrypted with a key management algorithm other than ECDH-ES.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [RFC7518] section 4.6
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that its JWE uses alg ECDH-ES+A128KW with the Relying Party's encryption key.
2. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that its JWE uses alg ECDH-ES+A256KW with the Relying Party's encryption key.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_006b_UF

Objective

Verify that the Relying Party rejects an Authorization Response via the W3C Digital Credentials API encrypted with a key management algorithm other than ECDH-ES.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [RFC7518] section 4.6
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that its JWE uses alg ECDH-ES+A128KW with the Relying Party's encryption key.
2. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that its JWE uses alg ECDH-ES+A256KW with the Relying Party's encryption key.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_007a_UF

Objective

Verify that the Relying Party rejects an Authorization Response via redirects encrypted with a content encryption algorithm it did not list.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [RFC7518] section 5.2
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that its JWE uses enc A128CBC-HS256.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_007b_UF

Objective

Verify that the Relying Party rejects an Authorization Response via the W3C Digital Credentials API encrypted with a content encryption algorithm it did not list.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [RFC7518] section 5.2
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that its JWE uses enc A128CBC-HS256.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_008a_UF

Objective

Verify that the Relying Party rejects an Authorization Response via redirects whose JWE was modified.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [RFC7516] section 5.2
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that one bit of its JWE ciphertext is flipped.
2. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that one bit of its JWE authentication tag is flipped.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_008b_UF

Objective

Verify that the Relying Party rejects an Authorization Response via the W3C Digital Credentials API whose JWE was modified.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [RFC7516] section 5.2
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that one bit of its JWE ciphertext is flipped.
2. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that one bit of its JWE authentication tag is flipped.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_009a_UF

Objective

Verify that the Relying Party rejects an Authorization Response via redirects whose ephemeral public key is not a valid P-256 point.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [RFC7518] section 4.6
• [RFC8725] section 3.4
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that the epk header of its JWE holds coordinates that are not a point on P-256.
2. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that the epk header of its JWE holds a key on curve P-384.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_009b_UF

Objective

Verify that the Relying Party rejects an Authorization Response via the W3C Digital Credentials API whose ephemeral public key is not a valid P-256 point.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [RFC7518] section 4.6
• [RFC8725] section 3.4
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that the epk header of its JWE holds coordinates that are not a point on P-256.
2. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that the epk header of its JWE holds a key on curve P-384.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_010a_UF

Objective

Verify that the Relying Party rejects an Authorization Response via redirects that is signed or unsecured instead of encrypted.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [RFC8725] section 3.1
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that the response parameter is a JWS signed with a key of the Conformance Wallet instead of a JWE.
2. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that the response parameter is an unsecured JWT with alg none instead of a JWE.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_010b_UF

Objective

Verify that the Relying Party rejects an Authorization Response via the W3C Digital Credentials API that is signed or unsecured instead of encrypted.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [RFC8725] section 3.1
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that the response member of the returned data object is a JWS signed with a key of the Conformance Wallet instead of a JWE.
2. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that the response member of the returned data object is an unsecured JWT with alg none instead of a JWE.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_011_UF

Objective

Verify that the Relying Party rejects an unencrypted Authorization Response via the W3C Digital Credentials API.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in an Authorization Response that is valid except that it is not encrypted: the data object returned through the Digital Credentials API carries the vp_token directly instead of an encrypted response.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_012a

Objective

Verify that the Relying Party ignores unrecognised members in a decrypted Authorization Response via redirects.

References

• [HAIP] section 5, 5.1
• [OpenID4VP] section 8.3, 8.3.1
• [OpenID4VP] section 8.1
• [ARF] Annex 2, OIA_03b, OIA_03c
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via redirects.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via redirects with response mode direct_post.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via redirects in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response whose decrypted payload additionally contains the member foo with the value bar.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

RP_WS_SM_SessionEncryption_012b

Objective

Verify that the Relying Party ignores unrecognised members in a decrypted Authorization Response via the W3C Digital Credentials API.

References

• [HAIP] section 5, 5.2
• [OpenID4VP] section 8.3, A.4
• [OpenID4VP] section 8.1
• [ARF] Annex 2, OIA_08, OIA_08a
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party supports presentations via the W3C Digital Credentials API.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation via the W3C Digital Credentials API with response mode dc_api.jwt.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a or RP_WS_IA_MainInteraction_001b passed in the same environment for the presentation flow of this test case.

Test Scenario

1. Perform a presentation for default_query_pid via the W3C Digital Credentials API in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response whose decrypted payload additionally contains the member foo with the value bar.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid.

Comments

The credential format does not affect this test case; use default_credential_pid in a format the Relying Party requests.

Security Mechanisms - Trust Mechanisms

RP_WS_SM_TrustMechanisms_001a

Objective

Verify that the Relying Party accepts a PID in SD-JWT VC format signed under a PID/Issuance anchor of the PID Provider list.

References

• [ARF] Annex 2, OIA_12, PPNot_05
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_001b

Objective

Verify that the Relying Party accepts a PID in mdoc format signed under a PID/Issuance anchor of the PID Provider list.

References

• [ARF] Annex 2, OIA_12, PPNot_05
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of default_credential_pid.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_002a_UF

Objective

Verify that the Relying Party rejects a PID in SD-JWT VC format signed by a QTSP whose anchor appears only in a Trusted List.

References

• [ARF] Annex 2, OIA_12, OIA_15
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]
• [ETSI TS 119 612]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by QP-A.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_002b_UF

Objective

Verify that the Relying Party rejects a PID in mdoc format signed by a QTSP whose anchor appears only in a Trusted List.

References

• [ARF] Annex 2, OIA_12, OIA_15
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]
• [ETSI TS 119 612]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by QP-A.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_003a_UF

Objective

Verify that the Relying Party rejects a PID in SD-JWT VC format signed under an anchor of a list other than the PID Provider list.

References

• [ARF] Annex 2, OIA_12, OIA_15
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by the Wallet Provider WP-A from TL-WP.
2. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by AC-A from TL-AC.
3. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by the PuB-EAA Provider PB-A from TL-PUB.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
3. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_003b_UF

Objective

Verify that the Relying Party rejects a PID in mdoc format signed under an anchor of a list other than the PID Provider list.

References

• [ARF] Annex 2, OIA_12, OIA_15
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by the Wallet Provider WP-A from TL-WP.
2. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by AC-A from TL-AC.
3. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by the PuB-EAA Provider PB-A from TL-PUB.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
3. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_004a_UF

Objective

Verify that the Relying Party rejects a PID in SD-JWT VC format signed under an anchor published only for the revocation service of a PID Provider.

References

• [ARF] Annex 2, OIA_12, PPNot_05
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is signed by a certificate under the revocation anchor CA-PP-A-REV of PP-A.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_004b_UF

Objective

Verify that the Relying Party rejects a PID in mdoc format signed under an anchor published only for the revocation service of a PID Provider.

References

• [ARF] Annex 2, OIA_12, PPNot_05
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is signed by a certificate under the revocation anchor CA-PP-A-REV of PP-A.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_005a_UF

Objective

Verify that the Relying Party rejects a PID in SD-JWT VC format from an issuer that is on no trust list.

References

• [ARF] Annex 2, OIA_12
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by CA-X.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_005b_UF

Objective

Verify that the Relying Party rejects a PID in mdoc format from an issuer that is on no trust list.

References

• [ARF] Annex 2, OIA_12
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by CA-X.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_006a_UF

Objective

Verify that the Relying Party rejects a PID in SD-JWT VC format from a PID Provider whose PID/Issuance service is withdrawn.

References

• [ARF] Annex 2, OIA_12, OIA_15a
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-W, whose PID/Issuance service is withdrawn.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

[ETSI TS 119 602] Annex D gives PID Providers lists no service status. TL-PID therefore expresses the withdrawal by listing only the PID/Revocation service of PP-W. Its anchor CA-PP-W is the one the PID is signed under.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_006b_UF

Objective

Verify that the Relying Party rejects a PID in mdoc format from a PID Provider whose PID/Issuance service is withdrawn.

References

• [ARF] Annex 2, OIA_12, OIA_15a
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-W, whose PID/Issuance service is withdrawn.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

[ETSI TS 119 602] Annex D gives PID Providers lists no service status. TL-PID therefore expresses the withdrawal by listing only the PID/Revocation service of PP-W. Its anchor CA-PP-W is the one the PID is signed under.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_007a_UF

Objective

Verify that the Relying Party stops accepting PIDs in SD-JWT VC format from a PID Provider once its entry is removed from the PID Provider list.

References

• [ARF] Annex 2, OIA_15a
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-D.
2. The Test Trust Infrastructure publishes a new version of TL-PID without the entry of PP-D. Wait until the Relying Party has retrieved it, at most T_refresh.
3. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-D.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of the presented credential.
2. The Test Trust Infrastructure logs a retrieval of the new version of TL-PID by the Relying Party.
3. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Restore the previous version of TL-PID after the test case.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_007b_UF

Objective

Verify that the Relying Party stops accepting PIDs in mdoc format from a PID Provider once its entry is removed from the PID Provider list.

References

• [ARF] Annex 2, OIA_15a
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-D.
2. The Test Trust Infrastructure publishes a new version of TL-PID without the entry of PP-D. Wait until the Relying Party has retrieved it, at most T_refresh.
3. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-D.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of the presented credential.
2. The Test Trust Infrastructure logs a retrieval of the new version of TL-PID by the Relying Party.
3. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Restore the previous version of TL-PID after the test case.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_008a

Objective

Verify that the Relying Party starts accepting PIDs in SD-JWT VC format from a PID Provider once its entry is added to the PID Provider list.

References

• [ARF] Annex 2, OIA_15a
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-C.
2. The Test Trust Infrastructure publishes a new version of TL-PID that adds an entry for PP-C with a granted PID/Issuance and PID/Revocation service. Wait until the Relying Party has retrieved it, at most T_refresh.
3. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-C.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Test Trust Infrastructure logs a retrieval of the new version of TL-PID by the Relying Party.
3. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of the presented credential.

Comments

Restore the previous version of TL-PID after the test case.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_008b

Objective

Verify that the Relying Party starts accepting PIDs in mdoc format from a PID Provider once its entry is added to the PID Provider list.

References

• [ARF] Annex 2, OIA_15a
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-C.
2. The Test Trust Infrastructure publishes a new version of TL-PID that adds an entry for PP-C with a granted PID/Issuance and PID/Revocation service. Wait until the Relying Party has retrieved it, at most T_refresh.
3. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-C.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Test Trust Infrastructure logs a retrieval of the new version of TL-PID by the Relying Party.
3. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of the presented credential.

Comments

Restore the previous version of TL-PID after the test case.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_009a_UF

Objective

Verify that the Relying Party rejects a PID in SD-JWT VC format signed under an expired trust anchor.

References

• [ARF] Annex 2, OIA_15a
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-E, whose PID/Issuance anchor certificate has expired.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_009b_UF

Objective

Verify that the Relying Party rejects a PID in mdoc format signed under an expired trust anchor.

References

• [ARF] Annex 2, OIA_15a
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-E, whose PID/Issuance anchor certificate has expired.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_010a

Objective

Verify that the Relying Party accepts a QEAA in SD-JWT VC format signed under the root of trust defined for QEAAs.

References

• [ARF] Annex 2, OIA_13, OIA_15b
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 612]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party requests QEAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_qeaa in which the Conformance Wallet presents default_credential_qeaa in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_qeaa, with the values of default_credential_qeaa.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_010b

Objective

Verify that the Relying Party accepts a QEAA in mdoc format signed under the root of trust defined for QEAAs.

References

• [ARF] Annex 2, OIA_13, OIA_15b
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 612]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party requests QEAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_qeaa in which the Conformance Wallet presents default_credential_qeaa in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_qeaa, with the values of default_credential_qeaa.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_011a_UF

Objective

Verify that the Relying Party does not accept an attestation in SD-JWT VC format as QEAA when its issuer has no granted qualified service.

References

• [ARF] Annex 2, OIA_13, OIA_15b
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 612]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party requests QEAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_qeaa in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_qeaa that differs from it only in that it is issued by QP-N, whose service is not qualified.
2. Perform a presentation for default_query_qeaa in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_qeaa that differs from it only in that it is issued by QP-W, whose qualified service is withdrawn.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_011b_UF

Objective

Verify that the Relying Party does not accept an attestation in mdoc format as QEAA when its issuer has no granted qualified service.

References

• [ARF] Annex 2, OIA_13, OIA_15b
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 612]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party requests QEAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_qeaa in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_qeaa that differs from it only in that it is issued by QP-N, whose service is not qualified.
2. Perform a presentation for default_query_qeaa in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_qeaa that differs from it only in that it is issued by QP-W, whose qualified service is withdrawn.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.
2. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_012a

Objective

Verify that the Relying Party accepts a PuB-EAA in SD-JWT VC format signed under the root of trust defined for PuB-EAAs.

References

• [ARF] Annex 2, OIA_14, PuBPNot_06
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party requests PuB-EAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pubeaa in which the Conformance Wallet presents default_credential_pubeaa in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pubeaa, with the values of default_credential_pubeaa.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_012b

Objective

Verify that the Relying Party accepts a PuB-EAA in mdoc format signed under the root of trust defined for PuB-EAAs.

References

• [ARF] Annex 2, OIA_14, PuBPNot_06
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party requests PuB-EAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pubeaa in which the Conformance Wallet presents default_credential_pubeaa in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pubeaa, with the values of default_credential_pubeaa.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_013a_UF

Objective

Verify that the Relying Party rejects a PuB-EAA in SD-JWT VC format signed under a PID Provider anchor.

References

• [ARF] Annex 2, OIA_14, OIA_15
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party requests PuB-EAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pubeaa in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pubeaa that differs from it only in that it is issued by PP-A.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_013b_UF

Objective

Verify that the Relying Party rejects a PuB-EAA in mdoc format signed under a PID Provider anchor.

References

• [ARF] Annex 2, OIA_14, OIA_15
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party requests PuB-EAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pubeaa in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pubeaa that differs from it only in that it is issued by PP-A.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_014a

Objective

Verify that the Relying Party accepts a non-qualified EAA in SD-JWT VC format signed under the root of trust defined for non-qualified EAAs.

References

• [ARF] Annex 2, OIA_15
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party requests non-qualified EAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_eaa in which the Conformance Wallet presents default_credential_eaa in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_eaa, with the values of default_credential_eaa.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_014b

Objective

Verify that the Relying Party accepts a non-qualified EAA in mdoc format signed under the root of trust defined for non-qualified EAAs.

References

• [ARF] Annex 2, OIA_15
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party requests non-qualified EAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_eaa in which the Conformance Wallet presents default_credential_eaa in a valid Authorization Response.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_eaa, with the values of default_credential_eaa.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_015a_UF

Objective

Verify that the Relying Party rejects a non-qualified EAA in SD-JWT VC format signed under an anchor that its rulebook does not define.

References

• [ARF] Annex 2, OIA_15
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party requests non-qualified EAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_eaa in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_eaa that differs from it only in that it is issued by PP-A.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_015b_UF

Objective

Verify that the Relying Party rejects a non-qualified EAA in mdoc format signed under an anchor that its rulebook does not define.

References

• [ARF] Annex 2, OIA_15
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [ETSI TS 119 602]

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party requests non-qualified EAAs.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_eaa in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_eaa that differs from it only in that it is issued by PP-A.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_016a_UF

Objective

Verify that the Relying Party enforces the trusted_authorities of its own request and rejects a PID in SD-JWT VC format from another trusted PID Provider.

References

• [OpenID4VP] section 6.1.1.1, 14.9
• [HAIP] section 5
• [SD-JWT VC] section 2.5
• [HAIP] section 6.1.1
• [RFC5280] section 6.1
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party uses trusted_authorities in DCQL queries.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. The Relying Party is configured to restrict default_query_pid with a trusted_authorities entry of type aki that names only the PID/Issuance anchor of PP-A.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-B.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

[OpenID4VP] section 14.9 states that the Verifier must not rely on the Wallet to enforce the constraints of its request.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_TrustMechanisms_016b_UF

Objective

Verify that the Relying Party enforces the trusted_authorities of its own request and rejects a PID in mdoc format from another trusted PID Provider.

References

• [OpenID4VP] section 6.1.1.1, 14.9
• [HAIP] section 5
• [ISO/IEC 18013-5] section 9.3.1
• [RFC5280] section 6.1
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party uses trusted_authorities in DCQL queries.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. The Relying Party is configured to restrict default_query_pid with a trusted_authorities entry of type aki that names only the PID/Issuance anchor of PP-A.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that it is issued by PP-B.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

[OpenID4VP] section 14.9 states that the Verifier must not rely on the Wallet to enforce the constraints of its request.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

Security Mechanisms - Validity

RP_WS_SM_Validity_001_UF

Objective

Verify that the Relying Party rejects a credential in SD-JWT VC format whose expiration time has passed.

References

• [RFC7519] section 4.1.4
• [RFC9901] section 7.1
• [SD-JWT VC] section 2.4
• [OpenID4VP] section 8.6
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that its Issuer-signed JWT carries an exp claim set to the current time minus T_skew minus one hour.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Validity_002

Objective

Verify that the Relying Party accepts a credential in SD-JWT VC format whose expiration time has passed by less than the declared clock tolerance.

References

• [RFC7519] section 4.1.4
• [RFC9901] section 7.1
• [SD-JWT VC] section 2.4
• [OpenID4VP] section 8.6
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party applies a clock tolerance greater than zero.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that its Issuer-signed JWT carries an exp claim set to the current time minus half of T_skew.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of the presented credential.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Validity_003_UF

Objective

Verify that the Relying Party rejects a credential in SD-JWT VC format that is not yet valid.

References

• [RFC7519] section 4.1.5
• [RFC9901] section 7.1
• [SD-JWT VC] section 2.4
• [OpenID4VP] section 8.6
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that its Issuer-signed JWT carries an nbf claim set to the current time plus T_skew plus one hour.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Validity_005a_UF

Objective

Verify that the Relying Party rejects an expired credential in SD-JWT VC format whose revocation status is VALID, without retrieving its status list.

References

• [Token Status List] section 7.1, 8.3
• [ARF] Annex 2, VCR_13
• [RFC9901] section 7.1
• [SD-JWT VC] section 2.4
• [OpenID4VP] section 8.6
• [CIR 2024/2982 amended] Annex II
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.
5. The status list referenced by the presented credential holds the value 0x00 (VALID) at the credential's index.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that its Issuer-signed JWT carries an exp claim set to the current time minus T_skew minus one hour.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx. The Test Status Provider logs no request from the Relying Party for the status list referenced by the credential.

Comments

[Token Status List] section 8.3 requires the validation of the credential itself to precede any evaluation of its status, and states that status list procedures, such as fetching the Status List Token, must not be performed once the credential is found invalid, unless the use case requires further evaluation. Presenting a PID does not.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Validity_005b_UF

Objective

Verify that the Relying Party rejects an expired credential in mdoc format whose revocation status is VALID, without retrieving its status list.

References

• [Token Status List] section 7.1, 8.3
• [ARF] Annex 2, VCR_13
• [ISO/IEC 18013-5] section 9.3.1
• [OpenID4VP] section 8.6
• [HAIP] section 5.3.1
• [CIR 2024/2982 amended] Annex II
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.
5. The status list referenced by the presented credential holds the value 0x00 (VALID) at the credential's index.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the validUntil value in the validityInfo of its MSO is set to the current time minus T_skew minus one hour.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx. The Test Status Provider logs no request from the Relying Party for the status list referenced by the credential.

Comments

[Token Status List] section 8.3 requires the validation of the credential itself to precede any evaluation of its status, and states that status list procedures, such as fetching the Status List Token, must not be performed once the credential is found invalid, unless the use case requires further evaluation. Presenting a PID does not.

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Validity_006a_UF

Objective

Verify that the Relying Party does not retrieve the status list of a credential in SD-JWT VC format whose issuer signature is invalid.

References

• [Token Status List] section 8.3
• [RFC9901] section 7.1
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in IETF SD-JWT VC format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in IETF SD-JWT VC format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001a passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that one bit of the signature value of its Issuer-signed JWT is flipped.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx. The Test Status Provider logs no request from the Relying Party for the status list referenced by the credential.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Validity_006b_UF

Objective

Verify that the Relying Party does not retrieve the status list of a credential in mdoc format whose issuer signature is invalid.

References

• [Token Status List] section 8.3
• [ISO/IEC 18013-5] section 9.3.1
• [CIR 2024/2979 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.
• Relying Party checks the revocation status of PIDs.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.
4. Every credential presented in this test case references a status list URI from which the Relying Party has not retrieved a status list before.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that one bit of the signature value of its IssuerAuth structure is flipped.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx. The Test Status Provider logs no request from the Relying Party for the status list referenced by the credential.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Validity_010_UF

Objective

Verify that the Relying Party rejects a credential in mdoc format whose validity period has ended.

References

• [ISO/IEC 18013-5] section 9.3.1
• [OpenID4VP] section 8.6
• [HAIP] section 5.3.1
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the validUntil value in the validityInfo of its MSO is set to the current time minus T_skew minus one hour.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Validity_011_UF

Objective

Verify that the Relying Party rejects a credential in mdoc format whose validity period has not started.

References

• [ISO/IEC 18013-5] section 9.3.1
• [OpenID4VP] section 8.6
• [HAIP] section 5.3.1
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the validFrom value in the validityInfo of its MSO is set to the current time plus T_skew plus one hour.

Expected results

1. The Relying Party rejects the presentation: its verification result reports a failure and releases no attribute value from the presentation, and the endpoint receiving the Authorization Response does not answer with HTTP status 5xx.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).

RP_WS_SM_Validity_012

Objective

Verify that the Relying Party accepts a credential in mdoc format whose expected update time has passed while its validity period has not ended.

References

• [ISO/IEC 18013-5] section 9.1.2.4
• [ISO/IEC 18013-5] section 9.3.1
• [OpenID4VP] section 8.6
• [HAIP] section 5.3.1
• [CIR 2024/2982 amended] Annex II

Profile applicability

• Relying Party requests credentials in ISO/IEC 18013-5 mdoc format.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

• Presentation of a credential in ISO/IEC 18013-5 mdoc format.

Preconditions

1. The Relying Party is set to default_configuration_rp_1.
2. The test environment publishes default_trust_configuration_rp, and the Relying Party has loaded it.
3. Test case RP_WS_IA_MainInteraction_001b passed in the same environment.

Test Scenario

1. Perform a presentation for default_query_pid in which the Conformance Wallet presents, in an otherwise valid Authorization Response, a variant of default_credential_pid that differs from it only in that the expectedUpdate value in the validityInfo of its MSO lies one day in the past, while validUntil lies in the future.

Expected results

1. The Relying Party accepts the presentation: its verification result reports success and releases exactly the attributes requested in default_query_pid, with the values of the presented credential.

Comments

Execute this test case once for each presentation flow the Relying Party supports (redirects, W3C Digital Credentials API).