One of the challenges in providing an effective means of
payment for the Internet is to make sure the buyer can make purchases from any
Internet enabled device. Providing
mobility does not, mean that security can be subjugated nor should it mean that
the buyer's option of payment methods is limited or that procedures become more
cumbersome.
Most of secure payment methods available today depend on a
software module and some associated data commonly referred to as a
"Wallet". The
"Wallet" must be loaded and becomes part of the software of a
PC. Banks must create Cryptographic
keys and certificates associated with each payment method and arrange to load
them into this “insecure” PC. This
dependence on software restricts the buyer purchasing only from those PCs they
have arranged to load the cryptographic information. Unless they figure out how to copy these cryptographic keys and
certificates securely carry them around.
The one solution that MasterCard and Visa are discussing to
solve this problem is to employ smart cards, defined by the EMV “Europay,
MasterCard and Visa” Integrated Circuit Card Specification, as the mechanism to
carry the consumer’s SET “Secured Electronic Transaction” certificates.
Unicate's concern is that this solution does nothing to
reduce the complexity of SET nor does it eliminate the costs associated with
issuing these EMV smart cards. A 5 to 10 year mega billion dollar negative business
case that no one has been able to sensibly justify.
Other methods currently being experimented with implement
the consumer's wallet inside a network server thus allowing the consumer to
access their network wallet from any PC.
Although these solutions begin to resolve the problem of mobility, it
does not successfully resolve the associated issues of security and ease of
use.
These network solutions are hampered by the fact that
assuring an acceptable level of security forces the user into having to
remember account numbers and passwords.
This requirement imposed to assure protection ends up defeating the
primary goal -
Provide The Consumer A Mobile And Easy To Use
Payment System.
In designing E*MERGE® Unicate began by considering the
devices and locations that a consumer may wish to effect Internet purchases
from. This holistic approach recognized
that without an effective ePayment mechanism the success of eCommerce was at
risk. Unicate also thought about the
needs of all the players and remembered, “The consumer is king”. This customer focus has assured the users of
E*MERGE that makes payments from a Cyber Café is as secure and easy as they are
from home.
If we simply consider the home, there is an assortment of devices a consumer may wish to use (PC, TV, …, Smart Phone). They do not expect to be limited to use the one supported by some specification just because the authors of that payment solution did not design mobility and device independence in from the beginning.
Simultaneously many office workers, during their lunch and breaks, surf the web and locate goods they wish to purchase. On the other hand, for business reasons they may wish to be able to effect payments against their expense account or a corporate payment card from their home office.
As Local Area Networks expand, users will end up working from a variety of devices in the office environment. The list could include the PC in their office, a PC in a conference room, PCs installed in locations away from their main place of work or on their laptop. All of these locations must be positions from where consumers should have the ability to spend money using the new channel provided by the eCommerce revolution.
Devices at both the home and office have one thing in common. There is a degree of trust assumed by the user.
In contrast the Cyber Café and locations such as hotels, outdoor kiosks, PCs in building lobbies and other public locations are locations from where consumers will have a heightened security concerns. This being said, the design of the E*MERGE® system assumes that every location is a threatening location and views that payments should operate the same no matter where the consumer is.
Unicate appreciates that certain communities will wish to provide distinguishing features on public terminals to assure the consumer that their payments are secure and cannot be tampered with. Therefore it assumes that some of these public locations will require some form of external certification to assure trust in both the software and the hardware being employed by the E*EMERGE® system.
How this certification should take place and how it can be policed must be the subject of multi-lateral discussions with the E*MERGE Consortium, International agencies, local authorities in each country or community planning to employ E*MERGE® in such public locations
As eCommerce expands, eCommerce merchants will wish to enable payments from a raft of small low powered devices that do not have the display capabilities or the computational power of a PC or, for that matter, a digital television. Three issues must be addressed when considering how to serve these locations. First, how the E*MERGE® Browser Plug-in interacts with the consumer? Second, how much memory or storage is available on these devices to allow the plug-in to store consumer profiles etc? Third, can the 3DAS™ Reader be made small enough?
Contrary to other initiatives Unicate has assumed mobility and the variety of
devices a consumer may wish to use as key to the overall design criteria. Simultaneously, Unicate's management demands
that the 3DAS™ solution avoids the use of cryptography and assures the consumer
the highest level of ease of use.
Equally, Unicate’s management has spent a great deal of time making sure
that the 3DAS™ reader is as small as possible.
Unicate will continue in its efforts to further reduce production cost
and further miniaturization of the reader.
www.issuerID.3DAS.org/mobile - The Key To Consumer Mobility
With E*MERGE® and
leveraging the power of 3DAS™, all that is required is that the device the
consumer wishes to use be equipped with an inexpensive 3DAS™ Reader.
The solution Unicate proposes
simply requires the user to insert their 3DAS™ Card into a 3DAS™ Reader when
prompted by the E*MERGE® Browser Plug-in to do so[1]. The E*MERGE® Browser Plug-in reads the card
and does not find a matching E*MERGE® Browser Plug-in Consumer Profile. (See Error!
Reference source not found. for more details.) It therefore assumes the consumer is a
mobile user and initiates the Mobile user routine.
The E*MERGE® Browser Plug-in
operates under the assumption that it is there to serve. Therefore it wants to locate the right
E*MERGE® CP Server. It can follow one
of two routes to server this mobile consumer.
Not finding a mobility file on the card, it asks the consumer to enter the Issuer Id, as found printed on face of the card. The user is then requested to enter their first name exactly as printed on the card.
Based on this very simple to remember, its printed on the card, information the plug-in can now prepare an E*MERGE® Mobility Message “No Mobility file present” consumer with ID is present. It first requests the 3DAS™ Reader to produce a 4 character FastKey
Using the Issuer Id entered by the buyer and a 3DAS™ FastKey it creates the URL www.issuerID.3DAS.org/mobile and connects to the Internet. Assuming the connection is established and recognising that the mobility file is not present, the E*MERGE® CP Server responds with request to produce a 3DAS™ Signature based on a random challenge value.
The E*MERGE® Browser Plug-in takes the value of the challenge plus the User ID, issuer ID, date and time and creates a Hash. Using this Hash the plug-in requests the 3DAS™ Reader to produce a 3DAS™ Signature. The plug-in then creates a message including the Hash, date and time and the 3DAS™ Signature and sends it back to the E*MERGE CP Server. The payment server validates that it the card is present by verifies the Hash and the 3DAS™ signature against the Consumer Profile is located using the User ID found in the first message. It is now ready to allow the E*MERGE® Browser Plug-in to serve its 3DAS™ authenticated consumer.
Consumer mobility ID |
First and Last Name with a sequence number |
27 Characters |
E*MERGE® CP Server Address |
The URL of the of the CP server |
Variable |
E*MERGE CP Server Public Key |
Last CP Server Public Key used to validate authenticity of messages from the payment server |
8 digits1024 bits |
(Or other machine readable media
on the card)
Finding an inexpensive (.15 to .20 US dollars) protected memory chip (or other machine readable data store) present and locating an E*MERGE® Mobility File, the E*MERGE® Browser Plug-in proceeds to read the information in the E*MERGE Mobility File.
The E*MERGE Browser Plug-in prepares a mobility message that includes the Consumer Mobility ID, a calculated Hash[2], the data, the time and a 3DAS®™ Signature[3]. Using the address in the Mobility File[4] and adding a /mobile to the URL it connects to the E*MERGE CP Server[5] and sends the message that initiates the request to download a temporary consumer profile.
The server looks up the consumer record from within the E*MERGE Consumer Payment Profile using the Consumer Mobility ID as the index. The payment server validates that it the card is present by verifies the Hash and the 3DAS™ signature against the Consumer Profile is located using the Consumer Mobility ID. It is now ready to allow the E*MERGE® Browser Plug-in to serve its 3DAS™ authenticated consumer.
The E*MERGE Mobility Routine returns, after positive verification of the Hash and the 3DAS™ signature, a temporary Consumer Profile to the Plug-in
In either of the two cases described above, the E*MERGE CP Server has used 3DAS™ to prove that the Card is Present so that the Issuing Bank can offer their treasured clients an easy to use mobile service.
Assuming the card is authentic, the E*MERGE CP Server creates a temporary copy of the E*MERGE® Consumer Payment Profile, inserting new pseudonyms in for both the consumer pseudonym and the payment method pseudonyms.
In the event that a protected memory chip was present[6] with an E*MERGE® Mobility File inside the payment server also sends a new Consumer Mobility ID. This new ‘Consumer Mobility ID’ is written to the chip, replacing the old value.
This temporary file and additional information is sent by the E*MERGE® CP Server to the E*MERGE® Browser Plug-in serving the mobile user. The E*MERGE® Browser Plug-in creates an additional temporary consumer profile using the standard structure describer in the section on the Error! Reference source not found..
The E*MERGE® Browser Plug-in is now able to continue with the standard secure E*MERGE® payment process at the stage that the plug-in compares the payment options the consumer has available to the payment options the merchant is willing to accept (See Error! Reference source not found. on Page 5).
Recognising that exceptions do occur the E*MERGE® browser plug-in will maintain a temporary log of the transaction. Either after the Internet connection is terminated and a specified period has elapsed or after receipt of message 8 these log records will be deleted.
In order to assure the consumer that the log at the primary E*MERGE® Browser Plug-in is up to date, the E*MERGE® payment server will store and create the log records necessary to update the consumer home plug-in’s log. This feature will allow the home E*MERGE® Browser Plug-in, see page 5 describing the Error! Reference source not found., to automatically update the consumers home log file when it is next connected to the Internet.
The software in the E*MERGE® Browser Plug must include logic
that says that if it does not find a consumer profile linked to the card in the
3DAS™ Reader it executes the logic associated with the E*MERGE® mobility
option.
The plug-in must also have within it logic to purge consumer
profiles that are no longer active. This suggests that when a mobile users
effects a mobile internet payment the 3DAS™ Browser Plug-in asks the user to
enter the number of days their temporary consumer profiles can remain
persistent[7]. This being said many consumers will not
understand the security issue surrounding the temporary E*MERGE® Consumer
Profiles. Therefore, as part of each payment
servers automated maintenance procedures it will have fraud prevention logic
capable of instruct an E*MERGE® Browser Plug-in to purge mobile consumer
profiles.
The E*MERGE® CP Server will be able to recognize the URL
extension /mobile and in an inbound
message and recognize that an E*MERGE® Browser Plug-in attempting to serve one
of the payment server mobile consumers.
The CP Servers mobility logic will also include specific fraud detection
logic designed to monitor irregular activity.
In order to make sure the consumer’s host plug-in’s logs are kept up to date the server will retain all pertinent information, so that the consumers host E*MERGE® Browser Plug-in’ log can be updated.
[1] This occurs immediately after the E*MERGE® Browser Plug-in has received the Merchant Invoice.
[2] The Hash is of the data in the mobility file along with the date and the time.
[3] The 3DAS™ Reader produced the 3DAS™ Signature based on the Hash
[4] Each E*MERGE® Consumer Payment Server must have a unique IP Address that links to the URL www.issuerID.3DAS.org in a central DNS Domain Name System. A DNA is a database system that translates an IP address into a domain name. The E*MERGE Consortium would manage the DNS for the domain 3DAS.org.
[5] The extension /mobile will allow the E* MERGE® Consumer Payment Server to direct the request to the mobility routine.
[6] Note: As an alternative a SSL connection may be set-up for retrieving the Consumer Profile. The ‘Last Mobility ID’ then remains unchanged. This is especially recommended if the data storage on the card is read-only and the ‘Last Mobility ID’ thus is a constant value.
[7] This feature would allow a consumer at a hotel to set the plug-in to keep the their profile for say 3 days. At a Cyber Café for only another hour. Their office could be set to maintain the profile for 120 days. The machine of a friend could be set for 30 days. The goal is to improve performance for repeat users, while at the same time protect the system from criminal activities. The default is be to delete after each use.