Extended Identity for Social Networks

Transcription

1 Extended Identity for Social Networks Antonio Tapiador, Antonio Fumero, and Joaquín Salvachúa Universidad Politécnica de Madrid, ETSI Telecomunicación, Avenida Complutense 30, Madrid, Spain Abstract. Nowadays we are experiencing the consolidation of social networks (SN). Although there are trends trying to integrate SN platforms. they remain as data silos between each other. Information can't be exchanged between them. In some cases, it would be desirable to connect this scattered information, in order to build a distributed identity. This contribution proposes an architecture for distributed social networking. Based on distributed user-centric identity, our proposal extends it by attaching user information. It also bridges the gap between distributed identity and distributed publishing capabilities. Keywords: WWW, social networks, social software, digital identity, architecture. 1 Introduction Social networks (SN) is one of the key words when we talk about the Web 2.0 realm. We are experiencing nowadays the consolidation of the SN platforms. The recent launching of the Facebook platform has officially opened up the opportunity for issuing the next wave of value added applications for the next generation SN platforms. When we talk about SN in general terms, we are considering a wide scope of web services ranging basically between content and contact oriented social networks, that could be understood as wide and narrow sense social networks. The former are platforms which main goal is content publication, and social relations are a side effect of the interactions. The last are specialized on contacts creation and management, and so they are social networks in a narrow sense. The trend seems to have the contact oriented platforms integrating content sharing services, being Facebook again the best example. Meanwhile we still have in place a lot of independent, isolated content sharing services (e.g. Flickr, blip.tv, Youtube, Slideshare) and contact management centered social networks (e.g. Xing, LinkedIn) we'll be using for a while. The social networking services scenario is living a consolidation stage in terms of platforms (e.g. Xing A.G. has acquired the two major professional networks in Spain) and, at the same time, with the announcement of the Open Social initiative from Google, all the actors in such a scenario are positioning themselves for starting the race for that value added services. At this time, we have the Web plenty of a wide offer of social network services. Users develop their personal or professional activities in different platforms. A user J.G. Breslin et al. (Eds.): BlogTalk 2008/2009, LNCS 6045, pp , Springer-Verlag Berlin Heidelberg 2010

2 Extended Identity for Social Networks 163 may use a blogging platform to express her thoughts, a photo platform to publish her images, and a social network platform to be in contact with her friends. But all these platforms ignore the activity the same user is developing in the rest of web sites. This is sometimes desirable for privacy reasons, but in other multiple cases interoperability is an added value. Things would be easier if images show available in the blogging platform to be integrated within posts, and last posts appear in the social network user's profile. This contribution describes an architecture for distributed SN that supports this interoperability. It proposes a distributed model for contacts and content integration. It's is build around distributed user-centric identity frameworks, such as OpenID. 2 Distributed Identity Such 'new age' services will be depending on the basic functionalities we will be delivering from our open platforms. One of the key functionalities of such platforms is the identity. We are still using as de-facto standard the ancient user/pass combination for identifying ourselves on them. As we have a lot of different services appearing on the Web 2.0 explosion, we have to manage not only a lot of different passwords for a variety of services, but a growing number of different profiles in a series of distributed platforms all around the world. This situation represents a fragmentation of user activity along all the SNs. There isn't a coherence between different user's profiles created in every SN. Furthermore, there is no way to combine digital contents created on every platform. Current scenario can be desirable for privacy reasons. Sometimes we don't want our activities traced and bound between every place we log in. But other times, Fig. 1. Digital identity is distributed among SN platforms

