Internet Architecture Board (IAB) A. Cooper
Request for Comments: 6973 CDT
Category: Informational H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
B. Aboba
Skype
J. Peterson
NeuStar, Inc.
J. Morris
Internet Architecture Board (IAB) A. Cooper
Request for Comments: 6973 CDT
Category: Informational H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
B. Aboba
Skype
J. Peterson
NeuStar, Inc.
J. Morris
M. Hansen ULD R. Smith Janet July 2013
M.Hansen ULD R.Smith Janet 2013年7月
Privacy Considerations for Internet Protocols
因特网协议的隐私考虑
Abstract
摘要
This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.
本文件为制定协议规范中的隐私注意事项提供了指导。它旨在使互联网协议的设计者、实施者和用户了解与隐私相关的设计选择。它表明，任何单独的RFC是否需要特定的隐私注意事项部分将取决于文档的内容。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6973.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6973.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................4
2. Scope of Privacy Implications of Internet Protocols .............5
3. Terminology .....................................................6
3.1. Entities ...................................................7
3.2. Data and Analysis ..........................................8
3.3. Identifiability ............................................9
4. Communications Model ...........................................10
5. Privacy Threats ................................................12
5.1. Combined Security-Privacy Threats .........................13
5.1.1. Surveillance .......................................13
5.1.2. Stored Data Compromise .............................14
5.1.3. Intrusion ..........................................14
5.1.4. Misattribution .....................................14
5.2. Privacy-Specific Threats ..................................15
5.2.1. Correlation ........................................15
5.2.2. Identification .....................................16
5.2.3. Secondary Use ......................................16
5.2.4. Disclosure .........................................17
5.2.5. Exclusion ..........................................17
6. Threat Mitigations .............................................18
6.1. Data Minimization .........................................18
6.1.1. Anonymity ..........................................19
6.1.2. Pseudonymity .......................................20
6.1.3. Identity Confidentiality ...........................20
6.1.4. Data Minimization within Identity Management .......21
6.2. User Participation ........................................21
6.3. Security ..................................................22
7. Guidelines .....................................................23
7.1. Data Minimization .........................................24
7.2. User Participation ........................................25
7.3. Security ..................................................25
7.4. General ...................................................26
8. Example ........................................................26
9. Security Considerations ........................................31
10. Acknowledgements ..............................................31
11. IAB Members at the Time of Approval ...........................32
12. Informative References ........................................32
1. Introduction ....................................................4
2. Scope of Privacy Implications of Internet Protocols .............5
3. Terminology .....................................................6
3.1. Entities ...................................................7
3.2. Data and Analysis ..........................................8
3.3. Identifiability ............................................9
4. Communications Model ...........................................10
5. Privacy Threats ................................................12
5.1. Combined Security-Privacy Threats .........................13
5.1.1. Surveillance .......................................13
5.1.2. Stored Data Compromise .............................14
5.1.3. Intrusion ..........................................14
5.1.4. Misattribution .....................................14
5.2. Privacy-Specific Threats ..................................15
5.2.1. Correlation ........................................15
5.2.2. Identification .....................................16
5.2.3. Secondary Use ......................................16
5.2.4. Disclosure .........................................17
5.2.5. Exclusion ..........................................17
6. Threat Mitigations .............................................18
6.1. Data Minimization .........................................18
6.1.1. Anonymity ..........................................19
6.1.2. Pseudonymity .......................................20
6.1.3. Identity Confidentiality ...........................20
6.1.4. Data Minimization within Identity Management .......21
6.2. User Participation ........................................21
6.3. Security ..................................................22
7. Guidelines .....................................................23
7.1. Data Minimization .........................................24
7.2. User Participation ........................................25
7.3. Security ..................................................25
7.4. General ...................................................26
8. Example ........................................................26
9. Security Considerations ........................................31
10. Acknowledgements ..............................................31
11. IAB Members at the Time of Approval ...........................32
12. Informative References ........................................32
[RFC3552] provides detailed guidance to protocol designers about both how to consider security as part of protocol design and how to inform readers of protocol specifications about security issues. This document intends to provide a similar set of guidelines for considering privacy in protocol design.
[RCF3552]为协议设计者提供了关于如何将安全考虑为协议设计的一部分以及如何向读者告知关于安全问题的协议规范的详细指导。本文件旨在为在协议设计中考虑隐私提供一套类似的指南。
Privacy is a complicated concept with a rich history that spans many disciplines. With regard to data, often it is a concept applied to "personal data", commonly defined as information relating to an identified or identifiable individual. Many sets of privacy principles and privacy design frameworks have been developed in different forums over the years. These include the Fair Information Practices [FIPs], a baseline set of privacy protections pertaining to the collection and use of personal data (often based on the principles established in [OECD], for example), and the Privacy by Design concept, which provides high-level privacy guidance for systems design (see [PbD] for one example). The guidance provided in this document is inspired by this prior work, but it aims to be more concrete, pointing protocol designers to specific engineering choices that can impact the privacy of the individuals that make use of Internet protocols.
隐私是一个复杂的概念，有着丰富的历史，跨越了许多学科。关于数据，它通常是一个适用于“个人数据”的概念，通常被定义为与已识别或可识别个人有关的信息。多年来，在不同的论坛上制定了许多隐私原则和隐私设计框架。其中包括公平信息实践[FIPs]，一组与收集和使用个人数据有关的隐私保护基线（例如，通常基于[OECD]中确立的原则），以及设计隐私概念，该概念为系统设计提供高级隐私指导（例如，见[PbD]）。本文档中提供的指导是受之前工作的启发，但其目的是更具体，将协议设计者引向可能影响使用互联网协议的个人隐私的特定工程选择。
Different people have radically different conceptions of what privacy means, both in general and as it relates to them personally [Westin]. Furthermore, privacy as a legal concept is understood differently in different jurisdictions. The guidance provided in this document is generic and can be used to inform the design of any protocol to be used anywhere in the world, without reference to specific legal frameworks.
不同的人对隐私意味着什么有着根本不同的概念，无论是一般意义上的还是与他们个人相关的（威斯汀）。此外，隐私作为一个法律概念在不同的司法管辖区有不同的理解。本文件中提供的指南是通用的，可用于通知世界任何地方使用的任何协议的设计，而无需参考具体的法律框架。
Whether any individual document warrants a specific privacy considerations section will depend on the document's content. Documents whose entire focus is privacy may not merit a separate section (for example, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks" [RFC3325]). For certain specifications, privacy considerations are a subset of security considerations and can be discussed explicitly in the security considerations section. Some documents will not require discussion of privacy considerations (for example, "Definition of the Opus Audio Codec" [RFC6716]). The guidance provided here can and should be used to assess the privacy considerations of protocol, architectural, and operational specifications and to decide whether those considerations are to be documented in a stand-alone section, within the security considerations section, or throughout the
任何单独的文档是否需要特定的隐私注意事项部分将取决于文档的内容。以隐私为中心的文档可能不需要单独的章节（例如，“在可信网络中声明身份的会话启动协议（SIP）的专用扩展”[RFC3325]）。对于某些规范，隐私注意事项是安全注意事项的子集，可以在安全注意事项部分中明确讨论。有些文件不需要讨论隐私问题（例如，“Opus音频编解码器的定义”[RFC6716]）。此处提供的指南可以也应该用于评估协议、架构和操作规范的隐私考虑因素，并决定是否将这些考虑因素记录在独立部分、安全考虑部分或整个过程中
document. The guidance provided here is meant to help the thought process of privacy analysis; it does not provide specific directions for how to write a privacy considerations section.
文件此处提供的指导旨在帮助隐私分析的思维过程；它没有提供如何编写隐私注意事项部分的具体说明。
This document is organized as follows. Section 2 describes the extent to which the guidance offered here is applicable within the IETF and within the larger Internet community. Section 3 explains the terminology used in this document. Section 4 reviews typical communications architectures to understand at which points there may be privacy threats. Section 5 discusses threats to privacy as they apply to Internet protocols. Section 6 outlines mitigations of those threats. Section 7 provides the guidelines for analyzing and documenting privacy considerations within IETF specifications. Section 8 examines the privacy characteristics of an IETF protocol to demonstrate the use of the guidance framework.
本文件的组织结构如下。第2节描述了此处提供的指南适用于IETF和更大的互联网社区的程度。第3节解释了本文件中使用的术语。第4节回顾了典型的通信体系结构，以了解哪些点可能存在隐私威胁。第5节讨论了适用于互联网协议的隐私威胁。第6节概述了这些威胁的缓解措施。第7节提供了在IETF规范中分析和记录隐私注意事项的指南。第8节检查IETF协议的隐私特征，以演示指导框架的使用。
Internet protocols are often built flexibly, making them useful in a variety of architectures, contexts, and deployment scenarios without requiring significant interdependency between disparately designed components. Although protocol designers often have a particular target architecture or set of architectures in mind at design time, it is not uncommon for architectural frameworks to develop later, after implementations exist and have been deployed in combination with other protocols or components to form complete systems.
Internet协议通常是灵活构建的，这使得它们在各种体系结构、上下文和部署场景中都很有用，而不需要在不同设计的组件之间存在显著的相互依赖性。尽管协议设计人员在设计时通常会考虑特定的目标体系结构或体系结构集，但体系结构框架在实现存在并与其他协议或组件一起部署以形成完整系统后，在以后开发也并不少见。
As a consequence, the extent to which protocol designers can foresee all of the privacy implications of a particular protocol at design time is limited. An individual protocol may be relatively benign on its own, and it may make use of privacy and security features at lower layers of the protocol stack (Internet Protocol Security, Transport Layer Security, and so forth) to mitigate the risk of attack. But when deployed within a larger system or used in a way not envisioned at design time, its use may create new privacy risks. Protocols are often implemented and deployed long after design time by different people than those who did the protocol design. The guidelines in Section 7 ask protocol designers to consider how their protocols are expected to interact with systems and information that exist outside the protocol bounds, but not to imagine every possible deployment scenario.
因此，协议设计者在设计时能够预见特定协议的所有隐私影响的程度是有限的。单个协议本身可能是相对良性的，它可以利用协议栈较低层的隐私和安全特性（互联网协议安全、传输层安全等）来降低攻击风险。但当部署在更大的系统中或以设计时无法想象的方式使用时，其使用可能会产生新的隐私风险。协议通常在设计时间之后很久由不同的人来实现和部署，而不是由进行协议设计的人来实现和部署。第7节中的准则要求协议设计者考虑它们的协议是如何与存在于协议边界之外的系统和信息交互的，而不是想象每个可能的部署场景。
Furthermore, in many cases the privacy properties of a system are dependent upon the complete system design where various protocols are combined together to form a product solution; the implementation, which includes the user interface design; and operational deployment practices, including default privacy settings and security processes of the company doing the deployment. These details are specific to
此外，在许多情况下，系统的隐私属性取决于完整的系统设计，其中各种协议组合在一起形成产品解决方案；实现，包括用户界面设计；以及操作部署实践，包括进行部署的公司的默认隐私设置和安全流程。这些细节是特定于
particular instantiations and generally outside the scope of the work conducted in the IETF. The guidance provided here may be useful in making choices about these details, but its primary aim is to assist with the design, implementation, and operation of protocols.
特定实例，通常不在IETF中执行的工作范围内。此处提供的指导可能有助于选择这些细节，但其主要目的是协助协议的设计、实施和操作。
Transparency of data collection and use -- often effectuated through user interface design -- is normally relied on (whether rightly or wrongly) as a key factor in determining the privacy impact of a system. Although most IETF activities do not involve standardizing user interfaces or user-facing communications, in some cases, understanding expected user interactions can be important for protocol design. Unexpected user behavior may have an adverse impact on security and/or privacy.
数据收集和使用的透明度——通常通过用户界面设计实现——通常作为决定系统隐私影响的关键因素（无论正确与否）。尽管大多数IETF活动不涉及标准化用户界面或面向用户的通信，但在某些情况下，理解预期的用户交互对于协议设计非常重要。意外的用户行为可能对安全和/或隐私产生不利影响。
In sum, privacy issues, even those related to protocol development, go beyond the technical guidance discussed herein. As an example, consider HTTP [RFC2616], which was designed to allow the exchange of arbitrary data. A complete analysis of the privacy considerations for uses of HTTP might include what type of data is exchanged, how this data is stored, and how it is processed. Hence the analysis for an individual's static personal web page would be different than the use of HTTP for exchanging health records. A protocol designer working on HTTP extensions (such as Web Distributed Authoring and Versioning (WebDAV) [RFC4918]) is not expected to describe the privacy risks derived from all possible usage scenarios, but rather the privacy properties specific to the extensions and any particular uses of the extensions that are expected and foreseen at design time.
总之，隐私问题，甚至那些与协议开发相关的问题，超出了本文讨论的技术指导。作为一个例子，考虑HTTP[RCF2616]，它被设计为允许交换任意数据。对使用HTTP的隐私注意事项的完整分析可能包括交换什么类型的数据、如何存储这些数据以及如何处理这些数据。因此，对个人静态个人网页的分析将不同于使用HTTP交换健康记录。从事HTTP扩展（如Web分布式创作和版本控制（WebDAV）[RFC4918]）工作的协议设计人员不需要描述所有可能的使用场景产生的隐私风险，而是特定于扩展的隐私属性，以及在设计时预期和预见的扩展的任何特定用途。
This section defines basic terms used in this document, with references to pre-existing definitions as appropriate. As in [RFC4949], each entry is preceded by a dollar sign ($) and a space for automated searching. Note that this document does not try to attempt to define the term 'privacy' with a brief definition. Instead, privacy is the sum of what is contained in this document. We therefore follow the approach taken by [RFC3552]. Examples of several different brief definitions are provided in [RFC4949].
本节定义了本文件中使用的基本术语，并酌情参考了已有的定义。与[RFC4949]一样，每个条目前面都有一个美元符号（$）和一个用于自动搜索的空格。请注意，本文件并不试图用简短的定义来定义“隐私”一词。相反，隐私是本文档中包含内容的总和。因此，我们遵循[RFC3552]采取的方法。[RFC4949]中提供了几种不同简要定义的示例。
Several of these terms are further elaborated in Section 4.
第4节进一步阐述了其中几个术语。
$ Attacker: An entity that works against one or more privacy protection goals. Unlike observers, attackers' behavior is unauthorized.
$ 攻击者：违反一个或多个隐私保护目标的实体。与观察者不同，攻击者的行为是未经授权的。
$ Eavesdropper: A type of attacker that passively observes an initiator's communications without the initiator's knowledge or authorization. See [RFC4949].
$ 窃听者：一种在发起者不知情或未经授权的情况下被动观察发起者通信的攻击者。见[RFC4949]。
$ Enabler: A protocol entity that facilitates communication between an initiator and a recipient without being directly in the communications path.
$ 启用码：一种协议实体，用于促进发起者和接收者之间的通信，而无需直接位于通信路径中。
$ Individual: A human being.
$ 个人：一个人。
$ Initiator: A protocol entity that initiates communications with a recipient.
$ 发起方：发起与接收方通信的协议实体。
$ Intermediary: A protocol entity that sits between the initiator and the recipient and is necessary for the initiator and recipient to communicate. Unlike an eavesdropper, an intermediary is an entity that is part of the communication architecture and therefore at least tacitly authorized. For example, a SIP [RFC3261] proxy is an intermediary in the SIP architecture.
$ 中介：位于发起方和接收方之间的协议实体，是发起方和接收方进行通信所必需的。与窃听者不同，中介是作为通信体系结构一部分的实体，因此至少是默认授权的。例如，SIP[rfc326]代理是SIP体系结构中的中介。
$ Observer: An entity that is able to observe and collect information from communications, potentially posing privacy threats, depending on the context. As defined in this document, initiators, recipients, intermediaries, and enablers can all be observers. Observers are distinguished from eavesdroppers by being at least tacitly authorized.
$ 观察者：能够观察和收集通信信息的实体，根据上下文可能会造成隐私威胁。正如本文档中所定义的，发起人、接收人、中间人和启用者都可以是观察者。观察员与窃听者的区别在于他们至少得到了默许。
$ Recipient: A protocol entity that receives communications from an initiator.
$ 接收方：从发起方接收通信的协议实体。
$ Attack: An intentional act by which an entity attempts to violate an individual's privacy. See [RFC4949].
$ 攻击：实体试图侵犯个人隐私的故意行为。见[RFC4949]。
$ Correlation: The combination of various pieces of information that relate to an individual or that obtain that characteristic when combined.
$ 相关性：与个体相关的各种信息的组合，或在组合时获得该特征的信息。
$ Fingerprint: A set of information elements that identifies a device or application instance.
$ 指纹：标识设备或应用程序实例的一组信息元素。
$ Fingerprinting: The process of an observer or attacker uniquely identifying (with a sufficiently high probability) a device or application instance based on multiple information elements communicated to the observer or attacker. See [EFF].
$ 指纹识别：观察者或攻击者基于与观察者或攻击者通信的多个信息元素唯一地识别（以足够高的概率）设备或应用程序实例的过程。见[EFF]。
$ Item of Interest (IOI): Any data item that an observer or attacker might be interested in. This includes attributes, identifiers, identities, communications content, and the fact that a communication interaction has taken place.
$ 感兴趣项（IOI）：观察者或攻击者可能感兴趣的任何数据项。这包括属性、标识符、身份、通信内容以及发生通信交互的事实。
$ Personal Data: Any information relating to an individual who can be identified, directly or indirectly.
$ 个人数据：与可直接或间接识别的个人有关的任何信息。
$ (Protocol) Interaction: A unit of communication within a particular protocol. A single interaction may be comprised of a single message between an initiator and recipient or multiple messages, depending on the protocol.
$ （协议）交互：特定协议内的通信单元。根据协议，单个交互可以由发起方和接收方之间的单个消息或多个消息组成。
$ Traffic Analysis: The inference of information from observation of traffic flows (presence, absence, amount, direction, timing, packet size, packet composition, and/or frequency), even if flows are encrypted. See [RFC4949].
$ 流量分析：通过观察流量（存在、不存在、数量、方向、定时、数据包大小、数据包组成和/或频率）推断信息，即使流量是加密的。见[RFC4949]。
$ Undetectability: The inability of an observer or attacker to sufficiently distinguish whether an item of interest exists or not.
$ 不可检测性：观察者或攻击者无法充分区分感兴趣的项目是否存在。
$ Unlinkability: Within a particular set of information, the inability of an observer or attacker to distinguish whether two items of interest are related or not (with a high enough degree of probability to be useful to the observer or attacker).
$ 不可链接性：在一组特定信息中，观察者或攻击者无法区分两个感兴趣的项目是否相关（具有足够高的概率，对观察者或攻击者有用）。
$ Anonymity: The state of being anonymous.
$ 匿名性：匿名的状态。
$ Anonymity Set: A set of individuals that have the same attributes, making them indistinguishable from each other from the perspective of a particular attacker or observer.
$ 匿名集：具有相同属性的一组个体，从特定攻击者或观察者的角度来看，它们彼此无法区分。
$ Anonymous: A state of an individual in which an observer or attacker cannot identify the individual within a set of other individuals (the anonymity set).
$ 匿名：个体的一种状态，在这种状态下，观察者或攻击者无法在一组其他个体（匿名集）中识别该个体。
$ Attribute: A property of an individual.
$ 属性：个人的属性。
$ Identifiability: The extent to which an individual is identifiable.
$ 可识别性：个体可识别的程度。
$ Identifiable: A property in which an individual's identity is capable of being known to an observer or attacker.
$ 可识别：观察者或攻击者能够知道个人身份的财产。
$ Identification: The linking of information to a particular individual to infer an individual's identity or to allow the inference of an individual's identity in some context.
$ 识别：将信息与特定个体联系起来，以推断个体的身份或允许在某些上下文中推断个体的身份。
$ Identified: A state in which an individual's identity is known.
$ 已识别：个人身份已知的状态。
$ Identifier: A data object uniquely referring to a specific identity of a protocol entity or individual in some context. See [RFC4949]. Identifiers can be based upon natural names -- official names, personal names, and/or nicknames -- or can be artificial (for example, x9z32vb). However, identifiers are by definition unique within their context of use, while natural names are often not unique.
$ 标识符：在某些上下文中唯一引用协议实体或个人的特定标识的数据对象。见[RFC4949]。标识符可以基于自然名称——官方名称、个人名称和/或昵称——也可以是人工的（例如x9z32vb）。然而，根据定义，标识符在其使用环境中是唯一的，而自然名称通常不是唯一的。
$ Identity: Any subset of an individual's attributes, including names, that identifies the individual within a given context. Individuals usually have multiple identities for use in different contexts.
$ 身份：个体属性的任何子集，包括名称，在给定上下文中标识个体。个人通常有多种身份，可在不同的环境中使用。
$ Identity Confidentiality: A property of an individual where only the recipient can sufficiently identify the individual within a set of other individuals. This can be a desirable property of authentication protocols.
$ 身份保密性：个人的财产，只有接收者才能在一组其他个人中充分识别该个人。这可能是身份验证协议的理想特性。
$ Identity Provider: An entity (usually an organization) that is responsible for establishing, maintaining, securing, and vouching for the identities associated with individuals.
$ 身份提供者：负责建立、维护、保护和担保与个人相关的身份的实体（通常是组织）。
$ Official Name: A personal name for an individual that is registered in some official context (for example, the name on an individual's birth certificate). Official names are often not unique.
$ 官方姓名：在某些官方背景下注册的个人姓名（例如，个人出生证上的姓名）。官方名称通常不是唯一的。
$ Personal Name: A natural name for an individual. Personal names are often not unique and often comprise given names in combination with a family name. An individual may have multiple personal names at any time and over a lifetime, including official names. From a technological perspective, it cannot always be determined whether a given reference to an individual is, or is based upon, the individual's personal name(s) (see Pseudonym).
$ 个人名称：个人的自然名称。人名通常不是唯一的，通常由已知姓名和姓氏组成。一个人在任何时候和一生中可能有多个人名，包括正式姓名。从技术角度来看，不能总是确定对某个人的特定引用是否是或基于该个人的个人姓名（见笔名）。
$ Pseudonym: A name assumed by an individual in some context, unrelated to the individual's personal names known by others in that context, with an intent of not revealing the individual's identities associated with his or her other names. Pseudonyms are often not unique.
$ 笔名：个人在某种情况下使用的名称，与该情况下其他人所知的个人姓名无关，目的是不透露个人与其其他姓名相关的身份。笔名通常不是唯一的。
$ Pseudonymity: The state of being pseudonymous.
$ 化名：化名的状态。
$ Pseudonymous: A property of an individual in which the individual is identified by a pseudonym.
$ 笔名的：个人的一种财产，其中个人以笔名识别。
$ Real Name: See Personal Name and Official Name.
$ 真实姓名：参见个人姓名和官方名称。
$ Relying Party: An entity that relies on assertions of individuals' identities from identity providers in order to provide services to individuals. In effect, the relying party delegates aspects of identity management to the identity provider(s). Such delegation requires protocol exchanges, trust, and a common understanding of semantics of information exchanged between the relying party and the identity provider.
$ 依赖方：依赖身份提供者对个人身份的声明，为个人提供服务的实体。实际上，依赖方将身份管理的各个方面委托给身份提供者。这种委托需要协议交换、信任以及对依赖方和身份提供者之间交换的信息语义的共同理解。
To understand attacks in the privacy-harm sense, it is helpful to consider the overall communication architecture and different actors' roles within it. Consider a protocol entity, the "initiator", that initiates communication with some recipient. Privacy analysis is most relevant for protocols with use cases in which the initiator acts on behalf of an individual (or different individuals at different times). It is this individual whose privacy is potentially threatened (although in some instances an initiator communicates information about another individual, in which case both of their privacy interests will be implicated).
为了理解隐私伤害意义上的攻击，考虑整体通信体系结构和不同的参与者角色是有帮助的。考虑一个协议实体，即“发起方”，它发起与某些接收者的通信。隐私分析最适用于具有发起人代表个人（或不同时间的不同个人）行事的用例的协议。该个人的隐私可能受到威胁（尽管在某些情况下，发起者会传达另一个人的信息，在这种情况下，他们的隐私利益都会受到牵连）。
Communications may be direct between the initiator and the recipient, or they may involve an application-layer intermediary (such as a proxy, cache, or relay) that is necessary for the two parties to communicate. In some cases, this intermediary stays in the communication path for the entire duration of the communication; sometimes it is only used for communication establishment, for either inbound or outbound communication. In some cases, there may be a series of intermediaries that are traversed. At lower layers, additional entities involved in packet forwarding may interfere with privacy protection goals as well.
通信可以是发起方和接收方之间的直接通信，或者它们可能涉及双方通信所必需的应用层中介（例如代理、缓存或中继）。在某些情况下，该中介体在通信的整个持续时间内保持在通信路径中；有时，它仅用于建立通信，用于入站或出站通信。在某些情况下，可能会遍历一系列中介。在较低层，包转发中涉及的其他实体也可能干扰隐私保护目标。
Some communications tasks require multiple protocol interactions with different entities. For example, a request to an HTTP server may be preceded by an interaction between the initiator and an Authentication, Authorization, and Accounting (AAA) server for network access and to a Domain Name System (DNS) server for name resolution. In this case, the HTTP server is the recipient and the other entities are enablers of the initiator-to-recipient communication. Similarly, a single communication with the recipient might generate further protocol interactions between either the initiator or the recipient and other entities, and the roles of the entities might change with each interaction. For example, an HTTP request might trigger interactions with an authentication server or with other resource servers wherein the recipient becomes an initiator in those later interactions.
某些通信任务需要与不同实体进行多协议交互。例如，对HTTP服务器的请求可以在发起方和用于网络访问的认证、授权和计费（AAA）服务器之间的交互以及对用于名称解析的域名系统（DNS）服务器之间的交互之前进行。在这种情况下，HTTP服务器是接收者，其他实体是发起方到接收者通信的使能器。类似地，与接收者的单一通信可能在发起者或接收者与其他实体之间产生进一步的协议交互，并且实体的角色可能随着每次交互而改变。例如，HTTP请求可能触发与身份验证服务器或其他资源服务器的交互，其中接收方在这些后续交互中成为启动器。
Thus, when conducting privacy analysis of an architecture that involves multiple communications phases, the entities involved may take on different -- or opposing -- roles from a privacy considerations perspective in each phase. Understanding the privacy implications of the architecture as a whole may require a separate analysis of each phase.
因此，当对涉及多个通信阶段的体系结构进行隐私分析时，所涉及的实体可能在每个阶段从隐私考虑的角度承担不同的——或相反的——角色。从整体上理解架构的隐私含义可能需要对每个阶段进行单独的分析。
Protocol design is often predicated on the notion that recipients, intermediaries, and enablers are assumed to be authorized to receive and handle data from initiators. As [RFC3552] explains, "we assume that the end systems engaging in a protocol exchange have not themselves been compromised". However, privacy analysis requires questioning this assumption, since systems are often compromised for the purpose of obtaining personal data.
协议设计通常基于这样一个概念，即假定接收者、中介和使能器被授权接收和处理来自发起方的数据。正如[RFC3552]所解释的，“我们假设参与协议交换的终端系统本身没有受到损害”。然而，隐私分析需要质疑这一假设，因为系统通常是为了获取个人数据而被破坏的。
Although recipients, intermediaries, and enablers may not generally be considered as attackers, they may all pose privacy threats (depending on the context) because they are able to observe, collect, process, and transfer privacy-relevant data. These entities are collectively described below as "observers" to distinguish them from traditional attackers. From a privacy perspective, one important
尽管接收者、中间人和使能者通常不被视为攻击者，但他们都可能构成隐私威胁（取决于上下文），因为他们能够观察、收集、处理和传输隐私相关数据。以下将这些实体统称为“观察者”，以区别于传统攻击者。从隐私的角度来看，一个重要的
type of attacker is an eavesdropper: an entity that passively observes the initiator's communications without the initiator's knowledge or authorization.
攻击者的类型是窃听者：一种在发起者不知情或未经授权的情况下被动观察发起者通信的实体。
The threat descriptions in the next section explain how observers and attackers might act to harm individuals' privacy. Different kinds of attacks may be feasible at different points in the communications path. For example, an observer could mount surveillance or identification attacks between the initiator and intermediary, or instead could surveil an enabler (e.g., by observing DNS queries from the initiator).
下一节中的威胁描述将解释观察者和攻击者可能会如何伤害个人隐私。不同类型的攻击可能在通信路径的不同点上可行。例如，观察者可以在启动器和中介之间发起监视或标识攻击，或者可以监视启用码（例如，通过观察来自启动器的DNS查询）。
Privacy harms come in a number of forms, including harms to financial standing, reputation, solitude, autonomy, and safety. A victim of identity theft or blackmail, for example, may suffer a financial loss as a result. Reputational harm can occur when disclosure of information about an individual, whether true or false, subjects that individual to stigma, embarrassment, or loss of personal dignity. Intrusion or interruption of an individual's life or activities can harm the individual's ability to be left alone. When individuals or their activities are monitored, exposed, or at risk of exposure, those individuals may be stifled from expressing themselves, associating with others, and generally conducting their lives freely. They may also feel a general sense of unease, in that it is "creepy" to be monitored or to have data collected about them. In cases where such monitoring is for the purpose of stalking or violence (for example, monitoring communications to or from a domestic abuse shelter), it can put individuals in physical danger.
隐私损害有多种形式，包括对财务状况、声誉、孤独、自主和安全的损害。例如，身份盗窃或勒索的受害者可能因此遭受经济损失。当披露有关个人的信息（无论是真是假）使该个人蒙受耻辱、尴尬或丧失个人尊严时，可能会发生声誉损害。侵入或中断个人的生活或活动可能会损害个人独处的能力。当个人或其活动受到监控、暴露或有暴露的风险时，这些人可能会被压抑，无法表达自己、与他人交往以及通常自由地进行生活。他们也可能会普遍感到不安，因为被监控或收集有关他们的数据是“令人毛骨悚然的”。如果这种监测是为了跟踪或暴力（例如，监测与家庭虐待庇护所之间的通信），可能会使个人处于身体危险之中。
This section lists common privacy threats (drawing liberally from [Solove], as well as [CoE]), showing how each of them may cause individuals to incur privacy harms and providing examples of how these threats can exist on the Internet. This threat modeling is inspired by security threat analysis. Although it is not a perfect fit for assessing privacy risks in Internet protocols and systems, no better methodology has been developed to date.
本节列出了常见的隐私威胁（摘自[Solove]和[CoE]），展示了每种威胁如何导致个人遭受隐私伤害，并举例说明这些威胁如何在互联网上存在。此威胁建模受安全威胁分析的启发。虽然它不适合评估互联网协议和系统中的隐私风险，但迄今为止还没有开发出更好的方法。
Some privacy threats are already considered in Internet protocols as a matter of routine security analysis. Others are more pure privacy threats that existing security considerations do not usually address. The threats described here are divided into those that may also be considered security threats and those that are primarily privacy threats.
在互联网协议中，一些隐私威胁已经被视为日常安全分析的问题。另一些则是现有安全考虑通常无法解决的更纯粹的隐私威胁。此处描述的威胁分为也可能被视为安全威胁的威胁和主要是隐私威胁的威胁。
Note that an individual's awareness of and consent to the practices described below may change an individual's perception of and concern for the extent to which they threaten privacy. If an individual authorizes surveillance of his own activities, for example, the individual may be able to take actions to mitigate the harms associated with it or may consider the risk of harm to be tolerable.
请注意，个人对下述行为的认识和同意可能会改变个人对这些行为威胁隐私程度的看法和担忧。例如，如果个人授权对他自己的活动进行监视，个人可能能够采取行动减轻与之相关的伤害，或者认为伤害的风险是可以容忍的。
Surveillance is the observation or monitoring of an individual's communications or activities. The effects of surveillance on the individual can range from anxiety and discomfort to behavioral changes such as inhibition and self-censorship, and even to the perpetration of violence against the individual. The individual need not be aware of the surveillance for it to impact his or her privacy -- the possibility of surveillance may be enough to harm individual autonomy.
监视是对个人通信或活动的观察或监视。监视对个人的影响范围从焦虑和不适到行为变化，如抑制和自我审查，甚至对个人实施暴力。个人无需意识到监视会影响其隐私——监视的可能性可能足以损害个人的自主性。
Surveillance can impact privacy, even if the individuals being surveilled are not identifiable or if their communications are encrypted. For example, an observer or eavesdropper that conducts traffic analysis may be able to determine what type of traffic is present (real-time communications or bulk file transfers, for example) or which protocols are in use, even if the observed communications are encrypted or the communicants are unidentifiable. This kind of surveillance can adversely impact the individuals involved by causing them to become targets for further investigation or enforcement activities. It may also enable attacks that are specific to the protocol, such as redirection to a specialized interception point or protocol-specific denials of service. Protocols that use predictable packet sizes or timing or include fixed tokens at predictable offsets within a packet can facilitate this kind of surveillance.
监视可能会影响隐私，即使被监视的个人无法识别，或者他们的通信是加密的。例如，进行流量分析的观察者或窃听者可能能够确定存在何种类型的流量（例如，实时通信或批量文件传输）或正在使用哪些协议，即使观察到的通信被加密或通信者无法识别。这种监视会对涉案人员产生不利影响，使他们成为进一步调查或执法活动的目标。它还可能启用特定于协议的攻击，例如重定向到专用拦截点或特定于协议的拒绝服务。使用可预测的数据包大小或定时，或在数据包中以可预测的偏移量包含固定令牌的协议可以促进这种监视。
Surveillance can be conducted by observers or eavesdroppers at any point along the communications path. Confidentiality protections (as discussed in Section 3 of [RFC3552]) are necessary to prevent surveillance of the content of communications. To prevent traffic analysis or other surveillance of communications patterns, other measures may be necessary, such as [Tor].
监视可以由观察者或窃听者在通信路径上的任何一点进行。保密保护（如[RFC3552]第3节所述）是防止监控通信内容所必需的。为了防止对通信模式进行流量分析或其他监控，可能需要采取其他措施，如[Tor]。
End systems that do not take adequate measures to secure stored data from unauthorized or inappropriate access expose individuals to potential financial, reputational, or physical harm.
未采取适当措施保护存储数据不被未经授权或不适当访问的终端系统会使个人面临潜在的财务、声誉或身体伤害。
Protecting against stored data compromise is typically outside the scope of IETF protocols. However, a number of common protocol functions -- key management, access control, or operational logging, for example -- require the storage of data about initiators of communications. When requiring or recommending that information about initiators or their communications be stored or logged by end systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize the potential for that information to be compromised and for that potential to be weighed against the benefits of data storage. Any recipient, intermediary, or enabler that stores data may be vulnerable to compromise. (Note that stored data compromise is distinct from purposeful disclosure, which is discussed in Section 5.2.4.)
防止存储数据泄露通常不在IETF协议的范围内。然而，许多常见的协议功能（例如，密钥管理、访问控制或操作日志记录）需要存储有关通信启动器的数据。当要求或建议终端系统存储或记录有关启动器或其通信的信息时（参见，例如，RFC 6302[RFC6302]），重要的是要认识到该信息被破坏的可能性，并将该可能性与数据存储的好处进行权衡。存储数据的任何收件人、中间人或启用程序都可能容易受到攻击。（请注意，存储数据泄露不同于第5.2.4节中讨论的故意泄露。）
Intrusion consists of invasive acts that disturb or interrupt one's life or activities. Intrusion can thwart individuals' desires to be left alone, sap their time or attention, or interrupt their activities. This threat is focused on intrusion into one's life rather than direct intrusion into one's communications. The latter is captured in Section 5.1.1.
入侵是指干扰或中断人的生活或活动的入侵行为。入侵可能会挫败个人独处的欲望，耗尽他们的时间或注意力，或打断他们的活动。这种威胁的重点是侵入一个人的生活，而不是直接侵入一个人的通讯。后者见第5.1.1节。
Unsolicited messages and denial-of-service attacks are the most common types of intrusion on the Internet. Intrusion can be perpetrated by any attacker that is capable of sending unwanted traffic to the initiator.
未经请求的消息和拒绝服务攻击是互联网上最常见的入侵类型。任何能够向发起方发送不需要的流量的攻击者都可以实施入侵。
Misattribution occurs when data or communications related to one individual are attributed to another. Misattribution can result in adverse reputational, financial, or other consequences for individuals that are misidentified.
当与一个人相关的数据或通信被归因于另一个人时，就会发生错误归因。错误归因可能会对被错误识别的个人造成不利的声誉、财务或其他后果。
Misattribution in the protocol context comes as a result of using inadequate or insecure forms of identity or authentication, and is sometimes related to spoofing. For example, as [RFC6269] notes, abuse mitigation is often conducted on the basis of the source IP address, such that connections from individual IP addresses may be prevented or temporarily blacklisted if abusive activity is determined to be sourced from those addresses. However, in the case
协议上下文中的错误归因是由于使用了不充分或不安全的身份或身份验证形式，有时与欺骗有关。例如，如[RFC6269]所述，滥用缓解通常基于源IP地址进行，因此，如果确定滥用活动源于这些地址，则可能会阻止或暂时将来自各个IP地址的连接列入黑名单。然而，在这种情况下
where a single IP address is shared by multiple individuals, those penalties may be suffered by all individuals sharing the address, even if they were not involved in the abuse. This threat can be mitigated by using identity management mechanisms with proper forms of authentication (ideally with cryptographic properties) so that actions can be attributed uniquely to an individual to provide the basis for accountability without generating false positives.
如果一个IP地址由多个人共享，则共享该地址的所有个人都可能遭受这些处罚，即使他们没有参与滥用。这种威胁可以通过使用身份管理机制和适当形式的身份验证（理想情况下具有加密属性）来缓解，这样可以将行动唯一地归因于个人，从而在不产生误报的情况下提供责任基础。
Correlation is the combination of various pieces of information related to an individual or that obtain that characteristic when combined. Correlation can defy people's expectations of the limits of what others know about them. It can increase the power that those doing the correlating have over individuals as well as correlators' ability to pass judgment, threatening individual autonomy and reputation.
相关性是与个体相关的各种信息的组合，或者是在组合时获得该特征的信息。相关性可以挑战人们对他人所知有限的期望。它可以增加那些进行关联的人对个人的权力以及关联者做出判断的能力，从而威胁到个人的自主性和声誉。
Correlation is closely related to identification. Internet protocols can facilitate correlation by allowing individuals' activities to be tracked and combined over time. The use of persistent or infrequently replaced identifiers at any layer of the stack can facilitate correlation. For example, an initiator's persistent use of the same device ID, certificate, or email address across multiple interactions could allow recipients (and observers) to correlate all of the initiator's communications over time.
相关性与识别密切相关。互联网协议通过允许个人的活动随着时间的推移而被跟踪和组合，从而促进相互关联。在堆栈的任何层使用持久的或不经常被替换的标识符可以促进相关性。例如，发起者在多个交互过程中持续使用相同的设备ID、证书或电子邮件地址可以使收件人（和观察者）在一段时间内关联发起者的所有通信。
As an example, consider Transport Layer Security (TLS) session resumption [RFC5246] or TLS session resumption without server-side state [RFC5077]. In RFC 5246 [RFC5246], a server provides the client with a session_id in the ServerHello message and caches the master_secret for later exchanges. When the client initiates a new connection with the server, it re-uses the previously obtained session_id in its ClientHello message. The server agrees to resume the session by using the same session_id and the previously stored master_secret for the generation of the TLS Record Layer security association. RFC 5077 [RFC5077] borrows from the session resumption design idea, but the server encapsulates all state information into a ticket instead of caching it. An attacker who is able to observe the protocol exchanges between the TLS client and the TLS server is able to link the initial exchange to subsequently resumed TLS sessions when the session_id and the ticket are exchanged in the clear (which is the case with data exchanged in the initial handshake messages).
作为一个例子，考虑传输层安全（TLS）会话恢复[RCF5246]或没有服务器端状态的TLS会话恢复[RCF5077 ]。在RFC 5246[RFC5246]中，服务器在ServerHello消息中向客户端提供会话id，并缓存主密钥以供以后交换。当客户端启动与服务器的新连接时，它会在其ClientHello消息中重新使用先前获得的会话id。服务器同意通过使用相同的会话id和先前存储的主密钥来恢复会话，以生成TLS记录层安全关联。RFC 5077[RFC5077]借鉴了会话恢复的设计思想，但服务器将所有状态信息封装到一个票证中，而不是缓存它。能够观察TLS客户端和TLS服务器之间的协议交换的攻击者能够将初始交换链接到随后恢复的TLS会话，当会话id和票据在清除状态下交换时（初始握手消息中交换的数据就是这种情况）。
In theory, any observer or attacker that receives an initiator's communications can engage in correlation. The extent of the potential for correlation will depend on what data the entity receives from the initiator and has access to otherwise. Often, intermediaries only require a small amount of information for message routing and/or security. In theory, protocol mechanisms could ensure that end-to-end information is not made accessible to these entities, but in practice the difficulty of deploying end-to-end security procedures, additional messaging or computational overhead, and other business or legal requirements often slow or prevent the deployment of end-to-end security mechanisms, giving intermediaries greater exposure to initiators' data than is strictly necessary from a technical point of view.
理论上，接收发起者通信的任何观察者或攻击者都可以参与关联。关联可能性的程度将取决于实体从发起方接收到的数据以及是否有权访问这些数据。通常，中介机构只需要少量信息来实现消息路由和/或安全性。理论上，协议机制可以确保这些实体无法访问端到端信息，但在实践中，部署端到端安全程序的难度、额外的消息传递或计算开销以及其他业务或法律要求往往会减慢或阻止端到端安全机制的部署，从技术角度来看，给中介机构提供比严格必要的更大的披露发起人数据的机会。
Identification is the linking of information to a particular individual to infer an individual's identity or to allow the inference of an individual's identity. In some contexts, it is perfectly legitimate to identify individuals, whereas in others, identification may potentially stifle individuals' activities or expression by inhibiting their ability to be anonymous or pseudonymous. Identification also makes it easier for individuals to be explicitly controlled by others (e.g., governments) and to be treated differentially compared to other individuals.
身份识别是将信息与特定个人联系起来，以推断个人身份或允许推断个人身份。在某些情况下，识别个人是完全合法的，而在另一些情况下，识别可能会抑制个人匿名或假名的能力，从而潜在地扼杀个人的活动或表达。身份识别还使个人更容易受到其他人（如政府）的明确控制，并且与其他个人相比更容易受到区别对待。
Many protocols provide functionality to convey the idea that some means has been provided to validate that entities are who they claim to be. Often, this is accomplished with cryptographic authentication. Furthermore, many protocol identifiers, such as those used in SIP or the Extensible Messaging and Presence Protocol (XMPP), may allow for the direct identification of individuals. Protocol identifiers may also contribute indirectly to identification via correlation. For example, a web site that does not directly authenticate users may be able to match its HTTP header logs with logs from another site that does authenticate users, rendering users on the first site identifiable.
许多协议都提供了一些功能来传达这样一种理念，即已经提供了一些方法来验证实体是否就是它们所声称的实体。通常，这是通过加密身份验证实现的。此外，许多协议标识符，例如SIP或可扩展消息传递和存在协议（XMPP）中使用的那些，可以允许直接识别个人。协议标识符还可以通过相关性间接地帮助识别。例如，不直接对用户进行身份验证的网站可能能够将其HTTP头日志与另一个对用户进行身份验证的网站的日志相匹配，从而使第一个网站上的用户可以识别。
As with correlation, any observer or attacker may be able to engage in identification, depending on the information about the initiator that is available via the protocol mechanism or other channels.
与关联一样，任何观察者或攻击者都可以进行身份识别，这取决于通过协议机制或其他渠道获得的有关启动器的信息。
Secondary use is the use of collected information about an individual without the individual's consent for a purpose different from that for which the information was collected. Secondary use may violate people's expectations or desires. The potential for secondary use
二次使用是指未经个人同意，将收集的个人信息用于与信息收集目的不同的目的。二次使用可能违反人们的期望或愿望。二次使用的潜力
can generate uncertainty as to how one's information will be used in the future, potentially discouraging information exchange in the first place. Secondary use encompasses any use of data, including disclosure.
可能会产生未来如何使用信息的不确定性，可能会首先阻碍信息交流。二次使用包括数据的任何使用，包括披露。
One example of secondary use would be an authentication server that uses a network access server's Access-Requests to track an initiator's location. Any observer or attacker could potentially make unwanted secondary uses of initiators' data. Protecting against secondary use is typically outside the scope of IETF protocols.
二次使用的一个示例是身份验证服务器，它使用网络访问服务器的访问请求来跟踪启动器的位置。任何观察者或攻击者都可能对启动器的数据进行不必要的二次使用。防止二次使用通常不在IETF协议的范围内。
Disclosure is the revelation of information about an individual that affects the way others judge the individual. Disclosure can violate individuals' expectations of the confidentiality of the data they share. The threat of disclosure may deter people from engaging in certain activities for fear of reputational harm, or simply because they do not wish to be observed.
披露是对个人信息的披露，影响他人对个人的判断。披露可能违反个人对共享数据保密性的期望。披露的威胁可能会阻止人们从事某些活动，因为他们害怕名誉受损，或者仅仅因为他们不希望被观察。
Any observer or attacker that receives data about an initiator may engage in disclosure. Sometimes disclosure is unintentional because system designers do not realize that information being exchanged relates to individuals. The most common way for protocols to limit disclosure is by providing access control mechanisms (discussed in Section 5.2.5). A further example is provided by the IETF geolocation privacy architecture [RFC6280], which supports a way for users to express a preference that their location information not be disclosed beyond the intended recipient.
任何接收到有关启动器的数据的观察者或攻击者都可能参与泄露。有时披露是无意的，因为系统设计者没有意识到所交换的信息与个人有关。协议限制披露的最常见方式是提供访问控制机制（在第5.2.5节中讨论）。IETF地理位置隐私体系结构[RFC6280]提供了另一个示例，该体系结构支持用户表达其位置信息不被披露到预期接收者之外的偏好的方式。
Exclusion is the failure to allow individuals to know about the data that others have about them and to participate in its handling and use. Exclusion reduces accountability on the part of entities that maintain information about people and creates a sense of vulnerability in relation to individuals' ability to control how information about them is collected and used.
排除是指不允许个人了解其他人拥有的关于他们的数据并参与其处理和使用。排斥减少了维护有关人员信息的实体的责任，并在个人控制如何收集和使用有关人员信息的能力方面产生了脆弱感。
The most common way for Internet protocols to be involved in enforcing exclusion is through access control mechanisms. The presence architecture developed in the IETF is a good example where individuals are included in the control of information about them. Using a rules expression language (e.g., presence authorization rules [RFC5025]), presence clients can authorize the specific conditions under which their presence information may be shared.
Internet协议参与强制排除的最常见方式是通过访问控制机制。IETF中开发的存在体系结构是一个很好的例子，其中个人被包括在关于他们的信息控制中。使用规则表达语言（例如，状态授权规则[RFC5025]），状态客户端可以授权共享其状态信息的特定条件。
Exclusion is primarily considered problematic when the recipient fails to involve the initiator in decisions about data collection, handling, and use. Eavesdroppers engage in exclusion by their very nature, since their data collection and handling practices are covert.
当接收者未能让发起人参与有关数据收集、处理和使用的决策时，排除主要被认为是有问题的。窃听者出于其自身的性质而进行排斥，因为他们的数据收集和处理行为是隐蔽的。
Privacy is notoriously difficult to measure and quantify. The extent to which a particular protocol, system, or architecture "protects" or "enhances" privacy is dependent on a large number of factors relating to its design, use, and potential misuse. However, there are certain widely recognized classes of mitigations against the threats discussed in Section 5. This section describes three categories of relevant mitigations: (1) data minimization, (2) user participation, and (3) security. The privacy mitigations described in this section can loosely be mapped to existing privacy principles, such as the Fair Information Practices, but they have been adapted to fit the target audience of this document.
众所周知，隐私很难衡量和量化。特定协议、系统或架构“保护”或“增强”隐私的程度取决于与其设计、使用和潜在误用相关的大量因素。但是，针对第5节中讨论的威胁，存在某些公认的缓解措施。本节介绍三类相关缓解措施：（1）数据最小化，（2）用户参与，以及（3）安全性。本节中描述的隐私缓解措施可以松散地映射到现有的隐私原则，如公平信息实践，但它们已经进行了调整，以适合本文档的目标受众。
Data minimization refers to collecting, using, disclosing, and storing the minimal data necessary to perform a task. Reducing the amount of data exchanged reduces the amount of data that can be misused or leaked.
数据最小化是指收集、使用、披露和存储执行任务所需的最少数据。减少交换的数据量可以减少可能被误用或泄漏的数据量。
Data minimization can be effectuated in a number of different ways, including by limiting collection, use, disclosure, retention, identifiability, sensitivity, and access to personal data. Limiting the data collected by protocol elements to only what is necessary (collection limitation) is the most straightforward way to help reduce privacy risks associated with the use of the protocol. In some cases, protocol designers may also be able to recommend limits to the use or retention of data, although protocols themselves are not often capable of controlling these properties.
数据最小化可以通过多种不同的方式实现，包括限制个人数据的收集、使用、披露、保留、可识别性、敏感性和访问。将协议元素收集的数据限制在必要的范围内（收集限制）是帮助减少与协议使用相关的隐私风险的最直接的方法。在某些情况下，协议设计者还可以建议限制数据的使用或保留，尽管协议本身通常无法控制这些属性。
However, the most direct application of data minimization to protocol design is limiting identifiability. Reducing the identifiability of data by using pseudonyms or no identifiers at all helps to weaken the link between an individual and his or her communications. Allowing for the periodic creation of new or randomized identifiers reduces the possibility that multiple protocol interactions or communications can be correlated back to the same individual. The following sections explore a number of different properties related to identifiability that protocol designers may seek to achieve.
然而，数据最小化在协议设计中最直接的应用是限制可识别性。通过使用假名或根本不使用标识符来降低数据的可识别性有助于削弱个人与其通信之间的联系。允许定期创建新的或随机的标识符，减少了多个协议交互或通信可以关联回同一个人的可能性。以下各节将探讨协议设计者可能寻求实现的与可识别性相关的许多不同属性。
Data minimization mitigates the following threats: surveillance, stored data compromise, correlation, identification, secondary use, and disclosure.
数据最小化可缓解以下威胁：监视、存储数据泄露、关联、识别、二次使用和泄露。
To enable anonymity of an individual, there must exist a set of individuals that appear to have the same attribute(s) as the individual. To the attacker or the observer, these individuals must appear indistinguishable from each other. The set of all such individuals is known as the anonymity set, and membership of this set may vary over time.
要实现个人的匿名性，必须存在一组看起来与个人具有相同属性的个人。对于攻击者或观察者来说，这些个体必须看起来彼此无法区分。所有这些个体的集合称为匿名集合，该集合的成员可能随时间而变化。
The composition of the anonymity set depends on the knowledge of the observer or attacker. Thus, anonymity is relative with respect to the observer or attacker. An initiator may be anonymous only within a set of potential initiators -- its initiator anonymity set -- which itself may be a subset of all individuals that may initiate communications. Conversely, a recipient may be anonymous only within a set of potential recipients -- its recipient anonymity set. Both anonymity sets may be disjoint, may overlap, or may be the same.
匿名集的组成取决于观察者或攻击者的知识。因此，匿名性相对于观察者或攻击者而言是相对的。一个发起者可能只有在一组潜在的发起者中是匿名的——它的发起者匿名集——它本身可能是所有可能发起通信的个人的子集。相反，一个接收者可能只在一组潜在接收者中是匿名的——它的接收者匿名集。两个匿名集可以是不相交的、重叠的或相同的。
As an example, consider RFC 3325 (P-Asserted-Identity (PAI)) [RFC3325], an extension for the Session Initiation Protocol (SIP) that allows an individual, such as a Voice over IP (VoIP) caller, to instruct an intermediary that he or she trusts not to populate the SIP From header field with the individual's authenticated and verified identity. The recipient of the call, as well as any other entity outside of the individual's trust domain, would therefore only learn that the SIP message (typically a SIP INVITE) was sent with a header field 'From: "Anonymous" <sip:anonymous@anonymous.invalid>' rather than the individual's address-of-record, which is typically thought of as the "public address" of the user. When PAI is used, the individual becomes anonymous within the initiator anonymity set that is populated by every individual making use of that specific intermediary.
作为一个例子，考虑RFC 3325（P-断言身份（拜县））[RFC33 25]，会话启动协议（SIP）的扩展，允许个人，例如IP语音（VoIP）调用方，指示中介人他或她不信任用个人的经过验证和验证的身份从SIP字段填充SIP。因此，呼叫的接收者以及个人信任域之外的任何其他实体只能了解到SIP消息（通常是SIP INVITE）是通过“来自：”匿名“<SIP:anonymous@anonymous.invalid>而不是个人的记录地址，这通常被认为是用户的“公共地址”。使用PAI时，个人在发起人匿名集内成为匿名者，该匿名集由每个使用该特定中介的个人填充。
Note that this example ignores the fact that the recipient may infer or obtain personal data from the other SIP payloads (e.g., SIP Via and Contact headers, the Session Description Protocol (SDP)). The implication is that PAI only attempts to address a particular threat, namely the disclosure of identity (in the From header) with respect to the recipient. This caveat makes the analysis of the specific protocol extension easier but cannot be assumed when conducting analysis of an entire architecture.
注意，该示例忽略了接收者可以从其他SIP有效载荷（例如，SIP Via和联系人报头、会话描述协议（SDP））推断或获取个人数据的事实。这意味着PAI仅试图解决特定威胁，即披露接收者的身份（在From标题中）。此警告使特定协议扩展的分析更容易，但在对整个体系结构进行分析时无法假设。
In the context of Internet protocols, almost all identifiers can be nicknames or pseudonyms, since there is typically no requirement to use personal names in protocols. However, in certain scenarios it is reasonable to assume that personal names will be used (with vCard [RFC6350], for example).
在互联网协议的上下文中，几乎所有标识符都可以是昵称或假名，因为协议中通常不要求使用个人名称。但是，在某些情况下，可以合理地假设将使用个人姓名（例如，vCard[RFC6350]）。
Pseudonymity is strengthened when less personal data can be linked to the pseudonym; when the same pseudonym is used less often and across fewer contexts; and when independently chosen pseudonyms are more frequently used for new actions (making them, from an observer's or attacker's perspective, unlinkable).
当更少的个人数据可以链接到笔名时，笔名会得到加强；当同一笔名在较少的上下文中使用较少时；当独立选择的笔名更频繁地用于新操作时（从观察者或攻击者的角度来看，使它们无法链接）。
For Internet protocols, the following are important considerations: whether protocols allow pseudonyms to be changed without human interaction, the default length of pseudonym lifetimes, to whom pseudonyms are exposed, how individuals are able to control disclosure, how often pseudonyms can be changed, and the consequences of changing them.
对于互联网协议，以下是重要的考虑因素：协议是否允许在没有人的交互的情况下更改假名、假名的默认使用寿命、假名暴露给谁、个人如何控制披露、更改假名的频率以及更改假名的后果。
An initiator has identity confidentiality when any party other than the recipient cannot sufficiently identify the initiator within the anonymity set. The size of the anonymity set has a direct impact on identity confidentiality, since the smaller the set is, the easier it is to identify the initiator. Identity confidentiality aims to provide a protection against eavesdroppers and intermediaries rather than against the intended communication endpoints.
当接收方以外的任何一方无法在匿名集内充分识别发起方时，发起方具有身份保密性。匿名集的大小对身份机密性有直接影响，因为匿名集越小，越容易识别发起方。身份保密旨在提供针对窃听者和中介的保护，而不是针对预期的通信端点。
As an example, consider the network access authentication procedures utilizing the Extensible Authentication Protocol (EAP) [RFC3748]. EAP includes an identity exchange where the Identity Response is primarily used for routing purposes and selecting which EAP method to use. Since EAP Identity Requests and Identity Responses are sent in cleartext, eavesdroppers and intermediaries along the communication path between the EAP peer and the EAP server can snoop on the identity, which is encoded in the form of the Network Access Identifier (NAI) as defined in RFC 4282 [RFC4282]. To address this threat, as discussed in RFC 4282 [RFC4282], the username part of the NAI (but not the realm part) can be hidden from these eavesdroppers and intermediaries with the cryptographic support offered by EAP methods. Identity confidentiality has become a recommended design criteria for EAP (see [RFC4017]). The EAP method for 3rd Generation Authentication and Key Agreement (EAP-AKA) [RFC4187], for example, protects the EAP peer's identity against passive adversaries by utilizing temporal identities. The EAP-Internet Key Exchange
作为一个例子，考虑使用可扩展认证协议（EAP）[RCF348]的网络接入认证过程。EAP包括一个标识交换，其中标识响应主要用于路由目的和选择要使用的EAP方法。由于EAP身份请求和身份响应以明文形式发送，因此沿着EAP对等方和EAP服务器之间的通信路径的窃听者和中介可以窥探该身份，该身份以RFC 4282[RFC4282]中定义的网络访问标识符（NAI）的形式编码。为了应对这种威胁，如RFC 4282[RFC4282]中所述，可以使用EAP方法提供的加密支持，对这些窃听者和中介隐藏NAI的用户名部分（而不是领域部分）。身份保密性已成为EAP的推荐设计标准（见[RFC4017]）。例如，用于第三代认证和密钥协商的EAP方法（EAP-AKA）[RFC4187]通过利用时间身份保护EAP对等方的身份免受被动对手的攻击。EAP因特网密钥交换
Protocol version 2 (EAP-IKEv2) method [RFC5106] is an example of an EAP method that offers protection against active attackers with regard to the individual's identity.
协议版本2（EAP-IKEv2）方法[RFC5106]是EAP方法的一个示例，该方法针对个人身份的主动攻击者提供保护。
Modern systems are increasingly relying on multi-party transactions to authenticate individuals. Many of these systems make use of an identity provider that is responsible for providing AAA functionality to relying parties that offer some protected resources. To facilitate these functions, an identity provider will usually go through a process of verifying the individual's identity and issuing credentials to the individual. When an individual seeks to make use of a service provided by the relying party, the relying party relies on the authentication assertions provided by its identity provider. Note that in more sophisticated scenarios the authentication assertions are traits that demonstrate the individual's capabilities and roles. The authorization responsibility may also be shared between the identity provider and the relying party and does not necessarily need to reside only with the identity provider.
现代系统越来越依赖多方交易来认证个人。这些系统中的许多都使用身份提供者，该提供者负责向提供某些受保护资源的依赖方提供AAA功能。为了促进这些功能，身份提供者通常会经历一个验证个人身份并向个人颁发凭据的过程。当个人试图使用依赖方提供的服务时，依赖方依赖其身份提供者提供的身份验证断言。请注意，在更复杂的场景中，身份验证断言是展示个人能力和角色的特征。授权责任也可以在身份提供者和依赖方之间共享，并且不一定只需要与身份提供者驻留在一起。
Such systems have the ability to support a number of properties that minimize data collection in different ways:
此类系统能够支持以不同方式最小化数据收集的许多属性：
In certain use cases, relying parties do not need to know the real name or date of birth of an individual (for example, when the individual's age is the only attribute that needs to be authenticated).
在某些用例中，依赖方不需要知道个人的真实姓名或出生日期（例如，当个人的年龄是唯一需要验证的属性时）。
Relying parties that collude can be prevented from using an individual's credentials to track the individual. That is, two different relying parties can be prevented from determining that the same individual has authenticated to both of them. This typically requires identity management protocol support as well as support by both the relying party and the identity provider.
可以防止串通的依赖方使用个人的凭证跟踪个人。也就是说，可以防止两个不同的依赖方确定同一个人已经向他们两人进行了身份验证。这通常需要身份管理协议支持以及依赖方和身份提供者的支持。
The identity provider can be prevented from knowing which relying parties an individual interacted with. This requires, at a minimum, avoiding direct communication between the identity provider and the relying party at the time when access to a resource by the initiator is made.
可以防止身份提供者知道个人与哪些依赖方进行了交互。这至少要求在发起方访问资源时避免身份提供者和依赖方之间的直接通信。
As explained in Section 5.2.5, data collection and use that happen "in secret", without the individual's knowledge, are apt to violate the individual's expectation of privacy and may create incentives for misuse of data. As a result, privacy regimes tend to include
如第5.2.5节所述，在个人不知情的情况下“秘密”收集和使用数据容易侵犯个人对隐私的期望，并可能导致滥用数据。因此，隐私制度往往包括
provisions to require informing individuals about data collection and use and involving them in decisions about the treatment of their data. In an engineering context, supporting the goal of user participation usually means providing ways for users to control the data that is shared about them. It may also mean providing ways for users to signal how they expect their data to be used and shared. Different protocol and architectural designs can make supporting user participation (for example, the ability to support a dialog box for user interaction) easier or harder; for example, OAuth-based services may have more natural hooks for user input than AAA services.
规定要求向个人通报数据收集和使用情况，并让他们参与有关数据处理的决定。在工程环境中，支持用户参与的目标通常意味着为用户提供控制共享数据的方法。它还可能意味着为用户提供方式，以表明他们希望如何使用和共享他们的数据。不同的协议和架构设计可以使支持用户参与（例如，支持用户交互对话框的能力）变得更容易或更难；例如，基于OAuth的服务可能比AAA服务具有更自然的用户输入挂钩。
User participation mitigates the following threats: surveillance, secondary use, disclosure, and exclusion.
用户参与缓解了以下威胁：监视、二次使用、披露和排除。
Keeping data secure at rest and in transit is another important component of privacy protection. As they are described in Section 2 of [RFC3552], a number of security goals also serve to enhance privacy:
保持数据在静止和传输过程中的安全是隐私保护的另一个重要组成部分。正如[RFC3552]第2节所述，许多安全目标也有助于增强隐私：
o Confidentiality: Keeping data secret from unintended listeners.
o 保密性：对无意的侦听器保密数据。
o Peer entity authentication: Ensuring that the endpoint of a communication is the one that is intended (in support of maintaining confidentiality).
o 对等实体身份验证：确保通信的端点是预期的端点（支持维护机密性）。
o Unauthorized usage: Limiting data access to only those users who are authorized. (Note that this goal also falls within data minimization.)
o 未经授权的使用：将数据访问限制为仅授权的用户。（请注意，此目标也属于数据最小化的范畴。）
o Inappropriate usage: Limiting how authorized users can use data. (Note that this goal also falls within data minimization.)
o 不当使用：限制授权用户使用数据的方式。（请注意，此目标也属于数据最小化的范畴。）
Note that even when these goals are achieved, the existence of items of interest -- attributes, identifiers, identities, communications, actions (such as the sending or receiving of a communication), or anything else an attacker or observer might be interested in -- may still be detectable, even if they are not readable. Thus, undetectability, in which an observer or attacker cannot sufficiently distinguish whether an item of interest exists or not, may be considered as a further security goal (albeit one that can be extremely difficult to accomplish).
请注意，即使实现了这些目标，感兴趣项目的存在——属性、标识符、身份、通信、操作（如通信的发送或接收）或攻击者或观察者可能感兴趣的任何其他内容——仍然可以检测到，即使它们不可读。因此，不可检测性（即观察者或攻击者无法充分区分感兴趣的项目是否存在）可被视为进一步的安全目标（尽管这可能极难实现）。
Detection of the protocols or applications in use via traffic analysis may be particularly difficult to defend against. As with the anonymity of individuals, achieving "protocol anonymity" requires that multiple protocols or applications exist that appear to have the
通过流量分析检测正在使用的协议或应用程序可能特别难以防范。与个人的匿名性一样，实现“协议匿名性”需要存在多个协议或应用程序，这些协议或应用程序似乎具有
same attributes -- packet sizes, content, token locations, or inter-packet timing, for example. An attacker or observer will not be able to use traffic analysis to identify which protocol or application is in use if multiple protocols or applications are indistinguishable.
相同的属性——例如，包大小、内容、令牌位置或包间定时。如果无法区分多个协议或应用程序，则攻击者或观察者将无法使用流量分析来识别正在使用的协议或应用程序。
Defending against the threat of traffic analysis will be possible to different extents for different protocols, may depend on implementation- or use-specific details, and may depend on which other protocols already exist and whether they share similar traffic characteristics. The defenses will also vary relative to what the protocol is designed to do; for example, in some situations randomizing packet sizes, timing, or token locations will reduce the threat of traffic analysis, whereas in other situations (real-time communications, for example) holding some or all of those factors constant is a more appropriate defense. See "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP" [RFC6562] for an example of how these kinds of trade-offs should be evaluated.
对于不同的协议，可以在不同程度上防御流量分析的威胁，这可能取决于实现或使用特定的细节，也可能取决于已经存在哪些其他协议以及它们是否具有相似的流量特征。相对于协议的设计目的，防御措施也会有所不同；例如，在某些情况下，随机化数据包大小、定时或令牌位置将减少流量分析的威胁，而在其他情况下（例如，实时通信），保持这些因素中的一些或全部不变是更合适的防御措施。有关如何评估此类权衡的示例，请参见“带安全RTP的可变比特率音频使用指南”[RFC6562]。
By providing proper security protection, the following threats can be mitigated: surveillance, stored data compromise, misattribution, secondary use, disclosure, and intrusion.
通过提供适当的安全保护，可以缓解以下威胁：监视、存储数据泄露、错误归因、二次使用、泄露和入侵。
This section provides guidance for document authors in the form of a questionnaire about a protocol being designed. The questionnaire may be useful at any point in the design process, particularly after document authors have developed a high-level protocol model as described in [RFC4101].
本节以调查问卷的形式为文件作者提供关于正在设计的协议的指导。问卷在设计过程中的任何时候都可能有用，尤其是在文档作者开发了[RFC4101]中所述的高级协议模型之后。
Note that the guidance provided in this section does not recommend specific practices. The range of protocols developed in the IETF is too broad to make recommendations about particular uses of data or how privacy might be balanced against other design goals. However, by carefully considering the answers to each question, document authors should be able to produce a comprehensive analysis that can serve as the basis for discussion of whether the protocol adequately protects against privacy threats. This guidance is meant to help the thought process of privacy analysis; it does not provide specific directions for how to write a privacy considerations section.
请注意，本节中提供的指南并不推荐具体做法。IETF中开发的协议范围太广，无法就数据的特定用途或隐私如何与其他设计目标相平衡提出建议。然而，通过仔细考虑每个问题的答案，文档作者应该能够进行全面的分析，作为讨论协议是否充分保护隐私免受威胁的基础。本指南旨在帮助隐私分析的思维过程；它没有提供如何编写隐私注意事项部分的具体说明。
The framework is divided into four sections: three sections that address each of the mitigation classes from Section 6, plus a general section. Security is not fully elaborated, since substantial guidance already exists in [RFC3552].
该框架分为四个部分：三个部分涉及第6节中的每个缓解类别，外加一个一般部分。由于[RFC3552]中已经存在实质性指导，因此安全性未得到充分阐述。
a. Identifiers. What identifiers does the protocol use for distinguishing initiators of communications? Does the protocol use identifiers that allow different protocol interactions to be correlated? What identifiers could be omitted or be made less identifying while still fulfilling the protocol's goals?
a. 标识符。协议使用什么标识符来区分通信的发起者？协议是否使用允许不同协议交互关联的标识符？在仍然实现协议目标的情况下，哪些标识符可以省略或减少识别？
b. Data. What information does the protocol expose about individuals, their devices, and/or their device usage (other than the identifiers discussed in (a))? To what extent is this information linked to the identities of the individuals? How does the protocol combine personal data with the identifiers discussed in (a)?
b. 数据协议公开了关于个人、他们的设备和/或他们的设备使用的哪些信息（除了（a）中讨论的标识符）？这些信息在多大程度上与个人身份有关？协议如何将个人数据与（a）中讨论的标识符相结合？
c. Observers. Which information discussed in (a) and (b) is exposed to each other protocol entity (i.e., recipients, intermediaries, and enablers)? Are there ways for protocol implementers to choose to limit the information shared with each entity? Are there operational controls available to limit the information shared with each entity?
c. 观察员。（a）和（b）中讨论的哪些信息向其他协议实体（即接收方、中间方和启用方）公开？协议实施者是否有办法选择限制与每个实体共享的信息？是否有可用于限制与每个实体共享的信息的操作控制？
d. Fingerprinting. In many cases, the specific ordering and/or occurrences of information elements in a protocol allow users, devices, or software using the protocol to be fingerprinted. Is this protocol vulnerable to fingerprinting? If so, how? Can it be designed to reduce or eliminate the vulnerability? If not, why not?
d. 指纹识别。在许多情况下，协议中信息元素的特定顺序和/或出现允许对使用协议的用户、设备或软件进行指纹识别。此协议易受指纹识别攻击吗？如果是，怎么做？其设计是否可以减少或消除漏洞？若否，原因为何？
e. Persistence of identifiers. What assumptions are made in the protocol design about the lifetime of the identifiers discussed in (a)? Does the protocol allow implementers or users to delete or replace identifiers? How often does the specification recommend deleting or replacing identifiers by default? Can the identifiers, along with other state information, be set to automatically expire?
e. 标识符的持久性。在协议设计中，对（a）中讨论的标识符的寿命做出了哪些假设？协议是否允许实现者或用户删除或替换标识符？规范建议默认情况下删除或替换标识符的频率是多少？标识符以及其他状态信息是否可以设置为自动过期？
f. Correlation. Does the protocol allow for correlation of identifiers? Are there expected ways that information exposed by the protocol will be combined or correlated with information obtained outside the protocol? How will such combination or correlation facilitate fingerprinting of a user, device, or application? Are there expected combinations or correlations with outside data that will make users of the protocol more identifiable?
f. 相关性协议是否允许标识符之间的关联？是否存在协议公开的信息与协议外获得的信息组合或关联的预期方式？这种组合或关联将如何促进用户、设备或应用程序的指纹识别？是否存在与外部数据的预期组合或关联，从而使协议的用户更易于识别？
g. Retention. Does the protocol or its anticipated uses require that the information discussed in (a) or (b) be retained by recipients, intermediaries, or enablers? If so, why? Is the retention expected to be persistent or temporary?
g. 保持协议或其预期用途是否要求（a）或（b）中讨论的信息由接收者、中间人或使能者保留？若然，原因为何？预计保留是持续的还是临时的？
a. User control. What controls or consent mechanisms does the protocol define or require before personal data or identifiers are shared or exposed via the protocol? If no such mechanisms or controls are specified, is it expected that control and consent will be handled outside of the protocol?
a. 用户控制。在通过协议共享或公开个人数据或标识符之前，协议定义或要求哪些控制或同意机制？如果未规定此类机制或控制措施，是否预期控制和同意将在协议之外处理？
b. Control over sharing with individual recipients. Does the protocol provide ways for initiators to share different information with different recipients? If not, are there mechanisms that exist outside of the protocol to provide initiators with such control?
b. 控制与单个收件人的共享。该协议是否为发起者提供了与不同接收者共享不同信息的方法？如果没有，是否存在协议之外的机制为启动器提供此类控制？
c. Control over sharing with intermediaries. Does the protocol provide ways for initiators to limit which information is shared with intermediaries? If not, are there mechanisms that exist outside of the protocol to provide users with such control? Is it expected that users will have relationships that govern the use of the information (contractual or otherwise) with those who operate these intermediaries?
c. 控制与中介机构的共享。协议是否为启动器提供了限制与中介共享哪些信息的方法？如果没有，是否存在协议之外的机制为用户提供此类控制？是否预期用户将与这些中介机构的运营商建立管理信息使用（合同或其他）的关系？
d. Preference expression. Does the protocol provide ways for initiators to express individuals' preferences to recipients or intermediaries with regard to the collection, use, or disclosure of their personal data?
d. 偏好表达。该协议是否为发起人提供了方式，以表达个人在收集、使用或披露个人数据方面对接收人或中介的偏好？
a. Surveillance. How do the protocol's security considerations prevent surveillance, including eavesdropping and traffic analysis? Does the protocol leak information that can be observed through traffic analysis, such as by using a fixed token at fixed offsets, or packet sizes or timing that allow observers to determine characteristics of the traffic (e.g., which protocol is in use or whether the traffic is part of a real-time flow)?
a. 监控协议的安全考虑如何防止监视，包括窃听和流量分析？协议是否泄漏了可通过流量分析观察到的信息，例如通过使用固定偏移量的固定令牌，或允许观察者确定流量特征的数据包大小或定时（例如，正在使用哪个协议或流量是否为实时流的一部分）？
b. Stored data compromise. How do the protocol's security considerations prevent or mitigate stored data compromise?
b. 存储数据泄露。协议的安全考虑如何防止或缓解存储数据泄露？
c. Intrusion. How do the protocol's security considerations prevent or mitigate intrusion, including denial-of-service attacks and unsolicited communications more generally?
c. 入侵协议的安全考虑因素如何防止或减轻入侵，包括更普遍的拒绝服务攻击和未经请求的通信？
d. Misattribution. How do the protocol's mechanisms for identifying and/or authenticating individuals prevent misattribution?
d. 错误归因。协议中用于识别和/或认证个人的机制如何防止错误归因？
a. Trade-offs. Does the protocol make trade-offs between privacy and usability, privacy and efficiency, privacy and implementability, or privacy and other design goals? Describe the trade-offs and the rationale for the design chosen.
a. 权衡。协议是否在隐私和可用性、隐私和效率、隐私和可实现性、隐私和其他设计目标之间进行了权衡？描述所选设计的权衡和基本原理。
b. Defaults. If the protocol can be operated in multiple modes or with multiple configurable options, does the default mode or option minimize the amount, identifiability, and persistence of the data and identifiers exposed by the protocol? Does the default mode or option maximize the opportunity for user participation? Does it provide the strictest security features of all the modes/options? If the answer to any of these questions is no, explain why less protective defaults were chosen.
b. 默认值。如果协议可以在多种模式下运行或使用多种可配置选项运行，那么默认模式或选项是否会最小化协议公开的数据和标识符的数量、可识别性和持久性？默认模式或选项是否最大化了用户参与的机会？它是否提供了所有模式/选项中最严格的安全功能？如果上述任何一个问题的答案都是否定的，请解释为什么选择保护性较低的默认值。
The following section gives an example of the threat analysis and threat mitigations recommended by this document. It covers a particularly difficult application protocol, presence, to try to demonstrate these principles on an architecture that is vulnerable to many of the threats described above. This text is not intended as an example of a privacy considerations section that might appear in an IETF specification, but rather as an example of the thinking that should go into the design of a protocol when considering privacy as a first principle.
以下部分给出了本文件建议的威胁分析和威胁缓解示例。它涵盖了一个特别困难的应用程序协议presence，试图在易受上述许多威胁影响的体系结构上演示这些原则。本文不打算作为可能出现在IETF规范中的隐私考虑部分的示例，而是作为将隐私作为第一原则考虑时，协议设计中应考虑的思想示例。
A presence service, as defined in the abstract in [RFC2778], allows users of a communications service to monitor one another's availability and disposition in order to make decisions about communicating. Presence information is highly dynamic and generally characterizes whether a user is online or offline, busy or idle, away from communications devices or nearby, and the like. Necessarily, this information has certain privacy implications, and from the start the IETF approached this work with the aim of providing users with the controls to determine how their presence information would be shared. The Common Profile for Presence (CPP) [RFC3859] defines a set of logical operations for delivery of presence information. This abstract model is applicable to multiple presence systems. The SIP
[RFC2778]摘要中定义的状态服务允许通信服务的用户监控彼此的可用性和配置，以便做出通信决策。存在信息是高度动态的，并且通常表征用户是在线还是离线、忙碌还是空闲、远离通信设备还是附近等等。当然，这些信息具有一定的隐私含义，IETF从一开始就着手这项工作，目的是为用户提供控制，以确定如何共享他们的状态信息。状态通用配置文件（CPP）[RFC3859]定义了一组用于传递状态信息的逻辑操作。该抽象模型适用于多存在系统。啜饮
for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence system [RFC3856] uses CPP as its baseline architecture, and the presence operations in the Extensible Messaging and Presence Protocol (XMPP) have also been mapped to CPP [RFC3922].
对于即时消息和状态利用扩展（简单）状态系统[RFC3856]使用CPP作为其基线架构，可扩展消息和状态协议（XMPP）中的状态操作也已映射到CPP[RFC3922]。
The fundamental architecture defined in RFC 2778 and RFC 3859 is a mediated one. Clients (presentities in RFC 2778 terms) publish their presence information to presence servers, which in turn distribute information to authorized watchers. Presence servers thus retain presence information for an interval of time, until it either changes or expires, so that it can be revealed to authorized watchers upon request. This architecture mirrors existing pre-standard deployment models. The integration of an explicit authorization mechanism into the presence architecture has been widely successful in involving the end users in the decision-making process before sharing information. Nearly all presence systems deployed today provide such a mechanism, typically through a reciprocal authorization system by which a pair of users, when they agree to be "buddies", consent to divulge their presence information to one another. Buddylists are managed by servers but controlled by end users. Users can also explicitly block one another through a similar interface, and in some deployments it is desirable to provide "polite blocking" of various kinds.
RFC 2778和RFC 3859中定义的基本架构是中介架构。客户机（RFC 2778术语中的实体）将其状态信息发布到状态服务器，然后服务器将信息分发给授权的观察者。因此，状态服务器会将状态信息保留一段时间，直到信息更改或过期，以便根据请求将其显示给授权的观察者。此体系结构反映了现有的预标准部署模型。在共享信息之前，将显式授权机制集成到存在体系结构中已广泛成功地让最终用户参与决策过程。现在部署的几乎所有状态系统都提供了这样一种机制，通常是通过一种互惠授权系统，通过该系统，两个用户在同意成为“好友”时，会同意将其状态信息泄露给另一个用户。BuddyList由服务器管理，但由最终用户控制。用户还可以通过类似的接口显式地相互阻塞，在某些部署中，需要提供各种类型的“礼貌阻塞”。
From a perspective of privacy design, however, the classical presence architecture represents nearly a worst-case scenario. In terms of data minimization, presentities share their sensitive information with presence services, and while services only share this presence information with watchers authorized by the user, no technical mechanism constrains those watchers from relaying presence to further third parties. Any of these entities could conceivably log or retain presence information indefinitely. The sensitivity cannot be mitigated by rendering the user anonymous, as it is indeed the purpose of the system to facilitate communications between users who know one another. The identifiers employed by users are long-lived and often contain personal information, including personal names and the domains of service providers. While users do participate in the construction of buddylists and blacklists, they do so with little prospect for accountability: the user effectively throws their presence information over the wall to a presence server that in turn distributes the information to watchers. Users typically have no way to verify that presence is being distributed only to authorized watchers, especially as it is the server that authenticates watchers, not the end user. Moreover, connections between the server and all publishers and consumers of presence data are an attractive target for eavesdroppers and require strong confidentiality mechanisms, though again the end user has no way to verify what mechanisms are in place between the presence server and a watcher.
然而，从隐私设计的角度来看，经典的存在架构几乎是最坏的情况。在数据最小化方面，存在实体与存在服务共享其敏感信息，而服务仅与用户授权的观察者共享此存在信息，但没有任何技术机制限制这些观察者将存在转发给其他第三方。这些实体中的任何一个都可以无限期地记录或保留状态信息。不能通过使用户匿名来降低敏感性，因为系统的目的确实是为了促进相互认识的用户之间的通信。用户使用的标识符是长期存在的，通常包含个人信息，包括个人姓名和服务提供商的域。虽然用户确实参与了buddylists和Blacklist的构建，但他们这样做的可能性很小：用户有效地将他们的状态信息扔到状态服务器上，然后服务器将信息分发给观察者。用户通常无法验证状态是否仅分发给授权的观察者，特别是因为验证观察者身份的是服务器，而不是最终用户。此外，服务器与状态数据的所有发布者和消费者之间的连接对于窃听者来说是一个有吸引力的目标，并且需要强大的保密机制，尽管最终用户同样无法验证状态服务器和观察者之间存在什么机制。
Additionally, the sensitivity of presence information is not limited to the disposition and capability to communicate. Capabilities can reveal the type of device that a user employs, for example, and since multiple devices can publish the same user's presence, there are significant risks of allowing attackers to correlate user devices. An important extension to presence was developed to enable the support for location sharing. The effort to standardize protocols for systems sharing geolocation was started in the GEOPRIV working group. During the initial requirements and privacy threat analysis in the process of chartering the working group, it became clear that the system would require an underlying communication mechanism supporting user consent to share location information. The resemblance of these requirements to the presence framework was quickly recognized, and this design decision was documented in [RFC4079]. Location information thus mingles with other presence information available through the system to intermediaries and to authorized watchers.
此外，存在信息的敏感性不限于配置和通信能力。例如，功能可以揭示用户使用的设备类型，并且由于多个设备可以发布同一用户的状态，因此存在允许攻击者关联用户设备的重大风险。开发了对存在的重要扩展，以支持位置共享。GEOPRIV工作组开始了为共享地理位置的系统标准化协议的工作。在组建工作组过程中的初始要求和隐私威胁分析中，很明显，该系统需要一个支持用户同意共享位置信息的底层通信机制。这些需求与存在性框架的相似性很快得到了认可，该设计决策记录在[RFC4079]中。因此，位置信息与通过系统向中介机构和授权观察者提供的其他存在信息混合在一起。
Privacy concerns about presence information largely arise due to the built-in mediation of the presence architecture. The need for a presence server is motivated by two primary design requirements of presence: in the first place, the server can respond with an "offline" indication when the user is not online; in the second place, the server can compose presence information published by different devices under the user's control. Additionally, to facilitate the use of URIs as identifiers for entities, some service must operate a host with the domain name appearing in a presence URI, and in practical terms no commercial presence architecture would force end users to own and operate their own domain names. Many end users of applications like presence are behind NATs or firewalls and effectively cannot receive direct connections from the Internet -- the persistent bidirectional channel these clients open and maintain with a presence server is essential to the operation of the protocol.
存在信息的隐私问题主要是由于存在体系结构的内置中介而产生的。对状态服务器的需求源于状态的两个主要设计要求：首先，当用户不在线时，服务器可以响应“离线”指示；其次，服务器可以在用户的控制下合成由不同设备发布的状态信息。此外，为了方便使用URI作为实体的标识符，一些服务必须运行域名出现在状态URI中的主机，实际上，任何商业状态体系结构都不会强迫最终用户拥有和操作自己的域名。许多应用程序（如presence）的最终用户位于NAT或防火墙之后，实际上无法从Internet接收直接连接——这些客户端与presence服务器打开并维护的持久双向通道对于协议的运行至关重要。
One must first ask if the trade-off of mediation for presence is worthwhile. Does a server need to be in the middle of all publications of presence information? It might seem that end-to-end encryption of the presence information could solve many of these problems. A presentity could encrypt the presence information with the public key of a watcher and only then send the presence information through the server. The IETF defined an object format for presence information called the Presence Information Data Format (PIDF), which for the purposes of conveying location information was extended to the PIDF Location Object (PIDF-LO) -- these XML objects were designed to accommodate an encrypted wrapper. Encrypting this data would have the added benefit of preventing stored cleartext presence information from being seized by an attacker who manages to compromise a presence server. This proposal, however, quickly runs
人们必须首先问，以调解换取存在是否值得。服务器是否需要处于所有存在信息发布的中间？对状态信息进行端到端加密似乎可以解决其中许多问题。存在实体可以使用观察者的公钥加密存在信息，然后通过服务器发送存在信息。IETF为状态信息定义了一种对象格式，称为状态信息数据格式（PIDF），为了传递位置信息，该格式被扩展到PIDF位置对象（PIDF-LO）——这些XML对象被设计为容纳一个加密的包装器。对这些数据进行加密还可以防止存储的明文状态信息被试图破坏状态服务器的攻击者捕获。然而，这项提议很快就得到了实施
into usability problems. Discovering the public keys of watchers is the first difficulty, one that few Internet protocols have addressed successfully. This solution would then require the presentity to publish one encrypted copy of its presence information per authorized watcher to the presence service, regardless of whether or not a watcher is actively seeking presence information -- for a presentity with many watchers, this may place an unacceptable burden on the presence server, especially given the dynamism of presence information. Finally, it prevents the server from composing presence information reported by multiple devices under the same user's control. On the whole, these difficulties render object encryption of presence information a doubtful prospect.
进入可用性问题。发现观察者的公钥是第一个困难，很少有互联网协议成功解决了这个问题。然后，该解决方案将要求存在实体为每个授权观察者向存在服务发布其存在信息的一个加密副本，而不管观察者是否在积极寻找存在信息——对于具有多个观察者的存在实体，这可能会给存在服务器带来不可接受的负担，特别是考虑到存在信息的动态性。最后，它防止服务器合成由同一用户控制下的多个设备报告的状态信息。总的来说，这些困难使得存在信息的对象加密前景令人怀疑。
Some protocols that support presence information, such as SIP, can operate intermediaries in a redirecting mode rather than a publishing or proxying mode. Instead of sending presence information through the server, in other words, these protocols can merely redirect watchers to the presentity, and then presence information could pass directly and securely from the presentity to the watcher. It is worth noting that this would disclose the IP address of the presentity to the watcher, which has its own set of risks. In that case, the presentity can decide exactly what information it would like to share with the watcher in question, it can authenticate the watcher itself with whatever strength of credential it chooses, and with end-to-end encryption it can reduce the likelihood of any eavesdropping. In a redirection architecture, a presence server could still provide the necessary "offline" indication without requiring the presence server to observe and forward all information itself. This mechanism is more promising than encryption but also suffers from significant difficulties. It too does not provide for composition of presence information from multiple devices -- it in fact forces the watcher to perform this composition itself. The largest single impediment to this approach is, however, the difficulty of creating end-to-end connections between the presentity's device(s) and a watcher, as some or all of these endpoints may be behind NATs or firewalls that prevent peer-to-peer connections. While there are potential solutions for this problem, like Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN), they add complexity to the overall system.
一些支持状态信息的协议（如SIP）可以在重定向模式而不是发布或代理模式下操作中介。换句话说，这些协议不需要通过服务器发送状态信息，只需将观察者重定向到存在实体，然后状态信息就可以直接安全地从存在实体传递到观察者。值得注意的是，这将向观察者披露实体的IP地址，观察者有自己的风险。在这种情况下，存在实体可以准确地决定它希望与相关观察者共享什么信息，它可以使用它选择的任何凭证强度对观察者本身进行身份验证，并且通过端到端加密，它可以降低任何窃听的可能性。在重定向体系结构中，状态服务器仍然可以提供必要的“脱机”指示，而无需状态服务器本身观察和转发所有信息。这种机制比加密更有前途，但也有很大的困难。它也不提供来自多个设备的状态信息的合成——事实上，它强制观察者自己执行这种合成。然而，这种方法最大的单一障碍是在实体的设备和观察者之间创建端到端连接的困难，因为这些端点中的一些或所有可能位于NAT或防火墙之后，这些NAT或防火墙阻止了对等连接。虽然有可能解决这个问题，如NAT的会话遍历实用程序（STUN）和NAT周围使用中继的遍历（TURN），但它们增加了整个系统的复杂性。
Consequently, mediation is a difficult feature of the presence architecture to remove. It is hard to minimize the data shared with intermediaries, especially due to the requirement for composition. Control over sharing with intermediaries must therefore come from some other explicit component of the architecture. As such, the presence work in the IETF focused on improving user participation in the activities of the presence server. This work began in the GEOPRIV working group, with controls on location privacy, as location
因此，中介是存在体系结构的一个难以移除的特性。很难最小化与中介共享的数据，特别是由于对组合的要求。因此，对与中介共享的控制必须来自架构的其他明确组件。因此，IETF中的状态工作侧重于提高用户对状态服务器活动的参与度。这项工作始于GEOPRIV工作组，对位置隐私进行控制，如位置隐私
of users is perceived as having especially sensitive properties. With the aim of meeting the privacy requirements defined in [RFC2779], a set of usage indications, such as whether retransmission is allowed or when the retention period expires, have been added to the PIDF-LO such that they always travel with the location information itself. These privacy preferences apply not only to the intermediaries that store and forward presence information but also to the watchers who consume it.
大多数用户被认为具有特别敏感的属性。为了满足[RFC2779]中定义的隐私要求，PIDF-LO中添加了一组使用指示，例如是否允许重新传输或保留期到期时，以便它们始终与位置信息本身一起移动。这些隐私偏好不仅适用于存储和转发状态信息的中介机构，也适用于使用状态信息的观察者。
This approach very much follows the spirit of Creative Commons [CC], namely the usage of a limited number of conditions (such as 'Share Alike' [CC-SA]). Unlike Creative Commons, the GEOPRIV working group did not, however, initiate work to produce legal language or design graphical icons, since this would fall outside the scope of the IETF. In particular, the GEOPRIV rules state a preference on the retention and retransmission of location information; while GEOPRIV cannot force any entity receiving a PIDF-LO object to abide by those preferences, if users lack the ability to express them at all, we can guarantee their preferences will not be honored. The GEOPRIV rules can provide a means to establish accountability.
这种方法非常符合知识共享[CC]的精神，即使用有限数量的条件（如“共享相同”[CC-SA]）。然而，与知识共享不同，GEOPRIV工作组并未启动制作法律语言或设计图形图标的工作，因为这不属于IETF的范围。具体而言，GEOPRIV规则规定了位置信息的保留和重传的优先权；虽然GEOPRIV无法强制任何接收PIDF-LO对象的实体遵守这些首选项，但如果用户根本没有表达这些首选项的能力，我们可以保证他们的首选项不会得到尊重。GEOPRIV规则可以提供一种建立问责制的方法。
The retention and retransmission elements were envisioned as the most essential examples of preference expression in sharing presence. The PIDF object was designed for extensibility, and the rulesets created for the PIDF-LO can also be extended to provide new expressions of user preference. Not all user preference information should be bound into a particular PIDF object, however; many forms of access control policy assumed by the presence architecture need to be provisioned in the presence server by some interface with the user. This requirement eventually triggered the standardization of a general access control policy language called the common policy framework (defined in [RFC4745]). This language allows one to express ways to control the distribution of information as simple conditions, actions, and transformation rules expressed in an XML format. Common Policy itself is an abstract format that needs to be instantiated: two examples can be found with the presence authorization rules [RFC5025] and the Geolocation Policy [RFC6772]. The former provides additional expressiveness for presence-based systems, while the latter defines syntax and semantics for location-based conditions and transformations.
保留和重传元素被视为共享状态下偏好表达的最基本示例。PIDF对象是为可扩展性而设计的，为PIDF-LO创建的规则集也可以扩展，以提供用户偏好的新表达式。然而，并非所有用户偏好信息都应该绑定到特定的PIDF对象中；存在体系结构假定的许多形式的访问控制策略需要通过与用户的某个接口在存在服务器中提供。这一要求最终触发了通用访问控制策略语言的标准化，称为公共策略框架（定义见[RFC4745]）。这种语言允许人们将控制信息分布的方式表示为以XML格式表示的简单条件、操作和转换规则。公共策略本身是一种需要实例化的抽象格式：存在授权规则[RFC5025]和地理位置策略[RFC6772]可以找到两个示例。前者为基于状态的系统提供额外的表达能力，而后者为基于位置的条件和转换定义语法和语义。
Ultimately, the privacy work on presence represents a compromise between privacy principles and the needs of the architecture and marketplace. While it was not feasible to remove intermediaries from the architecture entirely or prevent their access to presence information, the IETF did provide a way for users to express their preferences and provision their controls at the presence service. We have not had great successes in the implementation space with privacy
最终，关于存在的隐私工作代表了隐私原则与架构和市场需求之间的妥协。虽然完全从体系结构中删除中介体或阻止其访问状态信息是不可行的，但IETF确实为用户提供了一种表达其偏好并在状态服务中提供控制的方式。我们在涉及隐私的实施领域没有取得很大成功
mechanisms thus far, but by documenting and acknowledging the limitations of these mechanisms, the designers were able to provide implementers, and end users, with an informed perspective on the privacy properties of the IETF's presence protocols.
迄今为止的机制，但通过记录和承认这些机制的局限性，设计者能够为实施者和最终用户提供IETF存在协议隐私属性的知情视角。
This document describes privacy aspects that protocol designers should consider in addition to regular security analysis.
该文档描述了除了常规安全性分析之外，协议设计者应该考虑的隐私方面。
We would like to thank Christine Runnegar for her extensive helpful review comments.
我们要感谢Christine Runnegar，感谢她提供了大量有用的评论。
We would like to thank Scott Brim, Kasey Chappelle, Marc Linsner, Bryan McLaughlin, Nick Mathewson, Eric Rescorla, Scott Bradner, Nat Sakimura, Bjoern Hoehrmann, David Singer, Dean Willis, Lucy Lynch, Trent Adams, Mark Lizar, Martin Thomson, Josh Howlett, Mischa Tuffield, S. Moonesamy, Zhou Sujing, Claudia Diaz, Leif Johansson, Jeff Hodges, Stephen Farrell, Steven Johnston, Cullen Jennings, Ted Hardie, Dave Thaler, Klaas Wierenga, Adrian Farrel, Stephane Bortzmeyer, Dave Crocker, and Hector Santos for their useful feedback on this document.
我们要感谢Scott Brim、Kasey Chappelle、Marc Linsner、Bryan McLaughlin、Nick Mathewson、Eric Rescorla、Scott Bradner、Nat Sakimura、Bjourn Hoehrmann、David Singer、Dean Willis、Lucy Lynch、Trent Adams、Mark Lizar、Martin Thomson、Josh Hollett、Misha Tuffield、S.Moonesay、周素静、Claudia Diaz、Leif Johansson、Jeff Hodges、，斯蒂芬·法雷尔、史蒂文·约翰斯顿、卡伦·詹宁斯、特德·哈迪、戴夫·泰勒、克拉斯·维伦加、阿德里安·法雷尔、斯蒂芬·博茨梅尔、戴夫·克罗克和赫克托·桑托斯感谢他们对本文件的有用反馈。
Finally, we would like to thank the participants for the feedback they provided during the December 2010 Internet Privacy workshop co-organized by MIT, ISOC, W3C, and the IAB.
最后，我们要感谢参与者在2010年12月由麻省理工学院、ISOC、W3C和IAB联合举办的互联网隐私研讨会上提供的反馈。
Although John Morris is currently employed by the U.S. Government, he participated in the development of this document in his personal capacity, and the views expressed in the document may not reflect those of his employer.
尽管John Morris目前受雇于美国政府，但他以个人身份参与了本文件的编制，文件中表达的观点可能并不反映其雇主的观点。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler Hannes Tschofenig
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler Hannes Tschofenig
[CC-SA] Creative Commons, "Share Alike", 2012, <http://wiki.creativecommons.org/Share_Alike>.
[CC-SA]知识共享，“共享”，2012年<http://wiki.creativecommons.org/Share_Alike>.
[CC] Creative Commons, "Creative Commons", 2012, <http://creativecommons.org/>.
[CC]知识共享，“知识共享”，2012年<http://creativecommons.org/>.
[CoE] Council of Europe, "Recommendation CM/Rec(2010)13 of the Committee of Ministers to member states on the protection of individuals with regard to automatic processing of personal data in the context of profiling", November 2010, <https://wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec%282010%2913>.
[CoE]欧洲委员会，“部长委员会向成员国提出的关于在分析过程中自动处理个人数据方面保护个人的CM/Rec（2010）13号建议”，2010年11月<https://wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec%282010%2913>.
[EFF] Electronic Frontier Foundation, "Panopticlick", 2013, <http://panopticlick.eff.org>.
电子前沿基金会，“Panopticlick”，2013，<http://panopticlick.eff.org>.
[FIPs] Gellman, B., "Fair Information Practices: A Basic History", 2012, <http://bobgellman.com/rg-docs/rg-FIPShistory.pdf>.
[FIPs]Gellman，B.“公平信息实践：基本历史”，2012年<http://bobgellman.com/rg-docs/rg-FIPShistory.pdf>.
[OECD] Organisation for Economic Co-operation and Development, "OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data", (adopted 1980), September 2010, <http://www.oecd.org/>.
[OECD]经济合作与发展组织，“OECD个人数据隐私和跨境流动保护指南”（1980年通过），2010年9月<http://www.oecd.org/>.
[PbD] Office of the Information and Privacy Commissioner, Ontario, Canada, "Privacy by Design", 2013, <http://privacybydesign.ca/>.
[PbD]加拿大安大略省信息和隐私专员办公室，“设计隐私”，2013年<http://privacybydesign.ca/>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778]Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[RFC2779]Day，M.，Aggarwal，S.，Mohr，G.，和J.Vincent，“即时消息/存在协议要求”，RFC 27792000年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]Rosenberg，J.，“会话启动协议（SIP）的存在事件包”，RFC3856，2004年8月。
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[RFC3859]彼得森，J.，“存在的共同特征（CPP）”，RFC3859，2004年8月。
[RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 3922, October 2004.
[RFC3922]Saint Andre，P.，“将可扩展消息和状态协议（XMPP）映射到公共状态和即时消息（CPIM）”，RFC 3922，2004年10月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC4079] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005.
[RFC4079]Peterson，J.，“GEOPRIV定位对象分布的存在架构”，RFC 4079，2005年7月。
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[RFC4101]Rescorla，E.和IAB，“编写协议模型”，RFC 41012005年6月。
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4187]Arkko，J.和H.Haverinen，“第三代认证和密钥协议（EAP-AKA）的可扩展认证协议方法”，RFC 4187，2006年1月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
[RFC4745]Schulzrinne，H.，Tschofenig，H.，Morris，J.，Cuellar，J.，Polk，J.，和J.Rosenberg，“共同政策：表达隐私偏好的文件格式”，RFC 47452007年2月。
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918]Dusseault，L.，“用于Web分布式创作和版本控制（WebDAV）的HTTP扩展”，RFC4918，2007年6月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007.
[RFC5025]Rosenberg，J.，“在场授权规则”，RFC 50252，2007年12月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008.
[RFC5106]Tschofenig，H.，Kroeselberg，D.，Pashalidis，A.，Ohba，Y.，和F.Bersani，“可扩展认证协议互联网密钥交换协议版本2（EAP-IKEv2）方法”，RFC 5106，2008年2月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280]Barnes，R.，Lepinski，M.，Cooper，A.，Morris，J.，Tschofenig，H.，和H.Schulzrinne，“互联网应用中的位置和位置隐私架构”，BCP 160，RFC 62802011年7月。
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.
[RFC6302]Durand，A.，Gashinsky，I.，Lee，D.，和S.Sheppard，“面向Internet服务器的日志记录建议”，BCP 162，RFC 6302，2011年6月。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.
[RFC6350]Perreault，S.，“vCard格式规范”，RFC 63502011年8月。
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
[RFC6562]Perkins，C.和JM。Valin，“带安全RTP的可变比特率音频使用指南”，RFC 6562，2012年3月。
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, September 2012.
[RFC6716]Valin，JM.，Vos，K.，和T.Terriberry，“作品音频编解码器的定义”，RFC 67162012年9月。
[RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, January 2013.
[RFC6772]Schulzrinne，H.，Tschofenig，H.，Cuellar，J.，Polk，J.，Morris，J.，和M.Thomson，“地理位置政策：表达位置信息隐私偏好的文档格式”，RFC 6772，2013年1月。
[Solove] Solove, D., "Understanding Privacy", March 2010.
[Solove]Solove，D.，“理解隐私”，2010年3月。
[Tor] The Tor Project, Inc., "Tor", 2013, <https://www.torproject.org/>.
[Tor]Tor项目有限公司，“Tor”，2013年<https://www.torproject.org/>.
[Westin] Kumaraguru, P. and L. Cranor, "Privacy Indexes: A Survey of Westin's Studies", December 2005, <http://reports-archive.adm.cs.cmu.edu/anon/isri2005/ CMU-ISRI-05-138.pdf>.
[威斯汀]Kumaraguru，P.和L.Cranor，“隐私指数：威斯汀研究调查”，2005年12月<http://reports-archive.adm.cs.cmu.edu/anon/isri2005/ CMU-ISRI-05-138.pdf>。
Authors' Addresses
作者地址
Alissa Cooper CDT 1634 Eye St. NW, Suite 1100 Washington, DC 20006 US
Alissa Cooper CDT 1634 Eye St.NW，美国华盛顿特区1100号套房，邮编：20006
Phone: +1-202-637-9800
EMail: acooper@cdt.org
URI: http://www.cdt.org/
Phone: +1-202-637-9800
EMail: acooper@cdt.org
URI: http://www.cdt.org/
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Bernard Aboba Skype
伯纳德·阿博巴Skype
EMail: bernard_aboba@hotmail.com
EMail: bernard_aboba@hotmail.com
Jon Peterson NeuStar, Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 US
美国加利福尼亚州康科德市萨特街1800号570室乔恩·彼得森·纽斯塔公司，邮编94520
EMail: jon.peterson@neustar.biz
EMail: jon.peterson@neustar.biz
John B. Morris, Jr.
小约翰·B·莫里斯。
EMail: ietf@jmorris.org
EMail: ietf@jmorris.org
Marit Hansen ULD
马里特·汉森ULD
EMail: marit.hansen@datenschutzzentrum.de
EMail: marit.hansen@datenschutzzentrum.de
Rhys Smith Janet
里斯·史密斯·珍妮特
EMail: rhys.smith@ja.net
EMail: rhys.smith@ja.net