Subject: Re: FW: Authorization before OTP

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 02 Oct 1998 17:26:50 -0400

I think there are a lot of good ideas below but they seem much more appropriate
for version 2.0.

Thanks,
Donald

From:  "Smith, Chris" <[email-masked]>
To:  "[email-masked]'" <[email-masked]>
Date:  Thu, 24 Sep 1998 16:42:00 -0400
Message-ID:   <[email-masked]>
Sender:  [email-masked]
X-elistx:  ietf-trade

>
>Discussions like this make me think that an Authentication Exchange should 
>be allowed to become as fully complex as Payment Exchange IN THE SENSE THAT 
>there may be multiple round trips, and more than two parties may be 
>involved.
>
>In addition, it would allow the (already existing) requirement of 
>Customer(PaymentInstrument) authenticated by PaymentHandler, even though 
>the Customer must send the first AuthRequest TO the PaymentHandler.
>
>In flow...
>                Authentication Exchange
>   Customer                                Payment Handler
>   -------------------------------------------------------
>                   --AuthRequest--> 
>                   <-AuthExchange-- (Auth Details; crypto method and
>challenge)
> (crypto response) --AuthExchange->   check response
>                   <-AuthResponse-- send status
>
>1. Yes, I know it adds round trips. Some of these could travel at the same
>   time as parts of the Payment Exchange. Some can't. If you want this
>   functionality. it doesn't come for free.
>
>2. This moves us more towards dynamic and generalized Exchange sets. 
>   Do we *really* want this in Baseline?
>
>3. Finally, some of the 'ContinueNetLocn' functionality could be handled
>   by allowing one party (the Merchant) to send an AuthRequest to the Consumer
>   but require that the AuthResponse be shipped elsewhere (PaymentHandler). We
>   do already offer something like this (if I recall correctly) but not in this
>   more open fashion.
>
>Finally, we are again seeing that Org elements (perhaps even new organizations) 
>may be added to the transaction partway through. For example, I may be prepared 
>to give certain Org details to a DeliveryHandler (or PaymentHandler) that I do 
>not want to send to the other party. As such, I do not want to ship the Org 
>components as they appeared on the TPO - I may even want to add details that the
>Merchant was not given.
>
>This is (my opinion) an even more clear-cut reason to allow Org (organizations) 
>to be added to the transaction after the startup. There may be several ways to 
>do this, but we need to decide if we will allow Org components to be added or 
>modified and what the implications are.
>
>And, again, is this something we really want to do for Baseline?
>
>-----
>
>We are moving steadily in the direction of dynamic transactions and flexible
>signature architectures. Do we NEED this for Baseline (for 1.0) or can this wait
>for a later version?
>
>...chris
>
>______________________________ Reply Separator
>_________________________________
>Subject: FW: Authorization before OTP
>Author:  "Andrew Drapp" [SMTP:[email-masked]] at Internet
>Date:    1998-09-24 09:10
>
>
>This message from David Burdett, and meant for the list.
>     
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN 
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>     
>-----Original Message-----
>From:     David Burdett [SMTP:[email-masked]] 
>Sent:     Thursday, September 24, 1998 9:36 PM
>To:     'Andrew Drapp'
>Subject:     RE: Authorization before OTP
>     
>See comments below.
>     
>David
>>----------
>>From:      Andrew Drapp[SMTP:[email-masked]] 
>>Sent:      24 September 1998 06:02
>>To:      David Burdett; [email-masked]' 
>>Subject:      RE: Authorization before OTP
>>
>>
>>David,
>>
>>I think I explained myself poorly.  When I said that the Org component is
>in 
>>the first OTP message, I was referring to the TPO as the first OTP message.
>
>>
>>
>>When you say "The TPO Block can contain Organization Components" how
>exactly 
>>do you mean *can*.  From what I understood, the Org components were removed
>
>>from the Offer response, and placed only in the TPO Block.  The Org 
>>component would then be copied from message to message.  So, once the TPO 
>>message is sent, the Org component has a fixed value that cannot be
>changed. 
>>
>>
>>If we change the Authentication Transaction so that it contains the details
>
>>of the organization which is requesting the Authentication, then those 
>>details should also include a net location for the auth response to go to. 
>> If we made that change, then both the consumer and the merchant could 
>>authenticate each other before a trade actually occurs.
>>
>>I think that would solve this problem.
>>>>Agreed. Provided that the trading role(s) used by the requesting 
>organisation reflect the organisation's intended role in the actual 
>transaction. You could also make a constraint that the Organisation 
>component should not change between the use in the authentication and 
>the use in, for example, the Baseline Purchase.<<<
>>
>>--
>>Andrew Drapp
>>[email-masked]
>>Hitachi Systems Development Laboratory 
>>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN 
>>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F 
>>
>>-----Original Message-----
>>From:     David Burdett [SMTP:[email-masked]] 
>>Sent:     Wednesday, September 23, 1998 4:33 PM
>>To:     'Andrew Drapp'
>>Cc:     [email-masked]' 
>>Subject:     RE: Authorization before OTP 
>>
>>Andrew
>>
>>Not quite right. The TPO Block can contain Organisation Components. We 
>>should change the definition of the Authentication Transaction to >require 
>that this contains the details of the organisation which is >requesting the 
>Authentication specifying the role in which the >authenticator is taking in 
>the transaction (Merchant, Payment Handler or >Delivery Handler).
>>
>>The consumer will then know who to send the response to. 
>>
>>David
>>
>>
>>>----------
>>>From:      Andrew Drapp[SMTP:[email-masked]] 
>>>Sent:      22 September 1998 04:15
>>>To:      [email-masked]' 
>>>Subject:      Authorization before OTP 
>>>
>>>
>>>At the OTP meeting in Reston, there was some discussion of using the 
>>>Authorization exchange to automate the collection of personal information 
>>
>>>for a sale.  This would save time in typing out you name and address each 
>>
>>>time you purchased something.  This would have to occur before the first 
>>OTP
>>>message is sent, because the Org block is in the first message and cannot 
>>be
>>>changed later on.
>>>
>>>From what I remember of the meeting, it was generally agreed that this was
>
>>a
>>>good idea, and should be included in version 1.0 or 2.0. 
>>>
>>>However, I recently noticed a problem with that approach.  When the 
>>consumer
>>>receives an AuthReq block, it will have to be in HTML because the OTP 
>>client
>>>has not started yet.  This will kick off the OTP client which will create 
>>
>>>the AuthResp block.  The problem is, that the OTP client does not know 
>>where
>>>to send the AuthResp block.  No address information is included in the 
>>>AuthReq block.  It is assumed that the OTP client could just check the 
>>>TransId for the location, but because this occurs before the Offer 
>>Exchange,
>>>there is no TransId to refer too.
>>>
>>>Because of this, I suggest that:
>>>
>>>1.  We add addressing information to the AuthReq block, 
>>>
>>>or
>>>
>>>2.  We dump the idea to use the Authorization exchange outside of an OTP 
>>>transaction.
>>>
>>>
>>>Regards,
>>>
>>>Andrew Drapp
>>>
>>>
>>>--
>>>Andrew Drapp
>>>[email-masked]
>>>Hitachi Systems Development Laboratory 
>>>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN 
>>>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>>>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F 
>>>
>>>
>>>----------------------------------------------------------------------- 
>>>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]
>>>
>>
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>Mondex International Limited
>>47-53 Cannon Street, London  EC4M 5SQ 
>>England
>>Registered No: 3122085, England
>>
>>Telephone No: +44 (0)171 557 5000
>>Web Site: http://www.mondex.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]
>>
>     
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     
>     
>Mondex International Limited
>47-53 Cannon Street, London  EC4M 5SQ 
>England
>Registered No: 3122085, England
>     
>Telephone No: +44 (0)171 557 5000
>Web Site: http://www.mondex.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]
-----------------------------------------------------------------------
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: David Burdett <[email-masked]>
Date: Tue, 6 Oct 1998 00:19:59 +0100

I agree with Don. This is a definite for version 2.0.

David

>----------
>From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
>Sent: 	02 October 1998 22:26
>To: 	Smith, Chris
>Subject: 	Re: FW: Authorization before OTP 
>