既然應(yīng)用已經(jīng)驗(yàn)證在與正確的服務(wù)器通信并已被成功認(rèn)證， 那么用戶就可以開始發(fā)出服務(wù)請求了。 應(yīng)用必須確保傳輸?shù)臄?shù)據(jù)在傳輸過程中是安全且未被修改的。?
資金轉(zhuǎn)移請求會聯(lián)合使用密碼哈希與加密的方式來確保消息是難以理解的并且在傳輸階段是沒有經(jīng)過修改的。 雖然本節(jié)將會生成和介紹很多負(fù)載示例， 不過每個示例都會使用如下代碼定義的 JSON 負(fù)載結(jié)構(gòu)：
payload 屬性是請求體中唯一被加密的元素。 服務(wù)層要想正確解密負(fù)載， 就得要求應(yīng)用使用 Initialization Vector(IV) 來對數(shù)據(jù)進(jìn)行加密。 通常情況下， IV 會隨著被它加密的數(shù)據(jù)一起發(fā)送。 雖然這么做似乎降低了消息的安全性， 但實(shí)際上并不會， 因?yàn)閱螒{ IV 本身不足以解密消息。 當(dāng)服務(wù)層解密負(fù)載后， 它會使用同樣的預(yù)定義的負(fù)載屬性集合來生成 MAC（消息認(rèn)證碼， Message Authentication Code)， 然后將其與進(jìn)來的請求中的 MAC 進(jìn)行對比以驗(yàn)證消息的完整性。 如果消息在傳輸過程中被修改， 那么代碼就不會匹配， 被修改的消息則會產(chǎn)生錯誤
圖 6-2 概覽了請求、響應(yīng)交易中發(fā)生的步驟， 以及在交易每一端的加密與解密過程中使用的組件。 交易雙方都知道用于加密與解密的重要值和 MAC 算法。 此外， 請求體部分與之前示例中定義的 JSON 負(fù)載結(jié)構(gòu)是匹配的
