<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2616 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY RFC3325 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml'>
<!ENTITY RFC3552 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml'>
<!ENTITY RFC4101 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4101.xml'>
<!ENTITY RFC4918 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4918.xml'>
<!ENTITY RFC4949 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml'>
<!ENTITY RFC5025 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5025.xml'>
<!ENTITY RFC6280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6280.xml'>
<!ENTITY I-D.iab-privacy-terminology PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.iab-privacy-terminology.xml'>
]>

<rfc category="info" ipr="trust200902" docName="draft-iab-privacy-considerations-02.txt">
  <front>
  <title abbrev="Privacy Considerations">Privacy Considerations for Internet Protocols</title>   
    
	<author initials="A." surname="Cooper" fullname="Alissa Cooper">
    <organization>CDT</organization>
    <address>
      <postal>
        <street>1634 Eye St. NW, Suite 1100</street>
        <city>Washington</city>
		  <region>DC</region>
        <code>20006</code>
        <country>US</country>
      </postal>
      <phone>+1-202-637-9800</phone>
      <email>acooper@cdt.org</email>
      <uri>http://www.cdt.org/</uri>
    </address>
  </author>

  <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
    <organization>Nokia Siemens Networks</organization>
    <address>
      <postal>
        <street>Linnoitustie 6</street>
        <city>Espoo</city>
        <code>02600</code>
        <country>Finland</country>
      </postal>
      <phone>+358 (50) 4871445</phone>
      <email>Hannes.Tschofenig@gmx.net</email>
      <uri>http://www.tschofenig.priv.at</uri>
    </address>
  </author>

   <author initials="B." surname="Aboba" fullname="Bernard Aboba">
      <organization>Microsoft Corporation</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>WA</region>
          <code>98052</code>
          <country>US</country>
        </postal>
        <email>bernarda@microsoft.com</email>
      </address>
    </author>

        <author initials="J." surname="Peterson" fullname="Jon Peterson">
            <organization abbrev="NeuStar, Inc.">NeuStar, Inc.</organization>
            <address>
                <postal>
                    <street>1800 Sutter St Suite 570</street>
                    <city>Concord</city>
                    <region>CA</region>
                    <code>94520</code>
                    <country>US</country>
                </postal>
                <email>jon.peterson@neustar.biz</email>
            </address>
        </author>

	<author initials="J." surname="Morris" fullname="John B. Morris, Jr.">
      <address>
        <email>ietf@jmorris.org</email>
      </address>
    </author>

    <date year="2012"/>
    <keyword>Internet-Draft</keyword>
    <keyword>Privacy</keyword>
    <abstract>
    
    <t>This document offers guidance for developing privacy
   considerations for IETF documents and aims to make protocol designers aware of privacy-related design choices.
   </t>
   <t>Discussion of this document is taking place on the IETF Privacy Discussion mailing list 
   (see https://www.ietf.org/mailman/listinfo/ietf-privacy).</t>
    </abstract>

  </front>
  <middle>

    <!-- ====================================================================== -->

    <section anchor="introduction" title="Introduction">

   <t><xref target="RFC3552" /> provides detailed guidance to protocol designers about both how to consider security as part of protocol design and how to inform readers of IETF documents about security issues. This document intends to provide a similar set of guidance for considering privacy in protocol design.</t> 

<t>Whether any individual document will require 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, <xref target="RFC3325" />). For certain specifications, privacy considerations are a subset of security considerations and can be discussed explicitly in the security considerations section. 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.</t>

   <t>Privacy is a complicated concept with a rich history that spans many disciplines. 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 data about individuals (see <xref target="OECD" /> for one example), and the Privacy by Design concept, which provides high-level privacy guidance for systems design (see <xref target="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.</t>

	<t>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.</t>
	
	<t>This document is organized as follows. <xref target="scope"/> describes the extent to which the guidance offered is applicable within the IETF. <xref target="threatmodel"/> discusses threats to privacy as they apply to Internet protocols. <xref target="privacy-goals" /> outlines privacy goals. <xref target="guidelines"/> provides the guidelines for analyzing and documenting privacy considerations within IETF specifications.
   <xref target="example"/> examines the privacy characteristics of an IETF protocol to demonstrate the use of the guidance framework. <xref target="glossary" /> provides a concise glossary of terms used in this document, with a more complete discussion of some of the terms available in <xref target="I-D.iab-privacy-terminology" />.
   </t>

</section> 


      <!-- ====================================================================== -->

<section anchor="scope" title="Scope"> 

<t>The core function of IETF activity is building protocols. 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 some protocols assume particular architectures 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.</t>

<t>As a consequence, the extent to which protocol designers can foresee all of the privacy implications of a particular protocol at design time is significantly limited. An individual protocol may be relatively benign on its own, but when deployed within a larger system or used in a way not envisioned at design time, its use may create new privacy risks. The guidelines in <xref target="guidelines" /> 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.</t>
	 
<t>Furthermore, in many cases the privacy properties of a system are dependent upon API specifics, internal application functionality, database structure, local policy, and other details that 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 those details, but its primary aim is to assist with the design, implementation, and operation of protocols. Privacy issues, even those related to
protocol development, go beyond the technical
guidance discussed herein.</t>

<t>As an example, consider HTTP <xref target="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 WebDAV <xref target="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.</t>
</section> 

    <!-- ====================================================================== -->

<section anchor="threatmodel" title="Internet Privacy Threat Model"> 

<t>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. In cases where such monitoring is for the purpose of stalking or violence, it can put individuals in physical danger.</t>

	<t>This section lists common privacy threats (drawing liberally from <xref target="Solove" />), showing how each of them may cause individuals to incur privacy harms and providing examples of how these threats can exist on the Internet.</t> 

<section anchor="communications-model" title="Communications Model">

	<t>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 element that initiates communication with some recipient (an "initiator"). Privacy analysis is most relevant for protocols with use cases in which the initiator acts on behalf of a natural person (or different people at different times). It is this natural person -- the data subject -- whose privacy is potentially threatened.</t>  

	    <t>Communications may be direct between the initiator and
	    the recipient, or they may involve an intermediary (such as a proxy or cache) 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 and sometimes it is only used for
	    communication establishment, for either inbound or outbound
	    communication.  In rare cases there may be a series of
	    intermediaries that are traversed.</t>

	<t>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 or DNS resolver. 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 my generate further protocol interactions between either the initiator or the recipient and other entities. For example, an HTTP request might trigger interactions with an authentication server or with other resource servers.</t>   
	
	<t>As a general matter, recipients, intermediaries, and enablers are usually assumed to be authorized to receive and handle data from initiators. As <xref target="RFC3552" /> explains, "we assume that the end-systems engaging in a protocol exchange have not themselves been compromised."</t>  

	<t>Although they may not generally be considered as attackers, recipients, intermediaires, and enablers may all pose privacy threats (depending on the context) because they are able to observe and collect 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.</t> 
	
	<t>The threat descriptions in the next section explain how observers and attackers might act to harm data subjects' 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).</t>
</section> 

<section anchor="privacy-threats" title="Privacy Threats">

	<t>Some privacy threats are already considered in IETF 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.</t>

	<t>Note that an individual's knowledge and authorization of the practices described below can greatly affect the extent to which they threaten privacy. If a data subject authorizes surveillance of his own activities, for example, the harms associated with it may be significantly mitigated.</t> 

<section anchor="security-privacy-threats" title="Combined Security-Privacy Threats">

<section anchor="surveillance" title="Surveillance">

	<t>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 to the perpetration of violence against the individual. The individual need not be aware of the surveillance for it to impact privacy -- the possibility of surveillance may be enough to harm individual autonomy.</t>

	<t>Surveillance can be conducted by observers or eavesdroppers at any point along the communications path. Confidentiality protections (as discussed in <xref target="RFC3552" /> Section 3) 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 <xref target="Tor" />.</t> 
</section> 

<section anchor="stored-data-compromise" title="Stored Data Compromise">

<t>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.</t> 

	<t>By and large, protecting against stored data compromise is 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), 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.</t>
