Skip to content

Relying Party - PID Provider test cases

Security Mechanisms

Security Mechanisms - Revocation

RP_PP_SM_Revocation_001a
Objective

Verify that the Relying Party evaluates a valid Status List Token in JWT format and accepts a PID whose status is VALID.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [HAIP] section 6.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token with typ statuslist+jwt, a sub claim equal to the credential's status uri, an iat claim, an exp claim in the future and a ttl claim, signed by a certificate under the revocation anchor of PP-A, that holds the value 0x00 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_PP_SM_Revocation_001b
Objective

Verify that the Relying Party evaluates a valid Status List Token in CWT format and accepts a PID whose status is VALID.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [HAIP] section 6.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token with the type header (16) application/statuslist+cwt, a subject (2) equal to the credential's status uri, an issued at claim (6), an expiration time (4) in the future and a time to live (65534), signed by a certificate under the revocation anchor of PP-A, that holds the value 0x00 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_PP_SM_Revocation_002a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format with an invalid signature.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that one bit of its signature value 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.
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_PP_SM_Revocation_002b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format with an invalid signature.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that one bit of its signature value 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.
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_PP_SM_Revocation_003a_UF
Objective

Verify that the Relying Party does not use an unsigned Status List Token or a bare status list in place of a Status List Token in JWT format.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is an unsecured JWT with alg none and an empty signature.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, the bare status list JSON object (bits, lst) instead of a Status List Token.
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

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_PP_SM_Revocation_003b_UF
Objective

Verify that the Relying Party does not use an unsigned Status List Token or a bare status list in place of a Status List Token in CWT format.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, the bare status list CBOR map (bits, lst) instead of a Status List Token.
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 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_PP_SM_Revocation_004a_UF
Objective

Verify that the Relying Party does not use an expired Status List Token in JWT format.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its exp claim 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

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_PP_SM_Revocation_004b_UF
Objective

Verify that the Relying Party does not use an expired Status List Token in CWT format.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its expiration time (4) 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

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_PP_SM_Revocation_005a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format whose subject differs from the status list URI in the credential.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its sub claim is the URI of a different status list.
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 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_PP_SM_Revocation_005b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format whose subject differs from the status list URI in the credential.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its subject (2) is the URI of a different status list.
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 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_PP_SM_Revocation_006a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format that declares the wrong type.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its typ header is JWT.
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 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_PP_SM_Revocation_006b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format that declares the wrong type.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its type header (16) is application/cwt.
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 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_PP_SM_Revocation_007a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format that lacks a required claim.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its payload has no sub claim.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its payload has no iat claim.
  3. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its payload has no status_list claim.
  4. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its status_list claim has no bits member.
  5. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its status_list claim has no lst member.
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_PP_SM_Revocation_007b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format that lacks a required claim.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its claims set has no subject (2).
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its claims set has no issued at claim (6).
  3. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its claims set has no status list claim (65533).
  4. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its status list claim has no bits entry.
  5. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its status list claim has no lst entry.
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_PP_SM_Revocation_008a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format whose signer is not trusted.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [HAIP] section 6.1
  • [Token Status List] section 11.3
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by a certificate issued by CA-X, with that certificate chain in x5c.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it carries no x5c header, so its signer cannot be validated.
  3. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by a self-signed certificate that is not part of default_trust_configuration_rp.
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

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_PP_SM_Revocation_008b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format whose signer is not trusted.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [HAIP] section 6.1
  • [Token Status List] section 11.3
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by a certificate issued by CA-X, with that certificate chain in x5chain.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it carries no x5chain header, so its signer cannot be validated.
  3. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by a self-signed certificate that is not part of default_trust_configuration_rp.
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

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_PP_SM_Revocation_009a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format signed under a trusted anchor of another entity or another list.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [Token Status List] section 11.3
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by a certificate under the revocation anchor of PP-B.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by a certificate under the revocation anchor of the Wallet Provider WP-A in TL-WP.
  3. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by a certificate under the anchor of AC-A in TL-AC.
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

default_trust_configuration_rp defines that a status list is trusted only under the revocation anchor of the entity that issued the credential.

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_PP_SM_Revocation_009b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format signed under a trusted anchor of another entity or another list.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [Token Status List] section 11.3
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by a certificate under the revocation anchor of PP-B.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by a certificate under the revocation anchor of the Wallet Provider WP-A in TL-WP.
  3. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by a certificate under the anchor of AC-A in TL-AC.
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

default_trust_configuration_rp defines that a status list is trusted only under the revocation anchor of the entity that issued the credential.

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_PP_SM_Revocation_010a
Objective

Verify that the Relying Party uses a Status List Token in JWT format signed under the revocation anchor of the entity that issued the credential.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [Token Status List] section 11.3
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves a valid Status List Token for it that holds the value 0x00 at the credential's index and is signed by a certificate under the revocation anchor CA-PP-A-REV of PP-A.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents a variant of default_credential_pid issued by PP-B in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it that holds the value 0x00 at the credential's index and is signed with the same key and certificate as that credential.
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.
  2. 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. The Test Status Provider has logged a request from the Relying Party for the status list referenced by the credential.
