Challenge request

The APP can request the PKSA to sign a challenge.

Before sending its request, the APP must create a "challenge request data" object (challenge_req_data) it will send to the PKSA

The structure of the challenge_req_data is:

challenge_req_data

{
    key_type: string
    challenge: string
    decrypt: boolean = false // protocol >= 1
    nonce: number
}

Properties

• key_type: the key type required to sign the transactions. It can be one of posting|active|memo.

• challenge: a string to be encrypted or decrypted

• decrypt: (optional - default value is false) indicates if the passed challenge must be encrypted (decrypt=false) or decrypted (decrypt=true) before being returned by the PKSA

• nonce: current UNIX time in ms (Date.now() in JavaScript). If a transaction request ever fails, do NOT reuse the challenge_req_data object before first updating the nonce!

The APP must then encrypt the challenge_req_data object using the encryption key previously shared with the PKSA (auth_key). By encrypting the sign_data object, the HAS will be unaware of what's going on between the app and the PKSA and unable to tamper with the challenge request process.

Finally, the APP sends its request to the HAS using the following message:

challenge_req

{ 
    cmd: "challenge_req" 
    account: string
    data: string
    token: string // DEPRECATED - protocol < 1 only    
}

Properties

• account: the Hive account name

• data: the Base64 representation of an encrypted challenge_req_data object

• token: the authentication token - DEPRECATED since protocol V1

The HAS will reply with a challenge_wait message:

challenge_wait

{
    cmd: "challenge_wait"
    uuid: string
    expire: number
}

Properties

• uuid: a unique identifier given by the HAS to the request

• expire: UNIX timestamp when the request will expire