Internet DRAFT - draft-varun-social-networking
draft-varun-social-networking
INTERNET-DRAFT Varun Srivastava
<draft-varun-social-networking-02.txt> Citrix R&D India.
August 2007
Expires: December 2008
An Architecture for Human Meetings and Dating websites using
other Social Networking Internet resources.
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes an architecture for online meetings and
dating websites. The proposed architecture can use its own profiles
database as well as the other internet based social networking
database resources. The document proposes a modular design for
online meeting and similar kind of applications on Internet. The
architecture proposes an application specific search without
breaching privacy of the registered members. It also proposes to
utilize member profiles from legacy databases and websites as well as
other implementations of this architecture.
Abbreviations Used:
IPe Initiating Person
TPe Target Person
TTL Time to live
Varun [Page 1]
1 Introduction
Currently websites like Orkut [orkut], Facebook [facebook] etc
encourage social networking, but they lack requirement specific
querying, verification of information, feedback mechanism, and other
web resources usage model. They allow user to customize its private
and public information but in process make private fields unavailable
for querying.The objective should be that the IPe should not get
private information or should not be able to guess private
information. To achieve this they make private field unsearchable.
But we propose to give only limited querying option to IPe instead of
cutting down queryable fields. IPe should get all the relevant results
(results may become more reliable and specific if we take into account
different private fields provided by the members) but IPe should not
be allowed to view private information of TPe.
IPe will be able to place queries using an internal search-tool
[which will use all private and public fields to search required data],
but the information revealed, will be just what the TPe would like to
reveal. Since IPe will not have option to query database based on
several fields so he/she will not be able to modify query according
to different parameters, to guess the private information of TPe.
This on one hand provides information security desired by TPe and on
the other hand give much improved results to IPe.
Dating and other online communities like yahoo personal [yahoo] and
friend finder [friend] have tools for making online meetings possible
and also provide some security for personal data. But they require the
interested people to go through their tedious registration process.
Moreover members of one website cannot fix meetings with the members
of other websites. They also don't have any mechanism to have
reliability index for its members. A lot of fake profiles exist on
these websites.
The architecture proposed here tries to address these problems and
provide an extensible infrastructure for online meetings and dating
websites, and tools.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
1. Architecture
Architecture for Human meetings and dating websites have following
components.
1) Verification Function
2) Search Tool
3) Database
4) Database Enriching Tool
5) Database Information Exporting Agents
6) Database Exchange Format
Varun [Page 2]
Every implementation will have its own local database (refer section5)
to store TPe and IPe profiles, and other information like collaborating
websites and databases addresses. Implementation of this architecture
should first establish a secure connection with other databases that
desire to collaborate. On the secure channel, databases should
negotiate parameters like private fields (refer section 4) and if both
units agree then it should have the other website or database as
collaborating database. The exchange of member profiles should happen
on secure channel using Database Exchange Format (refer section 8).
Exchange of profile can be done both proactively or at the time of
search using Database Enriching Tool (refer section 6). Once an IPe's
profile is pulled into local database, IPe can use search-tool to get
desired TPe.Candidate profiles for TPe may be ordered by their
reliability factor (refer section 4).
All the legacy databases and websites desiring to collaborate with
implementations of this architecture should have Database Information
Exporting Agents which can convert member profiles into the
Database Exchange Format.
3. Verification Function
It should validate whether the member who registers, provide genuine
information or not. It should have a feedback mechanism to counter the
claims made by the members. All verification functions should at least
support the protocol described in section 3.1. Additionally, they may
have support third party verifications through other members or by some
agency. It's totally dependent on the implementer of the architecture
to make it more reliable and robust if required.
3.1 Basic Verification Algorithm
Verification function should support following algorithm:
a) When an IPe select TPe for meeting in real world or online,
IPe should be given a temporary unique ID, called IPe meeting
ID (ImI). ImI should be unique, random and should have some TTL
attached. System should store the ImI with meeting time, Time to
live (TTL), IPe and TPe for which it was generated. The ImI should
be secret, temporary and should be given only to IPe for which it
was generated. After the meeting, the ImI should expire after the
seconds given in TTL field.
b) If TPe accept the request send by IPe, then the TPe should be given
a temporary unique ID, called TPe meeting ID (TmI). TmI generated
should be unique, random and should have some Time to live (TTL)
attached. By default TTL will be 86400 seconds. System should store
the TmI with meeting time, TTL, IPe and TPe for which it was
generated. TmI should be secret, temporary and should be given
only to TPe for which it was generated. After the meeting TmI
should expire after the seconds given in TTL. By default TTL is
86400 seconds.
Varun [Page 3]
c) Both TPe and IPe are desired to exchange their meeting IDs when
they meet.
After the meeting, IPe is desired to enter the TmI provided by the
TPe and TPe is desired to enter the ImI provided by the IPe. System
should keep the count of, how many times members acting as IPe
entered the correct TmI, and while acting as TPe entered the
correct ImI received by other participating member.
d) The count of correct ImIs and TmIs entered by members should be
used by the system to prepare the reliability index of the members
and in turn validate them. System may also ask the IPe for feedback
about the TPe, while entering TmI and vice versa. This additional
information may also be used for calculating rank and reliability
index of the members.
4. Search-Tool
Search-Tool should provide a very limited but powerful querying option
to members. Members acting as TPe are expected to use search-tool,
that's why all the querying options and results should be formatted
and defined keeping the TPe requirements in mind.
Each implementation should define its own primary and secondary
fields, used for querying. The databases or websites which act as
feeder to the implementation should first negotiate primary fields.
Both feeder database and implementation should agree to collaborate,
only if they agree on the fields to be used as primary.
Primary field query values are matched against the corresponding
field values in the other member's profile. It does not matter whether
these fields lie in private or public section of the member's profile.
The search-tool will get a list of profiles after primary query, and it
will apply secondary search on the obtained profiles. For secondary
query it will match values with the other member's profile fields, only
if that field is in the public section of the profile.
The person querying, will only see the final result. This is intended
to ensure, that the person querying should not be able to use the
search-tool to get private information of other members in the
database. But the search-tool should still get the improved query
results using private information in the databases.
Refer to the example described in section 4.1 for better
understanding of the algorithm.
Varun [Page 4]
4.1 An Example of a search using search tool
Let's assume we have 3 profiles in our database and the implementation
defines age as the primary field.
Profile1
<private>
<key>phone number</key><value>044-7128990</value>
<key>age</key><value>20</value>
</private>
<public>
<key>name</key><value>Mary</value>
<key>email id</key><value>joe@befriend.com</value>
<key>meeting place</key><value>New York Hotel</value>
</public>
Profile2
<private>
<key>name</key><value>Ryi</value>
<key>phone number</key><value>033-2228990</value>
<key>age</key><value>20</value>
</private>
<public>
<key>email id</key><value>ryi@befriend.com</value>
<key>meeting place</key><value>Park Hotel</value>
</public>
Profile3
<private>
<key>name</key><value>Mary</value>
<key>phone number</key><value>418-4533290</value>
</private>
<public>
<key>email id</key><value>mary@befriend.com</value>
<key>meeting place</key><value>president garden</value>
<key>age</key><value>20</value>
</public>
Now assume a member uses age as primary field and name as secondary
field and he/she gave age=20 and name=Mary. Primary search will fetch
all 3 profiles but secondary search will fetch only Profile1. Notice
Profile3 also has Mary in name field, but it is private.
5 Database
Implementation should have a database of its own to store at least
a) Members profile
b) Meeting IDs
All persons acting as TPe and IPe should have entry to this Database.
This ensures building up of reliability index and other feedback
information for the members who used the current implementation at
least once. So once a person used the facility given by implementation
its profile will be stored in the local database.
6 Database Enriching Tool
Database enriching tool should be able to import data from
collaborating databases and websites. It should have capability
of working in both polling and pushing mode, i.e it should be capable
of being polled by other databases for updates and similarly having
capability of polling other collaborating databases for the
information.
7 Database Information Exporting Agents
The websites and databases having massive amount of members can use
the agents which will export members profile from their database to
Varun [Page 5]
the collaborating implementation of this architecture. Data should be
securely sent over the network. Each implementation should support at
least TLS [RFC4346] for secure information exchange. Information should
be transmitted in Database Exchange Format (refer section 10).
8 Database Exchange Format
Database should be exported in the following XML[xml] based format.
First field should be version inside <version> tag.
It should have a starting tag as <start> and inside this two
<private> and <public> tags on same level. Inside these public
and private tags we can have any field in key-value format. Each
field name should be defined inside <key></key> and its value inside
<value> </value>. A skeleton exchange file will look like as following.
<start>
<version>1.0</version>
<private>
</private>
<public>
</public>
</start>
This format can be evolved later to make it more robust and schema
should be exported in XML Schema[schema] format. Schema for above
defined minimum fields is as follows
<xs:element name="start">
<xs:complexType>
<xs:complexContent>
<xs:element name="version" type="float"/>
<xs:element name="private">
<xs:complextype>
<xs:complexContent>
<xs:sequence>
<xs:element name="key" type="string"/>
<xs:element name="value" type="string"/>
</xs:sequence>
</xs:complexContent>
</xs:complextype>
</xs:element>
<xs:element name="public">
<xs:complextype>
<xs:complexContent>
<xs:sequence>
<xs:element name="key" type="string"/>
<xs:element name="value" type="string"/>
</xs:sequence>
</xs:complexContent>
</xs:complextype>
</xs:element>
</xs:complexContent>
</xs:complextype>
</xs:element>
Varun [Page 6]
9 Security Considerations
This type of process document does not have a direct impact on the
security of the Internet or Internet protocols.
10 IANA Considerations
This document has no actions for IANA
11 References
[orkut] http://www.orkut.com
[facebook] http://www.facebook.com
[yahoo] http://personals.yahoo.com
[friend] http://friendfinder.com
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[xml] http://www.w3.org/XML/
[schema] http://www.w3.org/XML/Schema
12 Informative References
[socialnet]
http://www.genuinevc.com/archives/2006/02/vertical_social.htm
[webdate] http://www.web-date.co.uk/
Authors' Address
Varun Srivastava
Citrix R&D India
The Sirius,
69/3 Millers Road,
Bangalore - 560052.
India.
Telephone +91 (80) 4134000
Mobile +919844783518
Email varun.srivastava@citrix.com
varun.srivastav@gmail.com
Varun Expires December, 2008 [Page 7]
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
