部署模型

本页面介绍 Privacy Pass 部署的结构：四个角色各自的运营者、详细的示例部署模型、哪些部署模型适用于不同的客户需求，以及 Privacy Pass 作为其他产品的一部分。

虽然 Privacy Pass 令牌通过盲签名和大型匿名集提供密码学保护，但各角色的分配也必须具有足够的分离度，以确保隐私保证。典型的 Cloudflare 部署结构如下：

最重要的是，这将客户端的信息分散给多方，确保没有任何一个角色了解所有信息，这也被称为不可关联性。虽然不同的部署模型可以改变具体哪方知晓什么信息，但不可关联性保证没有人同时知道客户端是谁以及他们要去哪里。通常，信息分离方式如下：

• Attester — 知道客户端是谁以及在验证阶段共享的任何可识别信息，但不知道源身份。
• Issuer — 只知道客户端已通过验证并获得了签名令牌。（这取决于部署方式：如果 Attester 和 Issuer 是同一实体，Issuer 可能会获取身份信息，但源身份仍被隐藏。）
• Origin — 只知道客户端已通过验证。

需要注意的是，Privacy Pass 提供的令牌颁发和兑换之间的不可关联性仅部分依赖于角色分离。为了提供有意义的隐私保护，匿名集——即属于同一部署设置的客户端组——也必须保持较大规模。任何导致客户端看到不同设置的因素都会将其分裂成更小的组，缩小匿名范围。

有关更多信息，请参阅 Privacy Pass RFC 的准则 ↗。

主要的结构选择是确定 Attester、Issuer 和 Origin 在运营实体上是否有重叠，或者完全分离。虽然完全分离模型是最安全的，但根据用例将某些实体合并也有其好处。其他可能的模型包括联合 Attester-Issuer 和联合 Issuer-Origin，只要遵循额外准则 ↗，就不会破坏隐私保证。

Apple 创建了 PAT ↗，以便为 Safari 和参与应用程序及第三方浏览器上的 iOS 16+ 用户几乎完全绕过 CAPTCHA 挑战。在此部署中，Apple 利用其作为硬件提供商的角色，使用有效 Apple ID 和设备完整性检查等信号（而非 CAPTCHA）来证明设备合法性。角色分离结构如下：

此部署使用完全分离模型，意味着所有角色由不串通的实体运营。分离模型对 Apple 来说是理想的，因为他们作为硬件/基础设施提供商的工作自然契合 Attester 角色。但是，对于作为源运营的客户来说，此模型可能不那么有用，因为要么必须引入第三方作为 Attester，要么必须在 Cloudflare 和客户之间合并角色，以确保所有三个角色都得到运营。

应用程序开发者可能希望确保其服务的用户是订阅者或超过特定年龄，而无需将该信息与其账户一起持久存储。在这种用例中，角色分离结构可能如下所示：

此部署使用联合 Attester-Issuer 模型，其中 Cloudflare 同时运营颁发者和验证者。如果客户充当源，通常不应同时运营 Attester，因为这会创建一个知道用户身份和目的地的 Origin-Attester 实体，使隐私保证更难实现。让 Cloudflare 与颁发者联合运营它避免了引入全新的第三方，但这不是必须的。联合 Attester-Issuer 模型在角色颠倒时也很有用，例如当客户是身份授权机构（如企业 IdP/SSO 提供商），希望为其源提供私密验证时。

Privacy Pass 还为现有的 Cloudflare 产品提供支持。最成熟的例子是 Privacy Proxy，用于单跳（Microsoft Edge Secure Network ↗）和双跳（Apple Private Relay ↗）部署，其中 Privacy Pass 处理客户端与代理（或双跳中的第一个代理）之间的初始身份验证。如果你的用例符合现有产品，那可能是最简单的路径。有关代理级别架构，请参阅 Privacy Proxy 部署模型。

• Privacy Pass 协议
• 生产部署测试 — 使用 Cloudflare 部署这些模型之一的具体情况。
• 使用 Private Access Tokens 替换 CAPTCHA（Apple WWDC22） ↗ — Apple 关于其 Private Access Token 部署的概述。