Skip to content

Attestation Provider test cases

Interaction

Engagement

WS_AP_IA_Engagement_007a
Objective

Verify that, for issuance via Redirects, the Wallet can be invoked through the haip-vci:// custom URL scheme, if supported by Wallet.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4.2
Profile applicability

Wallet supports invocation through the haip-vci:// custom URL scheme.

EUDI-wallet relevancy

EUDI_generic | EUDI_optional

Technology

Issuance via Redirects. Wallet supports the Issuer initiated issuance flow.

Preconditions
  1. End-user is engaging with a Issuer using a User-agent.
Test Scenario
  1. Credential Issuer provides Credential Offer link to the User-agent using URL scheme haip-vci://. Note: for engagement by presenting the link as QR-code for cross-device usage, additional security measures are recommended.
  2. End-user triggers link to be followed (e.g. clicks button or link).
Expected results
  1. User-agent presents option to End-user to engage issuance.
  2. Wallet is invoked successfully.
WS_AP_IA_Engagement_007b
Objective

Verify that, for issuance via Redirects, the Wallet can be invoked through the eu-eaa-offer:// custom URL scheme.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

Wallet supports the Issuer initiated issuance flow. Issuance via Redirects. Wallet invocation uses the required custom URL scheme eu-eaa-offer://.

Preconditions
  1. End-user is engaging with a Issuer using a User-agent.
Test Scenario
  1. Credential Issuer provides Credential Offer link to the User-agent using URL scheme eu-eaa-offer://. Note: for engagement by presenting the link as QR-code for cross-device usage, additional security measures are recommended.
  2. End-user triggers link to be followed (e.g. clicks button or link).
Expected results
  1. User-agent presents option to End-user to engage issuance.
  2. Wallet is invoked successfully.

Main Interaction

WS_AP_IA_MainInteraction_010a
Objective

Verify that the Wallet sends an Authorization Request to the Authorization Server's Authorization Endpoint, after successfully pushing the Authorization Request (PAR).

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4
  • [OpenID4VCI] section 5.1
  • [RFC8414] section 2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects. Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained the Credential Issuer Metadata.
  4. Wallet successfully obtained the Authorization Server Metadata.
  5. Wallet successfully pushed an Authentication Request to the Authorization Server's pushed_authorization_request_endpoint.
Test Scenario
  1. Verify the Authorization Request.
Expected results
  1. The Wallet sends a HTTP Request to the Authorization Endpoint of the Authorization Server as listed in the Credential Issuer Metadata. The HTTP Request:
    1. Uses the GET or POST method.
    2. Has the 'hostname', and 'port-number' if applicable, of the authorization_endpoint in the Authorization Server's Metadata.
    3. Requests the 'path' and any 'query' component of the authorization_endpoint, without a fragment component.
WS_AP_IA_MainInteraction_010b
Objective

Verify that the Wallet sends a reference to a Pushed Authorization Request to the Authorization Server's Authorization Endpoint, when requesting a Credential.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4
  • [OpenID4VCI] section 5.1
  • [RFC9126] section 4
  • [RFC9101] section 5
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects. Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. Wallet successfully obtained the Authorization Server Metadata.
  5. Wallet successfully pushed an Authentication Request to the Authorization Server's pushed_authorization_request_endpoint.
  6. Wallet send an Authorization Request to the Authorization Server's authorization_endpoint.
Test Scenario
  1. Verify the contents of the Authorization Request.
Expected results
  1. The Authorization Request includes a request_uri parameter.
WS_AP_IA_MainInteraction_010c
Objective

Verify that the Wallet sends a reference to a successfully Pushed Authorization Request to the Authorization Server's Authorization Endpoint, when requesting a Credential.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4
  • [OpenID4VCI] section 5.1
  • [RFC9126] section 2.2, 4
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects. Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. Wallet successfully obtained the Authorization Server Metadata.
  5. Wallet successfully pushed an Authentication Request to the Authorization Server's pushed_authorization_request_endpoint.
  6. Wallet send an Authorization Request to the Authorization Server's authorization_endpoint.
  7. Wallet send a reference to a Pushed Authorization Request in the Authorization Request to the Authorization Server's Authorization Endpoint.
Test Scenario
  1. Verify the contents of the Authorization Request.
Expected results
  1. The value of the request_uri is the same value as the value of the request_uri send in response to the Pushed Authentication Request submission, by the PAR endpoint of the Authorization Server.
WS_AP_IA_MainInteraction_030a
Objective

Verify that the Wallet sends a Credential Request using a HTTP Request to the Credential Endpoint of the Credential Issuer.

References
  • [ETSI TS 119 472-3] section 4.6
  • [HAIP] section 4
  • [OpenID4VCI] section 8.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

OpenID4VCI Credential Endpoint requests.

Preconditions
  1. Wallet is set to 'default_configuration_1'.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet established a connection to the Credential Endpoint of the Credential Issuer, after receiving the Access Token from the Token Endpoint.
Test Scenario
  1. Verify the Credential Request.
Expected results
  1. The Wallet sends a HTTP Request to the Credential Endpoint of the Credential Issuer as listed in the Credential Issuer Metadata. The HTTP Request:
    1. Uses the POST method.
    2. Has the 'hostname', and 'port-number' if applicable, of the credential_endpoint in the Credential Issuer's Metadata.
    3. Requests the 'path' and 'query', if applicable, of the credential_endpoint, without a fragment part.
WS_AP_IA_MainInteraction_030b
Objective

Verify that the Wallet sends a Credential Request using a correctly formatted HTTP Request to the Credential Endpoint of the Credential Issuer.

References
  • [ETSI TS 119 472-3] section 4.6
  • [HAIP] section 4
  • [OpenID4VCI] section 8.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

OpenID4VCI Credential Endpoint requests.

Preconditions
  1. Wallet is set to 'default_configuration_1'.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a HTTP Request to the Credential Endpoint.
Test Scenario
  1. Verify the header of the HTTP Request of the Credential Request.
  2. Perform all Shared_JSON test cases on the contents of the Body of the HTTP Request.