</section> 

<section anchor="intrusion" title="Intrusion">

	<t>Intrusion consists of invasive acts that disturb or interrupt one's life or activities. Intrusion can thwart individuals' desires to be let alone, sap their time or attention, or interrupt their activities.</t> 

	<t>Unsolicited mail 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.</t>
</section> 

</section> 

<section anchor="privacy-specific-threats" title="Privacy-Specific Threats">

<section anchor="correlation" title="Correlation">

	<t>Correlation is the combination of various pieces of information about an individual. 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.</t>

	<t>Correlation is closely related to identification. Internet protocols can facilitate correlation by allowing data subjects' activities to be tracked and combined over time. The use of persistent or infrequently refreshed 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 to correlate all of the initiator's communications over time.</t>  

	<t>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.</t>
</section> 

<section anchor="identification" title="Identification">

	<t>Identification is the linking of information to a particular individual. 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).</t>

	<t>Many protocol identifiers, such as those used in SIP or XMPP, may allow for the direct identification of data subjects. 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.</t> 

	<t>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.</t>  
</section> 

<section anchor="secondary-use" title="Secondary Use">

	<t>Secondary use is the use of collected information without the data subject'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 over how one's information will be used in the future, potentially discouraging information exchange in the first place.</t>

	<t>One example of secondary use would be a network access server that uses an initiator's access requests to track the initiator's location. Any observer or attacker could potentially make unwanted secondary uses of initiators' data.</t>  
