Global Social Graph

Global Social Graph is not a brand new idea, several blogs and articles around social networking and related solutions agree that OpenID and Social Networks are quickly converging. The picture below shows the Asemantics vision of this synergy.



What I'm going to describe is a three level abstract architecture.

At top level we find Social Networks. Some of these, with the promotion of Google, are standardizing their own API to expose contents and services. This standardization is known as Open Social API.

Although this common API, people graphs remain partitioned among different social sites.
The complex of social graphs among social sites is what we call Global Social Site.

At bottom level we find a set of users connected together in real life through relations like friendship or work. These people would like to see the set of relationship they own across several social sites as a unique, harmonized graph;
this is the goal of middle level.

Middle level, what we say Global Social Aggregator is able to access content of social sites using generic adapters, like Open Social Adapter, or specific adapters, written to deal with service specific APIs. Access to users data for any network is granted by OpenID common identity or specific sign-on methods. Collected data is then mashed up by a layer called Global Social API, which provides an abstract interface on social relations. Access to social data is then filtered by the Profile Filter, allowing users to define restricted visibility to their resources. The returned graph is finally converted in one of available formats like FOAF, XNF, JSON or even exposed with an Open Social API built on top of it.

Consumers of Middle level are Social Consumers, i.e. anybody having a digital identity in a social network accessible through an OpenID. Social Consumers use Social browsers to access graph data. A social browser is any instrument, being it a service or a desktop application, able to support at least one of the formats provided by converters in middle tier.

The OpenPlatform Vision

Asemantics is the major implementor of OpenID related technologies in Italian IT scenario.
We have been implemented both Providers and Relying Party solutions.

Company experience can be reassumed in a general architecture that we call OpenPlatform.



The system front-end is load balancer, (usually hardware), distributing
requests on a battery of J2EE Web Containers.
Every Web container is accessed through an Apache Server 2.x used to perform URL rewriting, resource access restrictions and HTTPS support.

Web containers hosts both presentation and REST services.
Presentation layer is based on JSTL solutions. We don't use specific J2EE frameworks, with the exception of an IoC (Inversion of Control) support based on Google Guice.
DAO (Database Access Object) objects are written with iBATIS.

Business Tier lays on persistence and connector layers.

Persistence layers is divided in:

• Storage persistent infrastructure;


• Memory persistent infrastructure.

Storage persistent infrastructure is based on MySQL master-slave replication and is intended to maintain persistent data like User profiles, preferences logs and related.

Memory persihttp://www.blogger.com/img/blank.gifstent infrastructure is based on a Memcached server used to share user session data across Web Containers.

Connector layers provide access to:

• Legacy SSO (Single Sign On) systems;


• Social Networks.

Access to Social Networks is done with Open Social and Social Graph API.
Retrieval of social relations is used to generate FOAF (Friend Of A Friend) profiles exposed in Identity Pages and include user related widgets. With Open Social API
the Identity Page is enabled to work as an Open Social Container.

All the visible attributes of User profile are represented inside Itentity Page with
specific Microformats.

Platform allows an high configurability for Provider users.



The main use case allows user to aithenticate to a Relying Party, this can be done by chosing among several defined profiles.
Every profile maintains different attribute data.
User can modify visibility of attributes shown in Identity Page, visualize and modify preferences about Relying Party access and list access log activities.

OpenID and Reputation Service

A Reputation Service is a service providing reputation informations
on a given user identity, IP or server.

A Reputation Service implements a Reputation System, which definition can be found here: http://en.wikipedia.org/wiki/Reputation_system

Some Reputation Systems provide access to their database by exposing web services.

An example of reputation service platform is http://www.karmasphere.com.

OpenID implementations can be integrated with a Reputation Service to grant an improved user security.

As shown by the following pictures, there are two main integration scenarios for a Reputation Service in the OpenID context:

1. Provider side: an OpenID Provider uses a Reputation Service to report the level of reliability of Relying Parties its user requires to access during
   setup session. It can even reject the login request.
   
   
   



2. Relying Party side: a Relying Party uses a Reputation Service to verify the level of reliability of a OpenID Provider, providing feedback to the user or even deciding to reject the authentication request.
   
   

The third kind of interaction, not considered in this context, is when the user accesses the catalog of a Reputation Service by himself.

Wiki section on Identity Pages

The concept of Wiki doesn't need presentations.

The conceptual idea discussed in this post is the possibility of defining an editable section on the user identity Page, a simple Wiki area.

The Wiki section is just a subset of the content of the entire page, this because the contents of the Identity Page related to declaration of the authentication protocol and the section related to the user data must be unmodifiable by users to guarantee a good level of security and robustness of the system.

The immediate advantages are obvious: the Identity Page will become the baricenter of the user identity, anything that can be represented as a link and embedded in a HTML page, both static or dynamic scripting, is a candidate content of the Wiki Section.

Tipical contents would be:

• link User blog


• link to photo album


• link to social network profile

Expose your FOAF profile!

Still working on Identity Pages.

FOAF stays for Friend Of A Friend, and it is a RDF machine-readable format used
to describe people, activities and relations with other people and resources.

FOAF can be used to describe yourself, friendship, workmate relationship, relations with web entities, etc...

FOAF allows to describe a Social Network without the need to have a central database, in fact every FOAF resource links other resources
distributed over Internet.

More infomations about FOAF here.

Why adopt FOAF?

Main search engines (Google and Yahoo to begin) have started a series of standardization
activities to enable interoperability among Social Networks, ( see SocialGraph).

On the point of view of our Customer, we're dealing with a large pre-existing Community
that has been recently enabled with OpenID profiles and relative Identity Provider service.

We are evaluating the possibility to expose FOAF profiles through user Identity Pages. The FOAF document would be dynamically generated
to represent the interconnections of users inside the Community.

The exposition of the FOAF document would be declared as service of a Yadis manifest.

Yadis is a Service Discovery System allowing Relying Parties (aka identity consumers or membersites) to determine automatically, without end-user intervention, the most appropriate protocol to use for authenticating a user and exchanging data.

To have an overview see: what is Yadis

Microformats in your Identity Page

Microformats

In these days I'm evaluating the impact of adding Microformats in Identity Page
for a OpenID provider implementation developed for a big Italian Company.

Microformats, (abbreviation µF) is an approach to semantic markup meant to reuse
existing HTML and XHTML tags to express metadata.

This approach allows to identify and process in a fully automated way informations intended for final users(business cards, geographic coordinates, calendar events and so on).

Although web page content can be already processed in a fully automated way, Microformats are intended as a bridge to semantically connect data.

Data expressed with Microformats is enabled to be read in a unambiguous way by
browsers and search engines.

Version 3 of Firefor and version 8 on Internet Explorer support natively Microformats.

To know more about Microformats I suggest you Microformats

Integration of Microformats in OpenID identity Pages has a very low impact,
in fact it is just to decide what information expose and then rearrange the HTML page layout.

Considering the kind of data found in an Identity page, the first Microformat cames me to mind is the hcard.

Enabling an Identity Page with hcard will allow you collect personal information data of people you know just browsing it.

Let we start!

This is the first post of my blog on OpenID Tech Ideas.
The purpose of this blog is to collect a set of ideas around OpenID and its strictly related arguments: Social Networking, Security aspects, Multiple Identity Management and so on.
The expected target is to attract a critical mass of people discussing on these ideas and creating something new.

Let us try now...