index.html 220 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"  "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<head>
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />
  <title>A Standards-based, Open and Privacy-aware Social Web</title>
  <link rel="stylesheet" type="text/css" href="style.css" charset="utf-8" />
  <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-XGR" />
</head>
<body>
<div class="head">
  <p><a href="http://www.w3.org/"><img height="48" width="72" alt="W3C" src="http://www.w3.org/Icons/w3c_home"/></a>
    <a href="http://www.w3.org/2005/Incubator/XGR/"> <img height="48" width="160" alt="W3C Incubator Report" src="http://www.w3.org/2005/Incubator/images/XGR"/></a>
  </p>

  <h1 style="clear: both;" id="title">A Standards-based, Open and Privacy-aware Social Web</h1>

<h2 id="W3C-doctype">W3C Incubator Group Report 6th December 2010 </h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/2005/Incubator/socialweb/XGR-socialweb-20101206/">http://www.w3.org/2005/Incubator/socialweb/XGR-socialweb-20101206/</a></dd>

  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/2005/Incubator/socialweb/XGR-socialweb/">http://www.w3.org/2005/Incubator/socialweb/XGR-socialweb/</a>
    </dd>
</dl>
<dl>
  <dt>Editor:</dt>

    <dd rel="dc:creator">
    <span typeof="foaf:Person" about="http://www.ibiblio.org/hhalpin/foaf.rdf#me">
    <a href="http://www.ibiblio.org/hhalpin" property="foaf:name" rel="foaf:homepage">Harry Halpin</a>, University of Edinburgh/W3C
    </span>
    </dd>


    <dd rel="dc:creator">
  <span typeof="foaf:Person" about="http://mmt.me.uk/foaf.rdf#mischa">
    <a href="http://mmt.me.uk/" property="foaf:name" rel="foaf:homepage">Mischa Tuffield</a>, Garlik
  </span>
    </dd>

  <dt>Authors:</dt>
    <dd><a href="http://www.torgo.com/">Daniel Appelquist</a>, Vodafone </dd>

    <dd rel="dc:creator">
    <span typeof="foaf:Person" about="">
<a href="http://danbri.org/" property="foaf:name" rel="foaf:homepage">Dan Brickley</a>, Vrije University Amsterdam
    </span>
    </dd>

    <dd rel="dc:creator" >
    <span typeof="foaf:Person" about="http://foaf.me/melvincarvalho#me">
     <a href="http://melvincarvalho.com/"  property="foaf:name" rel="foaf:homepage">Melvin Carvahlo</a>,
   </span>
    </dd>

    <dd><a href="http://renato.iannella.it/">Renato Iannella</a>, Semantic Identity</dd>

    <dd rel="dc:creator">
    <span typeof="foaf:Person" about="http://apassant.net/alex">
    <a href="http://apassant.net/" property="foaf:name" rel="foaf:homepage">Alexandre Passant</a>, DERI, NUI Galway
    </span>
    </dd>

    <dd><a href="http://www.perey.com/">Christine Perey</a>, PEREY Research and Consulting</dd>

    <dd rel="dc:creator">
     <span typeof="foaf:Person" about="http://bblfish.net/#hjs">
     <a href="http://bblfish.net/" property="foaf:name" rel="foaf:homepage">Henry Story</a>
     </span>
    </dd>

</dl>

<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &copy; 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&reg;</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>

  <hr />
</div>

<h2 id="abstract">Abstract</h2>

<p>The Social Web is a set of relationships that link together people over the Web. The Web is an universal and open space of information where every item of interest can be identified with a URI. While the best known current social networking sites on the Web limit themselves to relationships between people with accounts on a single site, the Social Web should extend across the entire Web. Just as people can call each other no matter which telephone provider they belong to, just as email allows people to send messages to each other irrespective of their e-mail provider, and just as the Web allows links to any website, so the Social Web should allow people to create networks of relationships across the entire Web, while giving people the ability to control their own privacy and data. The standards that enable this should be  open and royalty-free. We present a framework for understanding the Social Web and the relevant standards (from both within and outside the W3C) in this report, and conclude by proposing a strategy for making the Social Web a "first-class citizen" of the Web.</p>

<h2 id="status">Status of this document</h2>

  <p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of <a href="/2005/Incubator/XGR/">Final Incubator Group Reports</a> is available. See also the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>

<p>This document was developed by the <a
  href="http://www.w3.org/2005/Incubator/socialweb/">Social Web Incubator Group</a>.</p>

<p>Publication of this document by W3C as part of the <a
href="http://www.w3.org/2005/Incubator/"><acronym class="spell"
>W3C</acronym> Incubator Activity</a> indicates no endorsement of its
content by <acronym class="spell">W3C</acronym>, nor that <acronym
class="spell">W3C</acronym> has, is, or will be allocating any resources
to the issues addressed by it. Participation in Incubator Groups and
publication of Incubator Group Reports at the <acronym class="spell"
>W3C</acronym> site are benefits of <a href="http://www.w3.org/Consortium/join"
><acronym class="spell">W3C</acronym> Membership</a>.</p>

  <p>Incubator Groups have as a <a href="http://www.w3.org/2005/Incubator/procedures.html#Patent">goal</a>  to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy.
    Participants in this Incubator Group have agreed to offer patent licenses according to the W3C
    Royalty-Free licensing requirements described in <a href="http://www.w3.org/Consortium/Patent-Policy-20030520.html#sec-Requirements" shape="rect">Section 5 of
      the W3C Patent Policy</a> for any portions of the XG Reports produced by
    this XG that are subsequently incorporated into a W3C Recommendation
    produced by a Working Group which is chartered to take the XG Report as an
    input.</p>

  <p>Comments on this document are welcome. Please send them to the public mailing list <a href="mailto:public-xg-socialweb@w3.org">public-xg-socialweb@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/public-xg-socialweb/">archive</a>).</p>


  <h2 id="TableOfContents">Table of Contents</h2>

  <div class="toc">
    <ul class="toc">
     <li class="tocline"><a href="#Overview">1. Overview</a></li>
     <li class="tocline"><a href="#State">2. State of the Social Web in 2010</a></li>
     <li class="tocline"><a href="#Frameworks">3. Social Web Frameworks</a>
     <ul class="toc">
          <li class="tocline"><a href="#Problem">3.1  The Problem of Walled Gardens</a></li>
          <li class="tocline"><a href="#Vision">3.2  The Social Web Vision </a></li>
          <li class="tocline"><a href="#Terminology">3.3  The Terminology</a>
          <ul class="toc">
            <li class="tocline"><a href="#User">3.3.1  Social Web User and Profiles</a></li>
            <li class="tocline"><a href="#Single">3.3.2  Single Distributed Social Graph</a></li>
            <li class="tocline"><a href="#Multiple">3.3.3  Multiple Distributed Social Graphs</a></li>
          </ul></li>
          <li class="tocline"><a href="#Case">3.4  The Case for Open Social Web Standards</a></li>
      </ul></li>
     <li class="tocline"><a href="#Identity">4. Identity</a>
       <ul class="toc">
         <li class="tocline"><a href="#Usernames">4.1 Problem: Usernames and Passwords are Insecure </a></li>
         <li class="tocline"><a href="#No">4.2 Use Case: No more passwords (or only one) </a></li>
         <li class="tocline"><a href="#IdentityStandards">4.3 Identity Standards</a>
           <ul class="toc">
             <li class="tocline"><a href="#Browser">4.3.1 Browser-based Password Management </a></li>
             <li class="tocline"><a href="#OAuth">4.3.2 OAuth </a></li>
             <li class="tocline"><a href="#OpenID">4.3.3 OpenID </a></li>
	     <li class="tocline"><a href="#WebID">4.3.4  WebID  </a></li>
	     <li class="tocline"><a href="#Infocard">4.3.5 Infocard</a> </li>
	     <li class="tocline"><a href="#XAuth">4.3.6 XAuth</a></li>
	     <li class="tocline"><a href="#SAML">4.3.7 SAML</a></li>
	     <li class="tocline"><a href="#Kantara">4.3.8 Kantara Trust Framework</a></li>

         </ul></li>
     </ul></li>
     <li class="tocline"><a href="#Profiles">5. Profiles</a>
       <ul class="toc">
         <li class="tocline"><a href="#Can">5.1  Problem:  Can Not Describe Yourself</a></li>
         <li class="tocline"><a href="#Keep">5.2  Use-Case: Keep Your Profile and Friends Across Networks</a></li>
         <li class="tocline"><a href="#ProfileStandards">5.3  Profile Standards</a>
           <ul class="toc">
             <li class="tocline"><a href="#XRD">5.3.1 XRD</a></li>
             <li class="tocline"><a href="#VCard">5.3.2 VCard</a></li>
             <li class="tocline"><a href="#FOAF">5.3.3 FOAF</a></li>
	     <li class="tocline"><a href="#PortableContacts">5.3.4 PortableContacts</a></li>
	     <li class="tocline"><a href="#OpenSocial">5.3.5 OpenSocial</a></li>
         </ul></li>
     </ul></li>
     <li class="tocline"><a href="#SocialMedia">6. Social Media</a>
       <ul class="toc">
         <li class="tocline"><a href="#Fined">6.1  Problem: Fined for Consuming Social Media</a></li>
         <li class="tocline"><a href="#Safely">6.2  Use-Case:  Safely Drag-and-Drop Social Media Across Multiple Platforms</a></li>
         <li class="tocline"><a href="#SocialMediaStandards">6.3 Social Media Standards</a>
           <ul class="toc">
             <li class="tocline"><a href="#Tagging">6.3.1 Tagging</a></li>
             <li class="tocline"><a href="#Microformats">6.3.2 Microformats</a></li>
	     <li class="tocline"><a href="#OpenGraphProtocol">6.3.3 Open Graph Protocol</a></li>
	     <li class="tocline"><a href="#Payswarm">6.3.4 Payswarm</a></li>
  	     <li class="tocline"><a href="#OExchange">6.3.5 OExchange</a></li>
  	     <li class="tocline"><a href="#Semantic">6.3.6 The Semantic Web</a></li>
              <li class="tocline"><a href="#SIOC">6.3.7 SIOC</a></li>
         </ul></li>
     </ul></li>
     <li class="tocline"><a href="#Privacy">7. Privacy </a>
       <ul class="toc">
         <li class="tocline"><a href="#Violation">7.1  Problem: Violation of Privacy</a></li>
         <li class="tocline"><a href="#Your">7.2  Use-Case: Your Own Terms of Service</a></li>
         <li class="tocline"><a href="#PrivacyStandards">7.3 Privacy Standards</a>
           <ul class="toc">
             <li class="tocline"><a href="#P3P">7.3.1 P3P</a></li>
             <li class="tocline"><a href="#POWDER">7.3.2 POWDER</a></li>
             <li class="tocline"><a href="#AIR">7.3.3 AIR</a></li>
	     <li class="tocline"><a href="#XACML">7.3.4 XACML</a></li>
	     <li class="tocline"><a href="#Rule">7.3.5 Rule Interchange Format </a></li>
	     <li class="tocline"><a href="#Device">7.3.6 Device APIs and Policy Working Group</a></li>
	     <li class="tocline"><a href="#Mozilla">7.3.7 Mozilla Privacy Icons</a></li>
	     <li class="tocline"><a href="#ODRL">7.3.8 ODRL</a></li>
         </ul></li>
     </ul></li>
     <li class="tocline"><a href="#Activity">8. Activity</a>
       <ul class="toc">
         <li class="tocline"><a href="#Cannot">8.1 Problem: Can not Integrate Conversations</a></li>
         <li class="tocline"><a href="#Realtime">8.2 Use-Case: Real-time Collaboration</a></li>
         <li class="tocline"><a href="#ActivityStandards">8.3 Activity Standards</a>
           <ul class="toc">
             <li class="tocline"><a href="#XMPP">8.3.1 XMPP</a></li>
             <li class="tocline"><a href="#Atom">8.3.2 Atom and Pubsubhubbub</a></li>
             <li class="tocline"><a href="#ActivityStreams">8.3.3  ActivityStreams</a></li>
	     <li class="tocline"><a href="#Salmon">8.3.4 Salmon Protocol</a></li>
	     <li class="tocline"><a href="#OStatus">8.3.5 OStatus</a></li>
         </ul></li>
     </ul></li>
     <li class="tocline"><a href="#Accessibility">9.  Accessibility Concerns</a></li>
     <li class="tocline"><a href="#Decentralized">10. Decentralized Social Networking Projects</a>
       <ul class="toc">
	 <li class="tocline"><a href="#Statusnet">10.1 StatusNet</a></li>
	 <li class="tocline"><a href="#GNU">10.2 GNU social</a></li>
	 <li class="tocline"><a href="#OneSocialWeb">10.3 OneSocialWeb</a></li>
	 <li class="tocline"><a href="#Higgin">10.4 Higgin's Project</a></li>
	 <li class="tocline"><a href="#Diaspora">10.5 Diaspora</a></li>
	 <li class="tocline"><a href="#Diso">10.6 Diso Project</a></li>
	 <li class="tocline"><a href="#SMOB">10.7 SMOB</a></li>
	 <li class="tocline"><a href="#Appleseed">10.8 Appleseed</a></li>
	 <li class="tocline"><a href="#OpenLink">10.9 OpenLink Data Spaces</a></li>
	 <li class="tocline"><a href="#Project">10.10 Project Danube</a></li>
     </ul></li>
     <li class="tocline"><a href="#Business">11. Business Considerations</a>
       <ul class="toc">
	 <li class="tocline"><a href="#Size">11.1 Size of Social Networking in 2010</a></li>
	 <li class="tocline"><a href="#Current">11.2 Current business models for social networks</a></li>
	 <li class="tocline"><a href="#New">11.3 New business models</a></li>
       </ul></li>
     <li class="tocline"><a href="#Conclusions">12. Conclusions</a>
      <ul class="toc">
	<li class="tocline"><a href="#Investigate">12.1  Investigate Identity in the Browser</a></li>
	<li class="tocline"><a href="#Coordinate">12.2 Co-ordinate the Core of Profile Data</a></li>
	<li class="tocline"><a href="#Combining">12.3 Combining Social Media and the Semantic Web</a></li>
	<li class="tocline"><a href="#Reengage">12.4  Re-engage Privacy Activity Focusing on the Social Web</a></li>
	<li class="tocline"><a href="#Federated">12.5 Support the Federated Social Web</a></li>
	<li class="tocline"><a href="#Open">12.6 Open the World Wide Web Consortium</a></li>
       </ul></li>
     <li class="tocline"><a href="#Acknowledgments">13. Acknowledgments</a></li>
     <li class="tocline"><a href="#References">14. References</a></li>
    </ul>
  </div>

<div class="body">

<h2 id="Overview">1. Overview</h2>

<p>The Social Web is a set of relationships that link together people over the Web. The Web is an universal and open space of information where every item of interest can be identified with a Uniform Resource Identifier (URI) <a href="#ref-uri">[URI]</a>. While the best known current social networking sites on the Web limit themselves to relationships between people with accounts on a single site, the Social Web should extend across the entire Web. Just as people can call each other no matter which telephone provider they belong to, just as email allows people to send messages to each other irrespective of their e-mail provider, and just as the Web allows links to any website, so the Social Web should allow people to create networks of relationships across the entire Web, while giving people the ability to control their own privacy and data.
</p><p>The Social Web is not just about relationships, but about the applications and innovations that can be built on top of these relationships. Social-networking sites and other user-generated-content services on the Web have a potential to be enablers of innovation, but cannot achieve this potential without open and royalty-free standards for data portability, identity, social networking, and privacy.
</p><p>The Social Web Incubator Group (SWXG) was founded as an outcome of the W3C Workshop on the Future of Social Networking <a href="#ref-msnws">[MSNWS]</a> to uncover and document existing technologies, software, and standards (both proposed and adopted) needed to enable a universal and decentralized Social Web. The group also sought to identify gaps, conflicts, and other areas for future standardization and research to increase adoption of the Social Web.
</p><p>Over the course of the SWXG’s activity the, approximately thirty, participants on the conference calls discussed a wide variety of topics and heard from over thirty invited guests from within and outside the W3C. We conclude that while the Social Web is a space of innovation, it is still not a "first-class" citizen of the Web: Social applications currently largely evolved as silos and thus implementations and integration are inconsistent, with little guarantees of privacy and enforcement of terms-of-service.
</p><p>Further, the members of the XG conclude:
</p>

<ol><li> The Social Web does not suffer from a lack of potential standards. A large number of diverse groups have evolved data models, communication protocols, and data formats at tangents to one another, addressing a large number of communities, each of which has its own terminology and viewpoint.
</li><li> While there has been a large amount of work done in this area, in terms of both current potential and standards, these tend to address basic issues around identity and portability, but do not address more complex and vital issues such as privacy, policy enforcement, and provenance. All of these issues are present scope for further research and the development of future standards.
</li><li> The creation of a decentralized and federated Social Web, as part of Web architecture, is a revolutionary opportunity to provide both increased social data portability and enhanced end-user privacy.
</li><li>One key to make ordinary users take advantage of a decentralized Social Web is to build identity and portability into the browser and other devices.
</li></ol>
<p>We respectfully recommend to the W3C areas of future work in which the W3C should play a pivotal role:

</p>
<ol><li> Investigate how identity can become a central part of the Web by supporting solutions that would allow for a high-level of security, multiple identities, and that are decentralized in nature. The W3C can focus on the topic of identity in the browser initially and its work should be coordinated with existing identity work and communities.
</li><li> Define mappings between existing data-formats for profiles on a semantic level, making sure that a common core is available in a consistent manner across various syntactic serializations.
</li><li> Start work combining the Social Web with the Semantic Web to enable people to describe social media, with a focus on describing terms-of-service agreements, licensing, and micropayment information using standardized vocabularies, which should be easy to find and use.
</li><li> Begin an over-arching privacy activity for the W3C, exploring the combination of technical and social approaches. All W3C Recommendations should be inspected for privacy concerns.
</li><li> Support the Federated Social Web effort by providing resources to the test-case driven development of a decentralized social web.
</li><li> Create a more "light-weight" and open process so that groups working on the Social Web are able to work with the W3C and liaison more easily.
</li></ol>
<p>This work could form the basis of new Working Groups, improved liaising with non-W3C efforts and standardization bodies, and increased co-ordination and focus on the Social Web among existing W3C working groups.
</p>

<h2 id="State">2. State of the Social Web in 2010</h2>
<p>2010 has been a tumultuous year for the Social Web. However, the Social Web is not a new phenomenon that has no precedent, but the result of a popularization of existing technologies. Many social features were available over the Internet before the Web, ranging from the blog-like features of Engelbart's "Journal" system in NLS (oN-Line System, the second node of the Internet), messaging via e-mail and IRC, the Well (1984), and the "Member Profiles" of AOL. The "list of friends" that is ubiquitous on the Social Web existed in the hand-authored links on the earliest webpages. The Web has always been social. As shown by this diagram below by Tim Berners-Lee in his original 1989 proposal to create the World Wide Web, the Web from its inception was meant to include not only connections between hypertext documents, but the relationships between people <a href="#ref-tbl1989">[TBL1989]</a>. This was clarified as one of the original reasons for adding "machine-readable semantics" to the Web <a href="#ref-tbl1989">[TBL1994]</a>.
</p>
<div id="fig-timbl" class="figure">
<a href="timblproposal2.png" class="image" title="Excerpt from Information Management: A Proposal (right) next to slide from WWW 1994 talk (left)"><img alt="Excerpt from Information Management: A Proposal (right) next to slide from WWW 1994 talk (left)" src="timblproposal2.png" width="672" height="318"  /></a>
<p style="clear:both" class="figcaption">Excerpt from <em>Information Management: A Proposal</em> (right) <a href="#ref-tbl1989">[TBL1989]</a> next to slide from WWW 1994 talk (left) <a href="#ref-tbl1989">[TBL1994]</a></p>
</div>
<p>What was missing was an easy-to-use interface to make finding people you know and sharing data with them easily accessible. A number of websites, ranging from Classmates.com (1995) to SixDegrees (1997), pioneered these features for ordinary users of the Web. Since the early days of the Web people that maintained their own homepages have been posting activity updates to their sites, and this has been pushed into the mainstream with the development of user friendly blogging software (the word "blog" coming from "web log") such as LiveJournal. Innovations in this space allowed the general public to become more and more apt at blogging, and independent news sites such as Indymedia (1999) pioneered the notion of user-generated content management. However, these services remained fairly experimental up until after the collapse of the initial "dot-com" bubble. After this a rash of social networking sites like Friendster (2002), LinkedIn (2003), MySpace (2003), Orkut (2004), and Facebook (2004)  took off, and eventually became the most popular sites on the Web. Starting with Flickr (2004) and Youtube (2005), user-generated content took over this newly re-invigorated Social Web. The launch of Twitter (2007), a micro-blogging site, which propagated updates to users' social networks, via desktop and mobile devices, showed another dominant trend in the Social Web. It was around this time that the concept of the Social Web became associated both with the aforementioned companies and with the wider "Web 2.0" paradigm. Today, the Social Web is becoming part of corporate communication portfolios and Web 2.0 companies start commercializing data from and about their users.
</p><p>While the social networking site usage remains geographically disparate, with many countries developing their own most popular social networking sites such as Hi5  in Japan  and QQ in China, there has been an overall tendency towards users moving their profiles between services, such as users moving their profiles from Friendster to MySpace for example. This, in turn, led to a dismissive attitude by some that the most "popular" social networking sites would simply turn over every year or two. In a similar manner to how competition amongst search engines eventually led to the dominance of Google, Facebook rapidly rose to become a global leader in social networking. A number of major vendors began either purchasing social networking sites (such as the purchase of Blogger (2003) and Orkut (2007) by Google) and other companies like Yahoo!  trying to roll their-own social networking sites like Yahoo! 360 (2005). Social Web features, such as comments and user-generated content, became intertwined with such phenomenon as Flickr for sharing photos and YouTube for sharing video. Today, it is a de-facto requirement for websites to have social features and for individuals and organizations to have a presence on popular social networking sites. Yet the ways for web-sites to do so are currently fractured and have yet to be standardized.
</p><p>While empowered by the compelling user experience of these social networking sites, the real victim of these data-silos has been the end-users. Social networking sites encourage users to put their data into the given proprietary platform, and have tended to make the portability of the user's own data to another site or even their home computer difficult if not impossible. Architects of new Social Web services and user-advocacy groups began to ask for the ability of users to move their data from platform to platform. The first technology created specifically for a portable social graph was the Friend-of-a-Friend project  (FOAF) for the Semantic Web in 2001 <a href="#ref-foaf">[FOAF]</a>, and in 2005, a biannual gathering of developers started the Internet Identity Workshop from which work like OpenID emerged  <a href="#ref-openid">[OPENID]</a>. Momentum took off after Brad Fitzpatrick (formerly of Livejournal) posted his  "Thoughts on the Social Graph" with David Recordon in 2007  <a href="#ref-opengraph">[OPENGRAPH]</a>. There quickly followed a number of initiatives like the DataPortability initiative  <a href="#ref-dataport">[DATAPORT]</a>, the Data Liberation Front at Google  <a href="#ref-dlf">[DLF]</a>, and lately, the Federated Social Web initiative <a href="#ref-fsw">[FSW]</a>. As most of this activity was outside the W3C, many developers involved in the Social Web created the Open Web Foundation in 2008 to create light-weight patent and copyright agreements to cover their draft specifications <a href="#ref-owf">[OWF]</a>. This momentum has continued to attract interest from developers. However, an open and decentralized Social Web still seems distant and few users have actually left these data-silos.

