Subject: RE: Question for IOTP Authentication

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Mon, 03 May 1999 00:19:45 +0900 (JST)

Tony mentioned to me the Mercahnt authentication has to do prior to
shopping phase, this is out of IOTP. So we can use separete
authentication only.

We need to define the SET Specific authentication, which
satisfy the requirement to the BAG Requirement, in SETCo.  because
consumer have to confirm whether Merchant is authorized by the
Acquirer and this requirement is payment dependent(IOTP is the payment
scheme independent messaging protocol).

I believe that the merit of using IOTP authentication is that we
can be concerned IOTP Authentication transaction with IOTP
Purchase transaction.

--
Yoshiaki Kawatsura Hitachi, Ltd.

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

> 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
> > Subject: 	RE: Question for IOTP Authentication
> > 
> > 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
> > > Subject: 	RE: Question for IOTP Authentication
> > > 
> > > 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]
> > > 
> > -----------------------------------------------------------------------
> > 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]
> > 
> 
> **********************************************************************************************
> 
> 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: Mon, 3 May 1999 11:50:45 -0700

Yes, this authentication is performed prior to the shopping phase, but can't
it be processed as a null payment and use both IOTP and SET authentication
mechanisms?

Tony
> Sent: 	Sunday, May 02, 1999 8:19 AM
> Cc: 	Lewis, Tony; [email-masked]; [email-masked]
> using email

---

From: "Lewis, Tony" <[email-masked]>
Date: Tue, 4 May 1999 08:20:38 -0700

David,

I'm replying to the list since the answer to your off-list question to me is
likely to be of general interest.

We are looking for a way to support an "Authenticate Me" button on a
merchant web site. When this button is clicked, it will invoke the SET
wallet, which will validate the merchant certificate, the payment gateway
certificate and a special signed message. If the validation is successful,
the wallet will then display a message indicating that this is a valid SET
merchant.

The flow would be something like this:

Click: "Authenticate Me"

<--- Authentication Wake up
---> PInitReq
<--- PInitRes

Wallet: "This is a valid SET merchant."

I'm suggesting that IOTP can be used for the wake up if we treat this as a
"null" payment (one where the payment phase is elided).

By the way, "BAG" is the "SETCo Business Advisors Group", which will hold
its first meeting next week.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Monday, May 03, 1999 3:00 PM
> To: 	Lewis, Tony
> I don't quite understand what Yoshiaki is talking about in his email. When
> he refers to the BAG requirement, what does he mean? I also don't quite
> understand how a "null" payment could be used as part of the solution as
> you
> describe.
> 
> It's just that I'm trying to understand the requirement so that I can see
> how IOTP could meet the need.
> 
> Clarification will be greatly appreciated.
> 
> David
> 
> 
> 
> > ----------
> > Sent: 	03 May 1999 11:50
> > To: 	[email-masked]
> > > > 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
> > > > merchant specifying in the Algorithm element that the Merchant
> should
> > > do,
> > > > separate consumer initiated IOTP Athentication of the merchant could
> > be
> > > used
> > > > to obtain it.
> > > > 
> > > > Does this make sense?
> > > > 
> > > > David
> > > > 
> > > > 
> > > > 
> > > > > ----------
> > > > > I believe what we will need is the ability for the merchant to
> push
> > > some
> > > > > wallet who will use that data to authenticate the merchant. If
> that
> > > can be
> > > > > > authenticate a Merchant is reasonable as, in the current version
> > of
> > > the
> > > > > > 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
> > > > > > 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
> > > > > > 		
> > > > > > 
> > > > > > > ----------
> > > > > > >  >The current version of IOTP does not support authentication
> of
> > > the
> > > > > > > Merchant
> > > > > > >  >state this. What would be requried is that, after the
> Consumer
> > > has
> > > > > > > received
> > > > > > >  >> From: 	Yoshiaki
> KAWATSURA[SMTP:[email-masked]]
> > > > > > >  >> IOTP version 1.0 cannot do this function in Offer
> Exchange,
> > > since
> > > > > > the
> > > > > > 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 
> > > > > > To (un)subscribe send a message with "subscribe" or
> "unsubscribe"
> > in
> > > the
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > > the

---

From: Steve Fabes <[email-masked]>
Date: Tue, 4 May 1999 15:27:54 -0700

What would this do to the txn time and number of messages going across?
-----Original Message-----
From: Lewis, Tony <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, May 03, 1999 12:20
Subject: RE: Question for IOTP Authentication

So,
>> > > > ... " by a Consumer to authenticate a *Merchant*, Payment Handler
or
files,
in

---

From: "Lewis, Tony" <[email-masked]>
Date: Tue, 4 May 1999 18:58:11 -0700

I thought I sent this to the list, but just realized that I did not.
> ----------
> From: 	Lewis, Tony
> Sent: 	Tuesday, May 04, 1999 5:14 PM
> To: 	'Steve Fabes'
> I think the transaction time is orthogonal to the authentication. The
> entire user experience will go something like this:
> 
> Enter web site.
> Press "Authenticate me".
> Shop.
> Press "Pay".
> Obtain certificates (SET PInitReq).
> Press "Confirm payment".
> Send purchase request (SET PReq).
> 
> There will likely be substantial clock time between the authentication
> request and the purchase.
> 
> Tony
> ----------
> From: 	Steve Fabes[SMTP:[email-masked]]
> Sent: 	Tuesday, May 04, 1999 3:27 PM
> To: 	Lewis, Tony
> Cc: 	Ietf Trade WG
> Subject: 	Re: Question for IOTP Authentication
>

