!!! Overview
[{$pagename}] are [Best Practices] for [Privacy].

[{$pagename}] is defined as [{$pagename}] for [Internet Protocols] in [RFC 6973] 

[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|Privacy models] and [Privacy design frameworks|Privacy Enhancing Technologies] 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].

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 [{$pagename}] 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" [RFC 3325]).  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" [RFC 6716]).  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 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.

[{$pagename}] [SHOULD] take the time to elaborate the security implications of not implementing a [MUST] or [SHOULD], or doing something the specification says [MUST NOT] or [SHOULD NOT]

These terms are frequently used to specify behavior with [privacy] implications. The effects on [privacy] of not implementing a [MUST] or [SHOULD], or doing something the specification says [MUST NOT] or [SHOULD NOT] be done may be very subtle. Document authors should take the time to elaborate the [privacy] implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification.

!! [RFC 6973] Section 3.1 [Entities]
* [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 [RFC 4949].
* [Enabler]:  A protocol entity that facilitates communication between an initiator and a recipient without being directly in the communications path.
* [Individual|Natural Person]:  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] [RFC 3261] [proxy] is an [intermediary|Intermediary] in the [SIP] architecture.
* [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|Intermediary], 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].

!! [RFC 6973] Section 3.2 [Data] and Analysis
* [Attack]:  An intentional act by which an entity attempts to violate an individual's [privacy].  See [RFC 4949].
* [Correlation|Identity Correlation]:  The combination of various pieces of information that relate to an [entity] 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].
* [Item of Interest] ([IOI]):  Any [data] item that an [observer] or [attacker] might be interested in.  This includes [attributes], [identifiers], [identities|Digital Identity], [communications content|message], and the fact that a communication interaction has taken place.
* [Personal data]:  Any information relating to an [individual] who can be [identified|Identification], 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 [RFC 4949].
* [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|Item of Interest] are related or not (with a high enough degree of probability to be useful to the [observer] or [attacker]).


!! [RFC 6973] Section 3.3. [Identifiability]
* [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 [RFC 4949].  [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.
* [Identity|Digital Identity]:  Any subset of an individual's attributes, including names, that identifies the individual within a given context. Individuals usually have [multiple identities|Digital Subject] 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|Identity Provider (IDP)]:  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 Provider (IDP)] in order to provide services to individuals.  In effect, the relying party delegates aspects of identity management to the [Identity Provider (IDP)].  Such [delegation] requires [protocol] exchanges, [trust], and a common understanding of semantics of information exchanged between the [Relying Party] and the [Identity Provider (IDP)].


!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]