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.

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.

For clarity, transaction refusal is not depicted in the above diagram. The flow would be the same but with a sign_nack message.