The Implementation of Electronic Document in Transaction Execution

Abstract

The article presents the implementation of an electronic document in the form of electronic forms that can be used in legally binding way in transactions execution regardless of the field of application, the type of entity involved in the transaction or their local information systems. Paper also presents the concept of the form in which the data layer, the presentation and the logic is encapsulated in a one single XML file, whose syntax is described using XML schema (XSD). Presentation of the document is done on the background of the discussion about the general concept of the document and the transaction. Authors present also the ways of implementation a few basic types of transactions, from which more complex solutions can be composed. The vision of the further research and development of the electronic document towards the use of crypto - currency, smart contracts, block chains and distributed autonomous organization is outlined in this paper.

1 Introduction

1.1 The Transaction

Activity understood as a series of structured activities carried out to achieve a specific goals is called a transaction. The transaction [1,2,3] can be understood as:

• Commercial operation associated with the purchase or sale of material assets, intangible assets or services and agreement associated with this operation,

• Transfer of material goods, services or intangible goods between the parties resulting from variety of relations binding the parties, may be economic, commercial, financial, social or any other relations,

• An agreement (contract) between the parties the subject of which are good, services or other agreements and commitments.

It should be emphasized that the subject of this article are not transaction in the sense of database transaction or other related to information technology.

The concept of transaction is general and applies to essentially all human activities regardless of: form of organization, activity, type of transaction or sector.

Transaction is always related to: creation, processing, transfer (flow), collection (gathering) and store of information [4].

1.2 The Document in the Transactions

It can be found, that information is in a immanent way is accompanied by a transactions and often is the subject of the transaction. However if information is to be useful in the implementation of transaction in secure manner, it must have some certain features:

• Authenticity – sure of the veracity of the information,

• Non-repudiation of origin – sure the origin of information,

• Durability – possibility to use of information after the time.

If the information meets the above characteristics, then we can talk about the document [5], which can be used as evidence in explanatory proceedings.

It should be noted that the role of the document has been extended through the use of electronic document as mean of supporting the transactions realization. The essence of the electronic document as a special form of a document is presented in the paper [5]. Here it should be noted that the electronic document must have all the features of the traditional document.

An important aspect of the electronic document is the need to ensure the interoperability of electronic document in a wide range, namely:

• the ability to use regardless of the maturity of IT used by users,

• document format must be independent of industry or activity sector of the economy,

• document format and software to use the document must be technology-neutral,

• ease of integration with various user’s systems,

• autonomy - the ability to use a document on a device without access to network,