3 164 A. Tapiador, A. Fumero, and J. Salvachúa specially when we want to build a coherent identity and reputation, such interoperability would make things easier. In these cases, from the user point-of-view, it will be desirable to have one single profile that could be validated against any service she would be accessing. The decentralized, user-centric, soft identity schemes are a way of implementing such a requirement. The most popular of these schemes is OpenID [1]. It's being implemented within the main development communities of the Web 2.0, e.g. Wordpress or Blogger from blogging platforms segment. Some security problems [2] have been identified, so a different kind of decentralized, user-centric identity framework should be used in cases where the security requirements are harder. 3 Architecture for Extended Identity The idea behind our proposal is the qualitative leap that entails using a dereferenceable IDs, like OpenID. Until now, using a new SN platform implies providing a login and a password. In most cases, an address is also required. The address will be verified by the web site, which sends an including a link that will confirm the validity of the address. If we analyze the information the SN platform has about us at this point, it is limited to some credentials to authenticate in the web site, and an address to contact with the user. On the other hand, we have authentication frameworks like OpenID. In these frameworks, we provide the SN platform with a dereferenceable ID, that is, an URI representing a resource that can be located and fetched. If the SN platform can dereference the ID, then it will be able to obtain extended information from it. Upon an OpenID URI we are able to get an HTML document, which can contain a lot of information about the user. We can use this ID for registering ourselves in a whole bunch of web services. These web services could include blogging, photo, slide, video sharing services, and narrow sense social networking services. Those service obtain more information about usdereferencing the ID, and discovering information attached to it. We also incorporate information back from web services to the ID. In such a way, we are able to connect information to sites. We will, for instance, allow our blog to know where our photos are (or some of them) or our friends knowing where are our videos are. 3.1 Architecture Components Our proposed architecture is client-server solution, and it is composed by three elements: Client Agents, Identity Servers and Resources Servers. Client Agent. A client agent (CA) is any application environment in a local machine or device controlled by a user. Examples of CA are mobile applications and browsers running in a PC. Network connection is assumed. The environment where the CA is running can provide it with API facilities such as authentication, resources fetching or content publishing. Identity Server. An identity server (IS) provides users with user-centric, decentralized IDs belonging to a given identity framework. Users authenticate with their IS and then have a mechanism for identifying themselves in the rest of SN platforms.

4 Extended Identity for Social Networks 165 It is an "OpenID Provider" in the OpenID world, with extended capabilities. It also supports mechanisms for allowing other parties to access private resources, using protocols like OAuth [3]. The IS acts as a user proxy. It stores the main, authoritative user profile. This profile is composed by links to user resources (such as presence, geo-localization, personal data) and collections (e.g. contacts lists, blogs, albums, podcasts). It also may provide information to edit these resources and post new resources to collections. Fig. 2. Example of the described architecture, including a client agent, a identity server and two resources servers Profile information is controlled by access control lists. Users control granting or restricting access to their resources and collections stored in the IS. The IS should provide mechanisms to manage different profile data sets easily. Users typically want to show different kinds of profile to different SNs. We want to provide the minimum required information to some SNs, but detailed information to other trusted SNs. This is also the case for other IDs apart from ours. Other users are expected to query IS to obtain more information about somebody when they discover her ID and want to know more about that person. The IDs should be, therefore, dereferenceable URIs. CAs obtain the main or favorite editable resources and collections. When the user logs into her IS using the CA, she obtains not only authentication capabilities, but also publish information usable by the CA. This information facilitates the CA to write blog entries, post photos or videos, even in other SN platforms. These are the resources servers.

5 166 A. Tapiador, A. Fumero, and J. Salvachúa Resources server. A resources server (RS) is any web service providing resources management. Examples of RS are content oriented web services (e.g. blogs, podcasts, social bookmarking), but also contact oriented ones. We can also think contacts as resources. Any SN platform can be a RS if it allows users to sign up and posting resources. RS supports authentication using a distributed identity framework. It is a "Relaying Party" in the OpenID world. They relay authentication in ISs. A user sings up into a RS using the identity framework provided by her IS. At this step, she selects which kind of profile she will show to this new RS. Then the RS obtains profile information from the user by querying the IS. RS publish resource collections owned by users, like IS may do. CAs obtain from each RS a complete list of user information generated from the user in this specific RS. Users can bookmark this information in their IS, controlling who can access them. This way, they build their authoritative and main profile, which resides in her IS. The user also controls in the IS which information (e.g. collections and resources) show to other RSs. In this way, RSs can discover and mashup resources and collections from their users. Access to RS resources is controlled by the the RS itself. There may be resources announced at the IS but not accessible at the RS and vice-versa. Synchronization between IS ACLs and RS ACLs should be specified. 4 Information Flows The main information attached to a user of this architecture is composed by his ID, along with the resources and collections associated with it. The ID is entered by the user when logging in the RS, which discovers the IS location, as we explained before. This procedure is described in the specification of the OpenID protocol [1]. Later, there may be exchanges of information between the IS and the RSs, which have two ways, from the RS point of view. 4.1 Pull The RS obtains more information about the ID asking the IS. This allows the SN platforms to know more about the user, finding out the latest entries in her blog or her contacts network, for example. The following technologies currently support this information exchanges. OpenID Attribute Exchange. OpenID Attribute Exchange [4] is an OpenID protocol extension that supports the exchange of key-value pairs between the Relaying Party (the RS in our architecture) and the Identity Provider (the IS). This technique is limited by the format of the attributes. HTML. OpenID identifiers are typically HTTP URLs. The RS can dereference the URL and get the HTML document. This document provides information about the ID. Two different formats are available: 1. Microformats [5] are semi-structured information embedded in the HTML markup. Currently, there are formats defined for personal cards (hcard), events (hcalendar) and tags (rel-tag). Other object types are in the definition process.

