Authentication approval

​
If the user approves the authentication request, the PKSA must:
create a new token with an expire value or reuse an existing one.
store the token, expire and key values locally.
create an "authentication approval data" object (auth_ack_data) that it will send to the APP
The structure of the auth_ack_data is:
auth_ack_data
{
    token: string, // protocol < 1.0 only
    expire: number,
    challenge: object = undefined
}
Properties
token: session token (we recommend using a UUID) - Deprecated since protocol v1.0
expire: UNIX timestamp when the authentication will expire
challenge: optional if the APP provided a challenge_data object with its auth_req_data, the PKSA must return a challenge_ack_data object (see Challenge approval ).
The PKSA must then encrypt the auth_ack_data object using the encryption key previously shared with the APP (auth_key).
Finally, the PKSA then inform the HAS of the user's approval by sending the following message:
auth_ack
{
    cmd: "auth_ack",
    uuid: string,
    data: string,
    pok: string
}
Properties
uuid: the request identifier
data: auth_ack_data encrypted with the auth_key and converted to Base64
pok: the uuid encrypted using the account private key and the HAS server public key (see Proof of Key)
The encryption of auth_ack_data is performed to ensure that a malicious actor operating a HAS cannot bypass the PKSA to approve an authentication request.
It will also make the HAS unaware of what's going on between the app and the PKSA and unable to tamper with the authentication request process.
Being the only one being able to decrypt the auth_ack.challenge using its encryption auth_key, the APP has 100% certainty that the encryption process was made by a PKSA which got the encryption auth_key from reading the off-band auth_req_payload.
​
Feedback to user
Authentication refusal
Last modified 6d ago