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 validauth_token
. - 2.the HAS checks the
auth_token
and provides the APP with a request identifier (uuid
) and its expiration time (expire
) in achallenge_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 prompts the user to approve or reject the challenge
- 6.the user approves the challenge. (For clarity, challenge refusal is not depicted in the above diagram. The flow would be the same but with a
challenge_nack
message) - 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.
Last modified 22d ago