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.