</p><p>Many social networking sites considered privacy and portability to be contradictory. At its inception, Facebook denied users the ability to let data be portable outside its system due to concerns over user privacy, as their terms of service in 2006 stated that "We understand you may not want everyone in the world to have the information you share on Facebook; that is why we give you control of your information"  <a href="#ref-fbtos">[FBTOS]</a>. In one particularly infamous incident, in 2008 blogger Robert Scoble wanted to make his information portable by copying his contacts from Facebook, but had his account disabled by Facebook <a href="#ref-scoble">[SCOBLE]</a>.  However, in 2009 there seemed to be little concern about issues of privacy and portability except amongst those deeply immersed in designing social networking sites, with 20 percent of users listing privacy as a primary concern motivating their choice in using a social networking site  <a href="#ref-jungle">[JUNGLE]</a>. Today, privacy is a secondary argument to stimulate new sign-ups. Widespread usability problems impede users to exercise effective control over their personal information on social networking sites, where permissive defaults are another threat to privacy. Although Scott McNealy of SUN infamously remarked that "You have zero privacy anyway," recent studies show that youth have "an aspiration for increased privacy" and are equally concerned about privacy as adults <a href="#ref-pew">[PEW]</a>.
</p><p>As more people are adopting Web-enabled smartphones, with mobile users spending more minutes per day on social networking sites than the average PC user, in 2010 30% of smartphone users accessed social networks via mobile browsers, the mobile Social Web must not be ignored. Users seem attracted to mobile device access because they can consult with friends and quickly make decisions while remaining mobile, allowing users to use applications in a context such as the live-tracking of buses. Many popular social networks at the time of writing this  report tend to offer both a Web-based version, and a dedicated application which can be downloaded for the given smartphone platform. These dedicated applications tend to be able to make much greater use of built in sensors, and applications found on these smartphones. As several mobile social networking sites allow users to both upload their location and see the location of their friends, a number of small groups have joined together to form the OSLO alliance (Open Sharing of Location-based Objects)  <a href="#ref-oslo">[OSLO]</a>. OSLO includes many players in mobile social networking and location-based social software which have signed an agreement to enable their approximately 30 million users to share location information between mobile social networks, in essence supporting the portability of location information between services. However, this activity seems to have stalled and the W3C Device API WG  is quickly filling the gap by standardizing a  set of APIs to be implemented by mobile browsers to cater for access to device functionality, such as a user's address book, calendar, location, within a Web Application running inside a standard mobile browser. As more and more of Web usage goes mobile and data access speeds increase, one can expect the difference in capabilities between the Social Web and the Mobile Web to diminish.
</p><p>The end of 2009 was when the issues of privacy on the Social Web grew beyond a niche concern and entered the popular consciousness. Facebook's membership began increasing globally, overtaking many local social networking site <a href="#ref-map">[MAP]</a>. In December 2009, Facebook changed its privacy settings by defaulting certain privacy settings which in turn made part of a user's profile information public. Users were encouraged to use "privacy controls" to provide access control to their data, but many users found these controls to be confusing and the default settings led to revealing lists of friends. This sparked widespread outrage, even amongst governments  <a href="#ref-germanlaw">[GERMANLAW]</a>. Recently, in 2010 the United States's Federal Trade Commission even put forward a proposal for a "Do-Not-Track" mechanism <a href="#ref-ftc">[FTC]</a>. </p>
<p>
In response to these privacy concerns, there was increased interest in decentralizing the Social Web.  Tim Berners-Lee proposed "Socially Aware Cloud Computing"  <a href="#ref-tbl2009">[TBL2009]</a>, where he illustrated that the technologies required to have a decentralized Social Web were available and how it is but a matter of engineering to realize this vision. The announcement of the open-source Diaspora Project in the New York Times to create privacy-preserving and decentralized social network  <a href="#ref-nyt">[NYT]</a> led to even more media attention. Overall interest is high amongst vendors, as witnessed by the launch in 2010 of products like Vodafone's OneSocialWeb  <a href="#ref-osw">[OSW]</a>.The first attempt at developing a common test-suite across differing standards-based social networking sites happened at the Federated Social Web Summit  <a href="#ref-fsw">[FSW]</a>. At this point in history, the Social Web has became the dominant platform for communication, rapidly beginning to even eclipse the use of e-mail amongst youth. The next steps taken by the companies and communities around the Social Web will have real consequences on the future of the Web and communication itself.</p>

<h2 id="Frameworks">3. Social Web Frameworks</h2>

<h3 id="Problem">3.1  The Problem of Walled Gardens</h3>
<p>The importance of the Web has always been its open and distributed nature as a universal space of information. Until recently this space of information has been limited to hypertext web-pages without attention being paid to social interactions and relationships. This was not a particular fault of the Web, in fact but a result of a certain focus of the early Web on documents. However, these kinds of activities are currently restricted to particular social networking sites, where the identity of a user and their data can easily be entered, but only accessed and manipulated via proprietary interfaces, so creating a "wall" around connections and personal data, as illustrated in the picture below. This current dismal situation is analogous to the early days of hypertext before the World Wide Web, where various systems stored hypertext in proprietary and incompatible formats without the ability to use, globally link and access hypertext data across systems, a situation solved by the creation of URIs and HTML. A truly universal, open, and distributed Social Web architecture is needed.
</p>
<div id="fig-simonds" class="figure">
<a href="Simondseconoart-small.png" class="image" title="Social Networking Sites as Walled Gardens by David Simonds (Used with permission"><img alt="Social Networking Sites as Walled Gardens by David Simonds (Used with permission" src="Simondseconoart-small.png" width="465" height="374"    /></a>
<p style="clear:both" class="figcaption">Social Networking Sites as Walled Gardens by David Simonds (Used with permission)</p>
</div>

<p>The lack of such an architecture deeply impacts the everyday experience of the Web of many users. There are four major problems experienced by the end user:
</p>
<ol><li> <strong>Portability</strong>: An ordinary user can not download their own data and share it as they like. Information stored on social networks could be useful for any number of applications, but the lack of portability of tediously entered social networking information causes users to continually re-enter and update their personal information, wasting their time.
</li><li> <strong>Identity</strong>: Not having a easy way to manage digital identity across digital networks leads to unsafe re-usage of passwords. Every time a user goes to a new site, they must not only create a new username and password, but re-find their friends and entice friends to move sites with them. Porting personal data from one network to another does not solve the problem of loosing one's friends if one moves.
</li><li> <strong>Linkability</strong>: Users have no way of being notified if they are being mentioned on a social networking site which they are not a member of. For example, if someone takes a photo of some friends at a party and wishes to publish it on the Web to share with those friends, but does not wish to make that publicly available, he must find a social network where each one of them is already a member, or simply not tell people that the photo has been uploaded.
</li><li> <strong>Privacy</strong>: A user cannot control how their information is viewed by others in different contexts by different social applications even on the same social networking site, which raises privacy concerns. Privacy means giving people control over their data, empowering people so they can communicate the way they want. This control is lacking if configuring data sharing is effectively impossible or data disclosure by others about oneself cannot be prevented or undone.
</li></ol>
<p>Participation is the life blood of social networks. If no one (or if too few people) participates, a social networking application dies.  If social applications are to thrive and provide engaging and valuable services to users, they must be easy-to-use, and must support ways for people to connect with and manage their social interactions and connections across multiple sites. While we take a "user-centric" approach in this report, having a common set of Social Web standards is a "win-win" proposition for both industry and users. As portability issues prevent new and small companies from building innovative applications, as these applications often need access to social data held on third-party sites. In turn, large social networking sites themselves lack standards to easily share and monetize their data with other companies. Lastly, the lack of standards forces developers to create multiple versions of the same social application for different closed platforms.</p>

<h3 id="Vision">3.2  The Social Web Vision </h3>
<p>People express different aspects depending on  context, thus giving themselves multiple profiles that enable them to maintain various relationships within and across different contexts: the family, the sporting team, the business environment, and so on. Equally so, in every context certain information is usually desired to be kept private. In the 'pre-Web world' people can usually sustain this multiplicity of profiles as they are physically constrained to a relatively small set of social contexts and interaction opportunities. In some ways, social dynamics on the Web resemble those outside the Web, but social interactions on the Web differ in a number of important ways:
</p>
<ul><li>the kinds of profile exhibited by a single person are not controlled by the same constraints and so are less limited in scope, and so may include profiles for fictional personae.
</li><li>the set (number) of people with whom interactions are possible is not limited by distance or time. The Web allows for users to user connect with a vast number of people, which was inconceivable only a few years ago.
</li><li>a person can explicitly "manage" the relationships and access to information they wish to have with others and with the increasing convergence of the Web and the world outside the Web is also leading to increasing concerns about privacy as these worlds collide.
</li></ul>
<p>Anyone should be able to create and to organize one or more different profiles using a trusted social networking site of choice, including hosting their own site that they themselves run either on a server or locally in their browser. For example, a user might want to manage their personal information such as home address, telephone number, and best friends on their own personal "node" in a federated social network while their work-related information such as office address, office telephone number, and work colleagues is kept on a private social network on their corporate intra-net.  Current aggregator-based approaches, exemplified by FriendFeed, are but a short-term solution akin to "screen scraping", that work over a limited number of social networking sites, are fragile to changes in the sites' HTML, and which are legally dubious.
</p><p>The approach we endorse allows the user to own their own data and associate specific parts of their personal data directly to different social networking sites, as well as the ability to link to data and friends across different sites. For example, your Friends Profile can be exposed to MySpace and Twitter, whereas your Work Profile to Plaxo and LinkedIn, and links between data and friends should be possible across all these sites. Traditional services can utilize these features, so that your "health" profile can be exposed to health care providers and your "citizen" profile exposed to online government sites and services. In this world of portable social data, both large and small new players can then also interface to profiles and offer seamless personalized social applications.
</p><p>Privacy is a complex topic, and we understand privacy as control over accessibility of social information in general, including security as an enabler (the authentication of digital identity and ownership of data). Privacy controls are often not well-understood by users and they do not stop data "leaking" from the social networking site itself, which may give user data to other companies or even governments for some kind of gain without alerting the user. In this regard, public key encryption is one solid technical basis of keeping data private, whether on the server-side or in terms of encrypting client to server communication using SSL <a href="#ref-tls">[TLS]</a>. Privacy should be controlled by the users themselves in an explicit contract with social networking sites and applications that makes privacy controls easy-to-use and understandable. As custodian of their own profiles, users can then decide which social applications can access which profile details via explicitly exposing personal data to that application provider, and retracting it as well, at an appropriate level of granularity. This in itself is one of the biggest challenges for the entire Web community, not just social networks, and needs a new policy-oriented Web architecture to support trust and privacy on the Web in the longer term, while building on the technical strengths of encryption. Whilst technical security is a mandatory enabler, users' effective ability to control the processing of their data is largely influenced by helpful user interface design with strong visual metaphors, and privacy-enhancing default settings regarding data sharing.
</p><p>This Social Web architecture articulated here is not the invention of the Social Web Incubator Group, but of a long-standing community-based effort that has been running for multiple years, of which only a small fraction of the contributors have been explicitly interviewed and acknowledged by the Social Web Incubator Group. This report is dedicated to all the developers out there working to make this vision a reality.
</p>

<h3 id="Terminology">3.3  The Terminology</h3>

<p>As the Social Web is a large and innovative space, the creation of new terms  can not be avoided, but to be too loose with terminology may serve to cause confusion rather than build consensus. Building on existing work like the lexicon of Identity Commons <a href="#ref-idlexicon">[IDLEXICON]</a>, we propose definitions for the following concepts in order to clarify our presentation:
</p>
<table border="1" cellpadding="10" cellspacing="0">
<tr>
<td>Concept
</td><td>Definition

</td><td>Graphical Representation
</td></tr>
<tr>
<td>User
</td><td>The user is a person, organization, or other agent that participates in online social interactions on the Web.
</td><td><a href="9user.png" class="image" title="user"><img alt="user" src="9user.png" width="43" height="43"   /></a>
</td></tr>
<tr>
<td>Identity
</td><td>A single digital representation of a user. These are potentially unlimited and may coincide with different personae of the user such as a personal profile and work profile. This is a "personae" in the Identity Commons Lexicon.
</td><td><a href="9profile.png" class="image" title="identity"><img alt="identity" src="9profile.png" width="75" height="73"   /></a>
</td></tr>
<tr>
<td>Profile Attribute
</td><td>Information about a user that is a component of the profile such as name, e-mail, status, photo, work phone, home phone, blog address, etc. This is an "identity attribute" in the Identity Commons Lexicon.
</td><td><a href="9prop.png" class="image" title="profile attribute"><img alt="profile attribute" src="9prop.png" width="40" height="22"   /></a>.
</td></tr>

<tr>
<td>Social Connection
</td><td>Social connections are associations between a profile and a resource (or group of resources) and may include the type of the relationship (e.g. friend, colleague, spouse, likes etc) and may be either reciprocal ('friend') or uni-directional (following). The connection may be between different users or between a user and some social media (a video or an item the user likes).  The collection of all connections of a profile is called the <strong>Social Graph</strong> of that profile.
</td><td><a href="9socialconn.png" class="image" title="social connection"><img alt="social connection" src="9socialconn.png" width="65" height="26"   /></a> <a href="9socialconn-uni.png" class="image" title="unidirectional social connection"><img alt="unidirectional social connection" src="9socialconn-uni.png" width="65" height="26"   /></a>
</td></tr>
<tr>
<td> Social Group
</td><td> Social Groups are explicit named sets of social connections between resources. For example, My Football Team, Wine Club, My Favorite Movies, etc.
</td><td><a href="9socialgroup.png" class="image" title="social group"><img alt="social group" src="9socialgroup.png" width="43" height="52"   /></a>
</td></tr>
<tr>

<td>Social Platforms
</td><td>Social platforms refer to a collection of features in which the user can interact with their social connections and social media, publish social media, and use social applications. The social platform is often centered on a single website,a <em>social networking site</em> analogous to Facebook or LinkedIn, but may also be owned and controlled by the user.
</td><td><a href="9socialapp.png" class="image" title="social platform"><img alt="social platform" src="9socialapp.png" width="111" height="70"   /></a>
</td></tr>
<tr>
<td>Distributed Social Graph
</td><td>A set of profiles and social connections between agents which may be hosted across different social platforms.
</td><td><a href="9prop-d.png" class="image" title="distributed social graph"><img alt="distributed social graph" src="9prop-d.png" width="65" height="73"   /></a>
</td></tr>
<tr>
<td>Social Applications
</td><td>Social Applications are functions of a social platform such as real-time messaging and social games. Social applications may be bound to a particular social platform (Facebook and FBML, Twitter API) or capable of running across multiple social platforms (OpenSocial). Note that the difference between a social platform and a social application is often fuzzy, as some platforms do not allow third-party applications, and some platforms are indistinguishable from their applications.

</td><td><a href="9socialappserv.png" class="image" title="social app"><img alt="social app" src="9socialappserv.png" width="43" height="43"   /></a>
</td></tr>
<tr>
<td>Profile Association
</td><td>A kind of social connection. A profile associations are used to indicate the link between a specific profile and a social platform. The social platform can then provide profile attributes for use to social applications.
</td><td><a href="9profileassoc.png" class="image" title="profile association"><img alt="profile association" src="9profileassoc.png" width="65" height="26"   /></a>
</td></tr>
<tr>
<td>Social Interaction
</td><td>A social interaction links a Social Web user and a social platform by providing all the necessary applications and profile information.
</td><td><a href="9socialinter.png" class="image" title="9socialinter.png"><img alt="9socialinter.png" src="9socialinter.png" width="48" height="30"   /></a>
</td></tr></table>
<p><br />
</p>


<h3 id="User">3.3.1  Social Web User and Profiles</h3>
<p>Figure 1 belows shows how a single user (one person) can have multiple profiles that share common attributes. A user can then associate her profile at the profile level with particular social applications, perhaps controlling them in some sort of aggregated view in an application. The profiles are exposed to and synchronized with different social networking sites and platforms. In some cases, the social networking site will update a profile property and this modified property will be reflected across all profile instances. The attributes included in a profile will depend greatly on the needs and desires of the user and context of each social application, including  dynamic attributes that capture the evolving changes of a person’s context, such as geolocation attributes.  In Figure 1, one profile is associated with the "light blue" and "red" social applications, one profile to the "grey" social application, and one profile to the "blue", "green", and "orange" social applications.
</p>

<div id="fig-identity" class="figure">
<a href="1identity.png" class="image" title="Social Identity"><img alt="Social Identity" src="1identity.png" width="676" height="437"   /></a>
<p style="clear:both" class="figcaption">A Single User with Multiple Profiles</p>
</div>

<h2 id="Single">3.3.2  Single Distributed Social Graph</h2>
<p>Attributes within a profile, including information about social connections, may be distributed. This means that the relevant attributes and social connections could be stored with a social application for use in the context of that application.  For example, a work phone attribute is stored by my current employer's social platform, but another social networking site (e.g., LinkedIn) may store my previous employer's information. Together, these two (distributed) attributes can be considered a distributed single "work" profile whose information I may want to combine in context of a social application (such as a job-hunting social application). Figure 2 below shows a profile that has two sets of two attributes at distributed sites each with  two local attributes. The user is interacting with the profile through the "blue" social platform, which could be a node in a decentralized Social Web. For example, a profile management service that could be run in the browser or via a third-party web-site would keep track of the distributed attributes and multiple profiles and allow the user to edit the attributes across multiple platforms and sites.
</p>

<div id="fig-distributed" class="figure">
<a href="2distributed.png" class="image" title="Distributed Profile"><img alt="Distributed Profile" src="2distributed.png" width="670" height="393"   /></a>
<p style="clear:both" class="figcaption">
A Single User with a Distributed Social Graph</p>
</div>

