Internet Draft Shanghai Hongchuang WEB Technology Service Co., Ltd. Intended Status: Experimental Tian Guorong Expires: Feb.,2014 Shen Jun Curtis Young August 22, 2013 HIEP: HTB Internet E-wallet Protocol draft-tianguorong-hiep-00 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on Feb., 2014. Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract: This document describes an online-paying method that realizes the paying addressing on the basis of HTTP protocol. It is for the purpose to setup a normative and safe E-paying system standard, and specify the definition of E-paying. Table of Contents 1. Introduction 2. Conventions used in the Document 3. HIEP Problem Statements 4. HIEP 5. HIEP Frame Format 6. HIEP Deployment Scenarios 7. Security Considerations 8. IANA Considerations 9. Conclusions 10. References 1. Introduction Till now, there's no one paying addressing language to realize the online paying or data set's interoperating that could be used for definite or name of E-currency's widely used. Under the promoting by W3C, the future generation WEB of the semantic web is defined as "the WEB concept structure which could be handled directly by the machine". On this background, this document is the E-currency paying public facilities pre-positive of the bank E-paying system in the field of E-paying. 1.1 Definitions 1) HTB: the identifier of paying domain or paying address. 2) HIEP: HTB Internet E-wallet Protocol. 3) http://www.username xxxbank.com: username, the username of E-wallet. xxxbank, to mark the field of the E-wallet. 4) WSDL: web service description language. 5) DPL: Digital Paying License. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMENDED", "MAY", AND "OPTIONAL" in this document are to be interpreted as described in RFC-2119[RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. HIEP Problem Statements At present, differentiation of the payment communication and system structure are formed by independent bank organizations or 3rd party payment company's leading position, that they are using different payment models to describe the objects, and formulate each standard. Those standards just extend the life time of each existed systems, instead ensure the data exchange or dataset's interoperation between different paying systems. Obviously, it will restrict the application field online paying, and it could not reach the ability and technique of handling the paying activities of all kinds of bank cards. The real-time of paying is finally a bottleneck problem of the E-business development. Without solving this problem, furthermore, it will bring the unsafe hidden trouble on the capital operation. For the time being, we can only say in own scope utmost, as it only can realize the online paying with safe within each own system. It cannot make the real-time online paying, and can not reach the comprehensive integration of huge scale (supranational, super-region, super-section). Currency's credit: The currency is a credit symbol of paying, people trust it to make it as the intermediation of substitution. It is accepted by the social due to its characterist advantage comparing the metal money on "Gold Standard System" or "Silver Standard System". Obviously, the symbol in virtual paying organizations transaction MUST use a unique identifier, which could make into a definition when people using. This is the credit problem in the paying procedure. 4. HIEP The HTB identifier is named in the overall situation and is cited as a unique one, that is used to mark the paying add. or paying domain name on the WEB service module. By making a HTB extension mark for HTML, and designing of definition template, it can realize the online-paying solution comprehensive service of communication, calculation, control and mass data operation on the base of a E-wallet frame by HTB paying add. space data and internet storage. 4.1 The solutions of credit symbol and paying security in the transaction of Virtual paying organizations. 4.2 To make the integration through many of channels in huge scale of all kinds of bank paying systems. 4.3 To use the existed paying systems and net setup thoroughly. 4.4 To supply a online-paying solution with the high efficient, cheap and random remote paying ability. 4.5 To formulate a normative and safe E-paying system standard by internationally accepted, and become the pre-positioning system of bank E-currency public facility. 4.6 Following the open standard of W3C, will be a part of IETF's process. 5. HIEP Frame Format Definite HIEP Template function to realize HTTP connection's template design: String.url=http://www... ...BANK.COM/ HTTP CONNECTION 1)Resolving the request of HTTP: Sending the HTTP request by treating the authenticated service, and extract the SOAP information from the WEB service, then sent it to SOAP.HIEP RPC mapping element. 2)SOAP.HIEP.RPR mapping: Resolve the SOAP information, and check the WSDL file from WEB service registration center. Then make the WEB service request mapping to HIEP PRC calling according to the information from the SOAP. The HIEP RPC calling language after mapping should be same with the one of WEB service element. Such as, RPC calling edited by VC++, and it is a JAVA RML calling if it is a working element edited by JAVA. 3)Treating HIEP RPC calling: Transfer the user's request mapping into HIEP RPC to exact WEB service element, and execute the HIEP RPC then send the result or abnormal information to HIEP RPC-SOAP mapping element. 4)HIEP RPC-SOAP mapping: Check the WEB service as well, make the HIEP RPC calling or abnormal information into the SOAP according to the XMLDSL file. Create the SOAP information, and send it to HTTP response. 5)Package the HTTP response: Receive the SOAP information with WEB service calling result, and make it into HTTP response sending to the service supplier. In the design, the whole request/response agent module is deployed into WEB server as a WEB application. The function of HTTP resolving and HTTP response are combined into one HTTP request processor, this processor could be a CGI program by VC++ or a Servlet by JAVA. While HIRP RPC-SOAP's mapping function is designed into a WSDL processor, the developer can use many existed tools to finish the element function, in order to reduce the work load for system development. HIEP RPC processor can be designed into a background service operated in a WEB server. Definite HIEP Template Function acting data enquiry's template design as following: Suppose there's only one record in the database, create a HTML template to replace the value by a tag. Then design another class to read this HTML template, change the tags back into the values. Such as: Display the enquiry information Account Balance From this template, all the dynamic display information could be expressed by tags. It is very much easier for WEB page designers to do the work on this HTML template. But, if there are many records and those records qty is not certain, the above tag is not enough. To treat those records, it should be regarded as a whole body like a table. The qty of tables equals to the qty of records. To realize this form, 2 new tags SHALL be cited: It means table starting. It means table ending. So the above HTML template SHALL be modified as follows: Displaying the enquiry information Account No. Currency Transcation Amount Account Balance It SHOULD be replaced a whole body, many tables should be inserted by module into the database if there are many records. In the actual practice, there are 2 situations during WEB pages replacement:1.Replacing the single variable,2.Replacing multiple variable (Unknown Qty). For the 1st situation, just use /<....TABLEENDNAME=XXXX....!> The current problem is how to design the program to treat this HTML template. While it is not big deal, it could use servlet and calling the template in this servlet, then read the HTML replacing the tags of this template into the output information followed by final output. 6.HIEP Deployment Scenarios 6.1 The WEB structure from HIEP system 6.2 The commercial bank net structure on the base of HIEP 6.3 HIEP Paying Modes comparing with the existed types of paying modes 7. Security Considerations In order to realize the interconnection and mutual certification, the HIEP mutual information approval is refer to X.509V3 extension. It is merged into PKCS#12, the indicated HTB domain name MUST be the first level domain name of a bank. Bind the user's public key information with other identified information including the username and email add., to complete the certification of users on the internet. 8.IANA Considerations The IANA will configure the HTB prot for HIEP. 9.Conclusions This document describes the pre-position E-currency paying public infrastructure of bank in the field of the internet E-paying, that realize the HIEP on the HTTP protocol according to the open standard of W3C. 10.References: [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", June 1999 [RFC1866] T. Berners-Lee, D. Connolly, "Hypertext Markup Language - 2.0", November 1995 Author's Address: Tian Guorong Shanghai Hongchuang WEB Technology Service Co., Ltd. Bldg 14, Xinyun Economic Zone, Lane 3199 Zhenbei Rd. Shanghai, China Phone no.: 0086 135 8592 1617 Email: bill.tian@shcn.cc Shen Jun Phone No.: 0086 133 0171 0551 Email: jun.shen@shcn.cc Curtis Yang Phone No.: 0086 138 0178 0703 Email: curtis.yang@shcn.cc