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.
3DAS.org
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.