6 Extended Identity for Social Networks HEAD links: the HTML <head> section provides support for <link> tags. These tags are already used for providing extended information about the HTML document, e.g. blog suscriptions in RSS or Atom format. Other data formats. The HTTP protocol supports a mechanism for requesting documents in a specific format. This is achieved including the Content-Type header in the request. This mechanism, along with the former of HEAD links, allow us to obtain the representation of the ID in different formats. One example are Atom feeds [6], a format used for content syndication. Other example is RDF (Resource Description Framework) and their schemas (RDFs, OWL), the base of the Semantic Web. FOAF [7] is a RDF based vocabulary used to describe agents (Users, Groups, Organizations) and their attributes. The experimental property foaf:openid supports the association of the user profile information with her ID. SIOC (Semantic Interlinked Online Communities) [8] provides a vocabulary for describing resources and resource collections. 4.2 Push The RS publishes information about the user in her IS. This case is interesting, for example, so the IS gathers the activity the user generates in the SN she participates. OpenID Attribute Exchange. The OpenID extension works in both ways. It can also be used by RSs to store key-value pairs in the IS. Atom Publishing Protocol. AtomPub [9] is a protocol designed by the IETF for publishing and editing web resources. One of the documents defined by the specification are Service documents. Service documents describe available Collections grouped in Workspaces. Collections are sets of resources. The Service document describes what kind of resources can be posted to a Collection. AtomPub can be extended, so Collections could also describe which kind of resources contains, for a better integration with CA publishing and management capabilities of the resources. 5 Validation OpenSocial [10] is one of the last technologies emerging in social software. OpenSocial is a public API launched by Google in late It provides management support on three kinds of resources attached to user's personal information; contacts, activities in SN platforms and persistent data support. OpenSocial proposal fits smoothly in our architecture model. In OpenSocial, user's contacts and activities are exported using Atom feeds. Activities publishing uses the Atom protocol. Finally, persistent data support shares the same principles with OpenID Attribute Exchange extension. To achieve a practical validation of the architecture, we are working on a plugin [11] for Ruby on Rails web development framework. This plugin provides an application with an authentication framework, supporting several authentication schemes including OpenID. It also provides authorization and contents and contact generation. We plan to evaluate the technologies mentioned in the previous section that support information exchanges between IS and RS. This plugin is currently used in several

7 168 A. Tapiador, A. Fumero, and J. Salvachúa SN platforms, which include the VCC [12] a rich web content management system that gives support to conferences. 6 Conclusions This article proposes an architecture that solves the problem of fragmented user identities on SN platforms. The architecture is based in OpenID, a user-centric distributed identity framework. The IS stores the authoritative user information. The RSs use the IS to obtain the extended identity about the users, as well as publishing new information about user's activities. There are currently several technologies supporting information flows among IS and RS. In this sense, we are working on a Ruby on Rails plugin supporting several of this technologies. This plugin is used as the base of SN platforms that will validate the proposed architecture. Finally, the proposed architecture fits with the last protocols emerging in the field, such as Google's Social API. References 1. Recordon, D., Reed, D.: OpenID 2.0: a Platform for User-Centric Identity Management. In: Proceedings of the second ACM workshop on Digital identity management, pp (2006) 2. Brands, S.: The problem(s) with OpenID, 3. OAuth, An open protocol to allow secure API authentication in a simple and standard method from desktop and web applications, 4. Hart, D., Bufu, J., Hoyt, J.: OpenID Attribute Exchange 1.0 Final, 5. Khare, R.: Microformats: the next (small) thing on the semantic Web? IEEE Internet Computing 10(1), (2006) 6. Nottingham, M., Sayre, R.: The Atom Syndication Format, RFC 4287 (2005), 7. Brickley, D., Miller, L.: FOAF Vocabulary Specification (2007), 8. Semantic Interlinked Online Communities, 9. Gregorio, J., de hora, B.: The Atom Publishing Protocol. RFC 5023 (2007), OpenSocial, Rails Station Engine, Virtual Conference Center,