Expected results
  1. The Wallet sends a HTTP Request with a Content-Type header with the value application/json.

  2. All test cases pass.

    • TODO Distinguish Credential Request encryption applicable or not?
WS_AP_IA_MainInteraction_031a
Objective

Verify that the Wallet handles a correct Credential Response.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4
  • [OpenID4VCI] section 8.3
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

OpenID4VCI Credential Endpoint response handling.

Preconditions
  1. Wallet is set to 'default_configuration_1'.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully sent a valid Credential Request to the Credential Issuer.
Test Scenario
  1. Issuer responds with a valid Credential Response, including at least one valid Credential matching the requested Credential Type.
Expected results
  1. The Credential is stored in the wallet and available for the End-user to present to a Verifier. The End-user is informed the Credential is available, if applicable.
WS_AP_IA_MainInteraction_031b_UF
Objective

Verify that the Wallet treats a Credential Error Response containing credential_request_denied as unrecoverable.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4
  • [OpenID4VCI] section 8.3.1.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

OpenID4VCI Credential Endpoint error-response handling.

Preconditions
  1. Wallet is set to 'default_configuration_1'.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully sent a valid Credential Request to the Credential Issuer.
Test Scenario
  1. The Issuer returns a valid Credential Error Response containing the error code credential_request_denied.
Expected results
  1. The Wallet does not store any new Credential. The End-user is informed the Credential was not issued, if applicable. The Wallet aborts the issuance process and does not make any further requests as part of this issuance attempt.

Supportive Interaction

WS_AP_IA_Supportive_010a
Objective

Verify that the Wallet sends a Pushed Authorization Request (PAR) to the Authorization Server's Pushed Authentication Request Endpoint as a HTTP POST request to the endpoint.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects. Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained the Credential Issuer Metadata.
  4. Wallet successfully obtained the Authorization Server Metadata, including pushed_authorization_request_endpoint.
Test Scenario
  1. End-user selects a Credential in the Wallet (based on credential_configuration_ids and Credential Issuer Metadata) to obtain such Credential from the Credential Issuer.
Expected results
  1. Wallet connects to the Authorization Server's Pushed Authorization Request (PAR) Endpoint using TLS, making a HTTP request:
    1. Uses the POST method.
    2. Has the 'hostname', and 'port-number' if applicable, of the pushed_authorization_request_endpoint in the Authorization Server's Metadata.
    3. Requests the 'path' of the pushed_authorization_request_endpoint, without a query or fragment part.
WS_AP_IA_Supportive_011a
Objective

Verify that the Wallet can handle an correct response when submitting a Pushed Authorization Request (PAR) to the Authorization Server's Pushed Authentication Request Endpoint.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects. Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. Wallet successfully obtained the Authorization Server Metadata, including pushed_authorization_request_endpoint.
  5. The Wallet sent a valid Pushed Authorization Request to the Authorization Server's Pushed Authorization Request Endpoint.
Test Scenario
  1. Issuer responds with a valid PAR Response. That is a HTTP Response:
    1. with a HTTP Header Content-Type with value application/json, containing:
    2. with the HTTP Response Body in JSON format:
      1. contains a request_uri
      2. contains a expires_in
Expected results
  1. The subsequent Authorization Request sent through the User-agent contains the exact request_uri value returned by the Authorization Server.
WS_AP_IA_Supportive_011b_UF
Objective

Verify that the Wallet can handle an incorrect response when submitting a Pushed Authorization Request (PAR) to the Authorization Server's Pushed Authentication Request Endpoint, when the response is omitting a request_uri.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects. Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. Wallet successfully obtained the Authorization Server Metadata, including pushed_authorization_request_endpoint.
  5. The Wallet sent a valid Pushed Authorization Request to the Authorization Server's Pushed Authorization Request Endpoint.
Test Scenario
  1. Issuer responds with a invalid PAR Response, with the response_uri omitted. That is a HTTP Response:
    1. with a HTTP Header Content-Type with value application/json, containing:
    2. with the HTTP Response Body in JSON format:
      1. contains a expires_in
      2. omitting the request_uri
Expected results
  1. Wallet does not send an Authorization Request to the Authorizations Server's Authorization Endpoint, and informs the user ot cannot continue, if applicable.

Message Structure

Protocol Messages

WS_AP_MS_ProtocolMessages_033a
Objective

Verify that the Wallet can handle a correctly formatted Credential Offer, using the issuer initiated flow and credential offer by value.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4.2
  • [OpenID4VCI] section 4.1
Profile applicability

Wallet supports the Issuer initiated issuance flow.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet can be invoked for issuance using the custom URL scheme eu-eaa-offer://.
Test Scenario
  1. Credential Issuer provides a valid Credential Offer as parameter in a custom URL Scheme to the User-agent. The credential_offer parameter:
    1. has a credential_issuer property with a valid issuer identifier.
    2. has a credential_configuration_ids property, as an array containing at least one identifier as string.
  2. End-user triggers link to be followed.
Expected results
  1. User-agent presents option to End-user to engage issuance, optionally after requesting the Credential Issuer Metadata (derived using .well-known from credential_issuer, if not cached already).
  2. The Wallet connects to the Credential Issuer, to make a request at the Authorization Server's Authorization Endpoint.
WS_AP_MS_ProtocolMessages_033b_UF
Objective

Verify that the Wallet does not engage issuance based on a Credential Offer with the credential_issuer omitted, using the issuer initiated flow and credential offer by value.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4.2
  • [OpenID4VCI] sections 4.1.1 and 12.2.2
Profile applicability

Wallet supports the Issuer initiated issuance flow.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Wallet supports invocation through the custom URL scheme eu-eaa-offer://.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet can be invoked for issuance using a custom URL scheme.
Test Scenario
  1. Credential Issuer provides a Credential Offer as parameter in a custom URL scheme to the User-agent. The credential_offer parameter:
    1. has no credential_issuer property.
    2. has a credential_configuration_ids property, as an array containing at least one identifier as string.
  2. End-user triggers link to be followed.
