Wallet Attestation¶

Wallet Attestation contains information regarding the security level of the device hosting the Wallet Instance. It primarily certifies the authenticity, integrity, security, privacy, and trustworthiness of a particular Wallet Instance.

Requirements¶

The requirements for the Wallet Attestation are defined below:

The Wallet Attestation MUST contain a Wallet Instance public key.
The Wallet Attestation MUST use the signed JSON Web Token (JWT) format;
The Wallet Attestation MUST provide all the relevant information to attest to the integrity and security of the device where the Wallet Instance is installed.
The Wallet Attestation MUST be signed by the Wallet Provider that has authority over and is the owner of the Wallet Solution, as specified by the overseeing registration authority. This ensures that the Wallet Attestation uniquely links the Wallet Provider to this particular Wallet Instance.
The Wallet Provider MUST ensure the integrity, authenticity, and genuineness of the Wallet Instance, preventing any attempts at manipulation or falsification by unauthorized third parties. The Wallet Provider MUST also verify the Wallet Instance using the App Store vendor's API, such as the Play Integrity API for Android and DeviceCheck for iOS. These services are defined in this specification as Device Integrity Service (DIS).
The Wallet Attestation MUST have a mechanism in place for revoking the Wallet Instance, allowing the Wallet Provider to terminate service for a specific instance at any time.
The Wallet Attestation MUST be securely bound to the Wallet Instance's ephemeral public key.
The Wallet Attestation MAY be used multiple times during its validity period, allowing for repeated authentication and authorization without the need to request new attestations with each interaction.
The Wallet Attestation MUST be short-lived and MUST have an expiration date/time, after which it SHOULD no longer be considered valid.
The Wallet Attestation MUST NOT be issued by the Wallet Provider if the authenticity, integrity, and genuineness are not guaranteed. In this case, the Wallet Instance MUST be revoked.
Each Wallet Instance SHOULD be able to request multiple attestations with different ephemeral public keys associated with them. This requirement provides a privacy-preserving measure, as the public key MAY be used as a tracking tool during the presentation phase (see also the point listed below).
The Wallet Attestation MUST NOT contain any information that can be used to directly identify the User.
The Wallet Instance MUST secure a Wallet Attestation as a prerequisite for transitioning to the Operational state, as defined by ARF.
Private keys MUST be generated and stored in the WSCD using at least one of the approaches listed below:
- Local Internal WSCD: The WSCD relies entirely on the device's native cryptographic hardware, such as the Secure Enclave on iOS devices or the Hardware-Backed Keystore or Strongbox on Android devices.
- Local External WSCD: The WSCD is hardware external to the User's device, such as a smart card compliant with GlobalPlatform and supporting JavaCard.
- Remote WSCD: The WSCD utilizes a remote Hardware Security Module (HSM).
- Local Hybrid WSCD: The WSCD involves a pluggable internal hardware component within the User's device, such as an eUICC that adheres to GlobalPlatform standards and supports JavaCard.
- Remote Hybrid WSCD: The WSCD involves a local component mixed with a remote service.
The Wallet Provider MUST offer a set of services, exclusively available to its Wallet Solution instances, for the issuance of Wallet Attestations.

Warning

At the current stage, the implementation profile defined in this document supports only the Local Internal WSCD. Future versions of this specification MAY include other approaches depending on the required AAL.

Static Component View¶

The image illustrates the containment of Wallet Provider and Wallet Instances within the Wallet Solution, managed by the Wallet Provider.

Dynamic Component View¶

The Wallet Attestation acquisition flow can be divided into two main phases. The first phase involves device initialization and registration, which occurs only during the initial launch of the Wallet Instance (after installation). The second phase pertains to the actual acquisition of the Wallet Attestation.

Wallet Instance Initialization and Registration¶

The figure illustrates the sequence diagram for initializing a Wallet Instance, with the steps explained below.

Step 1: The User starts the Wallet Instance mobile app for the first time.

Step 2: The Wallet Instance:

Checks whether the device meets the minimum security requirements.

Checks if the Device Integrity Service is available.

Note

Federation Check: The Wallet Instance needs to check if the Wallet Provider is part of the Federation, obtaining its protocol-specific Metadata. A non-normative example of a response from the endpoint .well-known/openid-federation with the Entity Configuration and the Metadata of the Wallet Provider is represented within the section Wallet Provider metadata.