</section> 

<section anchor="disclosure" title="Disclosure">

	<t>Disclosure is the revelation of truthful information about a person that affects the way others judge the person. Disclosure can violate people's 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.</t> 

	<t>Any observer or attacker that receives data about an initiator may choose to engage in disclosure. In most cases, there is nothing done at the protocol level to influence or limit disclosure, although there are some exceptions. For example, the GEOPRIV architecture <xref target="RFC6280" /> provides a way for users to express a preference that their location information not be disclosed beyond the intended recipient.</t>  
</section> 

<section anchor="exclusion" title="Exclusion">

	<t>Exclusion is the failure to allow the data subject to know about the data that others have about him or her 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 about individuals' ability to control how information about them is collected and used.</t>

	<t>The most common way for Internet protocols to be involved in limiting exclusion is through access control mechanisms. The presence architecture developed in the IETF is a good example where data subjects are included in the control of information about them. Using a rules expression language (e.g., Presence Authorization Rules <xref target="RFC5025" />), presence clients can authorize the specific conditions under which their presence information may be shared.</t> 

	<t>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.</t>

</section> 

</section> 

</section> 
</section> 

      <!-- ====================================================================== -->

<section anchor="privacy-goals" title="Internet Privacy Goals"> 

<t>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 privacy properties against which designs may be assessed for their potential to impact privacy. This section adapts these properties into four privacy goals for Internet protocols: (1) data minimization, (2) user participation, (3) accountability, and (4) security.</t> 

<section anchor="data-minimization-goal" title="Data Minimization">

