消耗 IDataProtectionProvider 的元件必須將唯一的 目的 參數傳遞給方法 CreateProtector 。 目的 參數 是資料保護系統安全性的固有條件，因為它提供加密使用者間的隔離，即使根密碼金鑰相同。
當消費者指定目的時，目的字串會與根密碼金鑰一起使用，以推導出該消費者獨有的密碼學子金鑰。 這使消費者與應用程式中所有其他加密使用者隔離：沒有其他元件能讀取其有效載荷，也無法讀取其他元件的有效載荷。 這種隔離也使得對該元件的攻擊類別變得不可行。
在上圖中， IDataProtector 實例 A 與 B 無法 讀取彼此的有效載荷，只能讀取自己的有效載荷。
目的字串不一定要是秘密的。 它應該是獨一無二的，因為沒有其他良好運作的元件能提供相同的目的字串。
小提示
使用使用資料保護 API 元件的命名空間與型別名稱是個不錯的經驗法則，因為實務上這些資訊不會衝突。
由 Contoso 撰寫、負責鑄造承載代幣的元件可能會使用 Contoso.Security.BearerToken 作為其目的字串。 或者——更好的是——它可能會使用 Contoso.Security.BearerToken.v1 作為目的字串。 附加版本號後，未來版本可使用 Contoso.Security.BearerToken.v2 作為用途，且不同版本在有效載荷上將完全隔離。
由於 的 CreateProtector 目的參數是字串陣列，上述內容本可改為 [ "Contoso.Security.BearerToken", "v1" ]。 這有助於建立目的層級，並開啟使用資料保護系統的多租戶場景的可能性。
警告
元件不應該允許不受信任的使用者輸入成為目的鏈的唯一輸入來源。
舉例來說，考慮一個負責儲存安全訊息的元件 Contoso.Messaging.SecureMessage。 若安全訊息元件呼叫 CreateProtector([ username ])，惡意使用者可能會建立名為「Contoso.Security.BearerToken」的帳號，試圖讓元件呼叫 CreateProtector([ "Contoso.Security.BearerToken" ])，從而無意中導致安全訊息系統鑄造可能被視為認證憑證的有效載荷。
訊息元件的更好用途鏈是 CreateProtector([ "Contoso.Messaging.SecureMessage", $"User: {username}" ])，這能提供適當的隔離。
由IDataProtectionProvider、IDataProtector及其目的所提供的隔離和行為如下：
對於給定
IDataProtectionProvider的物件，方法CreateProtector會建立IDataProtector一個物件，該物件同時與IDataProtectionProvider創建該物件的物件以及傳遞到方法的 purposes 參數都唯一相關聯。目的參數不得為空。 （若 目的指定為陣列，則陣列長度不得為零，且陣列中所有元素必須非空。）空弦目的在技術上是允許的，但不建議這麼做。
兩個目的參數當且僅當它們包含相同字串（使用序數比較器）且順序相同時，才是等價的。 單一目的參數等同於對應的單元素用途陣列。
兩個
IDataProtector物件當且僅當它們是由具有相同目的參數的等價IDataProtectionProvider物件所創造時，才是等價的。對於給定的
IDataProtector物件，只有當對等的IDataProtector物件符合protectedData := Protect(unprotectedData)時，呼叫Unprotect(protectedData)才會回傳原始的unprotectedData。
備註
我們不考慮某個元件故意選擇一個已知會與另一個元件衝突的目的字串的情況。 此類元件本質上會被視為惡意，且此系統並非設計用來在工作程序中運行惡意程式碼時提供安全保證。
