[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-trade Home]
Subject: RE: FW: Authorization before OTP
I agree with Don. This is a definite for version 2.0. David >---------- >From: Donald E. Eastlake 3rd[SMTP:dee3@torque.pothole.com] >Sent: 02 October 1998 22:26 >To: Smith, Chris >Cc: 'ietf-trade@lists.eListX.com' >Subject: Re: FW: Authorization before OTP > >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" <CHRIS.SMITH@royalbank.com> >To: "'ietf-trade@lists.eListX.com'" <ietf-trade@lists.eListX.com> >Date: Thu, 24 Sep 1998 16:42:00 -0400 >Message-ID: <9809241647.aa13526@one.eListX.com> >Sender: ietf-trade-owner@lists.eListX.com >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:andrew@sdl.hitachi.co.jp] at Internet >>Date: 1998-09-24 09:10 >> >> >>This message from David Burdett, and meant for the list. >> >>-- >>Andrew Drapp >>andrew@sdl.hitachi.co.jp >>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:David.Burdett@MONDEX.com] >>Sent: Thursday, September 24, 1998 9:36 PM >>To: 'Andrew Drapp' >>Subject: RE: Authorization before OTP >> >>See comments below. >> >>David >>>---------- >>>From: Andrew Drapp[SMTP:andrew@sdl.hitachi.co.jp] >>>Sent: 24 September 1998 06:02 >>>To: David Burdett; 'ietf-trade@lists.eListX.com' >>>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 >>>andrew@sdl.hitachi.co.jp >>>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:David.Burdett@MONDEX.com] >>>Sent: Wednesday, September 23, 1998 4:33 PM >>>To: 'Andrew Drapp' >>>Cc: 'ietf-trade@lists.eListX.com' >>>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:andrew@sdl.hitachi.co.jp] >>>>Sent: 22 September 1998 04:15 >>>>To: 'ietf-trade@lists.eListX.com' >>>>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 >>>>andrew@sdl.hitachi.co.jp >>>>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: ietf-trade@lists.elistx.com >>>>Archive available at: http://www.elistx.com/archives/ietf-trade/ >>>>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the >>>>body to: ietf-trade-request@lists.elistx.com >>>> >>> >>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> >>>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: ietf-trade@lists.elistx.com >>>Archive available at: http://www.elistx.com/archives/ietf-trade/ >>>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the >>>body to: ietf-trade-request@lists.elistx.com >>> >> >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >>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: ietf-trade@lists.elistx.com >>Archive available at: http://www.elistx.com/archives/ietf-trade/ >>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the >>body to: ietf-trade-request@lists.elistx.com >>----------------------------------------------------------------------- >>Message addressed to: ietf-trade@lists.elistx.com >>Archive available at: http://www.elistx.com/archives/ietf-trade/ >>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the >>body to: ietf-trade-request@lists.elistx.com >----------------------------------------------------------------------- >Message addressed to: ietf-trade@lists.elistx.com >Archive available at: http://www.elistx.com/archives/ietf-trade/ >To (un)subscribe send a message with "subscribe" or "unsubscribe" in the >body to: ietf-trade-request@lists.elistx.com > ----------------------------------------------------------------------- Message addressed to: ietf-trade@lists.elistx.com Archive available at: http://www.elistx.com/archives/ietf-trade/ To (un)subscribe send a message with "subscribe" or "unsubscribe" in the body to: ietf-trade-request@lists.elistx.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-trade Home]
Powered by eList eXpress LLC