Expected results
  1. User-agent presents option to End-user to engage issuance.
  2. The Wallet does not engage for issuance. This includes:
    1. The Wallet could inform the End-user about the incorrect engagement, if applicable.
    2. The Wallet does not connect to the Credential Issuer, for retrieving metadata. This includes not connecting to the Endpoint created by deriving from the URL where the User-agent was engaged (e.g. referrer or origin), by inserting .well-known/openid-credential-issuer.
WS_AP_MS_ProtocolMessages_033c_UF
Objective

Verify that the Wallet does not engage issuance based on a Credential Offer with the credential_configuration_ids property omitted, using the issuer initiated flow and credential offer by value.

References
  • [ETSI TS 119 472-3] section 4.1
  • [HAIP] section 4.2
  • [OpenID4VCI] section 4.1.1
Profile applicability

Wallet supports the Issuer initiated issuance flow.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Wallet supports invocation through the custom URL scheme eu-eaa-offer://.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet can be invoked for issuance using a custom URL scheme.
Test Scenario
  1. Credential Issuer provides a Credential Offer as parameter in a custom URL scheme to the User-agent. The credential_offer parameter:
    1. has a credential_issuer property with a valid issuer identifier.
    2. has no credential_configuration_ids property.
  2. End-user triggers link to be followed.
Expected results
  1. User-agent presents option to End-user to engage issuance.
  2. The Wallet does not engage for issuance. This includes:
    1. The Wallet could inform the End-user about the incorrect engagement, if applicable.
WS_AP_MS_ProtocolMessages_034a
Objective

Verify that the Wallet sends the HTTP Request Body in the correct format when sending a Pushed Authorization Request, when using Pushed Authorization Requests for issuance.

References
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. The Wallet sends an HTTP POST Request to the selected Authorization Server's PAR endpoint.
Test Scenario
  1. Verify the Content-Type header of the received HTTP Request.
Expected results
  1. The HTTP POST Request has the header Content-Type with value application/x-www-form-urlencoded.
WS_AP_MS_ProtocolMessages_034b
Objective

Verify that the Wallet sends a HTTP Request that contains a request parameter when sending a Pushed Authorization Request, when using Pushed Authorization Requests for issuance.

References
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 2
Profile applicability

Wallet that uses JAR during PAR for the Authorization Request to the Authorization Server on Credential Issuance.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. The Wallet sends an HTTP POST Request to the selected Authorization Server's PAR endpoint.
Test Scenario
  1. Verify the request parameters of the received HTTP Request.
Expected results
  1. The HTTP POST Request contains a parameter request.
WS_AP_MS_ProtocolMessages_034c
Objective

Verify that the Wallet sends a request parameter in the HTTP request is a JWT (Signed Request Object) when sending a Pushed Authorization Request, when using Pushed Authorization Requests for issuance.

References
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 3
Profile applicability

Wallet that uses JAR during PAR for the Authorization Request to the Authorization Server on Credential Issuance.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. The Wallet sends an HTTP POST Request to the selected Authorization Server's PAR endpoint.
  5. The HTTP POST Request to the selected Authorization Server's PAR endpoint contains a request parameter.
Test Scenario
  1. Verify the request parameter in the received HTTP Request.
Expected results
  1. The value of the request parameter has the structure of a signed JWT in compact serialization, that is three base64url-encoded segments separated by two period (.) characters.
  • Note: validation of the signed JWT itself as Authorization Request, is done in other test cases.
WS_AP_MS_ProtocolMessages_034d
Objective

Verify that the Wallet sends a request parameter in the HTTP request is a correctly formatted JWT (Signed Request Object) when sending a Pushed Authorization Request, when using Pushed Authorization Requests for issuance.

References
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 3
Profile applicability

Wallet that uses JAR during PAR for the Authorization Request to the Authorization Server on Credential Issuance.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. The Wallet sends an HTTP POST Request to the selected Authorization Server's PAR endpoint.
  5. The HTTP POST Request to the selected Authorization Server's PAR endpoint contains a request parameter.
  6. The request parameter sent to the selected Authorization Server's PAR endpoint has the structure of a signed JWT.
Test Scenario
  1. Perform all Shared_JWT_JWS test cases on the value of the request parameter.
Expected results
  1. All test cases pass.
WS_AP_MS_ProtocolMessages_035a
Objective

Verify that the Wallet sends a HTTP Request that contains one OAuth-Client-Attestation HTTP header when sending a Pushed Authorization Request, when using Pushed Authorization Requests for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 2.1
  • [IETF draft-attestation-based-client-auth] section 6.1, 6.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. The Wallet sends an HTTP POST Request to the selected Authorization Server's PAR endpoint.
Test Scenario
  1. Verify the HTTP Headers of the received HTTP Request.
Expected results
  1. The HTTP Request contains exactly one HTTP header OAuth-Client-Attestation.
WS_AP_MS_ProtocolMessages_035b
Objective

Verify that the Wallet sends a HTTP Request that contains a syntactically correct OAuth-Client-Attestation HTTP header when sending a Pushed Authorization Request, when using Pushed Authorization Requests for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 2.1
  • [IETF draft-attestation-based-client-auth] section 5.1, 6.1
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. The Wallet sends an HTTP POST Request to the selected Authorization Server's PAR endpoint.
  5. The HTTP Request to the selected Authorization Server's PAR endpoint contains an OAuth-Client-Attestation HTTP header.
Test Scenario
  1. Verify the OAuth-Client-Attestation HTTP-Header of the received HTTP Request.
Expected results
  1. The value of the OAuth-Client-Attestation HTTP Header of the HTTP Request has the structure of a signed JWT in compact serialization, that is three Base64url-encoded parts separated by exactly two period (.) characters.
WS_AP_MS_ProtocolMessages_036a
Objective

Verify that the Wallet sends a HTTP Request that contains one OAuth-Client-Attestation-PoP HTTP header when sending a Pushed Authorization Request, when using Pushed Authorization Requests for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 2.1
  • [IETF draft-attestation-based-client-auth] section 6.1, 6.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. The Wallet sends an HTTP POST Request to the selected Authorization Server's PAR endpoint.
Test Scenario
  1. Verify the HTTP Headers of the received HTTP Request.
