過去，第三方 Cookie 已用於儲存及傳送使用者狀態的相關資訊，例如登入狀態、所用裝置的相關資訊，或者是否受到已知和信任。例如，使用者是否已透過單一登入 (SSO) 登入、使用者是否有特定類型的相容裝置，或者使用者是否已知且信任使用者。由於第三方 Cookie 支援功能遭到淘汰，因此需要透過其他方式支援這類用途。
私密狀態權杖可讓您在網路上分享資訊，但透過控管實際可分享的資料量，以保障隱私的方式保護資訊。
Private State Tokens (舊稱「Trust Tokens」) 可讓信任將使用者的真實性從一個情境傳遞到另一個情境中，同時協助網站抵禦詐欺行為，以及區分機器人和真人，而不需要被動追蹤。
本文件概述實作私密狀態權杖 (PST) 的技術詳細資料。如需更詳盡的概要，請參閱 PST 總覽。
私密狀態權杖的運作方式
發卡機構和兌換者需要瞭解 PST 的主要關係。核發者和兌換者可以是同一家公司。
- Issuers - 這些實體有關於使用者的某些信號 (例如，使用者是否是機器人)，並將該信號嵌入使用者裝置的權杖中 (詳情請參閱後續章節)。
- 兌換者 - 這些實體可能沒有使用者信號，但需要知道一些相關資訊 (例如該使用者是否為機器人)，並要求核發者兌換權杖，才能瞭解該使用者的信任。
每次 PST 互動都會要求發卡機構和兌換者搭配運作，以便在網路上共用信號。這些信號為概略值，並未不夠詳盡，無法用來識別個人。
私密狀態權杖適合我嗎？
如果公司做出信任決定，且希望資訊能在各種情境中取用，就很適合使用 PST。如要進一步瞭解 PST 的潛在用途，請參閱 PST 使用案例說明文件。
核發及兌換代碼
PST 實作分為三個階段：
- 核發權杖
- 兌換代碼
- 兌換記錄轉送
在第一階段，系統會將符記核發給瀏覽器 (通常會在某種類型的驗證後)。在第二階段中，另一個實體會要求兌換符記，所核發的符記會讀取該符記中的值。在最終階段，兌換者會收到含有代碼所含值的兌換記錄 (RR)。兌換方隨後可將該記錄用來認證使用者，以用於各種用途。
定義權杖策略
定義權杖策略時，您需要瞭解 PST 的重要概念 (符記和兌換記錄)、變數、行為和限制，才能思考它們的潛在用途。
權杖和兌換記錄：兩者之間的關係為何？
每部裝置在每個頂層網站和核發機構最多可儲存 500 個權杖。此外，每個權杖都有中繼資料，說明核發者使用哪個金鑰。在兌換過程中，這些資訊可用來決定是否兌換代碼。PST 資料會儲存在使用者裝置的瀏覽器內部，且只能透過 PST API 存取。
使用者兌換代碼後，兌換記錄 (RR) 就會儲存在裝置上。 這個儲存空間可當做日後兌換項目的快取。針對每部裝置、網頁和核發者，每 48 小時會兌換 2 次權杖。新的兌換呼叫會盡可能使用快取 RR，而非向發卡機構發出要求。
- 系統會核發新的權杖 (每個核發機構、網站和裝置最多 500 個)。
- 所有權杖會儲存在裝置端權杖存放區 (類似 Cookie 存放區)。
- 如果找不到任何有效的 RR，則會在核發後產生新的 RR (最多每 48 小時 2 次)。
- 在到期之前，RR 都會視為有效，並會作為本機快取使用。
- 新的兌換呼叫會到達本機快取，不會產生新的 RR。
定義用途後，您必須謹慎定義 RR 的壽命，因為這會定義在事件中可以使用的次數。
定義策略之前，請務必瞭解下列關鍵行為和變數：
| 變數 / 行為 | 說明 | 可能的用量 |
|---|---|---|
| 權杖金鑰中繼資料 | 每個權杖只能使用一個加密編譯金鑰核發，且在 PST 中每個核發者最多只能有六組金鑰。 | 使用這個變數的一種可能方式，就是根據加密編譯金鑰來定義權杖的信任範圍 (例如，金鑰 1 = 高信任，而金鑰 6 = 不信任)。 |
| 權杖到期日 | 權杖到期日與金鑰到期日相同。 | 金鑰至少每 60 天輪替一次，而且由無效金鑰核發的所有權杖也會視為無效。 |
| 權杖兌換頻率限制 | 每部裝置和核發者每 48 小時最多只能兌換兩次權杖兌換作業。 | 視用途預估每 48 小時的兌換次數而定。 |
| 每個頂層來源的核發機構數量上限 | 目前每個頂層來源的核發機構數量上限為兩個。 | 仔細定義各頁面的發卡機構。 |
| 裝置上每個發卡機構的權杖數量 | 目前每個核發機構的權杖數量上限為 500 個。 | 每個核發者的權杖數量不得超過 500 個。 嘗試核發權杖時，請務必處理網頁上的錯誤。 |
| 金鑰使用承諾輪替 | 每個 PST 核發者都必須公開具有金鑰承諾的端點，這類修訂版本每 60 天可以變更，且任何速度的輪替時間都會超過系統會忽略的時間。 | 如果金鑰將於 60 天內到期，您必須在該日期前更新金鑰使用承諾，以免服務中斷 (請參閱詳細資料)。 |
| 兌換記錄效期 | 可以定義 RR 的效期，以便判斷到期日。系統會快取 RR，避免對核發機構發出不必要的新的兌換呼叫，因此請務必提供足夠的最新兌換信號。 | 由於每 48 小時有兩個符記的兌換率限制，因此請務必定義 RR 的效期，至少能在這段時間內執行成功的兌換呼叫 (RR 生命週期應據此設定)。建議您按照週次設定這個生命週期。 |
範例情境
情境 #1：RR 效期短於 24 小時 (t=t)，且在 48 小時內多次執行兌換作業。
情境 #2：RR 效期為 24 小時，且在 48 小時期間內多次執行兌換作業。
情境 #3：RR 效期為 48 小時，且在 48 小時內多次執行兌換作業。
執行示範
採用 PST 前，建議先進行示範設定。如要試用 PST 示範，您必須使用標記執行 Chrome 以啟用示範核發者金鑰承諾產品 (請按照示範頁面上的指示操作)。
執行這項示範之後，瀏覽器就會使用示範核發機構和兌換器伺服器來提供及使用權杖。
技術考量
建議您執行下列步驟，以最佳方式執行示範：
- 請務必先停止所有 Chrome 執行個體，再執行含有旗標的 Chrome。
- 如果您在 Windows 電腦上執行，請參閱 這份指南，瞭解如何將參數傳遞給 Chrome 執行檔二進位檔。
- 開啟 Chrome 開發人員工具 (依序點選「Applications」>「儲存空間」>「Private State Tokens」，同時查看示範核發機構核發/兌換的權杖)。
設定以採用
成為核發機構
發行者在 PST 中扮演關鍵角色。他們會指派值給符記，以判斷使用者是否為機器人。如要以核發者的身分開始使用 PST，您必須完成核發機構註冊程序才能完成註冊。
如要申請成為核發者，核發機構網站的操作者必須採用「New PST Issuer」範本，在 GitHub 存放區上建立新的問題。按照存放區的指南填寫問題。端點通過驗證後，系統會將其合併至這個存放區，Chrome 伺服器端基礎架構也會開始擷取這些金鑰。
核發者伺服器
發行者和兌換者是 PST 的關鍵執行者；伺服器和符記是 PST 的關鍵工具。雖然我們已在 GitHub 說明文件中提供部分權杖的相關詳細資料，但還是想提供更多有關 PST 伺服器的詳細資料。如要設定為 PST 的核發者，您必須先設定核發伺服器。
部署環境：核發者伺服器
如要實作權杖核發機構伺服器，您必須建構自己的伺服器端應用程式，公開 HTTP 端點。
核發者元件由兩個主要模組組成：(1) 核發者伺服器和 (2) 權杖核發者。
如同所有面向網頁版的應用程式，我們建議您為核發者伺服器多添一層保護。
核發者伺服器：在我們的範例實作中，核發伺服器是使用 Express 架構來託管核發者 HTTP 端點的 Node.js 伺服器。您可以前往 GitHub 查看程式碼範例。
權杖核發者：核發者加密元件不需要任何特定語言，但基於這個元件的效能要求，我們提供 C 實作範例，讓您使用 Boring SSL 程式庫管理權杖。您可以找到 Issuer 程式碼範例及關於 GitHub 安裝的詳細資訊
金鑰：權杖核發機構元件會使用自訂 EC 金鑰加密權杖。這些金鑰必須受到保護並儲存在安全儲存空間中。
核發機構伺服器的技術相關規定
根據通訊協定，您必須在核發者伺服器中至少實作兩個 HTTP 端點：
- 金鑰承諾 (例如
/.well-known/private-state-token/key-commitment)：可讓瀏覽器前往這個端點，確認您的伺服器是否合法。 - 權杖核發作業 (例如
/.well-known/private-state-token/issuance)：處理所有權杖要求的權杖核發端點，這個端點將成為權杖核發者元件的整合點。
如前文所述，由於這個伺服器可能會處理的流量偏高，因此建議您使用可擴充的基礎架構 (例如雲端環境) 部署伺服器，以便依據變數需求調整後端。
將通話傳送至核發機構伺服器
實作對發卡機構堆疊的網站擷取呼叫，以發出新的權杖。
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
兌換者伺服器
您必須建構自己的伺服器端應用程式，以實作權杖兌換服務。這可讓您讀取發卡機構傳送的憑證。下列步驟概述如何兌換代碼，以及如何解讀與這些代碼相關聯的兌換記錄。
您可以選擇在相同的伺服器 (或一組伺服器) 中執行核發機構和兌換者。
兌換者伺服器的技術相關規定
根據通訊協定，您必須為兌換工具伺服器實作至少兩個 HTTP 端點：
/.well-known/private-state-token/redemption：處理所有權杖兌換的端點。這個端點會是整合權杖遮蓋元件的位置
傳送呼叫至兌換者伺服器
如要兌換權杖，您需要在兌換工具堆疊中導入網站擷取呼叫，才能兌換先前核發的權杖。
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
請參閱程式碼範例。
兌換權杖後，您可以執行其他擷取呼叫來傳送兌換記錄 (RR)：
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
請參閱程式碼範例。
部署實作項目
如要測試實作結果，請先前往發出呼叫的網頁，並確認權杖是根據您的邏輯建立。在後端確認呼叫是根據規格發出，接著前往進行兌換呼叫的網頁，確認已按照邏輯建立 RR。
實際部署
建議您選取屬於特定用途的網站：
- 每月造訪次數較少 (每個月約 100 萬次造訪)：建議您先先將 API 部署至少數目標對象
- 其控制權為您所有：如有需要，您可以快速停用實作程序，不必進行複雜的核准程序
- 僅限一個核發者：限制權杖數量以簡化測試。
- 兌換者不得超過兩位：您需要簡化疑難排解過程，
疑難排解
您可以在 Chrome 開發人員工具「Network」和「Application」分頁中檢查 PST。
在「網路」標籤上：
在 [Application] (應用程式) 分頁中：
進一步瞭解這項開發人員工具整合。
伺服器最佳做法和疑難排解
為了讓核發機構和兌換者伺服器能夠有效運作，建議您採用下列最佳做法，確保您不會遇到 PST 的任何存取、安全性、記錄或流量等問題。
- 您的端點必須使用 TLS 1.3 或 1.2 套用高強度密碼編譯。
- 您的基礎架構必須準備好處理變動的流量 (包括尖峰)。
- 請確認您的金鑰受到保護且安全，並與您的存取權控管政策、金鑰管理策略和業務持續性計畫保持一致。
- 在堆疊中加入可觀測指標，確保在實際發布後，您能夠清楚掌握用量、瓶頸和效能問題。
更多資訊
- 參閱開發人員說明文件：
- 透過 GitHub 問題或 W3C 呼叫在對話中貢獻心力。
- 如要進一步瞭解任何術語，請參閱 Privacy Sandbox 詞彙。
- 如要進一步瞭解 Chrome 概念，例如「來源試用」或「Chrome 旗標」，請參閱 goo.gle/cc 提供的短片和文章。