Authentication approval

If the user approves the authentication request with its PKSA, the latest will send an auth_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

auth_ack

{
    cmd: "auth_ack"
    uuid: string
    data: string
}

Properties

• uuid: the request identifier

• data: auth_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 auth_wait message and ignore the auth_ack message if they don't match.

The APP must decrypt the auth_ack_data object using the encryption key previously shared with the PKSA (auth_key). If the APP cannot decrypt and parse auth_ack_data, the APP must ignore the auth_ack message.

This auth_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 an authentication request.

As the encryption key has been provided off-line to the PKSA, it is unknown to the HAS, which therefore cannot decrypt, tamper then (re-)encrypt any data exchanged between the APP and the PKSA.

The structure of the auth_ack_data is:

auth_ack_data

{
    expire: number
    challenge_data: object = undefined
    token: string // DEPRECATED - protocol < 1.0 only    
}

Properties

• expire: UNIX timestamp when the authentication will expire

• challenge_data: optional - if the APP provided a challenge object with the auth_req sent to the PKSA, it contains a challenge_ack_data object (see Challenge approval).

• token: session token - Deprecated since protocol v1.0

The application should store the auth_key it used to authenticate. This auth_key can be used with each subsequent request. This saves the user from having to re-authenticate with that same PKSA until auth_key has expired.

It is up to the APP to reuse the auth_key for as long as it is valid or to shorten its life by reinitiating a new authentication process.

When the auth_key expires, any related transaction requests will be rejected.