Appendix 6 - Consumer Enrolment in E*MERGE®


Buyer Enrolment Flowchart

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.

Name

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
with a .JPG or .BMP file stored with the E*MERGE® Browser Plug-in

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
with a .JPG or .BMP file stored with the E*MERGE® Browser Plug-in

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

 

 

E*MERGE® Consumer Profile

1) Set up & Maintain E*MERGE® Consumer Payment Profile

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.

2) Buyer Obtains 3DAS™ Reader with CD and Installs

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.

3) Issue 3DASä Card

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. 

4) Initialize and Authenticate Buyer and Card

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
with a .JPG or .BMP file stored with the E*MERGE® Browser Plug-in

Payment Method Pseudonym

Randomly generated and changed on a random cycle

12 bytes

Payment Method Type

E*MERGE® wide standard

4 Bytes
with a .JPG or .BMP file stored with the E*MERGE® Browser Plug-in

Payment Method Pseudonym

Randomly generated and changed on a random cycle

12 bytes

Payment Method

As many as required

 

E*MERGE® Browser Plug-in Consumer Profile

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.

5) Activate Consumer on Payment Server

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.


horizontal rule

[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.