---

From: David Burdett <[email-masked]>
Date: Wed, 5 May 1999 20:10:41 +0100

Tony

Thanks for the clarification, however, the SET  "authenticate me" is new to
me so I'd appreciate your clarification on a couple of things so that I can
see where it's coming from:

*	have you thought about what a user would do to authenticate a
merchant if they don't want to pay using SET?
*	what benefits, in business terms, would a user get from doing an SET
"authenticate me" rather than some other form of merchant authentication,
e.g. a straightforward IOTP authentication which returned a digital
signature that carried specific assertions?

David

> Sent: 	04 May 1999 08:20
> To: 	ietf-trade
> > > > > from the acquirer in the PackagedContent element in the Pay
> Protocol
> > > > element
> > > > > message from the acquirer is needed and makes a request to the
> IOTP
> > > > software
> > > > > 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
> > > > > > > >  >include a signature in the offer which can be used for
> this
> > > > purpose.
> > > > > > > >  >Would this make sense? If you think it does then please
> post
> > > the
> > > > > > idea
> > > > > > > to
> > > > > > > > the
> > > > > > > >  >> support simliar functionality. I believe that IOTP
> should
> > > > support
> > > > > > > > this.
> > > > > > > >  >> 
> > > > > > > >  >> IOTP version 1.0, IOTP supports a Consumer
> Authentication
> > by
> > > > > > > Merchant,
> > > > > > > This Email and any attached files are confidential and may
> also
> > be
> > > > > > > privileged. 
> > > > > > > Archive available at:
> http://www.elistx.com/archives/ietf-trade/

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

---

From: "Lewis, Tony" <[email-masked]>
Date: Wed, 12 May 1999 23:04:00 -0700

Sorry for the delayed response. I've been pretty much in non-stop meetings
since your message arrived.

We haven't specified the user interface for merchant authentication so this
is my personal vision; others from SETCo might offer a different perspective
on the UI. I'm expecting that merchants will eventually have a logo
available either on their home page or very early in the browsing
experience. Cardholders will come to recognize the logo as one that
indicates that the merchant can be authenticated. When the cardholder clicks
on the logo, a dialogue will begin with the wallet. At the conclusion of the
dialogue, the wallet will announce to the cardholder either that the
merchant has been authenticated or that it has not.

The benefit to cardholders is that they will be able to authenticate a
merchant before disclosing identifying information (name, address, etc.) or
personal information (dress size, medical condition, etc.).

The benefit to merchants is that cardholders will be more likely to do
business with a merchant that a financial institution certifies as having an
ongoing relationship.

Drilling down to the technical details, I envision a solution where the
financial institution creates a daily "I still trust this merchant" message
that will be included as part of the "Authenticate me" dialogue. This is an
improvement over a signed message from the merchant because it confirms an
ongoing relationship. (If SET had a merchant CRL, the signed message plus a
CRL check would serve the same purpose.)

In our SET pilots, cardholders have liked the fact that the merchant is
authenticated during the purchase phase, but have asked for that
authentication to occur earlier in the shopping experience.

Tony
> Sent: 	Wednesday, May 05, 1999 12:10 PM
> To: 	Ietf Trade WG; Lewis, Tony
> > I'm replying to the list since the answer to your off-list question to
> me
> > is
> > > > Yes, this authentication is performed prior to the shopping phase,
> but
> > > > can't
> > > > > > This involves the merchant including the relevent certificate
> and
> > > > > message
> > > > > > wants to use SET for a payment they just pass the data to the
> SET
> > > > > payment
> > > > > > In this case, the SET software recognises that there a
> certificate
> > > and
> > > > > > > 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
> > > > > > > accomplished with the existing authentication transaction then
> I
> > > > > believe
> > > > > > > However, there may be other issues behind the input from
> Hitachi
> > > so
> > > > > > > Yoshiaki
> > > > > > > should also respond.
> > > > > > > 
> > > > > > > Tony
> > > > > > > > ----------
> > > > > > > > As you can see I'm catching up on all the Trade WG emails
> and
> > > have
> > > > > > > thought
> > > > > > > > or a Delivery Handler (see section 8.1.13 second bullet
> point)
> > > and
> > > > > > > > therefore
> > > > > > > > >  >by the Consumer. Part of the reasoning behind this is
> that
> > > the
> > > > > > > > Merchant
> > > > > > > > > will
> > > > > > > > >  >> Consumer wants to send private information such as
> home
> > > > > address to
> > > > > > > > >  >> authenticated merchants only for Offer. In fact, SET
> is
> > > > > attempting
> > > > > > > > to
> > > > > > > > >  >> processes an Authentication, then a Web browser sends
> a
> > > > > private
> > > > > > > > >  >> however, IOTP does not support a Merchant
> Authentication
> > > by