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.
the APP sends a
challenge_req
command to the HAS with a validauth_token
.the HAS provides the APP with a request identifier (
uuid
) and its expiration time (expire
) in achallenge_wait
message.[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.
the HAS then forwards the
challenge_req
command to the PKSAthe PKSA checks if it can decrypt the payload and prompts the user to approve or reject the challenge
the user approves or rejects the challenge.
the PKSA signs the challenge and sends a
challenge_ack
to the HASthe 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.
Last updated