Subject: RE: General Question Related to IOTP V 1

From: David Burdett <[email-masked]>
Date: Thu, 10 Dec 1998 18:06:57 -0800

Tom

Thanks for your comments. I've responded in the text marked with >>>.

It's fine by me if you post this (or any reply) to the list.

David

>----------
>From: 	Tom Arnold[SMTP:[email-masked]]
>Sent: 	06 December 1998 20:11
>To: 	David Burdett; Donald E. Eastlake 3rd
>Subject: 	General Question Related to IOTP V 1
>
>David and Donald,
>
>I'm not certain whether to post this to the list or not as of yet as most
>of the dialog are between people that are very familiar with IOTP and I'm
>still trying to come up to speed so that I can both understand the protocol
>and offer constructive comments. As such, I have a few general questions....
>
>MOST GENERAL: IOTP seems to imply a set of trading roles and a specific
>process. I can see the implementation if a stored-value instrument was
>being presented at some kind of terminal and there was a need to handshake
>and chatter between the consumer, merchant and payment handler. But in the
>web envirnonment where the number of clicks that a consumer is forced to
>perform, this may not be viable. It seems that a consumer might submit
>purchase information to a merchant, and the merchant would proceed and
>process the consumer's payment, if the payment authorization suceeds, the
>merchant processes the delivery exchange on behalf of the consumer, then
>upon delivery, settles the payment transaction. In essence, the consumer
>has concluded a full buying experience with a single button click and never
>distracted from the immediate gratification of the experience. My fear (and
>experience) is that if a system begins to chatter with a consumer, the
>concept of buyer-remorse or frustration sets in and the buyer is more
>likely to cancel the order. Through one of the most well known merchants,
>we performed a statistical analysis and found that the optimal buying
>experience was no more than 3 mouse clicks after the consumer had selected
>the products and decided to buy. There is an approximately 30 percent
>chance the consumer will cancel the order if they are forced to a 4th
>click. This continues up, with the more clicks.
>>>I don't think that in practice you will get the chatter that you
anticipate. The thinking is as follows:
Firstly, before the consumer can click the 'pay' button, he must:
*	decide what he is going to buy
*	decide how to pay, e.g. which credit card, etc,
Once this is known the Consumer can then click the payment and the
payment can progress. A couple of points:
*	unless the consumer knows what they want to buy in advance (e.g. they
have a CD-Rom catalog) and they know what payment methods the merchant
accepts which will only be the case if the consumer already knows the
merchant well, then there inevitably has to be some chatter between the
merchant and the consumer, to discover this information. What IOTP does
is allow automation of part of this process as the merchant can present
a list of payment brands which are accepted (in a structured XML form)
from which the consumer can then make a selection. This means that the
selection process can be automated since the consumer's software can
remember the payment instruments they  have so that the consumer doesn't
have to re-enter the credit card numbers. So in this part of IOTP I
don't think the number of click's which the consumer has to do is
increased they're just done differently
*	once the consumer has clicked 'pay' there shouldn't be any need for
any more click's since the swapping of data to carry out the payment
(e.g. between the payment handler/merchant and the payment handler)
should continue without consumer intervention
*	if the consumer really does know what he wants to buy and how he can
pay there is no reason why IOTP should not allow an 'offer request'
message, from the consumer, which sends this information to the
merchant. The merchant could then, as you suggest, accept the payment,
issue a purchase and payment receipt and deliver the goods in the
response. In version 1.0 of IOTP this almost possible since you can
combine the payment response and delivery response in the same IOTP
message. 
*	I don't think that it will be the *normal* case for the consumer to
know what he wants to buy and how he's going to pay without being in
touch with the merchant, probably on the net, in advance.
>>>
>
>Some more specific questions:
>**** (Payment Exchange: How is the offer protected from tampering by 
>the consumer? In our experience, we had a situation where a consumer
>tampered with a digital offer and changed pricing and product information
>just to prove they could do it. Could the consumer change data in an offer
>inorder to alter the merchant's system behavior?)
>>>Merchants *can* digitally sign the offer which should make it tamper proof.
The payment information in the offer, including the signature, are
then sent to the Payment Handler who should check the signature to
make sure it has not been tampered with. If it has been tampered with
then the payment would fail. In either case, the merchant's system
behaviour would not be changed. The reason signatures are optional
are several, for example:
*	the consumer may be a very thin client and can't actually check
signatures anyway, or
*	the payment handler and merchant may have access to each other's
records (e.g. they're the same company) so the payment handler can check
if the offer has been changed and stop the transaction if it has without
the overhead of signatures.
>>>
>
>**** (Payment Exchange: How will merchant be aware of this out-of-band
>payment exchange? How will they know from a trusted entity that the payment
>was approved/cleared? In a SET pilot that we did in Denmark, we observed
>that the data being exchanged between the wallet running on a consumer's
>desktop and their browser was spoofable. In essence, this wallet upon
>receiving an authorization, would then fire and accept URL where the
>consumer, in this case, could take delivery of their product. Upon
>observing this, merchants immediately requested an out-of-band status that
>would validate to the payment handler that the specific transaction
>referenced in any accept URL was infact valid and successful. Please note:
>that this is a gross over simplification of the technicology but is offered
>as a simple question.)
>>> IOTP doesn't use "accept URLs" for delivery, it used a signed XML message
instead. How it works is as follows ... At the end of the payment
exchange, if signatures are being used, the payment handler creates a
new digital signature that signs the payment receipt as well as the
*signature on the offer response*. This effectively means that the
payment handler asserts that the payment has been made. In order to
get delivery of goods, the following are sent to the Delivery
Handler:
*	the "payment receipt signature", 
*	the "offer response signature"; 
*	a description of the goods being purchased in the Order component"
*	a description of how to do the delivery (delivery component)
*	the organisation component which describes the Merchant
*	the organisation component which describes the Payment Handler
The delivery handler then checks:
*	the Offer response signatue to check that:
*	the merchant who generated the signature is known (checks the
Merchant's Organisation component)
*	the Order description is valid (its signed by the Merchant)
*	Delivery information is valid (signed by the Merchant)
*	the Payment Handler may be a payment handler for this purchase (the
Payment Handler Organisation component is signed by the Merchant)
*	the Payment Receipt signature, to check that 
*	the payment has been made by the Payment Handler known to the
Merchant, and
*	the payment has actually been made (i.e. it signs the offer response
signature)
The Delivery also has "from" amd "to" dates which constrain its
validity.
The Delivery Handler should only do a delivery if all the checks
succeed. There is no need to interrogate a separate third party since
the assurance that delivery can occur is included in the signatures
which the consumer forwards on.
Finally there is still a need for the payment handler and delivery
handler to inform the merchant of the results of the transaction but
this can occur out of band, in batch, and after the transaction has
completed.
>>>
>
>*** (Delivery Exchange: How does this mechanism support impulse buying? I'm
>thinking of Web sites here. Some of the MOST successful sites on the Web
>support one-click, instant gratification. My fear is that by making the
>consumer work through some payment authorization transaction and then onto
>a fulfillment transaction may cause implementation problems. This was the
>primary problem that we saw in the use of a client/consumer wallet for
>payment. There was a significant percent of transactions that went into a
>"wallet wakeup" state and never further. Our only assumption is that the
>consumer bailed out.
> 
>It seems that there are numerous validation steps involved. Why wouldn't 
>the merchant do this for the consumer?)
>>>How do the "instant gratification" web sites work, from my experience, all
the "one-click" does is add something you want to buy to your
shopping cart. IOTP does not address this part of the shopping
experience since we didn't think that merchant's would welcome us
suggesting how their consumers should shop in their store. However
once you get to the "check-out" you still have to fill in credit card
numbers and the like (don't you?) This is where IOTP helps and allows
more automated selection of credit cards etc.
>You say ... "My fear is that by making the consumer work through some payment
>authorization transaction and then onto a fulfillment transaction may cause
implementation problems." IOTP doesn't require this. Once the consumer
accepts the Offer response, all other messages should flow automatically
without consumer intervention (although it's probably a good idea to let
him know what's going on).
I agree with your comments about transactions that go into a"wallet
wakup" state and never further... I know I've done it myself. I think
the main reasons are lack of familiarity and lack of perceived benefit.
Familiarity problems will go away (with effort, education and
experience!) and IOTP offers significant benefit in terms of receipts
which can be used to get problems fixed, feeding into software like
Quicken and even potentially for tax purposes.

>*** (Section 3.2 The first paragraph refers to organizations shouldn't this
>be "trading roles"?  )
>>> Yes. Trading roles would be a better term to use
>>>
>
>
>There will be more to follow from me.  If you would prefer, I can post this
>to the list in an effort to help educate and stimulate some discussion. 
>
>Thanks.
>
>
>
>Tom Arnold
>Vice President of Engineering
>CyberSource Corporation
>[email-masked]
>

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

---

From: Andrew Drapp <[email-masked]>
Date: Mon, 14 Dec 1998 13:15:12 +0900

Tom and David,

I have sniped the messages you sent to the ietf list, and
put my responses after them.

[Tom]
>> Through one of the most well known merchants,

[David]
> should continue without consumer intervention

[Andrew]
If depends on which click you say 'pay' is.  In our demo version of IOTP,
the consumer presses several buttons that could be labeled 'pay'.  The
first time is when viewing a shopping card, the user presses the purchase
button.  The mall server will then ask for shipping information if required.
There are still quite a few clicks before the transaction is done.  After that,
just before IOTP starts and there is another confirmation button.  There are
still quite a few clicks till the transaction is complete.  The third 'pay' button
is when the IOTP invoice is presented, the consumer confirms it, and 
goes on to the payment step.  There are still several mouse clicks after 
this button.  In the payment exchange, in SET, the consumer must digitally
sign the payment, this requires an additional click.  This sign could also
be considered a pay button.  It is the same with Mondex.  we ask the
consumer to confirm a payment just before it actually occurs.

From the time the consumer decides to make a purchase, while viewing his
shopping cart, it takes quite a number of clicks to complete the transaction.
I think Toms complaint is a valid one.  I also think we are on the right
track to solving it.  With the use of auth request, the merchant can 
retrieve shipping information.  This will cut down the number of clicks
required to complete the transaction significantly.  As David mentioned,
the IOTP aware wallet also simplifies payment by eliminating the need to
re-enter credit card information on every purchase.  If the software 
implementation had a few switches, this could also greatly reduce the
number of steps to complete a transaction, such as "AutoConfirm invoices/
receipts/payments/etc.".  

Regards,

Andrew Drapp