# Challenge

Sometimes, an **APP** may want to validate an account by asking it to sign a predefined text string (challenge) with one of its keys.

This can be useful if the **APP** uses a front-end/back-end infrastructure. The **APP** front-end asks the **PKSA** to sign a message with one of the account's keys, then send it to its back-end when it makes API calls related to the account. The back-end can then validate the signed challenge against the account public key.

![](https://1669603073-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFAr86K7oT03KsmxlrwVj%2Fuploads%2FDy4zElJ41redMylRJZoB%2Fimage.png?alt=media\&token=efeda82e-269b-4d50-b428-7a32dd79efcc)

1. the **APP** sends a `challenge_req` command to the **HAS** with a valid `auth_token`.
2. the **HAS** provides the **APP** with a request identifier (`uuid`) and its expiration time (`expire`) in a `challenge_wait` message.
3. \[Optional] the **APP** shows information about the pending request to the user. It may also ask them to (re)start their **PKSA** to approve the challenge signing within the allowed delay.\
   **Note:** the **PKSA** can be started before or after the challenge request is issued. It doesn't matter.
4. the **HAS** then forwards the `challenge_req` command to the **PKSA**
5. the **PKSA** checks if it can decrypt the payload and prompts the user to approve or reject the challenge
6. the user approves or rejects the challenge.
7. the **PKSA** signs the challenge and sends a `challenge_ack` to the **HAS**
8. the **HAS** forwards the `challenge_ack` message to the **APP**.

{% hint style="info" %}
*For clarity, transaction refusal is not depicted in the above diagram.* The flow would be the same but with a `sign_nack` message.
{% endhint %}