Comments

In the second step the issuance CA of PP-B is also published under the revocation service of PP-B, which is how default_trust_configuration_rp represents an issuer that signs its status lists with its issuance key ([Token Status List] section 11.3).

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

RP_PP_SM_Revocation_010b
Objective

Verify that the Relying Party uses a Status List Token in CWT format signed under the revocation anchor of the entity that issued the credential.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [Token Status List] section 11.3
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves a valid Status List Token for it that holds the value 0x00 at the credential's index and is signed by a certificate under the revocation anchor CA-PP-A-REV of PP-A.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents a variant of default_credential_pid issued by PP-B in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it that holds the value 0x00 at the credential's index and is signed with the same key and certificate as that credential.
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.
  2. 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. The Test Status Provider has logged a request from the Relying Party for the status list referenced by the credential.
Comments

In the second step the issuance CA of PP-B is also published under the revocation service of PP-B, which is how default_trust_configuration_rp represents an issuer that signs its status lists with its issuance key ([Token Status List] section 11.3).

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

RP_PP_SM_Revocation_011a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format whose signer chains only to the issuance anchor of the issuing entity, when that anchor is not published under the entity's revocation service.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [Token Status List] section 11.3
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed with the key and certificate that signed the presented credential.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by another certificate issued under the issuance CA CA-PP-A 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.
  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

PP-A publishes separate CAs for its issuance and revocation services, so its issuance CA is not a root of trust for its status lists.

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_PP_SM_Revocation_011b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format whose signer chains only to the issuance anchor of the issuing entity, when that anchor is not published under the entity's revocation service.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [Token Status List] section 11.3
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed with the key and certificate that signed the presented credential.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed by another certificate issued under the issuance CA CA-PP-A 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.
  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

PP-A publishes separate CAs for its issuance and revocation services, so its issuance CA is not a root of trust for its status lists.

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_PP_SM_Revocation_012a_UF
Objective

Verify that the Relying Party does not trust a root certificate embedded in the x5c header of a Status List Token in JWT format.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [HAIP] section 6.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its signer certificate chains to a self-signed root that x5c includes and that is not part of default_trust_configuration_rp.
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 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_PP_SM_Revocation_012b_UF
Objective

Verify that the Relying Party does not trust a root certificate embedded in the x5chain header of a Status List Token in CWT format.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [HAIP] section 6.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its signer certificate chains to a self-signed root that x5chain includes and that is not part of default_trust_configuration_rp.
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 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_PP_SM_Revocation_013a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format whose signer certificate is outside its validity period.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [RFC5280] section 6.1.3
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its signer certificate has expired.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its signer certificate is not yet valid.
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

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_PP_SM_Revocation_013b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format whose signer certificate is outside its validity period.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [RFC5280] section 6.1.3
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its signer certificate has expired.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its signer certificate is not yet valid.
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

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_PP_SM_Revocation_015a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format whose compressed status list is corrupt.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [Token Status List] section 4.1, 11.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that the lst member of its status_list claim is not valid base64url.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that the lst member of its status_list claim decodes to bytes that are not valid ZLIB data.
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

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_PP_SM_Revocation_015b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format whose compressed status list is corrupt.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [Token Status List] section 4.1, 11.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that the lst entry of its status list claim is not valid ZLIB data.
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 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_PP_SM_Revocation_016a_UF
Objective

Verify that the Relying Party refuses a Status List Token in JWT format whose status list decompresses to more than its declared maximum size, and stays available.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [Token Status List] section 4.1, 11.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its lst value decompresses to more bytes than the maximum status list size the Relying Party declares, for example a ZLIB stream that inflates to 1 GiB of zero bytes.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents a newly issued default_credential_pid in a valid Authorization Response, immediately after the previous step, while the status list referenced by that credential is valid and holds the value 0x00 at its 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.
  2. 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

Every entry of the inflated list holds 0x00, so a Relying Party that processes the list without a size limit accepts the presentation in the first step.

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_PP_SM_Revocation_016b_UF
Objective

Verify that the Relying Party refuses a Status List Token in CWT format whose status list decompresses to more than its declared maximum size, and stays available.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [Token Status List] section 4.1, 11.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that its lst value decompresses to more bytes than the maximum status list size the Relying Party declares, for example a ZLIB stream that inflates to 1 GiB of zero bytes.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents a newly issued default_credential_pid in a valid Authorization Response, immediately after the previous step, while the status list referenced by that credential is valid and holds the value 0x00 at its 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.
  2. 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

Every entry of the inflated list holds 0x00, so a Relying Party that processes the list without a size limit accepts the presentation in the first step.

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_PP_SM_Revocation_017a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format with an unsupported number of bits per status.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [Token Status List] section 4.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that the bits value of its status list is 3.
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 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_PP_SM_Revocation_017b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format with an unsupported number of bits per status.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [Token Status List] section 4.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that the bits value of its status list is 3.
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 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_PP_SM_Revocation_018a
Objective

