OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-enotary message

[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