Challenge approval

If the user approves the challenge request with its PKSA, the latest will send a challenge_ack message to the HAS with an access token and its expiration.
When the HAS will receive the user approval from its PKSA, it will forward it to the APP which will receive the following message:
challenge_ack
{
    cmd: "auth_ack",
    uuid: string,
    data: string
}
Properties
uuid: the request identifier
data: challenge_ack_data encrypted with the auth_key and converted to Base64
The APP must validate the received uuid against the request ID (uuid) that it received from the HAS in the challenge_wait message and ignore the challenge_ack message if they don't match.
The APP must decrypt the challenge_ack_data object using the encryption key previously shared with the PKSA (auth_key). If the APP cannot decrypt and parse challenge_ack_data, the APP must ignore the challenge_ack message.
This challenge_ack_data encryption/decryption process has been put in place to ensure that a malicious actor operating a HAS cannot bypass the PKSA to approve a challenge request.
As the encryption key has been provided offline to the PKSA, the HAS has no access to it and is therefore unable to decrypt, tamper then (re-)encrypt any data exchanged between the APP and the PKSA.
The structure of the challenge_ack_data is:
challenge_ack_data
{
    pubkey: string,
    challenge: string
}
Properties
pubkey: the account public key
challenge: the signed challenge

Feedback to user

Challenge refusal

Last modified 1yr ago