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 if the Device Integrity Service is available.

Checks whether the device meets the minimum security requirements.

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 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"
}

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 key generation 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.

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.

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 Provider Backend in order to register the Wallet Instance identified with 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. 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.

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 checks if a Cryptographic Hardware Key exists and generates an ephemeral asymmetric key pair. The Wallet Instance also:

MUST ensure that Cryptographic Hardware Keys exist. If they do not exist, it is necessary to reinitialize the Wallet.

MUST generates an ephemeral asymmetric key pair whose public key will be linked with the Wallet Attestation.

MUST check if Wallet Provider is part of the federation and obtain its metadata.

Steps 4-6: The Wallet Instance solicits a one-time "challenge" from 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 backend MUST produce the "nonce" 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"
}

Step 7: The Wallet Instance performs the following actions:

Creates a client_data, a JSON structure that includes the challenge and the thumbprint of ephemeral public jwk.

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

Below a non-normative example of the client_data.

{
  "challenge": "0fe3cbe0-646d-44b5-8808-917dd5391bd9",
  "jwk_thumbprint": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"
}

Steps 8-10: The Wallet Instance takes the following steps:

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

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

It receives a signed integrity_assertion 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, and cnf, and is signed using the private key of the initially generated ephemeral key pair.

Submits the Wallet Attestation Request to the token endpoint of the Wallet Provider Backend.

Below an 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"]
      },
    },
  },
  "iat": 1686645115,
  "exp": 1686652315
}

The Wallet Instance MUST do an HTTP request to the Wallet Provider's token endpoint, using the method POST.

The token endpoint (as defined in RFC 7523 section 4) requires the following parameters encoded in application/x-www-form-urlencoded format:

grant_type set to urn:ietf:params:oauth:grant-type:jwt-bearer;
assertion containing the signed JWT of the Wallet Attestation Request.

POST /token HTTP/1.1
Host: wallet-provider.example.org
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6ImtoakZWTE9nRjNHeG...

Steps 13-17: The Wallet Provider Backend assesses the Wallet Attestation Request and issues a Wallet Attestation, if the requirements described below are satisfied:

It MUST check the Wallet Attestation Request contains all the defined HTTP Request header parameters according to Table of the Wallet Attestation Request Header.

It MUST verify that the signature of the received Wallet Attestation Request is valid and associated with public jwk.

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

It MUST check that there is a Wallet Instance registered with that hardware_key_tag and that it is still valid.

It MUST reconstruct the client_data via the challenge and the jwk public key, to validate hardware_signature via the Cryptographic Hardware Key public key registered and associated with the Wallet Instance.

It MUST validate the integrity_assertion as defined by the device manufacturers' guidelines. The list of checks that the Wallet Provider MUST perform are defined by the operating system manufacturers documentation.

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

It MUST check that the URL in iss parameter is equal to the URL identifier of Wallet Provider.

If all checks are passed, Wallet Provider issues a Wallet Attestation with an expiration limited to 24 hours.

Below an 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": "eudiw:",
  "response_types_supported": [
    "vp_token"
  ],
  "response_modes_supported": [
    "form_post.jwt"
  ],
  "vp_formats_supported": {
      "vc+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: The response is returned by the Wallet Provider. If successful, the HTTP response code MUST be set with the value 200 OK and contain the Wallet Attestation signed by the Wallet Provider. The Wallet Instance therefore performs security, integrity and trust verification about 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 ...

Wallet Attestation Request¶

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

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:

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.

Wallet Attestation¶

The JOSE header of the Wallet Attestation JWT MUST contain:

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 3.2.1. Trust Chain Header Parameter.

The body of the Wallet Attestation JWT MUST contain:

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 (Universal Link).
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 JWS 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 Instance Lifecycle¶

The ability of the Wallet Instance to obtain a Wallet Attestation is bound to its current state. The Wallet Instance assesses its current state based on the Credentials stored locally and the Wallet Attestation issued by the Wallet Provider.

The lifecycle of a Wallet Instance encompasses all the potential states it can configure, along with the transitions from one state to another. This lifecycle is depicted in the diagram below:

A Wallet Instance SHOULD obtain a Wallet Attestation if it's in either Installed, Operational or Valid state; that implies that a Deactivated Wallet Instance cannot obtain a Wallet Attestation hence it cannot interact with other entities of the ecosystem, such as PID/(Q)EAA Providers and Relying Parties.

States¶

State	Description
Installed	The User has installed the Wallet Solution on the device.
Operational	The Wallet Instance has been verified and the Wallet Hardware Key has been registered; no valid PID is present in the storage.
Valid	A valid PID is present in the storage.
Deactivated	The Wallet Instance has been revoked and its Wallet Hardware Key has been marked as not usable.

Transitions¶

Transition	Description
install	The User performs a fresh installation or restores the initial state of the Wallet Instance on the device.
verify	The Wallet Instance has been verified by the Wallet Provider and its Wallet Hardware Key has been registered.
validate	The Wallet Instance obtains a valid PID.
invalidate	The PID expires or gets revoked.
revoke	The Wallet Provider marks the Wallet Instance as not usable.
uninstall	The User removes the Wallet Instance from the device.

Revocations¶

As mentioned in the Wallet Instance initialization and registration section above, a Wallet Instance is bound to a Wallet Hardware Key and it's uniquely identified by it. The Wallet Instance SHOULD send its public Wallet Hardware Key with the Wallet Provider, thus the Wallet Provider MUST identify a Wallet Instance by its Wallet Hardware Key.

When a Wallet Instance is not usable anymore, the Wallet Provider MUST revoke it. The revocation process is a unilateral action taken by the Wallet Provider, and it MUST be performed when the Wallet Instance is in the Operational or Valid state. A Wallet Instance becomes unusable for several reasons, such as: the User requests the revocation, the Wallet Provider detects a security issue, or the Wallet Instance is no longer compliant with the Wallet Provider's security requirements.

The details of the revocation mechanism used by the Wallet Provider as well as the data model for maintaining the Wallet Instance references is delegated to the Wallet Provider's implementation.

According to ARF, Section 6.5.4 and more specifically in Topic 38 the Wallet Instance can be revoked by the following entities:

Its owner, the User

Wallet Provider

PID Provider

During the Wallet Instance initialization and registration phase the Wallet Provider MAY associate the Wallet Instance with a specific User, subject to obtaining the User's consent. The Wallet Provider MUST evaluate the operating system and general technical capabilities of the device to check compliance with the technical and security requirements and to produce the Wallet Instance metadata. When the User consents to being linked with the Wallet Instance, they gain the ability to directly request Wallet revocation from the Wallet Provider, and it also allows the Wallet Provider to revoke the Wallet Instance associated with that User.

Regarding the reasons for revoking a Wallet Instance, the following scenarios may occur:

The smartphone is lost;
The smartphone has been compromised (e.g., a malicious actor gains control of the smartphone);
The smartphone has been reset to factory settings;
Any other scenarios where the User loses the control of the Wallet Instance.

If any of the previous scenarios occur, the Wallet Instance MUST be revoked. To allow the User to revoke the Wallet Instance, the Wallet Provider (WP) MUST offer a remote service, such as a web page, where the User can authenticate and request the revocation of a previously activated Wallet Instance.