Steps 3-5: The Wallet Instance sends a request to the nonce endpoint of the Wallet Provider Backend and receives a one-time challenge. This "challenge" is a nonce, which MUST be unpredictable to serve as the main defense against replay attacks. The backend MUST generate the nonce value in a manner that ensures it is single-use and valid only within a specific time frame. This endpoint is compliant with the specification OAuth 2.0 Nonce Endpoint.

GET /nonce HTTP/1.1
Host: walletprovider.example.com

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

{
  "nonce": "d2JhY2NhbG91cmVqdWFuZGFt"
}

If any errors occur during the nonce generation, the Wallet Provider MUST return an error response as defined in RFC 6749#section-5.2. The response MUST use application/json as the content type and MUST include the following parameters:

error. The error code.

error_description. Text in human-readable form providing further details to clarify the nature of the error encountered.

The following table lists HTTP Status Codes and related error codes that MUST be supported for the error response:

HTTP Status Code	Error Code	Description
`500 Internal Server Error`	`server_error`	An internal server error occurred while processing the request.
`503 Service Unavailable`	`temporarily_unavailable`	Service unavailable. Please try again later.

Step 6: The Wallet Instance, through the operating system, creates a pair of Cryptographic Hardware Keys and stores the corresponding Cryptographic Hardware Key Tag in local storage once the following requirements are met:

It MUST ensure that Cryptographic Hardware Keys do not already exist. If they do exist and the Wallet is in the initialization phase, they MUST be deleted.

It MUST generate a pair of asymmetric Elliptic Curve keys (Cryptographic Hardware Keys) via a local WSCD.

It SHOULD obtain a unique identifier (Cryptographic Hardware Key Tag) for the generated Cryptographic Hardware Keys from the operating system. If the operating system permits specifying a tag during the creation of keys, then a random string for the Cryptographic Hardware Key Tag MUST be selected. This random value MUST be collision-resistant and unpredictable to ensure security. To achieve this, consider using a cryptographic hash function or a secure random number generator provided by the operating system or a reputable cryptographic library.

If the previous points are satisfied, it MUST store the Cryptographic Hardware Key Tag in local storage.

Note

WSCD: The Wallet Instance MAY use a local WSCD for cryptographic operations, including key generation, secure storage, and cryptographic processing, on devices that support this feature. On Android devices, Strongbox is RECOMMENDED; Trusted Execution Environment (TEE) MAY be used only when Strongbox is unavailable. For iOS devices, Secure Elements (SE) MUST be used. Given that each OEM offers a distinct SDK for accessing the local WSCD, the discussion hereafter will address this topic in a general context.

If the WSCD fails during any of these operations, for example due to hardware limitations, it will raise an error response to the Wallet Instance (e.g., see TEE Client API Errors). The Wallet Instance MUST handle these errors accordingly to ensure secure operation. Details on error handling are left to the Wallet Instance implementation.

Step 7: The Wallet Instance uses the Device Integrity Service, providing the "challenge" and the Cryptographic Hardware Key Tag to acquire the Key Attestation.

Note

Device Integrity Service: In this section, the Device Integrity Service is considered as it is provided by device manufacturers. This service allows the verification of a key being securely stored within the device's hardware through a signed object. Additionally, it offers verifiable proof that a specific Wallet Instance is authentic, unaltered, and in its original state using a specialized signed document made for this purpose.

The service also incorporates details in the signed object, such as the device type, model, app version, operating system version, bootloader status, and other relevant information to assess whether the device has been compromised. For Android, the DIS is represented by Key Attestation, a feature supported by StrongBox Keymaster, which is a physical HSM installed directly on the motherboard, and the TEE (Trusted Execution Environment), a secure area of the main processor. Key Attestation aims to provide a way to strongly determine if a key pair is hardware-backed, what the properties of the key are, and what constraints are applied to its usage. Developers can leverage its functionality through the Play Integrity API. For Apple devices, the DIS is represented by DeviceCheck, which provides a framework and server interface to manage device-specific data securely. DeviceCheck is used in combination with the Secure Enclave, a dedicated HSM integrated into Apple's SoCs. DeviceCheck can be used to attest to the integrity of the device, apps, and/or encryption keys generated on the device, ensuring they were created in a secure environment like Secure Enclave. Developers can leverage DeviceCheck functionality by using the framework itself. These services, specifically developed by the manufacturer, are integrated within the Android or iOS SDKs, eliminating the need for a predefined endpoint to access them. Additionally, as they are specifically developed for mobile architecture, they do not need to be registered as Federation Entities through national registration systems. Secure Enclave has been available on Apple devices since the iPhone 5s (2013). For Android devices, the inclusion of Strongbox Keymaster may vary by manufacturer, who decides whether to include it or not.

