INTERNET-DRAFT Varun Srivastava Citrix R&D India. March 2007 Expires: October 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 human meetings and dating websites using other Social Networking Internet resources. Document proposes a modular design for dating websites and similar application on Internet. Architecture proposes application specific search as well as required privacy for the members. Main objective of the architecture is to provide required contact details for searching person without breaching privacy of the registered members. It also proposes an architecture to utilize member profiles from legacy databases and websites as well as other implementations of this architecture. Abbreviation Used IPe Initiating Person TPe Target Person TTL Time to live Varun [Page 1] 1 Introduction Currently websites like Orkut[orkut], Facebook[facebook] etc incourage social networking, but they lack requirement specific search, verification of information, feedback mechanism,and other websites data usage model. They allow user to customise its private and public information but there approach has a very fundamental weakness. The fields which they make private become unavailable for search. Objective is that the IPe should not get private information or should not be able to guess private information. To achieve it they make private field unsearchable. But we propose to give only limited search option to IPe instead of cutting down searchable fields. IPe should get all the relevant results (results may become more reliable and specific if we take into account diferent private fields provided by member) but IPe shouldn't be allowed to view private information of TPe. Information what IPe will get is based on internal search by search-tool, but the information revealed for IPe is just what the TPe wanted to convey. Since IPe dont have option to search database based on several fields so he can't modify search according to different parameters to guess the private information of TPe. This on one hand provide 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 people meetings possible and also provide some security for personal data. But they require all the interested person to go through their tedious registration process. Moreover people on one website cannot fix meetings with other website members. They also dont have any mechanism to have any reliability index for its member. A lots of fake profiles exist on these profiles. The architecture proposed here tries to address these problems and provide an extensible infrastructure for meeting fixing and dating websites and tools. 2 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 Every implementation has its own local database (refer section 5) to store TPe and IPe profiles and other information like collaborating websites and databases addresses. Implementation of this architecture should first stablish a secure connection with other databases which desire to collaborate. On the secure channel database should negotiate parametrs like private fields used Varun [Page 2] (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 it can use Search Tool to search 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 that the members which registered are providing correct information or they are fake. It should have feedback mechanism to counter the claims made by members. All verification functions should atleast support protocol described in section 3.1. On top of it they can have support for third party verifications through other members or by some agency. Its totally dependent on the implementor of architecture to make it more realiable 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 ImI with meeting time, TTL, IPe and TPe for which it was generated. ImI should be secret, temporary and should be given only to IPe for which it was generated. After the meeting time ImI should expire after seconds given in TTL. b) If TPe accept the request send by IPe then TPe should be given a temporary unique ID, called TPe meeting ID(TmI). TmI should be unique, random and should have some TTL attached. By default TTL is 86400 seconds. System should store 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 time TmI should expire after seconds given in TTL. By default TTL is 86400 seconds. c) Both TPe and IPe are desired to exchange their dating IDs while meeting. So after the meeting IPe is desired to enter TmI provided by TPe and TPe is desired to enter ImI provided by IPe. System should keep count of how many times members acting as IPe entered correct TmI and while acting as TPe entered correct ImI. Varun [Page 3] d) The count of correct ImI and TmI entered should be used by system to rate and validate member. System may also ask IPe feedback about TPe while entering TmI and vice versa. These additional information may also be used for ranking and increasing members reliability index. 4. Search Tool Search Tool should provide a very limited but powerful search option to members. Member acting as TPe is expected to use seach tool and thats why all the search options and results should be formatted and defined keeping TPe requirements in mind. Each implementation should specify its primary fields and secondary fields used for search. Each Implementation should define its own primary and secondary fields. The databases or websites which acts as feeder to the implementation should first negotiate primary fields. Both feeder database and implementation agrees to colloborate only if they agree on the fields to be used as primary. Primary field search values are matched against the corresponding field values in other members profile. It does not matter whether these fields lie in private or public section of the members profile. Search tool will get a list of profiles after primary search and it will apply secondary field value on the obtained profiles. For secondary search it will match values with the other member's profile fields only if that field is in public secion of the profile. The person searching will get to see only the final result. This will try to ensure that the person searching other member should not be able to use this search tool to get private information of others but still get the improved search using private information. Refer example described in section 4.1 for better understanding of the algorithm. 4.1 An Example of a search using search tool Lets assume we have 3 profiles in our database and the implementation defines age as the primary field. Profile1 phone number044-7128990 age20 nameMary email idjoe@befriend.com meeting placeNewYork Hotel Varun [Page 4] Profile2 nameRyi phone number033-2228990 age20 email idryi@befriend.com meeting placePark Hotel age20 Profile3 nameMary phone number418-4533290 email idmary@befriend.com meeting placepresident garden Now assume a new member use primary field age and name for secondary search and he 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 was private. 5 Database Implementation should have a database of its own to store atleast a) Members profile b) Meeting IDs All person acting as TPe and IPe should have entry in Database. This ensures building up of reliability index and other feedback informations for the members which used the current implementation atleast 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 able of both get polled by other databases for updates and similarly it should have capability of polling other collaborating databases for information. 7 Database Information Exporting Agents The websites and databases having a 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 securily sent over the network. Each implementation should support atleast 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 following XML[xml] based format. First field should be version inside tag. It should have a starting tag as and inside this two and 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 and its value inside . A skeleton exchange file will look like as following. 1.0 This format can be evolved later to make it more robust and schema should be exported in XML Schema[schema] format. 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/ Varun [Page 6] 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 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. Varun Expires October, 2008 [Page 7] 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. Acknowledgement 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.