Expected results
  1. The HTTP Request contains exactly one HTTP header OAuth-Client-Attestation-PoP.
WS_AP_MS_ProtocolMessages_036b
Objective

Verify that the Wallet sends a HTTP Request that contains a syntactically correct OAuth-Client-Attestation-PoP HTTP header when sending a Pushed Authorization Request, when using Pushed Authorization Requests for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4
  • [RFC9126] section 2.1
  • [IETF draft-attestation-based-client-auth] section 5.2, 6.1
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. End-user is engaging with a Credential Issuer using a User-agent.
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. The Wallet sends an HTTP POST Request to the selected Authorization Server's PAR endpoint.
  5. The HTTP Request to the selected Authorization Server's PAR endpoint contains an OAuth-Client-Attestation-PoP HTTP header.
Test Scenario
  1. Verify the OAuth-Client-Attestation-PoP HTTP-Header of the received HTTP Request.
Expected results
  1. The value of the OAuth-Client-Attestation-PoP HTTP Header of the HTTP Request has the structure of a signed JWT in compact serialization, that is three Base64url-encoded parts separated by exactly two period (.) characters.
WS_AP_MS_ProtocolMessages_037a
Objective

Verify that the Wallet sends a syntactically correct body of the Wallet Instance Attestation as Client Attestation, when using Pushed Authorization Requests for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section E
  • [IETF draft-attestation-based-client-auth] section 5.1
Profile applicability

None

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. End-user is engaging with a Credential Issuer using a User-agent.
  3. Wallet started engagement with Credential Issuer.
  4. Wallet successfully obtained Credential Issuer Metadata.
  5. Wallet send a HTTP POST Request for a Pushed Authorization Request to the PAR Endpoint of the selected Authorization Server.
  6. Wallet send a correctly signed and trusted Wallet Instance Attestation as a Client Attestation.
Test Scenario
  1. Verify the contents of the Wallet Instance Attestation (i.e. the JWT body).
Expected results
  1. The WIA contains the following top-level claims:
    1. wallet_name
    2. wallet_version
    3. wallet_solution_certification_information
    4. client_status
    5. exp
    6. wallet_link
    7. iss
    8. sub
    9. cnf
    10. (optionally) iat
    11. (optionally) nbf
WS_AP_MS_ProtocolMessages_037b
Objective

Verify that the Wallet sends a syntactically correct header of the Wallet Instance Attestation as Client Attestation, when using Pushed Authorization Requests for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section E
  • [RFC9126] section 2.1
  • [IETF draft-attestation-based-client-auth] section 5.1
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. End-user is engaging with a Credential Issuer using a User-agent.
  3. Wallet started engagement with Credential Issuer.
  4. Wallet successfully obtained Credential Issuer Metadata.
  5. Wallet send a HTTP POST Request for a Pushed Authorization Request to the PAR Endpoint of the selected Authorization Server.
  6. Wallet send a correctly signed and trusted Wallet Instance Attestation as Client Attestation.
Test Scenario
  1. Verify the header of the Wallet Instance Attestation (i.e. the JWT header).
Expected results
  1. The WIA JOSE header contains the required typ header parameter.
WS_AP_MS_ProtocolMessages_037c
Objective

Verify that the Wallet sends a correct typ header of the Wallet Instance Attestation as Client Attestation, when using Pushed Authorization Requests for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section E
  • [RFC9126] section 2.1
  • [IETF draft-attestation-based-client-auth] section 5.1
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. End-user is engaging with a Credential Issuer using a User-agent.
  3. Wallet started engagement with Credential Issuer.
  4. Wallet successfully obtained Credential Issuer Metadata.
  5. Wallet send a HTTP POST Request for a Pushed Authorization Request to the PAR Endpoint of the selected Authorization Server.
  6. Wallet send a correctly signed and trusted Wallet Instance Attestation as a Client Attestation.
  7. Wallet send a syntactically correct header of the Wallet Instance Attestation as Client Attestation.
Test Scenario
  1. Verify the typ JOSE header of the Wallet Instance Attestation (i.e. in the JWT header).
Expected results
  1. The value of the typ header of the WIA has the value oauth-client-attestation+jwt.
WS_AP_MS_ProtocolMessages_038a
Objective

Verify that the Wallet sends a syntactically correct Wallet Instance Attestation Proof of Possesion, when using Pushed Authorization Requests for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section E
  • [RFC9126] section 2.1
  • [IETF draft-attestation-based-client-auth] section 5.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. End-user is engaging with a Credential Issuer using a User-agent.
  3. Wallet started engagement with Credential Issuer.
  4. Wallet successfully obtained Credential Issuer Metadata.
  5. Wallet send a HTTP POST Request for a Pushed Authorization Request to the PAR Endpoint of the selected Authorization Server.
  6. Wallet send a correctly signed and trusted Wallet Instance Attestation as a Client Attestation.
Test Scenario
  1. Verify the claims set in the Wallet Instance Attestation Proof of Possession JWT.
Expected results
  1. The Proof of Possession contains the following top-level claims:
    1. iss
    2. aud
    3. jti
    4. iat
    5. (optionally) challenge
    6. (optionally) nbf
WS_AP_MS_ProtocolMessages_039a
Objective

Verify that the Wallet sends a syntactically correct Authorization Request to the Authorization Endpoint, when authentication to a Authorization Server for requesting issuance of a Credential.

References
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.2, 5.1.3
  • [RFC9126] section 4
  • [RFC9101] section 5.2.2
  • [RFC6749] section 4.1.1
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. End-user is engaging with a Credential Issuer using a User-agent.
  3. Wallet started engagement with Credential Issuer.
  4. Wallet successfully obtained Credential Issuer Metadata.
  5. Wallet send a valid and trusted PAR request the Authorization Server's PAR Endpoint.
  6. Wallet send a Authorization Request to the Authorization Server's Authorization Endpoint.
Test Scenario
  1. Verify the Authorization Request.
Expected results
  1. The Authorization Request contains the following top-level request parameters:
    1. request_uri
    2. client_id
WS_AP_MS_ProtocolMessages_039b
Objective

Verify that the Wallet sends a syntactically correct request_uri parameter in the Authorization Request to the Authorization Endpoint, when authentication to a Authorization Server for requesting issuance of a Credential.

References
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.2, 5.1.3
  • [RFC9126] section 4
  • [RFC9101] section 5, 5.2.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. End-user is engaging with a Credential Issuer using a User-agent.
  3. Wallet started engagement with Credential Issuer.
  4. Wallet successfully obtained Credential Issuer Metadata.
  5. Wallet send a valid and trusted PAR request the Authorization Server's PAR Endpoint.
  6. Wallet send a Authorization Request to the Authorization Server's Authorization Endpoint.
Test Scenario
  1. Verify the request_uri parameter of the Authorization Request.
Expected results
  1. The value of the request_uri parameter of the Authorization Request is a syntactically correct formatted URI.
WS_AP_MS_ProtocolMessages_040a
Objective

Verify that the Wallet sends a syntactically correct Pushed Authorization Request, when authentication to a Authorization Server for requesting issuance of a Credential.

References
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.2, 5.1.3
  • [RFC6749] section 4.1.1
  • [RFC7636] section 4.3
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. End-user is engaging with a Credential Issuer using a User-agent.
  3. Wallet started engagement with Credential Issuer.
  4. Wallet successfully obtained Credential Issuer Metadata.
  5. Wallet send a valid and trusted PAR request the Authorization Server's PAR Endpoint.
  6. Wallet send a valid Authorization Request to the Authorization Server's Authorization Endpoint.
Test Scenario
  1. Verify the Pushed Authorization Request.
Expected results
  1. The Pushed Authorization Request contains the following top-level request parameters:
    1. scope
    2. response_type
    3. client_id
    4. redirect_uri
    5. code_challenge
    6. code_challenge_method
    7. (optionally) issuer_state
    8. (optionally) resource
WS_AP_MS_ProtocolMessages_040b
Objective

Verify that the Wallet sends a correct Pushed Authorization Request, when authentication to a Authorization Server for requesting issuance of a Credential.

References
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. End-user is engaging with a Credential Issuer using a User-agent.
  3. Wallet started engagement with Credential Issuer.
  4. Wallet successfully obtained Credential Issuer Metadata.
  5. Wallet send a valid and trusted PAR request the Authorization Server's PAR Endpoint.
  6. Wallet send a valid Authorization Request to the Authorization Server's Authorization Endpoint.
  7. Wallet send a syntactically correct Authorization Request Request Object.
Test Scenario
  1. Verify the scope parameter in the Pushed Authorization Request.
Expected results

  1. The value of the scope parameter matches with one or more values, with whitespace(s) as separator, where each value matches a scope of a credential_configurations_supported of the Credential Issuer as stated in the Credential Issuer's metadata.

    • NOTE: this assumes the Credential Issuer's Metadata does include a unique scope for each supported Credential Configuration.
WS_AP_MS_ProtocolMessages_050a
Objective

Verify that the Wallet sends a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer, when requesting issuance of a Credential with Key Binding.

References
  • [ETSI TS 119 472-3] section 4.6
  • [HAIP] section 4.5
  • [OpenID4VCI] section 8.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. The Wallet obtained an Access Token from a Token Response that did not return credential_identifiers.
  5. Wallet send a correctly formatted HTTP Request to the Credential Endpoint.
Test Scenario
  1. Verify the presence of parameters in the HTTP Request send to the Credential Endpoint.
Expected results
  1. The HTTP Request contains the following parameters:
    1. credential_identifier is absent
    2. credential_configuration_id is present
    3. proofs is present
    4. (optionally) credential_response_encryption can be present
Comments
  • HAIP requires the scope Authorization parameter; under OpenID4VCI 8.2, the Credential Request uses credential_configuration_id only when the Token Response did not return credential_identifiers.
WS_AP_MS_ProtocolMessages_050b
Objective

Verify that the Wallet sends a syntactically correct credential_configuration_id parameter in the Credential Request to the Credential Endpoint of the Credential Issuer, when requesting issuance of a Credential with Key Binding.

References
  • [ETSI TS 119 472-3] section 4.6
  • [HAIP] section 4.5
  • [OpenID4VCI] section 8.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet obtained an Access Token from a Token Response that did not return credential_identifiers.
  5. Wallet send a HTTP Request to the Credential Endpoint.
  6. Wallet send a Credential Request containing the credential_configuration_id parameter to the Credential Endpoint.
Test Scenario
  1. Verify the credential_configuration_id parameter in the HTTP Request send to the Credential Endpoint.
Expected results
  1. The credential_configuration_id parameter in the HTTP Request is a string.
WS_AP_MS_ProtocolMessages_050c
Objective

Verify that the Wallet sends a correct credential_configuration_id parameter in the Credential Request to the Credential Endpoint of the Credential Issuer, when requesting issuance of a Credential with Key Binding.

References
  • [ETSI TS 119 472-3] section 4.6
  • [HAIP] section 4.5
  • [OpenID4VCI] section 8.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet obtained an Access Token from a Token Response that did not return credential_identifiers.
  5. Wallet send a HTTP Request to the Credential Endpoint
  6. Wallet send a Credential Request containing a syntactically correct credential_configuration_id parameter to the Credential Endpoint.
Test Scenario
  1. Verify the credential_configuration_id parameter in the HTTP Request send to the Credential Endpoint.
Expected results
  1. The credential_configuration_id value identifies a key in the credential_configurations_supported map whose corresponding configuration contains a scope value used in the Authorization Request.
WS_AP_MS_ProtocolMessages_050d
Objective

Verify that the Wallet sends a correctly formatted proofs parameter in the Credential Request to the Credential Endpoint of the Credential Issuer, when requesting issuance of a Credential with Key Binding.

References
  • [ETSI TS 119 472-3] section 4.6
  • [HAIP] section 4.5
  • [OpenID4VCI] section 8.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a HTTP Request to the Credential Endpoint.
  6. Wallet send a Credential Request containing the proofs parameter to the Credential Endpoint.
Test Scenario
  1. Verify the proofs parameter in the HTTP Request send to the Credential Endpoint.
Expected results
  1. The proofs parameter in the HTTP Request is a JSON object.
WS_AP_MS_ProtocolMessages_050e
Objective

Verify that the Wallet sends a syntactically correct proofs parameter in the Credential Request to the Credential Endpoint of the Credential Issuer, when requesting issuance of a Credential with Key Binding.

References
  • [ETSI TS 119 472-3] section 4.6.1
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section 8.2, F
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Issuance via Redirects.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a HTTP Request to the Credential Endpoint.
  6. Wallet send a Credential Request a containing syntactically correct proofs parameter to the Credential Endpoint.
Test Scenario
  1. Verify the presence of properties in the proofs parameter in the HTTP Request send to the Credential Endpoint.
Expected results
  1. The proofs parameter in the HTTP Request contains either a jwt or attestation property, not both.
WS_AP_MS_ProtocolMessages_051a
Objective

Verify that the Wallet sends a jwt in the proofs in the Credential Request to the Credential Endpoint of a Credential Issuer, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section 8.2, F.1
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a syntactically correct proofs parameter in the Credential Request.
Test Scenario
  1. Verify the contents of the proofs parameter in the Credential Request.
Expected results
  1. The proofs parameter contains a jwt property that is an array.
WS_AP_MS_ProtocolMessages_051b
Objective

Verify that the Wallet sends a correctly formatted jwt in the proofs in the Credential Request to the Credential Endpoint of a Credential Issuer, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section 8.2, F.1
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a syntactically correct proofs parameter in the Credential Request.
  7. Wallet send a jwt property in the proofs parameter of the Credential Request.
Test Scenario
  1. Verify the jwt property of the proofs parameter in the Credential Request.
Expected results
  1. The jwt parameter is an array of one element.
WS_AP_MS_ProtocolMessages_051c
Objective

Verify that the Wallet correctly formatted value(s) for the jwt parameter in the Credential Request to the Credential Endpoint of a Credential Issuer, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section 8.2, F.1
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a syntactically correct proofs parameter in the Credential Request.
  7. Wallet send a correctly formatted jwt property in the proofs parameter of the Credential Request.
Test Scenario
  1. Verify the element(s) of the jwt property of the proofs parameter in the Credential Request.
Expected results
  1. Any element in the jwt parameter is a string.
WS_AP_MS_ProtocolMessages_052a
Objective

Verify that the Wallet sends a syntactically correct header of the proof with Key Attestation in the Credential Request, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section F.1
  • [RFC7515] section 4
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a valid signed proof with Key Attestation in the Credential Request.
Test Scenario
  1. Verify the presence of parameters in the header of the proof with Key Attestation.
Expected results
  1. The presence of parameters in the header of the proof with Key Attestation is as follows:
    1. alg is present.
    2. typ is present.
    3. (optionally) kid can be present.
    4. (optionally) jwk can be present.
    5. key_attestation is present.
    6. (optionally) x5c can be present.
    7. (optionally) trust_chain can be present.
WS_AP_MS_ProtocolMessages_052b
Objective

Verify that the Wallet sends a correctly formatted typ header of the proof with Key Attestation in the Credential Request, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section F.1
  • [RFC7515] section 4
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a valid signed proof with Key Attestation in the Credential Request.
  7. The proof with Key Attestation contains a typ header.
Test Scenario
  1. Verify the typ header of the proof with Key Attestation.
Expected results
  1. The value of the typ header is a string.
WS_AP_MS_ProtocolMessages_052c
Objective

Verify that the Wallet sends a correct typ header of the proof with Key Attestation in the Credential Request, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section F.1
  • [RFC7515] section 4.1.9
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a valid signed proof with Key Attestation in the Credential Request.
  7. The proof with Key Attestation contains a syntactically correct typ header.
Test Scenario
  1. Verify the typ header of the proof with Key Attestation.
Expected results
  1. The value of the typ header is openid4vci-proof+jwt.
WS_AP_MS_ProtocolMessages_053a
Objective

Verify that the Wallet sends a syntactically correct body of the proof with Key Attestation in the Credential Request, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section F.1
  • [RFC7519] section 4
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential with Key Binding.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a valid signed proof with Key Attestation in the Credential Request.
Test Scenario
  1. Verify the presence of parameters in the body of the proof with Key Attestation.
Expected results
  1. The presence of parameters in the body of the proof with Key Attestation is as follows:
    1. (optionally) iss can be present.
    2. aud is present.
    3. iat is present.
    4. nonce is present.
WS_AP_MS_ProtocolMessages_053b
Objective

Verify that the Wallet sends a correctly formatted aud claim in the proof with Key Attestation in the Credential Request, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section F.1
  • [RFC7519] section 4
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential with Key Binding.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a valid signed proof with Key Attestation in the Credential Request.
  7. the proof with Key Attestation contains a aud claim.
Test Scenario
  1. Verify the aud claim in the proof with Key Attestation.
Expected results
  1. The value of the aud claim is a string.
WS_AP_MS_ProtocolMessages_053c
Objective

Verify that the Wallet sends a correctly formatted aud claim in the proof with Key Attestation in the Credential Request, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section F.1
  • [RFC7519] section 4
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential with Key Binding.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a valid signed proof with Key Attestation in the Credential Request.
  7. The proof with Key Attestation contains a syntactically correct aud claim.
Test Scenario
  1. Verify the aud claim in the proof with Key Attestation.
Expected results
  1. The value of the aud claim is equal to the Credential Issuer Identifier.
WS_AP_MS_ProtocolMessages_053d
Objective

Verify that the Wallet sends a correctly formatted nonce claim in the proof with Key Attestation in the Credential Request, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section F.1
  • [RFC7519] section 4
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential with Key Binding.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a valid signed proof with Key Attestation in the Credential Request.
  7. the proof with Key Attestation contains a nonce claim.
Test Scenario
  1. Verify the nonce claim in the proof with Key Attestation.
Expected results
  1. The value of the nonce claim is a string.

Security Mechanisms

Device Binding

WS_AP_SM_DeviceBinding_001a
Objective