If any errors occur in any DIS process, such as device integrity verification, for example, due to an unavailable DIS, an internal error, or an invalid nonce in the integrity request, the DIS raises an error response (e.g., see Play Integrity API Errors). The Wallet Instance MUST process these errors accordingly. Details on error handling are left to the Wallet Instance implementation.

Step 8: The Device Integrity Service performs the following actions:

Creates a Key Attestation that is linked with the provided "challenge" and the public key of the Wallet Hardware.
Incorporates information pertaining to the device's security.
Uses an OEM private key to sign the Key Attestation, therefore verifieable with the related OEM certificate, confirming that the Cryptographic Hardware Keys are securely managed by the operating system.

Step 9: The Wallet Instance sends the challenge with Key Attestation and Cryptographic Hardware Key Tag to the wallet-instance endpoint of the Wallet Provider Backend to register the Wallet Instance identified by the Cryptographic Hardware Key public key.

In order to register the Wallet Instance, the request to the Wallet Provider MUST use the HTTP POST method. The parameters MUST be encoded using the application/json format and included in the message body. The following parameters MUST be provided:

Table 2 Wallet Instance registration http request parameters¶
Claim	Description	Reference
challenge	MUST be set to the challenge obtained from the Wallet Provider throught the `nonce` endpoint.	OAuth 2.0 Nonce Endpoint
key_attestation	It MUST be a `base64url` encoded Key Attestation obtained from the Device Integrity Service.
hardware_key_tag	It MUST be set with the unique identifier of the Cryptographic Hardware Keys and encoded in `base64url`.

Below is a non-normative example of the request.

POST /wallet-instance HTTP/1.1
Host: walletprovider.example.com
Content-Type: application/json

{
  "challenge": "0fe3cbe0-646d-44b5-8808-917dd5391bd9",
  "key_attestation": "o2NmbXRvYXBwbGUtYXBw... redacted",
  "hardware_key_tag": "WQhyDymFKsP95iFqpzdEDWW4l7aVna2Fn4JCeWHYtbU="
}

Note

It is not necessary to send the Wallet Hardware public key because it is already included in the key_attestation. As seen in the previous steps, the Device Integrity Service (DIS) creates a Key Attestation linked to the provided "challenge" and the public key of the Wallet Hardware. This process eliminates the need to send the Wallet Hardware public key directly, as it is already included in the key attestation. The hardware_key_tag serves as a reference or identifier for the corresponding Cryptographic Hardware key stored by the Wallet Provider. Therefore, the Wallet Provider can associate the received hardware_key_tag with the appropriate Cryptographic Hardware key in its storage.

Warning

During the registration phase of the Wallet Instance with the Wallet Provider it is also necessary to associate it with a specific user uniquely identifiable by the Wallet Provider. This association is at the discretion of the Wallet Provider and will not be addressed within these guidelines as each Wallet Provider may or may not have a user identification system already implemented.

Steps 10-12: The Wallet Provider validates the challenge and key_attestation signature, therefore:

It MUST verify that the challenge was generated by Wallet Provider and has not already been used.

It MUST validate the key_attestation as defined by the device manufacturers' guidelines.

It MUST verify that the device in use has no security flaws and reflects the minimum security requirements defined by the Wallet Provider.

If these checks are passed, it MUST register the Wallet Instance, keeping the Cryptographic Hardware Key Tag and all useful information related to the device.

It SHOULD associate the Wallet Instance with a specific User uniquely identified within the Wallet Provider's systems. This will be useful for the lifecycle of the Wallet Instance and for a future revocation.

Upon successful registration of the Wallet Instance, the Wallet Provider MUST respond with a status code set to 204 (No Content). Below is a non-normative example of the response.

HTTP/1.1 204 No content

If any errors occur during the Wallet Instance registration, the Wallet Provider MUST return an error response as defined in RFC 7231, with additional details available in RFC 7807. The response MUST use the content type set to application/json and MUST include the following parameters:

error. The error code.

error_description. Text in human-readable form providing further details to clarify the nature of the error encountered.

Below is a non-normative example of an error response:

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store

{
  "error": "forbidden",
  "error_description": "The provided challenge is invalid, expired, or already used."
}

The following table lists HTTP Status Codes and related error codes that MUST be supported for the error response, unless otherwise specified:

HTTP Status Code	Error Code	Description
`400 Bad Request`	`bad_request`	The request is malformed, missing required parameters, or includes invalid and unknown parameters.
`403 Forbidden`	`integrity_check_error`	The device does not meet the Wallet Provider’s minimum security requirements.
`403 Forbidden`	`invalid_request`	The provided challenge is invalid, expired, or already used.
`403 Forbidden`	`invalid_request`	The signature of the Key Attestation is invalid.
`422 Unprocessable Content` [OPTIONAL]	`validation_error`	The request does not adhere to the required format.
`500 Internal Server Error`	`server_error`	An internal server error occurred while processing the request.
`503 Service Unavailable`	`temporarily_unavailable`	Service unavailable. Please try again later.

Steps 13-14: The Wallet Instance has been initialized and becomes operational.

Note

Threat Model: while the registration endpoint does not necessitate any client authentication, it is safeguarded through the use of key_attestation. Proper validation of this attestation permits the registration of authentic and unaltered app instances. Any other claims submitted will not undergo validation, leading the endpoint to respond with an error. Additionally, the inclusion of a challenge helps prevent replay attacks. The authenticity of both the challenge and the hardware_key_tag is ensured by the signature found within the key_attestation.

Wallet Attestation Issuance¶

This section describes the Wallet Attestation format and how the Wallet Provider issues it.

The figure illustrates the sequence diagram for issuing a Wallet Attestation, with the steps explained below.

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

Steps 2-3: The Wallet Instance MUST:

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

Generate an ephemeral asymmetric key pair for Wallet Attestation, linking the public key to the attestation.

Verify the Wallet Provider's federation membership and retrieve its metadata.

Steps 4-6: The Wallet Instance solicits a one-time "challenge" from the nonce endpoint of the Wallet Provider Backend. This "challenge" takes the form of a nonce, which is required to be unpredictable and serves as the main defense against replay attacks. The nonce MUST be produced in a manner that ensures its single-use within a predetermined time frame.

GET /nonce HTTP/1.1
Host: walletprovider.example.com

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

{
  "nonce": "d2JhY2NhbG91cmVqdWFuZGFt"
}

If an error occurs during nonce generation, the Wallet Provider MUST return an error response (see Nonce Error Handling for details on possible errors).

Step 7: The Wallet Instance performs the following actions:

Creates client_data, a JSON object that includes the challenge and the thumbprint of ephemeral public 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.

{
  "challenge": "0fe3cbe0-646d-44b5-8808-917dd5391bd9",
  "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.

requests the Device Integrity Service to create an integrity_assertion value linked to the client_data_hash.

receives a signed integrity_assertion value from the Device Integrity Service, authenticated by the OEM.

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: The Wallet Instance:

Constructs the Wallet Attestation Request in the form of a JWT. This JWT includes the integrity_assertion, hardware_signature, challenge, hardware_key_tag, cnf and other configuration related parameters (see Table of the Wallet Attestation Request Body below) and is signed using the private key of the initially generated ephemeral key pair.

Submits the Wallet Attestation Request to the wallet-attestation endpoint of the Wallet Provider Backend.

Below is a non-normative example of the Wallet Attestation Request JWT without encoding and signature applied:

{
  "alg": "ES256",
  "kid": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
  "typ": "war+jwt"
}
.
{
  "iss": "https://wallet-provider.example.org/instance/vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
  "sub": "https://wallet-provider.example.org/",
  "challenge": "6ec69324-60a8-4e5b-a697-a766d85790ea",
  "hardware_signature": "KoZIhvcNAQcCoIAwgAIB...redacted",
  "integrity_assertion": "o2NmbXRvYXBwbGUtYXBwYX...redacted",
  "hardware_key_tag": "WQhyDymFKsP95iFqpzdEDWW4l7aVna2Fn4JCeWHYtbU=",
  "cnf": {
    "jwk": {
      "crv": "P-256",
      "kty": "EC",
      "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
      "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg"
    }
  },
  "vp_formats_supported": {
      "jwt_vc_json": {
        "alg_values_supported": ["ES256K", "ES384"]
      },
      "jwt_vp_json": {
        "alg_values_supported": ["ES256K", "EdDSA"]
      },
    },
  },
  authorization_endpoint": "https://wallet-solution.digital-strategy.europa.eu/authorization",
  "response_types_supported": [
    "vp_token"
  ],
  "response_modes_supported": [
    "form_post.jwt"
  ],
  "request_object_signing_alg_values_supported": [
    "ES256"
  ],
  "presentation_definition_uri_supported": false,
  "iat": 1686645115,
  "exp": 1686652315
}