<t>Data minimization refers to collecting, using, and storing the minimal data necessary to perform a task. The less data about data subjects that gets exchanged in the first place, the lower the chances of that data being used for privacy invasion.</t> 

	<t>Data minimization is comprised of a number of mutually exclusive sub-goals:</t>

		<t><list style='symbols'>

	<t>Use limitation: Limiting the uses to which data is put helps contain the spread of data to third parties and protects against uses that may violate data subjects' expectations.</t> 

	<t>Retention limitation: Limiting the duration of data storage reduces the risk of stored data compromise.</t> 

	<t>Identifiability limitation: Minimization pertains not only to the amount of data exchanged, but also the extent to which it can be used to identify data subjects. Reducing the identifiability of data by using pseudonymous or anonymous identifiers helps to weaken the link between a data subject and his or her communications. Refreshing or recycling identifiers reduces the possibility that multiple protocol interactions or communications can be correlated back to the same data subject.</t>

	<t>Sensitivity limitation: The sensitivity of data is another property that can be minimized. For example, the street address of a building that an individual visits may be considered to be a more sensitive piece of information than the city and postal code in which the building is located. Collecting, using, and storing less sensitive data may mitigate the damage caused by secondary use, disclosure, stored data compromise, and correlation.</t>
	
</list></t>
	
</section> 

<section anchor="user-participation-goal" title="User Participation">

<t>As explained in <xref target="exclusion" />, data collection and use that happens "in secret," without the data subject's knowledge, is apt to violate the subject's expectation of privacy and may create incentives for misuse of data. As a result, privacy regimes tend to include provisions to support informing data subjects 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.</t>

</section>

<section anchor="accountability-goals" title="Accountability">

	<t>An entity that collects, uses, or stores data can undergird its commitments to the other privacy goals by providing mechanisms by which data subjects and third parties can hold the entity accountable for those commitments. These mechanisms usually allow for verification of what data is collected or stored and with whom it is shared, again helping to mitigate the threat of exclusion.</t>
	
</section>

<section anchor="security-goal" title="Security">

<t>Keeping data secure at rest and in transit is another important component of privacy protection. As they are described in <xref target="RFC3552" /> Section 2, a number of security goals also serve to enhance privacy:</t>

<t><list style='symbols'>

	<t>Confidentiality: Keeping data secret from unintended listeners.</t>

	<t>Peer entity authentication: Ensuring that the endpoint of a communication is the one that is intended (in support of maintaining confidentiality).</t>

	<t>Unauthorized usage: Limiting data access to only those users who are authorized, helping to prevent stored data compromise.</t>

	<t>Inappropriate usage: Limiting how authorized users can use data. (Note that this goal also falls within data minimization.)</t>
	
</list></t>

</section>

</section>

      <!-- ====================================================================== -->

<section anchor="guidelines" title="Guidelines"> 
<t>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 <xref target="RFC4101"/>.</t>

<t>Note that the guidance 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.</t> 

<t>The framework is divided into four sections that address each of the goals from <xref target="privacy-goals" />, plus a general section. Security is not fully elaborated since substantial guidance already exists in <xref target="RFC3552" />.</t>

	<section anchor="general" title="General">
		<t><list style="hanging">
			<t>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.</t>
		</list></t>
	</section>
	
	<section anchor="data-minimization" title="Data Minimization">
		<t><list style="hanging">
			<t>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?</t>

			<t>b. Personal data. What information does the protocol expose about data subjects and/or their devices (other than the identifiers discussed in (a))? To what extent is this information linked to the identities of data subjects? How does the protocol combine personal data with the identifiers discussed in (a)?</t>

			<t>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?</t>

			<t>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?</t>  

			<t>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 recycle identifiers? How often does the specification recommend to delete or recycle identifiers by default?</t>

			<t>f. Correlation. 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?</t>    

			<t>g. Retention. Do the protocol or its anticipated uses require that the information discussed in (a) or (b) be retained by recipients, intermediaries, or enablers? Is the retention expected to be persistent or temporary?</t>
		</list></t>
	</section>
	
	<section anchor="user-participation" title="User Participation">
		<t><list style="hanging">
			<t>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 are specified, is it expected that control and consent will be handled outside of the protocol?</t>

			<t>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?</t> 

			<t>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 (contractual or otherwise) with intermediaries that govern the use of the information?</t>

			<t>d. Preference expression. Does the protocol provide ways for initiators to express data subjects' preferences to recipients or intermediaries with regard to the use or disclosure of their personal data?</t>
		</list></t>
	</section>
	
	<section anchor="accountability" title="Accountability">
		<t><list style="hanging">
			<t>a. Verification. If the protocol provides for user preference expression, does it also define or require mechanisms that allow initiators to verify that data subjects' preferences are being honored? If not, are there mechanisms that exist outside of the protocol that allow for verification?</t>
		</list></t>
	</section>
	
	<section anchor="security" title="Security">
		<t><list style="hanging">
			<t>a. Surveillance. How do the protocol's security considerations prevent surveillance, including eavesdropping and traffic analyis?</t>
			
			<t>b. Stored data compromise. How do the protocol's security considerations prevent or mitigate stored data compromise?</t>
			
			<t>c. Intrusion. How do the protocol's security considerations prevent or mitigate intrusion, including denial-of-service attacks and unsolicited communications more generally?</t> 
		</list></t>
		
	</section>

