Subject: RE: Question for IOTP Authentication

From: David Burdett <[email-masked]>
Date: Fri, 30 Apr 1999 00:00:54 +0100

Yoshiaki

As you can see I'm catching up on all the Trade WG emails and have thought
about your suggestion. In principle I can see why allowing a Consumer to
authenticate a Merchant is reasonable as, in the current version of the
specification, it states that a Conumer can authenticate a Payment Handler
or a Delivery Handler (see section 8.1.13 second bullet point) and therefore
it is logical that a Consumer should also be able to authenticate a
Merchant.

However the method you suggest below for authenticating a Merchant is
different from the way the Consumer authenticates a Payment Handler or
Delivery Handler in that it is integrated into the transaction (e.g a
purchase) which implies a further variation on the message flow. So, I
suggest that we meet your requirement by simply changing the first bullet
point in section 8.1.13 to read the authentication transaction can be used
... " by a Consumer to authenticate a *Merchant*, Payment Handler or a
Delivery Handler ..."

Is this OK?

David

> ----------
> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> Sent: 	29 March 1999 22:45
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: 	RE: Question for IOTP Authentication
> 
> David,
> I agree with your suggestion.
> But I also want to add the Merchant Authenticaton by Consumer 
> prior to IOTP Purchase Transaction.
> 
> These are the same flow as follows,
> 
> Consumer             Merchant
>    <-------------------
>          TPO
> 
>    ------------------->
>       Auth Req
> 
>    <------------------
>       Auth Res
> 
> and Status Block is not sent to the Merchant.
> 
> After Consumer receives the Auth Response,
> 1. If prior to IOTP purchase transaction
> Success: Consumer sends the message to the Success NetLocation.
> Fail: Stop
> 
> 2. If in the IOTP Purchase Transaction
> Success: Continue the transaction
> Fail: Stop.
> 
> Make sense?
> 
> This is minor change and I think there is no affect in the IOTP protocol.
> Regards,
> ----
> Yoshiaki Kawatsura : E-mail [email-masked]
>  Business & Information Systems Development Devision, Hitachi,Ltd.
> Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> 
> 
>  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
> 	 David Burdett <[email-masked]> said:
> 
>  >Yoshiaki
>  >
>  >The current version of IOTP does not support authentication of the
> Merchant
>  >by the Consumer. Part of the reasoning behind this is that the Merchant
> will
>  >include a signature in the offer which can be used for this purpose.
>  >HOwever, as you say, the consumer might not want to give address
> information
>  >until they have authenticated the Merchant.
>  >
>  >You could actually do this although section 8.1.13 does not specifically
>  >state this. What would be requried is that, after the Consumer has
> received
>  >the TPO, he authenticates the merchant with a separate Authentication
>  >transaction and then if its  OK continues with the original transaction.
>  >
>  >Would this make sense? If you think it does then please post the idea to
> the
>  >list. I don't know though if we want to include this in v1.0 although it
>  >could easily go into v 2.0
>  >
>  >David
>  >
>  >> ----------
>  >> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
>  >> Sent: 	25 March 1999 22:46
>  >> To: 	[email-masked]; [email-masked];
> [email-masked]
>  >> Cc: 	[email-masked]
>  >> Subject: 	Question for IOTP Authentication
>  >> 
>  >> Don and David,
>  >> I have a couple of question for IOTP Authentication.
>  >> 
>  >> Consumer wants to send private information such as home address to
>  >> authenticated merchants only for Offer. In fact, SET is attempting to
>  >> support simliar functionality. I believe that IOTP should support
> this.
>  >> 
>  >> IOTP version 1.0 cannot do this function in Offer Exchange, since the
>  >> Offer Exchange is simplified. The idea would be that initially IOTP
>  >> processes an Authentication, then a Web browser sends a private
>  >> information for Offer, and finally IOTP does Purchase Transaction. In
>  >> IOTP version 1.0, IOTP supports a Consumer Authentication by Merchant,
>  >> however, IOTP does not support a Merchant Authentication by
>  >> Consumer. Is this correct?
>  >> 
>  >> If this is correct, will IOTP version 2.0 support the Merchant
>  >> Authentication by Consumer?
>  >> 
>  >> Regards,
>  >> 
>  >> --
>  >> Yoshiaki Kawatsura
>  >> Hitachi, Ltd.
>  >> 
>  >
> 
> 
> 
> 

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
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: "Lewis, Tony" <[email-masked]>
Date: Thu, 29 Apr 1999 17:36:04 -0700

David,

I believe this proposal originates from requirements that SETCo has defined
for SET 2.0 although when we discussed the approach outlined by Yoshiaki at
our meeting last week, we recommended some changes.

I believe what we will need is the ability for the merchant to push some
data (certificates and a signed message from the acquirer) to the cardholder
wallet who will use that data to authenticate the merchant. If that can be
accomplished with the existing authentication transaction then I believe
your change will satisfy our needs.

However, there may be other issues behind the input from Hitachi so Yoshiaki
should also respond.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Thursday, April 29, 1999 4:00 PM
> To: 	Yoshiaki KAWATSURA
> Cc: 	Ietf Trade WG

---

From: David Burdett <[email-masked]>
Date: Fri, 30 Apr 1999 20:04:11 +0100

Tony

I can think of three ways that IOTP might be able to meet the requirement
you describe:
*	using the Packaged Content element in the Pay Protocol element (see
section 6.6.4),
*	the Consumer authenticates the Merchant separately using an
authentication transaction, or 
*	a combination of the two.

Each is discussed in a bit more detail below.

PAY PROTOCOL ELEMENT
This involves the merchant including the relevent certificate and message
from the acquirer in the PackagedContent element in the Pay Protocol element
for SET of the Brand List (see spec section  6.6.4), then if the Consumer
wants to use SET for a payment they just pass the data to the SET payment
software working within IOTP which then checks the credentials.

The advantage of this approach is that the certificate will always be there
and no extra messages will be required to retrieve it. The disadvantage is
that it increases the size of the messages.

SEPARATE CONSUMER AUTHENTICATION OF THE MERCHANT
In this case, the SET software recognises that there a certificate and
message from the acquirer is needed and makes a request to the IOTP software
to obtain it. When this need occurs, a separate IOTP Authentication
Transaction (see spec section 8.1.6) is used to get the information. 

This would involve:
*	the Consumer sending an IOTPAuthentication Request message to the
merchant specifying in the Algorithm element that the Merchant should do,
for example, a SET merchant authentication, then
*	the Merchant replying with a Authentication Response message
including the necessary certificate and acquirer message in the Packaged
Content.

COMBINATION
An alternative might be to include some fingerprint of the
certificate/message in the PayProtocol element, so that the consumer SET
software can check if it already has a copy of it. If it hasn't then a
separate consumer initiated IOTP Athentication of the merchant could be used
to obtain it.

Does this make sense?

David

> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	29 April 1999 17:36
> To: 	Yoshiaki KAWATSURA
> Cc: 	Ietf Trade WG
> > >  >Would this make sense? If you think it does then please post the
> idea
> > to
> > > the
> > >  >list. I don't know though if we want to include this in v1.0
> although
> > it
> > If you are not the intended recipient, please notify the postmaster
> using
> > email 

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200