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 encourage social networking, but they lack requirement specific querying, verification of information, feedback mechanism, and other websites data usage model. They allow user to customize its private and public information but there approach has a very fundamental weakness. The fields which they make private become unavailable for querying. 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 unquerable. But we propose to give only limited querying option to IPe instead of cutting down query able 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 member) but IPe should not be allowed to view private information of TPe. Information what IPe will get is based on internal query by search-tool, but the information revealed for IPe is just what the TPe wanted to convey. Since IPe do not have option to query database based on several fields so he/she can not modify query 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 don't have any mechanism to have any reliability index for its member. A lot of fake profiles exist on these websites. The architecture proposed here tries to address these problems and provide an extensible infrastructure for meeting fixing 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. 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 Varun [Page 2] 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 establish a secure connection with other databases that desire to collaborate. On the secure channel database should negotiate parameters like private fields used (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 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 members who are registering provide correct information or they are fake. It should have feedback a mechanism to counter the claims made by members. All verification functions should at least support the protocol described in section 3.1. On top of it they may have support for third party verifications through other members or by some agency. It's totally dependent on the implementer of 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 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 meeting IDs when they meet. Varun [Page 3] 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 received by other participating member. d) The count of correct ImI and TmI entered should be used by system to prepare reliability index of members and validate them. 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 querying option to members. Because member acting as TPe is expected to use search- tool, all the query options and results should be formatted and defined keeping TPe requirements in mind. Each implementation should define its own primary and secondary fields used for querying. The databases or websites which acts as feeder to the implementation should first negotiate primary fields. Both feeder database and implementation should agre 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 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 query and it will apply secondary field value on the obtained profiles. For secondary query it will match values with the other member's profile fields only if that field is in public section of the profile. The person querying will be able to see the final result only. 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 database, but still get the improved query results using private information in database. 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 Profile3 nameMary phone number418-4533290 email idmary@befriend.com meeting placepresident garden age20 Now assume a member use 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 was private. 5 Database Implementation should have a database of its own to store at least 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 information for the members which 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 able of being polled by other databases for updates and similarly having 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 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 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. Schema for above defined minimum fields is as follows 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 October, 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.