Verify that the Wallet correctly serializes the Client Attestation as a signed JWT to authenticate at the PAR Endpoint of the selected Authorization Server, when using Pushed Authentication Requests in the Authorization Code Flow for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4, E
  • [IETF draft-attestation-based-client-auth] section 5.1
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. Wallet send an HTTP POST Request for a Pushed Authorization Request to the PAR Endpoint of the Authorization Server.
  5. The HTTP Request to the PAR Endpoint of the Authorization Server contains a syntactically correct OAuth-Client-Attestation HTTP header.
Test Scenario
  1. For the value of the OAuth-Client-Attestation HTTP Header in the HTTP request, perform all Shared_JWT_JWE test cases.
Expected results
  1. All test cases pass.
WS_AP_SM_DeviceBinding_001b
Objective

Verify that the Wallet correctly serializes the Client Attestation Proof of Possession as a signed JWT to authenticate at the PAR Endpoint of the Authorization Server, when using Pushed Authentication Requests in the Authorization Code Flow for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4, E
  • [IETF draft-attestation-based-client-auth] section 5.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. Wallet send an HTTP POST Request for a Pushed Authorization Request to the PAR Endpoint of the selected Authorization Server.
  5. The HTTP Request to the PAR Endpoint of the Authorization Server contains a syntactically correct OAuth-Client-Attestation-PoP HTTP Header.
Test Scenario
  1. For the value of the OAuth-Client-Attestation-PoP HTTP Header in the HTTP request, perform all Shared_JWT_JWE test cases.
Expected results
  1. All test cases pass.
WS_AP_SM_DeviceBinding_002a
Objective

Verify that the Wallet Provider uses an acceptable signature algorithm for signing the Client Attestation used by the Wallet to authenticate at the PAR Endpoint of the Authorization Server, when using Pushed Authentication Requests in the Authorization Code Flow for issuance.

References
  • [CIR 2024/2979 amended] annex Ia, Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4, E
  • [IETF draft-attestation-based-client-auth] section 5.1
  • [ECCG ACM] section 5.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. Wallet send an HTTP POST Request for a Pushed Authorization Request to the PAR Endpoint of the selected Authorization Server.
  5. The HTTP Request to the PAR Endpoint of the Authorization Server contains a syntactically correct OAuth-Client-Attestation HTTP header.
  6. The Client Attestation used by the Wallet to authenticate to the PAR Endpoint is a correctly serialized signed JWT.
Test Scenario
  1. Verify the signature algorithm (alg in protected header) used for signing the Client Attestation.
Expected results
  1. The signature algorithm in alg:
    1. is on the list of acceptable algorithms [ECCG ACM], and
    2. is one of ES256, ES384, or ES512.
WS_AP_SM_DeviceBinding_002b
Objective

Verify that the Wallet Provider correctly signs the Client Attestation used by the Wallet to authenticate at the PAR Endpoint of the Authorization Server, when using Pushed Authentication Requests in the Authorization Code Flow for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3, 4.4.1
  • [OpenID4VCI] section 5.1.4, E
  • [IETF draft-attestation-based-client-auth] section 5.1
  • [ECCG ACM] section 5.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. Wallet send an HTTP POST Request for a Pushed Authorization Request to the PAR Endpoint of the selected Authorization Server.
  5. The HTTP Request to the PAR Endpoint of the Authorization Server contains a syntactically correct OAuth-Client-Attestation HTTP header.
  6. The Client Attestation used by the Wallet to authenticate to the PAR Endpoint is a correctly serialized signed JWT.
  7. The Client Attestation uses an acceptable signature algorithm.
Test Scenario
  1. Verify the signature of the Client Attestation, using the public key identified using the x5c JOSE header.
Expected results
  1. The signature is valid.
WS_AP_SM_DeviceBinding_003a
Objective

Verify that the Wallet uses an acceptable signature algorithm for signing the Client Attestation Proof of Possession used by the Wallet to authenticate at the PAR Endpoint of the Authorization Server, when using Pushed Authentication Requests in the Authorization Code Flow for issuance.

References
  • [CIR 2024/2979 amended] annex Ia, Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4, E
  • [IETF draft-attestation-based-client-auth] section 5.2
  • [ECCG ACM] section 5.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. Wallet send an HTTP POST Request for a Pushed Authorization Request to the PAR Endpoint of the selected Authorization Server.
  5. The HTTP Request to the PAR Endpoint of the Authorization Server contains a syntactically correct OAuth-Client-Attestation-PoP HTTP header.
  6. The Client Attestation Proof of Possession used to authenticate to the PAR Endpoint is a correctly serialized signed JWT.
Test Scenario
  1. Verify the signature algorithm (alg in protected header) used for signing the Client Attestation Proof of Possession.
Expected results
  1. The signature algorithm in alg:
    1. is on the list of acceptable algorithms [ECCG ACM], and
    2. is one of ES256, ES384, or ES512.
WS_AP_SM_DeviceBinding_003b
Objective

Verify that the Wallet correctly signs the Client Attestation Proof of Possession used to authenticate at the PAR Endpoint of the Authorization Server, when using Pushed Authentication Requests in the Authorization Code Flow for issuance.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.4
  • [HAIP] section 4.3
  • [OpenID4VCI] section 5.1.4, E
  • [IETF draft-attestation-based-client-auth] section 5.1
  • [ECCG ACM] section 5.2
Profile applicability

None

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential Issuance using the Authorization Code Flow.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata.
  4. Wallet send an HTTP POST Request for a Pushed Authorization Request to the PAR Endpoint of the selected Authorization Server.
  5. The HTTP Request to the PAR Endpoint of the Authorization Server contains a syntactically correct OAuth-Client-Attestation-PoP HTTP header.
  6. The Client Attestation Proof of Possession used to authenticate to the PAR Endpoint is a correctly serialized signed JWT.
  7. The Client Attestation Proof of Possession uses an acceptable signature algorithm.
Test Scenario
  1. Verify the signature of the Client Attestation Proof of Possession, using the public key from the cnf claim in the Client Attestation.
Expected results
  1. The signature is valid.
WS_AP_SM_DeviceBinding_010a
Objective