</section> 

      <!-- ====================================================================== -->

    <section anchor="example" title="Example">
	<t>[To be provided in a future version once the guidance is settled.]</t>

</section> 

    <!-- ====================================================================== -->

	    <section anchor="glossary" title="Glossary">
		
		<t>
		<list style="hanging">
		
		<t hangText="$ Anonymity" />
		<t>The state of being anonymous. See <xref target="I-D.iab-privacy-terminology" />.</t>
		
		<t hangText="$ Anonymous" />
		<t>A property of a data subject in which an observer or attacker cannot identify the data subject within a set of other subjects (the anonymity set).</t>
		
		<t hangText="$ Attacker" />
		<t> An entity that intentionally works against some protection goal.</t>
		
		<t hangText="$ Attribute" />
		<t>A property of a data subject or initiator.</t>
		
		<t hangText="$ Correlation" />
		<t>The combination of various pieces of information about a data subject.</t>
		
		<t hangText="$ Data Subject" />
		<t>An identified natural person or a
		      natural person who can be identified, directly or indirectly.</t>
		
		<t hangText="$ Eavesdropper" />
		<t>An entity that passively observes an initiator's communications without the initiator's knowledge or authorization. See <xref target="RFC4949" />.</t>
		
		<t hangText="$ Enabler" />
		<t>A protocol entity that facilitates communication between an initiator and a recipient without being directly in the communications path.</t>
		
		<t hangText="$ Fingerprint" />
		<t>A set of information elements that identifies a device, application, or initiator.</t>
		
		<t hangText="$ Fingerprinting" />
		<t>The process of an observer or attacker partially or fully identifying a device, application, or initiator based on multiple information elements communicated to the observer or attacker. See <xref target="EFF" />.</t>
		
		<t hangText="$ Identifiable" />
		<t>A state in which a data subject's identity is known.</t>
		
		<t hangText="$ Identifiability" />
		<t>The extent to which a data subject is identifiable. See <xref target="I-D.iab-privacy-terminology" />.</t>
		
		<t hangText="$ Identifier" />
		<t>A data object that represents a specific identity of a protocol entity or data subject. See <xref target="RFC4949" />.</t>
		
		<t hangText="$ Identification" />
		<t>The linking of information to a particular data subject to infer the subject's identity.</t>
		
		<t hangText="$ Identity" />
		<t>Any subset of a data subject's attributes that identifies the subject within a given context. Data subjects usually have multiple identities for use in different contexts.</t> 
		
		<t hangText="$ Initiator" />
		<t>A protocol entity that initiates communications with a recipient.</t>
		
		<t hangText="$ Intermediary" />
		<t>A protocol entity that sits between the initiator and the recipient and is necessary for the initiator and recipient to communicate.</t>
		
		<t hangText="$ Item of Interest (IOI)" />
		<t>Any data item that an observer or attacker might be interested in. This includes attributes, identifiers, identities, communications, or actions (such as the sending or receiving of a communication). See <xref target="I-D.iab-privacy-terminology" />.</t> 
		
		<t hangText="$ Observer" />
		<t>An entity that is authorized to receive and handle data from an
		    initiator and thereby is able to observe and collect information, potentially posing privacy threats depending on the context.
		    Recipients, intermediaries, and enablers can all be
		    observers.</t> 
		
		<t hangText="$ Personal Data" />
		<t>Any information relating to a data subject.</t>
		
		<t hangText="$ (Protocol) Interaction" />
		<t>A unit of communication within a particular protocol. A single interaction may be compromised of a single message between an initiator and recipient or multiple messages, depending on the protocol.</t>
		
		<t hangText="$ Pseudonym" />
		<t>An identifier of a data subject other than the subject's real name.</t>
		
		<t hangText="$ Pseudonymity" />
		<t>The state of being pseudonymous. See <xref target="I-D.iab-privacy-terminology" />.</t>
		
		<t hangText="$ Pseudonymous" />
		<t>A property of a data subject in which the subject is identified by a pseudonym.</t>
		
		<t hangText="$ Recipient" />
		<t>A protocol entity that recieves communications from an initiator.</t>
		
		<t hangText="$ Traffic Analysis" />
		<t>The inference of information from observation of traffic
		      flows (presence, absence, amount, direction, and frequency). See <xref target="RFC4949" />.</t>

	</list></t>

	</section> 

	    <!-- ====================================================================== -->

    <section anchor="SecurityConsiderations" title="Security Considerations">
