[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-trade Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-trade Home]
Powered by eList eXpress LLC