[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [legalxml-enotary] Example - Authenticating Request For Service
This soundslike a pretty standard enrollment procedure, which often is encountered in the process of getting an SSL server certificate for a business enterprise. In the law we might refer to such information as circumstantial evidence. That is useful to invoke when there is a paucity of information at one's disposal, as in the investigation of a crime. It is somewhat disappointing as a selection in a field of almost unlimited choices when identity is first established for key mapping purposes. For one who is the least bit determined, a Dunn and Bradstreet rating and Equifax account are not that hard to get. Having a trumped up business name and phone number, with an associate on the line, is all that is needed to fool the enrollment process. The CA who relies on that identification has little to offer a bank that is looking for substantial electronic online residential mortgage lending capabilities. Therefore, such an identification would not be suitable for online transactions of any kind where the due diligence of the relying party involved required more than the identification process which you have described. This having been said, for ordinary commercial purposes of repetitive low value transactions, where perhaps a username and password had been previously employed for authorization access to an Internet web service of an e-commerce site, the enrollment process is perfectably acceptable. Therefore, it could be said that the process performs an eNotary function for a defined category of online transactions where the per transaction value does not exceed, for sake of argument $100, where eNotary is a short hand expression for what should be adjudged by the courts to be self-authenticating evidence under the Federal Rules of Evidence, E.R. 901 et seq. and equivalent state law in the United States. That section of the federal evidence code has been referred to consistently in the cases previously provided to the TC dealing with authentication and admissibility of electronic evidence in federal courtroom trials. I propose that we take on the task of creating a formula for bringing forward the application of such a dollar standard (of any hypothetical value) during predictable economic flunctuations so that equivalent relative values between the value of the transaction in relation to the other values of the society could be maintained indefinitely into the future. That requires identifying the policies and business rules being served, articulating how they translate to a dollar amount, and where they should be placed in a hierarchy that balances ranges of services against risks of liability across an entire field of information services. Where the work will make an important contribution practically is in consideration of the cases which fall squarely within the standard. Proving the content of the transaction will be facilitated and perhaps even declared to be definitive in the absence of any known contrary information, and all capable of being performed from beginning to end through totally automated means. That will create a base level of legal certainty which will help to promote robust computerized activity in each eNotarized sector. Although this might displace paper notaries for such transactions, there are wonderful opportunities for the higher value paper and electronic transactions as in international real estate transactions, and enterprising individuals can improve their lot consistently with the eNotary process, with some advanced training. This ties in well with the offer of Dr. Leff to investigate how eNotary could apply to ebXML (to be described in the draft minutes, which will be forthcoming). Once we havesuccessfully tackled the described enrollment process, we can begin to expand with a consideration of what else in addition to SSL ebXML brings to the infrastructure, and what its eNotary needs may be, given where it ties into the emerging WSS security hiearchy. I think we should ask Dr. Leff if he would be willing take on the added job of eNotary liasion to ebXML in addition to doing that job for the Court Filing TC of LegalXML Oasis. Please be alert to the absence in the discussion so far of data integrity determinations, which bring their own eNotary considerations. I think most of us can agree that the standard public key exchange principles for the generation and transmission of a shared symmetric session key used by SSL probably meet any conceivable eNotary standard, but I think we should articulate in concrete policy language why we feel that way. I would appreciate comment on these propositions. ----- Original Message ----- From: "Moskovitz, Ram Austryjak" <ram@verisign.com> To: <legalxml-enotary@lists.oasis-open.org> Sent: Friday, October 18, 2002 10:47 AM Subject: [legalxml-enotary] Example - Authenticating Request For Service > Hiya, > > Here's my first contribution of an example - a real world example from our > Public CA operations team. > > When we are processing certificate requests we jump through a number of > hoops to ensure that the request is legitimate (requestor is authorized by > the company, company exists, right to use name, right to use domain name... > - the details vary by class, product line, and political/social/geographical > constraints etc). > > We may use a third party (credit scorer, government agency) to lookup a > corporate phone number in order to call back into the organization and > ensure that the alleged employee who made the certificate request is in > actual fact an employee of the named organization and/or is authorized to > act on their behalf. If we are unable to get a third party reference to the > phone # then we require the customer provide a notarized letter confirming > the organization has in fact enrolled for a n ID as well as validating the > name and email address of the technical contact. > > ram > > ----- > Ram Austryjak Moskovitz > Director > VeriSign Research > VeriSign, Inc. > Ram@VeriSign.Com > +1(650)426-3485 > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC