9.1.4.2.2. Wallet Instance Attestation Issuance

This section describes how the Wallet Provider issues a Wallet Instance Attestation.

Fig. 9.4 Sequence Diagram for Wallet Instance Attestation acquisition.

Step 1: The User initiates a new operation that necessitates the acquisition of a Wallet Instance Attestation.

Steps 2-3: The Wallet Instance MUST:

1. Verify the existence of Cryptographic Hardware Keys. If none exist, Wallet Instance re-initialization is required (WP_140a).

2. Generate an ephemeral asymmetric key pair for Wallet Instance Attestation (ephemeral_key_pub, ephemeral_key_priv), linking the public key to the attestation (WP_026).

3. Verify the Wallet Provider's federation membership and retrieve its metadata (WP_023).

Steps 4-6 (Nonce Retrieval): The Wallet Instance requests a nonce value from the Wallet Solution Nonce Endpoint of the Wallet Provider Backend (WP_140b). The nonce is required to be unpredictable and serves as the main defense against replay attacks.

The nonce MUST ensure single-use within a predetermined time frame.

Upon a successful request, the Wallet Provider generates and returns the nonce value to the Wallet Instance.

Step 7: The Wallet Instance performs the following actions (WP_140c):

• Creates client_data, a JSON object that includes the nonce and the thumbprint of ephemeral_key_pub JWK.

• Computes client_data_hash by applying the SHA256 algorithm to the client_data.

Below is a non-normative example of the client_data JSON object.

{
  "nonce": "i4ThI2Jhbu81i8mqyWEuDG5t",
  "jwk_thumbprint": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"
}

Steps 8-10: The Wallet Instance:

• produces an hardware_signature value by signing the client_data_hash with the Wallet Hardware's private key, serving as a proof of possession for the Cryptographic Hardware Keys (WP_140d).

• requests the Device Integrity Service to create an integrity_assertion value for Wallet Instance Attestation linked to the client_data_hash.

• receives a signed integrity_assertion value for Wallet Instance Attestation from the Device Integrity Service, authenticated by the OEM (WP_140e).

Note

integrity_assertion is a custom payload generated by Device Integrity Service, signed by device OEM and encoded in base64 to have uniformity between different devices.

Steps 11-12 (Wallet Instance Attestation Issuance Request): The Wallet Instance:

• Constructs the Wallet Instance Attestation Request in the form of a JWT. This JWT includes the integrity_assertion, hardware_signature, nonce, hardware_key_tag, intended_issuer, cnf, platform, wallet_solution_id, wallet_solution_version and, when reusing a status list entry, status_list_idx (see Table of the Wallet Instance Attestation Request Body and Per-Issuer Status Entry Reuse). It is signed using the private key of the initially generated ephemeral key pair (WP_140–141).

• Submits the Wallet Instance Attestation Request to the Wallet Instance Attestation Issuance Endpoint of the Wallet Provider Backend.

The Wallet Instance MUST send the signed Wallet Instance Attestation Request JWT as an assertion parameter in the body of an HTTP request to the Wallet Provider's Wallet Instance Attestation Issuance Endpoint (WP_142).

Steps 13-17: The Wallet Provider Backend evaluates the Wallet Instance Attestation Request and MUST perform the following checks (WP_143):

1. The request MUST include all required HTTP header parameters as defined in Wallet Instance Attestation Issuance Request (WP_143a).

2. The signature of the Wallet Instance Attestation Request MUST be valid and verifiable using the provided jwk (WP_143b).

3. The nonce value MUST have been generated by the Wallet Provider and not previously used (WP_143c).

4. A valid and currently registered Wallet Instance associated with the provided hardware_key_tag MUST exist (WP_143d).

5. The client_data MUST be reconstructed using the nonce and the jwk public key. The hardware_signature parameter value is then validated using the registered Cryptographic Hardware Key's public key associated with the Wallet Instance (WP_143e).

6. The integrity_assertion MUST be validated according to the device manufacturer's guidelines. The specific checks performed by the Wallet Provider are detailed in the operating system manufacturer's documentation (WP_143f).

7. The device in use MUST be free of known security flaws and meet the minimum security requirements defined by the Wallet Provider.

8. The URL in the iss parameter MUST match the Wallet Provider's URL identifier (WP_143g).

9. The Wallet Provider MUST apply Per-Issuer Status Entry Reuse.

Upon successful completion of all checks, the Wallet Provider issues a Wallet Instance Attestation that meets the Wallet Instance Attestation lifetime (WP_028, WP_144).

Step 18 (Wallet Instance Attestation Issuance Response): Upon successful completion, the Wallet Provider MUST return a confirmation response using status code 200 and Content-Type application/json, containing the Wallet Instance Attestation signed by the Wallet Provider. The Wallet provider MUST return the Wallet Instance Attestation in JWT format. The Wallet Instance will then perform security and integrity verification of the Wallet Instance Attestation received in addition to trust verification of its Issuer (WP_030–031).

Below is a non-normative example of the response.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "wallet_instance_attestation": "omppc3N1ZXJBdXRohEOhASaiBE...dElEAnFlbGVtZW50SWRl"
}

9.1.4.2.2.1. Per-Issuer Status Entry Reuse

The Wallet Provider MUST use the per-issuer reuse option of Section 2.5.1 of EUDI-TS 3 for the client_status.status entry of each Wallet Instance Attestation.

The Wallet Instance MUST keep the status list index assigned to it for each PID Provider or Attestation Provider.

The Wallet Instance Attestation Request MUST include intended_issuer.

When the Wallet Instance requests a Wallet Instance Attestation for a PID Provider or Attestation Provider for which it already holds an index, the request MUST include status_list_idx set to that index.

When the Wallet Instance requests a Wallet Instance Attestation for a PID Provider or Attestation Provider for which it holds no index, the request MUST omit status_list_idx.

When status_list_idx is present, the Wallet Provider MUST verify that the Wallet Instance is entitled to that index for intended_issuer before issuing a Wallet Instance Attestation that reuses it. The Wallet Provider MUST reject the request when the Wallet Instance is not entitled to that index.

The Wallet Provider MUST NOT reuse the same status list entry for Wallet Instance Attestations that the same Wallet Instance presents to different PID Providers or Attestation Providers.

When status_list_idx is absent, the Wallet Provider MUST assign a new status list entry for that Wallet Instance and intended_issuer.

The Wallet Provider MUST document the use of this option in its privacy policy.