<h2 id="Multiple">3.3.3  Multiple Distributed Social Graphs</h2>
<p>A profile is associated with one or more social platforms in which the user's social graph is formed and nurtured.  The social platform is the context for how a user is connected to the profiles of others and will support the specific connection types (e.g. friend, colleague, likes, etc) that will typically serve the purpose of some social application. A core feature or service of a social application is to make, maintain, and expand these connections.
</p><p>A user’s connections in a particular social networking site or platform should be portable. The user should be able to take them to another social networking site, so it is not necessary to re-establish all connections again for another (new) social application.  Note that Amy (Profile 1) in the "blue" social platform is connected twice to Bob via his Profile 1 and 2. This demonstrates that the same user can connect via different social networking sites. The social networking sites do not necessarily have to be controlled by the same entity, but could be links through the open Web.  The lines between profiles  are either uni-directional (such as Twitter) or bi-directional (such as Facebook) to capture where the connection is one-way (following) or mutual (friendship). Two dots means that the connection is bi-directional.  One dot means the connection or association it is not reciprocal.
</p><p>Figure 3A shows an example of multiple distributed social graphs with a number of different users, profiles, and social networking sites or platforms. For example:
</p>
<ul><li> The blue social platform connects Amy (Profile#1) to Bob (Profile#2), Col (Profile#3), Dan (Profile#2), Bob (Profile#1).
</li><li> The green social platform connects Amy (Profile#1) to Fran (Profile#3), Gary (Profile#1), Ed (Profile#2).
</li><li> The orange platform connects Bob (Profile#1) to Amy (Profile#2), Fran (Profile#1), Ed (Profile#7).
</li><li> The red social platform connects Ed (Profile#7) to Dan (Profile#2).
</li></ul>
<p>Figure 3B shows an example of explicit groups. In this example, Amy has designated a number of her connections into two groups. These named groups then enable Amy to refer to the collection of connections in a single instance. For example, "allow my book reviews to be read by my Book Club members only", and with global digital identities and profile information, these groups could encompass users across many social networking sites and platforms.
</p>


<div id="fig-distributed2" class="figure">
<a href="800px-3Bgroup.png" class="image" title="Social Graph"><img alt="Social Graph" src="800px-3Bgroup.png" width="800" height="520"    /></a>
<p style="clear:both" class="figcaption">Distributed Social Graphs and Groups</p>
</div>

<p>So far, an emphasis has been placed on the creation and management of profiles with their associated interwoven multiple social graphs. To be successful, the Social Web must include far more than distributed profile and social graph management. We propose an open conceptual system in which there are multiple interoperable frameworks (see Figure 4) covering different levels of complexity and use-cases.
</p>

<div id="fig-framework" class="figure">
<a href="Frameworks.png" class="image" title="Frameworks"><img alt="Frameworks" src="Frameworks.png" width="740" height="563"   /></a>
<p style="clear:both" class="figcaption">Social Web Frameworks</p>
</div>

<h2 id="Case">3.4  The Case for Open Social Web Standards</h2>

<p>In effect we depict a "meta-framework" within which there currently appears:
</p>
<ul><li> Identity Framework,
</li><li> Profile Framework,
</li><li> Social Media Framework,
</li><li> Privacy Framework,
</li><li> Activity Framework, and
</li><li> Emerging Frameworks
</li></ul>
<p>At this point, we will assume the frameworks will be able to work together  seamlessly via a combination and harmonization of  standards in order to enable a wide variety of innovation across social networking sites, platforms and applications. An evolving combination of interoperable frameworks will move the Social Web towards this overall objective without constraining developers to a single monolithic architecture.
</p>
<p>Of utmost importance is the fact that any framework should lead to a core set of functionality that allows developers to easily interrelate their existing technologies while encouraging new uses and hence leading innovation rather than holding it back by premature optimization. The framework we are also proposing is modular, so that new emerging social applications and frameworks can be added. For example, it is possible to envisage an e-Commerce framework encompassing an assortment of billing, product tracking, fulfillment protocols which are already in use in e-commerce applications and that can build on top of the social media and policy frameworks. Shockingly enough, users are already sharing this kind of information through sites such as Blippy.  Another possible framework is an analytics framework that enables users to benefit from active social application participation by providing the dynamic analysis of the users behavior's and feeding this back into the user's profile via automatically creating and updating a user's profile information based on an analysis of their activity. This could enable the formation of communities-of-interest as the profiles of individuals reach a threshold of similarity if the privacy settings of a person's profile allow such connections to be made. Lastly, one could imagine a trust framework that is highly dependent on identity, context, and the provenance of social media.   The level of trust necessary between a merchant and a user, for the purpose of fulfilling a transaction is on a different scale than that of sharing a blog post and trust will likely vary wildly across individuals and contexts, and so not easily be reducible to overly-simplistic metrics.
</p>
<p>A critical problem in realizing this vision of Social Web is the fact that any "distributed" social networking platform will become yet another walled garden unless it is based on open and royalty-free standards. Simply creating yet another decentralized social networking codebase will likely not be the solution by itself, as that would require everyone to use the same code and limit innovation. Instead, a number of social networking sites and applications based on different code-bases can band together and share their data using standards, which allows them to maintain their autonomy and development while still gaining the "network effect" of having large numbers of users.  Via open standards,  multiple social networking platforms ranging from large vendors to simple personal websites should be able to demonstrate interoperability. For example, one codebase could use Atom, a format based on serializing updates in tree-structured XML <a href="#ref-password">[ATOM]</a>, while another could use RDF, a graph-based data model where all the data is identified with URIs. However, by using open standards that can communicate to each other, these different architectures and codebases should be able to work together to share status updates with each other. While the technology and work already exists to create such an decentralized social web, the standards needed by developers are currently scattered across various communities and are at times even incompatible, so that producing a single overview of what technologies and standards exist is a difficult if not impossible task. Lastly, without strong royalty-free patent policies, it is also impossible to guarantee that implementers can develop a distributed social networking codebase without being hit by a patent lawsuit.
</p>

<h2 id="Identity">4. Identity</h2>
<p><strong>Identity</strong> is the connection between a profile, a set of attributes, and a user. Some credentials or "proof" of identity may be required from the user to access or create a profile, which is the step of <strong>authentication</strong>. In particular, these credentials may take many forms such as a password, a signed digital certificate, or some other log-in credentials.  Identity providers make claims (at least one) by providing attributes and may or
may not authenticate the identity of a user. One of the most important parts of any profile claim is the identifier (a URI, including an
e-mail address) for a user, although making a claim does not always reveal an identifier. An identity may be de-coupled from all but the most minimal of profiles (a simple identifier) and make claims without revealing any identifier, and may be anonymized so as to not include a user's true identity (i.e. legal name or other identifying characteristics).

</p><p>Using an identity selector, a user may want to select from amongst multiple profiles (each of which could be a personae) and their attendant set
of attributes. Each of these sets of claims could be hosted by different providers. A user should be able to have multiple identities as well as multiple profiles. A user should be able to revoke an identity if it becomes compromised or for any other reason.
</p>

<h2 id="Usernames"> 4.1 Problem: Usernames and Passwords are Insecure </h2>
<p>Username and password combinations are currently the most prevalent identification technology on the Web. They are easy to understand, but suffer from a number of technical and economic drawbacks, including phishing threats. Web users are excessively requested to create password-backed accounts across various websites, leading to password-reuse with growing insecurity of each account. Passwords that are manually generated are often insecure, and automatically generated ones are difficult to remember. Widespread technical negligence in implementing password systems securely further undermines the security of password systems on the Web, and can be partially attributed to lacking practical advice or standards on how to implement good password schemes <a href="#ref-password">[PASSWORD]</a>. Approaches like Facebook Connect and Google FriendConnect at this point rely on user-name and password-based authentication for sharing personal social data.
</p>

<h2 id="No">4.2 Use Case: No more passwords (or only one) </h2>
<p>Social Web user Alice wants to access her social networking sites Twitbook for her friends and BizLink for job contacts. She wants to keep the two identities separate, and access these sites from multiple devices. Unfortunately, Alice uses so many social networking sites and associated applications that she currently just repeats the same password and username combination over and over again, which is insecure and may lead to identity theft. Luckily, using a distributed and secure identity framework, she can verify her identity by associating herself to a profile using some proof like self-signed certificates on her favorite devices like her laptop and mobile phone. Furthermore, as sometimes she may want to access her social networking site using an Internet cafe while traveling,  she finds a trusted third-party passphrase-based identity provider called SocialAggregator. It should be noted that if SocialAggregator is developed on top of open standards, people would be able to implement their own version of such a service, allowing them to host it where they wished. As both Twitbook and Bizlink support her standardized identity authentication mechanism, whether it is used via her browser on her mobile phone and laptop or via a third-party identity provider, Alice no longer has to remember passwords when she uses any social networking site or application on her trusted everyday devices, and has to use a passphrase only when not using a trusted device.
</p>

<h2 id="IdentityStandards">4.3 Identity Standards</h2>

<p>This section will list a number of online identity providers which are currently deployed or in development on the Web. We will include both identity standards, as well as authentication and discovery standards that rely on a notion of digital identity.
</p>

<h2 id="Browser">4.3.1 Browser-based Password Management </h2>
<p>Browsers now make it easier for users to create different passwords for each website by remembering them for the user, as is currently implemented by Mozilla.  The Weave Project of Mozilla aims to make password based authentication more integrated in the browser by allowing the browser to create and update passwords automatically across the Web, and its first release is the Sync project <a href="#ref-sync">[SYNC]</a>. Instead of trapping the user within the browser, Mozilla's Sync plugin allows the user to copy passwords, browser preferences and bookmarks from one browser and device to another in a secure manner by storing these preferences cryptographically encrypted on a server <a href="#ref-sync">[SYNC]</a>. The end user then only needs to remember this URL and the one password for its contents, to be able to retrieve it in any other device that knows how to decrypt and read the content. While currently browser based approaches do not track social connections, these could be addressed in future work, and one could imagine cross-browser generalizations of Sync functionality. However, even then it would not address the ability to make and use connections across different social networking sites.</p>

<h2 id="OAuth">4.3.2 OAuth </h2>
<p>OAuth (Open Authorization) is an IETF standard that lets users share their private resources on a resource-hosting site with another third-party site without having to give the third-party their credentials for the site and so access to all their personal data on the social site <a href="#ref-oauth1">[OAUTH1]</a>. OAuth is a standard for granting data authorization to third parties, allowing people to grant access to private resources after authenticating themselves via their online identity. This standard essentially defeats the dangerous practice of many early social networking sites of accessing the username and password of an e-mail account in order to populate a list of friends. Instead, OAuth allows an authorized handshake to happen between a resource-hosting site and a third-party, which then lets the third-party  redirect the user to authorize the transaction explicitly on the original site. If the transaction is explicitly authorized, then OAuth generates a  duration-limited token for the third party that grants access to the resource-hosting site for specific resource. OAuth's tokens establish a unique ID and shared secret for the client making the request, the authorization request, and the access grant. To its huge advantage, this approach works securely over ordinary HTTP requests, as the client generates a signature on every API call by encrypting unique information using the token secret, and the token secrets never leave the sites. However, a session-fixation attack was discovered in the original specification that allowed a malicious party to save the authorization request and then convince a victim to authorize it, giving the malicious party access to the victim's resources. This attack was fixed by having the third-party register with the resource-hosting site, as given in an update to OAuth. Recently there has also been a timing attacks (using the difference of time in "bad" and correct digital signature verification to figure out tokens), but this has been addressed by having digital signature verification use a constant time. </p>

<p>While OAuth 1.0 is highly successful, the creation of the cryptographic work needed to produce correct signatures and the managing of various tokens was considered too difficult by many developers, so the IETF draft standard OAuth 2.0 simplifies the process <a href="#ref-oauth2">[OAUTH2]</a>. OAuth 2.0 does this by relying on  Transport Layer Security (TLS), another IETF standard for securing traffic over the Internet using encryption, which is usually known by the name of its predecessor from Netscape, Secure Sockets Layer (SSL) <a href="#ref-tls">[TLS]</a>. OAuth 2.0 also breaks apart the various use-cases around getting tokens such that each is simpler. OAuth 2.0 requires that the resource-hosting site use HTTPS rather than HTTP and is therefore backwards incompatible with OAuth 1.0, i.e. as OAuth 2.0 requires SSL and OAuth 1.0 does not. SSL is required to generate tokens in OAuth 2.0, so signatures are no longer required for both token generation and API calls. Decreasing complexity, OAuth 2.0 has just a single security token and no signature is required. This has led to wider adoption across social networking sites like Twitter and Facebook.</p>

<h2 id="OpenID">4.3.3 OpenID </h2>
<p>OpenID  centralizes the authentication step at an identity provider, so that a user can identify themselves with one site (an OpenID identity provider) and share their profile data with another site, the relying party <a href="#ref-openid">[OPENID]</a>. A user need only remember one globally unique identity, which in OpenID 1.0 was a URI. In the initial OpenID 1.0 specification, the identity provider was discovered by following links of a HTML page accessed by the OpenID 1.0 URI, and OpenID 2.0 also allowed the use of the XRD format <a href="#ref-xrd">[XRD]</a>. One of the primary findings of the OpenID effort was that many non-technical users were unable to use URIs to identify themselves, and so approaches like directed identity and Webfinger, or even just an e-mail address enabled by the Webfinger, were developed to facilitate adoption [WEBFINGER].  With directed identity, the user only needs to click on a graphical icon of their preferred ID provider to execute the login process.  These enhancements dramatically improved the usability and adoption of OpenID. </p>

<p>Once the OpenID provider is discovered, a shared secret is established in between the provider and the relying party, allowing them to share data.Initially data was exchanged via one of two OpenID extensions, Simple Registration or Attribute Exchange <a href="#ref-openid">[OPENID]</a>.  These extensions allow the user to specify what personal data should be sent to the relying party. Note that the attribute exchange protocol is constrained by the information that can be placed as attribute-value pairs inside a URI, which is practically limited to a maximum of 2000 characters. However, many identity providers have implemented an OpenID/OAuth hybrid approach which allows for more robust data sharing.  Additionally, the OpenID Foundation is working on the Artifact Binding protocol which will also allow for more extensive data sharing.  Large international OpenID identity providers include AOL, Blogger, Flickr, France Telecom, Google, GMX/Web.DE, Hyves, Janrain, Livedoor, LiveJournal, Mixi, MySpace, NEC Biglobe, Netlog, Rakuten, Telecom Italia, Verisign, WordPress, and Yahoo. In total these represent over one billion user accounts.  Not all OpenID providers are also OpenID relying parties, but over the past year a number including Yahoo, Google, and AOL have also become relying parties.</p>
<p>As a server-side solution, OpenID and successor technologies have the advantage of only relying on server-side HTTP redirects, and so in general works independent of browsers. OpenID does not specify the credentials needed by the authentication mechanism, and very few OpenID providers provide authentication based on certificates or other kinds of credentials today, generally utilizing username-password authentication. As with all traditional username-password authentication processes, which represent the majority of all web-based authentication processes today, a possibility for phishing using redirection to "fake" identity providers exists  <a href="#ref-laurie">[LAURIE]</a>. Thus far there have been no significant reported OpenID related incidents and secondary forms of authentication (i.e. certificates, challenge questions, biometrics, one time passwords, etc.) can be utilized to minimize the threat, as with traditional username/password authentication processes. Many OpenID providers including Google, Verisign, and Janrain offer various kinds of secondary authentication.  Additionally, most major OpenID providers have implemented sophisticated backend policies and analytic tools to ensure the security of their users and services, in much the same way credit card issuers utilize analytics to detect and prevent unusual or fraudulent behavior.  In this way, OpenID-based authentication can be more secure and reliable than traditional username/password authentication since OpenID identity providers have dedicated teams and capabilities well beyond what most independent website operators provide.

</p><p>Some developers view the technology as complex, requiring up to 7 HTTPS connections in the workflow.  OpenID supporters feel that past and future enhancements continue to drive ease of deployment and adoption of the technology. There are also a number of third party solutions and plug-ins that facilitate deployment.  Additionally, given the similarities between the workflow of OpenID and the success of OAuth with developers, the OpenID Foundation is pursuing a new version of OpenID, known as OpenID Connect, being built on top of OAuth  <a href="#ref-oidconnect">[OIDCONNECT]</a>. Due to the existence of OAuth 2.0, OpenID Connect is designed to be a thin layer on top of OAuth. One of the major things this brings to OAuth is true decentralization in terms of not needing to pre-register consumer keys and secrets with a given service. It will also standardize some basic profile attributes that are commonly available across providers. OpenID-Connect will offer an alternative to the OpenID 2.0 with Attribute Exchange and Artifact Binding approach also in development. As each of these initiatives progresses, the market will determine the appropriate applications and use cases for each approach.
</p>


<h2 id="WebID">4.3.4  WebID  </h2>
<p>WebID uses TLS and client-side certificates for identification and authentication <a href="#ref-webid">[WEBID]</a>. To authenticate a user requesting an access-controlled resource over HTTPS, the "verifying agent" controlling the resource needs to request an X.509 certificate from the client. Inside this certificate, in addition to the public-key there is a "Subject Alternative Name" field which contains a URI identifying the user (the "WebID"). Using standard TLS mutual-authentication, the user agent confirms they know the private key matching the public-key in the certificate. A single HTTPS cachable lookup on the WebID should retrieve a profile. If the semantics of the profile specifies that the user named by that URI is whoever knows the private key of the public-key sent in the X.509 certificate, this will confirm that the user is indeed named by the WebID, allowing the authenticating agent to make an access control decision based on the position of the WebID in a web of trust. WebID was originally known as FOAF+SSL <a href="#ref-foafssl">[FOAFSSL]</a>.
</p><p>The user does not need to remember any identifier or even password and the protocol uses exactly the same TLS stack as is used for global commercial transactions and is not vulnerable to phishing.  As it is widely known that certificate authorities can be impersonated (although with a lot of work) <a href="#ref-rogue">[ROGUE]</a>, instead of relying on widely known certificate authorities, the client side certificates may be self-signed. Such certificates can be generated in the browser in a one click operation. Disabling a certificate is as simple as removing the public keys from the personal profile.
</p><p>However, there are a number of problems with this approach. First, certificate management and selection in browsers still has a lot of room for improvement on desktop browsers, and is a lot less widely supported on mobile devices, although there exists WebID implementations that are written in Javascript as to be completely de-coupled from the browser. Furthermore, it is often thought that by tying identity to a certificate in a browser, users are tied to the device on which their certificate was created.  In fact a user profile can publish a number of  keys for each browser, and certificates are cheap to create.  Some people see that this can be enhanced by uses of protocol such as the Nigori Protocol that requires only a single password to access "secrets" like certificates on a server <a href="#ref-nigori">[NIGORI]</a>. Combined with Nigori, WebID could be integrated into a Mozilla Sync-style identity management system <a href="#ref-sync">[SYNC]</a>.
</p>

<h2 id="Infocard">4.3.5 Infocard</h2>
<p>Infocard (Information Cards) is a user-centered identity technology based on three interrelated concepts: the card metaphor, active client software, and a protocol for identity authentication <a href="#ref-infocard">[INFOCARD]</a>. As such, it is a multi-layered integrated approach and infrastructure in and of itself. "Active client" software integrated with the local browser acts as a local digital wallet for the user. Each card in this wallet supports a set of profile attributes called "claims." Personal cards can be created directly by the user and hold self-asserted claims and values. "Managed cards," on the other hand, are issued by identity provider websites that act as the authority for the claims supported by that card. The interactions between the active client and external services are defined by the OASIS IMI protocol <a href="#ref-imi">[IMI]</a>.
</p>

<p>Under IMI, an Infocard-compatible relying party website, usually via HTML extensions passively expresses its policy: the set of claim URIs that it requires, the card issuer it trusts, etc  <a href="#ref-imi">[IMI]</a>. When the user clicks on an HTML button, extensions with the browser trigger the invocation of the active client which displays a set of cards that support the claims required. If a managed card is selected by the user, the user authenticates and the client fetches a security token from the card issuer site using IMI protocols, and POSTs it to the relying website where it can be validated and the claim values extracted. Thus Infocards eliminates the need for per-site passwords, allows minimum disclosure, and provider stronger levels of assurance if the verification is done locally. Microsoft's Cardspace, is built into Vista and Windows 7 and open-source projects include Novell's Digital Me, OpenInfocard, and Eclipse Higgins <a href="#ref-higgins">[HIGGINS]</a>.
</p>

<p>However, its main disadvantage is the perceived complexity of interlocking standards and technology needed to support the architecture, so current work is on driving adoption via focus on applications in the government sector, as it does offer a higher level of assurance than  browser-redirect-based identity technologies. Also, cards are too tied to a single device, so work is underway to incorporate Web services to at least provide "card roaming" across browsers and devices as well as making Infocards more compatible with other technology stacks.
</p>

<h2 id="XAuth">4.3.6 XAuth</h2>
<p>XAuth allows multiple identity providers to update an "XAuth provider" (currently only <em>xauth.org</em>) so that third parties can authenticate a given user's identity <a href="#ref-xauth">[XAUTH]</a>. When a user signs-on to an account on an XAuth-enabled identity provider, the identity provider notifies <em>xauth.org</em>. When a site is encountered that needs authentication, the site can use some simple embedded Javascript to ask <em>xauth.org</em> which identity providers the user is logged in on, and then uses the cookies stored locally on the browser to help the user authenticate with the third-party site. This approach easily allows logging out (as XAuth-enabled identity providers can tell <em>xauth.org</em> that the user's session has ended) and lets users enable or block identity providers. However, this approach has been heavily criticized. First, <em>xauth.org</em> is controlled by a single entity (currently the company Meebo), and as a result XAuth is heavily centralized  <a href="#ref-xauthc">[XAUTHC]</a>. Although this could be fixed (i.e. letting xauth.org redirect to a local host <a href="#ref-xauthd">[XAUTHD]</a>, it still reveals to third-parties the identity providers a user employs without their authentication, which can be enough information to identify them for malicious purposes <a href="#ref-mali">[MALI]</a>. Google and Meebo deploy XAuth.
</p>

<h2 id="SAML">4.3.7 SAML</h2>
<p>SAML (Security Assertion Markup Language) is an OASIS standard for the exchange of authentication and privacy between identity providers and service providers using an XML-based data format, tackling the single-sign on problem amongst many others <a href="#ref-saml">[SAML]</a>. SAML allows one to make assertions that include the subject making the assertion, the time of the assertion, any conditions to the assertion, and the resource to be accessed. An identity provider that can verify these assertions using  a number of means by the identity provider, such as SSL, and make an authorization decision. SAML is often embedded in SOAP messages.  In addition to the SAML protocol itself, SAML metadata supports the communication of identity provider and relying party information across multiple federations and so can be leveraged by federation providers and the majority of higher education institutions around the world as well as by other protocols such as Infocard and OpenID.
</p><p>Examples of SAML deployment include universities, Google, SalesForce.com, Cisco, and WebEx. Unlike many other identity technologies, SAML is able to provide security solutions for banking and government web portals. In 2010 SAML was certified by the US Government for use by external identity providers at Identity Level of Assurance 1 through 3 for accessing specified government resources. SAML is, however, often viewed as being more complex than is necessary to support implementations requiring low levels of assurance.  This has driven many developers to deploy simpler technologies like OpenID in low assurance scenarios.
</p>

<h2 id="Kantara">4.3.8 Kantara Trust Framework</h2>

<p>The Kantara Initiative  fosters the emerging Trust Framework model which enables interoperability and trust in identity authentication systems through  certified credentials <a href="http://kantarainitiative.org">[KANTARA]</a>. This framework is composed of policy, privacy, and protocol deployment criteria to enable trust across all actors in a transaction, from end-users to identity providers and federation operators.
</p><p>Kantara Initiative has developed an Identity Assurance Framework (IAF) as the criteria for interoperability amongst identity providers <a href="#ref-iaf">[IAF]</a>. The IAF is certified when a combination of privacy and protocol profiles provides the Trust Framework. The Kantara Initiative IAF is technology agnostic and available to be profiled (specific to jurisdictions and verticals).  Kantara Initiative also currently operates an Accreditation and Certification Program to accredit auditors to perform assessments and certify identity providers.  The US Government has fostered some of the first  deployments of this model. Kantara is continuing to refine the model with other stakeholders across the globe.</p>


<h2 id="Profiles">5. Profiles</h2>
<p>The Profile framework contains those applications which can be used to access attributes and the distributed access to such information. Users in this stage should also be able to find, discover, add and delete connections in order to update their profile. A user may want to select amongst multiple profiles (each of which could be a personae) and their attendant set of attributes. Each of these set of claims could be hosted by different providers. It should be possible for a user to control multiple profiles across multiple social networking sites, and synchronize the updates to their identity providers. In this manner, social applications should be able to share profile information, but on an as needed basis, so that only the information needed in a particular context is revealed. Users can then be able to import their connections to new social networking sites and applications so they do not have to find and confirm all contacts from scratch over and over again. Furthermore, a user should be able to export all their profile information and delete all profile information from an identity provider.
</p>

<h2 id="Can">5.1  Problem:  Can Not Describe Yourself</h2>
<p>Today, when users create profiles they are often constrained in how they describe themselves and have to manually re-find their friends. Worse, some social networking sites constrain preferences, such as gender and religion preferences, that can be very sensitive. Also, many users may wish to have different names and profiles on different kinds of sites, and on some sites anonymity is a must. Furthermore, a near fatal problem with the uptake of new social networking sites and applications is that not only do users have to re-enter all their information to conform to what the new site wants, but then they have to re-locate all their friends on the new site or re-invite them.
</p>


<h2 id="Keep">5.2  Use-Case: Keep Your Profile and Friends Across Networks</h2>
<p>Alice has gotten bored of her social networking sites, and wants to move to the new and increasingly popular augmented social reality gaming platform Fazer. However, she does not want to re-enter her old information and find her friends again. She authenticates herself using her browser-based ID and then accesses Fazer, and selects her "personal" identity as to not let her work colleagues know about her game-playing identity. Since Fazer is a "real-world" augmented reality social game, she does not create a completely fictional profile (although she could) but instead opts to use an existing profile. In the account creation process, she is not required to complete all the profile attributes, but has them auto-completed, and she even creates a few new (custom) fields in a profile, and this new updated  personal profile information is automatically synchronized between Twitbook and Fazer. She also explicitly agrees to share her geolocation with Fazer, which she has never done with Twitbook. Her various settings, such as avatars, presence, mood indicators, time-of-day and geolocation context are also automatically synchronized. Then using her set of social connections, her existing friends are automatically discovered on Fazer and she is given the option to add each of them or invite them if they are not on Fazer. A few months later she quickly gets tired of Fazer after having made some new friends in the process of playing various augmented reality games, and she decides to completely remove her profile from Fazer. However, as Fazer supports portability, Alice is able to download her own data to her profile manager at SocialAggregator and not lose touch with her friends, including downloading their numbers automatically to her mobile phone and backing her valuable data up locally.
</p>

<h2 id="ProfileStandards">5.3  Profile Standards</h2>
<p>A number of standards exist for profile and relationship information on the Web. One distinction among them is what data format (plaintext, XML, RDFa) the profile is in and whether or not they are easily extensible. Even more importantly, there are differences in how, given a digital identity, any particular application can then try to discover and access the profile data and other capabilities that the digital identity may implement. While some profiles mention this discovery and use techniques explicitly and others do not, these common or standardized discovery techniques will be mentioned in context with each profile data format.
</p>

<h2 id="XRD">5.3.1 XRD</h2>
<p>XRD (Extensible Resource Description), formerly YADIS and XRD-Simple (XRD-S), is an XML file format for discovering what capabilities a particular identity provider may have <a href="#ref-xrd">[XRD]</a>. For example, is this provider also an OpenID identity provider or does it provide Portable Contacts information? The XRD format provides this for arbitrary resources via the use of types and typed links describing URIs (URI templates) given in the XML format that can then be queried by a user-agent. The work around XRD has led to a number of innovations for locating XRD besides the W3C-style use of content negotiation, including the use of the IETF draft standards like ".host-meta"  <a href="#ref-hostmeta">[HOSTMETA]</a>and more generic ".well-known" subdirectories from any URI  <a href="#ref-wellknown">[WELLKNOWN]</a>. Furthermore, the XRD file (or other metadata format) can be discovered via possibly a combination of markup directly in the document (such as a Link element in HTML), HTTP Link Headers in response codes, and then generic directories like .host-meta. The priority can be determined by the IETF LRDD (Link-based Resource Descriptor Discovery) informational document  <a href="#ref-lrdd">[LRDD]</a>, which has now been subsumed by the host-meta  <a href="#ref-hostmeta">[HOSTMETA]</a>. The Web Linking standard specifies an IETF standard for Link Registries  <a href="#ref-weblinking">[WEBLINKING]</a>.

</p><p> Despite the fact that XRD was originally developed in 2004 by the OASIS XRI (Extensible Resource Identifier) Technical Committee as the resolution format for XRIs (an alternative to URIs for personal identifiers), it no longer mandates the use of XRIs, which are custom URI-like identifiers for people and organizations that have in the past not been used in W3C Recommendations due to technical concerns <a href="#ref-conc">[CONC]</a> and the use of at least previously patented technology <a href="#ref-pt">[PT]</a>. Also, Web developers want a JSON specification of XRD, tentatively called JRD (although there is no RDF serialization of XRD)<a href="#ref-jrd">[JRDF]</a>. The general discovery management also needs to be integrated with content negotiation, but Web Linking and related specifications provide a much needed clarification of how to retrieve metadata about resources on the Web.
</p>

<h2 id="VCard">5.3.2 VCard</h2>
<p>VCard is the oldest and most widespread IETF standard format for personal address-book data, which is the kind of information typically found on a business card, such as names, phone number, and address <a href="#ref-vcard3">[VCARD3]</a>. Therefore, this format serves in general as the common core of most data-formats, except for FOAF (leading to a the definition of vCard 3.0 in RDF <a href="#ref-vcardrdf">[VCARDRDF]</a>). However, vCard 3.0 in general lacked the ability to describe social relationships and was serialized in a ASCII text format, so the VCard 4.0 activity at IETF  has provided improved semantics for properties about people and organizations (such as the ability to express groups of users, e.g.  "Wine Club members") and direct relationships between users ("friendship") and mechanisms to extend these terms <a href="#ref-vcard4">[VCARD4]</a>. Syntactically, vCard can be expressed in its native format similar to VCard 3.0 and in a new XML format  similar to the PortableContacts XML format <a href="#ref-vcard4xml">[VCARD4XML]</a>. VCard import and export is supported by most mail programs like Thunderbird, Microsoft Exchange, and Apple Mail.

</p><p>Based on vCard 3.0, profiles can also be embedded in HTML pages using the hCard microformat <a href="#ref-hcard">[HCARD]</a>.  Another microformat often used for relationship data is XFN (XHTML Friends Network), which embeds its own idiosyncratic  social contact relationships directly into HTML links using the "rel" attribute, and provides a set of finite attributes to define which kind of relationships exist between individuals (friend, co-worker, met) <a href="#ref-xfn">[XFN]</a>. This kind of contact information based on hCard is currently deployed by sites such as Slideshare, dopplr, and Twitter to express social networks and can be converted to formats like RDF via GRDDL <a href="#ref-grddl">[GRDDL]</a>. Despite debates on alignment vCard 4.0 promises to be a stable core set of terms for the Social Web.
</p>

<h2 id="FOAF">5.3.3 FOAF</h2>
<p>The first project that used standards to describe decentralized social networks was the FOAF project (Friend-of-a-Friend)<a href="#ref-foaf">[FOAF]</a>. FOAF however only attempts to address descriptive challenges, rather than the entire problem space. FOAF provides an extensible and open-ended approach to modeling information about people, groups, organizations and associated entities, and is designed to be used alongside other descriptive vocabularies. Despite these innovations, FOAF itself does not provide for social networking functionality by itself. It assumes other tools and techniques will be used alongside it, and does not itself specify authentication, syndication or update mechanisms. Today the vast majority of data expressed in FOAF is exported from large "social network" sites. However when FOAF began, most social networking sites (except Livejournal) did not yet exist, and the conceptual model for FOAF was the personal homepage.
</p><p>FOAF profiles can be used to describe both attributes of a user as well as their social network. The discovery of FOAF information currently supports that information being simply accessed via RDFa or Linked Data over HTTP, and for private profile data, authentication using an identity provider before access.  Current applications natively export FOAF profiles of their users, including Hi5, StatusNet, Drupal, and Semantic Micro-blogging <a href="#ref-smob">[SMOB]</a>. Various exporters have been created by the community to enable FOAF export of sites like Twitter, Facebook, and Last.fm.

</p><p>FOAF is well-suited to enable a decentralized Social Web due to its use of URIs and web-scale linking.  Like other RDF vocabularies, FOAF can be easily extended in a decentralized manner, as done by the SIOC vocabulary regards user-profiles and user-generated content  <a href="#ref-sioc">[SIOC]</a> and the Online Presence Ontology does for presence  <a href="#ref-opo">[OPO]</a>. However, while FOAF was created to demonstrate the decentralized nature of distributed vocabularies, it's historic divergence from vCard and PortableContacts makes it difficult to use with current Social Web applications <a href="#ref-port">[PORT]</a>, along with the general perceived complexity of RDF and lack of adequate RDF tooling. The FOAF project does not propose FOAF as the only format that should be adopted for decentralized social networking; rather it is offered as a representational model that can find middle-ground between the semantics from diverse initiatives ranging from digital libraries and cultural heritage to those used in the Social Web. Recent changes to the FOAF specification have brought parts of it into closer alignment with the PortableContacts and VCard 4.0, and further such convergence is needed if FOAF is to be seen as a modern component of the technology landscape.</p>

<h2 id="PortableContacts">5.3.4 PortableContacts</h2>
<p>An increasingly popular profile standard is PortableContacts, which is derived from vCard and is serialized as XML and JSON <a href="#ref-port">[PORT]</a>. It contains a vast amount of profile attributes, such as the <em>relationshipStatus</em> property, that map easily to common profiles on the Web like the Facebook Profile. More than a profile standard, the PortableContacts profile scheme is  designed to give users a secure way to permit applications to access their contacts, depending on XRD for discovery of PortableContact end-points and OAuth for delegated authorization. It provides a common access pattern and contact scheme as well as authentication and authorization requirements for access to private contact information.  It has support from Google, Hi5, Plaxo and others, and is a subset of the contact schema used by OpenSocial, so every valid OpenSocial provider is also a PortableContacts profile provider.
</p><p>Originally as VCard 3.0 did not have an XML format, PortableContacts was the first realistic contact schema with an XML format. It is also a proper super-set of vCard 3.0  and is very close to mapping on to vCard 4.0, as co-ordination work in the DAP group shows <a href="#ref-cfc">[CFC]</a>.  Ideally, PortableContacts and vCard 4.0 could converge or gain an easy-to-understand super-set or subset relationship with each other to reduce the friction between various profile data formats.
</p>

<h2 id="OpenSocial">5.3.5 OpenSocial</h2>
<p>OpenSocial is a collection of Javascript APIs, controlled by the OpenSocial Foundation, that allow Google Gadgets (a proprietary portable Javascript application) to access profile data, as well as other necessary tasks such as persistence and data exchange <a href="#ref-opensocial">[OPENSOCIAL]</a>. It allows developers to easily embed social data into their Gadgets. The profile data it uses is a superset of the PortableContacts and vCard 3.0 data formats. It does not require access to Google servers to run, but instead can run-off the open-source Shindig  implementation and so positions itself as an "open" alternative to the Facebook Platform, and has been supported by a number of vendors such as Google, MySpace, Yahoo!, IBM, and Ning.
</p><p>There is a rather unfortunate mismatch between OpenSocial Gadgets and W3C Widgets from the Web Applications WG <a href="#ref-widgets">[WIDGETS]</a>, given that both are primarily based on top of HTML and Javascript. Currently there is work being undertaken by Apache Wookie (incubating) to provide interoperability between W3C Widgets and OpenSocial Gadgets, although ideally in the future the W3C Widgets would either be adopted or work more closely with major vendors in the next iteration <a href="#ref-wookie">[WOOKIE]</a>. Also, W3C Working Groups like the DAP (Device Access Policy) Working Group are also producing APIs that involve contact information and so should ideally maintain some baseline compatibility with OpenSocial and PortableContacts.
</p>

<h2 id="SocialMedia">6. Social Media</h2>
<p>The  Social Web is not only the connections between people, but the connections between people and arbitrary resources, including messages like  blog posts, audio, photos, videos, and other resources. So <strong>social media</strong> is any resource that is used in a social relationship with a user. A user should also be capable of having connections to "non-Web" resources like locations and items. For example, a user may "like" a particular musical style or "review" a particular album. The Social Web should offer a way to avoid having identical user content stored in different social networking sites and platforms. Users should be able to create, link to, and annotate social media with multiple social applications to aggregate their social media together in designated social platforms, as well as being given the option to save the data to local storage (e.g. in their browser).  This is an extension of what is called by Berners-Lee "Linked Data" where links (connections) should be possible between arbitrary resources (anything identified with a URI), not just hypertext web-pages <a href="#ref-linked">[LINKED]</a>. One of the most important features that will support the generation of media on the Social Web is provenance. Provenance information should support the tracking of social media, identifying when and how it came to be posted on a given social networking site or application on the Web. Any such provenance information should be capable of answering questions such as "When was it originally posted?", "Where does it originate from?", and "Who posted it?"
</p>

<h2 id="Fined">6.1  Problem: Fined for Consuming Social Media</h2>
<p>Increasingly users find themselves consuming social media, but not knowing if it is trustworthy or whether or not they can consume such social media without a monetary fine, i.e. whether their usage breaks the content's copyright! Not knowing this information can lead to disaster. People who are often downloading and re-using social media can now be fined for huge amounts of money, but many of them are unaware that the data was under copyright in the first place. So many users would like to have mechanisms to automatically determine whether a Web document or resource can be used, based on the original source of the content, the licensing information associated with the resource, and any usage restrictions on that content. Without any provenance (the information about who created the data and how has it changed over time), users can not trust social media. This applies to social applications themselves, whose reputation can be dependent on verifying sources, such as verifying the person or organization who created a news story in order to credit the original source in its site, which most real-world social applications would like to do automatically for thousands of sites a day. With the increase in fines related to social media consumption, users will want to be exceptionally well-informed about the social media they consume.
</p>

<h2 id="Safely">6.2  Use-Case:  Safely Drag-and-Drop Social Media Across Multiple Platforms</h2>
<p>Alice enjoys taking photographs about penguins and would like to share them as widely as possible with her friends. Using an image processor on her laptop, she fine-tunes her photos and publishes these to her personal blog using a graphical drag-and-drop interface that lets her just drop the photo into her blog and automatically update social networking sites she uses. Since she controls not only her profile but her social media, she can easily attach a Creative Commons with attribution non-Commercial license and ask for a small fee of 10 cents for commercial use. As Alice explores social media, she even finds herself paying for some social media she finds useful, and she uses a simple micropayment policy that allows her to consume up to five dollars in social media a week without having to worry about fines. She finds herself automatically paying tiny amounts of money for some social media to help support her friends and creators she likes and she finds herself collecting micropayments for her penguin photos, allowing her to turn her hobbies into a way to help sustain herself. Also, not only can she drag-and-drop social media safely, she can remove social media. When she discovers she has accidentally sent a message on Twitbook that spread a false rumor about an oil spill threatening penguins, she retracts it immediately so she does not cause a panic. Not only is the message removed from Twitbook, but it's removed from other sites as that aggregated it as well!
</p>

<h2 id="SocialMediaStandards">6.3 Social Media Standards</h2>

<h2 id="Tagging">6.3.1 Tagging</h2>

<p>Tagging is a powerful and massively deployed means of categorizing content on the Web, as deployed for bookmarks (Delicious), photos (Flickr), videos (YouTube), and blog posts. Unlike more complex categorization methods, the simplicity and ease of entering natural language keywords appeals to users. However, there are problems with interoperability. The two general approaches have been a common API for tagging (via the currently inactive TagCommons effort  <a href="#ref-tagcommons">[TAGCOMMONS]</a>) and an approach using some sort of common data-model based on RDF. There is also the rel:tag microformat used to link an item to its tag(s) <a href="#ref-reltag">[RELTAG]</a>, which is deployed on sites like Flickr.
</p><p> There has been a long history of tagging vocabularies in RDF, with the most recent effort in the area being the CommonTag vocabulary <a href="#ref-ctag">[CTAG]</a> that solves ambiguity ('apple') and heterogeneity ('socialweb', 'social_web', 'socweb') by means of an additional link to a resource in order to represent the tag's meaning, such as URIs from Linked Data to represent that meaning. Most of the data-models use a tripartite model of tagging as the relationship between a user, a resource and a tag. Going beyond this, the NiceTag ontology  explicitly puts each tagging act inside a named graph that receives its own URI to make it easier to add context such as where it was performed and license information <a href="#ref-nict">[NICT]</a>. All of these vocabularies are easily extensible and CommonTag is supported by Yahoo!.
</p>

<h2 id="Microformats">6.3.2 Microformats</h2>
<p>Microformats are a simple way to embed semantics in ordinary HTML by re-using established HTML attributes such as <em>rel</em>, <em>class</em>, and <em>rev</em> with a set of string values given definition by a number of vocabularies <a href="#ref-microformat">[MICROFORMAT]</a>. These vocabularies are meant to standardize common information on the Social Web. For example, social sites often allow users to rate online content using some simple integer (like "1-5 stars"). The hReview microformat allow to represent these ratings in a structured way inside ordinary HTML without the use of RDF or XML <a href="#ref-hrev">[HREV]</a>. Overall, the approach to using microformats has been massively successful in deployment, with over two billion web-pages marked up in microformats, about 5 percent of web-sites <a href="#ref-microstats">[MICROSTATS]</a>.
</p><p>While easy-to-use, microformats specializes in a finite number of vocabularies, with these being done via a centralized and informal process based around <em>microformats.org</em><a href="#ref-microformat">[MICROFORMAT]</a>. Alternative decentralized approaches like RDFa aim at the "long-tail" of vocabularies, which allow arbitrary RDF data to be put inside HTML <a href="#ref-rdfa">[RDFA]</a>. The Microdata work of HTML5 also lets arbitrary attribute-value pairs to be put inside HTML <a href="#ref-microformat">[MICRODATA]</a>. However, alternative approaches to microformats have not reached wide-scale deployment, although RDFa is now used in Drupal and all three kinds of semantic markup are consumed by Google Rich Snippets. 94 percent of Google Rich Snippets data indexed by Google Rich Snippets is based on microformats rather than RDFa or microdata  <a href="#ref-microstats">[MICROSTATS]</a>. It should be noted that this statistic could be misleading, as it compares microformats against the use of Google's own vocabulary in RDFa and microformats. i.e. vocabularies such as FOAF and SIOC are not included.</p>

<h2 id="OpenGraphProtocol">6.3.3 Open Graph Protocol</h2>
<p>Facebook's Open Graph Protocol is a metadata vocabulary for describing documents and (indirectly) their topics, not that dissimilar from Dublin Core. It is typically serialized in RDFa in &lt;meta&gt; elements in HTML pages <a href="#ref-ogp">[OGP]</a>. An application of the the Open Graph Protocol is the Javascript enabled Facebook "Like" button. This allows developers to add a "Like" button to an item described in a webpage by adding only a small amount of simplified RDFa to the header of a web-site. When users click the "Like" button, the fact that the user "likes" this item is added to the activity stream and Facebook profile of the user. The Facebook Like button has been enormously popular and is deployed across a number of high traffic websites such as IMDB, Rotten Tomatoes, Microsoft, and has become nearly ubiquitous in large web-sites; so Facebook's Open Graph Protocol is the largest metadata deployment of RDFa on the Web.

</p><p>Although it is licensed under a OWF license, the Facebook Like button is itself hosted on <em>facebook.com</em>, and as a result Facebook have the ability to read any Facebook cookies a user has in their browser, regardless of whether or not the Facebook Like button is actually pressed <a href="#ref-likeb">[LIKEB]</a>. However, attempts to create an OpenLike alternative to the "Like" button have yet to see much deployment <a href="#ref-olike">[OLIKE]</a>.
</p>

<h2 id="Payswarm">6.3.4 Payswarm</h2>
<p>The PaySwarm specification supports Web-based payments ranging from hundred-thousandths of a cent to pennies to thousands of dollars, and can be deployed for paying micropayments for social media <a href="#ref-pays">[PAYS]</a>. The technology is designed to be integrated directly into websites and builds on the OAuth protocol. A transaction has two participants - a buyer and a website. With PaySwarm, the buyer assigns a Payment Token to a website using the OAuth protocol. The Payment Token is much like a debit card with a pre-set spending limit. Once the buyer issues the Payment Token to the website, the website can use the Payment Token to charge the buyer for services rendered. The website is prevented from abuse of the Payment Token via spending limits, usage limits and an expiration date set by the buyer.While the W3C had a micropayment activity in the past <a href="#ref-micropay">[MICROPAY]</a>, it was never widely deployed; but given that this activity was about ten years old, this attempt may have been simply too early. With the wide-scale nature of user-contributed social media and the desire by many to make a living off such media, making wide-spread digital content sales easily possible could allow - if the timing is right - a more decentralized approach to Web payments that would empower ordinary users to buy and sell over the Web with the mediators of their choosing. However, the security aspects of this proposal are incredibly dangerous, and require further review.</p>

<h2 id="OExchange">6.3.5 OExchange</h2>

<p>OExchange is a OWF-licensed specification for users sharing rich content over the Web using URIs between social sites  <a href="#ref-oex">[OEX]</a>. While this problem may seem trivial, one of the major issues facing the Social Web is the use of URI-shorteners, which then can redirect a user unwittingly towards a malicious site. Also, increasingly social media is shared by embedded "buttons" rather than URI linking.  OExchange addresses this by defining an OExchange protocol that supports the offering of URIs to other services in a standardized way (with the possibility of identity authentication) and then allows sites to advertise using XRD their ability to receive data. This proposal is backed by Google but has not yet seen wide-scale deployment.</p>

<h2 id="Semantic">6.3.6 The Semantic Web</h2>
<p>The Semantic Web is a set of languages for describing machine-readable data in an extensible manner, where every piece of information is given a URI and can be linked to other pieces of information <a href="#ref-sw">[SW]</a>. The basic language of the Semantic Web is RDF (Resource Description Format), a language that lets data be connected using links, as in the hypertext Web allows web-pages to be connected using links <a href="#ref-rdf">[RDF]</a>. As RDF can link any kind of data together and does not constrain the descriptions, it would be an ideal language for describing interactions on the Social Web. However, while it has had some use for profile data via the deployment of FOAF, the use of the Semantic Web to describe social media in general has not taken off. This is likely because of three factors. First, while groups like microformats centralize their formats, due to the decentralized nature of the Semantic Web, it is difficult if not impossible to discover vocabularies relevant for the Social Web <a href="#ref-vochost">[VOCHOST]</a>. Second, the RDF specification itself is rather difficult for developers to understand, and at times there are complaints of immature tooling. Lastly,  RDF does not track provenance of data like Atom. RDF could be extended to support the more nuanced provenance needed for the Social Web. This topic is being explored by the W3C Provenance Incubator Group, who have been working on use-cases for the Social Web <a href="#ref-prov">[PROV]</a>, and this technology would allow one to, for example, discover and verify the sources of tweets or the aggregation of comments on blogs.
</p>

<h2 id="SIOC">6.3.7 SIOC</h2>

<p>SIOC (Semantically-Interlinked Online Communities) aims at developing a standard vocabulary for representing user-generated content on the Web, using Semantic Web technologies <a href="#ref-sioc">[SIOC]</a>. The SIOC ontology (a W3C member submission, still evolving) consists in a core vocabulary (with classes such as <em>sioc:UserAccount</em> and <em>sioc:Item</em>) and several modules that provide classes for finer-grained content description. SIOC has strong ties with FOAF, so that it can be used to represent user-generated content of a person defined by the FOAF data format, and so that the content can be distributed over the Web, following the decentralized Social Web vision.  SIOC is used in Drupal 7 as one of its core vocabularies.
</p>

<h2 id="Privacy">7. Privacy </h2>
<p>Instead of believing that privacy has "disappeared" or that web-sites invariably will violate privacy, we believe users should be aware of and ideally in control of whether information about them on the Social Web is public or not. So, we also take a <strong>policy-centric</strong> view towards privacy, where policies capture the permissions (access control), obligations (such as terms-of-service and licensing) and other data-handling settings that allow a user to control their interactions with social media and other users. Privacy and a decentralized Social Web can both enhance privacy and data liquidity. In particular, policies apply privacy settings to the profile and social media frameworks to consistently manage the user expectations of privacy and other obligations, and this allows businesses and others on the Social Web to share information about their users without fear of violating user privacy or any regulations. A social platform that manages privacy on behalf of a user over multiple social applications and other platforms is a <strong>privacy provider</strong> and allows social applications to be <strong>privacy-aware</strong> by taking into account the privacy settings of a user.  A privacy provider allows the user to select a set of policies to capture various social obligations, which can then be expressed in a machine-readable manner via policy languages. These obligations may come from a legal (only allow Creative Commons work to be used), best practice (do not let children under a specified age befriend adults outside of their family), corporate or social  (don't mix "work" and "friend" profiles) perspective. Currently, existing individual policy languages have barely been put to use in understanding privacy and terms-of-service on social networking sites. However, a standardized policy language for privacy should provide an accountable, enforceable, flexible and trusted experience of the Social Web for users, automatically detecting policy conflicts and allowing  some modicum of accountability to be instilled in the Social Web in a user-centric manner. Most attempts to provide enforcement on the Web (for example, traditional digital rights management for multimedia content) have ended in failure, and are not well accepted by the Web community.
</p>

<h2 id="Violation">7.1  Problem: Violation of Privacy</h2>
<p>People are increasingly finding their social media spread across multiple social networking sites and accessed by all sorts of people, many of whom they did not originally intend. As social media is central to everything from job recruiting to personal relationships, the ability to grant and restrict access to one's personal data is becoming a critical component of many social applications. New technologies, the ubiquity of the Web, and the amount of time people spend interacting with social media are both advancing our freedoms and enabling novel invasions of privacy. Exactly how far-reaching services and technologies are affecting privacy was pushed into the mainstream in spring 2010 by Facebook's changes to its privacy settings, leading to news articles that have highlighted how convoluted their privacy policy has become <a href="#ref-fbpriv">[FBPRIV]</a>. Tools such as a "Terms of Service Tracker" [FBTOS] have led to visualizations of how Facebook is leading to more and more private data being shared <a href="#ref-fbviz">[FBVIZ]</a>. Useful Web-based add-ons like Facebook's Open Graph Protocol's "like" button <a href="#ref-ogp">[OGP]</a> have also led to possible privacy violations, such as the browsing habits of people on medical web-sites being shared with Facebook and Google, amongst others <a href="#ref-fbnhs">[FBNHS]</a>.</p>

<h2 id="Your">7.2  Use-Case: Your Own Terms of Service</h2>

<p>When Alice uploaded her penguin photos, she only wanted them exposed to certain groups of her friends, in particular, those who are also photographers and penguin enthusiasts. Luckily, due to the profile management which she does both locally on her browser and via SocialAggregator, she is able to transform her friends in groups of photographers and penguin enthusiasts via a mixture of manual work and automatic suggestion via their profiles, and she shares the photos with these users. However, since she is able to phrase the licensing (Creative Commons with attribution) with SocialAggregator, which serves as her privacy platform, she discovers that Twitbook has extremely draconian terms of service that mean that her photo, if uploaded to Twitbook, then becomes property of Twitbook. Thanks to the fact that Twitbook's policy is also phrased using a common policy language, her privacy provider discovers the policy conflict and warns her not to upload her pictures to Twitbook. Furthermore, after uploading them to her personal blog and propagating them via  Bizlink (which has a more sensible terms of service Alice agrees with), SocialAggregator informs her that a large private company CSO is using her photos without her permission in an advertising campaign, which can be detected via its accountability mechanism that checks on usages of her data and her privacy policy. Alice is informed, and she demands her photos be removed. As the company refuses, she orders an automatic take-down of the penguin photo and blocks any further social communication with the CSO company. Later in the day, a friend uploads a photo of her to Twitbook at a fancy-dress party that she wants only her friends to know about, and SocialAggregator warns her again, and automatically sends a message to her friend and Twitbook to restrict views of that photo from her business colleagues.
</p>

<h2 id="PrivacyStandards">7.3 Privacy Standards</h2>

<p>
In order for any decentralized social networking service to be a success, the service's privacy policy with respect to the information it holds regarding its users must appeal to the privacy aware masses. Work by researchers at the University of Cambridge has studied various terms-of-service agreements and has put forward best-practices like displaying "privacy practices in a non-textual format to help users make more informed privacy choices" and "requiring sites to provide clear, Web-integrated interfaces for users to see exactly what personal data of theirs is held, and exactly which parties have access to it"  <a href="#ref-jungle">[JUNGLE]</a>.
</p><p>The SWXG has looked at a number of technologies and initiatives that may provide insight into methods of developing machine-readable Web-based policy languages and the visual ways to display their contents to users. Such machine-readable policies would help empower users to set policies on their data, stating how they intend to have their data used and shared on the Social Web.
</p>

<h2 id="P3P">7.3.1 P3P</h2>
<p>Expressing privacy via machine-readable languages began with the W3C P3P (Platform for Privacy Preferences) Recommendation, which allows website operators to express their data collection, use, sharing, and retention practices in a machine-readable format <a href="#ref-p3p">[P3P]</a>. While at first glance this may seem well-suited to phrasing terms of service, P3P has not been widely adopted. While Internet Explorer has exposed a P3P-enabled feature since version 6, it only allows cookie-blocking. The Firefox/Mozilla browser discontinued its built-in support for P3P; those wishing to use P3P can use plug-ins. The primary criticism that it suffers from is that it is too complex and offers no legal or technical bindings for privacy agreements, and this has led P3P to fail to have significant deployment.

</p>


<h2 id="POWDER">7.3.2 POWDER</h2>

<p>The W3C POWDER (Protocol for Web Description Resources) language provides a mechanism for describing groups of resources by essentially providing a "glob" operator over URIs and linking these groups of URIs to a group of common XML statements regarding topics like authentication and RDF statements <a href="#ref-powder">[POWDER]</a>. While more generic than P3P, it was aimed at the same use-cases such as privacy descriptions for child protection. While interesting for allowing RDF to describe groups of URIs rather than single URIs, it is seen as complex and has failed to gain deployment for the same reasons as P3P.
</p>

<h2 id="AIR">7.3.3 AIR</h2>
<p>Despite the lack of deployment of P3P, research still continues on languages to express policies for privacy and data-handling. AIR (AMORD in RDF) is a policy language that is represented in Turtle and features a basic proof-level, as well as special-purpose classes and properties, that can be used to define policies in a machine-readable manner <a href="#ref-air">[AIR]</a>. However, AIR is limited by its ability to handle only RDF data and features no defined mapping to the W3C standard rule language RIF <a href="#ref-rif">[RIF]</a>. Although AIR is a potentially-useful research project, it has no deployment outside a research context.
</p>

<h2 id="XACML">7.3.4 XACML</h2>
 <p>XACML (eXtensible Access Control Markup Language) is an OASIS specification for a declarative policy language for access control <a href="#ref-xacml">[XACML]</a>.  XACML allows for rules, especifically access control rules, to be expressed in a machine-readable manner. Attempts have been made to extend the XACML access control language to support privacy on the Social Web use cases  by the PrimeLife EU Project <a href="#ref-primelife">[PRIMELIFE]</a>. However, XACML only operates over XML-based data and is viewed as too heavy-weight, in addition to still succumbing to the enforcement and complexity problems that caused P3P to not take-off. Unlike other standardized rule languages, XACML has some limited use in industry, including an Apache module, as was primarily backed by SUN Microsystems (now Oracle).
</p>

<h2 id="Rule">7.3.5 Rule Interchange Format </h2>

<p>The W3C RIF (Rule Interchange Format) Recommendation is a format to exchange rules between rule engines that operates over both XML and RDF data <a href="#ref-rif">[RIF]</a>. Due to its extension mechanisms, it is an ideal language to investigate machine-readable first-order logic rules, and existing languages like AIR should attempt to map to it. However, it suffers from the same problems as P3P of being overly-complex and not having any legal binding, and despite being a W3C Recommendation with support from major vendors like IBM and Oracle, has little deployment as of yet.
</p>


<h2 id="Device">7.3.6 Device APIs and Policy Working Group</h2>

<p>The Device APIs and Policy Working Group's (DAP) primary mission is to create client-side APIs that enable the development of web applications  that interact with one's devices and their applications, such as calendars, contacts, cameras, and the like <a href="#ref-dap">[DAP]</a>. The DAP Working Group has also been chartered to produce a framework for the expression of privacy policies that govern access to these APIs. So far, the primary output has been the Privacy Ruleset proposal <a href="#ref-ruleset">[RULESET]</a>.

</p><p>Privacy rulesets describes "bundles" of privacy preferences in a way that should be understandable to the typical user and developer  <a href="#ref-ruleset">[RULESET]</a>. Privacy rulesets allows users to describe their privacy preferences over three categories: Sharing, Secondary Use, and Retention. These have a number of different possible values. An example of the least permissive privacy preference bundle is called <em>sharing=internal</em>. This least permissive ruleset bundle states that the user wants her data shared only internally by the data collector and organizations that help the data collector deliver the service, only used for contextual purposes (which includes contextual advertising), and not retained beyond the baseline period. An example of the most permissive ruleset is one that allows sharing to everyone (including <em>unrelated-companies</em>), secondary use for marketing or profiling, as well as contextual use, and indefinite retention. For simplicity, the rulesets only apply to identified data  - information that can reasonably be tied to an individual. While considerably simpler than P3P, privacy rulesets could be based on first-order logic, allowing for inference over data-sets to be performed. Furthermore, as with P3P there is still no model to legally bind the enforcement of these policies.
</p>

<h2 id="Mozilla">7.3.7 Mozilla Privacy Icons</h2>
	    <p>Mozilla Privacy Icons takes a simple icon-based approach inspired by Creative Commons <a href="#ref-privicon">[PRIVICON]</a>. Instead of specifying every possible type of privacy and data-handling scenario, they specify only a few common privacy scenarios that users can encounter. The icons are designed to be easy to use and understand by ordinary end-users. As there is a no incentive for sites that violate user privacy to label themselves as such, it would be up to the browser to automatically label such sites. Also, users do not ordinarily notice an icon by its absence but only by its presence, so the browser would automatically use the icon to notify users they have entered a site where their privacy could be violated.
</p><p>This approach manages to defeat the complexity barrier of rule-based approaches, although it does not address every possible scenario. While it does not address legally-binding enforcement, by alerting end-users to possible privacy violations, informed user choice about privacy risks can serve as a de-facto way to get sites to respect privacy. However, currently Mozilla Privacy Icons are available as a plug-in to Firefox, so the pool of users that are aware of this work and deploy it is still quite limited.
</p>

<h2 id="ODRL">7.3.8 ODRL</h2>
<p>The Open Digital Rights Language (ODRL) Initiative is an international effort aimed at developing and promoting an open standard for policy expressions in a machine readable format, currently in its  second version of the ODRL language, namely ODRL 2.0 <a href="#ref-odrl">[ODRL]</a>. The motivation for this revision of the ODRL language was to try and abstract away from expressing rights and towards a general policy language. ODRL 2.0 is currently expressed in XML with an RDF version in progress. ODRL is meant to express access control (what content is available after authentication), permission control (how an agent should re-use such data), and privacy control (obligations of personal data).  In order to illustrate that ODRL 2.0 can be used as a general policy language the initiative has been looking at modeling some use cases based around social networking <a href="#ref-odrlu">[ODRLU]</a>. ODRL are working with OneSocialWeb decentralized social networking project  to help develop a solution for policy expression on the Social Web <a href="#ref-osw">[OSW]</a>. This collaboration with OneSocialWeb aims to output XMPP bindings for ODRL <a href="#ref-xmpp">[XMPP]</a>.

</p>

<h2 id="Activity">8. Activity</h2>
         <p>The most distinguishing feature of the Social Web over the previous hypertext Web is the increasing focus on sharing information in real-time. As opposed to pulling information on an as-needed basis, users desire to have information that may be of interest pushed to them immediately. The social interactions of user and resources, including other users, are the <em>activities</em> of the user.  Each activity, such as changing status, making new connections, creating a blog post, and attending events can be considered an <em>update</em> in an activity. The total of all activities of a user is the <em>stream</em> of the user.  Social media, like a conventional blog post, can have its own stream of activities such as comments, microblogs, tags, and ratings. In a privacy-aware manner the various streams can be shared with social connections, and so constantly bring together shared items of interest and status updates to a user. Social application can "assemble" context in real-time by combining information from the profile, connections, and policies the user has stipulated in order to bring the relevant information to the user. Furthermore, the content of these streams can have access control policies set on them, and they can also be signed by the authoring user allowing for the information to be verified upon receipt. Through this shift we can see the Web is evolving from a graph of linked hypertext web-pages to a dynamic universal stream of social information that every user contributes to and actively sifts through using their own trusted connections.
</p>

<h2 id="Cannot">8.1 Problem: Can not Integrate Conversations</h2>
         <p>Currently, users are being forced to not only "silo" their profile information and social media, but also all the time-sensitive updating of this information.  As more and more updates - ranging from location changes to blog comments to "liking" social media - are circulated across multiple social networking sites, information is being fragmented over the Web. For example, there is no standard way to update and integrate back distributed comments back to their original source. This can lead to dangerous privacy violations, as some conversations may want to switch to more private modes, like e-mail and even public key encryption, and there is no easy way to signal to other users that the conversation should "move" to a more or less private medium or what groups or people should be allowed to see a message. To make things even worse, users want updates about their friends and social media increasingly in real-time, which is difficult using the "pull" architecture of the Web. This leads to possibly crucial information not reaching its intended audience in time.
</p>

<h2 id="Realtime">8.2 Use-Case: Real-time Collaboration</h2>

<p>As Alice starts using more social applications, she increasingly finds her behavior on the Web moving from searching for new relevant social media to being in near-real time updated about the activities of her friends and the social media they have created or discovered. These streams of updates are not just new information, but chances to help collaborate with others.  She also finds herself using e-mail less and less, as she can now use her social Web-enabled platform to directly communicate in both asynchronous messaging and  near real-time video and audio-enhanced chat with her friends, and authoring new social media collectively with them. One of the major drawbacks of e-mail was that it is mostly insecure (i.e. delivered in plaintext) and unauthenticated (and so easy to send spam with faked e-mail addresses). Thanks to the identity technology of the Social Web, she is now able to verify whether or not she is communicating with another user or not, and thanks to the identity and profile management in her browser, she even by default uses public key encryption to encrypt her messages and social media she sends to her friends if needed. So she can be updated of the activities of all her friends constantly and share her work with them, all while keeping her communications and identity secure in a way that was unimaginable to her earlier.</p>

<h2 id="ActivityStandards">8.3 Activity Standards</h2>
<p>We will note the ability of social network messaging (ranging from blog comments to chat) to be implemented, both asynchronous and near real-time, to be co-ordinated via Atom, Pubsubhubbub, and XMPP, giving special attention to activity stream updates <a href="#ref-push">[PUSH]</a>.
</p><p>In contrast to fractured landscape of portable profiles, the standards used to describe activities are at this point new and rapidly being deployed. The core architecture presumes an ability to send content (status updates, messages, and other content) in as near to real-time as possible. This is currently accomplished through two distinct architectures. The first based on XMPP, where the XMPP messaging framework natively provides an XML "envelope" for data to be sent in real-time with updates (as demonstrated by Vodafone's OneSocialWeb). The second architecture is based on HTTP, but overriding its traditional "pull" architecture with a "push" architecture based on Pubsubhubbub (which could sensibly be abbreviated as PUSH). This architecture allows Atom clients to sign up to a server that they poll to receive notifications of content changing. While the underlying architecture may differ, the core functionality remains the same, the creation and updating of activity streams.
</p>


<h2 id="XMPP">8.3.1 XMPP</h2>
<p>XMPP (Extensible Messaging and Presence Protocol) is an IETF RFC for the near real-time transfer of XML data  <a href="#ref-xmpp">[XMPP]</a>. Originally named "Jabber" and developed for use in instant messaging, in its simplest form XMPP can be regarded as a protocol for passing XML fragments between machines, but features its own methodology for identity authentication and extensibility. Its many of its extensions being hosted by the XMPP Foundation  <a href="#ref-xmppf">[XMPPF]</a>. The  XMPP technology stack is mature and widely deployed by Google GTalk and open-source instant messaging projects like Pidgin.
</p><p>One of the main concerns of the Social Web is to provide status updates and messages in near-real time, so XMPP is a natural fit for federated social networks. One advantage that XMPP provides is for devices to connect to the federated social network without the need to bypass standard firewall setups. However, it does so insofar as XMPP is not directly built on top of HTTP and so provides a whole parallel level of complexity. A number of federated Social Web solutions like OneSocialWeb have been built on XMPP  <a href="#ref-osw">[OSW]</a>.</p>

<h2 id="Atom">8.3.2 Atom and Pubsubhubbub</h2>
       <p>The main problem with building a specification on top of HTTP is the "pull" architecture of the Web. This "pull" architecture is not suited to status updates, messaging, and other kinds of activity streams in general. However, the draft Pubsubhubbub (PUSH) specification provides a "push" architecture for the HTTP-based Web that can provide activity stream updates in near real-time, built on top of a simple distributed publish-and-subscribe architecture  <a href="#ref-push">[PUSH]</a>. In particular, PUSH allows publishers to publish data via the XML-based  IETF RFC Atom as usual, but contain a pointer to a PUSH-aware hub  <a href="#ref-atom">[ATOM]</a>. When subscribers subscribe to an Atom feed, they can discover the hub and subscribe to the feed via the hub as well. Then when the feed has been updated, subscribers are updated in near real-time by running a PUSH-aware server that the hub will update.
</p><p>Overall, this approach has the advantage of building on top of widely deployed and mature software that is part of the HTTP web, the already largely deployed Atom infrastructure. Also, PUSH allows the full content to be delivered (unlike earlier alternatives). While XMPP Pubsub gives updates in closer to real time via persistent connections (i.e. like chat)  <a href="#ref-xpubsub">[XPUBSUB]</a>, for scenarios where the updates are not needed to be so close to real-time and persistent connections may be more unreasonable, PUSH and Atom are suitable. As such, this approach has been taken up by a number of federated Social Web codebases, in particular StatusNet  <a href="#ref-statusnet">[STATUSNET]</a>.
</p>

<h2 id="ActivityStreams">8.3.3 ActivityStreams</h2>
	  <p>ActivityStreams is an Atom serialization for activity streams such as status updates in popular social networking sites <a href="#ref-activity">[ACTIVITY]</a>. While Atom is easy to work with, it doesn't capture the semantics of the original activity in a cross-platform way. Social applications dependent on cross-site Atom aggregation become increasingly costly to support. Each new social networking site, as the semantics of each new site has to be added manually (Facebook lets users "like" items, Twitter sends "tweets" to friends), would require a change to the ActivityStreams specification, which in turn would result in developer resource across the board. ActivityStreams standardizes the way of embedding status update semantics by dividing the activity into an action that was performed (verb) by an actor on another person, place, or thing (the object). An additional target (like a photo album) could be involved. Each activity is by virtue of being in a stream given an explicit date in time, so the stream itself is a feed of activities for a person or social media object.
</p><p>ActivityStreams features an experimental API  <a href="#ref-actapi">[ACTAPI]</a> and JSON serialization  <a href="#ref-actjson">[ACTJSON]</a>, and it does not currently have an RDF serialization. Although ActivityStreams has a "subject-verb-object" in a similar fashion to RDF, it uses Atom rather than RDF because the Atom tool-set is more mature and developers are more aware of Atom than RDF. Currently ActivityStreams maintains a schema of activities  <a href="http://activitystrea.ms/head/activity-api.html">[ACTSCHEMA]</a>. These activities could become open and exentensible if any URI were used instead of a string.   ActivityStreams has widespread deployment, including Facebook, MySpace, Google Buzz, Opera, and the BBC.</p>

<h2 id="Salmon">8.3.4 Salmon Protocol</h2>
	   <p>As content starts moving around outside of its original social networking site: How would comments, ratings, and annotations that happen on another social networking site besides the original somehow be sent back to the original poster? TheSalmon Protocol addresses this problem of "unifying the conversations" <a href="#ref-salmon">[SALMON]</a>. It assumes there will be spam, but uses digital signatures to assure content comes from a legitimate identity, so that any content whose creator's identity is not authenticated simply disappears. Salmon Protocol works by adding a new link relation to Atom-serialized content that identifies the original Salmon-enabled content provider. After that content has be annotated "downstream", a Salmon-enabled social platform could then send the annotations back to the original content provider back "upstream." The annotations are signed via the Magic Signatures specification and OAuth can provide additional verification of the identity of the signer <a href="#ref-magic">[MAGIC]</a>. Then, the "upstream" content provider can re-aggregate the content's "conversation."
</p><p>While Salmon, or something similar in nature, is definitely needed by a federated Social Web, currently Salmon works only on public annotations and content, and so should be expanded to deal with various levels of privacy. Salmon completely forbids anonymous and untraceable messages. While useful for preventing abuse, this approach may also prevent legitimate use of content by, for example, activists living under oppressive governments or others with a legitimate desire to protect their privacy. Therefore, one interesting extension could be some kind of "spammer" identification that propagates identified spammers but allows anonymous users to register at authorized anonymous identity providers or "prove" themselves. There are also debates  <a href="#ref-jclark">[JCLARK]</a> around the use of Magic Signatures' encoding rather than the use of the RSA Public Key ASN.1 structure specified by  and used by OpenSSL <a href="#ref-rsa">[RSA]</a>. The secure retrieval of XRD requires SSL or can be performed by implementing the W3C XML Digital Signatures  Recommendation <a href="#ref-xmlds">[XMLDS]</a>, but in a decentralized environment this interaction model of trusted roots might not be all that is necessary.</p>

<h2 id="OStatus">8.3.5 OStatus</h2>

<p>The OStatus specification is a a "meta-specification" for sending status updates to people in a federated Social Web <a href="#ref-ostatus">[OSTATUS]</a>. OStatus weaves together a number of previously mentioned specifications (PubSubHubbub, ActivityStreams, Salmon, Portable Contacts, and Webfinger) in a straightforward way. It does this by adding two "link" extensions to ActivityStreams, one that stores a URI for a user when a user is mentioned or directed at an activity, and the other that tracks the URI of a distributed "conversation" described in Salmon. Given a URI for a user, the XRD and Portable Contacts methodologies can then be used to retrieve data about the user, and the Salmon Protocol  re-aggregates any distributed  activities, using PubSubHubbub to deliver these back in near real time for the user.
</p><p>Overall, this specification provides a service to the Social Web community by providing an HTTP-based meta-architecture that defines the baseline functionality needed in a distributed social application based on activities. So, people who desire to create their own software for federated social networking can then follow the instructions here to begin becoming interoperable with other networks. However, this specification begins to explore the requirements and functionality needed for federated social networks (i.e. it does not take into account distributed widgets like OpenSocial and private communication). Also, a competing architecture could easily be specified using an XMPP base.
</p>

<h2 id="Accessibility">9.  Accessibility Concerns</h2>
     <p>Accessibility concerns cuts across all aspects of the Social Web. With regards to identity, having the user be able to specify their accessibility requirements as part of identification and authentication  with an identity provider is of utmost concern. In the world of social media, authoring tools should support accessibility, e.g., prompting users for <em>alt</em> text for uploaded formats, and also interchange formats need to support accessibility, e.g., including text alternatives when photos are shared. This is not currently uniformly addressed by current Social Web networking sites. For example,
Facebook suffers from many standard dynamic HTML accessibility issues:  the "Hide" pop-up link not keyboard accessible, lack of landmarks,  there is considerable confusion over what keyboard access in widgets should be, lack of pop-up text on image links, and issues with simultaneous updates.  Accessibility specific issues of Social Web user interfaces are in general addressed by the W3C work on ARIA in HTML, so the W3C should encourage further use of ARIA by existing social networking sites  <a href="#ref-aria">[ARIA]</a>.
</p><p>Many social sites provide APIs in addition to the primary Web interface. This leads to a possibility to create alternate accessible interfaces, but depends on the API exposing all of the features. Many users and communities would work on creating these if the APIs produced the necessary for information. For example, due to invalid markup and a lack of consistent use of "alt" text and other accessibility problems encountered with Twitter's default web-based interface, persons with a disability usually use Twitter via a third-party  social application such as  AccessibleTwitter (a web based interface which uses ARIA, platform agnostic), Echofon (iPhone), or Qwitter (Windows). Note that this is just an incomplete sampling that does not imply endorsement. The W3C should encourage sites to release full-fledged APIs that let communities create their own alternate accessible interface to the Social Web.
</p>

<h2 id="Decentralized">10. Decentralized Social Networking Projects</h2>
 <p>2010 has seen a lot of work undertaken towards making federated social networking real. To describe in more detail,  in order to overcome the need for users to hand over their data to a third-party social networking site, a number of concrete coding projects have started to build federated Social Web platforms, which allow users to run their own social web provider, allowing users to keep their data where they want - even on their own server - while still interacting with the rest of the Social Web. These projects met at the Federated Social Web Summit 2010 <a href="#ref-fsw">[FSW]</a>. One of the results of the summit was the definition of the test-case named Social Web Acid Test 0 (SWAT0)<a href="#ref-swat0">[SWAT0]</a>.  SWAT0 details a use case where a user running a "node" of their own social network wishes to tag a photo of a friend running a node of another social networking codebase, and for the tagging update to propagate amongst both networks.  Below is a non-exhaustive list of projects currently in development for a federated Social Web by participating in SWAT0.  A more complete list is maintained by the GNU social Project <a href="#ref-gnulist">[GNULIST]</a>.
</p>

<h2 id="Statusnet">10.1 StatusNet</h2>
<p>StatusNet is a free software microblogging platform to help people in a community, company or group to exchange short (140 characters, by default) messages over the Web <a href="#ref-statusnet">[STATUSNET]</a>. Users can choose which people to "follow" and receive only their friends' or colleagues' status messages. StatusNet used to be based on the Open Micro-blogging specification but is now based on OStatus, and runs on PHP and MySQL  <a href="#ref-ostatus">[OSTATUS]</a>. It is currently deployed by identi.ca (and an increasing number of independent sites) and supported by plug-ins for Drupal and WordPress.
</p>

<h2 id="GNU">10.2 GNU social</h2>
<p>GNU social is a project championed by the Free Software Foundation (FSF)  <a href="#ref-gnusocial">[GNUSOCIAL]</a>. A decision by the GNU social steering committee has been made to built on top of the OStatus protocol and the StatusNet codebase. It's main goal is to deployable with a minimal hosting configuration. As it is based on StatusNet, it is run from MySQL and PHP.
</p>

<h2 id="OneSocialWeb">10.3 OneSocialWeb</h2>
<p>Vodafone's OneSocialWeb open source decentralized federated social web platform built on XMPP  <a href="#ref-osw">[OSW]</a>. OneSocialWeb has extended XMPP using a number of draft specifications: ActivityStreams over XMPP  <a href="#ref-axmpp">[AXMPP]</a>, vCard4 over XMPP  <a href="#ref-vcardxmpp">[VCARDXMPP]</a>, Social Relationships  <a href="#ref-sr">[SR]</a>, and Personal Eventing Protocol (to allow events to be stored offline in an "inbox") <a href="#ref-pep">[PEP]</a> . OneSocialWeb has a Java-based plug-in for servers, web clients, and an Android application.</p>

<h2 id="Higgin">10.4 Higgin's Project</h2>
<p>Eclipse's Higgin's Project is one of the earliest open-source efforts to create a decentralized social network  <a href="#ref-osw">[HIGGINS]</a>. It is based on the Personal Data Store model and its own RDF/OWL persona data model. It also includes support for active clients and OASIS IMI infocards to deal with issues related to identity provisioning, multiple identities, multiple personae, and multiple levels of assurance  <a href="#ref-infocard">[INFOCARD]</a>.
</p>

<h2 id="Diaspora">10.5 Diaspora</h2>
<p>The Diaspora project  to "leave Facebook"  <a href="#ref-diaspora">[DIASPORA]</a> was greeted with much fanfare by the New York Times in May, as it was founded by four students from New York University who have managed to collect 200,000 US dollars using online donations  <a href="#ref-nyt">[NYT]</a>. Their main focus is security, with all communications encrypted and signed. Their alpha code in Ruby has been released.
</p>


<h2 id="Diso">10.6 Diso Project</h2>
<p>The Diso project is an umbrella-group to build a decentralized Social Web into open-source software, focussing first on enabling OpenID, OAuth, and Microformats for WordPress and Movable Type in PHP  <a href="#ref-diso">[DISO]</a>.</p>

<h2 id="SMOB">10.7 SMOB</h2>
<p>Semantic MicroBlogging (SMOB) is a framework for distributed microblogging based on Semantic Web technologies  <a href="#ref-smob">[SMOB]</a>. Each "hub" of SMOB exposes its data in RDFa and as a SPARQL end-point. Updates are then down using SPARQL Update, so that interaction consists of exchanging RDF data such as FOAF and SIOC, but augmented, with a special focus on tags vocabularies like CommonTag, making microblogging part of the Linked Open Data effort.</p>

<h2 id="Appleseed">10.8 Appleseed</h2>
<p>Appleseed is another decentralized social networking project that claims to be the first fully decentralized social networking software, emphasizes privacy, the ability to move around without losing your friends, and advocates open standards  <a href="#ref-apples">[APPLES]</a>.
</p>

<h2 id="OpenLink">10.9 OpenLink Data Spaces</h2>
<p>OpenLink Data Spaces (ODS) is an open source project on the OpenLink Virtuoso Server with several  pre-built subsidiary user-focused applications  <a href="#ref-ods">[ODS]</a>. In addition to OpenID and WebID, it supports Semantic Web technologies, Atom variants, oData, and gData (communicating via "semantic pingback"). Its focus is on data-space virtualization and ACLs for Web storage.
</p>

<h2 id="Project">10.10 Project Danube</h2>
<p>Project Danube is an example of a Personal Data Store (PDS) (aka Personal Data Locker), a <em>fourth party</em> service that works on a user's behalf as put forward by the VRM  (Vendor Relationship Management) community  <a href="#ref-danube">[DANUBE]</a>. The intent is to centralize control for the user, and to provide them with a central dashboard for decentralized and federated data. Project Danube is an XRI-based implementation of a Personal Data store and participates in the Federated Social Web effort, having  a working OStatus implementation.</p>

<h2 id="Business">11. Business Considerations</h2>
<p>The purpose of a distributed and decentralized Social Web is not to propose or promote solutions which reduce or erode existing and viable businesses. It seeks to explore the introduction of an entirely new Social Web architecture that new and existing businesses can take advantage of in the future. By combining existing business models that allow existing large social networking sites to leverage their huge amounts data with a lower transaction cost, new businesses can be built downstream from these data silos and whole new models can emerge.
</p>

<h2 id="Size">11.1 Size of Social Networking in 2010</h2>
<p>How large is the Social Web? This brings up immediately the question of metrics: What are the appropriate measures of the size of the existing the Social Web and how could a move to a decentralized and federated approach increase its size? While a number of metrics and analytics  were explored <a href="#ref-metrics">[METRICS]</a>, the metric which matters most for businesses is money. Observers have speculated that Facebook, the undisputed leader in most markets, received between $600 and $900 million in advertising sales in 2009, so that Facebook declared that it had reached break-even and was running profitably <a href="#ref-fbprofit">[FBPROFIT]</a>. Tencent, the operator of the Chinese social platform QQ, announced in May 2010 that it generated $1.8 billion in revenues in 2009, and judging from the rate of increase in the past year, Tencent can be expected to generate double the 2009 revenues in 2010. According to an independent analysis in March 2010 , Facebook is on track to exceed 1 billion in 2010  <a href="#ref-insidefb">[INSIDEFB]</a>.  There are also steadily increasing revenues across the entire ecosystem:
</p>
<ul><li> Mobile network operators up-sell smartphones and a greater number of higher margin data plans to people who are avid users of social networks
</li><li> Social application developers generate revenues and a wide variety of publishers want to be available on social networks
</li><li> Social games, a phenomenon which was already wildly popular in China, Japan and Korea, expanded rapidly on MySpace and Facebook in 2009-2010, creating high valuations and recurring revenues from users who acquire digital goods and services within games.
</li></ul>

<h2 id="Current">11.2 Current business models for social networks</h2>
<p>Currently,  revenues can be generated from the Social Web by:
</p>
<ul><li> Users paying from their own pockets
</li><li> Corporations purchasing advertising which they can convert into future business revenues
</li><li> Commissions on transactions (a case in which the end user paying for a digital or physical good and the vendor selling that good provide a small percentage of the total cost to the provider of the social applications through which the transaction happens, like  a purchase on eBay).
</li></ul>
<p>Some of the largest social networks today are only using advertising to generate revenues. Others only have user premium service fees. Some companies are combining two or three business models. For example, mobile social networks such as MeetMoi and Flirtomatic are reliant on both. Facebook continues to offer its service at no cost to end users and generating its revenues entirely on advertising, although transactions in the platform are enabled and expected to generate increasing revenues in the future.  In Japan, Gree, Mixi, and Mobagetown provide their social networking for free and generate revenues from sales of advertisements, sales of premium options to members of the community (e.g., extra storage for photos, a larger virtual 'room' for their avatar, a new template for a blog with professional graphics), and sales of digital goods ( games, wallpaper, accessories for avatars). We expect the trend towards combining current business models to continue, leading to the desire for secure Web-centric identity and Web payments.
</p>

<h2 id="New">11.3 New business models</h2>
<p>In the future,  revenues can be generated from the Social Web by:
</p>
<ul><li> New kinds social applications that enable new kinds of collaboration  to take place that take advantage of social data-mash-ups from multiple services.
</li><li> Software sales, maintenance or tuning of new identity-aware and privacy-aware Social Web applications that offer strong guarantees to users.
</li><li> A more flexible and open market of low-cost social media paid for by Web payments
</li><li> Increased liquidity of social data with strong assurances of a lack of legal liability.

</li><li> Integrating social features into all aspects of existing applications and computing in general.
</li></ul>
<p>The Social Web will affect every area of activity, and each area has very specialized requirements and sources of revenue. For example, an identity provide for Social Web might also generate revenues by way of providing a highly robust authentication mechanism  that would be considered an added value  due to its prevention of identity theft or the enabling of Web-based e-commerce based on micropayments. Such identity and privacy providers will be able to generate revenues by way of users choosing and paying either a one time (fixed cost) fee, a monthly subscription cost (flat recurring), a pay as you use (variable cost) fee or even viewing agreed-upon advertising.  An open Social Web would cater for entirely new innovations, such as a provider or even user making revenues by selling (as controlled by the user), bundles of privacy-protected data about the user that it puts up for auction on personal data exchanges (similar to stock markets) where other providers can bid for and acquire these data in order to provide new and valuable services back to the user. Notice in particular that government agencies that interact with the public require much more clearly defined and formalized rules over privacy and identity, while e-commerce will require the ability to describe rights and identity to a high extent. Research will need better social tools for relating people, data-sets, and results.  Each of these areas will have very different value propositions and so different places to monetize the service.
</p>
<h2 id="Conclusions">12. Conclusions: A Strategy for the Social Web</h2>
<p>The Social Web architecture detailed in this report strives to keep the Web universal by allowing the various components of the Social Web to each be treated as a "first-class" citizen of Web architecture. In order to do this, this Social Web architecture necessary separates the underlying social platforms like social networking sites from the social applications that leverage the profile information these social platforms provide. If the frameworks described can be implemented, the distinction between social networking sites, social platforms and social applications  will become more and more blurry.  Far from disappearing, the importance of particular social networking sites and social platforms as central identity and privacy providers in the "cloud" will become even more paramount, as a larger eco-system of social applications are created that run off the data and policies provided by these identity and privacy providers. The open-ended and evolving social framework presented in this report would, if implemented across the Social Web, be a leap forward in allowing current social networking sites to share their data with applications and other sites in a manner that allows them to gain maximum value from their user-base while in good faith not violating laws regarding content and privacy. With such a Social Web architecture in place, social application developers will be able to focus on their value proposition to users in terms of improved interfaces and services, and not low-level data management or be concerned about privacy. As opposed to being stuck in proprietary platforms, the Web itself will become the ultimate social platform  <a href="#ref-long">[LONG]</a>.
</p>


<h2 id="Investigate">12.1  Investigate Identity in the Browser</h2>
<p>The increasing pressure from identity theft combined with movements by governments like the USA to establish national identity schemes gives special urgency for a secure and widely-used digital identity to be part of the Web <a href="#ref-usa">[USA]</a>. As mentioned earlier, the OpenID simplifications proposed by approaches like WebFinger (e-mails as identifiers) and OpenID Connect (building OpenID on top of OAuth) are likely help facilitate deployment of these technologies. All of these approaches rely on a common general pattern: a client authenticates with a trusted server using some client-side authentication mechanism (commonly a user-name and a  password), and the server can then access social services on behalf of the authenticated user. Currently the problem of possible phishing is tackled by secondary authentication such as SMS texting, but another approach would be to look to the Web for secondary authentication <a href="#ref-laurie">[LAURIE]</a>. Web-based client-side approaches, like using certificates, could help server-side identity providers with secure user authentication. Furthermore, any approach should allow the user to easily setup their own server or use their browser as an identity provider, and provide a higher-level of security assurance as needed for government and e-commerce interactions. However, client-side approaches to identity have poor user experiences at the moment, partially because of lack of support within the browser and proposals in this space such as Information Cards or WebID are still in need of more work. Lastly, the Web lacks Javascript APIs around identity, which limit deployment of even the best technical solutions. The W3C should use its role within the browser community to support the development of client-side approaches to identity to help browsers become fully-fledged social agents while maintaining a decentralized approach to user-centric identity that fulfills the security requirements of e-commerce, governments, and ordinary users.
</p><p>The W3C should participate in Identity Commons  and liaison with the OpenID Foundation, Infocard Foundations, and the Kantara Initiative on this front. User requirements should be gathered from governments and e-Commerce, and future W3C workshop(s) on client-oriented approaches should identify technical work and standardization that compliments the ongoing work in the digital identity community. The W3C should also incubate specific technical proposals for standardization that are simple enough to be widely deployed while taking security and privacy requirements on board.
</p>


<h2 id="Coordinate">12.2 Co-ordinate the Core of Profile Data</h2>
<p>Users should be able to describe themselves in their profile without any technical restrictions imposed on them by social networking sites. Equally so, developers should be able to access the commonly-used core of profile data in an easy-to-use manner across different social networking sites and social platforms. For example,  OpenID Connect reuses the same core, but makes a variation by using underscore instead of "camelCase". The core of vCard 4.0, PortableContacts, OpenSocial and FOAF should all be mappable to each other and use the same design pattern, regardless of the debates around underscore and "camelCase". Also, the common core of names should be the same across XML, RDFa, and JSON serializations, and be the same across social APIs. The W3C DAP Working Group is already pursuing this coordination <a href="#ref-cfc">[CFC]</a>. At the same point, the common core must be extensible  and not make arbitrary limits on how users identify themselves and must be able to handle international differences, such as internationalized names. Therefore, we also suggest that this core be reviewed for internationalization by the W3C, and that all social web standards support Internationalized Resource Identifiers <a href="#ref-iri">[IRI]</a>. Also, we suggest that a common and decentralized extension mechanism be chosen based on a combination of a registry of strings and encouraging the use of URIs for decentralized extensibility. Developers should be able to access profile data across various social APIs in a consistent manner for the core, but in a way that is extensible and internationalized.</p>


<h2 id="Combining">12.3 Combining Social Media and the Semantic Web</h2>
<p>Social media on the Web is one of the most under-developed areas as regards functionality and standards. Social media should be portable, and allow licensing and usage information to "move" with social data that is cut and pasted across media. The general trend towards portable metadata for social media is a golden opportunity for the Semantic Web. However, the Semantic Web overall has a number of problems that are leading to its lack of uptake by  developers to use. First, RDF currently has no standard way of inter-operating with Atom and JSON, the primary dataformats of the Social Web.  Second, the core architecture of RDF also does not support provenance and the expression of rules in RDF, which are crucial for Social Web use-cases. Third, there is also a practical issue with URIs on the Semantic Web, namely that it is impossible to locate URIs and vocabularies for kinds of social media that users want to find. Microformats and the Open Graph Protocol have succeeded up to this point because not only are they easy to use, but also specify in an easy-to-find way their vocabularies. While vocabulary hosting services are already available, Semantic Web users need easy ways to identify and build vocabularies in any domain. That can be done for instance through a central vocabulary hosting and management site, possibly managed by the W3C or some other neutral body, that allows users to register and create new vocabularies with a well-defined process, or at least through a vocabulary listing website, used to identify vocabularies available on the Web, with their core characteristics (last activity date, etc.) <a href="#ref-vochost">[VOCHOST]</a>. Lastly, the issue of expressing licensing information for social media and Web-based micropayments for social media should be investigated. In order for these approaches to take off and to enable "cut-and-paste" of social media, browser vendors should be involved as early as possible. The W3C community should explore incubator groups around ODRL and Web-based micropayments (Webpayments).
</p>

<h2 id="Reengage">12.4  Re-engage Privacy Activity Focusing on the Social Web</h2>
<p>As the privacy crisis of 2010 (over Google Buzz and the Facebook privacy settings) and various empirical studies have shown  <a href="#ref-jungle">[JUNGLE]</a>,  users want to have control of their privacy, and the W3C needs to take a position of leadership in this area. Previous attempts by the W3C in this area such as P3P and POWDER have not been successful. The three main issues were complexity, lack of enforcement, and lack of economic incentives for website operators.
</p><p>There is no clear technical approach to privacy that is technically agreed upon, although elements such as public key encryption do exist. However, users should at least be able to express their privacy preferences and be alerted to possible violations. No simple logic and proof-based system by itself will be usable, simply because it will be far too complicated (even more so than P3P) for ordinary users and developers. Work on simplified sets of common privacy settings - as exemplified by Mozilla Privacy Icons and Privacy rule-sets - are a way forward to reduce complexity to a level that users and developers can use. The second issue however, is one of enforcement. While embedding privacy icons in a browser may help, it is not enough, and technical approaches can only work with existing social approaches. For example, a consortium of government officials and lawyers specialized in privacy could map out how the use of these common privacy settings can be legally enforced and then set up a "preserve privacy" initiative (similar to the "Stop Badware" initiative <a href="#ref-badware">[BADWARE]</a>)  to crowd-source privacy violations. The main objection to this could be commercial, namely that it would discourage the use of data by sites, although by letting such a scheme be opt-in, it would provide new markets for privacy-aware users and also let companies have a healthier relationship with legal privacy regulations by providing them basic protection around issues of privacy and rights to data. Such combinations of technical and social mechanisms should be actively investigated by the W3C.
</p><p>Despite the complexity of the issue of privacy on the Social Web, the time for action is now. User privacy is of utmost importance, and the W3C should invest in full-time resources to create an over-arching privacy activity to inspect all W3C Recommendations and Web technologies in general for privacy concerns.
</p>


<h2 id="Federated">12.5 Support the Federated Social Web</h2>
<p>One of the most inspiring developments was the creation of a test-driven approach towards creating a federated Social Web over the last year. If successful, this very practical approach will create interoperability among code-bases. It recognizes that many of the Social Web specifications are still experimental and the code-bases are mostly still a work in development, but is nonetheless it could be the crucial element to getting a decentralized and privacy-enhanced Social Web working. At the Federated Social Web Summit, the first Social Web Acid Test (SWAT0) of sharing a tagged photo across multiple social networking sites was produced <a href="#ref-fsw">[FSW]</a>. However, as many of the core individuals that have supported a decentralized Social Web based on open standards are now quite busy with other work, it would be important for the W3C to offer its resources to the Federated Social Web effort in order to help this effort succeed. Ideally, <em>w3.org</em> itself should become a node in a federated social network, allowing social features (blog-comments, tweets, status-updates) to improve the social interactions around specification development itself. So while the W3C should not favor any one particular technology or standard in this space, at this early stage a Federated Social Web Incubator Group would be the next step.

</p>


<h2 id="Open">12.6 Open the World Wide Web Consortium</h2>
<p>The World Wide Web originally became successful as the Web was built on standards that were given to the world on a royalty-free basis, allowing the Web to be implemented over different underlying systems. There is no reason to believe that the Social Web will be any different. In this regard, ensuring that the standards that can serve as the foundation of the Social Web are genuinely open, which means that they can implemented on a royalty-free basis guaranteed by patent non-assertion agreements, is of utmost importance. Simply branding something "open" is no longer enough. The progress of the Open Web Foundation License in allowing individual authors and organizations to sign patent non-assertions is a vital key to allowing specifications to be written in a more "open-source" process  <a href="#ref-owf">[OWF]</a>, as many of the standards created for the Social Web have been created outside the W3C. So that the decentralized Social Web can reach maturity, the World Wide Web Consortium should offer its resources to the wider Social Web community. However, the World Wide Web Consortium has a number of structural issues with its current standardization process, as it is difficult to start new work and the membership requirements are too exclusive. However, we recognize that to a large extent the value proposition of the World Wide Web Consortium consists not only in its resources and well-defined process, but also in the fact that it can get the consortium members, often large companies, to agree to a royalty-free patent policy. The Social Web Incubator Group supports the creation of the Community Group process that lets individuals participate in the experimental stage of a standards process and supports the existence of a clear path from individuals giving Open Web Foundation licenses to their specifications to these specifications becoming W3C Royalty-Free Recommendations <a href="#ref-community">[COMMUNITY]</a>. This should decentralize the standardization process of the W3C to allow more standards to emerge from the grassroots and harness the collective intelligence of the Web in a more effective manner.</p><p>Now is a critical moment, as the open Web itself is under threat from the increasing use of proprietary platforms on mobile and other devices primarily for social applications <a href="#ref-long">[LONG]</a>. As the Social Web is not yet a first-class citizen of the standards-based open Web, many users and developers find it easier to use closed platforms rather than the Web itself. However, a standards-based, open and privacy-aware Social Web created is the obvious next step in the evolution of the Web, as the Web is increasingly the Social Web. Together with wider eco-system of the Web itself, the W3C can help lead the  Social Web to its full potential.
</p>


<h2 id="Acknowledgments">13. Acknowledgments</h2>
<p>This document is the product of the Social Web (SWXG) Incubator Group. At the time of publication, the active members of the Social Web Incubator Group included Tim Anglade, Daniel Appelquist, Dan Brickley, Melvin Carvalho, Venezia Claudio, Harry Halpin, Renato Iannella, Toby Inkster, Alexandre Passant, Christine Perey, Ronald Reck, Ted Thibodeau, Mischa Tuffield, Oshani Seneviratne, Henry Story, Fabien Gandon, and Paul Trevithick. This report is dedicated to the memory of Peter Ferne, who participated in the Social Web Incubator Group, and all the developers out there working to make a decentralized Social Web a reality. The group would like to thank the following people who we consulted with over the lifetime of the Social Web Incubator Group in order to make this final report: Robin Berjon, Tim Berners-Lee (MIT), Joseph Bonneau (Cambridge), Marcos Caceres (Opera), Michael Cooper (W3C), Sam Critchley (Gypsii), Anita Doehler (Vodafone), Nathan Eagle (MIT), Kaliya Hamlin (Identity Commons), Michael Hanson (Mozilla), Dick Hardt (OpenID Foundation), Eran Hammer-Lahav (Yahoo!), Yolanda Gil (USc), Paul Groth (Vrije University Amsterdam ), Lalana Kagal (MIT), Ros Lawler (Random House), Matt Lee (Free Software Foundation), Chris Messina (Google), Alexandre Monnin (Sorbonne), Soren Preibusch (Cambridge), Evan Prodromou (StatusNet), David Raggett (W3C), Aza Raskin (Mozilla), David Recordon (Facebook), Gregory Rosmaita, Janina Sajka (Web Accessibility Initiative), Luke Shepard (Facebook), Joseph Smarr (Google), Manu Sporny (Digital Bazaar), Peter St. Andre (Cisco), Simon Tenant, and Slim Trabelsi (SAP). We also gratefully received and incorporated comments from J. Trent Adams (ISOC), Jon Bradley (OpenID Foundation), Joni Brennan (Kantara Initiative) and Brian Kissel (OpenID Foundation). Finally, the W3C would like to thank Eduserv for providing a W3C Fellowship for Harry Halpin <a href="#ref-eduserv">[EDUSERV]</a>.
</p>


<h2 id="References">14. References</h2>
<p><span id="ref-actapi" class="anchor"></span>
</p>
<dl><dt> [ACTAPI]
</dt><dd> <em>Activity Streams API Draft Specification</em>, M. Atkins, M. Keller, W. Norris.  Draft specification, May 18th 2010. Available at <a href="http://activitystrea.ms/head/activity-api.html" class="external free" title="http://activitystrea.ms/head/activity-api.html">http://activitystrea.ms/head/activity-api.html</a>
</dd></dl>
<p><span id="ref-activity" class="anchor"></span>
</p>
<dl><dt> [ACTIVITY]
</dt><dd> <em>Atom Activity Extensions</em>, M. Atkins, D. Recordon, C. Messina, M. Keller, and R. Dolin. Draft specification, March 9th 2010. Available at <a href="http://activitystrea.ms/spec/1.0/atom-activity-01.html" class="external free" title="http://activitystrea.ms/spec/1.0/atom-activity-01.html">http://activitystrea.ms/spec/1.0/atom-activity-01.html</a>

</dd></dl>
<p><span id="ref-actjson" class="anchor"></span>
</p>
<dl><dt> [ACTJSON]

</dt><dd> <em>Activity Streams Concepts and Representations</em>, M. Atkins, W. Norris, C. Messina, M. Wilkinson, and R. Dolin. October 13th 2010. Available at <a href="http://activitystrea.ms/head/json-activity.html" class="external free" title="http://activitystrea.ms/head/json-activity.html">http://activitystrea.ms/head/json-activity.html</a>
</dd></dl>

<p><span id="ref-actschema" class="anchor"></span>
</p>
<dl><dt> [ACTSCHEMA]
</dt><dd> <em>Atom Activity Extensions</em>,  M. Atkins, D. Reordon, C. Messina, M. Keller, A. Steinberg, and R. Dolin. Draft specification,  March 9th 2010.  Available at <a href="http://activitystrea.ms/schema/1.0/activity-schema-01.html" class="external free" title="http://activitystrea.ms/schema/1.0/activity-schema-01.html">http://activitystrea.ms/schema/1.0/activity-schema-01.html</a>
</dd></dl>

<p><span id="ref-air" class="anchor"></span>
</p>
<dl><dt> [AIR]
</dt><dd> <em>AIR</em>, L. Kagal.  Draft specification. Retrieved October 26th 2010.  Available at <a href="http://dig.csail.mit.edu/2009/AIR/" class="external free" title="http://dig.csail.mit.edu/2009/AIR/">http://dig.csail.mit.edu/2009/AIR/</a>
</dd></dl>

<p><span id="ref-apples" class="anchor"></span>
</p>
<dl><dt> [APPLES]
</dt><dd> <em>Appleseed</em>,  Retrieved October 26th 2010. Available at <a href="http://opensource.appleseedproject.org/" class="external free" title="http://opensource.appleseedproject.org/">http://opensource.appleseedproject.org/</a>
</dd></dl>
<p><span id="ref-aria" class="anchor"></span>
</p>

<dl><dt> [ARIA]
</dt><dd> <em>ARIA</em>, J. Craig and M. Cooper. September 16th 2010. Available at <a href="http://www.w3.org/TR/wai-aria/" class="external free" title="http://www.w3.org/TR/wai-aria/">http://www.w3.org/TR/wai-aria/</a>
</dd></dl>

<p><span id="ref-axmpp" class="anchor"></span>
</p>
<dl><dt> [ASXMPP]
</dt><dd> <em>ActivityStreams over XMPP</em>, L. Eschenauer.  Draft specification. April 4th 2009. Available at <a href="http://onesocialweb.org/spec/1.0/osw-activities.html" class="external free" title="http://onesocialweb.org/spec/1.0/osw-activities.html">http://onesocialweb.org/spec/1.0/osw-activities.html</a>
</dd></dl>

<p><span id="ref-atom" class="anchor"></span>
</p>
<dl><dt> [ATOM]
</dt><dd> <em>The Atom Syndication Format</em>, M. Nottingham and R. Sayre. IETF RFC 4287 (Standards Track). December 5th. 2010. Available at <a href="http://www.ietf.org/rfc/rfc4287.txt" class="external free" title="http://www.ietf.org/rfc/rfc4287.txt">http://www.ietf.org/rfc/rfc4287.txt</a>

</dd></dl>
<p><span id="ref-badware" class="anchor"></span></p>
<dl><dt> [BADWARE]
</dt><dd> <em>Stop Badware</em>, Retrieved October 26th 2010. Available at <a href="http://stopbadware.org/" class="external free" title="http://stopbadware.org/">http://stopbadware.org/</a>
</dd></dl>

<p><span id="ref-cfc" class="anchor"></span>
</p>
<dl><dt> [CFC]
</dt><dd> <em>W3C Comparison of Contact Formats</em>,  26th October 2010. Available at <a href="http://www.w3.org/2009/dap/wiki/ContactFormatsComparison" class="external free" title="http://www.w3.org/2009/dap/wiki/ContactFormatsComparison">http://www.w3.org/2009/dap/wiki/ContactFormatsComparison</a>
</dd></dl>

<p><span id="ref-community" class="anchor"></span>
</p>
<dl><dt> [COMMUNITY]
</dt><dd><em>Community Group Proposal</em>, I. Jacobs. November 4th 2010. Available at <a href="http://www.w3.org/2010/07/community" class="external free" title="http://www.w3.org/2010/07/community">http://www.w3.org/2010/07/community</a>
</dd></dl>

<p><span id="ref-conc" class="anchor"></span>
</p>
<dl><dt> [CONC]
</dt><dd> <em>Technical concerns presented on W3C Mailing list</em>, S. Williams.  May 21st 2008. Available at <a href="http://lists.w3.org/Archives/Public/www-tag/2008May/0078.html" class="external free" title="http://lists.w3.org/Archives/Public/www-tag/2008May/0078.html">http://lists.w3.org/Archives/Public/www-tag/2008May/0078.html</a>
</dd></dl>

<p><span id="ref-ctag" class="anchor"></span>
</p>
<dl><dt> [CTAG]
</dt><dd> <em>CommonTag</em>. Retrieved October 26th 2010. Available at <a href="http://www.commontag.org/Home" class="external free" title="http://www.commontag.org/Home">http://www.commontag.org/Home</a>
</dd></dl>

<p><span id="ref-danube" class="anchor"></span>
</p>
<dl><dt> [DANUBE]
</dt><dd> <em>Project Danube</em>. Retrieved October 2010. Available at <a href="http://www.projectdanube.org/" class="external free" title="http://www.projectdanube.org/">http://www.projectdanube.org/</a>
</dd></dl>

<p><span id="ref-dap" class="anchor"></span>
</p>
<dl><dt> [DAP]
</dt><dd> <em>W3C DAP WG</em>. Retrieved October 26th 2010. Available at <a href="http://dev.w3.org/2009/dap/" class="external free" title="http://dev.w3.org/2009/dap/">http://dev.w3.org/2009/dap/</a>
</dd></dl>

<p><span id="ref-dataport" class="anchor"></span>
</p>
<dl><dt> [DATAPORT]
</dt><dd> <em>DataPortability</em>. Retrieved October 26th 2010. Available at <a href="http://www.dataportability.org/" class="external free" title="http://www.dataportability.org/">http://www.dataportability.org/</a>
</dd></dl>

<p><span id="ref-diaspora" class="anchor"></span>
</p>
<dl><dt> [DIASPORA]
</dt><dd> <em>Diaspora project</em>. Retrieved October 26th 2010. Available at <a href="http://joindiaspora.com/" class="external free" title="http://joindiaspora.com/">http://joindiaspora.com/</a>
</dd></dl>

<p><span id="ref-diso" class="anchor"></span>
</p>
<dl><dt> [DISO]
</dt><dd> <em>DISO project</em>. Retrieved October 26th 2010. Available at <a href="http://diso-project.org/" class="external free" title="http://diso-project.org/">http://diso-project.org/</a>
</dd></dl>

<p><span id="ref-dlf" class="anchor"></span>
</p>
<dl><dt> [DLF]
</dt><dd> <em>Data Liberation Front</em>. Retrieved October 26th 2010. Available at <a href="http://www.dataliberation.org/" class="external free" title="http://www.dataliberation.org/">http://www.dataliberation.org/</a>
</dd></dl>

<p><span id="ref-eduserv" class="anchor"></span>
</p>
<dl><dt> [EDUSERV]
</dt><dd> <em>Eduserv</em>. Retrieved October 26th 2010. Available at <a href="http://www.eduserv.org.uk" class="external free" title="http://www.eduserv.org.uk">http://www.eduserv.org.uk</a>
</dd></dl>

<p><span id="ref-fbnhs" class="anchor"></span>
</p>
<dl><dt> [FBNHS]
</dt><dd> <em>NHS.uk allowing Google, Facebook, and others to track you</em>, M. Tuffield. November 21st 2010. Available at <a href="http://mmt.me.uk/blog/2010/11/21/nhs-and-tracking/" class="external free" title="http://mmt.me.uk/blog/2010/11/21/nhs-and-tracking/">http://mmt.me.uk/blog/2010/11/21/nhs-and-tracking/</a>
</dd></dl>

<p><span id="ref-fbpriv" class="anchor"></span>
</p>
<dl><dt> [FBPRIV]
</dt><dd> <em>Facebook Privacy: A Bewildering Tangle of Options</em>, G. Gates. New York Times, May 12th 2010. Available at <a href="http://www.nytimes.com/interactive/2010/05/12/business/facebook-privacy.html" class="external free" title="http://www.nytimes.com/interactive/2010/05/12/business/facebook-privacy.html">http://www.nytimes.com/interactive/2010/05/12/business/facebook-privacy.html</a>
</dd></dl>

<p><span id="ref-fbprofit" class="anchor"></span>
</p>
<dl><dt> [FBPROFIT]
</dt><dd> <em>Facebook Crosses 300 Million Users</em>,  M. Siegler. TechCrunch. September 15th 2009. Available at <a href="http://techcrunch.com/2009/09/15/facebook-crosses-300-million-users-oh-yeah-and-their-cash-flow-just-went-positive/" class="external free" title="http://techcrunch.com/2009/09/15/facebook-crosses-300-million-users-oh-yeah-and-their-cash-flow-just-went-positive/">http://techcrunch.com/2009/09/15/facebook-crosses-300-million-users-oh-yeah-and-their-cash-flow-just-went-positive/</a>
</dd></dl>

<p><span id="ref-fbtos" class="anchor"></span>
</p>
<dl><dt> [FBTOS]
</dt><dd> <em>Facebook's Terms of Service</em>.  Retrieved October 26th 2010. Available at <a href="http://www.tosback.org/policy.php?pid=39" class="external free" title="http://www.tosback.org/policy.php?pid=39">http://www.tosback.org/policy.php?pid=39</a>
</dd></dl>

<p><span id="ref-fbviz" class="anchor"></span>
</p>
<dl><dt> [FBVIZ]
</dt><dd> <em>Facebook Privacy Vizualizer</em>, M. McKeown. Retrieved October 26th 2010. Available at <a href="http://mattmckeon.com/facebook-privacy/" class="external free" title="http://mattmckeon.com/facebook-privacy/">http://mattmckeon.com/facebook-privacy/</a>
</dd></dl>

<p><span id="ref-foaf" class="anchor"></span>
</p>
<dl><dt> [FOAF]
</dt><dd> <em>FOAF Vocabulary Specification</em>, D. Brickley and L. Miller. Draft specification, August 9th 2010. Available at <a href="http://xmlns.com/foaf/spec/" class="external free" title="http://xmlns.com/foaf/spec/">http://xmlns.com/foaf/spec/</a>
</dd></dl>
<p><span id="ref-foafssl" class="anchor"></span>
</p>
<dl><dt> [FOAFSSL]

</dt><dd> <em>FOAF+SSL</em>.  Retrieved October 26th 2010. Available at <a href="http://esw.w3.org/foaf+ssl" class="external free" title="http://esw.w3.org/foaf+ssl">http://esw.w3.org/foaf+ssl</a>
</dd></dl>

<p><span id="ref-fsw" class="anchor"></span>
</p>
<dl><dt> [FSW]
</dt><dd> <em>Federated Social Web</em>. Retrieved October 26th 2010. Available at <a href="http://federatedsocialweb.net/" class="external free" title="http://federatedsocialweb.net/">http://federatedsocialweb.net/</a>
</dd></dl>

<p><span id="ref-ftc" class="anchor"></span>
</p>
<dl><dt> [FTC]
</dt><dd> <em>Protecting Consumer Privacy in an Era of Rapid Change</em>.  Federal Trade Commission, December 2010.  Available at <a href="http://www.ftc.gov/os/2010/12/101201privacyreport.pdf" class="external free" title="http://www.ftc.gov/os/2010/12/101201privacyreport.pdf">http://www.ftc.gov/os/2010/12/101201privacyreport.pdf</a>
</dd></dl>


<p><span id="ref-germanlaw" class="anchor"></span>
</p>
<dl><dt> [GERMANLAW]
</dt><dd> <em>Facebook faces inquiry, fine by German privacy official </em>, Monsters and Critics. July 8th 2010. Available at <a href="http://www.monstersandcritics.com/news/europe/news/article_1569169.php/Facebook-faces-inquiry-fine-by-German-privacy-official" class="external free" title="http://www.monstersandcritics.com/news/europe/news/article_1569169.php/Facebook-faces-inquiry-fine-by-German-privacy-official">http://www.monstersandcritics.com/news/europe/news/article_1569169.php/Facebook-faces-inquiry-fine-by-German-privacy-official</a>

</dd></dl>
<p><span id="ref-gnulist" class="anchor"></span>
</p>
<dl><dt> [GNULIST]

</dt><dd> <em>List of Project on the GNUSocial Site</em>. Retrieved October 26th 2010. Available at <a href="http://gitorious.org/social/pages/ProjectComparison" class="external free" title="http://gitorious.org/social/pages/ProjectComparison">http://gitorious.org/social/pages/ProjectComparison</a>
</dd></dl>
<p><span id="ref-gnusocial" class="anchor"></span>
</p>
<dl><dt> [GNUSOCIAL]
</dt><dd> <em>GNU social</em>. Retrieved October 26th 2010. Available at <a href="http://www.gnu.org/software/social/" class="external free" title="http://www.gnu.org/software/social/">http://www.gnu.org/software/social/</a>
</dd></dl>

<p><span id="ref-grddl" class="anchor"></span>
</p>
<dl><dt> [GRDDL]
</dt><dd> <em>Gleaning Resource Descriptions from Dialects of Languages (GRDDL)</em> D. Connolly. W3C Recommendation, September 11th 2007. Available at <a href="http://www.w3.org/TR/grddl/" class="external free" title="http://www.w3.org/TR/grddl/">http://www.w3.org/TR/grddl/</a>
</dd></dl>

<p><span id="ref-hcard" class="anchor"></span>
</p>
<dl><dt> [HCARD]
</dt><dd> <em>hCard</em>. T. Celik. February 2nd 2006.   Available at <a href="http://microformats.org/wiki/hcard" class="external free" title="http://microformats.org/wiki/hcard">http://microformats.org/wiki/hcard</a>
</dd></dl>

<p><span id="ref-higgins" class="anchor"></span>
</p>
<dl><dt> [HIGGINS]
</dt><dd> <em>Higgins Project</em>. Retrieved October 26th 2010. Available at <a href="http://higgins-project.org/" class="external free" title="http://higgins-project.org/">http://higgins-project.org/</a>
</dd></dl>

<p><span id="ref-hostmeta" class="anchor"></span>
</p>
<dl><dt> [HOSTMETA]
</dt><dd> <em>Web Host Metadata</em>. E. Hammer-Lahav.  IETF Internet Draft (Standards Track), June 15th 2010. Available at <a href="http://tools.ietf.org/html/draft-hammer-hostmeta-13" class="external free" title="http://tools.ietf.org/html/draft-hammer-hostmeta-13">http://tools.ietf.org/html/draft-hammer-hostmeta-13</a>
</dd></dl>

<p><span id="ref-hrev" class="anchor"></span>
</p>
<dl><dt> [HREV]
</dt><dd> <em>hReview</em>. T. Celik. February 2nd 2006. Available at <a href="http://microformats.org/wiki/hreview" class="external free" title="http://microformats.org/wiki/hreview">http://microformats.org/wiki/hreview</a>
</dd></dl>

<p><span id="ref-iaf" class="anchor"></span>
</p>
<dl><dt> [IAF]
</dt><dd> <em>Identity Assurance Framework</em>. Retrieved October 26th 2010. Available at <a href="http://kantarainitiative.org/confluence/display/certification/Identity+Assurance+Certification+Program" class="external free" title="http://kantarainitiative.org/confluence/display/certification/Identity+Assurance+Certification+Program">http://kantarainitiative.org/confluence/display/certification/Identity+Assurance+Certification+Program</a>
</dd></dl>
<p><span id="ref-idlexicon" class="anchor"></span>
</p>
<dl><dt> [IDLEXICON]
</dt><dd> <em>Identity Commons Lexicon</em>. Retrieved October 26th 2010.  Available at <a href="http://wiki.idcommons.net/Lexicon" class="external free" title="http://wiki.idcommons.net/Lexicon">http://wiki.idcommons.net/Lexicon</a>.
</dd></dl>

<p><span id="ref-imi" class="anchor"></span>
</p>
<dl><dt> [IMI]
</dt><dd> <em>Identity Metasystem Interoperability Version 1.0 (IMI)</em>,  M. Jones and M. McIntosh. OASIS Standard. July 1st 2009. Available at <a href="http://docs.oasis-open.org/imi/identity/v1.0/identity.html" class="external free" title="http://docs.oasis-open.org/imi/identity/v1.0/identity.html">http://docs.oasis-open.org/imi/identity/v1.0/identity.html</a>

</dd></dl>
<p><span id="ref-infocard" class="anchor"></span>
</p>
<dl><dt> [INFOCARD]
</dt><dd> <em>Infocard</em>. Retrieved October 26th 2010. Available at <a href="http://informationcard.net/" class="external free" title="http://informationcard.net/">http://informationcard.net/</a>.
</dd></dl>

<p><span id="ref-insidefb" class="anchor"></span>
</p>
<dl><dt> [INSIDEFB]
</dt><dd> <em>Facebook Revenues Up to $700 Million in 2009, On Track Towards $1.1 Billion in 2010</em>,  E. Eldon. InsideFacebook, March 2nd 2010. Available at <a href="http://www.insidefacebook.com/2010/03/02/facebook-made-up-to-700-million-in-2009-on-track-towards-1-1-billion-in-2010/" class="external free" title="http://www.insidefacebook.com/2010/03/02/facebook-made-up-to-700-million-in-2009-on-track-towards-1-1-billion-in-2010/">http://www.insidefacebook.com/2010/03/02/facebook-made-up-to-700-million-in-2009-on-track-towards-1-1-billion-in-2010/</a>

</dd></dl>

<p><span id="ref-IRI" class="anchor"></span>
</p>
<dl><dt> [IRI]
</dt><dd><em>Internationalized Resource Identifiers (IRIs)</em>, M. Duerst and M. Suignard. IETF RFC 3987 (Standards Track), January 2005. Available at <a href="http://www.ietf.org/rfc/rfc3987.txt" class="external free" title="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a>
</dd></dl>


<p><span id="ref-jclark" class="anchor"></span>
</p>
<dl><dt> [JCLARK]
</dt><dd> <em>A tour of the open standards used by Google Buzz</em>, J. Clark. February 12th 2010. Available at <a href="http://blog.jclark.com/2010/02/tour-of-open-standards-used-by-google.html" class="external free" title="http://blog.jclark.com/2010/02/tour-of-open-standards-used-by-google.html">http://blog.jclark.com/2010/02/tour-of-open-standards-used-by-google.html</a>

</dd></dl>
<p><span id="ref-jrd" class="anchor"></span>
</p>
<dl><dt> [JRD]
</dt><dd> <em>JRD, the Other Resource Descriptor</em>, E. Hammer-Lahav. May 24th 2010. Available at <a href="http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/" class="external free" title="http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/">http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/</a>
</dd></dl>

<p><span id="ref-jungle" class="anchor"></span>
</p>
<dl><dt> [JUNGLE]
</dt><dd> <em>The Privacy Jungle: On the Market for Data Protection in Social Networks</em>, J. Bonneau and S. Preibusch. In The Eighth Workshop on the Economics of Information Security (WEIS 2009). London, England 24-25th June 2009. Available at <a href="http://preibusch.de/publications/Bonneau_Preibusch__Privacy_Jungle__2009-05-26.pdf" class="external free" title="http://preibusch.de/publications/Bonneau_Preibusch__Privacy_Jungle__2009-05-26.pdf">http://preibusch.de/publications/Bonneau_Preibusch__Privacy_Jungle__2009-05-26.pdf</a>
</dd></dl>

<p><span id="ref-kantara" class="anchor"></span>
</p>
<dl><dt> [KANTARA]
</dt><dd> <em>Kantara Initiative</em>. Retrieved October 26th 2010. Available at <a href="http://kantarainitiative.org" class="external free" title="http://kantarainitiative.org">http://kantarainitiative.org</a>
</dd></dl>

<p><span id="ref-laurie" class="anchor"></span>
</p>
<dl><dt> [LAURIE]
</dt><dd> <em>OpenID: Phishing Heaven</em>,  B. Laurie. January 19th 2007. Available at <a href="http://www.links.org/?p=187" class="external free" title="http://www.links.org/?p=187">http://www.links.org/?p=187</a>
</dd></dl>

<p><span id="ref-likeb" class="anchor"></span>
</p>
<dl><dt> [LIKEB]
</dt><dd> <em>The Facebook Like Button, and how it is following you around the web</em>, M. Tuffield. July 30th 2010. Available at <a href="http://mmt.me.uk/blog/2010/07/30/the-facebook-like-button/" class="external free" title="http://mmt.me.uk/blog/2010/07/30/the-facebook-like-button/">http://mmt.me.uk/blog/2010/07/30/the-facebook-like-button/</a>
</dd></dl>

<p><span id="ref-linked" class="anchor"></span>
</p>
<dl><dt> [LINKED]
</dt><dd> <em>Linked Data</em>, T. Berners-Lee.  July 27th 2006. Available at <a href="http://www.w3.org/DesignIssues/LinkedData.html" class="external free" title="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
</dd></dl>

<p><span id="ref-long" class="anchor"></span>
</p>
<dl><dt> [LONG]
</dt><dd> <em>Long Live the Web: A Call for Continued Open Standards and Neutrality</em>, T. Berners-Lee. Scientific American, December 2010.  Available at <a href="http://www.scientificamerican.com/article.cfm?id=long-live-the-web" class="external free" title="http://www.scientificamerican.com/article.cfm?id=long-live-the-web">http://www.scientificamerican.com/article.cfm?id=long-live-the-web</a>
</dd></dl>


<p><span id="ref-lrdd" class="anchor"></span>
</p>
<dl><dt> [LRDD]
</dt><dd> <em>
LRDD: Link-based Resource Descriptor Discovery</em>, E. Hammer-Lahav. IETF Internet Draft (Informational), 26th October 2010. Available at <a href="http://tools.ietf.org/html/draft-hammer-discovery-06#section-5" class="external free" title="http://tools.ietf.org/html/draft-hammer-discovery-06#section-5">http://tools.ietf.org/html/draft-hammer-discovery-06</a>
</dd></dl>

<p><span id="ref-magic" class="anchor"></span>
</p>
<dl><dt> [MAGIC]
</dt><dd> <em>Magic Signatures</em>, J. Panzer and B. Laurie. Draft specification. February 2010. Available at  <a href="http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html" class="external free" title="http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html">http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html</a>
</dd></dl>

<p><span id="ref-mali" class="anchor"></span>
</p>
<dl><dt> [MALI]
</dt><dd> <em>XAuth: Who Should Know What?</em>, B. Laurie. June 8th 2010. Available at <a href="http://www.links.org/?p=938" class="external free" title="http://www.links.org/?p=938">http://www.links.org/?p=938</a>
</dd></dl>

<p><span id="ref-map" class="anchor"></span>
</p>
<dl><dt> [MAP]
</dt><dd> <em>Map of Geolocations</em>, V. Cosenza. Retrieved 26th October 2010. Available at <a href="http://www.vincos.it/wp-content/uploads/2009/06/wmsn-06-09.png" class="external free" title="http://www.vincos.it/wp-content/uploads/2009/06/wmsn-06-09.png">http://www.vincos.it/wp-content/uploads/2009/06/wmsn-06-09.png</a>
</dd></dl>
<p><span id="ref-metrics" class="anchor"></span>
</p>
<dl><dt> [METRICS]
</dt><dd> <em>The search for appropriate community (service) metrics</em>, C. Perey, July 2009. Available at <a href="http://www.w3.org/2005/Incubator/socialweb/wiki/images/f/f2/Social_networking_metrics_July_2009.pdf" class="external free" title="http://www.w3.org/2005/Incubator/socialweb/wiki/images/f/f2/Social_networking_metrics_July_2009.pdf">http://www.w3.org/2005/Incubator/socialweb/wiki/images/f/f2/Social_networking_metrics_July_2009.pdf</a>
</dd></dl>

<p><span id="ref-microdata" class="anchor"></span>
</p>
<dl><dt> [MICRODATA]
</dt><dd> <em>HTML Microdata</em>, I. Hickson. W3C Working Draft, June 24th 2010. Available at <a href="http://dev.w3.org/html5/md/" class="external free" title="http://dev.w3.org/html5/md/">http://dev.w3.org/html5/md/</a>
</dd></dl>

<p><span id="ref-microformat" class="anchor"></span>
</p>
<dl><dt> [MICROFORMAT]
</dt><dd> <em>Microformats.org</em>  Retrieved October 26th 2010. Available at <a href="http://microformats.org" class="external free" title="http://microformats.org">http://microformats.org</a>
</dd></dl>

<p><span id="ref-micropay" class="anchor"></span>
</p>
<dl><dt> [MICROPAY]
</dt><dd> <em>W3C Micropayment Activity</em>.  Retrieved October 26th 2010. Available at <a href="http://www.w3.org/ECommerce/Micropayments/" class="external free" title="http://www.w3.org/ECommerce/Micropayments/">http://www.w3.org/ECommerce/Micropayments/</a>
</dd></dl>

<p><span id="ref-microstats" class="anchor"></span>
</p>
<dl><dt> [MICROSTATS]
</dt><dd> <em>Google's Semantic Web Push: Rich Snippets Usage Growing</em>, R. MacManus. ReadWriteWeb, June 24th 2010. Available at <a href="http://www.readwriteweb.com/archives/google_semantic_web_push_rich_snippets_usage_grow.php" class="external free" title="http://www.readwriteweb.com/archives/google_semantic_web_push_rich_snippets_usage_grow.php">http://www.readwriteweb.com/archives/google_semantic_web_push_rich_snippets_usage_grow.php</a>
</dd></dl>

<p><span id="ref-msnws" class="anchor"></span>
</p>
<dl><dt> [MSNWS]
</dt><dd> <em>W3C Workshop on the Future of the Social Networking</em>. Retrieved October 26th 2010. Available at <a href="http://www.w3.org/2008/09/msnws/"  title="http://www.w3.org/2008/09/msnws/">http://www.w3.org/2008/09/msnws/</a>
</dd></dl>

<p><span id="ref-nict" class="anchor"></span>
</p>
<dl><dt> [NICT]
</dt><dd> <em>Nice Tag Ontology</em>, A. Monnin, F. Limpens, D. Laniado, and F. Gandon. Retrieved October 26th 2010.  Draft specification. Available at <a href="http://ns.inria.fr/nicetag/2010/09/09/voc#" class="external free" title="http://ns.inria.fr/nicetag/2010/09/09/voc#">http://ns.inria.fr/nicetag/2010/09/09/voc#</a>
</dd></dl>

<p><span id="ref-nigori" class="anchor"></span>
</p>
<dl><dt> [NIGORI]
</dt><dd> <em>Nigori: Storing Secrets in the Cloud</em>, B. Laurie. June 5th 2010. Draft specification. Available at <a href="http://www.links.org/files/nigori-protocol.html" class="external free" title="http://www.links.org/files/nigori-protocol.html">http://www.links.org/files/nigori-protocol.html</a>
</dd></dl>

<p><span id="ref-nyt" class="anchor"></span>
</p>
<dl><dt> [NYT]
</dt><dd> <em>Four Nerds and a Cry to Arms against Facebook</em>, J. Dwyer. New York Times, May 12th 2010. Available at <a href="http://www.nytimes.com/2010/05/12/nyregion/12about.html" class="external free" title="http://www.nytimes.com/2010/05/12/nyregion/12about.html">http://www.nytimes.com/2010/05/12/nyregion/12about.html</a>
</dd></dl>

<p><span id="ref-oauth1" class="anchor"></span>
</p>
<dl><dt> [OAUTH]
</dt><dd> <em>The OAuth 1.0 Protocol</em>, E. Hammer-Lahav. IETF RFC 5849 (Informational). April 2010. Available at <a href="http://tools.ietf.org/html/rfc5849" class="external free" title="http://tools.ietf.org/html/rfc5849">http://tools.ietf.org/html/rfc5849</a>
</dd></dl>

<p><span id="ref-oauth2" class="anchor"></span>
</p>
<dl><dt> [OAUTH2]
</dt><dd> <em>The OAuth 2.0 Protocol</em>, E. Hammer-Lahav, D. Recordon, and D. Hardt. IETF Internet Draft (Standards Track). July 11th 2010. Available at <a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-10" class="external free" title="http://tools.ietf.org/html/draft-ietf-oauth-v2-10">http://tools.ietf.org/html/draft-ietf-oauth-v2-10</a>
</dd></dl>

<p><span id="ref-odrl" class="anchor"></span>
</p>
<dl><dt> [ODRL]
</dt><dd> <em>ODRL 2.0</em>, R. Iannella, H. Hundacker, D. Paehler, A. Kasten, and S. Guth.  Draft specification, October 15th 2010. Available at <a href="http://odrl.net/2.0/DS-ODRL-Model.html" class="external free" title="http://odrl.net/2.0/DS-ODRL-Model.html">http://odrl.net/2.0/DS-ODRL-Model.html</a>
</dd></dl>

<p><span id="ref-odrlu" class="anchor"></span>
</p>
<dl><dt> [ODRLU]
</dt><dd> <em>The use cases in the ODRL language</em>. Retrieved October 26th 2010. Available at <a href="http://odrl.net/wiki/tiki-index.php?page=W3C+Privacy+Rulesets" class="external free" title="http://odrl.net/wiki/tiki-index.php?page=W3C+Privacy+Rulesets">http://odrl.net/wiki/tiki-index.php?page=W3C+Privacy+Rulesets</a>
</dd></dl>

<p><span id="ref-ods" class="anchor"></span>
</p>
<dl><dt> [ODS]
</dt><dd> <em>OpenLink Data Spaces</em>. Retrieved October 26th 2010. Available at <a href="http://ods.openlinksw.com/wiki/ODS/" class="external free" title="http://ods.openlinksw.com/wiki/ODS/">http://ods.openlinksw.com/wiki/ODS/</a>
</dd></dl>

<p><span id="ref-oex" class="anchor"></span>
</p>
<dl><dt> [OEX]
</dt><dd> <em>OExchange</em>. Draft specification, May 14th 2010. Available at <a href="http://www.oexchange.org/spec/" class="external free" title="http://www.oexchange.org/spec/">http://www.oexchange.org/spec/</a>
</dd></dl>

<p><span id="ref-ogp" class="anchor"></span>
</p>
<dl><dt> [OGP]
</dt><dd> <em>Open Graph Protocol</em>, D. Recordon. Draft specification.   26th October 2010. Available at <a href="http://opengraphprotocol.org/" class="external free" title="http://opengraphprotocol.org/">http://opengraphprotocol.org/</a>
</dd></dl>

<p><span id="ref-oidconnect" class="anchor"></span>
</p>
<dl><dt> [OIDCONNECT]
</dt><dd><em>OpenID Connect</em>. Retrieved October 26th 2010. Available at <a href="http://openidconnect.com/" class="external free" title="http://openidconnect.com/">http://openidconnect.com/</a>
</dd></dl>

<p><span id="ref-olike" class="anchor"></span>
</p>
<dl><dt> [OLIKE]
</dt><dd> <em>OpenLike</em>. Retrieved October 26th 2010. Available at <a href="http://openlike.org/" class="external free" title="http://openlike.org/">http://openlike.org/</a>
</dd></dl>

<p><span id="ref-opengraph" class="anchor"></span>
</p>
<dl><dt> [OPENGRAPH]
</dt><dd> <em>Thoughts on the Social Graph</em>, B. Fitzpatrick and D. Recordon. August 2007. Available at <a href="http://bradfitz.com/social-graph-problem/" class="external free" title="http://bradfitz.com/social-graph-problem/">http://bradfitz.com/social-graph-problem/</a>.
</dd></dl>

<p><span id="ref-openid" class="anchor"></span>
</p>
<dl><dt> [OPENID]
</dt><dd> <em>OpenID</em>. Collection of specifications. Retrieved October 26th 2010.  Available at <a href="http://openid.net/developers/specs/" class="external free" title="http://openid.net/developers/specs/">http://openid.net/developers/specs/</a>
</dd></dl>

<p><span id="ref-opensocial" class="anchor"></span>
</p>
<dl><dt> [OPENSOCIAL]
</dt><dd> <em>OpenSocial</em>. Retrieved October 26th 2010. Available at <a href="https://code.google.com/apis/opensocial/" class="external free" title="https://code.google.com/apis/opensocial/">https://code.google.com/apis/opensocial/</a>
</dd></dl>

<p><span id="ref-opo" class="anchor"></span>
</p>
<dl><dt> [OPO]
</dt><dd> <em>Online Presence Ontology Specification (OPO)</em>, M. Stankovic.  Draft specification. May 1st 2009. Available at <a href="http://online-presence.net/opo/spec/" class="external free" title="http://online-presence.net/opo/spec/">http://online-presence.net/opo/spec/</a>
</dd></dl>

<p><span id="ref-oslo" class="anchor"></span>
</p>
<dl><dt> [OSLO]
</dt><dd> <em>OSLO alliance mailing list</em>. Retrieved October 26th 2010. Available at <a href="http://groups.google.com/group/locallies" class="external free" title="http://groups.google.com/group/locallies">http://groups.google.com/group/locallies</a>
</dd></dl>

<p><span id="ref-ostatus" class="anchor"></span>
</p>
<dl><dt> [OSTATUS]
</dt><dd> <em>OStatus</em>. E. Prodromou, B. Vibber, J. Walker, and Z. Copley. Draft Specification, August 30th 2010. Available at <a href="http://ostatus.org/specification" class="external free" title="http://ostatus.org/specification">http://ostatus.org/specification</a>

</dd></dl>
<p><span id="ref-osw" class="anchor"></span>
</p>
<dl><dt> [OSW]
</dt><dd> <em>OneSocialWeb</em>. Retrieved October 26th 2010. Available at <a href="http://onesocialweb.org/" class="external free" title="http://onesocialweb.org/">http://onesocialweb.org/</a>
</dd></dl>

<p><span id="ref-owf" class="anchor"></span>
</p>
<dl><dt> [OWF]
</dt><dd> <em>Open Web Foundation</em>. Retrieved  October 26th 2010. Available at <a href="http://www.openwebfoundation.org/" class="external free" title="http://www.openwebfoundation.org/">http://www.openwebfoundation.org/</a>
</dd></dl>

<p><span id="ref-p3p" class="anchor"></span>
</p>
<dl><dt> [P3P]
</dt><dd> <em>The Platform for Privacy Preferences 1.1 (P3P1.1) Specification</em>, R. Wenning and M. Schunter. W3C Working Group Note, 13 November 2006. Available at <a href="http://www.w3.org/TR/P3P11/" class="external free" title="http://www.w3.org/TR/P3P11/">http://www.w3.org/TR/P3P11/</a>
</dd></dl>

<p><span id="ref-password" class="anchor"></span>
</p>
<dl><dt> [PASSWORD]
</dt><dd> <em>How to implement good password schemes</em>, S. Preibusch. July 29th 2010. Available at <a href="http://www.lightbluetouchpaper.org/2010/07/29/web-password-standards-2/" class="external free" title="http://www.lightbluetouchpaper.org/2010/07/29/web-password-standards-2/">http://www.lightbluetouchpaper.org/2010/07/29/web-password-standards-2/</a>
</dd></dl>

<p><span id="ref-pays" class="anchor"></span>
</p>
<dl><dt> [PAYS]
</dt><dd> <em>PaySwarm</em>.  Retrieved October 26th 2010. Available at <a href="http://payswarm.com/" class="external free" title="http://payswarm.com/">http://payswarm.com/</a>

</dd></dl>
<p><span id="ref-pep" class="anchor"></span>
</p>
<dl><dt> [PEP]
</dt><dd> <em>Personal Eventing Protocol</em>, L. Eschenauer. Draft specification, April 9th 2010. Available at <a href="http://onesocialweb.org/spec/1.0/osw-inbox.html" class="external free" title="http://onesocialweb.org/spec/1.0/osw-inbox.html">http://onesocialweb.org/spec/1.0/osw-inbox.html</a>

</dd></dl>
<p><span id="ref-pew" class="anchor"></span>
</p>
<dl><dt> [PEW]
</dt><dd> <em>Teens, Privacy and Online Social Networks </em>, A. Lenhart and M. Madden. Pew Internet and American Life Project, April 18th 2007. Available at <a href="http://www.pewinternet.org/Reports/2007/Teens-Privacy-and-Online-Social-Networks.aspx" class="external free" title="http://www.pewinternet.org/Reports/2007/Teens-Privacy-and-Online-Social-Networks.aspx">http://www.pewinternet.org/Reports/2007/Teens-Privacy-and-Online-Social-Networks.aspx</a>
</dd></dl>

<p><span id="ref-port" class="anchor"></span>
</p>
<dl><dt> [PORT]
</dt><dd> <em>Portable Contacts 1.0</em>, J. Smarr.  Draft specification, August 5th 2008. Available at <a href="http://portablecontacts.net/draft-spec.html" class="external free" title="http://portablecontacts.net/draft-spec.html">http://portablecontacts.net/draft-spec.html</a>
</dd></dl>

<p><span id="ref-powder" class="anchor"></span>
</p>
<dl><dt> [POWDER]
</dt><dd> <em>Protocol for Web Description Resources (POWDER): Description Resources</em>, P. Archer, K. Smith, and A. Perego. W3C Recommendation, September 1st 2009. Available at <a href="http://www.w3.org/TR/powder-dr/" class="external free" title="http://www.w3.org/TR/powder-dr/">http://www.w3.org/TR/powder-dr/</a>
</dd></dl>

<p><span id="ref-primelife" class="anchor"></span>
</p>
<dl><dt> [PRIMELIFE]

</dt><dd> <em>PrimeLife Project</em>.  Retrieved October 26th 2010. Available at <a href="http://www.primelife.eu/" class="external free" title="http://www.primelife.eu/">http://www.primelife.eu/</a>
</dd></dl>
<p><span id="ref-privicon" class="anchor"></span>
</p>
<dl><dt> [PRIVICON]
</dt><dd> <em>Privacy Icons</em>. Retrieved October 26th 2010. Available at <a href="https://wiki.mozilla.org/Drumbeat/Challenges/Privacy_Icons" class="external free" title="https://wiki.mozilla.org/Drumbeat/Challenges/Privacy_Icons">https://wiki.mozilla.org/Drumbeat/Challenges/Privacy_Icons</a>
</dd></dl>
<p><span id="ref-prov" class="anchor"></span>
</p>
<dl><dt> [PROV]
</dt><dd> <em>W3C Provenance XG Social Web Use-cases</em>.  Retrieved October 26th 2010. Available at <a href="http://www.w3.org/2005/Incubator/prov/wiki/Social_Web" class="external free" title="http://www.w3.org/2005/Incubator/prov/wiki/Social_Web">http://www.w3.org/2005/Incubator/prov/wiki/Social_Web</a>
</dd></dl>

<p><span id="ref-push" class="anchor"></span>
</p>
<dl><dt> [PUSH]
</dt><dd> <em>Pubsubhubbub Core</em>, B. Fitzpatrick, B. Slatkin, and M. Atkins.  Draft specification, February 8th 2010. Available at <a href="http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html" class="external free" title="http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html">http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html</a>
</dd></dl>


<p><span id="ref-pt" class="anchor"></span>
</p>
<dl><dt> [PT]
</dt><dd> <em>Patent Policy, and patented technologies</em>, D. Brickley. January 29th 2008. Available at <a href="http://danbri.org/words/2008/01/29/266" class="external free" title="http://danbri.org/words/2008/01/29/266">http://danbri.org/words/2008/01/29/266</a>
</dd></dl>

<p><span id="ref-rdf" class="anchor"></span>
</p>
<dl><dt> [RDF]
</dt><dd> <em>Resource Description Framework (RDF): Concepts and Abstract Syntax</em>, G. Klyne and J. Carroll. W3C Recommendation, February 10th 2004. Available at <a href="http://www.w3.org/TR/rdf-concepts/" class="external free" title="http://www.w3.org/TR/rdf-concepts/">http://www.w3.org/TR/rdf-concepts/</a>

</dd></dl>


<p><span id="ref-rdfa" class="anchor"></span>
</p>
<dl><dt> [RDFA]
</dt><dd> <em> RDFa in XHTML: Syntax and Processing</em>, B. Adida, M. Birbeck, S. McCarron, and S. Pemberton. W3C Recommendation, October 14th 2008. Available at <a href="http://www.w3.org/TR/rdfa-syntax/" class="external free" title="http://www.w3.org/TR/rdfa-syntax/">http://www.w3.org/TR/rdfa-syntax/</a>
</dd></dl>

<p><span id="ref-reltag" class="anchor"></span>
</p>
<dl><dt> [RELTAG]
</dt><dd> <em>rel="tag"</em>, T. Celik and K. Marks. Retrieved on October 26th 2010. Available at <a href="http://microformats.org/wiki/rel-tag" class="external free" title="http://microformats.org/wiki/rel-tag">http://microformats.org/wiki/rel-tag</a>

</dd></dl>


<p><span id="ref-rif" class="anchor"></span>
</p>
<dl><dt> [RIF]
</dt><dd> <em>RIF Core Dialect</em>, H. Boley, G. Hallmark, M. Kifer, A. Pashke, A. Polleres, and D. Reynolds. W3C Recommendation, June 22nd 2010. Available at <a href="http://www.w3.org/TR/rif-core/" class="external free" title="http://www.w3.org/TR/rif-core/">http://www.w3.org/TR/rif-core/</a>
</dd></dl>

<p><span id="ref-rogue" class="anchor"></span>
</p>
<dl><dt> [ROGUE]
</dt><dd> <em>MD5 considered harmful today: Creating a rogue CA certificate</em>, A. Sotirov, M. Stevens, J. Appelbaum, A. Lenstra, D. Molnar, D. Arne Osvik, and  B. de Weger. December 30th 2008. Available at <a href="http://www.win.tue.nl/hashclash/rogue-ca/" class="external text" title="http://www.win.tue.nl/hashclash/rogue-ca/">http://www.win.tue.nl/hashclash/rogue-ca/</a>
</dd></dl>

<p><span id="ref-rsa" class="anchor"></span>
</p>
<dl><dt> [RSA]
</dt><dd> <em>
Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</em>, J. Jonsson and B. Kaliski. IETF RFC 3447 (Informational). Available at <a href="http://tools.ietf.org/html/rfc3447" class="external free" title="http://tools.ietf.org/html/rfc3447">http://tools.ietf.org/html/rfc3447</a>
</dd></dl>

<p><span id="ref-ruleset" class="anchor"></span>
</p>
<dl><dt> [RULESET]
</dt><dd> <em>Privacy Ruleset</em>, A. Cooper, J. Morris, and E. Newland. W3C Editor's Draft, October 6th 2010. Available at <a href="http://dev.w3.org/2009/dap/privacy-rulesets/" class="external free" title="http://dev.w3.org/2009/dap/privacy-rulesets/">http://dev.w3.org/2009/dap/privacy-rulesets/</a>
</dd></dl>

<p><span id="ref-salmon" class="anchor"></span>
</p>
<dl><dt> [SALMON]
</dt><dd> <em>The Salmon Protocol</em>, J. Panzer. Draft specification, February 2010. Available at <a href="http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html" class="external free" title="http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html">http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html</a>

</dd></dl>
<p><span id="ref-saml" class="anchor"></span>
</p>
<dl><dt> [SAML]
</dt><dd> <em>The Security Assertion Markup Language (SAML)</em>. Collection of OASIS specifications. Retrieved October 26th 2010. Available at <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security" class="external text" title="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security">http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security</a>
</dd></dl>

<p><span id="ref-scoble" class="anchor"></span>
</p>
<dl><dt> [SCOBLE]
</dt><dd> <em>Facebook Disabled My Account</em>, R. Scoble. January 2008. Available at <a href="http://scobleizer.com/2008/01/03/ive-been-kicked-off-of-facebook/" class="external free" title="http://scobleizer.com/2008/01/03/ive-been-kicked-off-of-facebook/">http://scobleizer.com/2008/01/03/ive-been-kicked-off-of-facebook/</a>.
</dd></dl>

<p><span id="ref-sioc" class="anchor"></span>
</p>
<dl><dt> [SIOC]
</dt><dd> <em>SIOC Core Ontology Specification</em>, U. Bojars and J. Breslin.  Draft specification, March 25th 2010. Available at <a href="http://sioc-project.org/ontology" class="external free" title="http://sioc-project.org/ontology">http://sioc-project.org/ontology</a>
</dd></dl>

<p><span id="ref-smob" class="anchor"></span>
</p>
<dl><dt> [SMOB]
</dt><dd> <em>Semantic MicroBlogging (SMOB)</em>. Retrieved October 26th 2010. Available at <a href="http://smob.me/" class="external free" title="http://smob.me/">http://smob.me/</a>
</dd></dl>

<p><span id="ref-sr" class="anchor"></span>
</p>
<dl><dt> [SR]
</dt><dd> <em>Social Relationships</em>, L. Eschenauer. Draft specification, February 2nd 2010. Available at <a href="http://onesocialweb.org/spec/1.0/osw-relations.html" class="external free" title="http://onesocialweb.org/spec/1.0/osw-relations.html">http://onesocialweb.org/spec/1.0/osw-relations.html</a>

</dd></dl>
<p><span id="ref-statusnet" class="anchor"></span>
</p>
<dl><dt> [STATUSNET]
</dt><dd> <em>StatusNet</em>. Retrieved October 26th 2010. Available at <a href="http://status.net/" class="external free" title="http://status.net/">http://status.net/</a>
</dd></dl>

<p><span id="ref-sw" class="anchor"></span>
</p>
<dl><dt> [SW]
</dt><dd> <em>Semantic Web</em>.  Retrieved October 26th 2010. Available at <a href="http://www.w3.org/2001/sw/" class="external free" title="http://www.w3.org/2001/sw/">http://www.w3.org/2001/sw/</a>
</dd></dl>

<p><span id="ref-swat0" class="anchor"></span>
</p>
<dl><dt> [SWAT0]
</dt><dd> <em>Social Web Acid Test</em>.  Retrieved October 26th 2010. Available at <a href="http://federatedsocialweb.net/wiki/SWAT0" class="external free" title="http://federatedsocialweb.net/wiki/SWAT0">http://federatedsocialweb.net/wiki/SWAT0</a>
</dd></dl>

<p><span id="ref-sync" class="anchor"></span>
</p>
<dl><dt> [SYNC]
</dt><dd> <em>Sync plugin</em>.  Retrieved October 26th 2010.   Available at <a href="http://mozillalabs.com/sync/" class="external free" title="http://mozillalabs.com/sync/">http://mozillalabs.com/sync/</a>
</dd></dl>

<p><span id="ref-tagcommons" class="anchor"></span>
</p>
<dl><dt> [TAGCOMMONS]
</dt><dd> <em>TagCommons</em>.   Retrieved October 26th 2010. Available at <a href="http://www.tagcommons.org" class="external free" title="http://www.tagcommons.org">http://www.tagcommons.org</a>
</dd></dl>

<p><span id="ref-tbl1989" class="anchor"></span>
</p>
<dl><dt> [TBL1989]
</dt><dd> <em>Information Management: A Proposal</em>, T. Berners-Lee. March 1989.  Available at <a href="http://www.w3.org/History/1989/proposal.html" class="external free" title="http://www.w3.org/History/1989/proposal.html">http://www.w3.org/History/1989/proposal.html</a>
</dd></dl>

<p><span id="ref-tbl1994" class="anchor"></span>
</p>
<dl><dt> [TBL1994]
</dt><dd> <em>Plenary at WWW Geneva 94</em>, T. Berners-Lee. 1994.  Available at <a href="http://www.w3.org/Talks/WWW94Tim/" class="external free" title="http://www.w3.org/Talks/WWW94Tim/">http://www.w3.org/Talks/WWW94Tim/</a>
</dd></dl>


<p><span id="ref-tbl2009" class="anchor"></span>
</p>
<dl><dt> [TBL2009]
</dt><dd> <em>Socially Aware Cloud Computing</em>, T. Berners-Lee. August 17th 2009. Available at <a href="http://www.w3.org/DesignIssues/CloudStorage.html" class="external free" title="http://www.w3.org/DesignIssues/CloudStorage.html">http://www.w3.org/DesignIssues/CloudStorage.html</a>
</dd></dl>

<p><span id="ref-tls" class="anchor"></span>
</p>
<dl><dt> [TLS]
</dt><dd> <em>The Transport Layer Security (TLS) Protocol Version 1.2</em>, T. Dierks and E. Rescorla. IETF RFC 5246 (Standards Track).  August 2008. Available at <a href="http://tools.ietf.org/html/rfc5246" class="external free" title="http://tools.ietf.org/html/rfc5246">http://tools.ietf.org/html/rfc5246</a>
</dd></dl>

<p><span id="ref-tos" class="anchor"></span>
</p>
<dl><dt> [TOS]
</dt><dd> <em>Terms of Service Tracker</em>. Retrieved October 26th 2010.  Available at <a href="http://www.tosback.org/timeline.php" class="external free" title="http://www.tosback.org/timeline.php">http://www.tosback.org/timeline.php</a>
</dd></dl>

<p><span id="ref-uri" class="anchor"></span>
</p>
<dl><dt> [URI]
</dt><dd> <em>Uniform Resource Identifier (URI): Generic Syntax
</em>, T. Berners-Lee, R. Fielding, and L. Masinter. IETF RFC 3986 (Standards Track), January 2005. Available at <a href="http://www.ietf.org/rfc/rfc3986.txt" class="external free" title="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
</dd></dl>

<p><span id="ref-usa" class="anchor"></span>
</p>
<dl><dt> [USA]
</dt><dd> <em>Fact Sheet for National Strategy for Trusted Identities in Cyberspace</em>. White House Press Release, June 25th 2010. Available at <a href="http://www.whitehouse.gov/the-press-office/fact-sheet-national-strategy-trusted-identities-cyberspace" class="external free" title="http://www.whitehouse.gov/the-press-office/fact-sheet-national-strategy-trusted-identities-cyberspace">http://www.whitehouse.gov/the-press-office/fact-sheet-national-strategy-trusted-identities-cyberspace</a>
</dd></dl>

<p><span id="ref-vcard3" class="anchor"></span>
</p>
<dl><dt> [VCARD3]
</dt><dd><em>vCard MIME Directory Profile</em>, F. Dawson and T. Howes. IETF RFC 2426 (Standards Track), September 1998. Available at <a href="http://www.ietf.org/rfc/rfc2426.txt" class="external free" title="http://www.ietf.org/rfc/rfc2426.txt">http://www.ietf.org/rfc/rfc2426.txt</a>
</dd></dl>

<p><span id="ref-vcard4" class="anchor"></span>
</p>
<dl><dt> [VCARD4]
</dt><dd> <em>vCard Format Specification</em>,  S. Perreault and P. Resnick. IETF Internet Draft (Standards Track). August 2nd 2010. Available at <a href="http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13" class="external free" title="http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13">http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13</a>
</dd></dl>

<p><span id="ref-vcard4xml" class="anchor"></span>
</p>
<dl><dt> [VCARD4XML]
</dt><dd> <em>vCard XML Representation</em>,  S. Perreault. IETF Internet Draft (Standards Track). August 2nd 2010. Available at <a href="http://www.ietf.org/id/draft-ietf-vcarddav-vcardxml-05.txt" class="external free" title="http://www.ietf.org/id/draft-ietf-vcarddav-vcardxml-05.txt">http://www.ietf.org/id/draft-ietf-vcarddav-vcardxml-05.txt</a>
</dd></dl>

<p><span id="ref-vcardrdf" class="anchor"></span>
</p>
<dl><dt> [VCARDRDF]
</dt><dd> <em>Representing vCard Objects in RDF</em>, H. Halpin,  R. Iannella,  B. Suda, and N. Walsh. W3C Member Submission, January 10th 2010. Available at <a href="http://www.w3.org/Submission/vcard-rdf/" class="external free" title="http://www.w3.org/Submission/vcard-rdf/">http://www.w3.org/Submission/vcard-rdf/</a>
</dd></dl>

<p><span id="ref-vcardxmpp" class="anchor"></span>
</p>
<dl><dt> [VCARDXMPP]
</dt><dd><em>vCard4 over XMPP</em>, L. Eschenauer.  Draft specification. April 4th 2009. Available at <a href="http://onesocialweb.org/spec/1.0/osw-vcard4.html" class="external free" title="http://onesocialweb.org/spec/1.0/osw-vcard4.html">http://onesocialweb.org/spec/1.0/osw-vcard4.html</a>
</dd></dl>

<p><span id="ref-vochost" class="anchor"></span>
</p>
<dl><dt> [VOCHOST]
</dt><dd> <em>Vocabulary Hosting</em>, H. Halpin and T. Baker.  In the AAAI Spring Symposium on Linked Data Meets Artificial Intelligence (LINKED-AI 2010). Palo Alto, United States of America, 22-24th March 2010. Available at <a href="http://www.aaai.org/ocs/index.php/SSS/SSS10/paper/download/1140/1450" class="external free" title="http://www.aaai.org/ocs/index.php/SSS/SSS10/paper/download/1140/1450">http://www.aaai.org/ocs/index.php/SSS/SSS10/paper/download/1140/1450</a>
</dd></dl>

<p><span id="ref-webfinger" class="anchor"></span>
</p>
<dl><dt> [WEBFINGER]
</dt><dd> <em>Webfinger</em>. Retrieved October 26th 2010.  Draft specification. Available at <a href="http://code.google.com/p/webfinger/wiki/WebFingerProtocol" class="external free" title="http://code.google.com/p/webfinger/wiki/WebFingerProtocol">http://code.google.com/p/webfinger/wiki/WebFingerProtocol</a>
</dd></dl>

<p><span id="ref-webid" class="anchor"></span>
</p>
<dl><dt> [WEBID]
</dt><dd> <em>WebID: Web Identification and Discovery</em> M. Sporny, S. Corlosquet, T. Inkster, H. Story, B. Harbulot, and R. Bachmann-Gmur.  Draft specification, August 9th 2010. Available at <a href="http://webid.info/spec/" class="external free" title="http://webid.info/spec/">http://webid.info/spec/</a>
</dd></dl>

<p><span id="ref-weblinking" class="anchor"></span>
</p>
<dl><dt> [WEBLINKING]
</dt><dd> <em>Web Linking</em>, M. Nottingham. IETF RFC 5988 (Standards Track). October 2010. Available at <a href="http://tools.ietf.org/html/draft-nottingham-http-link-header-10" class="external free" title="http://tools.ietf.org/html/draft-nottingham-http-link-header-10">http://tools.ietf.org/html/draft-nottingham-http-link-header-10</a>
</dd></dl>

<p><span id="ref-wellknown" class="anchor"></span>
</p>
<dl><dt> [WELLKNOWN]
</dt><dd> <em>Defining Well-Known URIs</em>, M. Nottingham and E. Hammer-Lahav. IETF RFC 5785 (Standards Track), April  2010. Available at <a href="http://tools.ietf.org/html/rfc5785" class="external free" title="http://tools.ietf.org/html/rfc5785">http://tools.ietf.org/html/rfc5785</a>
</dd></dl>

<p><span id="ref-widgets" class="anchor"></span>
</p>
<dl><dt> [WIDGETS]
</dt><dd> <em>Widget Packaging and Configuration</em>, M. Cáceres. W3C Working Draft, October 5th 2010. Available at <a href="http://www.w3.org/TR/widgets/" class="external free" title="http://www.w3.org/TR/widgets/">http://www.w3.org/TR/widgets/</a>
</dd></dl>

<p><span id="ref-wookie" class="anchor"></span>
</p>
<dl><dt> [WOOKIE]
</dt><dd> <em>Apache Wookie (incubating)</em>.  Retrieved October 26th 2010. Available at <a href="http://incubator.apache.org/wookie/" class="external free" title="http://incubator.apache.org/wookie/">http://incubator.apache.org/wookie/</a>
</dd></dl>

<p><span id="ref-xacml" class="anchor"></span>
</p>
<dl><dt> [XACML]
</dt><dd> <em>eXtensible Access Control Markup Language (XACML)</em>. Collection of OASIS specifications.  Retrieved October 26th 2010. Available at <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml" class="external free" title="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml">http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml</a>
</dd></dl>

<p><span id="ref-xauth" class="anchor"></span>
</p>
<dl><dt> [XAUTH]
</dt><dd> <em>XAuth Spec</em>. Draft specification. Retrieved October 26th 2010. Available at <a href="http://xauth.org/spec/" class="external free" title="http://xauth.org/spec/">http://xauth.org/spec/</a>
</dd></dl>

<p><span id="ref-xauthc" class="anchor"></span>
</p>
<dl><dt> [XAUTHC]
</dt><dd> <em>XAuth – a Terrible, Horrible, No Good, Very Bad Idea</em>, E. Hammer-Lahav. June 5th 2010. Available at <a href="http://hueniverse.com/2010/06/xauth-a-terrible-horrible-no-good-very-bad-idea/" class="external free" title="http://hueniverse.com/2010/06/xauth-a-terrible-horrible-no-good-very-bad-idea/">http://hueniverse.com/2010/06/xauth-a-terrible-horrible-no-good-very-bad-idea/</a>
</dd></dl>

<p><span id="ref-xauthd" class="anchor"></span>
</p>
<dl><dt> [XAUTHD]
</dt><dd> <em>XAuth is a lot like democracy</em>, J. Panzer. June 6th 2010. Available at <a href="http://www.abstractioneer.org/2010/06/xauth-is-lot-like-democracy.html" class="external free" title="http://www.abstractioneer.org/2010/06/xauth-is-lot-like-democracy.html">http://www.abstractioneer.org/2010/06/xauth-is-lot-like-democracy.html</a>
</dd></dl>

<p><span id="ref-xfn" class="anchor"></span>
</p>
<dl><dt> [XFN]
</dt><dd> <em>XHTML Friends Network (XFN)</em>, T. Celik, M. Mullenweg, and E. Meyer. Retrieved October 26th 2010. Available at <a href="http://gmpg.org/xfn/11" class="external free" title="http://gmpg.org/xfn/11">http://gmpg.org/xfn/11</a>
</dd></dl>

<p><span id="ref-xmlds" class="anchor"></span>
</p>
<dl><dt> [XMLDS]
</dt><dd> <em>XML Signature Syntax and Processing</em>, D. Eastlake, J. Reagle, D. Solo, F. Hirsh, and T. Roessler. W3C Recommendation, June 10th 2008. Available at <a href="http://www.w3.org/TR/xmldsig-core/" class="external free" title="http://www.w3.org/TR/xmldsig-core/">http://www.w3.org/TR/xmldsig-core/</a>
</dd></dl>


<p><span id="ref-xmpp" class="anchor"></span>
</p>
<dl><dt> [XMPP]
</dt><dd> <em>Extensible Messaging and Presence Protocol (XMPP): Core</em>, P. Saint-Andre. IETF RFC 3920 (Standards Track). Available at <a href="http://www.ietf.org/rfc/rfc3920.txt" class="external free" title="http://www.ietf.org/rfc/rfc3920.txt">http://www.ietf.org/rfc/rfc3920.txt</a>
</dd></dl>

<p><span id="ref-xmppf" class="anchor"></span>
</p>
<dl><dt> [XMPPF]
</dt><dd> <em>XMPP Standards Foundation</em>. Retrieved October 26th 2010. Available at <a href="http://xmpp.org/xsf/" class="external free" title="http://xmpp.org/xsf/">http://xmpp.org/xsf/</a>
</dd></dl>


<p><span id="ref-xpubsub" class="anchor"></span>
</p>
<dl><dt> [XPUBSUB]
</dt><dd> <em>XEP-0060: Publish-Subscribe</em>, P. Millard, P. Saint-Andre, and R. Meijer. XMPP Standards Foundation Draft (Standards Track). July 12th 2010. Available at <a href="http://xmpp.org/extensions/xep-0060.html" class="external free" title="http://xmpp.org/extensions/xep-0060.html">http://xmpp.org/extensions/xep-0060.html</a>
</dd></dl>

<p><span id="ref-xrd" class="anchor"></span>
</p>
<dl><dt> [XRD]
</dt><dd> <em>Extensible Resource Descriptor (XRD) Version 1.0</em>, E. Hammer-Lahav and W. Norris. OASIS Standard, November 1st 2010. Available at <a href="http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html" class="external free" title="http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html">http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html</a>
</dd></dl>

</div>
</body>
</html>