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_reqcommand to the HAS with a valid
- 2.the HAS provides the APP with a request identifier (
uuid) and its expiration time (
expire) in a
- 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_reqcommand 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_ackto the HAS
- 8.the HAS forwards the
challenge_ackmessage to the APP.
For clarity, transaction refusal is not depicted in the above diagram. The flow would be the same but with a