Verify that the Relying Party reads the status value at the credential's index correctly from a Status List Token in JWT format, for every permitted number of bits per status.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [Token Status List] section 4.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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, issued with status index 15, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 1, in which the entry at index 15 holds 0x01 and every other entry holds 0x00.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 15, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 1, in which the entry at index 15 holds 0x00 and every other entry holds 0x01.
  3. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 7, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 2, in which the entry at index 7 holds 0x01 and every other entry holds 0x00.
  4. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 7, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 2, in which the entry at index 7 holds 0x00 and every other entry holds 0x01.
  5. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 3, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 4, in which the entry at index 3 holds 0x01 and every other entry holds 0x00.
  6. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 3, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 4, in which the entry at index 3 holds 0x00 and every other entry holds 0x01.
  7. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 1, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 8, in which the entry at index 1 holds 0x01 and every other entry holds 0x00.
  8. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 1, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 8, in which the entry at index 1 holds 0x00 and every other entry holds 0x01.
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 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.
  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 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.
  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.
  6. 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.
  7. 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.
  8. 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

Each index is the last entry of the second byte of the status list, so a Relying Party that reads the bits in the wrong order within a byte, or computes the byte offset incorrectly, reads a neighbouring entry. Every step uses a newly issued credential.

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

RP_PP_SM_Revocation_018b
Objective

Verify that the Relying Party reads the status value at the credential's index correctly from a Status List Token in CWT format, for every permitted number of bits per status.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [Token Status List] section 4.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
Test Scenario
  1. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 15, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 1, in which the entry at index 15 holds 0x01 and every other entry holds 0x00.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 15, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 1, in which the entry at index 15 holds 0x00 and every other entry holds 0x01.
  3. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 7, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 2, in which the entry at index 7 holds 0x01 and every other entry holds 0x00.
  4. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 7, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 2, in which the entry at index 7 holds 0x00 and every other entry holds 0x01.
  5. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 3, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 4, in which the entry at index 3 holds 0x01 and every other entry holds 0x00.
  6. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 3, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 4, in which the entry at index 3 holds 0x00 and every other entry holds 0x01.
  7. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 1, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 8, in which the entry at index 1 holds 0x01 and every other entry holds 0x00.
  8. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid, issued with status index 1, in a valid Authorization Response, while the Test Status Provider serves a valid Status List Token for it with bits set to 8, in which the entry at index 1 holds 0x00 and every other entry holds 0x01.
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 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.
  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 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.
  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.
  6. 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.
  7. 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.
  8. 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

Each index is the last entry of the second byte of the status list, so a Relying Party that reads the bits in the wrong order within a byte, or computes the byte offset incorrectly, reads a neighbouring entry. Every step uses a newly issued credential.

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

RP_PP_SM_Revocation_019a_UF
Objective

Verify that the Relying Party does not use a Status List Token in JWT format protected with an algorithm outside the agreed cryptographic mechanisms.

References
  • [Token Status List] section 5.1, 8.3
  • [RFC7519] section 7.2
  • [ECCG ACM]
  • [HAIP] section 6.1, 7
  • [RFC8725] section 3.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token in JWT 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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed with ES256K (curve secp256k1).
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is protected with HS256, keyed with the encoded public key of the certificate in its x5c header.
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

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_PP_SM_Revocation_019b_UF
Objective

Verify that the Relying Party does not use a Status List Token in CWT format protected with an algorithm outside the agreed cryptographic mechanisms.

References
  • [Token Status List] section 5.2, 8.3
  • [RFC8392] section 7.2
  • [ECCG ACM]
  • [HAIP] section 6.1, 7
  • [RFC8725] section 3.1
  • [ARF] Annex 2, PPNot_05, VCR_13, VCR_14
  • [ETSI TS 119 602]
  • [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.
  • Status List Token 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.
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 Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is signed with ES256K (curve secp256k1).
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the Test Status Provider serves, for the status list referenced by the credential, a Status List Token that holds the value 0x00 at the credential's index and is valid in every other respect, except that it is protected with a COSE_Mac0 structure using HMAC 256/256, keyed with the encoded public key of the certificate in its x5chain header.
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

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_PP_SM_Revocation_030_UF
Objective

Verify that the Relying Party does not use an identifier list in CWT format that is badly signed, expired or signed by an untrusted signer.

References
  • [ISO/IEC 18013-5 ed2]
  • [RFC8392] section 7.2
  • [ARF] Annex 2, PPNot_05, VCR_11, VCR_12, VCR_14
  • [ETSI TS 119 602]
  • [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.
  6. The identifier list served for each presented credential does not contain the credential's identifier.
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 one bit of the signature value of the referenced identifier list is flipped.
  2. Perform a presentation for default_query_pid in which the Conformance Wallet presents default_credential_pid in a valid Authorization Response, while the expiration time (4) of the referenced identifier list lies T_skew plus one hour in the past.
  3. 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 is signed by a certificate 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.
  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

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).