Verify that the Wallet sends a correctly serialized JWT as proof with Key Attestation in the Credential Request to the Credential Endpoint of a Credential Issuer, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section 8.2, F.1
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential with Key Binding.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a syntactically correct proofs parameter in the Credential Request.
  7. Wallet send a JWT as value of the jwt property in the proofs parameter of the Credential Request.
Test Scenario
  1. Perform all Shared_JWT_JWS test cases on the value of the jwt property of the proofs parameter in the Credential Request.
Expected results
  1. All test cases pass.
WS_AP_SM_DeviceBinding_010b
Objective

Verify that the Wallet uses an acceptable algorithm for signing the proof with Key Attestation in the Credential Request to the Credential Endpoint of a Credential Issuer, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ia, Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section 8.2, F.1
  • [ECCG ACM] section 5.2
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

Credential with Key Binding.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a syntactically correct proofs parameter in the Credential Request.
  7. Wallet send a correctly serialized JWT as proof with Key Attestation in the Credential Request.
Test Scenario
  1. Verify the signature algorithm (alg in protected header) used for signing the proof with Key Attestation.
Expected results
  1. The signature algorithm in alg:
    1. is on the list of acceptable algorithms [ECCG ACM], and
    2. is one of ES256, ES384, or ES512.
Comments

TODO consider proof_signing_alg_values_supported as well!

WS_AP_SM_DeviceBinding_010c
Objective

Verify that the Wallet uses a valid signature value for signing the proof with Key Attestation in the Credential Request to the Credential Endpoint of a Credential Issuer, when the jwt Proof Type is used.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section 8.2, F.1
  • [ECCG ACM] section 5.2
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_generic | EUDI_required

Technology

Credential with Key Binding.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a syntactically correct proofs parameter in the Credential Request.
  7. Wallet send a JWT as value of the jwt property in the proofs parameter of the Credential Request.
  8. The proof with Key Attestation uses an acceptable signature algorithm.
Test Scenario
  1. Verify the signature value of the proof with Key Attestation, using the public key in the first element in attested_keys in key_attestation.
Expected results
  1. The signature is valid.
WS_AP_SM_DeviceBinding_011a
Objective

Verify that the Wallet Provider signs the Key Attestation using an acceptable signature algorithm, when the Wallet uses the jwt Proof Type.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section F.1
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

Credential with Key Binding.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a syntactically correct proofs parameter in the Credential Request.
  7. Wallet send a valid signed JWT as value of the jwt property in the proofs parameter of the Credential Request.
Test Scenario
  1. Verify the signature algorithm (alg in protected header) used for signing the Key Attestation.
Expected results
  1. The signature algorithm in alg:
    1. is on the list of acceptable algorithms [ECCG ACM], and
    2. is one of ES256, ES384, or ES512.
WS_AP_SM_DeviceBinding_011b
Objective

Verify that the Wallet Provider signs the Key Attestation with a valid signature value, when the Wallet uses the jwt Proof Type.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section F.1
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

Credential with Key Binding.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  4. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  5. Wallet send a syntactically correct Credential Request to the Credential Endpoint of the Credential Issuer.
  6. Wallet send a syntactically correct proofs parameter in the Credential Request.
  7. Wallet send a valid signed JWT as value of the jwt property in the proofs parameter of the Credential Request.
  8. The Key Attestation in the jwt proof type is signed using an acceptable signature algorithm.
Test Scenario
  1. Verify the signature value of the Key Attestation, using the public key in the x5c JOSE header.
Expected results
  1. The signature is valid.
WS_AP_SM_DeviceBinding_012a
Objective

Verify that the Wallet uses the nonce from the Nonce Endpoint of the Credential Issuer to include a nonce in the proof of Key Attestation, when the Wallet uses the jwt Proof Type.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.2
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section 7, 8.2, F.1
Profile applicability

Wallet uses the jwt proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology
Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata, including the nonce_endpoint of the Credential Issuer.
  4. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  5. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  6. Wallet successfully obtained a value in c_nonce in the Nonce Response, by making a Nonce Request to the Nonce Endpoint of the Credential Issuer.
  7. Wallet send a valid and trusted signed JWT as proof of Key Attestation, with the Credential Request.
  8. Wallet send a syntactically correct nonce in the proof of Key Attestation.
Test Scenario
  1. Verify the nonce value in the proof of Key Attestation.
Expected results
  1. The value of the nonce in the signed JWT that makes the proof of Key Attestation, is equal to the value of the c_nonce provided in the Nonce Response from the Nonce Endpoint.
WS_AP_SM_DeviceBinding_013a
Objective

Verify that the Wallet uses the nonce from the Nonce Endpoint of the Credential Issuer to include a nonce in the Key Attestation, when the Wallet uses the attestation Proof Type.

References
  • [CIR 2024/2979 amended] annex Ib
  • [ETSI TS 119 472-3] section 4.6.1.3
  • [HAIP] section 4.5.1
  • [OpenID4VCI] section 7, 8.2, F.3
Profile applicability

Wallet uses the attestation proof type to convey a key attestation in Credential Requests.

EUDI-wallet relevancy

EUDI_specific | EUDI_required

Technology

Credential with Key Binding.

Preconditions
  1. Wallet is set to 'default_configuration_1'
  2. Wallet started engagement with Credential Issuer.
  3. Wallet successfully obtained Credential Issuer Metadata, including the nonce_endpoint of the Credential Issuer.
  4. Wallet successfully authenticated to the (Authorization Server of the) Credential Issuer.
  5. Wallet successfully obtained an Access Token from the Token Endpoint of the (Authorization Server of the) Credential Issuer.
  6. Wallet successfully obtained a value in c_nonce in the Nonce Response, by making a Nonce Request to the Nonce Endpoint of the Credential Issuer.
  7. Wallet send a valid and trusted signed attestation as Key Attestation, with the Credential Request.
  8. Wallet send a syntactically correct nonce in the Key Attestation.
Test Scenario
  1. Verify the nonce value in the Key Attestation.
Expected results
  1. The value of the nonce in the signed attestation that makes the Key Attestation, is equal to the value of the c_nonce provided in the Nonce Response from the Nonce Endpoint.