The Wallet Instance MUST send an HTTP request to the Wallet Provider's wallet-attestation endpoint, using the POST method with Content-Type application/json. The request body MUST contain an assertion parameter whose value is the signed JWT of the Wallet Attestation Request.

POST /wallet-attestation HTTP/1.1
Host: wallet-provider.example.org
Content-Type: application/json

{
  "assertion": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImtoakZWTE9nRjNHeG..."
}

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

The request MUST include all required HTTP header parameters as defined in Table of the Wallet Attestation Request Header.

The signature of the Wallet Attestation Request MUST be valid and verifiable using the provided jwk.

The challenge value MUST have been generated by the Wallet Provider and not previously used.

A valid and currently registered Wallet Instance associated with the provided MUST exist.

The client_data MUST be reconstructed using the challenge 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.

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.

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

The URL in the iss parameter MUST match the Wallet Provider's URL identifier.

Upon successful completion of all checks, the Wallet Provider issues a Wallet Attestation valid for a maximum of 24 hours.

Below is a non-normative example of the Wallet Attestation without encoding and signature applied:

  {
  "alg": "ES256",
  "kid": "5t5YYpBhN-EgIEEI5iUzr6r0MR02LnVQ0OmekmNKcjY",
  "trust_chain": [
    "eyJhbGciOiJFUz...6S0A",
    "eyJhbGciOiJFUz...jJLA",
    "eyJhbGciOiJFUz...H9gw",
  ],
  "typ": "wallet-attestation+jwt",
}
.
{
  "iss": "https://wallet-provider.example.org",
  "sub": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
  "aal": "https://trust-list.eu/aal/high",
  "cnf":
  {
    "jwk":
    {
      "crv": "P-256",
      "kty": "EC",
      "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
      "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg"
    }
  },
  "authorization_endpoint": "https://wallet-solution.digital-strategy.europa.eu/authorization",
  "response_types_supported": [
    "vp_token"
  ],
  "response_modes_supported": [
    "form_post.jwt"
  ],
  "vp_formats_supported": {
      "dc+sd-jwt": {
          "sd-jwt_alg_values": [
              "ES256",
              "ES384"
          ]
      }
  },
  "request_object_signing_alg_values_supported": [
    "ES256"
  ],
  "presentation_definition_uri_supported": false,
  "iat": 1687281195,
  "exp": 1687288395
}

Step 18: Upon successful completion, the Wallet Provider MUST return an HTTP response with a status code of 200 OK, containing the Wallet Attestation signed by the Wallet Provider. The Wallet Instance will then perform security, integrity, and trust verification of the Wallet Attestation and its issuer.

Below is a non-normative example of the response.

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

eyJhbGciOiJFUzI1NiIsInR5cCI6IndhbGx ...

If any errors occur during the Wallet Attestation Request Verification, the Wallet Provider MUST return an error response as defined in RFC 7231 (additional details available in RFC 7807). The response MUST use the content type set to application/json and MUST include the following parameters:

error. The error code.

error_description. Text in human-readable form providing further details to clarify the nature of the error encountered.

Below is a non-normative example of an error response:

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store

{
  "error": "integrity_check_error",
  "error_description": "The device does not meet the Wallet Provider’s minimum security requirements."
}

The following table lists HTTP Status Codes and related error codes that MUST be supported for the error response, unless otherwise specified:

HTTP Status Code	Error Code	Description
`400 Bad Request`	`bad_request`	The request is malformed, missing required parameters (e.g., header parameters or integrity assertion), or includes invalid and unknown parameters.
`403 Forbidden`	`invalid_request`	The wallet instance was revoked.
`403 Forbidden`	`integrity_check_error`	The device does not meet the Wallet Provider’s minimum security requirements.
`403 Forbidden`	`invalid_request`	The signature of the Wallet Attestation Request is invalid or does not match the associated public key (JWK).
`403 Forbidden`	`invalid_request`	The integrity assertion validation failed; the integrity assertion is tampered with or improperly signed.
`403 Forbidden`	`invalid_request`	The provided challenge is invalid, expired, or already used.
`403 Forbidden`	`invalid_request`	The Proof of Possession (`hardware_signature`) is invalid.
`403 Forbidden`	`invalid_request`	The `iss` parameter does not match the Wallet Provider’s expected URL identifier.
`404 Not Found`	`not_found`	The Wallet Instance was not found.
`422 Unprocessable Content` [OPTIONAL]	`validation_error`	The request does not adhere to the required format.
`500 Internal Server Error`	`server_error`	An internal server error occurred while processing the request.
`503 Service Unavailable`	`temporarily_unavailable`	Service unavailable. Please try again later.

