The assumed business relationships between the three parties
involved in the buyer enrollment process are as follows:
Buyers have a series of
relationships with banks that provide them with an assortment of payment
options.
Based on the
assumption defined in Error! Reference source not found.,
banks select from the list of accredited payment system operators an operator
to manage the banks E*MERGE® CP Server.
A number of banks may decide to develop and operate E*MERGE® CP
Servers.
The operator of the
payment server will have a tertiary relationship with the buyer, based on the
terms of their relationship with the bank.
The delivery of the
3DAS™-enabled Card to the buyer is the responsibility of the bank and the
establishment of the payment methods that can be employed. Using that payment
card is the responsibility of that same bank.
Description |
Source |
Size |
|
Buyer Name |
First and last name |
Issuer |
27 Characters |
Buyer Pseudonym |
Randomly generated and changed on a random cycle |
CP server |
12 bytes |
3DAS™ Key |
Data Table of 3DAS™ Marker in the bank's buyers card |
Issuer - at card personalization |
80 bytes |
Payment Method Type |
E*MERGE® wide standard used to define if the method is MasterCard, Visa, Check, Micro-payment … |
Issuing Bank |
4
Bytes |
Payment Method Pseudonym |
Randomly generated and changed on a random cycle |
CP server |
12 bytes |
Payment Details |
Static Information required to complete EFTPOS Message |
Issuing Bank |
Variable - based on payment scheme specifications |
Payment Method Type |
E*MERGE® wide standard used to define if the method is MasterCard, Visa, Check, Micro-payment … |
Issuing Bank |
4
Bytes |
Payment Method Pseudonym |
Randomly generated and changed on a random cycle |
CP server |
12 bytes |
Payment Details |
Static Information required to complete EFTPOS Message |
Issuing Bank |
Variable - based on Payment Scheme specifications |
Payment Method |
As many as required |
|
|
Key to the responsibilities defined in the relationship between
the Issuing Bank and the operator of the E*MERGE® CP Server is a record
referred to as the E*MERGE® Consumer Profile.
The role of this record is to record the payment methods the
bank defines the buyer is allowed to use over the Internet. Further, it will securely hold the static
information required to submit the EFTPOS message associated with that
particular payment method.
For example, the Issuing Bank may decide that John Smith can
use his MasterCard and his USA checking account.
For a MasterCard
credit card the Issuer would provide the complete content of track 1 and/or
track 2.
For a USA Checking
Account the Issuer would provide the content of the MICR line and any other
information employed when submitting electronic checks to the ACH system.
Periodically, the Issuer will be required to update this
record. For example when issuing a new
card when the expiries date changes.
As described in Error! Reference source not found.on
page 5, the operator of the CP server will establish the
procedures and technology necessary to maintain the accuracy of this secure
payment information.
The working assumption is that the E*MERGE® system will be
widely accepted and that the buyer will be able to go to any store that sells
personal computers and purchase a 3DAS™ Reader.
On the other hand, the buyer’s bank may wish to brand the
3DASä
Reader and the CD.
At some point the buyer will sit down in front of their PC
ready to set-up their E*MERGE® environment.
Core to the buyer proposition is that all the buyer does is plug the
3DASä
Reader in and be ready to insert the CD when prompted to do so. The Plug and Play mechanism will identify
the new device and ask the user if they have the disk.
The working assumption is that the E*MERGE® Browser Plug-in
is included on the install CD. Another
option is that the E*MERGE® Browser Plug-in is included as part of the
Microsoft wallet. This would allow
integration of customer profile related capabilities of the wallet with the
payment related services of the E*MERGE® system.
As part of the automated installation process, the plug-in
and the drivers are loaded into the PC.
Next the E*MERGE® Browser Plug-in will attach to the appropriate browser
within the user’s configurations. The
E*MERGE® Browser Plug-in can test communication with the 3DASä
Reader. It can then go on to
automatically register itself with the distributor responsible for the warranty
and service of the 3DASä Reader and E*MERGE® Browser plug-in. Assuming successful connection to the
distributor’s site, further automated tests can take place and the download of
any software upgrades can occur.
The next step in the buyer enrolment process is to create
the 3DAS™-enabled Card.
At the time that the card is produced and personalized, the
3DAS™ Key must be created as described in section on the Error!
Reference source not found..
The 3DAS™ Key is registered in the E*MERGE® Consumer Profile. The entry associated with this particular
buyer begun during the 1) Set up &
Maintain E*MERGE® Consumer Payment Profile described on page 5.
After the 3DAS™ Key is loaded into the CP server database,
two files containing information pertinent to creating the E*MERGE® Browser
version of the buyer profile and supporting the mobility option are
prepared.
The Issuer delivers the card to the buyer in much the same
manner as today, by mail or by asking the buyer to pick it up at their bank
branch.
The delivery of files can occur in one of three ways.
It could be loaded
onto a CD and sent with the card.
It could be built
within the payment server. A mail
insert can be prepared with an Internet address printed on it.
It could be loaded
into an inexpensive chip on the card.
The advantage to this approach is that the chip facilitates
the user mobility option (see Error! Reference source not found.). In addition, independent of E*MERGE® this
inexpensive chip[1]
can provide a platform to offer value added services to these Internet
aware and computer literate customers.
Everything is now prepared to move to the next step.
The Issuer, in conjunction with the E*Merge® CP Server
operator, can send the buyer the 3DAS™-enabled Card
With an inexpensive, protect memory
chip in it.
With a CD inside the envelope.
With a mail insert with a URL printed
on it.
In order to assure the highest level of security there is a
separate secure mailer, with an initialization secret[2] inside.
When the buyer has the envelope with the card and the
separate envelope with the secret, they will read the instructions, sit down at
their PC and do one of the following:
Insert the card into
the 3DAS™ Reader.
Insert the CD into the
CD drive.
Launch the browser and
connect to the URL.
Whichever option is employed, the E*MERGE® Browser Plug-in
will automatically start and begin the initialization process.
The E*MERGE® Browser Plug-in will acquire either from the chip
card, CD or URL, two files. These two
files will be used to create the E*MERGE® Browser Plug-in's Consumer
Profile.
One of the data elements in the first file is the public key
of the E*MERGE® CP Server. This key is
used to assure trust between the buyer and the E*MERGE® CP Server. To provide this assurance, a simple public
key infrastructure is required.
In the future, when the E*MERGE® Browser Plug-in receives
information and instructions it will know that it came from this trusted
payment server. The payment server will
sign its outbound messages with its Private Key and the plug-in will
authenticate these messages with the payment server's Public Key.
Name |
Description |
Size |
3DAS™ Code |
Result of read of 3DAS™ Marker Associated With Issuer |
4 bytes |
Buyer Pseudonym |
Randomly generated and changed on a random cycle |
12 bytes |
E*MERGE® CP Server Address |
The URL of the of the CP server on the secure VPN |
Variable |
E*MERGE CP Server Public Key |
Public Key used to validate authenticity of messages from the payment server |
1024 bits |
Payment Method Type |
E*MERGES® wide standard |
4
Bytes |
Payment Method Pseudonym |
Randomly generated and changed on a random cycle |
12 bytes |
Payment Method Type |
E*MERGE® wide standard |
4
Bytes |
Payment Method Pseudonym |
Randomly generated and changed on a random cycle |
12 bytes |
Payment Method |
As many as required |
|
At this stage the E*MERGE® Browser Plug-in is ready to
activate the card.
The plug-in will recognize either that a card is in the
reader or request the buyer to insert their 3DASä Card
The plug-in will prompt the buyer to type in the secret[3]
known to them and the Issuing Bank.
The E*MERGE® Browser Plug-in will calculate a Hash (see Error! Reference source
not found. for details) using the buyer pseudonym, the
secret, the data and the time as input.
It then asks the 3DASä Reader to read the 3DASä Marker and generate a
3DASä
Signature.
Using the URL, now stored in the buyer's profile, the
E*MERGE® Browser Plug-in will establish and connect to the E*MERGE® CP Server
and request authentication of the buyer's card. The CP server will use the buyer pseudonym to locate the buyer
profile and authentication the 3DAS™ Signature and respond accordingly.
During this communication session any new E*MERGE® .JPG or
.BMP files containing visual icons for the payment methods that user is
authorized to employ can be added to the plug-in's library.
Assuming authentication, the E*MERGE® Browser Plug-in will
ask the 3DASä
Reader to read the marker one more time4. The output of this read will be inserted
into the E*MERGE® Browser Plug-in Consumer Profile as the 3DASä Code
used in the future to identify the appropriate consumer payment profile and
pre-authenticate the user.
When multiple banks send cards to the buyer, this 3DAS™ Code
is used to determine which payment methods the buyer is allowed to use with the
card then in the reader.
At the end of this short process, the buyer can use their
E*MERGE® Card to securely shop on the Internet.
If the customer enrolment completed successfully and the
E*MERGE® Browser Plug-in was loaded properly the E*MERGE® CP Server activates
the card.
From this point forward, or until the Issuer states
otherwise, the E*MERGE® CP Server will accept requests for payment from the
buyer and issue appropriate authentication information to the seller.
[1] The E*MERGE® system would require two files inside the chip. The first file includes basic information used to simplify the mobility option and initialize the E*MERGE® Browser Plug-in. The second file carries the content of the E*MERGE® Browser Consumer Profile and is only used once to initialize the home PC of the consumer and is subsequently erased. This therefore allows the card Issuer to use the space for other applications.
[2] The use of the secret is described in the subsequent section 5) Activate Consumer on Payment Server and is a security mechanisms to protect against not received fraud and application fraud.
[3] There is a risk that a criminal may intercept the card in the mail and attempt to register it fraudulently. Therefore, it is prudent to include a secret only in the registration process that the consumer payment server and the consumer know. This would then be used as part of the data used to generate this 3DAS™ signature. Specifics of how this secret is established are up to the Issuer and the E*MERGE Consumer Payment Server Operator to define. After this procedure is complete, this secret would only be used if the Browser plug-in fails and requires reinitialized.
4 As part of the software in the 3DASä Reader logic will exist that makes sure that the card is not changed when the 3DASä plug-in is requesting multiple reads of the same consumer's card.