Appendix 5 - System Components of E*MERGE®

In all attempts to implement payment systems, Interoperability has been the greatest obstacle.  Therefore, Unicate has set out to make sure that throughout the design there is assurance that E*MERGE® can be implemented on a global scale and remains true to the tenants of open competition and guarantee interoperability.

The following components make up the E*MERGE® system:

*   The E*MERGE® Specifications

*   The 3DAS™ Card

*   The 3DAS™ Reader

*   The E*MERGE® Message Protocol

*   The E*MERGE® Browser Plug-in

*   The E*MERGE® Merchant OLTP Server Components

*   The E*MERGE® Secure VPN, MP and CP Servers

The intention of this section, and in conjunction with the description provided in Error! Reference source not found., is not to specify each of these components.  Its goal is to provide a high level overview of these components, how they are to be made available to the appropriate parties and how through the overall management of the E*MERGE® scheme, interoperability can be guaranteed.

The E*MERGE® Specifications

Obviously in order to assure interoperability the specification must be singular and extremely proscriptive. 

Unicate will develop this document and submit it as a draft to the consortium that will be ultimately responsible for the management of E*MERGE® System.  Inherent in this document will be the specifications that define the unique characteristics of the components defined below.

The 3DASä Card

The card is made up of two elements the plastic body (as it exists today) and the 3DAS™ Marker. 

Unicate will provide for the secure and auditable provision of 3DASä Markers.  In time, other entities can be licensed to provide the markers so long as these entities adhere to the security regulations defined in the specifications. 

The insertion of the 3DASä Marker into the card is a simple operation and equipment already exists and is employed by many of the organizations that produce plastic payment cards gearing up to embed smart cards[1].  Therefore, the suppliers of payment cards will procure markers and arrange for the insertion of the 3DASä Marker into the card body.

Note a marker is only valid
after it has been registered and statuses as live.
Before that time it is worth less to the criminal
than the pre-printed body of a credit card.

The 3DASä Reader

The reader includes a specific sub-assembly capable of reading and interpreting the 3DASä Marker.  Only qualified suppliers under license should be permitted to manufacture this 3DASä specific intelligent optic sub-assembly.

The integration of this 3DAS™ specific component and the electronics that interface to the PC or server into the PCMCIA, free-standing or rack mounted form can be accomplished by virtually any manufacturer of computer components.  The key is assuring interoperability is making sure that the hardware is provided with software that guarantees that applications written by others can talk to it and that the hardware and software package matches the computer equipment that it will be attached to (Windows, Unix, Linux…).  (See section on Error! Reference source not found. on page 5 for further details)

Core to the E*MERGE® specification will be a defined set of APIs that describe how applications communicate with the 3DASä Reader.  This specification will define how the application software requests the generation of a 3DAS™ Signature and how it will return the result. 

*   It will define the structure of the input that the application software must provide. 

*   It will define the structure of the output the 3DAS™ Reader will provide. 

*   It will define the error conditions that may be returned. 

*   It will articulate how to incorporate a buyer PIN in the 3DAS™ Signature. 

*   It will define how the application software specifies the length of the signature

*   It will define how the application software can specify that the signature must come from a new read of the same Card.[2].

The sale and support of the 3DASä Reader can be through any number of distributors.  These distributors can range from the local PC store through to systems integrators involved in developing merchant web sites.  Alternately the banks may wish to provide this component as a branded part of the banking relationship.

The E*MERGE® Message Protocol

As part of the release of the specifications a specific document will be prepared that defines the flow, message content, message format and data structure governing the Internet protocol that has been defined in Error! Reference source not found. on page 5.

The E*MERGE® Browser Plug-in

At this stage in the design of the E*MERGE® system the assumption is that the E*MERGE® Browser Plug-in is a software component that will be provided by one vendor, both as a specification and a reference model.  This initial version will be capable of being employed through either Netscape or Internet Explorer running under a yet to be defined list of operating systems. 

In the future, software suppliers may determine that it is appropriate to embed this component into future releases of the software or banks may decide to include this as part of an overall-banking package provided to the buyer.  As long as all implementations are capable of supporting the full range of 3DASä Reader APIs and responding to, and issuing the appropriate messages as defined in The E*MERGE® Message Protocol assures interoperability.

The E*MERGE® Merchant OLTP Server

At this stage in the design of the E*MERGE® system the assumption is that the E*MERGE® Merchant OLTP Server is a set of software modules that will be integrated into the online transaction processing environment of the merchant.  Web transaction processing system software suppliers may determine that it is appropriate to embed this component into future releases of their software.  As long as all implementations are capable of supporting the full range of 3DASä Reader APIs and receiving and issuing the messages defined in The E*MERGE® Message Protocol then interoperability is assured. 

Later in the specification it will refer to the E*MERGE® Merchant OLTP Control Software.  As the project moves into detailed design it is hoped that a component similar to the E*MERGE® Browser Plug-in can be developed for the merchant server environment thus improving the lead-time on merchant server development.

The Merchant and Consumer Payment Servers

A limited number of implementations are anticipated of these systems and it is recognized that this will be the most complex part and requires the highest level of security of the entire E*MERGE® system.  Unicate proposes that a limited number of suppliers work together to develop the core aspects of these applications.  It is then assumed that these suppliers will work with the organizations that will operate these systems to customize them to afford each operator competitive advantage. 

As a baseline, these systems must be able to respond to and support The E*MERGE® Message Protocol.  These systems will also have to support a secure environment capable of storing and managing the 3DAS™ Key and the related payment instructions.  On the Merchant/Acquiring side, the appropriate interfaces to the existing payment systems will have to be included in the overall solution.

As part of the ongoing payment authorization process, and in a secure way, the MP server will be responsible to format the EFTPOS messages and transmit them through the appropriate Acquiring Bank interface.  This will involve

*   Inserting the consumer information received over the Secure VPN from the 3DAS™ Consumer Servers into the appropriate EFTPOS message e.g. PAN, Expiry Date …

*   Inserting the appropriate elements of the static payment details held in the E*MERGE® Merchant Profile into the EFTPOS message

*   Inserting any transaction specific data into the EFTPOS Message e.g. (amount, date …

*   Awaiting response from the Acquiring Bank interface

*   Returning to the CP server status of payment authorization

The Secure VPN

The Secure VPN supports secure communication of a set of messages that will be defined in the detail transaction flow included as a further addendum to this document and a secure network capable of assuring the confidentiality of the payment instructions.  The overall architecture of the VPN will be a function of the number of payment servers that will ultimately operate and is identical to numerous networks currently in operation.

For any pilot installation, these three components can be assembled as one system.

In order to assure the success of the mobility option and assist in making sure that the Secure VPN and the links between the trusted payment servers are current a set of redundant DNS servers will need to be maintained by the E*MERGE consortium.

horizontal rule

[1] Unicate has already validated that the equipment used to embed smart cards can just as easily be used to embed the 3DAS™ Marker

[2] This particular requirement is required during both card personalization and during consumer profile activation.