Skip to content

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