INTERNET-DRAFT Varun Srivastava 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 phone number044-7128990 age20 nameMary email idjoe@befriend.com meeting placeNew York Hotel 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 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 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 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.