• the ability to interpret the document both:

  • automatically (the integration with information systems,

  • by human and automatically.

2 Expected Features of an Electronic Document and Proposal

2.1 Expectations vs. Possibilities of Existing Solutions

To be able to support transactions or to be a subject of transactions, electronic document must be provided with the following features:

• A. Non-repudiation, integrity, authenticity – legal effectiveness

• B. Autonomy – the ability to use document without access to the network,

• C. Intelligibility for people – visualization based on universal commonly known rules,

• D. Interoperability – ease of automatic processing, ease of data exchange with information systems (XML),

• E. Ability to define and execute the logic – validation rules, calculation rules, rules of dynamic presentation of objects in the document, build – in cryptography and public key infrastructure functions, build – in mechanisms for communication via SMTP/POP3, SOAP, REST, HTTP GET/POST,

• F. Ability to integrate and use emerging technologies like: cryptocurrency, block chains, distributed autonomous organizations, session initialization protocols.

Solution	Feature
	A	B	C	D	E	F
PDF	+	+	+	–	–	–
Packages (MS Office, Libre Office)	–	+	+	–	–	–
SMTP/POP3/IMAP	–	+	+	–	–	–
Fax	–	+	+	–	–	–
Centralized IT systems	+	–	–	–	–	+

• PDF (Portable Document Format) – the biggest problem in using it to document the transaction is complicated structure of the file what makes automatic processing difficult and requires dedicated libraries. Also the logic layer doesn’t exist what makes this format less useful. It is at least difficult to use it to exchange legally binding data between systems (with automatic processing) [6].

• Office packages (MS Office, Libre Office and similar) – in the case of those solutions the problem of parsing and interpreting data can be observed – similar to PDF. Non repudiation of origin, integrity and authenticity cannot be ensured. Also definition and execution of the logic does not exist [7].

• E-Mail approach (SMTP/POP3/IMAP) – it is possible to sign e-mail message, but doubts appear if it is fully legal. Processing the mail message is embarrassing It is at least difficult to use it to support transaction execution [8].

• Fax – it is the image of the document only. It is not possible to exchange legally binding information using the image of document.

• Centralized IT systems – allow to support transactions in efficient way but it is limited to the space of specific system only. The information exchange with other systems requires specific preparations for all systems involved in the information flow [9].

2.2 Proposal

The solution which meets all needs/features/requirements considered above is electronic document (electronic form), in the form of XML file, with syntax defined using XML schema (XSD) [10,11,12,13]. To use the form, the dedicated application or standard commonly known XML parsers should be applied.

The extension of electronic documents application is to integrate and use them with the implementation of concepts: Cryptocurrency, Smart Contracts, Block Chains, Distributed Autonomous Organizations.

3 ebForm – Electronic Form

3.1 ebForm

The concept of the electronic form that meets all of the above features has been implemented as ebForm forms.

The whole solution consists of (Fig. 1):

• Electronic form in the form of XML file with syntax defined using XSD,

• The application designed to use ebForm forms – interprets and executes visualization (presentation) data input, signature operations and form logic,

• ebFormProcessor server – application server:

  • communicates with the ebForm application (ebCommunicator), using SOAP protocol according to the logic defined in the logic layer of the form, and

  • processes the form – downloads data from the form and records data to the organization’s internal systems, verifies the document authenticity, writes data into the form, generates signature in the form, returns the form to the ebCommunicator application, all above in accordance with logic defined in the ebFormProcessor.xml file.

• ebFormAPI library – library designed for developers to create solutions based on, and using ebForm. The library allows reading and writing data from/to the form as well as execution and verification signatures.

Fig. 1.

Key elements of the electronic forms solution

ebForm contains the following conceptual layers of the document (Fig. 2):

• visualization (presentation) layer – a description of the visual shape of components of the form,

• data layer – the data entered into the form is not separated from the presentation layer, but with other layers (visualization and logic) is a single entity in the form of file,

• logic layer – these are non – visual elements not existing in traditional paper forms, this layer allows to:

  • define the validity rules for data entered into particular fields of the form,

  • define the dynamic behavior of graphical components and other calculations depending on the status of individual forma fields,

  • define the activities initiated as a result of interaction with the user.

Fig. 2.

Conceptual layers of electronic forms

ebForm syntax description is a specific description language for forms and can be regarded as the implementation of the concept of declarative programming. In particular, ebForm includes:

• Graphical components – graphical elements of the form. Each element (text, text field etc.) has a defined list of attributes that determine the way of presentation. Attributes can take the values depend on the values of input field/s or current referred function value/s.

• Expressions – default values can be calculated and assigned to individual fields. Calculations are performed using various expressions using appropriate type (string, integer or decimal etc.). It allows to determine values of attributes of components.

• Actions (Activities) – special component is a push button that can be assigned to a sequence of actions, to be performed by the application ebCommunicator. These actions include: construction of a signature, the removal of a signature, writing to the file, sending a mail, calling the Web service SOAP RPC calling to a SOAP Web Service MSG, updating values in a component, verifying the value of the component opening the specified web site.

• Signatures – four types of signatures are implemented in the form:

  • Resource signatures – signatures of resources, files located in the global network and pointed by URL, which are in logical relations with the form,

  • Approval signatures – designed to legally approve the form to use. Signatures cover the blank (empty) form and countersign resource signature(s) if exists. Approval signature is to be done by the organization (or organizations) that uses the form to support its (their) business process.

  • Form signature – single mandatory signature, covers blank form, countersigns resource and approval signatures. The aim is to protect the whole form against tampering (the visualization, logic, approval signatures and resource signatures)

  • Users signatures – user signature countersigns the form signature and signs data entered by the user and countersigns signatures of other users as specified for that signature in the form logic.

3.2 Forms Transfer and Processing - ebFormProcessor

The form can be transferred between parties taking a part in the transaction:

• Simple transfer of the XML file using any storage media (disk, pen drive etc.)

• The use of electronic mail (SMTP server, Fig. 3) – the recipients list and encryption information, the mail content text, mail subject can be defined in the logic for send mail action. ebCommunicator application, builds and sends a mail message with ebForm file attached to the message. The mail message does not constitute a document (document is attached as file)

  Fig. 3.

  

  UML sequence diagram for mail transport of electronic form

• The form can also be the content of the SOAP-Envelope structure and transferred to the server pointed by address specified in the logic layer for action Send SOAP.

The third way it is the web application (servlet running on the server). It gives wide possibilities to define processing of received forms. The form is:

• received by the application (servlet) as a structure of HTTP SOAP Request, then

• processed according to the logic described in the process descriptor file, where the treatment of different types of the ebForm form is defined. Form processing consists of tasks performed in the order specified in the processes descriptor file, for example:

  • full verification of indicated signatures in the form,

  • read the indicated data from the form and write it to the internal system,

  • generate and write data to the form,

  • generate digital signature in the form,

  • construct a mail message and send it to intended recipients,

  • save the form in the local file system or internal information system,

  • build the SOAP Response structure with the form included (Envelope) and return it to the application ebCommunicator.

Use ebFormProcessor server allows to build solutions that implement the support of transactions in a distributed manner - without the use of the central system with the need to register and then login and verify the logged user.

4 The Transaction with Use of Electronic Forms

Electronic forms in accordance with the requirements described above must reflect the traditional paper forms. Traditional forms can/should reflect all steps of the transaction in the various areas of the form. In the same manner – electronic form should document stages of its processing e.g.:

• Undeniable delivery of a document to the recipient:

  • Using SOAP Protocol – the sequence of actions executed is presented in the Figs. 4 and 5.

    Fig. 4.

    

    UML sequence diagram for SOAP transport and processing of electronic form

    Fig. 5.

    

    UML sequence diagram for SOAP transport implementation for undeniable form delivery

  • Using electronic mail – the sequence of actions executed is presented in the Figs. 3 and 6.

    Fig. 6.

    

    UML sequence diagram for MAIL transport implementation for undeniable form delivery

• Document (form) flow

  It is possible to implement the document flow between the participants in the transaction. It is possible to implement:

  • automated document flow, with the use of document processing server (ebFormProcessor),

  • non-automatic flow process, in which the role of the server serve the people and the email is used to transport the document between the parties.

  The transfer of the form is executed according to sequence diagrams for SOAP and Mail transport presented in Figs. 3 and 4.

• It is possible to implement support for transaction associated with payment, money transfer and other sophisticated transactions.

5 Implementation, Applications

In the following part of this paper real implementation of the ebForm forms are presented.

Hundreds of traditional paper forms has been implemented in the shape of ebForm forms in about 50 Municipal authorities. Also ebFormProcessor integrated with internal (local) IT systems has been installed. The integration was implemented to store values of data fields in RDBMS SQL Systems, Lotus Notes Server and a few local document flow systems. The experience proofed the usability of the ebForm solution in wide area of applications regardless of the sector, area or social environment. Here only few forms are presented (Figs. 7, 8 and 9).

Fig. 7.

Example of the form delivered to Municipal Authority in Szczecin. Non deniable receipt is shown in the violet table.

Fig. 8.

Example of the form implementing the concept of the envelope with non-deniable delivery to the server.

Fig. 9.

Example of the form implementing the concept of the envelope with non-deniable delivery to the client.

6 Discussion

As stated above, the document as useful mean for transaction support, must meet features discussed in Sect. 2 of this paper. All popular and widely known and being used solutions doesn’t fit to those requirements.

In contrast to approaches presented above, ebForm (XML) proposal provides:

• ease automatic processing, data manipulation, data exchange between information systems thanks to use XML [3] format as the base

• legal effectiveness by through the use of standard XML Signature in accordance with the W3C specification [1, 2],

• intelligibility for people by possibility to visualize the document based on universal, defined with XML Schema [X], syntax and semantic of the document,

• possibility to define and execute the logic defined in the document file and executed by application in accordance to defined syntax and semantics of the form format,

• autonomy – the document can be used by people and systems regardless of network or other systems connection,

• the ability of emerging technologies (cryptocurrency, block chains, smart contracts distributed autonomous organizations) integration in a rapid way. It is not necessary to wait until new technologies are implemented in other approaches in a way required for documents in transactions.

It seems that presented XML form though the generic approach meets expectations and requirements of different kind of transactions and business processes involving those transactions. I does not require to use complex centralized systems and transactions can be executed in totally distributed (decentralized) way.

7 Conclusions

It was found and presented in the paper that the immanent features of electronic document, useful for processing, presentation for human and transaction support are:

• visualization integrated with data and

• the possibility of automatic processing and use by humans,

• the independence that allows to use a document without a network connection,

• while ensuring authenticity, non-repudiation and integrity [14].

As far as presented features apply to all documents (both traditional, paper and electronic), the logic layer, is specific for digital documents (form) only, and provide the ability to define: validation rules, dynamic presentation of graphic components, communication mechanisms calculation rules. In this layer the integration and implementation of concepts of emerging technologies are to be included.

Further development of electronic document capabilities should be anticipated. For example:

• further integration with the communication environment, the dynamic relation between parties of transaction and document should be allowed – for example implementation of the support of the Session Initialization Protocol (SIP). The application executing the logic should present the status/availability of parties involved in transaction and the connection between parties should be established on demand. The example is Skype system.

• Integration with cryptocurrency (e.g. Bitcoin) and the use of these currencies in the implementation of the various types of transactions [15].

• The development and implementation of the concept of Block Chains [16] to build confidence in transactions (documents without the electronic signature) and the use of the concept of distributed databases,

• The use of electronic documents (form ebForm) as so called Smart Contracts with the integration with elements of the Internet of Things.

• The development and implementation of electronic forms integrated with the use of the concept of Distributed Autonomous Organization.

It should be highlighted that current implementation of forms in different solutions show the assumptions are correct and further development is promising.