Internet Draft Shanghai Hongchuang WEB Technology Service Co., Ltd. Intended Status: Experimental Tian Guorong Expires: Aug.,2014 Shen Jun Curtis Young Feb 23, 2014 HIEP: HTB Internet E-wallet Protocol draft-tianguorong-hiep-01 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 Aug., 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 the background of this technology, this ID describes an E-currency paying public infrastructure of the bank pre-positive 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) username: the name the E-wallet; xxxbank: to mark the field of the E-wallet Field/ =domain name (xxx) Root field abcbank.com/ =http://www.xxx xxxbank.com 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 characteristic advantage comparing the metal money on "Gold Standard System" or "Silver Standard System". Obviously, the symbol in virtual paying organizations transaction use a unique identifier, which could make into a definition when people using. This is the credit problem in the paying procedure. 4. HIEP This ID names and cites an unique identifier to express the field which the user exists. The form is xxx (user) xxxbank.com. xxx(user) is the domain name, and xxxbank.com is the root field. On this basis, to resolve the xxx(user) xxxbank.com by http in order to setup the paying communication protocol for regulating E-currency activities form. Combining with html web, it could structure paying space data integrated service platform and be used to setup bank pre-positive e-paying system public infrastructure. A paying communication protocol is http//www.xxx xxxbank.com/, ...... In order to avoid the complex of mis-operation by the web designer, it requires HTML and DOM API be designed into the ones which could not detect other script synchronous executing, even workers obey this regulation with no exception. (Note: In this mode, navigator, yield for storage update() equal to turning back the calling for keeping other scripts executing.) On this base, the purpose of HIEP is to make the operation thought to be execution step by step the context paying scripts from the ID in order to execute the HIEP termination's display data passing to the client ends smooth. The client ends here are PCs or non-PCs using different structure systems, i.e. the computers operating UNIX, Linux or DOS etc. Through the HIEP protocol, the computer could get the corresponding services from the remote operating server. Furthermore, it's structure supports multi point data transport, that could transfer to data from end server program to every client ends. i.e. Data are transported to multi destinations for synchronous execution from a real time application program. Here, we would design an e-wallet structure public account system supplying interface standard to connect with bank e-paying system, as it could interoperate the data between them. 4.1 General Design 4.2 System Module Division 4.3 Paying Application 4.4 e-top Management Platform 5. HIEP Frame Format 5.1 General Design 5.1.1 HIEP Protocol Structure 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 SHOUL 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 is 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 are cited: It means table starting. It means table ending. So the above HTML template is modified as follows: Displaying the enquiry information Account No. Currency Transaction Amount Account Balance It is replaced a whole body, many tables are 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. Here, we cite an dealing transaction as an example: Single Consuming Transaction Foreground Webpage Display Example
Single Transaction Background http://aa.xx.com/pay?account=abc abc.com&pid=x&pname=x&price=x &amount=x&busitype=x&trantype=x&total=x&mid=x&bookid=x&bookdate=x&transdate=x&cu rrency=x&signtype=x&sign=x&country=x&timezone=x&ip=x 5.1.2Operation Environment Use JAVA as the developing language Use Oracle database, Oracle 10g over Use Websphere or Weblogic as the service vessel 5.1.3 System Structure 5.2 System Module Division The whole "Paying" system could be divided into the following modules according to its functions: 5.2.1 Channels accessing treating system This system is the core platform of the " Paying" system, and it is on the basis of e-top financial pre-positive exchange platform. Recording all the transactions, it takes the responsibility of communication connection with banks and all transaction requests from www paying gateways. 5.2.1.1 System Functions 5.2.1.1.1 Communication Function The communication is key function of the platform, which realizes the widely used any communication protocols and manners, realizes the overtime treatment. It could handle all the complicated situations easily. 5.2.1.1.2 Routing Exchanging Function This is also an important function, it could achieve the transaction communication route exchanging between different systems. The platform exchange function includes communication protocols, message formats and treating manners. 5.2.1.1.3 Data Treatment and Flow Control Different from the normal exchanging system, it system core adopts the new asynchronous driving flow line complication system. So it could reach high flow treating ability of communication and format exchange by very few core processes. 5.2.1.2 Transaction Function 5.2.1.2.1 Banks channels accessing 5.2.1.2.1.1 Account Registration Function It takes in charge of the accessing for registration channel interface of bank's account. a.Go to bank for open the account b.Sign with the bank, the client could check whether the account is ready on the platform and confirm to bind the bank account with the domain name c.Inform the bank after binding d.Complete the blinding and activate the account 5.2.1.2.1.2 Account Paying Function It takes in charge of the accessing for paying channel interface of bank's account. a.The client launch the paying request on the platform b.The platform make the verifying for the validity of the account that made request c.Make the request to the bank after verify d.Bank withhold the responding amount from the account through the withholding interface e.Transfer the amount to recipient account in the account circle 5.2.1.2.2 www Paying Gateway accessing It takes in charge of the response and treatment for paying requests from trader APPs via www paying gateway, and pass them onto the Banks. The protocol of www paying gate accessing standard is subject to the platform. 5.2.2 Account Function 5.2.2.1 System Functions 5.2.2.1.1 Day-end batch process Day-end supplies auto and manual end treatment The auto day-end automatically starts according to system configuration including auto backup, auto assembly process, auto implement process and auto error handling. Manual one needs to start the operation manually. 5.2.2.1.2 Domain Name Management It manages and approves the domain name in the paying system. At present stage, the creating and management of the domain name is just completed in this system without any links with other system while the extending interface is necessary. 5.2.2.1.3 Domain Name Resolving This module is similar with the DNS domain name resolving solution, it could make the bidirectional resolving between domain name and bank account. At present stage, it just works as an individual one while has the extending interface and frame for further system, i.e. directory management server. 5.2.2.1.4 Statistics Returns It supplies all the statistics reports, and it could inquiry the data by conditions. i.e. Day dealing statement, success ratio report, return code analysis form and suspicious dealing monitoring report. 5.2.2.1.5 Auto Reconciliation It could make the reconciliation automatically according to the agreement or protocols with the paying channels. It subjects to the bank's requirement, which is final confirmed after negotiation with banks. 5.2.2.1.6 Certificate System It could keep, management and verify any spontaneous or issued certificates, and use them based on various business or transaction process. Certificate with trader APP: will not use CA for the time being, use the own certificate system. Certificate with the banks: platform's connection with banks use the certificate issued by banks. 5.2.2.2 Transaction Function 5.2.2.2.1 Internal Portal This portal allows the internal management staff to manage the domain name, reconciliation, transfer rate configuration, returns statistics and risk control. 5.2.2.2.2 External Portal This portal allows the trader APPs to download the forms and to inquiry the bank journal by supplying the fund flow. 5.2.3 Risk Control System The risk control of paying includes all types of trader risks and paying client risks, the basic links have client signing, trader online implementing, transaction process and special business treating etc. 5.2.3.1 Grey list Management Function It supplies a Grey list interface which put into all risky accounts information. When paying requests from those accounts submit, the risk control module would judge it whether it is the transaction within Grey List and sent the warning if yes. 5.2.3.2 Black List Management Function It supplies a Black List interface which put into all risky accounts information. When paying requests from those accounts submit, the risk control module would judge it whether it is the transaction within Black List and refuse the dealing if yes. 5.2.4 Credit Ranking System This system is one of the basic frame be built, and will be extended for further credit ranking data creating. The credit ranking data is to sanction on the behavior of client within the platform. 5.2.4.1 Credit Ranking Rules On the base of transaction, the rules will be regulated to be the criteria of the credit ranking data creating. 5.2.4.2 Data creating According to the rules, the client credit ranking report will be made on the base of his behaviors. 5.2.5 www Paying Gateway www Paying Gateway is the accessing for trader's application, supplying all dealing paying plug-in. The traders call the interface from the paying plug-in to fulfill the paying. 5.2.5.1 Security Plug-in The security plug-in is a paying plug-in development kit for trader's use supplied by the platform. The message from it obeys the HIEP. 5.2.5.2 Key Management The security communication key for trader APPs is managed in the www paying gateways. When the trader APP send the paying request to the gateway, the key message will be decrypted and verified. 5.2.5.3 Paying Accessing Treatment This module is making the responding and verifying for the paying requests from traders, and transfer to be treated in accessing system. 5.2.6 Account Portal Application Program 5.2.6.1 Account Registration The client use secondary function to create the account on the platform, and bind it with the bank account then activate. Details refer to 5.2.1.2.1.1. 5.2.6.2 Account Enquiry It could inquiry the balance of the account. It could inquiry the dealing details of account. 5.2.6.3 My applications It presents all the Apps following HIEP. When the client chooses the App, a reminding of whether agree to the paying protocol would be come up. 5.2.6.4 Financial Consultant In this module, the client could setup the reminding of all the periodically payment via account, such as public service fares, periodic financial transfer, fixed insurance paying etc. 5.2.6.5 My collections Trader could push its App's link and introduction, the client could keep them on his interests. And it also could keep some staple account. 5.2.6.6 Transfer Function The client could use this function to transfer into other accounts. Transfer rate reminding would be made, and a flow chart of transfer fund would be shown to the client. 5.3 Paying Application 5.3.1 Aim at the individual client 5.3.1.1 Online paying The remote paying is realized by APPs on the mobile terminations to fit the online consuming. Paying process: The client choose to operate the related App on his own mobile terminations, picking up the consuming items (i.e public fares) and input the related factors to fulfill the transaction on the paying platform. 5.3.1.2 Offline paying The offline paying uses the order paying function on the termination to realize the onsite paying and catching. Paying process: The client carries the mobile termination to the real shop, completing the paying transferring on the platform after consuming. 5.3.2 Aim at the Trader client Paying process: Register the account, receive all the transfer on the platform via related Apps. 5.4 E-top Management Platform 5.4.1 Production Description This system is a bank pre-positive communication application platform integrated by exploit, deployment and operation, used JAVA and field and flow driving technology. Based on quantizing structure designed from field driving, E-top completes application layer and some domain field layer that makes the users just focus on the business logistics. The perfect pseudo nature language configured system makes it easier understood, and easy to design, exploit and manage the application programs. 5.4.2 Production Positioning E-top platform is a system mainly used for bank pre-positive self-service or mid business platform. It could solve the communication protocol, manners, message format and character set exchange in the case of the mass communication capacity, high transaction pressure. Refer to the following As the extending function, E-top also could be used for mid-business, local feature business etc. In those fields, the E-top platform has inimitable technique advantages comparing with the traditional ones. 5.4.3 Functions Description As the whole frame, the E-top handle the operation of the system. It completes the functions as communication, message exchanging with internal data, complicating treatment control, time operation management and diary record. It just leaves a uniform interface to the business modules. 5.4.3.1 Communication Function The communication is key function of the platform, which realizes the widely used any communication protocols and manners, realizes the overtime treatment. It could handle all the complicated situations easily. The platform supports HTTP/HTTPS, WEBSEVICE, TCP synchronous and asynchronous, long and short connections, UDP and MQ etc. communication modes, and it is easily to extend to support the Tuxedo, Tonglink mid-ware. The platform supplies the overall openness due to the various special communication protocols and treating manners. It could exploit to achieve any complicated treating functions in short time. 5.4.3.2 Message format exchange function As message format exchange, the platform support the familiar formats, and could treat the nested and array message, could treat the definition of alignment, padding and separators, could handle the character set exchanging. The platform could exchange among the following formats: fixed length message, variable length separator message, XML message and 8583 message. 5.4.3.3 Loading Balance Complicating control and over-load precaution is always the focus for a communication platform. E-top uses Java threading pond technique to eliminate the cost of creating and destroy threading by multiplexing the threading. Meantime, it applies waiting line getting the executing time by system space at the extremist of threading treating. That balances the system load efficiently and increases the system stability. Aim at the different channels' complicating control, it could setup the channel maximum complicating qty according to the flow rate and importance of different channel business in order to control the complicating to keep the system operation security avoiding the impact from particular channel. 5.4.3.4 Batch process mission It is capable of timed operation, it allows the client to implement the mission according to the fixed time interval, period or precise time point. It is very easy to dispatch the control configuration to finish the batch process mission. 5.4.3.5 Multi-level journal The multi-level journal method supplies the references for analysis the journal and trouble resolution. 5.4.3.6 Business Uniform Interface Business logistic exploit through the completion of uniform interface, which make the exploit very easy, and could make the extending to another module to structure own level for all demands. 5.4.3.7 Security It supply data's encryption, decryption, MAC checking, MAC calculation treatment, supporting financial data encryption machine or program mathematics. 5.4.3.8 Performance Index 5.4.4 Features Efficiency: It uses threading pond technique, the core of server has strong dynamic scalability with high treatment efficiency. Support high complicating treating: when the system meets the mass online transaction requests, it has excellent complicating control and treatment ability by Java New IO technique to reach 2000 deals per second. Capable of efficient information exchanging and treating function: It supplies efficient communication system that could exchange in the modes of within host or cross host. Information exchange and application adopt the common data pond system to realize the high speed transport between platform plug-ins. It could shield the difference between host and cross host communications by transparent visiting interface. It has complete communication control and guarantee system to realize the stable operation of the module function. Extending: System supplies the support for business extending on the basis of stable operation frame and secondary developing platform. It could structure the new business demand to meet the requirements from the client and market. Reliability: It adopt the mature open frame Spring as the bottom support level and keep the updating for perfect completing. Support group: It could support the group technique, by use JBoss Cache as bottom level. 5.4.5 Operation Environment 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 is 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