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 valid auth_token.
the HAS checks the auth_token and provides the APP with a request identifier (uuid) and its expiration time (expire) in a challenge_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 PKSA
the PKSA prompts the user to approve or reject the challenge
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)
the PKSA signs the challenge and sends a challenge_ack to the HAS
the HAS forwards the challenge_ack message to the APP.
Last modified 22d ago