Subject: RE: shipping address for the OfferResponse -- was RE: Consumer de livery address
From: "Smith, Chris " <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Trade (E-mail)" <[email-masked]>
Cc: "Rudolf Hornig"@metechnology.com
Date: Mon, 30 Aug 1999 15:04:42 -0400

Once again, you have most of the outline correct. I'll edit
in some additional details...

>  1) Consumer picks the goods in the web shop.

This is all standard http and html, pages and forms.

>  2) Consumer finishes shopping and wants to check out the cart.

The assumption here is that any card (no matter where it is stored)
must be passed to the merchant to check out. At this point the merchant
has all the content details.

However, the merchant now has a choice. They can ship an Offer Response,
OR - watch closely now - they send the Auth Request with the intent of
requesting a shipping address.

The working assumption of IOTP has always been that the merchant will
trigger the wallet by responding to a plain forms HTTP request.

>  3) Wallet fires up.

...and it examines the initial request. If the initial request is an
Auth requesting a shipping address, then it opens the address book
for the consumer.

This is the critical step. The wallet should be started and passed ANY
IOTP message, not just an Offer Response. (As an example, if the MIME
type is pointed towards a helper app, the app will be launched and
passed the initial IOTP message. The app will have to see if the message
is appropriate given what has gone before.)

>  4) Consumer selects address from the address book.

Yes. Note that the consumer might be given an easy way to send
phone and/or email address and/or mail address. This is bound to
be easier and less error prone that entering the whole address
every time. Also, when buying gifts, one could have other addresses
available for sending.

>  5) Wallet SENDS THE ADDRESS BACK TO THE SHOP so that Merchant 
>     can generate the IOTP offer.

Exactly - as part of the Auth Response.

>  6) Merchant generates IOTP Offer Response and optionally signs it.

The Offer Response is complete now, because the merchant had both
the goods (the contents of the cart) and the address (from the 
Auth Response).

>  7) Consumer selects payment brand, protocol, currency.

Onward! (You might want to keep an eye out for the coming Secure Channel
Credit, which is designed to do for card information what just happened
above for delivery information.)

>  8) ...

------------------------------------------------------------
 Chris Smith                                +1.416.348.6090
 Royal Bank                       [email-masked]

> -----Original Message-----
> From: Andras Varga [mailto:[email-masked]]
> Sent: August 30, 1999 09:10 AM
> To: Ietf-Trade (E-mail)
> Cc: "Rudolf Hornig"@metechnology.com
> Subject: shipping address for the OfferResponse -- was RE: Consumer
> delivery address
> 
> 
> Chris Smith wrote:
> > The intent is that all relevant details are available for 
> > construction and signing of the Offer Response. This includes 
> > items such as the shipping address.
> 
> This is reasonable. However, it doesn't make it easier to 
> create a good strategy for handling the shipping address.
> 
> Our goal is to design an IOTP Wallet which is comfortable to use
> and has enough features to make the buying easier for consumers.
> We would like to include an address book in the wallet. (In our
> understanding, one point which makes Internet shopping cumbersome
> is that one has to enter the address with every purchase. Or one
> has to register and become a "member" in the shop which doesn't
> help much if you go to a different web shop every time... A locally 
> stored address book would help; such feature is included
> in many existing wallets).
> 
> Now how could we use the address book? If we want the shipping 
> address to be included in the Offer Response, the address
> selection must take place before generating the Offer:
> 
>  1) Consumer picks the goods in the web shop.
>  2) Consumer finishes shopping and wants to check out the cart.
>  3) Wallet fires up.
>  4) Consumer selects address from the address book.
>  5) Wallet SENDS THE ADDRESS BACK TO THE SHOP so that Merchant 
>     can generate the IOTP offer.
>  6) Merchant generates IOTP Offer Response and optionally signs it.
>  7) Consumer selects payment brand, protocol, currency.
>  8) ...
>  
> What IOTP message could be used in point 5? Maybe Brand Dependent 
> Purchase (TPO Selection) could be extended to include Org
> components for Consumer and DelivTo trading roles (for the Merchant
> to include them in the Offer Response)?
> 
> Regards...
> Andras 
> 
> ----
> Andras Varga
> MeTechnology Ltd.
> 
> --------------------------------------------------------------
> ---------
> 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]
>