Wallet Attestation Request¶

The JOSE header of the Wallet Attestation Request JWT MUST contain the following parameters:

JOSE header	Description	Reference
alg	A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section Cryptographic Algorithms and MUST NOT be set to `none` or any symmetric algorithm (MAC) identifier.	RFC 7516#section-4.1.1.
kid	Unique identifier of the `jwk` used by the Wallet Provider to sign the Wallet Attestation, essential for matching the Wallet Provider's cryptographic public key needed for signature verification.	RFC 7638#section_3.
typ	It MUST be set to `var+jwt`

The body of the Wallet Attestation Request JWT MUST contain the following parameters:

Claim	Description	Reference
iss	Identifier of the Wallet Provider concatenated with thumbprint of the JWK in the `cnf` parameter.	RFC 9126 and RFC 7519.
aud	It MUST be set to the identifier of the Wallet Provider.	RFC 9126 and RFC 7519.
exp	UNIX Timestamp with the expiry time of the JWT.	RFC 9126 and RFC 7519.
iat	REQUIRED. UNIX Timestamp with the time of JWT issuance.	RFC 9126 and RFC 7519.
challenge	Challenge data obtained from `nonce` endpoint
hardware_signature	The signature of `client_data` obtained using Cryptographic Hardware Key base64 encoded.
integrity_assertion	The integrity assertion obtained from the Device Integrity Service with the holder binding of `client_data`.
hardware_key_tag	Unique identifier of the Cryptographic Hardware Keys
cnf	JSON object, containing the public part of an asymmetric key pair owned by the Wallet Instance.	RFC 7800
vp_formats_supported	JSON object with name/value pairs, identifying a Credential format supported by the Wallet.
authorization_endpoint	URL of the Wallet Authorization Endpoint, it can be a universal link or a custom url-scheme.
response_types_supported	JSON array containing a list of the OAuth 2.0 `response_type` values.
response_modes_supported	JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports.	RFC 8414
request_object_signing_alg_values_supported	JSON array containing a list of the signing algorithms (alg values) supported.
presentation_definition_uri_supported	Boolean value specifying whether the Wallet Instance supports the transfer of presentation_definition by reference. MUST be set to false.

Wallet Attestation¶

The JOSE header of the Wallet Attestation JWT MUST contain the following parameters:

JOSE header	Description	Reference
alg	A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section Cryptographic Algorithms and MUST NOT be set to `none` or any symmetric algorithm (MAC) identifier.	RFC 7516#section-4.1.1.
kid	Unique identifier of the `jwk` inside the `cnf` claim of Wallet Instance as base64url-encoded JWK Thumbprint value.	RFC 7638#section_3.
typ	It MUST be set to `wallet-attestation+jwt`	OPENID4VC-HAIP
trust_chain	Sequence of Entity Statements that composes the Trust Chain related to the Relying Party.	OID-FED Section 4.3 Trust Chain Header Parameter.

The body of the Wallet Attestation JWT MUST contain the following parameters:

Claim	Description	Reference
iss	Identifier of the Wallet Provider	RFC 9126 and RFC 7519.
sub	Identifier of the Wallet Instance which is the thumbprint of the Wallet Instance JWK contained in the `cnf` claim.	RFC 9126 and RFC 7519.
exp	UNIX Timestamp with the expiry time of the JWT.	RFC 9126 and RFC 7519.
iat	UNIX Timestamp with the time of JWT issuance.	RFC 9126 and RFC 7519.
cnf	JSON object, containing the public part of an asymmetric key pair owned by the Wallet Instance.	RFC 7800
aal	JSON String asserting the authentication level of the Wallet and the key as asserted in the cnf claim.
authorization_endpoint	URL of the Wallet Authorization Endpoint, it can be a universal link or a custom url-scheme.
response_types_supported	JSON array containing a list of the OAuth 2.0 `response_type` values.
response_modes_supported	JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports.	RFC 8414
vp_formats_supported	JSON object with name/value pairs, identifying a Credential format supported by the Wallet.
request_object_signing_alg_values_supported	JSON array containing a list of the signing algorithms (alg values) supported.
presentation_definition_uri_supported	Boolean value specifying whether the Wallet Instance supports the transfer of presentation_definition by reference. MUST be set to false.
client_id_schemes_supported	Array of JSON Strings containing the values of the Client Identifier schemes that the Wallet supports.	OpenID4VP