<t>
This document describes privacy aspects that protocol designers should consider in addition to regular security analysis.</t>
</section>

    <!-- ====================================================================== -->

    <section anchor="iana" title="IANA Considerations">
	<t>
This document does not require actions by IANA. </t>
    </section>

    <!-- ====================================================================== -->

    <section title="Acknowledgements">
      <t>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.</t>
    </section>
  </middle>
  <!-- ====================================================================== -->
  <back>
  
<references title="Normative References">
	&I-D.iab-privacy-terminology;
</references>

    <references title="Informative References"> 
			&RFC2616;
			&RFC3325;
			&RFC3552;
			&RFC4101;
			&RFC4918;	 
			&RFC4949;
			&RFC5025;
			&RFC6280;
      
			<reference anchor="EFF">
				<front>
		          <title>Panopticlick</title>
		          <author>
		            <organization>Electronic Frontier Foundation</organization>
		          </author>
				  <date year="2011" />
		        </front>
				<format target="http://panopticlick.eff.org" type="HTML" />
		      </reference>       

<reference anchor="OECD">
        <front>
          <title>OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data</title>
          <author fullname="" initials="" surname="">
            <organization>Organization for Economic Co-operation and Development</organization>
          </author>
          <date year="1980"/>
        </front>
        <seriesInfo
          name="available at (September 2010)"
          value=", http://www.oecd.org/EN/document/0,,EN-document-0-nodirectorate-no-24-10255-0,00.html"/>
        <format target="http://www.oecd.org/EN/document/0,,EN-document-0-nodirectorate-no-24-10255-0,00.html" type="HTML"/>
      </reference>  	


	<reference anchor="PbD">
        <front>
          <title>Privacy by Design</title>
          <author> 
            <organization>Office of the Information and Privacy Commissioner, Ontario, Canada</organization> 
          </author>
          <date year="2011"/>
        </front>
        <format type='HTML'
        target='http://privacybydesign.ca/' />
      </reference>
	
	<reference anchor="Solove">
		<front>
			<title>Understanding Privacy</title>
			<author surname="Solove" initials="D.J." fullname="Daniel J. Solove" />
			<date year="2010" />
		</front>
	</reference>
	
	<reference anchor="Tor">
		<front>
          <title>Tor</title>
          <author>
            <organization>The Tor Project, Inc.</organization>
          </author>
		  <date year="2011" />
		</front>
		<format type='HTML' target="https://www.torproject.org/" />
      </reference>

	</references>
  </back>
</rfc>